Evaluación de modelos (evals)

Una evaluación de modelos (eval) es un conjunto de casos de prueba con criterios de éxito definidos que se usa para medir, de forma repetible, qué tan bien responde un modelo como Claude a una tarea concreta. Funciona como los tests de software, pero adaptado a salidas no deterministas: en lugar de comprobar un valor exacto, puntúa si la respuesta cumple lo que se espera.

Cómo funciona

Toda eval tiene tres piezas:

1. Dataset de casos: entradas representativas del uso real, incluidos casos límite, entradas ambiguas e intentos de abuso. Pueden salir de logs de producción o generarse con el propio Claude a partir de unos pocos ejemplos escritos a mano.
2. Criterio de éxito: qué cuenta como respuesta correcta. Debe ser específico y medible: "clasifica bien el ticket en al menos el 95 % de los casos" en vez de "funciona bien".
3. Calificador (grader): el mecanismo que puntúa cada salida.

Hay tres formas de calificar, de más rígida a más flexible:

• Basada en código: coincidencia exacta, expresiones regulares, validar un JSON contra un esquema o ejecutar tests unitarios sobre el código generado. Rápida, barata y reproducible.
• Modelo como juez (LLM-as-a-judge): otro modelo, a menudo Claude con una rúbrica detallada, valora tono, completitud o fidelidad a las fuentes. Escala bien, pero hay que verificar que su criterio coincide con el humano.
• Humana: la más fiable para matices, pero lenta y cara; se reserva para calibrar las anteriores.

Por qué importa

Sin evals, cada cambio en un system prompt, en la temperatura o en el modelo es una apuesta. Con ellas puedes:

• Saber si una nueva versión del prompt mejora o empeora antes de desplegarla.
• Migrar entre modelos de la familia Claude (por ejemplo, de Sonnet a Haiku para reducir costes) con datos y no con intuiciones.
• Detectar regresiones cuando Anthropic publica un modelo nuevo o retira uno antiguo.
• Medir tasas de alucinación, rechazos indebidos o fallos de un agente al usar herramientas.

La documentación de Anthropic propone este orden: definir criterios de éxito, construir la eval y solo entonces iterar el prompt. Es la misma disciplina que se practica al aprender a construir sobre la API de Claude: primero la vara de medir, después la optimización.

Ejemplo mínimo

Un clasificador de tickets de soporte con calificación por código:

casos = [
  {'input': 'No puedo entrar a mi cuenta', 'esperado': 'acceso'},
  {'input': 'Me cobrasteis dos veces', 'esperado': 'facturacion'},
]
aciertos = 0
for c in casos:
    salida = clasificar(c['input'])  # llamada a la API de Claude
    aciertos += salida.strip().lower() == c['esperado']
print(f'Precisión: {aciertos / len(casos):.0%}')

En un proyecto real el dataset tendría cientos de casos. Como las respuestas de Claude varían entre ejecuciones, conviene repetir cada caso varias veces o fijar una temperatura baja para separar el ruido de los cambios reales. La Consola de Anthropic incluye además una herramienta de evaluación para comparar versiones de un prompt lado a lado sin escribir código.

Qué NO es

• No es un benchmark público. MMLU, SWE-bench o GPQA comparan modelos en tareas genéricas; tu eval mide tu caso de uso. Un modelo que lidera los rankings puede fallar en tu formato de salida.
• No es probar cinco prompts a mano. Revisar ejemplos sueltos (el famoso vibe check) sirve para explorar, no para decidir.
• No se hace una sola vez. El dataset debe crecer con cada fallo que aparezca en producción.
• No son las evals de seguridad de Anthropic. Las que la compañía ejecuta antes de lanzar un modelo, ligadas a su política de escalado responsable, miden capacidades peligrosas, no la calidad de tu aplicación.