Anthropic describe cómo evaluar agentes de IA: tres tipos de graders y SWE-bench del 40% al 80%

Anthropic ha publicado una guía de ingeniería para evaluar agentes de IA, y su idea central es muy terrenal: sin evals, tras el primer despliegue en producción el equipo empieza a arreglar una cosa y a romper otra. Un agente llama a herramientas, modifica el estado del entorno y se adapta a los resultados intermedios a lo largo de muchos pasos, por lo que los errores se acumulan. Evaluar un sistema así exige combinar varios métodos. Como ilustración, los autores aportan cifras: en SWE-bench Verified los modelos pasaron del 40% a más del 80% en un solo año, y Bolt montó un sistema de evaluación funcional en tres meses.

Qué compone un eval de agente

Anthropic empieza por la terminología, porque en la industria se usa de forma dispar. Una tarea (task) es una prueba individual con datos de entrada y criterios de éxito. Cada intento se llama trial y se ejecuta varias veces, porque la salida del modelo cambia de una ejecución a otra. Un grader es la lógica que evalúa un aspecto concreto del trabajo; una misma tarea puede tener varios. El transcript es el registro completo de un intento: mensajes, llamadas a herramientas y razonamientos. El outcome es el estado final del entorno.

La diferencia entre estos dos últimos es fundamental. Un agente de reservas puede escribir «Su vuelo ha sido reservado», pero lo único que debe contar es que exista el registro correspondiente en la base de datos SQL. Otra precisión se refiere al objeto de la medición: al evaluar un agente, se evalúa la combinación de modelo y arnés (harness), no el modelo por sí solo. Como ejemplo, los autores citan un caso de Opus 4.5 en el test τ2-bench. El modelo encontró una laguna en las reglas de reserva de vuelos y, según los criterios formales, «suspendió» la tarea, aunque ideó una solución mejor para el usuario.

Tres tipos de graders

Los evals de agentes suelen construirse con tres tipos de comprobaciones:

• Graders basados en código: comprobaciones de cadenas y regex, tests fail-to-pass, análisis estático, verificación del estado final y de las llamadas a herramientas. Son rápidos, baratos y reproducibles, pero frágiles ante variaciones correctas de la respuesta. • Graders basados en modelos: rúbricas, afirmaciones en lenguaje natural, comparación por pares, consenso de varios jueces. Son flexibles y escalables, pero no deterministas, más caros y requieren calibración con humanos. • Graders humanos: revisión de expertos, crowdsourcing, muestreo de control, tests A/B. Son el estándar de oro en calidad, pero lentos y costosos.

La puntuación final de una tarea puede ser ponderada, binaria (todos los graders deben aprobar) o híbrida. La segunda bifurcación es entre capability-evals y regression-evals. Las primeras deben arrancar con un pass rate bajo y marcar al equipo la pendiente que debe remontar. Las segundas deben pasar cerca del 100% y detectar regresiones. Cuando un conjunto de capability se satura, sus tareas se «gradúan» al paquete de regresión.

Agentes de programación y conversacionales

Para los agentes de programación resultan naturales las comprobaciones deterministas: el código se ejecuta y los tests pasan. SWE-bench Verified entrega al agente issues de GitHub de repositorios populares de Python y da por buena la solución solo si los tests que fallaban se arreglan y los existentes no se rompen. Terminal-Bench comprueba tareas técnicas de extremo a extremo, como compilar el kernel de Linux desde el código fuente o entrenar un modelo de ML.

Además de los tests, Anthropic aconseja evaluar el transcript: heurísticas de calidad del código y rúbricas sobre el comportamiento del agente. En un YAML ilustrativo para la tarea «corregir una vulnerabilidad de omisión de autenticación» aparecen todos los tipos de comprobación, incluidos tests, ruff, mypy, bandit y métricas de número de turnos, tokens y latencia. En la práctica, advierten los autores, bastan los tests unitarios y una rúbrica de LLM sobre la calidad del código.

Los agentes conversacionales (soporte, ventas, coaching) se distinguen porque la calidad de la propia interacción forma parte de lo que se evalúa. Aquí se recurre a un estado final verificable y a rúbricas que cubren tanto la resolución de la tarea como la calidad de la comunicación.

Por dónde empezar

Los argumentos de Anthropic a favor de los evals son prácticos. En una fase temprana obligan a fijar qué se considera éxito: dos ingenieros con la misma especificación interpretarán de forma distinta el comportamiento en casos límite. Más adelante aportan líneas base de latencia, consumo de tokens, coste por tarea y tasa de errores. También aceleran la migración a nuevos modelos: los equipos con evals valoran sus puntos fuertes y débiles en días, mientras que el resto tarda semanas en probarlos.

Los ejemplos prácticos son estos. Claude Code se desarrolló primero a partir del feedback, luego incorporó evals de concisión y edición de archivos, y después de sobrecomplicación de las soluciones. Descript evalúa a su agente con tres criterios: no rompas nada, haz lo que se te pide, hazlo bien. El equipo pasó de la revisión manual a graders basados en LLM con calibración humana periódica. Bolt empezó tarde, cuando el agente ya estaba en uso masivo.

La conclusión práctica: no esperen a tener un conjunto perfecto. Tomen las tareas en las que el agente falla ahora y conviértanlas en un capability-eval. Añadan graders de código sobre el estado final del entorno. Incorporen un juez LLM solo para lo que el código no puede comprobar, y contrástenlo con las valoraciones de personas. Ejecuten cada tarea varias veces y pasen al paquete de regresión las que se superan de forma estable.