Contenido
Montaste un sistema multiagente, le diste herramientas y lo ejecutaste con el Agent SDK: entonces, como mides si el agente realmente esta 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 actua con estado. Aunque la ultima frase parezca correcta, puede haber cruzado un puente peligroso por el camino. Aqui es donde las agent evals toman el protagonismo.
Este articulo expone, basandose en informacion oficial, que son las agent evals, en que se diferencian de las LLM evals, que medir (5 dimensiones), como puntuar (3 evaluadores), los escollos exclusivos y el flujo de trabajo practico 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: porque comprobar los pasos de forma mecanica es fragil. (3) Empieza con un conjunto pequeno de 20-50 tareas extraidas de fallos reales y ejecuta una puntuacion 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 que fallo. Usa ambos, para la tarea adecuada.
1. Que son las Agent Evals?
Las agent evals son el proceso de medir sistematicamente si un "agente" —uno que usa herramientas y da multiples pasos para alcanzar un objetivo— puede realmente cumplir sus tareas. Son una evolucion 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 que importa: en su guia sobre agent evals, Anthropic senala que "las evals se vuelven mas dificiles de construir cuanto mas esperes. Al principio, los requisitos del producto se traducen de forma natural en casos de prueba", y recomienda que "20-50 tareas sencillas extraidas de fallos reales son un gran comienzo". Dicho de otro modo, las agent evals convierten "parece que funciona" en numeros reproducibles. Esto va de la mano con la observabilidad de IA (observar la ejecucion): los rastros que observas se convierten en material para la evaluacion.
2. Por que se diferencian de las LLM evals (salida vs trajectory)
Las LLM evals tradicionales basicamente puntuan "entrada -> una salida". Pero un agente planifica, llama a herramientas, mira los resultados, decide el siguiente movimiento y actualiza el estado. Asi que mirar solo la salida final no basta. Google tambien afirma que "no basta con comprobar las salidas; necesitamos entender el 'por que' detras de las acciones de un agente", y divide la evaluacion en dos familias: "respuesta final" y "trajectory". Microsoft, igualmente, dice que hay que "evaluar no solo la salida final, sino tambien la calidad y la eficiencia de cada paso", dividiendola en evaluacion 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 evaluacion de una sola salida y de LLM-as-judge, consulta el articulo sobre AI evals.
3. Que medir: 5 dimensiones
Aqui tienes cinco enfoques de uso comun para la evaluacion de agentes.
Alcanzo 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 inutiles o movimientos peligrosos?
Eligio la herramienta correcta y paso los argumentos correctos? Comprueba nombres de funcion, tipos de argumentos y valores (y detecta llamadas innecesarias).
Cuantos pasos, tokens, dolares y segundos? Una respuesta correcta es poco practica si el coste se dispara. Hay que enlazarla con metricas observadas.
Es la salida relevante, precisa y completa? Puntua el contenido abierto con LLM-as-judge o una rubrica.
Nota: la 4. eficiencia (tokens, coste, latencia) ningun proveedor la codifica formalmente como "metrica de eval"; en la practica suele tratarse de senales de observabilidad llevadas a la evaluacion. Aun asi, es una dimension esencial para detener a un agente que entra en bucle y se descontrola.
4. Como 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 |
|---|---|---|
| Codigo (programatico) | Rapido, barato, objetivo, reproducible | Fragil ante variaciones validas / alternativas |
| LLM-as-judge (modelo) | Flexible, escalable, capta los matices | No determinista, mas caro, necesita calibracion con humanos |
| Humano | Estandar de oro para la calidad | Caro, lento (evitalo si es posible) |
La jugada estandar: puntua con codigo 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 diseno de LLM-as-judge (rubricas detalladas, salidas discretas, sesgo del juez) se trata a fondo en el articulo sobre LLM evals.
El "emparejamiento de trajectory" mecanico es fragil
Entonces, como se puntua la trajectory? Aqui Anthropic adopta una postura firme: "Hay un instinto comun 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 rigido y produce pruebas excesivamente fragiles, porque los agentes encuentran con regularidad enfoques validos que los disenadores 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 tomo." 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 metricas formales. Ambos enfoques no se contradicen: las evals de trajectory son buenas para diagnosticar "por que fallo", y las evals de resultado evitan penalizar la creatividad valida. En la practica, el termino medio realista es evitar la coincidencia exacta estricta y relajarla hasta una comprobacion de acciones clave: "se llamo a las herramientas criticas?"
5. Problemas exclusivos de las agent evals
Las agent evals conllevan dificultades que la evaluacion de una sola salida no tiene.
- No determinismo (la misma entrada toma caminos distintos): un exito no significa que se reproduzca. Necesitas metricas de fiabilidad como si tiene exito en las k ejecuciones (pass^k). El articulo 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 exito con probabilidad p, entonces t pasos tienen exito a aproximadamente pt. Cuanto mas larga es la cadena, mas rapido colapsa, y por eso el exito 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 camara y el objeto, enganando a los evaluadores para que creyeran que habia agarrado el objeto cuando no lo habia hecho. Detectar "parece correcto pero el camino es peligroso" requiere evaluar la trajectory y los efectos secundarios.
- Conjuntos de eval que se vuelven obsoletos / contaminacion: cuando un benchmark se filtra a los datos de entrenamiento (contaminacion), 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 pequeno, a partir de fallos reales: no necesitas cientos. Convierte 20-50 fallos que ocurrieron en produccion en casos de prueba.
- Ejecuta puntuacion automatizada: codigo primero, LLM-as-judge solo para las partes abiertas. Prioriza el volumen sobre la calidad puntuada a mano.
- Separa dos tipos: capability evals (en que es bueno?) y regression evals (sigue pudiendo hacer lo que hacia?).
- Ponlo en un ciclo de vida: (1) evals automatizadas previas al lanzamiento (integradas en CI) -> (2) monitorizacion en produccion -> (3) pruebas A/B -> (4) feedback de usuarios y revision de rastros, en capas sucesivas.
- Escribelas pronto: las evals se vuelven mas dificiles de construir cuanto mas esperes.
Los benchmarks de agentes conocidos tambien son referencias utiles para construir tus propias evals (la clave es leer "que mide cada uno"; las puntuaciones cambian segun el modelo y la version, asi 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 ejecucion) |
| τ-bench / τ²-bench | Dialogo multiturno de herramienta x usuario en retail, aerolineas, etc. + seguimiento de politicas; puntuado por el estado final de la DB |
| WebArena | Finalizacion de tareas de operacion web autonoma en replicas realistas de sitios |
| GAIA | Tareas de asistente general faciles para humanos, dificiles para la IA (razonamiento + herramientas + navegacion) |
| OSWorld | Uso de ordenador operando una GUI en un SO real, evaluado en base a la ejecucion |
| BFCL | Precision en la llamada a funciones/herramientas (nombres de funcion, estructura de argumentos, ejecutabilidad) |
En cuanto al tooling, LangSmith, Braintrust, DeepEval y Arize Phoenix admiten la evaluacion de trajectory y de llamadas a herramientas. La mayoria se construyen sobre rastros, puntuando a nivel de paso, ejecucion y dataset. Ten en cuenta que Claude Managed Agents incorpora puntuacion basada en resultados —donde un evaluador independiente puntua frente a tu rubrica— de serie.
Resumen
Las agent evals son el proceso de medir si un agente que usa herramientas y da multiples 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. Puntua con codigo -> LLM-as-judge -> humano, y Anthropic recomienda "puntuar el resultado (estado final), no el camino" (comprobar los pasos de forma mecanica es fragil).
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 practica, la jugada estandar es empezar en pequeno con 20-50 casos a partir de fallos reales, ejecutar puntuacion automatizada en CI, separar capability y regression evals, y escribirlas pronto. Relacionado: AI evals, observabilidad, como construir un sistema multiagente, Managed Agents.
FAQ
Q. Que son las agent evals?
A. El proceso de medir sistematicamente si un agente que usa herramientas y da multiples pasos puede realmente cumplir sus tareas. Son una evolucion de las LLM evals, que puntuan 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 que llevo a ella (que herramientas se llamaron, y como).
Q. En que 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 si sola no basta. Una respuesta correcta puede ocultar un proceso roto, y una respuesta correcta puede haber llegado por un atajo peligroso. Por eso evaluas tanto el resultado (estado final) como la trajectory (proceso).
Q. Que deberia medir?
A. Las cinco dimensiones comunes: (1) resultado (exito de la tarea = coincide el estado final con el objetivo?) (2) trajectory (pasos razonables?) (3) correccion 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 dimension 4 incorpora senales de observabilidad y es importante para detener descontroles.
Q. Deberia comprobar la trajectory (los pasos) por coincidencia exacta?
A. No: la coincidencia exacta estricta tiende a ser fragil. Anthropic recomienda: "comprobar que las llamadas a herramientas siguieron el orden correcto es demasiado rigido y fragil; los agentes encuentran alternativas validas, asi que es mejor puntuar el resultado, no el camino". En la practica, evita la coincidencia exacta y relajala hasta una comprobacion de acciones clave: "se llamo a las herramientas criticas?" Dicho esto, la trajectory es util para diagnosticar por que fallo, asi que usa cada cosa donde encaje.
Q. Como empiezo?
A. Empieza por convertir 20-50 fallos de produccion en casos de prueba. Como dice Anthropic, "no necesitas cientos; 20-50 tareas sencillas extraidas de fallos reales son un gran comienzo". Puntua automaticamente —codigo para lo que el codigo 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 que es bueno) de las regression evals (mantener lo que funcionaba), y escribe tus evals pronto.
