Un agente de IA en producción sin monitoreo activo es un sistema que opera con un nivel de confianza que nadie puede justificar. El equipo sabe que funciona porque no ha recibido quejas. Eso no es evidencia de calidad: es ausencia de información.
Apache Airflow no construye ni gestiona agentes de IA directamente. Su rol en este contexto es orquestar los procesos periódicos que mantienen al agente funcionando de forma confiable: la actualización de la base de conocimiento, la evaluación sistemática de la calidad de los outputs, y la generación de alertas cuando algo sale del rango esperado.
Prerequisito: el registro estructurado de conversaciones
Antes de implementar cualquier DAG de monitoreo, el sistema de IA debe estar registrando conversaciones de forma estructurada. Esto significa que cada interacción —consulta del usuario, respuesta del agente, documentos recuperados del índice si es un sistema RAG, timestamp, identificador de sesión— queda almacenada en un formato que permite consulta y análisis posterior.
Si el sistema no tiene este registro, la primera tarea no es el DAG de monitoreo: es instrumentar el sistema para que lo genere. Sin datos históricos, el monitoreo no tiene base sobre la que operar.
Estructura del DAG de monitoreo
El DAG de monitoreo se ejecuta con una frecuencia definida según el volumen de conversaciones y la criticidad del sistema. Para sistemas con uso diario activo, una ejecución diaria en horario de bajo tráfico es el punto de partida habitual.
Tarea 1: Extracción de conversaciones del período
El DAG extrae del registro las interacciones del período definido que todavía no han sido evaluadas. El criterio puede ser temporal (últimas 24 horas) o basado en un marcador de estado (conversaciones con estado ‘pendiente de evaluación’). Para volúmenes altos, se puede implementar muestreo estratificado con sobremuestreo de los casos de mayor riesgo.
Tarea 2: Evaluación automatizada de calidad
Cada conversación se evalúa contra criterios de calidad definidos antes del despliegue. Hay tres estrategias con distintos niveles de cobertura y costo computacional:
Evaluación basada en reglas: verificación de condiciones explícitas sobre el output. Simple, de bajo costo computacional, cubre los fallos más obvios.
Verificación de soporte documental: para sistemas RAG, verifica que la respuesta tiene correspondencia con los documentos recuperados del índice. Si la respuesta contiene información que no aparece en los documentos recuperados, es un indicador potencial de alucinación.
Evaluación con modelo evaluador: un segundo modelo de lenguaje evalúa la calidad de la respuesta según criterios definidos en el prompt del evaluador. Mayor capacidad de detectar errores sutiles, con costo computacional adicional.
En la práctica, la combinación de evaluación basada en reglas como primer filtro y modelo evaluador para los casos que lo superan es el enfoque más eficiente para empresas medianas.
Tarea 3: Verificación de la base de conocimiento
En paralelo o como tarea secuencial, el DAG verifica el estado de la base de conocimiento: que el proceso de ingesta se ejecutó correctamente, que no hay documentos fuente con errores pendientes, y que la antigüedad máxima de los documentos en el índice está dentro del umbral definido. Una interrupción en el proceso de ingesta puede no generar errores visibles en el agente, pero sí producir respuestas basadas en información desactualizada.
Tarea 4: Cálculo de métricas y generación de alertas
El DAG agrega los resultados de las evaluaciones y calcula las métricas del período: tasa de respuestas evaluadas como correctas, tasa de conversaciones sin soporte documental, cobertura del índice, latencia promedio. Cada métrica se compara con el umbral definido. Si alguna está fuera del rango, se genera una alerta con suficiente contexto para que el receptor pueda evaluar la severidad.
Gestión de alertas y acciones de respuesta
La alerta debe llegar a alguien con criterio sobre el dominio, no solo al equipo técnico. Un problema de calidad requiere análisis de contenido para determinar la causa. Las acciones posibles son: actualizar la base de conocimiento, ajustar el prompt del agente, revisar manualmente las conversaciones del período, o suspender temporalmente el agente mientras se investiga. El DAG orquesta la notificación; la decisión sobre qué hacer es del equipo.
Herramientas complementarias de observabilidad
Para equipos que quieran complementar el DAG de Apache Airflow con herramientas de observabilidad específicas para LLM, LangSmith (para stacks basados en LangChain, con trazabilidad detallada de cada llamada) y Langfuse (open source, agnóstico de framework, auto-hospedable) son opciones que se integran con el registro estructurado de conversaciones y añaden capacidades de análisis de trazas y evaluación de calidad. En ambos casos, Apache Airflow orquesta los ciclos periódicos de evaluación; las herramientas de observabilidad cubren el análisis en tiempo real por sesión.
Punto de entrada para equipos sin monitoreo activo
Para sistemas ya en producción sin monitoreo, el primer paso es confirmar que existe registro estructurado de conversaciones. Si no existe, instrumentar el sistema para generarlo es la primera tarea.
Una vez que el registro existe, el DAG más simple que entrega valor real es la evaluación muestral diaria con alerta cuando la tasa de evaluaciones negativas supera el umbral definido. Eso convierte el monitoreo de reactivo a proactivo, y es el punto de partida desde el que se construye el sistema de observabilidad completo.
