Evaluación de agentes de IA: cómo Elastic pasó del caos de tests aislados a un framework único tras casi dos años en producción

Cuando tienes un solo agente de IA en producción, probarlo a mano parece suficiente. Cuando tienes cinco equipos construyendo agentes distintos, cada uno con sus propios datasets, métricas y herramientas, la evaluación de agentes de IA se convierte en un problema de ingeniería por derecho propio. Es lo que le pasó a Elastic, la empresa detrás de Elasticsearch y Kibana, y lo que Susan Chang, Principal Data Scientist de la compañía, contó en QCon AI: cómo migraron de evaluaciones artesanales y aisladas a un framework de evaluación reutilizable para todos sus productos de IA generativa.

Elastic lleva casi dos años con un sistema de agentes orientado al usuario en producción. Entre ellos hay Attack Discovery, un agente de ciberseguridad que revisa logs para encontrar posibles ataques en lugar de que lo haga un analista a mano. Chang citó a un gran banco cliente que ingiere petabytes de datos en Elastic para este caso de uso. También hay un agente para chatbots empresariales que responde con datos propietarios de cada cliente. Antes del framework común, cada equipo creaba sus datasets, escribía sus evaluadores, guardaba las trazas en un sitio distinto y ejecutaba las pruebas en otro. El equipo de seguridad trabajaba con analistas e investigadores para crear escenarios de ataque novedosos, y también guardaba escenarios benignos. Medía precisión y recall sobre IDs de alertas, similitud, factualidad y que el modelo no inventara tácticas del marco MITRE. El equipo del chatbot medía otra cosa: relevancia y completitud de la respuesta, y que el agente generara sintaxis correcta de ES|QL, el lenguaje de consultas de Elastic.

La respuesta fue un marco compartido. Según las diapositivas de la charla, la lógica es simple. A medida que madura el desarrollo de agentes se necesitan más evaluaciones, y construirlas desde cero cada vez es costoso. Con una base común, los equipos colaboran y mantienen el sistema juntos, y se puede levantar una evaluación completa en poco tiempo. El diseño combina LLM como juez con reglas deterministas, une las pruebas de ciencia de datos en Python con el código de producción en TypeScript, y se apoya en trazabilidad profunda (tracing) para detectar regresiones en flujos RAG y de ciberseguridad sin perder el contexto de cada dominio.

Hay un matiz importante. Ni la charla ni los resúmenes disponibles publican métricas de impacto, como reducción de costos, tiempos de desarrollo o mejora de calidad. Un análisis automatizado de la cobertura también señala la ausencia de benchmarks y de ejemplos concretos de cómo se equilibra el juez LLM con las reglas. Conviene tomarlo como un patrón de ingeniería probado en producción, no como un caso con ROI cuantificado.

Qué puedes aplicar en tu estrategia de evaluación de agentes de IA

La lección central es que evaluar IA no es lo mismo que hacer unit tests. Un agente puede responder distinto ante la misma entrada, y una regresión puede estar en la recuperación de documentos, en el prompt o en una herramienta que el agente invoca. Por eso Chang insiste en que lo primero es la trazabilidad: sin tracing y monitoreo no sabes qué falló ni dónde. Su recomendación para quien aún no lo ha hecho es implementarlo en el flujo de IA en producción y crear o revisar los datasets de evaluación.

Puedes traducir el caso de Elastic en una hoja de ruta:

Empieza por las trazas. Registra cada paso del agente (recuperación, llamadas a herramientas, respuesta final) en un único lugar, antes de pensar en métricas sofisticadas.

Construye datasets con expertos de dominio. Elastic trabajó con analistas de seguridad para crear escenarios de ataque y también casos benignos. Sin ejemplos negativos no sabrás medir falsos positivos.

Mezcla evaluadores según el riesgo. Usa reglas deterministas para lo verificable, como sintaxis de consultas o coincidencia de IDs, y un LLM como juez para lo subjetivo, como relevancia o completitud. Las reglas son baratas y repetibles; el juez aporta matiz pero exige calibración.

Centraliza lo común y deja lo específico a cada equipo. Un núcleo compartido (carga de datasets, ejecución, puntuación y agregación) con métricas personalizables evita que cada equipo reinvente la infraestructura.

Une a ciencia de datos y producción. Si tus evaluaciones viven en Python y tu producto en otro lenguaje, planifica el puente desde el principio. De lo contrario, las pruebas se desconectan del código real.

Errores que conviene evitar

El primero es esperar a tener decenas de agentes para estandarizar. Elastic empezó con evaluaciones individuales y las unificó con el tiempo, pero cada migración tardía duplica trabajo. El segundo es copiar métricas de otro equipo sin adaptarlas: lo que importa en un agente de seguridad (no alucinar tácticas de ataque) no es lo que importa en un chatbot de documentación. El tercero es tratar la evaluación como un evento previo al lanzamiento. Las pruebas offline y el monitoreo de aplicaciones vivas son dos caras de la misma disciplina.

El mismo patrón aparece en otros casos. Quien despliega agentes de ciberseguridad autónomos como los de Exaforce necesita medir falsos positivos con rigor, y quien monta sistemas RAG para consultas regulatorias como el de Amazon depende de saber si la recuperación está degradando las respuestas. Si además te preocupa el control de riesgos, mira cómo AWS y Cisco automatizan la seguridad de agentes empresariales.

El momento de actuar

La pregunta ya no es si tu empresa necesita una evaluación de agentes de IA seria, sino cuántos agentes más puedes poner en producción antes de pagar el costo de no tenerla. Un buen primer paso: esta semana, revisa si puedes reconstruir paso a paso qué hizo tu agente ante una respuesta incorrecta. Si no puedes, ahí empieza tu framework.