Contenido
Montaste un sistema multiagente, le diste herramientas y lo ejecutaste con el Agent SDK: entonces,¿ cómo mides si el agente realmente está haciendo su trabajo? Para una sola salida, puedes puntuarla con AI evals. Pero un agente planifica a lo largo de muchos pasos, llama a herramientas y actúa con estado. Aunque la última frase parezca correcta, puede haber cruzado un puente peligroso por el camino. Aquí es donde las agent evals toman el protagonismo.
Este artículo expone, basándose en información oficial, qué son las agent evals, en qué se diferencian de las LLM evals, qué medir (5 dimensiones), cómo puntuar (3 evaluadores), los escollos exclusivos y el flujo de trabajo práctico junto con los benchmarks. Las claves por adelantado. (1) Las agent evals miden no solo "la salida final", sino la "trajectory" de las acciones. (2) Anthropic recomienda puntuar el resultado (el estado final), no el camino: porqué comprobar los pasos de forma mecánica es frágil. (3) Empieza con un conjunto pequeño de 20-50 tareas extraídas de fallos reales y ejecuta una puntuación automatizada.
Mide tanto "la respuesta final" como "el camino recorrido"
— las evals de salida no bastan; los agentes son multipaso, usan herramientas y tienen estado
Anthropic recomienda puntuar el resultado por encima del camino: pero la trajectory te dice por qué fallo. Usa ambos, para la tarea adecuada.
1. ¿Qué son las Agent Evals?
Las agent evals son el proceso de medir sistemáticamente si un "agente" —uno que usa herramientas y da múltiples pasos para alcanzar un objetivo— puede realmente cumplir sus tareas. Son una evolución de las LLM evals, que juzgan la calidad de un solo prompt; el objetivo se amplia de "una salida" a "una secuencia de acciones".
Por qué importa: en su guía sobre agent evals, Anthropic señala que "las evals se vuelven más difíciles de construir cuanto más esperes. Al principio, los requisitos del producto se traducen de forma natural en casos de prueba", y recomienda qué "20-50 tareas sencillas extraídas de fallos reales son un gran comienzo". Dicho de otro modo, las agent evals convierten "parece que funciona" en números reproducibles. Esto va de la mano con la observabilidad de IA (observar la ejecución): los rastros qué observas se convierten en material para la evaluación.
2. Por qué se diferencian de las LLM evals (salida vs trajectory)
Las LLM evals tradicionales básicamente puntúan "entrada -> una salida". Pero un agente planifica, llama a herramientas, mira los resultados, decide el siguiente movimiento y actualiza el estado. Así que mirar solo la salida final no basta. Google también afirma que "no basta con comprobar las salidas; necesitamos entender el 'por que' detrás de las acciones de un agente", y divide la evaluación en dos familias: "respuesta final" y "trajectory". Microsoft, igualmente, dice que hay que "evaluar no solo la salida final, sino también la calidad y la eficiencia de cada paso", dividiéndola en evaluación de sistema (de extremo a extremo) y de proceso (paso a paso).
💡 La idea central: una "respuesta final correcta" puede ocultar un proceso roto. A la inversa, la respuesta puede ser correcta pero alcanzada por suerte, azar o un atajo peligroso. Por eso, para los agentes, miras tanto el "resultado" como el "proceso". Para los fundamentos de la evaluación de una sola salida y de LLM-as-judge, consulta el artículo sobre AI evals.
3. Qué medir: 5 dimensiones
Aquí tienes cinco enfoques de uso común para la evaluación de agentes.
¿Alcanzó el objetivo? Juzga por el estado final —si existe una reserva en la DB— no por la frase "lo reserve".
¿Dio pasos razonables? ¿Uso las herramientas correctas en el orden y la cantidad correctos? ¿Hubo rodeos inútiles o movimientos peligrosos?
¿Eligió la herramienta correcta y pasó los argumentos correctos? Comprueba nombres de función, tipos de argumentos y valores (y detecta llamadas innecesarias).
¿Cuantos pasos, tokens, dólares y segundos? Una respuesta correcta es poco práctica si el coste se dispara. Hay que enlazarla con métricas observadas.
¿Es la salida relevante, precisa y completa? Puntúa el contenido abierto con LLM-as-judge o una rúbrica.
Nota: la 4. eficiencia (tokens, coste, latencia) ningún proveedor la codifica formalmente como "métrica de eval"; en la práctica suele tratarse de señales de observabilidad llevadas a la evaluación. Aun así, es una dimensión esencial para detener a un agente que entra en bucle y se descontrola.
4. Cómo puntuar: 3 evaluadores y "resultado vs camino"
Hay, a grandes rasgos, tres tipos de evaluador. Siguiendo el planteamiento de Anthropic, cada uno tiene sus compensaciones.
| Evaluador | Fortalezas | Debilidades |
|---|---|---|
| Código (programático) | Rápido, barato, objetivo, reproducible | Frágil ante variaciones validas / alternativas |
| LLM-as-judge (modelo) | Flexible, escalable, capta los matices | No determinista, más caro, necesita calibración con humanos |
| Humano | Estándar de oro para la calidad | Caro, lento (evítalo si es posible) |
La jugada estándar: puntúa con código todo lo que puedas, entrega solo las partes subjetivas y abiertas a un modelo distinto como LLM-as-judge, y usa a humanos para comprobaciones puntuales en momentos clave. El diseño de LLM-as-judge (rubricas detalladas, salidas discretas, sesgo del juez) se trata a fondo en el artículo sobre LLM evals.
El "emparejamiento de trajectory" mecánico es frágil
Entonces, ¿cómo se puntúa la trajectory? Aquí Anthropic adopta una postura firme: "Hay un instinto común de comprobar que los agentes siguieron pasos muy concretos, como una secuencia de llamadas a herramientas en el orden correcto. Hemos visto que este enfoque es demasiado rígido y produce pruebas excesivamente frágiles, porque los agentes encuentran con regularidad enfoques válidos que los diseñadores de la eval no anticiparon. Para no penalizar innecesariamente la creatividad, a menudo es mejor puntuar lo que el agente produjo, no el camino que tomó." Para una reserva de vuelo, por ejemplo, mides si realmente existe una reserva en la SQL DB del entorno como estado final, no la frase "lo reserve".
Por su parte, Google y Microsoft ofrecen grados de coincidencia de trajectory (exacta / en orden / en cualquier orden, etc.) como métricas formales. Ambos enfoques no se contradicen: las evals de trajectory son buenas para diagnosticar "por qué fallo", y las evals de resultado evitan penalizar la creatividad valida. En la práctica, el término medio realista es evitar la coincidencia exacta estricta y relajarla hasta una comprobación de acciones clave: "¿se llamó a las herramientas críticas?"
5. Problemas exclusivos de las agent evals
Las agent evals conllevan dificultades que la evaluación de una sola salida no tiene.
- No determinismo (la misma entrada toma caminos distintos): un éxito no significa que se reproduzca. Necesitas métricas de fiabilidad como si tiene éxito en las k ejecuciones (pass^k). El artículo de τ-bench reporta que "los modelos se degradan considerablemente a medida que k aumenta, revelando su falta de fiabilidad" (las cifras son puntuales en el tiempo).
- Errores que se acumulan: si un solo paso tiene éxito con probabilidad p, entonces t pasos tienen éxito a aproximadamente pt. Cuanto más larga es la cadena, más rápido colapsa, y por eso el éxito cae bruscamente en tareas de horizonte largo.
- Reward hacking / specification gaming: comportamiento que satisface la letra del evaluador sin lograr el objetivo real. En el ejemplo de DeepMind, un brazo robotico se coloco entre la cámara y el objeto, enganando a los evaluadores para que creyeran que había agarrado el objeto cuándo no lo había hecho. Detectar "parece correcto pero el camino es peligroso" requiere evaluar la trajectory y los efectos secundarios.
- Conjuntos de eval que se vuelven obsoletos / contaminación: cuando un benchmark se filtra a los datos de entrenamiento (contaminación), las puntuaciones dejan de reflejar la capacidad real. Hay que seguir actualizando las regression evals a medida que el agente madura.
El problema del "camino peligroso" es continuo con las guardrails de IA. Una eval que mira solo la respuesta final pasa de largo ante estas trampas.
6. El flujo de trabajo y los benchmarks
Anclado en las recomendaciones de Anthropic, el flujo de trabajo es sencillo.
- Construye en pequeño, a partir de fallos reales: no necesitas cientos. Convierte 20-50 fallos que ocurrieron en producción en casos de prueba.
- Ejecuta puntuación automatizada: código primero, LLM-as-judge solo para las partes abiertas. Prioriza el volumen sobre la calidad puntuada a mano.
- Separa dos tipos: capability evals (¿en qué es bueno?) y regression evals (¿sigue pudiendo hacer lo que hacía?).
- Ponlo en un ciclo de vida: (1) evals automatizadas previas al lanzamiento (integradas en CI) -> (2) monitorización en producción -> (3) pruebas A/B -> (4) feedback de usuarios y revisión de rastros, en capas sucesivas.
- Escríbelas pronto: las evals se vuelven más difíciles de construir cuanto más esperes.
Los benchmarks de agentes conocidos también son referencias útiles para construir tus propias evals (la clave es leer "qué mide cada uno"; las puntuaciones cambian según el modelo y la versión, así que no las tomes al pie de la letra).
| Benchmark | Que mide |
|---|---|
| SWE-bench / Verified | Resolver issues reales de GitHub con un parche, puntuado pass/fail por la suite de pruebas (basado en ejecución) |
| τ-bench / τ²-bench | Diálogo multiturno de herramienta x usuario en retail, aerolineas, etc. + seguimiento de políticas; puntuado por el estado final de la DB |
| WebArena | Finalización de tareas de operación web autónoma en réplicas realistas de sitios |
| GAIA | Tareas de asistente general fáciles para humanos, difíciles para la IA (razonamiento + herramientas + navegación) |
| OSWorld | Uso de ordenador operando una GUI en un SO real, evaluado en base a la ejecución |
| BFCL | Precisión en la llamada a funciones/herramientas (nombres de función, estructura de argumentos, ejecutabilidad) |
En cuanto al tooling, LangSmith, Braintrust, DeepEval y Arize Phoenix admiten la evaluación de trajectory y de llamadas a herramientas. La mayoría se construyen sobre rastros, puntuando a nivel de paso, ejecución y dataset. Ten en cuenta que Claude Managed Agents incorpora puntuación basada en resultados —donde un evaluador independiente puntúa frente a tu rúbrica— de serie.
Resumen
Las agent evals son el proceso de medir si un agente que usa herramientas y da múltiples pasos puede realmente cumplir sus tareas. A diferencia de las LLM evals, que miran una sola salida, examinan tanto "la respuesta final (resultado)" como "el camino recorrido (trajectory)". Las dimensiones son (1) resultado (2) trajectory (3) uso de herramientas (4) eficiencia (5) calidad final. Puntúa con código -> LLM-as-judge -> humano, y Anthropic recomienda "puntuar el resultado (estado final), no el camino" (comprobar los pasos de forma mecánica es frágil).
Los escollos exclusivos son el no determinismo (pass^k), los errores que se acumulan, el reward hacking y los conjuntos de eval obsoletos. En la práctica, la jugada estándar es empezar en pequeño con 20-50 casos a partir de fallos reales, ejecutar puntuación automatizada en CI, separar capability y regression evals, y escribirlas pronto. Relacionado: AI evals, observabilidad, cómo construir un sistema multiagente, Managed Agents.
FAQ
Q. ¿Qué son las agent evals?
A. El proceso de medir sistemáticamente si un agente que usa herramientas y da múltiples pasos puede realmente cumplir sus tareas. Son una evolución de las LLM evals, que puntúan un solo prompt; el objetivo se amplia de "una salida" a "una secuencia de acciones". El rasgo distintivo es mirar no solo la respuesta final, sino la trajectory qué llevó a ella (qué herramientas se llamaron, y cómo).
Q. ¿En qué se diferencian de las LLM evals normales?
A. En si miras "una salida" o "una cadena de acciones". Como un agente planifica, llama a herramientas y actualiza el estado, la salida final por sí sola no basta. Una respuesta correcta puede ocultar un proceso roto, y una respuesta correcta puede haber llegado por un atajo peligroso. Por eso evalúas tanto el resultado (estado final) como la trajectory (proceso).
Q. ¿Qué debería medir?
A. Las cinco dimensiones comunes: (1) resultado (éxito de la tarea = ¿coincide el estado final con el objetivo?) (2) trajectory (¿pasos razonables?) (3) corrección en el uso de herramientas (¿herramienta correcta, argumentos correctos?) (4) eficiencia (pasos, tokens, coste, latencia) (5) calidad de la respuesta final ¿(relevante, precisa, completa?). La dimensión 4 incorpora señales de observabilidad y es importante para detener descontroles.
Q. ¿Debería comprobar la trajectory (los pasos) por coincidencia exacta?
A. No: la coincidencia exacta estricta tiende a ser frágil. Anthropic recomienda: "comprobar que las llamadas a herramientas siguieron el orden correcto es demasiado rígido y frágil; los agentes encuentran alternativas validas, así que es mejor puntuar el resultado, no el camino". En la práctica, evita la coincidencia exacta y relajala hasta una comprobación de acciones clave: "¿se llamó a las herramientas críticas?" Dicho esto, la trajectory es útil para diagnosticar por qué fallo, así que usa cada cosa donde encaje.
Q. ¿Cómo empiezo?
A. Empieza por convertir 20-50 fallos de producción en casos de prueba. Como dice Anthropic, "no necesitas cientos; 20-50 tareas sencillas extraídas de fallos reales son un gran comienzo". Puntúa automáticamente —código para lo que el código puede medir, un LLM-as-judge de modelo independiente solo para las partes abiertas— y ponlo en CI para detectar regresiones. Separa las capability evals (en qué es bueno) de las regression evals (mantener lo que funcionaba), y escribe tus evals pronto.
