Medir la calidad: cómo montar una evaluación básica

La mayoría de quienes construyen con modelos de lenguaje miden la calidad de la misma manera: prueban un cambio, miran una o dos salidas y deciden que "se siente mejor". Eso funciona hasta que deja de hacerlo: hasta que tienes dos prompts y ninguna forma de decir cuál es realmente mejor, o lanzas un retoque que arregla un caso y rompe en silencio otros cinco. La solución es una evaluación (eval): una prueba pequeña y repetible que convierte una sensación vaga de calidad en un número que puedes comparar. No necesitas un framework ni una plataforma para empezar. Necesitas un puñado de ejemplos y la disciplina de puntuarlos de la misma forma dos veces. Este recorrido lo construye desde la nada.

Por qué "se siente mejor" fracasa

Juzgar un modelo por una sola salida tiene tres problemas, y cada uno es fatal por sí solo. No generaliza: la demo impresionante no dice nada sobre las siguientes cien entradas. No es repetible: tu impresión depende de qué ejemplo te tocó mirar y del humor que tuvieras. Y no puede detectar regresiones: cuando un cambio mejora un caso y empeora otro, mirar una salida a la vez nunca te mostrará el intercambio. Una evaluación resuelve los tres fijando las entradas, fijando la puntuación y mirando el conjunto entero en lugar de una muestra afortunada.

El objetivo no es un benchmark perfecto y científico. Es algo mejor que las sensaciones: una medición lo bastante honesta como para que, cuando diga que la versión B supera a la versión A, te lo creas.

Paso 1: un conjunto de datos de ejemplos reales

Una evaluación empieza con un conjunto de entradas que representen el trabajo que tu sistema realmente hace. Este es el paso más importante y el que más gente quiere saltarse. De veinte a cincuenta ejemplos bastan para empezar: la calidad importa mucho más que la cantidad. Lo que importa es que sean representativos: extraídos de uso real o realista, cubriendo los casos fáciles, los casos comunes y, sobre todo, los difíciles y raros.

Incluye las entradas peliagudas a propósito. La entrada vacía, la pregunta ambigua, la petición que debería rechazarse, el caso que se rompió la semana pasada. Una evaluación construida solo a partir de ejemplos fáciles informará de que todo va bien justo hasta que un usuario real envíe algo difícil. Tu conjunto de datos es un pequeño museo de las situaciones que te importa acertar, y debería sobrerrepresentar las situaciones que te dan miedo.

Paso 2: decide qué significa "bueno"

Antes de poder puntuar nada, tienes que decir qué es una buena salida para tu tarea, y esto es más difícil y más valioso de lo que suena, porque te obliga a hacer explícito el criterio. Distintas tareas exigen distintas definiciones:

• Las tareas de coincidencia exacta tienen una sola respuesta correcta: una etiqueta de clasificación, un campo extraído, un sí/no. Bueno significa que la salida iguala la respuesta esperada.
• Las tareas estructuradas se preocupan por la forma: JSON válido, los campos requeridos presentes, la forma correcta. Bueno significa que se analiza y se ajusta.
• Las tareas abiertas —resúmenes, explicaciones, borradores— no tienen una sola respuesta correcta. Bueno se define por criterios: ¿es preciso?, ¿se mantiene en el tema?, ¿evita inventar hechos?, ¿tiene la longitud y el tono adecuados?

Escribe tu definición antes de mirar cualquier resultado. Decidir qué significa "bueno" después de ver las salidas es como te convences de la conclusión que querías. La definición es tu vara de medir fija, y una vara que se dobla para encajar con la respuesta no mide nada.

Paso 3: elige cómo puntuar

Con una definición en mano, necesitas un método para aplicarla de forma consistente a cada ejemplo. Hay tres opciones honestas, más o menos en orden de cuánto te cuestan.

Las comprobaciones programáticas son las mejores cuando aplican. Si hay una respuesta correcta o un formato requerido, unas pocas líneas de código pueden comparar la salida con el resultado esperado, o comprobar que el JSON se analiza y tiene los campos correctos. Esto es rápido, gratis, perfectamente repetible y no está sujeto al humor de nadie. Úsalo donde la tarea lo permita.

El juicio humano es el recurso de reserva para el trabajo abierto que se resiste a la comprobación automática. Lees cada salida y la puntúas contra tus criterios escritos. Para mantenerlo honesto, puntúa en una escala simple y definida en lugar de una impresión difusa: incluso "pasa / dudoso / falla" con una regla de una línea para cada uno supera a una corazonada. La trampa es la inconsistencia: la misma persona puntúa la misma salida de forma distinta en una tarde cansada. Escribir los criterios es lo que mantiene firme la puntuación a lo largo de una sesión.

El modelo como juez usa un segundo modelo de lenguaje para puntuar las salidas contra tus criterios, lo que escala el juicio al estilo humano a muchos ejemplos de forma barata. Es genuinamente útil y genuinamente falible: el juez tiene sus propios sesgos y puede ser engañado por respuestas seguras, fluidas y equivocadas. Si lo usas, valídalo: haz que un humano puntúe una muestra y comprueba que el juez está de acuerdo. Un juez que nunca has comprobado es un número en el que no deberías confiar.

Paso 4: ejecútala y lee los fallos

Ahora tienes las piezas: un conjunto de datos, una definición de bueno, un método de puntuación. Ejecuta cada ejemplo por tu sistema, puntúa cada uno y calcula un resumen simple: qué fracción pasó, la puntuación media, como sea que tu método agregue. Ese único número es tu línea base. Por sí solo significa poco; su valor aparece en el momento en que cambias algo y vuelves a ejecutar, porque ahora "se siente mejor" se convierte en "pasó del 71 % al 78 %", y eso es una afirmación que puedes defender.

Pero el número es la mitad más pequeña de la recompensa. La mitad mayor es leer los fallos. Saca cada ejemplo que puntuó mal y busca el patrón: una categoría de entrada que el sistema maneja mal, un error recurrente, un tipo de pregunta que falla de forma consistente. La puntuación agregada te dice si las cosas funcionan; los fallos te dicen qué arreglar. Una línea base que esconde sus fallos es un termómetro sin diagnóstico. Lee siempre el fondo de la distribución, no solo el promedio.

Paso 5: cambia una cosa a la vez

Una evaluación se gana su sustento cuando la usas para comparar. Haz un solo cambio —un prompt distinto, una nueva instrucción, otro modelo— y vuelve a ejecutar el mismo conjunto de datos con la misma puntuación. Si el número sube y ninguna categoría de fallo empeoró, conserva el cambio. Si baja, acabas de cazar una regresión antes que tus usuarios, que es el objetivo entero.

La disciplina es cambiar una variable por ejecución. Cambia tres cosas a la vez y una mejor puntuación no te dice nada sobre cuál ayudó, ni si dos ayudaron mientras la tercera perjudicó. Un cambio, una reejecución, una comparación. Es más lento de lo que parece que debería ser, y es la única forma de que el número siga siendo significativo.

En resumen

Una evaluación básica son cuatro piezas honestas: un conjunto pequeño de ejemplos representativos, una definición escrita de qué significa bueno, una forma consistente de puntuar y el hábito de cambiar una cosa a la vez y volver a ejecutar. Puedes construirla con una hoja de cálculo y una tarde. No será un benchmark perfecto, y no necesita serlo: solo necesita ser mejor que las sensaciones, lo bastante repetible para confiar en ella y lo bastante reveladora para mostrarte dónde se agrupan los fallos. Una vez que "se siente mejor" se convierte en un número que puedes defender, toda decisión posterior se vuelve más fácil y más honesta.