La IA no debería perder tiempo reinventando ETL
La IA no debe reinventar ETL
El progreso reciente en IA es muy emocionante. Las personas la están utilizando de formas novedosas, desde mejorar las experiencias de atención al cliente y escribir y ejecutar código hasta crear nueva música e incluso acelerar la tecnología de imágenes médicas.
Pero en el proceso, ha surgido una tendencia preocupante: la comunidad de IA parece estar reinventando el movimiento de datos (también conocido como ELT). Ya sea que los llamen conectores, extractores, integraciones, cargadores de documentos u otra cosa, las personas están escribiendo el mismo código para extraer datos de las mismas APIs, formatos de documentos y bases de datos, y luego cargarlos en bases de datos vectoriales o índices para sus LLMs.
El problema es que construir y mantener tuberías de extracción y carga sólidas desde cero es un compromiso enorme. Y hay tanto conocimiento previo en esa área que para casi todos los ingenieros o empresas en el espacio de IA, es una gran pérdida de tiempo reconstruirlo. En un espacio donde las noticias de última hora surgen aproximadamente cada hora, el enfoque principal debería ser hacer que tu producto principal sea increíble para tus usuarios, no embarcarse en misiones secundarias. Y para casi todos, el producto principal no es el movimiento de datos; es la “salsa mágica” impulsada por IA que estás creando.
Se ha escrito mucho sobre los desafíos involucrados en la construcción de tuberías de Extract, Transform and Load (ETL) sólidas, pero contextualicémoslo dentro de la IA.
¿Por qué necesita la IA el movimiento de datos?
Los LLM entrenados con datos públicos son geniales, pero ¿sabes qué es aún mejor? IA que puede responder preguntas específicas para nosotros, nuestras empresas y nuestros usuarios. A todos nos encantaría que ChatGPT pudiera aprender toda nuestra wiki de la empresa, leer todos nuestros correos electrónicos, mensajes de Slack, notas de reuniones y transcripciones, conectarse a nuestro entorno de análisis de la empresa y utilizar todas estas fuentes al responder nuestras preguntas. O, al integrar la IA en nuestro propio producto (por ejemplo, con Notion AI), nos gustaría que el modelo de IA de nuestra aplicación conociera toda la información que tenemos sobre un usuario cuando los ayudamos.
- ¡10 cosas geniales que puedes hacer con embeddings! [Parte 1]
- 10 Podcasts de Ciencia de Datos que Debes Escuchar si Eres un Entus...
- Este artículo de IA propone Blending-NeRF que consiste en NeRF pree...
El movimiento de datos es un requisito previo para todo eso.
Ya sea que estés ajustando un modelo o utilizando Generación con Recuperación Mejorada (RAG), necesitas extraer datos de donde sea que se encuentren, transformarlos en un formato digerible para tu modelo y luego cargarlos en un almacén de datos al que tu aplicación de IA pueda acceder para satisfacer tu caso de uso.
El diagrama anterior ilustra cómo se ve esto al utilizar RAG, pero puedes imaginar que incluso si no estás utilizando RAG, los pasos básicos son poco probables que cambien: necesitas extraer, transformar y cargar, también conocido como ETL, los datos para construir modelos de IA que conozcan información no pública específica para ti y tu caso de uso.
¿Por qué es difícil el movimiento de datos?
Construir un MVP funcional básico para la extracción de datos desde una API o base de datos generalmente es factible en poco tiempo (menos de 1 semana). La parte realmente difícil es hacerlo listo para 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.
Extracciones incrementales y gestión de estado
Si tienes un volumen significativo de datos, necesitarás implementar extracción incremental para que tu tubería solo extraiga los datos que no ha visto antes. Para hacer esto, necesitarás tener una capa de persistencia para realizar un seguimiento de qué datos extrajo cada conexión.
Gestión de errores transitorios, intervalos de espera, reanudación en caso de fallos, aislamiento de red
Las fuentes de datos upstream fallan todo el tiempo, a veces sin ninguna razón clara. Tus tuberías deben ser resilientes a esto y reintentar con las políticas de intervalo de espera adecuadas. Si los fallos no son tan transitorios (pero aún no son tu culpa), entonces tu tubería debe ser lo suficientemente resiliente como para recordar dónde se detuvo y reanudar desde el mismo lugar una vez que se solucione el problema en la fuente. A veces, el problema que viene de upstream es lo suficientemente grave (como una API que elimina algunos campos cruciales de los registros) como para que quieras pausar toda la tubería hasta que examines qué está sucediendo y decidas manualmente qué hacer.
Identificación y corrección proactiva de errores de configuración
Supongamos que estás construyendo tuberías de extracción de datos para extraer los datos de tus clientes. En ese caso, necesitarás implementar algunas verificaciones defensivas para asegurarte de que toda la configuración que tus clientes te dieron para extraer datos en su nombre sea correcta, y si no lo es, darles rápidamente mensajes de error accionables. La mayoría de las APIs no facilitan esto porque no publican tablas de errores completas y, incluso cuando lo hacen, rara vez te brindan puntos finales que puedas usar para verificar los permisos asignados a, por ejemplo, tokens de API, por lo que debes encontrar formas de equilibrar verificaciones exhaustivas con comentarios rápidos para el usuario.
Autenticación y Gestión de Secretos
Las APIs varían en simplicidad desde una autenticación simple basada en token hasta implementaciones “creativas” de tokens de sesión o tokens de OAuth de un solo uso. Deberás implementar la lógica para realizar la autenticación y gestionar los secretos, que pueden estar siendo actualizados cada hora, potencialmente coordinando la actualización de secretos en múltiples trabajadores concurrentes.
Optimización de la velocidad de extracción y carga, concurrencia y límites de velocidad
Hablando de trabajadores concurrentes, es probable que desees implementar la concurrencia para lograr un alto rendimiento en tus extracciones. Aunque esto puede no importar en conjuntos de datos pequeños, es absolutamente crucial en los más grandes. Aunque las APIs publican límites de velocidad oficiales, deberás determinar empíricamente los mejores parámetros de paralelismo para aprovechar al máximo el límite de velocidad proporcionado por la API sin ser bloqueado o limitado permanentemente.
Adaptándose a los cambios en la API de origen
Las APIs cambian y adoptan nuevos comportamientos o peculiaridades no documentadas todo el tiempo. Muchos proveedores publican nuevas versiones de API trimestralmente. Deberás estar atento a cómo todas estas actualizaciones pueden afectar tu trabajo y dedicar tiempo de ingeniería para mantenerlo actualizado. Constantemente surgen nuevos puntos finales, y algunos cambian su comportamiento (y no siempre te avisan).
Programación, Monitoreo, Registro y Observabilidad
Además del código que extrae datos de APIs específicas, es probable que también necesites construir algunas capacidades horizontales utilizadas por todos tus extractores de datos. Querrás tener programación, así como registro y monitoreo para cuando la programación no funcione o cuando ocurran problemas, y necesites investigar. También es probable que desees tener cierta observabilidad, como cuántos registros se extrajeron ayer, hoy, la semana pasada, etc., y de qué puntos finales de la API o tablas de bases de datos provienen.
Bloqueo o Hashing de Datos
Dependiendo de dónde estés extrayendo datos, es posible que necesites algunas funciones de privacidad para bloquear o hacer hashing de columnas antes de enviarlas hacia abajo.
Para ser claro, lo anterior no se aplica si solo quieres mover algunos archivos de forma puntual.
Pero sí se aplica cuando estás construyendo productos que requieren movimiento de datos. Tarde o temprano, deberás lidiar con la mayoría de estas preocupaciones. Y aunque ninguna de ellas por sí sola es una ciencia de cohetes imposible, juntas pueden sumar rápidamente uno o varios trabajos a tiempo completo, especialmente si estás extrayendo datos de múltiples fuentes.
Y ahí radica precisamente la dificultad de mantener la extracción de datos y las canalizaciones: la mayoría de su costo proviene de la inversión incremental continua necesaria para mantener esas canalizaciones funcionales y robustas. Para la mayoría de los ingenieros de IA, ese no es el trabajo que agrega más valor a sus usuarios. Su tiempo se invierte mejor en otro lugar.
Entonces, ¿qué tiene que hacer un ingeniero de IA para mover algunos datos aquí?
Si alguna vez te encuentras necesitando canalizaciones de extracción y carga de datos, prueba las soluciones ya disponibles en lugar de construir automáticamente la tuya propia. Es probable que puedan resolver muchos, si no todos, tus problemas. Si no es así, construye la tuya como último recurso.
E incluso si las plataformas existentes no admiten todo lo que necesitas, aún deberías poder llegar bastante lejos con un marco portátil y extensible. De esta manera, en lugar de construir todo desde cero, puedes llegar al 90% del camino con características listas para usar en la plataforma y solo construir y mantener el último 10%. El ejemplo más común son las integraciones de baja demanda: si la plataforma no viene con una integración a una API que necesitas, una buena plataforma facilitará escribir algo de código o incluso una solución sin código para construir esa integración y aún obtener todas las características útiles ofrecidas por la plataforma. Incluso si deseas la flexibilidad de simplemente importar un conector como un paquete de Python y activarlo como desees desde tu código, puedes usar una de las muchas herramientas EL de código abierto como Airbyte o los conectores Singer.
Para ser claro, el movimiento de datos no está completamente resuelto. Hay situaciones en las que las soluciones existentes realmente no son suficientes y necesitas construir soluciones novedosas. Sin embargo, esto no es lo que experimenta 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. Simplemente usemos las soluciones que ya han sido probadas en la batalla y se han puesto a disposición de cualquiera para que podamos seguir agregando el valor que realmente les importa a nuestros usuarios.
