El progreso reciente en IA es muy emocionante. La gente lo está utilizando de muchas maneras novedosas, desde las experiencias de atención al cliente y código, hasta música nueva e incluso la tecnología de imágenes médicas. mejorar escribir y ejecutar crear acelerar Pero en el proceso, ha surgido una tendencia preocupante: la comunidad de IA parece estar reinventando el movimiento de datos (también conocido como ETL). Ya sea que los llamen conectores, extractores, integraciones, cargadores de documentos o cualquier otra cosa, las personas escriben el mismo código para extraer datos de las mismas API, formatos de documentos y bases de datos y luego los cargan en bases de datos vectoriales o índices para sus LLM. El problema es que construir y mantener tuberías robustas de extracción y carga desde cero es un gran compromiso. Y hay tanto arte previo en esa área que para casi todos los ingenieros o empresas en el espacio de la IA, es una gran pérdida de tiempo reconstruirlo. En un espacio donde surgen noticias de última hora aproximadamente cada hora, el enfoque principal debe estar en hacer que su producto principal sea increíble para sus usuarios, no en realizar misiones secundarias. Y para casi todos, el producto central no es el movimiento de datos; es la salsa mágica impulsada por IA que estás elaborando. Se ha escrito mucho ( , ) sobre los desafíos que implica la creación de canalizaciones robustas de extracción, transformación y carga (ETL), pero contextualicémoslo dentro de la IA. 1 2 ¿Por qué la IA necesita movimiento de datos? Los LLM capacitados en datos públicos son excelentes, pero ¿sabe qué es aún mejor? AI que pueden responder preguntas específicas para nosotros, nuestras empresas y nuestros usuarios. A todos nos encantaría que ChatGPT pudiera aprender toda la wiki de nuestra empresa, leer todos nuestros correos electrónicos, mensajes de Slack, notas y transcripciones de reuniones, conectarse al entorno de análisis de nuestra empresa y usar todas estas fuentes al responder nuestras preguntas. O al integrar IA en nuestro propio producto (por ejemplo, con Notion AI , nos gustaría que el modelo de IA de nuestra aplicación conozca toda la información que tenemos sobre un usuario cuando lo ayudamos. ) El movimiento de datos es un requisito previo para todo eso. Ya sea que esté ajustando un modelo o la generación aumentada por recuperación (RAG), necesita extraer datos de donde sea que vivan, transformarlos en un formato digerible para su modelo y luego cargarlos en un almacén de datos al que pueda acceder su aplicación de IA. para servir a su caso de uso. utilizando El diagrama anterior ilustra cómo se ve esto cuando se usa RAG, pero puede imaginar que incluso si no está usando RAG, es poco probable que los pasos básicos cambien: necesita Extraer, Transformar y Cargar, también conocido como ETL, los datos para poder construya modelos de IA que conozcan información no pública específica para usted y su caso de uso. ¿Por qué es difícil el movimiento de datos? La creación de un MVP funcional básico para la extracción de datos de una API o una base de datos suele ser, aunque no siempre, factible con un aviso rápido (<1 semana). La parte realmente difícil es prepararlo para la producción y mantenerlo así. Veamos algunos de los desafíos estándar que vienen a la mente al construir tuberías de extracción. Extractos incrementales y gestión de estado Si tiene un volumen de datos significativo, deberá implementar la extracción incremental de modo que su canalización solo extraiga los datos que no ha visto antes. Para hacer esto, deberá tener una capa de persistencia para realizar un seguimiento de los datos que extrajo cada conexión. Manejo de errores transitorios, backoffs, reanudación en caso de falla, espacio de aire Fuentes de datos ascendentes todo el tiempo, a veces sin una razón clara. Sus canalizaciones deben ser resistentes a esto y volver a intentarlo con las políticas de interrupción adecuadas. Si las fallas no son tan transitorias (pero aún así no es su culpa), entonces su tubería debe ser lo suficientemente resistente para recordar dónde se quedó y reanudar desde el mismo lugar una vez que se solucionó el flujo ascendente. Y, a veces, el problema que proviene del flujo ascendente es lo suficientemente grave (como una API que elimina algunos campos cruciales de los registros) que desea pausar toda la tubería hasta que examine lo que está sucediendo y decida manualmente qué hacer. Identificar y corregir proactivamente errores de configuración Si está creando canalizaciones de extracción de datos para extraer los datos de sus clientes, deberá implementar algunos controles defensivos para asegurarse de que toda la configuración que sus clientes le dieron para extraer datos en su nombre sea correcta y, si no lo es, rápidamente. darles mensajes de error accionables. La mayoría de las API no facilitan esto porque no publican tablas de errores completas e incluso cuando lo hacen, rara vez le brindan puntos finales que puede usar para verificar los permisos asignados a, por ejemplo, tokens de API, por lo que debe encontrar formas de equilibrar verificaciones con retroalimentación rápida para el usuario. Autenticación y gestión de secretos Las API varían en simplicidad desde la autenticación de token de portador simple hasta implementaciones "creativas" de tokens de sesión o OAuth de token de un solo uso. Deberá implementar la lógica para realizar la autenticación y administrar los secretos que pueden actualizarse una vez por hora, coordinando potencialmente las actualizaciones de secretos entre varios trabajadores simultáneos. Optimización de las velocidades de extracción y carga, la concurrencia y los límites de velocidad Y hablando de trabajadores simultáneos, es probable que desee implementar la simultaneidad para lograr un alto rendimiento para sus extracciones. Si bien esto puede no importar en conjuntos de datos pequeños, es absolutamente crucial en los más grandes. A pesar de que las API publican límites de tasa oficiales, deberá determinar empíricamente los mejores parámetros de paralelismo para maximizar el límite de tasa que le proporciona la API sin que la IP se incluya en la lista negra o tenga una tasa limitada para siempre. Adaptarse a los cambios de API ascendentes Las API cambian y adoptan nuevos comportamientos o peculiaridades no documentadas todo el tiempo. Muchos proveedores publican nuevas versiones de API trimestralmente. Deberá estar atento a cómo todas estas actualizaciones pueden afectar su trabajo y dedicar tiempo de ingeniería para mantenerlo todo actualizado. Aparecen nuevos puntos finales todo el tiempo, y algunos cambian su comportamiento (y no siempre recibe un aviso). Programación, monitoreo, registro y observabilidad Más allá del código que extrae datos de API específicas, es probable que también necesite crear algunas capacidades horizontales aprovechadas por todos sus extractores de datos. Querrá un poco de programación, así como registro y supervisión para cuando la programación no funcione, o cuando otras cosas salgan mal y necesite investigar. También es probable que desee cierta observabilidad, como cuántos registros se extrajeron ayer, hoy, la semana pasada, etc. y de qué puntos finales de API o tablas de base de datos provienen. Bloqueo de datos o hashing Dependiendo de dónde extraiga los datos, es posible que necesite algunas funciones de privacidad para bloquear o aplicar hash a las columnas antes de enviarlas en sentido descendente. Para ser claros, lo anterior no se aplica si solo desea mover algunos archivos como algo único. Pero se aplica cuando crea productos que requieren movimiento de datos. Tarde o temprano, tendrá que lidiar con la mayoría de estas preocupaciones. Y aunque ninguno de ellos es una ciencia espacial insuperable, en conjunto pueden sumar rápidamente uno o varios trabajos de tiempo completo, más aún cuantas más fuentes de datos obtenga. Y esa es exactamente la dificultad de mantener la extracción de datos y las canalizaciones: la mayor parte de su costo proviene de la inversión incremental continua necesaria para mantener esas canalizaciones funcionales y sólidas. Para la mayoría de los ingenieros de IA, ese no es el trabajo que agrega más valor a sus usuarios. Es mejor pasar su tiempo en otro lugar. Entonces, ¿qué tiene que hacer un ingeniero de inteligencia artificial para mover algunos datos por aquí? Si alguna vez necesita extracción de datos y canalizaciones de carga, pruebe las soluciones ya disponibles en lugar de crear automáticamente las suyas propias. Lo más probable es que puedan resolver muchas, si no todas, sus inquietudes. Si no, construya uno propio como último recurso. E incluso si las plataformas existentes no son compatibles con todo lo que necesita, aún debería poder llegar a la mayor parte del camino con un marco portátil y extensible. De esta manera, en lugar de construir todo desde cero, puede obtener el 90 % del camino con las funciones listas para usar en la plataforma y solo construir y mantener el último 10 %. El ejemplo más común son las integraciones de cola larga: si la plataforma no se envía con una integración a una API que necesita, entonces una buena plataforma facilitará la escritura de código o incluso una solución sin código para construir esa integración y Todavía obtenga todas las características útiles que ofrece la plataforma. Incluso si desea la flexibilidad de simplemente importar un conector como un paquete de python y activarlo como quiera desde su código, puede usar una de las muchas herramientas EL de código abierto como los conectores Airbyte o Singer. Para ser claros, el movimiento de datos no está completamente resuelto. Hay situaciones en las que las soluciones existentes realmente se quedan cortas y necesita crear soluciones novedosas. Pero esta no es la mayoría de la población de ingenieros de IA. La mayoría de las personas no necesitan reconstruir las mismas integraciones con Jira, Confluence, Slack, Notion, Gmail, Salesforce, etc. una y otra vez. Solo usemos las soluciones que ya han sido probadas en batalla y abiertas para que cualquiera las use, de modo que podamos continuar agregando el valor que realmente les importa a nuestros usuarios. También aparece . aquí

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Making security fun one episode at a time

AI no debería tener que perder el tiempo reinventando ETL

Demasiado Largo; Para Leer

John Lafleur

STORY’S CREDIBILITY

Opinion piece / Thought Leadership

Vested Interest

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

AI no debería tener que perder el tiempo reinventando ETL

Demasiado Largo; Para Leer

John Lafleur

STORY’S CREDIBILITY

Opinion piece / Thought Leadership

Vested Interest

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS