Los equipos de plataforma recurren a DataOps y MLOps para respaldar la IAGen

Los primeros usuarios de DataOps se inspiraron en los principios de DevOps para ayudar a los científicos de datos a crear rápidamente valor comercial a partir de big data; a medida que las aplicaciones de IA generativa se generalizan, esa interacción entre disciplinas de TI está cerrando el círculo.

Al igual que con el desarrollo de software ágil y los métodos DevOps, las operaciones de datos buscaban derribar las barreras organizacionales y fomentar la colaboración entre las partes interesadas del negocio y los equipos de TI. Por lo tanto, ya se ha producido cierto intercambio de técnicas entre disciplinas. Los ingenieros de DevOps y de plataforma llevan años aplicando métodos desarrollados por profesionales de DataOps y operaciones de aprendizaje automático (MLOps) a los flujos de trabajo de AIOps y de observabilidad.

Pero ahora, la IA generativa está impulsando el análisis basado en datos cada vez más hacia el uso general de los usuarios comerciales, colocando la gestión y la gobernanza de datos al frente de las preocupaciones de las operaciones de TI empresariales.

La adopción de IA, incluyendo IAGen, se citó como el principal impulsor del aumento del uso de datos corporativos en un reciente estudio de mercado. De los 318 participantes en una encuesta realizada en junio de 2024 por el Grupo de Estrategia Empresarial de Informa TechTarget, el 56 % consideró la IA como la principal razón para tener más usuarios de datos corporativos en sus organizaciones.

La adopción de IA también genera un mayor escrutinio de la gobernanza y la seguridad, preocupaciones fundamentales para los principios de DataOps: el 83 % de los encuestados añadió nuevas funciones de gobernanza de datos o amplió las existentes –o ambos– durante el último año gracias a la IA.

Como ya han descubierto los primeros en adoptar AIOps y las herramientas de automatización de IA, la calidad y la integridad de los datos pueden ser clave para el éxito o el fracaso de estas iniciativas: el 70 % de los encuestados las clasificaron como de alta o muy alta prioridad para los proyectos de IA. La mayoría de los encuestados (el 51 %) indicó que aún no confía plenamente o desconfía ligeramente de la precisión de los datos utilizados en la toma de decisiones.

Secuencias de datos de IAGen vs. Secuencias de datos de ML

Para una empresa con experiencia en DataOps y MLOps, IAGen ha sido una nueva bestia en lo que respecta a la gestión de la calidad de los datos y la arquitectura de la canalización de datos.

«Prácticamente cualquier modelo interesante [de lenguaje extenso] no se entrenará únicamente con un flujo de datos», afirmó Stephen Manley, director de tecnología de Druva, empresa que comercializa una plataforma SaaS de resiliencia de datos. «Se implementarán múltiples flujos, lo que requiere, en mi opinión, un rigor mucho mayor que el que hemos aplicado en el ámbito del aprendizaje automático, donde solía tratarse de un conjunto más pequeño de datos de mayor intensidad».

Por ejemplo, el flujo de trabajo de aprendizaje automático (ML) de Druva procesa 100.000 millones de operaciones por hora, pero esa cantidad de datos no sería adecuada para los modelos de IAGen, afirmó Manley. Los datos de ML suelen utilizarse para detectar anomalías en una serie de eventos bien definidos; el entrenamiento de los grandes modelos de lenguaje que sustentan el asistente de IA Dru de Druva requirió el ajuste preciso de tres flujos de datos diferentes, con tasas de cambio generalmente más bajas para garantizar la consistencia.

Un flujo de datos de LLM consiste en la documentación de Druva; otro, en información sobre el marco de respuesta a incidentes de Mitre ATT&CK , que cambia con poca frecuencia. El tercer flujo de datos, actualizado con mayor frecuencia, contiene información de clientes utilizada para personalizar las respuestas de IA para cada cliente.

La integración de datos de clientes coloca a IAGen en Druva en una posición diferente a las aplicaciones anteriores de big data y ML, dijo Manley.

“En cuanto al aprendizaje automático, procesábamos metadatos internos, por lo que todo estaba sujeto a nuestra necesidad estándar de seguridad, pero todo era interno y nunca se veía externamente”, explicó. “Dado que la aplicación de IAGen se ve externamente, se necesita un flujo de trabajo de DataOps riguroso en cuanto a privacidad y seguridad”.

Para solucionar esto, los ingenieros de integraron las secuencias de datos de IAGen en la infraestructura principal de seguridad informática de la empresa para funciones como el control de acceso basado en roles y la autenticación. La creación de la secuencia de datos de IAGen también presentó desafíos de escalabilidad, ya que Druva debe soportar 6.000 canales lógicamente separados –uno para cada cliente– dentro de este flujo de datos en constante evolución.

«DataOps y DevOps están separados… pero hay superposiciones. No es que no puedan aprender el uno del otro», dijo Manley. «Así que lo que aprendimos en DevOps es a contenerizarlo todo, a hacerlo prácticamente efímero. Lo vimos de la misma manera en nuestro flujo de datos, así que no estoy implementando infraestructura persistente, porque eso nos arruinaría si intentáramos hacerlo para 6.000 clientes».

Manley predijo que la profundización de las relaciones entre DevOps y DataOps continuará, ya que los datos generados por IA de los LLM de la empresa podrían reincorporarse a los sistemas de análisis y aprendizaje automático para probar los flujos de trabajo de datos. Los flujos de trabajo y los flujos de trabajo de IAGen también se volverán más complejos a medida que Dru actúe sobre los sistemas de los clientes en lugar de generar recomendaciones pasivas.

La orquestación del flujo de trabajo ayuda a las plataformas DataOps

Druva desarrolló sus propias secuencias de datos de aprendizaje automático hace años, basados en el almacenamiento de Amazon S3 y el formato de tabla Apache Iceberg, así como en código desarrollado internamente para la conversión de datos. Hasta ahora, la necesidad de la empresa de un control de versiones preciso de los datos y controles de calidad personalizados le ha impedido utilizar un producto comercial, afirmó Manley.

Para otras organizaciones, las herramientas de orquestación comerciales y de código abierto han resultado vitales para los ingenieros de plataformas que dan soporte a DataOps. Por ejemplo, el proyecto de flujo de trabajo como código de código abierto Apache Airflow utiliza un grafo acíclico dirigido (DAG) para construir sistemas sofisticados que organizan tareas y sus dependencias. Puede utilizarse como herramienta de flujo de datos, que se centra en cómo se mueven los datos a través de un sistema distribuido, incluyendo los prompts de IAGen. O puede funcionar como herramienta de flujo de trabajo, que se centra en cómo un objeto de datos específico progresa a través de una serie de cambios.

La orquestación del flujo de trabajo es la principal forma en que Black Crow AI, creador de una aplicación de análisis basada en IA para empresas de comercio electrónico, utiliza Airflow. Black Crow cuenta con un equipo de plataforma específico para DataOps que supervisa el desarrollo y la implementación de secuencias de datos para aprendizaje automático, IA predictiva e IA generativa. Airflow ayuda al equipo de la plataforma de datos a actuar como ingenieros de confiabilidad del sitio al automatizar partes del proceso de resolución de problemas de los canales de datos, según Will Norman, ingeniero sénior de Black Crow AI.

«[Se encarga de] la orquestación [del flujo de trabajo], pero también de las alertas. Si algo falla, se activa una alerta de PagerDuty para que quien esté de guardia pueda investigar el problema con el trabajo», explicó. «O si estos problemas se prolongan más de lo previsto, [se] activan alertas de acuerdo de nivel de servicio (SLA) para que podamos obtener información y empezar a investigar el motivo».

Hasta ahora, el mayor cambio impulsado por IAGen ha sido la importancia de la supervisión humana al trabajar con LLM, dijo Norman.

«Se pueden crear herramientas para generar código o contenido con IAGen, pero contar con alguien que las revise antes de su lanzamiento es sumamente útil», afirmó. «Desarrollar criterios de evaluación también es muy útil, y estos son aspectos que se podrían coordinar con Airflow [para garantizar] que se cumplan los criterios de evaluación».

Aquí, Black Crow puede tomar prestadas herramientas similares a las que el equipo de la plataforma de datos desarrolló para evaluar modelos de ML. «Tenemos trabajos que se ejecutan constantemente para verificar el rendimiento de nuestros modelos», dijo Norman. «Parte de nuestro reentrenamiento de modelos, que se ejecuta a diario, simplemente analiza el rendimiento del modelo y pregunta: ‘¿Ha habido degradación? ¿Necesitamos reentrenar estos modelos? ¿Hay algo que alguien deba revisar?'».

Como usuario frecuente de los servicios de AWS, el equipo de la plataforma de datos adoptó Amazon Managed Workflows para Apache Airflow (MWAA) en cuanto estuvo disponible, en 2020, para eliminar la carga de trabajo de administrar sus propios servidores. 

Cuando su negocio y el entorno de Airflow crecieron, Black Crow recurrió a un servicio gestionado especializado de Astronomer que gestionaba mejor el escalado incremental y admitía las reversiones de actualizaciones, lo que había consumido mucho tiempo al equipo de la plataforma de datos que usaba MWAA.

La suite Astro de Astronomer admite la implementación automatizada de Airflow en contenedores, incluidas implementaciones efímeras para trabajos de prueba, junto con la integración directa en herramientas CI/CD que Norman dijo que planea evaluar para uso futuro.

Las herramientas DataOps se adaptan a la era de IAGen

Los equipos de plataforma han incorporado otras herramientas de automatización para dar soporte a las aplicaciones de IA, incluyendo marcos de orquestación de microservicios y utilidades de coreografía de microservicios. 

Prefect, competidor de Apache Airflow y los proveedores de servicios gestionados asociados, promociona la orquestación de flujos de trabajo sin necesidad de un DAG. En junio, Prefect lanzó ControlFlow, un marco de Python de código abierto para flujos de trabajo de IA, anticipándose a la orquestación más compleja que exigirá la IA con agentes.

«Hemos descubierto que una de las maneras en que las personas pueden obtener resultados de mayor calidad es siendo muy estructurados y enseñando a la IA cómo es realmente un flujo de trabajo; dándole objetivos específicos que cumplir, de los cuales no podrá desviarse [hasta] que [lo haga correctamente]», declaró Jeremiah Lowin, fundador y director ejecutivo de Prefect, en una entrevista con Informa TechTarget Editorial en 2024. 

«Hemos utilizado nuestra experiencia en flujos de trabajo para desarrollar un producto que controla agentes [de IA] y permite que las personas confíen en [que pueden] activar uno sin que salga corriendo a gritarle a los clientes, porque tiene un control muy estricto», señaló.

Flatiron Health, cliente de Prefect, aún no ha aplicado ControlFlow a los flujos de trabajo de IA de agentes, pero aún es pronto para ambas cosas, según Will Shapiro, jefe de IA y vicepresidente de ciencia de datos en la empresa de investigación biotecnológica.

«Estamos utilizando el diseño agéntico para trabajar en la creación de documentos científicos, y no es algo que necesitemos hacer ni siquiera semanalmente. El volumen no nos ha obligado a pensar en una orquestación más robusta en los sistemas de producción [aún]», dijo Shapiro durante una entrevista en 2024. «[Pero] podríamos empezar a utilizar enfoques agénticos en situaciones de mayor volumen que requieran una planificación más profunda de la orquestación».

Flatiron Health, que recopila y analiza datos de pacientes con cáncer que los investigadores pueden utilizar para mejorar los resultados oncológicos, logró multiplicar por diez sus conjuntos de datos mediante aprendizaje automático. Shapiro expresó su esperanza de que los LLM y la IA agéntica amplíen aún más el proceso de interpretación de historiales médicos electrónicos, que actualmente realizan humanos en Flatiron.

«Históricamente, hemos contratado a analistas humanos para que revisen y procesen manualmente los datos del gráfico, y hemos desarrollado políticas y procedimientos detallados sobre cómo extraer cada tipo de variable», explicó. «Hemos estado experimentando con la introducción de ese conjunto de instrucciones en un LLM y, luego, [con un modelo] para procesar las instrucciones y extraer los datos, y luego con otro para analizar los datos extraídos, identificar errores y, posteriormente, realizar un refinamiento rápido iterativo utilizando múltiples agentes».

Mientras tanto, Prefect puso orden en las prácticas MLOps de Flatiron al reemplazar un sistema de extracción, transformación y carga (ETL) desarrollado internamente, dijo Shapiro.

«El sistema ETL desarrollado internamente era bastante opaco y muy complejo desde el punto de vista de la integración, la interpretabilidad y la observación», afirmó. «Prefect ha sido excelente en la creación de observabilidad, reproducibilidad y estandarización del procesamiento de datos en general».

Desde entonces, Shapiro dejó Flatiron para irse a otra empresa, pero un portavoz de Flatiron dijo que no había habido ningún cambio significativo en el uso de Prefect e IA agéntica por parte de la empresa hasta fines de octubre de 2024.

(computerweekly.com)

Les estaremos informando con mucho más detalle, en el marco del informe especial: “Soluciones y productos de infraestructura para edificios y ciudades inteligentes (Sistemas BIM y BMS), POL (Passive Optical LAN). Seguridad integrada, video vigilancia y control de acceso. Casos de uso y aplicabilidad de cada solución y producto, incluyendo la colaboración digital (relacionado a realidad virtual sistema BIM) (Gemelos digitales). Buenas prácticas ambientales.», que estamos preparando para nuestra edición 216 y publicaremos en el mes de julio.

Mantente conectado a nuestra revista Channel News Perú, haciendo clic aquí y suscribiéndote a nuestro newsletter para contenido de valor diario.