Introducción y contexto
un equipo de IA bien financiado hace una demostración de su asistente financiero de múltiples agentes ante el comité ejecutivo. El sistema era impresionante: enrutaba consultas de forma inteligente, extraía documentos relevantes y generaba respuestas articuladas. Las cabezas asintieron. Se aprobaron los presupuestos. Entonces alguien preguntó: "¿Cómo sabemos que está listo para la producción?" La habitación quedó en silencio.
Esta escena se desarrolla con frecuencia en toda la industria. Nos hemos vuelto notablemente buenos en la construcción de sistemas de agentes sofisticados, pero no hemos desarrollado el mismo rigor para demostrar que funcionan. Cuando pregunto a los equipos cómo validan a sus agentes antes de la implementación, normalmente escucho una combinación de "lo probamos manualmente", "la demostración salió bien" y "lo monitorearemos en producción". Ninguno de estos está mal, pero ninguno constituye una puerta de calidad que la gobernanza pueda aprobar o que la ingeniería pueda automatizar.
El problema: evaluación de sistemas multiagente no deterministas
El desafío no es que a los equipos no les importe la calidad: a ellos les importa. El desafío es que evaluar sistemas basados en LLM es realmente difícil y las arquitecturas multiagente lo hacen más difícil.
Las pruebas de software tradicionales suponen determinismo. Dada la entrada X, esperamos la salida Y y escribimos una afirmación para validar. Pero si le hacemos a un LLM la misma pregunta dos veces obtendremos diferentes frases, diferentes estructuras y, a veces, diferentes énfasis. Ambas respuestas podrían ser correctas. O uno podría estar sutilmente equivocado en formas que no son obvias sin experiencia en el campo. El modelo mental basado en afirmaciones se derrumba.
Ahora multiplique esta complejidad en un sistema multiagente. Un agente enrutador decide qué especialista maneja la consulta. Ese especialista podría recuperar documentos de una base de conocimientos. El contexto recuperado da forma a la respuesta generada. Una falla en cualquier parte de esta cadena degrada el resultado, pero diagnosticar dónde salió mal requiere evaluar cada componente.
He observado que los equipos necesitan respuestas a tres preguntas distintas antes de poder implementar con confianza:
¿El enrutador está haciendo su trabajo? Cuando un usuario hace una pregunta sencilla, ¿recurre al agente rápido y económico? Cuando preguntan algo complejo, ¿se dirige al agente con capacidades más profundas? Hacer esto mal tiene consecuencias reales: o está perdiendo dinero y tiempo en respuestas excesivamente diseñadas o está dando a los usuarios respuestas superficiales a preguntas que merecen profundidad. ¿Las respuestas son realmente buenas? Esto suena obvio, pero lo “bueno” tiene múltiples dimensiones. ¿La información es precisa? Si el agente está haciendo un análisis, ¿es sólido el razonamiento? Si está generando un informe, ¿está completo? Los diferentes tipos de consultas necesitan diferentes criterios de calidad. Para los agentes que utilizan la recuperación, ¿está funcionando el canal RAG? ¿Hemos obtenido los documentos correctos? ¿El agente realmente los usó o alucinó información que suena plausible pero que no está basada en el contexto recuperado?
Fuera de línea versus en línea: una breve distinción
Antes de profundizar en el marco, quiero aclarar lo que quiero decir con “evaluación fuera de línea” porque la terminología puede resultar confusa.
La evaluación fuera de línea se realiza antes de la implementación, en comparación con un conjunto de datos curado donde se conocen los resultados esperados. Estás realizando pruebas en un entorno controlado sin impacto para el usuario. Esta es su puerta de calidad: el punto de control que determina si una versión del modelo está lista para la producción.
La evaluación en línea se realiza después de la implementación, frente al tráfico en vivo. Está monitoreando las interacciones reales de los usuarios, tomando muestras de las respuestas para controles de calidad y detectando desviaciones. Ésta es su red de seguridad: la garantía continua de que el comportamiento de producción coincide con las expectativas.
Ambos importan, pero tienen propósitos diferentes. Este artículo se centra en la evaluación fuera de línea porque ahí es donde veo la mayor brecha en la práctica actual. Los equipos a menudo saltan directamente a "lo monitorearemos en producción" sin establecer de antemano qué significa "bueno". Eso es al revés. Necesita una evaluación fuera de línea para definir su línea base de calidad antes de que la evaluación en línea pueda indicarle si la está manteniendo.
Hoja de ruta del artículo
Aquí presento un marco que he desarrollado y perfeccionado en múltiples implementaciones de agentes. Analizaré una arquitectura de referencia que ilustra los desafíos de evaluación comunes y luego presentaré lo que llamo los tres pilares de la evaluación fuera de línea: enrutamiento, LLM como juez y evaluación RAG. Para cada pilar, explicaré no sólo qué medir sino también por qué es importante y cómo interpretar los resultados. Finalmente, cubriré cómo poner en funcionamiento la automatización (CI/CD) y conectarla con los requisitos de gobernanza.
El sistema bajo evaluación
Arquitectura de referencia
Para concretar esto, tomaré un ejemplo que se está volviendo más común en el entorno actual. Una empresa de servicios financieros está modernizando sus herramientas y servicios apoyando a sus asesores que atienden a sus clientes finales. Una de las aplicaciones es un asistente de investigación financiera con capacidades para buscar instrumentos financieros, realizar diversos análisis y realizar investigaciones detalladas.
Está diseñado como un sistema de múltiples agentes con diferentes agentes que utilizan diferentes modelos según la necesidad y la complejidad de la tarea. El agente enrutador se sienta al frente, clasifica las consultas entrantes por complejidad y las dirige adecuadamente. Bien hecho, esto optimiza tanto el costo como la experiencia del usuario. Si se hace mal, crea frustrantes desajustes: los usuarios esperan respuestas simples u obtienen respuestas superficiales a preguntas complejas.
Desafíos de la evaluación
Esta arquitectura es elegante en teoría, pero crea desafíos de evaluación en la práctica. Diferentes agentes necesitan diferentes criterios de evaluación, y esto no siempre es obvio desde el principio.
El agente simple debe ser rápido y preciso en cuanto a los hechos, pero nadie espera que proporcione un razonamiento profundo. El agente de análisis necesita demostrar una lógica sólida, no sólo hechos precisos. El agente de investigación debe ser exhaustivo: pasar por alto un factor de riesgo importante en un análisis de inversión es un fracaso incluso si todo lo demás es correcto. Luego está la dimensión RAG. Para los agentes que recuperan documentos, tienen un conjunto de preguntas completamente separado. ¿Recuperamos los documentos correctos? ¿El agente realmente los usó? ¿O ignoró el contexto recuperado y generó algo que suena plausible pero infundado?
La evaluación de este sistema requiere evaluar múltiples componentes con diferentes criterios. Veamos cómo abordamos esto.
Tres pilares de la evaluación fuera de línea
Descripción general del marco
Durante los últimos dos años, trabajando en varias implementaciones de agentes, he convergido en un marco con tres pilares de evaluación. Cada uno aborda un modo de falla distinto y juntos brindan una cobertura razonable de lo que puede salir mal.
Los pilares no son independientes. El enrutamiento afecta qué agente maneja la consulta, lo que afecta si RAG está involucrado y qué criterios de evaluación se aplican. Pero separarlos analíticamente le ayuda a diagnosticar dónde se originan los problemas en lugar de simplemente observar que algo salió mal.
Un principio importante: no todas las evaluaciones se ejecutan en todas las consultas. Realizar una evaluación RAG integral a partir de una simple búsqueda de precios es un desperdicio: no hay ningún RAG que evaluar. Al realizar únicamente comprobaciones de exactitud fáctica en un informe de investigación complejo no se detecta si el razonamiento fue sólido o si la cobertura fue completa.
Pilar 1: Evaluación de enrutamiento
La evaluación de enrutamiento responde a lo que parece una pregunta simple: ¿el enrutador eligió al agente correcto? En la práctica, hacer esto bien es más complicado de lo que parece, y hacerlo mal tiene consecuencias en cascada.
Pienso en los errores de enrutamiento en dos categorías. El enrutamiento insuficiente ocurre cuando una consulta compleja llega a un agente simple. El usuario solicita un análisis comparativo y obtiene una respuesta superficial que no aborda los matices de su pregunta. Están frustrados, y con razón: el sistema tenía la capacidad de ayudarlos, pero no la implementó.
El enrutamiento excesivo es lo contrario: consultas simples dirigidas a agentes complejos. El usuario solicita el precio de las acciones y espera quince segundos mientras el agente de investigación gira, recupera documentos que no necesita y genera una respuesta elaborada a una pregunta que merecía tres palabras. La respuesta probablemente sea buena, pero ha desperdiciado computación, dinero y tiempo del usuario.
En una interacción, descubrimos que el enrutador estaba sobreenrutando alrededor del 40% de las consultas simples. Las respuestas fueron buenas, por lo que nadie se había quejado, pero el sistema gastaba cinco veces más de lo que debería en esas consultas. Arreglar la lógica de clasificación del enrutador redujo significativamente los costos sin ninguna degradación en la calidad percibida por el usuario.
Para la evaluación, utilizo dos enfoques según la situación. Evaluación determinista: cree un conjunto de datos de prueba donde cada consulta esté etiquetada con el agente esperado, mida qué porcentaje el enrutador acierta. Esto es rápido, económico y proporciona un número de precisión claro.
Evaluación basada en LLM: agrega matices para casos ambiguos. Algunas consultas realmente podrían ir en cualquier dirección: "Háblame sobre el negocio de Microsoft" podría ser una simple descripción general o un análisis profundo dependiendo de lo que el usuario realmente quiera. Cuando la elección del enrutador difiere de su etiqueta, un juez de LLM puede evaluar si la elección fue razonable incluso si no era lo que esperaba. Esto es más costoso pero le ayuda a distinguir los errores verdaderos de las decisiones tomadas con criterio.
Las métricas que sigo incluyen la precisión general del enrutamiento, que es el número del titular, pero también una matriz de confusión que muestra qué agentes se confunden con quién. Si el enrutador envía constantemente consultas de análisis al agente de investigación, ese es un problema de calibración específico que puede abordar. También hago un seguimiento de las tasas de enrutamiento excesivo y insuficiente por separado porque tienen diferentes impactos comerciales y diferentes soluciones.
Pilar 2: Evaluación de LLM como juez
El desafío de evaluar los resultados de un LLM es que no son deterministas, por lo que no pueden compararse con una respuesta esperada. Las respuestas válidas varían en redacción, estructura y énfasis. Necesita una evaluación que comprenda la equivalencia semántica, evalúe la calidad del razonamiento y detecte errores fácticos sutiles. La evaluación humana lo hace bien pero no escala. No es factible que alguien revise manualmente miles de casos de prueba en cada implementación.
LLM-as-juez aborda esto mediante el uso de un modelo de lenguaje capaz de evaluar los resultados de otros modelos. Usted le proporciona al juez la consulta, la respuesta, sus criterios de evaluación y cualquier verdad fundamental que tenga, y le devuelve una evaluación estructurada. El enfoque ha sido validado en investigaciones que muestran una fuerte correlación con los juicios humanos cuando los criterios de evaluación están bien especificados.
Algunas notas prácticas antes de sumergirnos en las dimensiones. Su modelo de juez debe ser al menos tan capaz como los modelos que está evaluando; normalmente uso Claude Sonnet o GPT-4 para juzgar. Usar un modelo más débil como juez conduce a evaluaciones poco confiables. Además, las indicaciones de los jueces deben ser específicas y estructuradas. Instrucciones vagas como "calificar la calidad" producen resultados inconsistentes. Las rúbricas detalladas con criterios de puntuación claros producen evaluaciones utilizables.
Evalúo tres dimensiones, aplicadas selectivamente en función de la complejidad de la consulta.
La precisión fáctica es fundamental. El juez extrae afirmaciones fácticas de la respuesta y verifica cada una de ellas con la verdad fundamental. Para una consulta financiera, esto podría significar verificar que la relación P/E citada sea correcta, que la cifra de ingresos sea precisa y que la tasa de crecimiento coincida con la realidad. El resultado es una puntuación de precisión más un desglose de qué hechos fueron correctos, incorrectos o faltantes.
Esto se aplica a todas las consultas independientemente de su complejidad. Incluso las búsquedas simples necesitan verificación de hechos; posiblemente las búsquedas especialmente simples, ya que los usuarios confían en respuestas objetivas directas y los errores socavan esa confianza.
La calidad del razonamiento es importante para las respuestas analíticas. Cuando el agente compara opciones de inversión o evalúa riesgos, es necesario evaluar no sólo si los hechos son correctos sino también si la lógica es sólida. ¿La conclusión se deriva de las premisas? ¿Las afirmaciones están respaldadas por evidencia? ¿Se hacen explícitos los supuestos? ¿La respuesta reconoce adecuadamente la incertidumbre?
Solo realizo evaluaciones de razonamiento en consultas de complejidad media y alta. Las búsquedas simples de hechos no implican razonamiento: no hay nada que evaluar. Pero para cualquier cosa analítica, la calidad del razonamiento suele ser más importante que la exactitud de los hechos. Una respuesta puede citar números correctos pero sacar conclusiones inválidas de ellos, y eso es un grave fracaso.
La integridad se aplica a resultados integrales como informes de investigación. Cuando un usuario solicita un análisis de inversión, espera cubrir ciertos elementos: desempeño financiero, posición competitiva, factores de riesgo, catalizadores de crecimiento. Omitir un elemento importante es un fracaso incluso si todo lo incluido es preciso y está bien razonado.
Realizo evaluaciones de integridad solo en consultas de alta complejidad donde se espera una cobertura completa. Para consultas más simples, la integridad no es significativa; no se espera que una búsqueda del precio de las acciones cubra los factores de riesgo.
La estructura del aviso del juez importa más de lo que la gente cree. Siempre incluyo la consulta original (para que el juez comprenda el contexto), la respuesta que se evalúa, la verdad fundamental o los criterios de evaluación, una rúbrica específica que explica cómo calificar cada dimensión y un formato de salida requerido (uso JSON para la analizabilidad). Invertir tiempo en una ingeniería rápida para sus jueces vale la pena en términos de confiabilidad de la evaluación.
Pilar 3: Evaluación del RAG
La evaluación RAG aborda un modo de falla que es invisible si solo se observan los resultados finales: el sistema que genera respuestas que suenan plausibles y que en realidad no se basan en el conocimiento recuperado.
El oleoducto RAG tiene dos etapas y cualquiera de ellas puede fallar. La falla de recuperación significa que el sistema no extrajo los documentos correctos: recuperó contenido irrelevante o omitió documentos que eran relevantes. Una falla de generación significa que el sistema recuperó buenos documentos pero no los usó adecuadamente, ya sea ignorándolos por completo o alucinando información que no está presente en el contexto.
La evaluación de respuesta estándar combina estos fallos. Si la respuesta final es incorrecta, no se sabe si la recuperación falló o la generación falló. La evaluación específica de RAG separa las inquietudes para que usted pueda diagnosticar y solucionar el problema real.
Utilizo el marco RAGAS (Evaluación de generación aumentada de recuperación) para esto, que proporciona métricas estandarizadas que se han convertido en estándar de la industria. Las métricas se dividen en dos grupos.
Las métricas de calidad de recuperación evalúan si se recuperaron los documentos correctos. La precisión del contexto mide qué fracción de los documentos recuperados fueron realmente relevantes; si recuperó cuatro documentos y solo dos fueron útiles, eso es una precisión del 50%. Estás haciendo ruido. La recuperación del contexto mide qué fracción de documentos relevantes se recuperaron; si tres documentos eran relevantes y solo obtuvo dos, eso es un 67% de recuperación. Te falta información.
Las métricas de calidad de la generación evalúan si el contexto recuperado se utilizó correctamente. La fidelidad es fundamental: mide si las afirmaciones de la respuesta están respaldadas por el contexto recuperado. Si la respuesta hace cinco afirmaciones y cuatro se basan en los documentos recuperados, eso es 80% de fidelidad. La quinta afirmación proviene del conocimiento paramétrico del modelo o es una alucinación; de cualquier manera, no se basa en su recuperación, lo cual es un problema si confía en RAG para su precisión.
Quiero enfatizar la fidelidad porque es la métrica más directamente relacionada con el riesgo de alucinaciones en los sistemas RAG. Una respuesta puede parecer autoritaria y ser completamente inventada. La evaluación de fidelidad detecta esto al verificar si cada reclamo se remonta al contenido recuperado.
En un proyecto, descubrimos que las puntuaciones de fidelidad variaban drásticamente según el tipo de consulta. Para consultas fácticas sencillas, la fidelidad fue superior al 90%. Para consultas analíticas complejas, se redujo a alrededor del 60%: el modelo estaba haciendo más "razonamiento" que iba más allá del contexto recuperado. Eso no es necesariamente incorrecto, pero significaba que los usuarios no podían confiar en que las conclusiones analíticas estuvieran basadas en los documentos originales. Terminamos ajustando las indicaciones para restringir más explícitamente el modelo a la información recuperada para ciertos tipos de consultas.
Implementación e integración
Arquitectura de tuberías
El proceso de evaluación tiene cuatro etapas: cargar el conjunto de datos, ejecutar el agente en cada muestra, ejecutar las evaluaciones apropiadas y agregarlos en un informe.
Comenzamos con el conjunto de datos de muestra que se va a evaluar. Cada muestra necesita la consulta en sí, metadatos que indiquen el nivel de complejidad y el agente esperado, hechos reales para la evaluación de la precisión y, para consultas RAG, los documentos relevantes que deben recuperarse. Construir este conjunto de datos es un trabajo tedioso, pero la calidad de su evaluación depende completamente de la calidad de su base de datos. Vea el ejemplo a continuación (código Python):
{ "id": "eval_001", "query": "Compare las relaciones P/E de Microsoft y Google", "category": "comparison", "complexity": "medium", "expected_agent": "analysis_agent", "ground_truth_facts": [ "El P/E de Microsoft es aproximadamente 35", "El P/E de Google es aproximadamente 25" ], "ground_truth_answer": "Microsoft cotiza a precios más altos P/E (~35) que Google (~25)…", "relevant_documents": ["MSFT_10K_2024", "GOOGL_10K_2024"] }
Recomiendo comenzar con al menos 50 muestras por nivel de complejidad, es decir, 150 como mínimo para un sistema de tres niveles. Más es mejor: 400 en total le brinda una mayor confianza estadística en las métricas. Estratifique las categorías de consulta para no sobreindexar accidentalmente un tipo.
Para la observabilidad, utilizo Langfuse, que proporciona almacenamiento de seguimiento, archivos adjuntos de puntuación y seguimiento de ejecución de conjuntos de datos. Cada muestra de evaluación crea un seguimiento y cada métrica de evaluación se adjunta como puntuación a ese seguimiento. Con el tiempo, crea un historial de ejecuciones de evaluación que puede comparar entre versiones de modelos, cambios de solicitudes o modificaciones de arquitectura. La capacidad de profundizar en fallas específicas y ver el seguimiento completo es muy útil para solucionar problemas.
Puertas de calidad automatizadas (CI/CD)
La evaluación se vuelve muy poderosa cuando está automatizada y bloqueada. La ejecución programada de la evaluación en un subconjunto de datos representativo es un buen comienzo. La ejecución produce métricas. Si las métricas caen por debajo de los umbrales definidos, el mecanismo de gobernanza posterior se activa ya sea que se realicen revisiones de calidad, controles de entrada fallidos, etc.
Los umbrales deben calibrarse según su caso de uso y tolerancia al riesgo. Para una aplicación financiera donde la precisión es fundamental, podría establecer la precisión objetiva en 90% y la fidelidad en 85%. Para una herramienta de productividad interna con riesgos menores, el 80% y el 75% podrían ser aceptables. La clave es alinear los umbrales con los equipos de gobernanza y calidad y aplicarlos de manera estándar y repetible.
También recomiendo la ejecución programada de la evaluación con el conjunto de datos completo, no solo con el subconjunto utilizado para las comprobaciones de relaciones públicas. Esto detecta la deriva en las dependencias externas (cambios de API, actualizaciones de modelos, modificaciones de la base de conocimientos) que podrían no aparecer en el conjunto de datos de relaciones públicas más pequeño.
Cuando la evaluación falla, la canalización debe generar un informe de falla que identifique qué métricas no alcanzaron el umbral y qué muestras específicas fallaron. Esto proporciona las señales necesarias a los equipos para resolver las fallas.
Gobernanza y cumplimiento
Para implementaciones empresariales, la evaluación abarca la calidad de la ingeniería y la responsabilidad organizacional. Los equipos de gobernanza necesitan evidencia de que los sistemas de IA cumplen con estándares definidos. Los equipos de cumplimiento necesitan pistas de auditoría. Los equipos de riesgo necesitan visibilidad de los modos de falla.
La evaluación fuera de línea proporciona esta evidencia. Cada ejecución crea un registro: qué versión del modelo se evaluó, qué conjunto de datos se utilizó, qué puntuaciones se alcanzaron y si se cumplieron los umbrales. Estos registros se acumulan en una pista de auditoría que demuestra un control de calidad sistemático a lo largo del tiempo.
Recomiendo definir los criterios de aceptación en colaboración con las partes interesadas en la gobernanza antes de la primera ejecución de la evaluación. ¿Qué umbral de precisión fáctica es aceptable para su caso de uso? ¿Qué nivel de fidelidad se requiere? Lograr la alineación desde el principio evita confusión y conflictos al interpretar los resultados.
Los criterios deben reflejar el riesgo real. Un sistema que proporciona información médica necesita umbrales de precisión más altos que uno que resume las notas de las reuniones. Un sistema que hace recomendaciones financieras necesita umbrales de fidelidad más altos que una copia de marketing. No hay una solución única que sirva para todos, y los equipos de gobierno lo entienden cuando lo plantean en términos de riesgo.
Finalmente, piense en informar para diferentes audiencias. Ingeniería quiere desgloses detallados por métrica y tipo de consulta. La gobernanza quiere un resumen del estado de aprobación/rechazo con líneas de tendencia. Los ejecutivos quieren un panel que muestre el estado verde/amarillo/rojo en todos los sistemas. Langfuse y herramientas similares admiten estas diferentes vistas, pero es necesario configurarlas intencionalmente.
Conclusión
La brecha entre demostraciones impresionantes y sistemas listos para producción se salva mediante una evaluación rigurosa y sistemática. El marco presentado aquí proporciona la estructura para crear una gobernanza adaptada a sus agentes, casos de uso y tolerancia al riesgo específicos.
Conclusiones clave
Requisitos de evaluación: los requisitos varían según el caso de uso de la aplicación. Una búsqueda simple necesita verificaciones de precisión objetiva. Un análisis complejo necesita una evaluación del razonamiento. Una respuesta habilitada por RAG necesita verificación de fidelidad. Aplicar las evaluaciones correctas a las consultas correctas le brinda una señal sin ruido. Automatización: la evaluación manual no escala y no detecta regresiones. La integración de la evaluación en los procesos de CI/CD, con umbrales explícitos que bloquean la implementación, convierte el aseguramiento de la calidad de una acción ad hoc en una práctica repetible. Gobernanza: los registros de evaluación proporcionan la pista de auditoría que el cumplimiento necesita y la evidencia que el liderazgo necesita para aprobar la implementación de producción. Establecer esta conexión tempranamente hace que la gobernanza de la IA sea una asociación y no un obstáculo.
Por dónde empezar
Si no estás realizando una evaluación sistemática fuera de línea hoy, no intentes implementar todo a la vez.
Comience con la precisión del enrutamiento y la precisión objetiva: estas son las métricas de señal más alta y las más fáciles de implementar. Cree un pequeño conjunto de datos de evaluación, tal vez entre 50 y 100 muestras. Ejecútelo manualmente varias veces para calibrar sus expectativas. Agregue evaluación de razonamiento para consultas complejas y métricas RAG para agentes habilitados para recuperación. Integre en CI/CD. Defina umbrales con sus socios de gobierno. Construir, probar, iterar.
El objetivo es comenzar a sentar las bases y construir procesos para proporcionar evidencia de calidad a través de criterios definidos. Esa es la base para la preparación de la producción, la confianza de las partes interesadas y la implementación responsable de la IA.
Este artículo resultó ser largo, muchas gracias por permanecer hasta el final. Espero que te haya resultado útil y que pruebes estos conceptos. Todo lo mejor y feliz edificio 🙂