Construye una evaluación mínima viable

La demostración de este video se grabó en agosto de 2026. Se ejecutó en Claude Haiku 4.5, Claude Sonnet 5 y Claude Opus 5. Los resultados serán diferentes en modelos más nuevos. La demostración de cada lección es una ejecución de evaluación independiente, así que sus puntuaciones y costos no coincidirán con los de otras lecciones.

Una evaluación es una prueba que toman los modelos. Tiene tres partes: entradas realistas, la respuesta que esperas para cada una, y una forma de calificar lo que devuelve cada modelo. Cada modelo ejecuta tu prompt en cada entrada. Una entrada junto con su respuesta esperada forma un caso, y calificar cada caso te da una puntuación.

El prompt de extracción de Meridian extrae tres campos de cada informe mensual de proyecto: el ID del proyecto y el estado del cronograma, que son valores cortos, y el principal riesgo, que es una oración.

Construir una evaluación es como dar un examen, contigo como el profesor y los modelos como los estudiantes.

Un juez LLM es un segundo modelo que revisa una respuesta y decide si es correcta. Cualquier cosa que califique una respuesta se llama calificador, ya sea código, un modelo o una persona. Construirás la evaluación de Meridian en seis pasos:

1. Elige un calificador para cada campo
2. Diseña el conjunto de casos
3. Anota las respuestas esperadas
4. Configura el juez LLM para el principal riesgo
5. Ejecuta los modelos y califica sus respuestas
6. Califica una muestra a mano antes de confiar en el juez

Elige un calificador para cada campo

Hay tres formas de calificar una respuesta. La regla es elegir el método más rápido que también sea confiable y escale.

1. Calificación basada en código. Tu código verifica que una respuesta coincida exactamente con su respuesta esperada, o que contenga una frase clave. Es la forma más rápida y confiable, y escala a cualquier cantidad de casos.
2. Juez LLM. El juez se adapta a respuestas donde dos oraciones diferentes pueden ser correctas. También es rápido, flexible y escalable.
3. Calificación humana. Una persona lee cada respuesta, lo que da la mejor calidad pero es lento y costoso, así que queda en último lugar. Las personas siguen siendo los calificadores adecuados para trabajo especializado y de alto riesgo, y para respuestas que dependen del juicio.

Usa código para cada campo que pueda verificarse con exactitud, y dale al juez solo lo que quede. Así es como esto se aplica a los tres campos de Meridian en uno de sus casos, el informe r032.

Sin embargo, cuando un informe no nombra ningún riesgo, la respuesta esperada de top_risk es null, el valor vacío de JSON. El código puede verificar eso con una coincidencia exacta.

Diseña el conjunto de casos

Cuatro reglas dan forma a todo el conjunto de casos. Se basan en los principios de diseño de evaluaciones de la documentación.

1. Haz que los casos sean específicos de la tarea. Constrúyelos a partir de tus propios informes reales, porque los datos de muestra solo muestran cómo le va a un modelo con muestras.
2. Automatiza la calificación. Ejecutarás el conjunto una y otra vez, así que la calificación cotidiana tiene que funcionar sin una persona.
3. Favorece el volumen sobre el pulido. Con el mismo esfuerzo, muchos casos calificados automáticamente te dicen más que unos pocos calificados cuidadosamente a mano.
4. Estratifica tus casos extremos. Un caso extremo es una entrada inusual que la producción todavía envía, como un informe escaneado. Dale a cada tipo aproximadamente la proporción de casos que tiene en producción, así que si los informes escaneados son el 5% de lo que llega, haz que sean cerca del 5% del conjunto.

Sobre todo, la mezcla de casos debería parecerse a lo que te envía la producción. Los equipos suelen entender "volumen" como cientos de casos, pero un conjunto de 20 a 50 casos simples es un excelente comienzo.

Meridian se decidió por 50 casos. Treinta son informes típicos, 10 cubren varios proyectos, y 10 son casos sin riesgo, lo que significa informes sin sección de riesgo. Ambos tipos inusuales llegan a Meridian con la frecuencia suficiente como para que quiera cubrirlos.

Anota las respuestas esperadas

Los casos cuyas respuestas esperadas una persona ha anotado se llaman un conjunto etiquetado. Escribe tú mismo cada respuesta esperada, a partir del informe, antes de que se ejecute cualquier modelo. El calificador de código compara las respuestas de los modelos con ellas.

Meridian mantiene su conjunto etiquetado en un solo archivo, golden.json, con un registro para cada caso. Un registro contiene el id del caso, su category, y la respuesta esperada para cada campo. La category es typical, multi_project, o missing_risk.

Configura el juez LLM para el principal riesgo

El campo top_risk contiene una oración. El código no puede saber si dos oraciones diferentes nombran el mismo riesgo, así que este campo va al juez. Es la pregunta de ensayo, y como el asistente de cátedra, el juez necesita una guía de calificación.

Esa guía es una rúbrica, un conjunto escrito de reglas sobre qué cuenta como correcto y qué cuenta como incorrecto. Debe ser detallada y clara.

El prompt del juez contiene el informe, la respuesta y la rúbrica. Cada uno va en sus propias etiquetas XML, para que sea menos probable que el juez los confunda. Tu respuesta esperada no está en el prompt, porque el juez decide a partir del informe mismo. De esa forma, una respuesta no pierde puntos solo por expresar el riesgo con palabras distintas a las tuyas. Aun así, conserva tu respuesta esperada, ya que es tu registro de la respuesta correcta cuando calificas una muestra a mano.

La decisión del juez sobre una respuesta se llama su veredicto. Un veredicto solo es útil si vuelve en una forma que tu código pueda contar. Las salidas estructuradas te dan eso. Envías un esquema JSON con la solicitud, y la respuesta tiene que coincidir con él. Un esquema JSON describe qué campos puede contener el JSON y qué puede ir en cada uno.

El esquema de Meridian tiene dos campos, explanation y verdict. El veredicto debe ser correct, incorrect, o unknown. La explicación es un breve relato de por qué el juez decidió así, así que es lo que lees cuando quieres saber qué salió mal con una respuesta.

El valor que más importa es unknown. Le da al juez una salida, una opción para decir que no puede saberlo. Sin eso, el juez tiene que adivinar entre las otras dos cada vez que no está seguro.

Ejecuta los modelos y califica sus respuestas

Antes de poder calificar nada, necesitas respuestas. Ejecuta tu prompt en cada caso con cada modelo que estés probando, y guarda cada respuesta en un archivo. Meridian ejecutó su prompt de extracción en los 50 casos con Claude Haiku 4.5, Claude Sonnet 5 y Claude Opus 5.

Prueba el juez una vez, en casos que el código también pueda calificar, para ver si los dos calificadores coinciden. La primera ejecución del juez de Meridian tomó solo los 10 casos sin riesgo, que sumaron 30 respuestas entre los tres modelos. Su respuesta esperada es null, así que el código también podía calificarlos. Guarda cada veredicto junto a su respuesta, para que puedas revisar al juez a mano más tarde.

La primera ejecución del juez, en los 10 casos sin riesgo, donde el código también podía calificar.

Para informes sin sección de riesgo, Meridian ahora tiene un número para cada modelo donde antes tenía opiniones.

Las cinco respuestas incorrectas de Haiku 4.5 son todas el mismo tipo de error, y el caso r045 muestra uno.

La explicación del juez nombra el tipo de error que cometió la respuesta. Ese error viene del prompt de extracción, que nunca indica qué hacer cuando un informe no nombra ningún riesgo.

Califica una muestra a mano antes de confiar en el juez

El juez coincidió con el código en las 30 respuestas, pero el código podía verificarlas de todos modos. El verdadero trabajo del juez es calificar texto libre, donde el código no puede ayudar. Antes de darle ese trabajo, verifica que sea confiable. Dos prácticas ayudan.

1. Califica tú mismo una muestra. Califica a mano un puñado de respuestas guardadas y compara tus calificaciones con los veredictos del juez, porque un juez debería coincidir de cerca con expertos humanos. Donde tú y el juez discrepen, aclara más la rúbrica y vuelve a ejecutarla.
2. Usa un juez que no haya escrito las respuestas. Por lo general, es mejor calificar con un modelo diferente al que escribió la salida.

En resumen

1. Califica con código donde funcione una verificación exacta, con un juez donde dos oraciones diferentes puedan ser correctas, y con personas donde dependa del juicio.
2. Anota las respuestas esperadas antes de que se ejecute cualquier modelo, y construye un conjunto de casos que se parezca a la producción.
3. Dale al juez una rúbrica, un esquema con el que su veredicto tenga que coincidir, y la opción de decir unknown.
4. Califica a mano una muestra del trabajo del juez antes de confiar en él.