Saltar al contenido principal

Evalúa tu agente Claude (Evals)

Avanzado

Ajustaste un prompt y parece mejor, ¿pero lo es? Sin evals (evaluaciones) vuelas a ciegas: cada cambio es un volado, y te enteras de que se rompió por un usuario enojado, no por una prueba. Las evals convierten el "a ojo" en un número en el que puedes confiar, que puedes defender y observar a lo largo del tiempo. Esto es lo más importante que separa los prompts de afición del trabajo con Claude de grado producción.

What you'll learn
  • Por qué "a mí me parece bien" no es una prueba, y qué medir en su lugar
  • Construir un golden dataset a partir de fallos REALES (de abajo hacia arriba), no imaginados
  • Puntuar con código donde puedas, y con un LLM-as-judge donde no puedas
  • Conectar las evals al CI para que un cambio de prompt o modelo nunca regrese en silencio

La mentalidad: medir, no adivinar​

Tres reglas que te salvan:

  • De abajo hacia arriba supera a de arriba hacia abajo. Recolecta primero los fallos reales, luego diseña la métrica para atraparlos. Una eval construida a partir de roturas reales predice roturas reales; una eval inventada en una pizarra mide sobre todo tu imaginación.
  • Un número que puedes volver a ejecutar. Una eval es repetible: las mismas entradas → una puntuación comparable. Eso es lo que te permite comparar honestamente el prompt v1 frente al v2, o claude-haiku-4-5 frente a claude-sonnet-4-6.
  • Barata de ejecutar, ejecútala a menudo. Si a una persona le toma una tarde, no va a pasar. Automatízala.

Construye un golden dataset (de abajo hacia arriba)​

Tu golden dataset es el corazón de toda eval: un conjunto curado de entradas con expectativas correctas conocidas.

Guided walkthrough1 of 4
  1. Empieza por las salidas malas reales: trazas de producción, reportes de bugs, tickets de soporte. Estos son los casos que importan.

Puntuar: primero código, luego juez​

Recurre primero a la comprobación fiable más barata.

  • Comprobaciones programáticas (deterministas) — úsalas siempre que la respuesta tenga estructura: coincidencia exacta/por palabra clave, "JSON válido contra este esquema", "¿llamó a la herramienta correcta con los argumentos correctos?", "por debajo de N tokens / por debajo de X ms". Rápidas, gratuitas y nunca inestables.
  • LLM-as-judge — para dimensiones difusas (utilidad, tono, fidelidad a una fuente) que se resisten al código. Dale al juez una rúbrica, no un "a ojo", y calíbralo contra etiquetas humanas antes de confiar en él.

:::warning Los jueces tienen sesgos Los jueces LLM se inclinan hacia respuestas más largas (sesgo de verbosidad) y hacia la opción que se muestra primero (sesgo de posición). Defensas: una rúbrica estricta, comparación por pares en lugar de puntuación absoluta, intercambiar el orden de las respuestas y volver a verificar al juez contra una porción etiquetada por humanos. Un juez es una capa, no toda la prueba. :::

Rúbrica de LLM-as-judge (inicial)

You are a strict grader. You are given a QUESTION, a REFERENCE answer, and a MODEL answer.
Score the MODEL answer from 1-5 on (a) faithfulness to the reference and (b) helpfulness.
Output ONLY JSON, nothing else: {"score": <1-5>, "reason": "<one short sentence>"}

QUESTION: {{question}}
REFERENCE: {{reference}}
MODEL: {{model_answer}}

Para los agentes, prueba también la trayectoria​

Un agente puede llegar a la respuesta final correcta por el camino equivocado: entrando en bucles, llamando a una herramienta destructiva o quemando tu presupuesto. Así que evalúa el camino, no solo el destino: ¿llamó a las herramientas correctas, en un orden sensato, sin bucles, dentro del presupuesto? La corrección de las llamadas a herramientas y las comprobaciones de trayectoria detectan fallos que una eval centrada solo en la respuesta final nunca ve.

Conéctalo al CI​

Aquí es donde las evals rinden frutos: hacer imposible fusionar regresiones.

Guided walkthrough1 of 3
  1. Puntúa de forma programática donde sea posible; ejecuta el juez en el resto.
Vocabulario de evals
Term shown.
1 / 4

Compruébate

0/3
  1. ¿Cuál es la primera opción más fiable para puntuar una eval?
  2. ¿De dónde deberían provenir mayormente los casos de un golden dataset?
  3. Para un AGENTE, ¿qué deberías evaluar más allá de la respuesta final?
Key takeaways
  • Sin eval = publicar a ojo. Construye una antes de confiar en un prompt o agente.
  • Golden dataset a partir de fallos reales; hazlo crecer cada semana con las nuevas regresiones.
  • Comprobaciones basadas en código primero; LLM-as-judge (con una rúbrica, calibrado) para las partes difusas.
  • Para los agentes, califica la trayectoria, no solo la salida.
  • Ejecútalo en el CI y haz fallar el build ante una caída: así es como la calidad deja de regresar.

Fuentes y lecturas adicionales​

Siguiente​