Eval datasets y métricas: el test set es el spec del producto

Una evaluación son dos cosas atornilladas juntas: un dataset de casos para correr, y un método de calificación que puntúa la salida en cada caso. Te falta cualquiera de las mitades y no tenés una eval. Un dataset sin calificador es una pila de inputs; un calificador sin dataset es una opinión sin dónde apuntar. Esta página construye las dos mitades, porque el test set — los casos más cómo los puntuás — es lo más parecido a un spec de producto que tiene una feature de IA. Es la respuesta escrita a "qué significa funcionar acá", y hasta que existe, "funciona" es una sensación, no una afirmación.

Acá es donde el principio 3 deja de ser un eslogan y se convierte en trabajo. Si no lo podés evaluar, no lo podés shipear — y no lo podés evaluar sin un conjunto de casos y una forma de calificarlos. Todo lo de abajo en esta subcategoría — LLM-as-judge, tracing, regresión, el monitoreo que detecta una degradación silenciosa — corre sobre el dataset que esta página construye. Acertá el set y el resto tiene algo real sobre lo que pararse. Erralo — demasiado chico, sesgado lejos de producción, calificado a ojo — y cada número que produce es seguro y no significa nada.

Construir el eval set: espejá la distribución real, después sumá los bordes

La primera regla es la que los equipos se saltean porque suena obvia: el eval set espeja tu distribución real de la tarea. El primer principio de diseño de evals de Anthropic es "diseñá evals que espejen tu distribución real de la tarea" — si el 70% del tráfico de producción son preguntas factuales cortas y el 30% son pedidos multi-paso, un eval set que es 90% multi-paso te miente en las dos direcciones. Sub-testea el caso común y sobre-pondera el raro, así que un modelo que regresiona en la query de todos los días igual puede sacar un score verde. El dataset es una muestra de la realidad; una muestra sesgada produce un veredicto sesgado.

La segunda regla es la que atrapa las fallas: incluí a propósito los edge cases. La misma guía de Anthropic es explícita — "no te olvides de tener en cuenta los edge cases" — y nombra los que importan: input irrelevante o inexistente, input demasiado largo, input de usuario dañino o fuera de tema, y casos ambiguos donde hasta a un humano le costaría ponerse de acuerdo. Estos son exactamente los inputs que una demo de happy-path nunca ve y producción ve el día uno. Un eval set construido solo con casos limpios y representativos te dice que el modelo maneja el 80% fácil — que ya sospechabas — y no te dice nada del 20% que genera los tickets de soporte. Los bordes no son ruido para limpiar del set; son el motivo de tener uno.

Qué tan grande: volumen sobre pulido a mano

El instinto es laburar a mano unas pocas docenas de casos perfectos, calificados a mano. El tercer principio de diseño de evals de Anthropic dice lo contrario, y vale la pena citarlo porque es contraintuitivo: "Más preguntas con calificación automática de señal un poco más baja es mejor que menos preguntas con evals de alta calidad calificadas a mano por un humano." El razonamiento es estadístico. Un puñado de casos produce un número con varianza enorme — tres casos que pasan de pasar a fallar pueden mover una eval de 20 casos quince puntos, así que no podés distinguir una regresión real del ruido de muestreo. Cientos de casos calificados automáticamente dan un número que de verdad podés mover y en el que podés confiar, y corren en cada cambio gratis. Un calificador un poco más ruidoso aplicado a muchos casos le gana a un calificador impecable aplicado a pocos, porque el volumen es lo que te compra señal. Por eso también el segundo principio de diseño — "automatizá cuando puedas" — no es una comodidad sino un prerrequisito: un set que solo podés calificar a mano es un set que vas a calificar una vez y nunca más, lo que lo vuelve inútil como red de regresión. Escribir cientos de casos a mano es su propio costo; la guía de Anthropic es sembrar un set base y que Claude genere más a partir de él.

Métodos de calificación: un método por caso

Cada caso necesita una forma de convertir una salida en un score. No hay un único calificador para un set entero — elegís el método que encaja con la forma de cada caso, y un mismo eval set usa varios de rutina. La regla de Anthropic para elegir es ir por "el método más rápido, más confiable, más escalable" que el caso permita, y evitar la calificación humana donde un método automático sirva. Acá están los métodos, para qué sirve cada uno, y dónde muerde cada uno:

Método	Cómo funciona	Bueno para	Cuidado con
Exact / string match	Comparar la salida con una respuesta conocida tras normalizar mayúsculas y espacios (`output == golden`), o chequear que una frase clave esté presente (`phrase in output`)	Respuestas categóricas y nítidas — labels de sentimiento, sí/no, un valor específico que tiene que aparecer	Frágil en texto libre: una respuesta correcta fraseada distinto falla. Mala herramienta para algo abierto.
Code-graded	Una función determinista chequea una propiedad de la salida — JSON válido, compila, en rango, pasa un regex	Structured output, contratos de formato, cualquier cosa con una regla chequeable	Tan bueno como la regla. Chequea la forma, no si el contenido está bien.
Multiple-choice	Restringir la tarea para que el modelo elija de un conjunto fijo, después chequear la elección	Clasificación y ruteo donde vos controlás el conjunto de opciones; la señal confiable más barata	Requiere reformular la tarea en opciones, lo que no toda tarea permite.
Similarity / semantic	Embeber salida y referencia, puntuar qué tan cerca están (p. ej. cosine similarity sobre sentence embeddings); ROUGE-L para overlap de resúmenes	Consistencia y paráfrasis — "son dos respuestas semánticamente lo mismo" aunque el fraseo difiera	Un score, no un veredicto; vos ponés el umbral. Necesita un modelo de embeddings y texto de referencia.
LLM-graded	Un modelo aparte puntúa la salida contra una rúbrica — correcto/incorrecto, o una escala de 1 a 5	Cualidades matizadas y subjetivas — tono, fidelidad, utilidad — que ninguna regla captura	Hay que validarlo antes de confiar en él. Usá un modelo distinto del que está bajo prueba, dale una rúbrica detallada, y hacelo emitir un label discreto.

Tres detalles de la guía de calificación de Anthropic sostienen la fila de LLM-graded, porque es la que los equipos agarran demasiado rápido y en la que confían demasiado pronto. Primero, la rúbrica es el calificador — una rúbrica vaga produce un score vago e inestable, así que tiene que ser concreta y empírica: "la respuesta tiene que mencionar 'Acme Inc.' en la primera oración; si no lo hace, calificala incorrecta." Segundo, hacé que el juez emita un resultado discreto — correcto/incorrecto o una escala fija de 1 a 5, nunca un párrafo libre que después tenés que parsear. Tercero, dejalo razonar, después descartá el razonamiento — pedirle al juez que piense en tags <thinking> antes de emitir un <result> mejora de forma medible el score en los juicios difíciles. LLM-as-judge tiene su propia página en esta subcategoría; acá es una fila de la tabla, el método que elegís cuando ninguno más barato encaja con la cualidad que estás puntuando.

Ground truth: de dónde sale la respuesta correcta, y cuánto cuesta

La mayoría de estos métodos necesitan una respuesta conocida-buena contra la cual comparar — el exact match necesita el valor golden, similarity necesita el texto de referencia, la calificación LLM basada en referencia necesita la salida esperada. Esa respuesta conocida-buena es el ground truth (LangSmith lo llama el reference output), y el hecho incómodo es que alguien tiene que producirla. No cae del cielo. Para un set de mil casos de sentimiento, eso es mil sentimientos etiquetados por un humano; para un set de summarization, un resumen de referencia por artículo. Este etiquetado es el costo real de un eval set, y es por qué el principio de volumen-sobre-pulido importa dos veces: querés casos suficientes para tener señal, pero cada caso con un reference output es un caso que alguien tuvo que etiquetar.

Dos cosas le sacan el filo al costo. Primero, no todo método necesita una referencia — los chequeos code-graded ("¿es JSON válido?", "¿está bajo el tope de largo?") y la calificación LLM sin referencia ("¿esta respuesta filtra PII?", juzgada contra una política, no contra una respuesta esperada) puntúan la salida por sus propias propiedades, sin respuesta golden requerida. Apoyate en esos donde la tarea lo permite; son libres de ground truth por construcción. Segundo, donde sí necesitás labels, sembrá un set chico a mano y hacelo crecer — generá casos candidatos, etiquetá los candidatos en vez de redactar cada uno desde cero. Lo que no podés hacer es dejar que el modelo bajo prueba escriba su propio ground truth; eso es calificar el examen con la hoja de respuestas que escribió el alumno, y no certifica nada.

Versionar el eval set: para que dos corridas sean comparables

Un número de eval no significa nada solo. Solo significa algo comparado — con la semana pasada, con el prompt de antes del cambio, con el baseline que estás tratando de superar. Esa comparación solo es válida si las dos corridas corrieron contra el mismo set. En el momento en que sumás diez casos, sacás tres, o arreglás una respuesta mal etiquetada, el score de esta semana ya no es comparable con el de la semana pasada, y una "regresión" puede ser nomás un set más difícil. Así que versionás el eval set. Tratá el dataset como un artefacto versionado, igual que tratás el código: un cambio en los casos es un commit, con una nota de qué cambió y por qué. LangSmith lo trae de fábrica — las versiones del dataset se crean automáticamente a medida que cambian los examples, y podés taggear una versión para marcar un hito — y aun sin ese tooling la disciplina es la misma: fijá la versión contra la que se produjo un resultado, y cuando cambiás el set, decilo, así nadie compara dos números que nunca midieron lo mismo. Esto es el principio 11 metiéndose en el eval set mismo — trazá todo — porque un score que no podés atar a un set y una versión exactos es un score que no podés defender.

Un set, tres consumidores: dónde se enchufa

El toolkit se compone acá exactamente como dice el principio 7 que debería — componé el toolkit a la tarea — y el eval set es el artefacto compartido que hace que la composición funcione. Los casos y su ground truth se redactan una vez; lo que cambia es dónde los corrés. El mismo set alimenta tres lugares:

La capa del modelo — el tooling de evals de Anthropic. La Claude Console tiene una Evaluation tool de fábrica: una pestaña Evaluate en el editor de prompts donde tus casos se vuelven filas de test (sumadas a mano, generadas por Claude, o importadas de un CSV), y calificás respuestas en una escala de 5 puntos, comparás dos versiones de prompt lado a lado, y re-corrés toda la suite contra una versión nueva del prompt. Es el camino más rápido de "cambié el prompt" a "esto es lo que eso hizo en cada caso", y es donde un cambio a nivel prompt tiene su primera lectura. (Necesita prompts escritos con placeholders {{variable}} para que los casos puedan variar los inputs.)
El harness fuera de plataforma — un dataset de LangSmith. Cuando lo que está bajo prueba no es un solo prompt sino una chain, un agente, o un grafo, los mismos casos viven como un dataset de LangSmith de examples — inputs más reference outputs — calificados por evaluadores de código, LLM-as-judge, humanos, o pairwise, con cada corrida capturada como un experiment que comparás lado a lado entre versiones. Este es el harness del sistema entero, no solo de la llamada al modelo.
La red de regresión de lo ya shipeado. El mismo set es la red de seguridad debajo de cada página ya en este catálogo. Los agentes que construís en agents, el retrieval que afinás en grounding, los prompts que endurecés en prompting — ninguno se queda correcto de casualidad. El eval set es lo que re-corrés cuando cambiás un modelo, editás un system prompt, o cambiás un retriever, así un arreglo en un lado que en silencio rompe otro aparece como un caso rojo en vez de como un reclamo de un cliente. Ojo que la calidad de retrieval tiene su propio eval set dedicado, query-a-chunk, separado de la calidad de la respuesta — mirá retrieval quality; el set que construye esta página califica la respuesta, y los dos corren lado a lado.

Los mismos casos, el mismo ground truth, tres harnesses. No mantenés tres eval sets; mantenés uno y lo apuntás a donde está la pregunta.

La disciplina, recapitulada

Una eval es un dataset más un calificador, y el test set es el spec de producto de una feature de IA — la definición escrita de funcionar. Construí el dataset para que espeje la distribución real y llenalo a propósito con edge cases, porque los casos que dejás afuera son los que se rompen primero. Hacelo grande y calificado automáticamente en vez de chico y pulido a mano, porque el volumen es lo que te compra señal en la que podés confiar. Calificá cada caso con el método confiable más barato que encaje con su forma, y cuando solo un juez LLM sirve, dale una rúbrica concreta, una salida discreta, y un modelo distinto del que está bajo prueba. Conseguí el ground truth a propósito y versioná el set como código, así dos corridas son de verdad comparables. Después apuntá ese único set a la Evaluation tool de la Console, a un dataset de LangSmith, y a todo lo que ya shipeaste. Hacé eso y el principio 3 queda satisfecho: lo podés evaluar, así que lo podés shipear. Salteatelo y estás shipeando sobre una sensación — que funciona hasta el momento exacto en que llega el input que nunca testeaste.

AI Engineering principles — si no lo podés evaluar, no lo podés shipear (3); trazá todo (11); componé el toolkit (7)
What is context engineering — la disciplina de prompting de la que el eval set es la red de regresión
Structured output — la validación code-graded es el espejo del lado eval de validá-después-fallback
Retrieval quality — el eval set de retrieval (query-a-chunk), el análogo al lado del que corre el set del lado respuesta de esta página
What is grounding — los sistemas grounded que un eval set mantiene honestos
What is an agent — los agentes de los que un eval set es la red de regresión
Style Guide de evaluación — cuándo agarrar qué calificador
Debuggear evals — cuando el que miente es el dataset o la métrica
Debugging agents — lo que agarrás cuando un caso se pone rojo y necesitás la traza

Reference: