Curso exprés · No. 13
Una función de IA se apoya en un componente no determinista: la misma entrada puede dar salidas distintas, y «se veía bien cuando lo probé» no es una prueba. Una eval es una suite de pruebas para ese componente: entradas conocidas, salidas puntuadas, ejecutadas en cada cambio. Es la disciplina poco glamorosa que separa una demo que esperas que funcione de un producto que sabes que funciona.
Solo lo esencial · Una imagen por idea · Mide, no adivines
Puedes probar con tests unitarios el código corriente porque la misma entrada da la misma salida. Un LLM rompe eso, así que necesitas otro tipo de prueba — y sin ella vuelas a ciegas.
No puedes hacer un test unitario a 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.
El ojo no sobrevive al contacto con el cambio
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.
Llegar al 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 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.
Una vez que tienes una eval, puedes cambiar el prompt, reemplazar el modelo o reestructurar el pipeline y ver de inmediato si ayudó o perjudicó. Atrapa las regresiones antes que los usuarios, y se convierte en silencio en la verdadera especificación de «cómo se ve lo bueno» para tu función. Sin ella, cada cambio es una apuesta; con ella, la mejora se vuelve un bucle que de verdad puedes ejecutar.
No puedes hacer un test unitario a un componente no determinista. Una eval lo puntúa en su lugar — y sin una, cada cambio es una adivinanza.
«¿Es bueno?» no es medible. El primer trabajo real de las evals es convertir esa pregunta vaga en cosas concretas que de verdad puedas puntuar — elegidas para encajar con la tarea que hace tu función.
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, paraste del todo, aparcaste dentro de las líneas?
«Calidad» es demasiado vago para optimizar. Divídelo en propiedades medibles: ¿fue correcta la respuesta, estaba anclada 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 habilidad está en elegir las pocas propiedades que de verdad importan para tu tarea, no en medirlo todo.
Ajusta la métrica a la tarea
Juzgas a un traductor por fidelidad y fluidez, a un cajero por velocidad y exactitud — vara equivocada, evaluación inútil.
Funciones distintas necesitan métricas distintas. Un sistema RAG: ¿recuperó los fragmentos correctos, y es la respuesta fiel a ellos? Un clasificador: exactitud frente a las etiquetas. Un agente: ¿eligió las herramientas correctas y alcanzó la meta? Un resumen: fiel, completo, conciso. Elige métricas que mapeen lo que el fallo de verdad significa para tu tarea, o estarás optimizando un número que no importa.
Fidelidad y corrección son cosas distintas
Un estudiante puede escribir una respuesta bellamente argumentada que está mal, o una torpe que está bien. Estilo y verdad son puntuaciones separadas.
Dos de las propiedades más importantes se confunden. La corrección es si la respuesta es de verdad acertada; la fidelidad es si está respaldada por el contexto provisto sin invención. Un sistema anclado puede ser fiel (usó la fuente) pero estar mal (la fuente estaba mal), o ser correcto pero infiel (acertó por suerte, no a partir del contexto). Medirlas por separado te dice dónde está el fallo.
Un solo número esconde demasiado
Una temperatura media de «agradable» puede esconder una habitación helada y otra sofocante. El agregado borra los casos que más necesitas ver.
Una única puntuación global es un punto de partida, no la foto. Desglosa los resultados por categoría y dificultad — fácil frente a difícil, cada tipo de pregunta, cada modo de fallo — porque un plano 85% 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 dónde apuntar después.
«¿Es bueno?» no es una métrica. Divide la calidad en propiedades concretas y puntuables elegidas para tu tarea — y nunca confíes en un solo número agregado.
Una eval es tan honesta como los ejemplos que contiene. El conjunto de datos — las entradas y sus resultados conocidos como buenos — es el activo real, y la mayor parte del cuidado va aquí.
Un conjunto dorado: 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 la calificación sea consistente y no caprichosa.
El núcleo de una eval es un conjunto dorado: una colección de entradas representativas, cada una con una respuesta conocida como buena o una definición clara de éxito. Esto es contra lo que puntúas. Construirlo es trabajo real — es donde fijas qué significa siquiera «correcto» para tu función — y es el activo que hace medible cada cambio futuro.
Cubre los bordes y los fallos conocidos
Un puente se somete a prueba de estrés con los camiones más pesados y las peores tormentas, no solo con un coche promedio en un día soleado.
Un conjunto de solo entradas fáciles y típicas te da una puntuación halagadora e inútil. Incluye a propósito los casos difíciles: preguntas ambiguas, entradas límite, prompts adversariales y, sobre todo, los fallos que ya has visto. Cada vez que un bug llega a producción, añádelo a la eval para que nunca pueda volver en silencio. El conjunto debe concentrarse en donde el sistema tiene más probabilidad de romperse.
Cosecha ejemplos reales de producción
Las mejores preguntas de prueba vienen del examen que de verdad hicieron los estudiantes, 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 que salió mal. Minería de tus logs y comentarios para extraer entradas reales e incorpóralas al conjunto. Los ejemplos inventados reflejan lo que crees que pasa; los ejemplos de producción reflejan lo que pasa, incluido el fraseo desordenado y las peticiones raras que jamás habrías imaginado.
Pequeño y afilado vence 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 de verdad ejecutas vence a una enorme que no ejecutas.
El conjunto dorado es el activo. Empareja entradas reales con resultados conocidos como buenos, concéntrate en lo difícil y lo roto, y hazlo crecer a medida que aprendes.
Una vez que tienes entradas y expectativas, necesitas una forma de puntuar cada salida. Los métodos van de baratos y exactos a flexibles y falibles — y echas mano del más barato que encaje.
Usa comprobaciones exactas y basadas en reglas donde puedas
Corregir un examen de opción múltiple no necesita juicio — la respuesta está bien o no lo está, y una máquina la califica al instante.
Cuando la salida está acotada, califícala de forma determinista: coincidencia exacta para una clasificación, una regex o comprobació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. Empuja siempre la mayor parte posible de tu eval a esta categoría — es la calificación más fiable que existe.
LLM-as-judge para lo difuso
Para un ensayo traes a un segundo examinador con una rúbrica clara — juicio, pero guiado por criterios explícitos para que sea consistente.
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 haces que puntúe. Escala el juicio al estilo humano a través de miles de casos. Es la herramienta estándar para cualidades que no puedes comprobar con una regla — pero viene con salvedades.
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 contra unas pocas decisiones humanas antes de confiar en él.
Un juez LLM tiene modos de fallo: puede preferir respuestas verbosas, dejarse llevar por un tono seguro o desviarse de tu intención. Así que valida al juez contra calificaciones humanas sobre 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 confíes en sus puntuaciones hasta confirmar que rastrean lo que de verdad te importa.
Mantén a humanos en el bucle, en dosis pequeñas
Incluso con calificación automatizada, un chef sigue probando la comida — una comprobación rápida de que los instrumentos no se han desajustado en silencio.
La calificación automatizada escala, pero periódicamente lee las salidas reales tú mismo. Haz una comprobación puntual de una muestra, mira con atención los fallos y verifica que tus métricas todavía reflejan la calidad real. La revisión humana no escala a cada caso, pero una dosis pequeña y regular atrapa las cosas que tus puntuaciones automatizadas se pierden — y te impide optimizar un número que se ha desviado de la realidad.
Califica de forma determinista donde puedas, usa un juez LLM para el resto difuso — y valida al juez, porque un calificador sin comprobar es solo otra adivinanza.
Los agentes necesitan más que una calificación de la respuesta final, porque pueden llegar a una respuesta limpia a través de un proceso roto. Para confiar en un agente, mides el camino, no solo el destino.
Una respuesta final limpia puede esconder un medio roto
Un examen de matemáticas calificado solo por el número final aprueba al estudiante que llegó a él a través de dos errores que se cancelan — no aprendes nada de lo que de verdad pasó.
En un agente de varios pasos, un error intermedio puede pasar una comprobación de salida final mientras corrompe el proceso — recupera la fuente correcta, atribuye mal un dato a mitad de camino y escribe un resumen limpio que está mal. Califica solo la respuesta final y dejas pasar eso. Los fallos que más necesitas atrapar son justo los que una comprobación de solo destino menos ve.
Califica la trayectoria
Un examinador de conducir observa todo el trayecto — cada intermitente, mirada al espejo y cambio de carril — no solo si llegaste a la dirección.
Para agentes evalúas la 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 accionable que saber solo que el final estaba mal. Los pasos son donde la fiabilidad de un agente de verdad se hace o se pierde.
Comprueba las llamadas a herramientas y las recuperaciones directamente
Auditar a un asistente de investigación significa comprobar qué fuentes sacó de verdad y qué llamadas hizo — no solo leer su informe final.
Gran parte del comportamiento de un agente es concreto y calificable sin juicio: ¿llamó a send_email cuando debía, con el destinatario correcto? ¿recuperó el documento relevante? ¿se mantuvo dentro de sus permisos de herramientas? Estas son comprobaciones deterministas sobre los pasos, baratas y exactas, y fijan con precisión una gran parte de los fallos de agente.
Mide también las aburridas verdades operativas
Un servicio de reparto se juzga no solo 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, rastrea las métricas operativas de un agente: cuántos pasos dio, con qué frecuencia entró en bucle o reintentó, la latencia y el coste por tarea. Un bucle que llega a la respuesta correcta en veinte pasos caros cuando bastarían tres es un problema de fiabilidad y de coste que tu puntuación de respuesta final no mostrará. Estos números revelan agentes que funcionan pero no sobrevivirán a producción.
Un agente puede llegar a una respuesta limpia a través de un proceso roto. Califica la trayectoria — las herramientas, las recuperaciones, los pasos — no solo el destino.
Las evals vienen en dos tipos que hacen trabajos distintos: la suite de pruebas que ejecutas antes de lanzar, y la medición que mantienes corriendo en producción. Necesitas ambas, porque el mundo no es tu conjunto de pruebas.
Evals offline: la puerta antes de lanzar
Una pista de pruebas donde pones un coche a prueba antes de que lleve a un solo pasajero — controlada, repetible, ejecutada antes del lanzamiento.
La eval offline es tu conjunto dorado, ejecutado contra un cambio antes de lanzarlo: ¿puntuó mejor este nuevo prompt o modelo en los casos que curaste? Es controlada y repetible, el lugar donde atrapas regresiones y comparas opciones con seguridad. Esta es la eval que conectas al bucle de desarrollo — idealmente una puerta en CI para que nada que baje la puntuación llegue a lanzarse.
Evals online: medir el mundo real
Por buena que sea la pista de pruebas, sigues monitoreando los coches una vez que están en carreteras reales — porque las carreteras reales tienen baches que la pista nunca tuvo.
La producción se comporta de formas que ningún conjunto offline predice del todo: los usuarios reales frasean cosas que no imaginaste, y la distribución de entradas cambia. Así que mides online también — muestrea y puntúa salidas en vivo, vigila las métricas de calidad y recoge señales de usuario. El conjunto offline prueba que un cambio es seguro de lanzar; la medición online te dice qué está pasando de verdad una vez que está ahí fuera.
Los comentarios de usuario son una señal de eval gratis
Un botón de pulgar arriba y una bandeja de quejas son una encuesta continua y gratuita de si la cosa de verdad funciona para quienes la usan.
Tus usuarios te están calificando lo recojas o no. Captura las señales — pulgar arriba/abajo, correcciones, reintentos, abandonos, escalaciones — y aliméntalas de vuelta. 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 bucle: la producción le enseña al conjunto de eval cómo se ve la realidad, y el conjunto de eval protege el siguiente lanzamiento.
Vigila la deriva
Una balanza se descalibra poco a poco — nada dramático, solo cada lectura un poco más desviada hasta que un día los números están mal.
Un sistema que puntuaba bien puede degradarse en silencio: un proveedor de modelos actualiza, tus datos cambian, los patrones de uso varían. Sin medición online continua, te enteras por usuarios enfadados en vez de por un panel. Rastrea la calidad a lo largo del tiempo para que la deriva aparezca como una tendencia sobre la que puedes actuar, no como una sorpresa. La eval no es una puerta de una sola vez; es un signo vital que sigues leyendo.
Las evals offline controlan el lanzamiento; las evals online vigilan la realidad. La primera prueba que un cambio es seguro, la segunda te dice qué está pasando de verdad.
Las evals son una práctica, no algo de una sola vez. La habilidad está en empezar antes de sentirte listo, conectar la medición al bucle y no dejar que el número se vuelva una meta que te miente.
Primero la eval, luego ajusta
Calibras el termómetro antes de empezar a ajustar el horno — de lo contrario cada ajuste es adivinanza disfrazada de progreso.
El error común es retocar el prompt sin fin y solo más tarde, quizá, construir una eval. Dale la vuelta: escribe una eval pequeña antes de optimizar, para que cada cambio se mida desde el principio. Incluso diez casos vencen a cero. Ajustar sin una eval se siente productivo y mayormente no lo es — estás moviendo números que no puedes ver.
Haz de la eval una puerta de CI
El código no se fusiona si las pruebas fallan — y la misma disciplina impide que un prompt silenciosamente peor llegue a los usuarios.
Una vez que tienes una eval, ejecútala automáticamente en cada cambio, y bloquea el lanzamiento si la puntuación cae por debajo de un listón. Esto convierte las evals de algo que haces cuando te acuerdas en una barrera que siempre está activa — el equivalente en IA de una suite de pruebas que pasa. «Evals o no se lanzó» es el estándar que vale la pena sostener: un cambio sin medir a una función de IA es un despliegue sin probar.
No dejes que la métrica se vuelva el objetivo
Enseñar puramente para el examen produce estudiantes que bordan la prueba y no saben hacer el trabajo — la puntuación subió, lo que medía no.
Cuando una medida se vuelve un objetivo, deja de ser una buena medida — la ley de Goodhart. Puedes sobreajustar los prompts a tus casos de eval concretos y ver subir la puntuación mientras la calidad real se estanca. Protégete: mantén algunos casos apartados, refresca 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 sienten 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 cubrir en silencio todo lo que alguna vez salió mal.
No esperes una eval perfecta y exhaustiva — 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.
- ¿Hay siquiera una eval — un conjunto de entradas con una forma de puntuar las salidas? - ¿Las métricas encajan con la tarea, desglosadas por dificultad y tipo de fallo, no una puntuación plana? - ¿Incluye el conjunto los casos difíciles, raros y previamente rotos, extraídos del uso real? - ¿Es la calificación el método fiable más barato — determinista donde es posible, un juez validado donde no? - Para agentes, ¿se califican los pasos, no solo la respuesta final? - ¿Se ejecuta en CI, y cómo medirás la calidad una vez esté en vivo?
- Ajustar prompts leyendo un par de salidas y lanzar cuando se siente mejor. - Una única puntuación agregada sin desglose por tipo de caso o dificultad. - Un conjunto de eval de solo entradas fáciles y típicas — sin casos límite, sin fallos pasados. - Un juez LLM que nunca validaste contra calificaciones humanas. - Sin monitoreo en producción — te enterarías de una caída de calidad por una queja.
- Un conjunto dorado de entradas reales con resultados conocidos como buenos, concentrado en los casos difíciles. - Métricas que mapean la tarea, puntuadas por el método fiable más barato y desglosadas. - Calificación a nivel de paso para agentes, y un juez validado para las partes difusas. - La eval es una puerta de CI, y una regresión añade un caso en vez de colarse. - Medición online y comentarios de usuario alimentan de vuelta los nuevos fallos al conjunto.
Las evals no son una prueba de una sola vez. Son el bucle — mide, encuentra los fallos, incorpóralos de vuelta — que convierte un componente no determinista en algo en lo que puedes confiar y que puedes mejorar.