Anthropic explica evals para agentes de IA | Keryc
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).
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.
