Los equipos que desarrollan agentes de IA necesitan algo más que comprobar la respuesta final para saber si el sistema funciona como debería. En aplicaciones que combinan recuperación, generación y llamadas a herramientas, un resultado incorrecto puede deberse a la selección de una base de datos equivocada o a la recuperación de documentos inadecuados, aunque el problema parezca estar únicamente en el texto final. Durante una presentación ofrecida a través de InfoQ, Susan Chang, científica de datos principal en Elastic, explicó cómo la empresa desarrolló un marco común para evaluar sus agentes utilizados en ciberseguridad y en chatbots empresariales.
De evaluaciones aisladas a herramientas compartidas
Los equipos de Elastic comenzaron creando conjuntos de datos, evaluadores y procesos de seguimiento separados para cada agente. En el caso de un agente de detección de ataques, las pruebas incluían escenarios de ataque y escenarios normales redactados por analistas e investigadores de seguridad, con métricas como precisión y recuperación, corrección factual, similitud y clasificación de tácticas de MITRE. En cambio, los chatbots basados en datos empresariales probaban preguntas y recuperación de documentos, con énfasis en la relevancia y la completitud de la respuesta, la corrección de los identificadores de productos y la formulación de consultas ES|QL.
La diferencia entre estos casos provocó una gran duplicación del trabajo. Por ello, Elastic creó un marco común capaz de importar distintos tipos de conjuntos de datos mediante un esquema unificado, ejecutar evaluaciones basadas en trazas de ejecución y utilizar evaluadores compartidos para aplicaciones RAG, junto con componentes personalizados para cada producto. El proceso puede ejecutarse localmente, cargar los datos, ejecutar el agente, recopilar los resultados y después mostrar las puntuaciones a los desarrolladores.
La trazabilidad es necesaria para entender la causa del fallo
La experiencia confirma que el seguimiento del agente no debería limitarse a su salida final. Deben registrarse las herramientas que invocó, las búsquedas vectoriales y de texto, los datos recuperados, el consumo de tokens, el tiempo de respuesta y la secuencia de decisiones. Este nivel de detalle permite evaluar la invocación de una herramienta específica o descubrir que el agente utilizó una fuente equivocada antes de que el problema aparezca en la respuesta final.
También es posible convertir los casos fallidos reportados por los usuarios, como una evaluación negativa, en nuevos ejemplos para el conjunto de pruebas. De este modo, los comentarios de producción se convierten en pruebas de regresión para versiones posteriores, en lugar de permanecer como observaciones manuales separadas del ciclo de desarrollo.
¿Por qué no basta con LLM-as-a-judge?
Elastic utilizó modelos de lenguaje para evaluar las salidas de otros modelos en tareas abiertas o ambiguas, como el estilo, la coherencia y la adecuación de la respuesta al contexto. Este enfoque permite ampliar la evaluación cuando resulta difícil escribir una regla precisa para juzgar un texto largo. Sin embargo, puede producir resultados variables entre una ejecución y otra, y puede no detectar errores específicos, como un identificador de producto inexistente o una formulación de consulta no válida.
Por ello, Elastic combinó LLM-as-a-judge con evaluaciones deterministas basadas en reglas y programación. Estas evaluaciones comprueban la estructura de JSON o YAML, la validez de la sintaxis, la presencia de las entidades requeridas y la posibilidad de ejecutar el código o la consulta, además de métricas como precisión y recuperación y corrección factual. Esta combinación reduce el coste y acelera la evaluación en los casos que tienen una respuesta clara, y reserva el juicio semántico para las tareas difíciles de reducir a reglas.
¿Qué no se puede generalizar?
Elastic no consideró que la creación de datos de prueba especializados fuera completamente automatizable. En ciberseguridad, el equipo necesita analistas e investigadores que determinen qué constituye un ataque real y cuál es el comportamiento aceptable para el usuario final. Además, la definición de regresión varía entre agentes; por ejemplo, un agente de seguridad puede volverse más propenso a declarar que existen ataques incluso cuando se introducen datos normales después de una determinada actualización.
La calibración de los evaluadores sigue siendo responsabilidad de cada equipo. Si el evaluador lingüístico asigna puntuaciones diferentes al mismo caso o no coincide con el criterio humano objetivo, el marco común producirá cifras engañosas, independientemente de la calidad de la arquitectura de software. Chang también señaló el riesgo de sesgo del evaluador cuando se utilizan familias de modelos relacionadas para la generación y el juicio, ya que podría sobreestimar el rendimiento de esos modelos.
¿Qué cambia en la práctica para los equipos?
La experiencia de Elastic recomienda comenzar con un conjunto pequeño de ejemplos de prueba, que puede oscilar entre 20 y 50 casos, en lugar de esperar a contar con un conjunto perfecto. En las primeras etapas, el trabajo disperso puede ser aceptable para acelerar el aprendizaje, especialmente cuando los casos de uso y las métricas todavía están en fase de descubrimiento. Sin embargo, cuando varios agentes entran en producción, la trazabilidad y la evaluación básica se vuelven esenciales para responder preguntas sobre el rendimiento y diagnosticar los problemas de los usuarios.
Elastic también trasladó algunas herramientas de evaluación de Python a TypeScript para alinearlas con el código de producción escrito en TypeScript y utilizar Playwright y una herramienta interna personalizada llamada Scout. Este paso no significa que sea necesario trasladar todas las evaluaciones de ciencia de datos, sino que refleja una necesidad específica de reducir la brecha entre lo que prueba el equipo y lo que el sistema ejecuta realmente. La conclusión práctica es que el marco común puede unificar el esquema, la ejecución y las métricas generales, pero no puede sustituir la experiencia del dominio ni el criterio sobre lo que debe considerarse éxito y fracaso.