Evaluar agentes de IA no es un lujo: es la forma de pasar de arreglar incendios en producción a mejorar con intención. ¿Cómo sabes si tu agente mejora o si solo cambias el ruido? Anthropic comparte una guía práctica y técnica para diseñar evals que realmente midan comportamiento y no penalicen la creatividad útil.
Qué es una evaluación (eval) y por qué importa
Una eval es un test automatizado: le das una entrada al agente y aplicas lógica de calificación para medir éxito. Suena simple, pero con agentes que actúan en múltiples turnos, llaman herramientas y modifican estado, evaluar se vuelve complejo. ¿Qué mide exactamente la eval: la respuesta, la serie de pasos que siguió el agente, o el estado final en la base de datos? La respuesta correcta suele ser las tres.
Buenas evals hacen visibles cambios de comportamiento antes de que afecten a los usuarios.
Al definir términos clave: tarea (test case), trial (intento), grader (lógica que puntúa), transcript (registro completo), outcome (estado final), harness (infraestructura que corre la eval) y suite (colección de tareas), tienes el vocabulario para construir una estrategia repetible.
Tipos de graders y cuándo usarlos
Anthropic recomienda combinar tres familias de graders según lo que quieras medir: determinísticos (code-based), basados en modelos (LLM graders) y humanos.
-
Code-based graders: rápidos, baratos y reproducibles. Son ideales para verificaciones objetivas: tests unitarios, análisis estático, chequear llamadas a herramientas y estado final. Su debilidad: son frágiles ante variaciones legítimas.
-
Model-based graders: usan LLMs como jueces con rúbricas estructuradas. Sirven bien para evaluar calidad de lenguaje, empatía o cobertura en respuestas abiertas. Necesitan calibración humana y mecanismos para que devuelvan "Unknown" si no pueden juzgar.
-
Human graders: imprescindibles para calibrar y resolver ambigüedades. Úsalos de forma estratégica, no para todo.
Para cada tarea puedes combinar graders y usar scoring binario, ponderado o híbrido.
Métricas útiles para lidiar con no-determinismo
Los agentes son estocásticos. Dos métricas prácticas:
-
pass@k: probabilidad de que al menos uno de k intentos sea correcto. Útil cuando una solución entre muchas basta. -
pass^k: probabilidad de que los k intentos sean todos correctos. Importante cuando la consistencia importa.
Ejemplo numérico: si la tasa por trial es 75% y corres 3 trials, pass^3 = 0.75^3 ≈ 0.42. Eso te dice que exigir 3 éxitos consistentes es un umbral mucho más duro.
Cómo evaluar distintos tipos de agentes (práctico)
-
Coding agents: confía en tests deterministas. Si el código pasa la suite de tests sin romper otras partes, pasa. Complementa con análisis estático (
ruff,mypy,bandit) y rúbricas LLM para calidad de código y estilo. -
Conversational agents: mezcla outcomes verificables (estado en ticketing), métricas de transcript (n_turns) y rúbricas LLM para tono y empatía. Simula usuarios con otro LLM para cubrir conversaciones adversariales.
-
Research agents: combina groundedness checks (citas), coverage checks (hechos clave) y evaluaciones de calidad de fuente. Calibra constantemente con expertos humanos.
-
Computer-use agents: correlos en entornos sandbox. Verifica artefactos post-tarea: sistema de archivos, DB, elementos UI. Balancea entre DOM (rápido pero token-intenso) y screenshots (más eficiente en tokens).
Ejemplo teórico (YAML) para una tarea de coding
task:
id: "fix-auth-bypass_1"
desc: "Fix authentication bypass when password field is empty"
graders:
- type: deterministic_tests
required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]
- type: llm_rubric
rubric: prompts/code_quality.md
- type: static_analysis
commands: [ruff, mypy, bandit]
- type: state_check
expect:
security_logs: {event_type: "auth_blocked"}
- type: tool_calls
required:
- {tool: read_file, params: {path: "src/auth/*"}}
- {tool: edit_file}
- {tool: run_tests}
tracked_metrics:
- type: transcript
metrics: [n_turns, n_toolcalls, n_total_tokens]
- type: latency
metrics: [time_to_first_token, time_to_last_token]
Usa lo esencial: en la práctica, unit tests + rúbrica LLM suelen bastar, y añades más graders solo cuando el caso lo requiere.
Roadmap práctico: de cero a evals confiables
- Empieza temprano: 20-50 tareas reales bastan para comenzar. No esperes cientos.
- Convierte checks manuales y bugs reales en tareas de eval. Prioriza por impacto de usuario.
- Escribe tareas no ambiguas y crea soluciones de referencia que pasen todos los graders.
- Balancea el dataset: incluye casos positivos y negativos para evitar optimizaciones unidireccionales.
- Construye un eval harness estable: inicia cada trial desde un entorno limpio para evitar ruido.
- Diseña graders resistentes a hacks y evita pruebas demasiado rígidas sobre la secuencia de pasos.
- Lee transcripts regularmente: los números no valen sin contexto.
- Mantén la suite: asigna propietarios, permite contribuciones y trata las evals como tests unitarios.
Cómo encajan las evals con otras prácticas
Las evals automatizadas son la primera línea en CI/CD. Complementalas con:
- Monitoreo en producción para detectar drift.
- A/B tests para validar cambios significativos con tráfico real.
- Feedback de usuarios y revisión manual de transcripts para calibración.
- Estudios humanos sistemáticos para outputs subjetivos.
La combinación correcta depende de la etapa del producto y del riesgo asociado.
Riesgos y trampas comunes que debes evitar
- Evaluaciones que penalizan creatividad útil: gradea resultados, no caminos siempre.
- Tasks mal especificadas que causan 0% pass@100: reescribe la tarea o arregla el grader.
- Entornos compartidos que introducen dependencias no deseadas entre trials.
- Rúbricas LLM sin calibración: sincroniza con humanos y permite respuestas "Unknown".
Reflexión final
Evals bien diseñadas transforman la incertidumbre en métricas accionables. No son un costo: son apalancamiento. Si las tratas como tests y les das mantenimiento, aceleran la adopción de nuevos modelos, reducen regresiones y permiten que equipos confíen en cambios rápidos. ¿Quieres mejorar un agente? Define qué significa "mejor" en pruebas, automatiza esas pruebas y lee los transcripts.
Fuente original
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents