El mapa: 24 conceptos en siete grupos

Un mapa de metro: primero ves las líneas enteras, luego recorres estación por estación.

Primero, tres bases: qué es una eval, por qué ajustar a ojo no funciona y por qué el último 15% de calidad es casi todo el trabajo. Luego seis grupos, uno por capítulo: qué medir, el conjunto de eval, cómo calificar, agentes, offline y online, y hacerlo bien.

Cada concepto que sigue tiene la misma forma: su nombre en inglés (recuérdalo: es el término), una imagen de la vida real, un diagrama y una ficha con campos: problema, idea, ejemplo, coste, cuándo usarlo y relaciones.

Eval — una prueba para algo que adivina

Calificar un ensayo no es como comprobar una suma — no hay una única cadena correcta contra la que comparar, y el mismo prompt produce un ensayo un poco distinto cada vez.

Una prueba normal afirma output === expected. Un LLM es no determinista y abierto: el mismo prompt da un texto que varía, y «correcto» suele ser una cualidad, no una cadena exacta. Así que el modelo de aserción se rompe. Una eval lo reemplaza: un conjunto de entradas, cada una con una forma de puntuar qué tan buena es la salida, ejecutado de forma repetida — pruebas pensadas para un componente que no devuelve lo mismo dos veces.

Tuning by Vibes — la trampa de ajustar a ojo

Un cocinero que nunca prueba el plato, solo retoca la receta y confía — no puede saber si el cambio de anoche ayudó o lo arruinó en silencio.

Sin una eval, ajustas los prompts a ojo: pruebas algo, miras un par de salidas por encima, lo lanzas si se siente mejor. La trampa es que no puedes ver las regresiones: un cambio que arregla un caso a menudo rompe tres que no volviste a revisar. Una eval convierte «se siente mejor» en «sacó 84% frente a 79%», que es la diferencia entre ingeniería y adivinar.

The Last Mile — el 80% es rápido, el 95% es todo el proyecto

El primer borrador de cualquier cosa sale rápido. Convertir un borrador tosco en algo fiable es donde se va el tiempo de verdad.

Esta es la verdad dura que las evals existen para gestionar: una demo que acierta el 80% de las veces lleva una tarde; pulirla de ahí al 95% es casi todo el trabajo. Ese último tramo, la last mile, se encuentra caso por caso — las entradas límite, los fallos raros — y solo puedes encontrarlos y arreglarlos si estás midiendo. La eval es el instrumento que hace visible la larga subida.

Una eval es tu red de regresión y tu especificación

Un arnés de seguridad permite a un escalador intentar un movimiento difícil porque un resbalón no será fatal — hace seguros los cambios audaces.

Cuando tienes una eval, puedes cambiar el prompt, cambiar el modelo o reestructurar el pipeline y ver de inmediato si ayudó o perjudicó. Atrapa las regresiones antes que los usuarios y, sin hacer ruido, se convierte en la especificación real de «cómo es lo bueno» para tu función. Sin ella, cada cambio es una apuesta; con ella, mejorar se vuelve un ciclo que de verdad puedes ejecutar.

Eval Criteria — convierte «bueno» en comprobaciones concretas

Un examen de conducir no pregunta «¿eres buen conductor?» — puntúa cosas concretas: ¿pusiste el intermitente, te mantuviste en el carril, frenaste del todo, aparcaste dentro de las líneas?

La «calidad» es demasiado vaga para optimizarla. Divídela en propiedades medibles — eval criteria: ¿era correcta la respuesta, estaba fundamentada en la fuente, era válido el formato, llamó a la herramienta correcta, tenía la longitud y el tono adecuados? Cada una es algo que puedes puntuar. La destreza está en elegir las pocas propiedades que de verdad importan para tu tarea, no en medirlo todo.

Task-specific Metrics — la métrica según el trabajo

A un traductor se le juzga por fidelidad y fluidez, a un cajero por rapidez y exactitud — vara equivocada, evaluación inútil.

Cada función necesita métricas distintas. Un sistema RAG: ¿recuperó los fragmentos correctos y la respuesta es fiel a ellos? Un clasificador: exactitud frente a etiquetas. Un agente: ¿eligió las herramientas correctas y alcanzó el objetivo? Un resumen: fiel, completo y conciso. Elige métricas que correspondan a lo que realmente significa fallar en tu tarea, o optimizarás un número que no importa.

Faithfulness vs Correctness — dos cosas distintas

Un estudiante puede escribir una respuesta muy bien argumentada que es errónea, o una torpe que es correcta. El estilo y la verdad son puntuaciones separadas.

Dos de las propiedades más importantes se confunden. La correctness (corrección) es si la respuesta es realmente correcta; la faithfulness (fidelidad) es si está respaldada por el contexto dado, sin inventar. Un sistema con fundamento puede ser fiel (usó la fuente) y aun así errar (la fuente estaba mal), o ser correcto y no fiel (acertó por suerte, no por el contexto). Medirlas por separado te dice dónde está el fallo.

Slicing — un solo número oculta demasiado

Una temperatura media «agradable» puede esconder una habitación helada y otra sofocante. El agregado borra los casos que más necesitas ver.

Una puntuación global única es un punto de partida, no el cuadro completo. Desglosa los resultados — slicing — por categoría y dificultad: fáciles frente a difíciles, cada tipo de pregunta, cada modo de fallo — porque un 85% plano puede ser 100% en los casos fáciles y 40% en los que importan. El valor de una eval está en el desglose que te muestra exactamente adónde apuntar a continuación.

Golden Set — entradas con resultados conocidos como buenos

La hoja de respuestas de un profesor — las preguntas emparejadas con cómo se ve una respuesta correcta, para que calificar sea coherente y no caprichoso.

El núcleo de una eval es un golden set: una colección de entradas representativas, cada una con una respuesta conocida como buena o una definición clara de éxito. Contra esto puntúas. Construirlo es trabajo de verdad — es donde fijas qué significa siquiera «correcto» para tu función — y es el activo que hace medible cada cambio futuro.

Hard Cases — cubre los extremos y los fallos conocidos

Un puente se prueba con los camiones más pesados y las peores tormentas, no solo con un coche medio en un día soleado.

Un conjunto con solo entradas fáciles y típicas te da una puntuación halagadora e inútil. Incluye a propósito los hard cases: preguntas ambiguas, edge cases, prompts adversariales y, sobre todo, los fallos que ya has visto. Cada vez que un bug llegue a producción, añádelo a la eval como regression case para que nunca vuelva en silencio. El conjunto debe concentrarse donde el sistema tiene más probabilidades de romperse.

Production Sampling — cosecha ejemplos reales

Las mejores preguntas de prueba salen del examen real que hicieron los alumnos, no de lo que el profesor imaginó que preguntarían.

La fuente más rica de casos de eval es el uso real: lo que los usuarios de verdad preguntaron, sobre todo lo que preguntaron y salió mal. Explora tus logs y el feedback en busca de entradas reales y súmalas al conjunto. Los ejemplos inventados reflejan lo que crees que ocurre; los de producción reflejan lo que sí ocurre, incluidas las formulaciones desordenadas y las peticiones raras que nunca habrías soñado.

Pequeño y afilado gana a grande y rancio

Cincuenta preguntas bien elegidas que sondean los puntos débiles reales te enseñan más que mil al azar que nunca miras de cerca.

No necesitas miles de casos para empezar: unas pocas docenas bien elegidas, que cubran los comportamientos principales y los modos de fallo conocidos, bastan para atrapar la mayoría de las regresiones y guiar el ajuste. Empieza pequeño, mantenlo honesto y hazlo crecer a medida que aprendes dónde se rompe el sistema. Una eval que ejecutas de verdad gana a una enorme que no ejecutas.

Code-based Graders — comprobaciones exactas, basadas en reglas

Corregir un examen tipo test no requiere criterio — la respuesta es correcta o no lo es, y una máquina la califica al instante.

Cuando la salida está acotada, califícala de forma determinista, en código — un code-based grader: coincidencia exacta para una clasificación, una regex o validación de esquema para el formato, ¿llamó a la herramienta correcta? para un agente, ¿es correcto el número? para una extracción. Estas comprobaciones son baratas, rápidas e indiscutibles. Lleva siempre a esta categoría todo lo que puedas de tu eval: es la calificación más fiable que existe.

LLM-as-Judge — un modelo califica lo difuso

Para un ensayo traes a un segundo examinador con una rúbrica clara — criterio, pero guiado por criterios explícitos para que sea coherente.

Para salidas abiertas — ¿es fiel este resumen? ¿es útil esta respuesta? — no hay coincidencia exacta, así que usas un modelo para calificar, LLM-as-judge: le das a un segundo modelo la salida, el contexto y una rúbrica clara, y le pides que puntúe. Escala un juicio parecido al humano a miles de casos. Es la herramienta estándar para cualidades que no puedes comprobar con una regla — pero viene con salvedades.

Judge Validation — al juez también hay que juzgarlo

Un segundo árbitro puede tener sesgos — favorecer la respuesta más larga o la que suena segura — así que compruebas al árbitro con unas cuantas decisiones humanas antes de fiarte de él.

Un juez LLM tiene modos de fallo: puede preferir respuestas largas (verbosity bias), dejarse llevar por un tono seguro o alejarse de tu intención. Por eso valida al juez frente a calificaciones humanas en una muestra, dale una rúbrica afilada con ejemplos y mantenlo simple. Un juez que no has comprobado es solo otro modelo sin medir — no te fíes de sus puntuaciones hasta confirmar que siguen lo que de verdad te importa.

Human Review — humanos en el ciclo, en dosis pequeñas

Aunque la calificación sea automática, un cocinero igualmente prueba la comida — una comprobación rápida de que los instrumentos no se han descalibrado en silencio.

La calificación automática escala, pero de vez en cuando lee tú mismo las salidas reales — human review. Revisa una muestra, mira con atención los fallos y comprueba que tus métricas aún reflejan la calidad real. La revisión humana no escala a todos los casos, pero una dosis pequeña y regular atrapa lo que tus puntuaciones automáticas pasan por alto — y evita que optimices un número que se ha alejado de la realidad.

Una respuesta final limpia puede esconder un medio roto

Un examen de matemáticas calificado solo por el número final aprueba al alumno que llegó a él con dos errores que se cancelan — no aprendes nada de lo que pasó de verdad.

En un agente de varios pasos, un error intermedio puede pasar la comprobación de la salida final y a la vez corromper el proceso: recupera la fuente correcta, atribuye mal un dato a mitad de camino y escribe un resumen limpio que es erróneo. Si solo calificas la respuesta final, lo dejas pasar. Los fallos que más necesitas atrapar son justo los que una comprobación solo del destino ve peor.

Trajectory Evaluation — califica el camino

Un examinador de conducir observa todo el trayecto — cada señal, cada mirada al espejo, cada cambio de carril — no solo si llegaste a la dirección.

En los agentes evalúas la trajectory (trayectoria): en cada paso, ¿eligió la herramienta correcta, pasó los argumentos correctos, recuperó el contexto correcto y razonó con solidez? Esto atrapa el medio roto que una comprobación final se pierde, y te dice qué paso falló — mucho más útil que saber solo que el final estaba mal. En los pasos es donde la fiabilidad de un agente se gana o se pierde.

Step-level Checks — comprueba directamente las llamadas a herramientas y las recuperaciones

Auditar a un asistente de investigación es comprobar qué fuentes sacó de verdad y qué llamadas hizo — no solo leer su memorando final.

Buena parte del comportamiento de un agente es concreto y se puede calificar sin criterio: ¿llamó a send_email cuando debía, con el destinatario correcto? ¿recuperó el documento relevante? ¿se mantuvo dentro de los permisos de sus herramientas? Son comprobaciones deterministas sobre los pasos — step-level checks, baratas y exactas, y precisan una gran parte de los fallos de los agentes.

Operational Metrics — mide también las verdades aburridas

A un servicio de reparto no solo se le juzga por si el paquete llegó, sino por cuánto tardó, cuántos intentos hizo y cuánto costó.

Más allá de la corrección, sigue las operational metrics de un agente: cuántos pasos dio, con qué frecuencia entró en bucle o reintentó, la latency y el coste por tarea. Un bucle que llega a la respuesta correcta en veinte pasos caros cuando bastaban tres es un problema de fiabilidad y de coste que tu puntuación de la respuesta final no mostrará. Estos números revelan agentes que funcionan pero no sobrevivirán en producción.

Offline Eval — la puerta antes de lanzar

Una pista de pruebas donde pones a un coche a prueba antes de que lleve a un solo pasajero — controlada, repetible, antes del lanzamiento.

La offline eval es tu golden set, ejecutado contra un cambio antes de lanzarlo: ¿puntuó mejor este prompt o modelo nuevo en los casos que seleccionaste? Es controlada y repetible, el lugar donde atrapas regresiones y comparas opciones con seguridad. Esta es la eval que conectas al ciclo de desarrollo — idealmente como una puerta en CI para que no salga nada que baje la puntuación.

Online Eval — medir el mundo real

Por buena que sea la pista de pruebas, sigues vigilando los coches cuando están en carreteras reales — porque las carreteras reales tienen baches que la pista nunca tuvo.

La producción se comporta de maneras que ningún conjunto offline predice del todo: los usuarios reales formulan cosas que no imaginaste y la distribución de entradas cambia. Así que mides también online — una online eval: muestrear y puntuar salidas en vivo, vigilar métricas de calidad y recoger señales de usuarios. El conjunto offline demuestra que un cambio es seguro para lanzar; la medición online te dice qué está pasando de verdad una vez que está fuera.

User Feedback — una señal de eval gratuita

Un botón de «me gusta» y un buzón de quejas son una encuesta continua y gratuita sobre si la cosa de verdad funciona para quienes la usan.

Tus usuarios te están calificando, la recojas o no. Captura las user feedback signals — pulgar arriba/abajo, correcciones, reintentos, abandono, escalados — y devuélvelas al sistema. Un pico de reintentos o de pulgares abajo es una alerta temprana; los fallos concretos se convierten en los casos de eval de mañana. Esto cierra el ciclo: la producción enseña al conjunto de eval cómo es la realidad, y el conjunto de eval protege el próximo lanzamiento.

Drift — vigila el deterioro lento

Una báscula se va descalibrando poco a poco — nada dramático, solo cada lectura un poco más errada hasta que un día los números están mal.

Un sistema que puntuaba bien puede degradarse en silencio — eso es el drift: un proveedor actualiza el modelo, tus datos cambian, cambian los patrones de uso. Sin medición online continua, te enteras por usuarios enfadados en lugar de por un panel. Sigue la calidad en el tiempo para que el drift aparezca como una tendencia sobre la que puedes actuar, no como una sorpresa. La eval no es una puerta de una sola vez; es una constante vital que sigues leyendo.

Eval-driven Development — primero la eval, luego ajusta

Calibras el termómetro antes de empezar a ajustar el horno — si no, cada ajuste es una conjetura disfrazada de progreso.

El error común es retocar el prompt sin fin y construir una eval solo después, quizá. Dale la vuelta: escribe una eval pequeña antes de optimizar, para que cada cambio se mida desde el principio — eso es el eval-driven development. Incluso diez casos son mejor que cero. Ajustar sin una eval se siente productivo y casi nunca lo es: mueves números que no ves.

CI Gate — haz de la eval una puerta en CI

El código no se fusiona si fallan las pruebas — y la misma disciplina evita que un prompt un poco peor llegue a los usuarios.

Cuando ya tienes una eval, ejecútala automáticamente en cada cambio y bloquea el lanzamiento si la puntuación cae por debajo de un umbral — un CI gate. Esto convierte las evals de algo que haces cuando te acuerdas en una barandilla siempre activa — el equivalente en IA de una suite de pruebas en verde. «Sin evals no se lanza» es el estándar que vale la pena mantener: un cambio sin medir en una función de IA es un despliegue sin probar.

Goodhart's Law — no dejes que la métrica se convierta en el objetivo

Enseñar solo para el examen produce alumnos que sacan sobresaliente y no saben hacer el trabajo — la nota subió, lo que medía no.

Cuando una medida se convierte en objetivo, deja de ser una buena medida — la ley de Goodhart. Puedes hacer overfitting de los prompts a tus casos de eval y ver subir la puntuación mientras la calidad real se estanca. Defiéndete: reserva algunos casos held out, renueva el conjunto con nuevos fallos de producción y recuerda que la eval es un proxy del valor para el usuario, no el valor en sí. Un número que sube y que los usuarios no notan es una advertencia, no una victoria.

Empieza pequeño, crece con los fallos

Una buena suite de pruebas no se escribe de golpe — se acumula, un caso por bug, hasta que cubre en silencio todo lo que alguna vez salió mal.

No esperes a una eval perfecta y completa: nunca lanzarás. Empieza con un puñado de casos para el comportamiento central y añade uno cada vez que algo se rompa. Con el tiempo el conjunto crece justo a lo largo de los contornos de donde tu sistema de verdad falla, que es exactamente donde quieres tu cobertura. La eval madura con el producto, y nunca está del todo terminada.

Cómo se conectan los conceptos

Una rueda que sigue girando: cada vuelta vuelve el conjunto más honesto y el lanzamiento más seguro.

Todo en este curso es parte de un solo ciclo. Los criteria dicen qué medir; el golden set dice sobre qué probar; los graders (código, juez, humano) dan la puntuación. La offline eval con un CI gate custodia el lanzamiento, la online eval vigila la realidad — feedback y drift — y los fallos que encuentra se convierten en casos nuevos que vuelven al conjunto. Para los agentes calificas la trajectory, y la ley de Goodhart te recuerda que la puntuación es solo un proxy.