# Sin una eval, ajustas a ojo Curso exprés sobre cómo evaluar sistemas de IA. 24 conceptos — eval, golden set, eval criteria, faithfulness y correctness, LLM-as-judge, trajectory evaluation, evals offline y online, drift, CI gate, ley de Goodhart y más — cada uno con su nombre en inglés, un diagrama, un ejemplo y una ficha. Al final, una hoja de referencia de una página con todos los conceptos. La esencia: no puedes mejorar lo que no mides, y llegar al 95% es casi todo el trabajo. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~35 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/evals-express --- ## 1. Por qué existen las evals 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. ### 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_. _Diagram: Las bases arriba; debajo, seis grupos — los capítulos 2–7 los siguen._ ### 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. _Diagram: Código normal: una entrada, una salida, aserción. Un LLM: una entrada, respuestas distintas — así que las puntúas en lugar de comparar con una cadena._ #### Eval (evaluación de un sistema de IA) - **Problema:** Un LLM es no determinista: `output === expected` falla, y «correcto» es una cualidad. - **Idea:** Un conjunto de entradas + una forma de puntuar cada salida + una ejecución en cada cambio. - **Ejemplo:** Cien preguntas para un bot de soporte, cada una con una señal de buena respuesta; resultado: «84% aprobadas». - **Coste:** Tiempo para reunir casos y construir formas de puntuarlos. - **Cuándo usarlo:** Cualquier función con un LLM en la cadena. - **Relaciones:** Se apoya en un **golden set**, la puntúan **graders**, se ejecuta en un **CI gate**. ### 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. _Diagram: El prompt nuevo arregla el caso que miraste y rompe en silencio otros tres. Mirar a ojo no lo ve._ #### Tuning by Vibes (ajuste a ojo) - **Qué es:** Cambiar el prompt, mirar unas pocas salidas y lanzar si «se siente mejor». - **Por qué es malo:** Las regresiones son invisibles: arreglas un caso y rompes tres. - **Ejemplo:** «Parece mejor» en lugar de «84% frente a 79%». - **Remedio:** Incluso una **eval** pequeña, ejecutada antes y después del cambio. - **Relaciones:** Lo opuesto a **Eval-driven Development**. ### 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. _Diagram: Hasta el 80% es una subida rápida en una tarde. Del 80% al 95% es el trabajo largo, caso por caso._ #### The Last Mile (80% → 95%) - **Qué es:** El primer 80% de calidad llega rápido; el 15% restante es casi todo el trabajo. - **Por qué:** El resto son entradas límite y fallos raros, que se encuentran de uno en uno. - **Ejemplo:** Una demo de una tarde funciona; el producto encima de ella lleva semanas. - **Consecuencia:** Sin medición, esta subida es invisible e ingobernable. - **Relaciones:** La hacen visible la **eval**, los **hard cases** y el **slicing**. ### 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. _Diagram: Cualquier cambio — prompt, modelo, pipeline — pasa por la misma eval y muestra enseguida si ayudó o perjudicó._ > **La pregunta de encuadre:** «Cuando cambio este prompt o este modelo, ¿cómo sé — con un número, no con una sensación — si mejoró o empeoró?» > 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 conjetura. ## 2. Qué medir «¿Es bueno?» no se puede medir. El primer trabajo real de las evals es convertir esa pregunta vaga en cosas concretas que sí puedas puntuar — elegidas para que encajen con el trabajo de tu función. ### 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. _Diagram: El vago «¿es bueno?» se divide en comprobaciones concretas, cada una con su puntuación._ #### Eval Criteria (propiedades medibles) - **Problema:** «¿Es bueno?» no se puede medir ni optimizar. - **Idea:** Dividir la calidad en propiedades: corrección, fundamentación, formato, uso de herramientas, longitud y tono. - **Ejemplo:** «El JSON cumple el esquema», «la respuesta se apoya en el documento recuperado». - **Coste:** Tienes que decidir qué importa — y descartar el resto con honestidad. - **Relaciones:** Elegir criterios son las **task-specific metrics**; los **graders** los comprueban. ### 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. _Diagram: El tipo de función fija la métrica: RAG, clasificador, agente y resumen necesitan cada uno una vara distinta._ #### Task-specific Metrics (métricas a medida del trabajo) - **Problema:** Una métrica única para todo mide algo distinto de lo que se rompe. - **Idea:** La métrica refleja lo que significa fallar en esta función concreta. - **Ejemplo:** RAG — fragmentos correctos y fidelidad; clasificador — exactitud; agente — herramientas y objetivo. - **Coste:** Hay que pensar las métricas función por función. - **Relaciones:** Concreta los **eval criteria**; los agentes añaden la **trajectory**. ### 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. _Diagram: Dos ejes dan cuatro resultados. Cada uno señala un lugar distinto donde arreglar: recuperación, fundamentación o ambos._ #### Faithfulness vs Correctness (fundamentado vs correcto) - **Qué es:** Correctness — la respuesta es correcta. Faithfulness — viene del contexto dado, sin invención. - **Por qué importa:** Los distintos fallos se arreglan en lugares distintos. - **Ejemplo:** Fiel pero errónea — arreglar los datos o la recuperación. Correcta pero no fiel — arreglar la fundamentación. - **Ojo:** Una sola puntuación global de «calidad» mezcla ambas y oculta la causa. - **Relaciones:** El par de métricas clave para **RAG**; suele puntuarlo un **LLM-as-judge**. ### 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. _Diagram: Un 85% global parece bien hasta que lo cortas: 100% en los casos fáciles, 40% en los que importan._ #### Slicing (desglose por segmento) - **Problema:** Un promedio borra los casos donde el sistema realmente falla. - **Idea:** Puntuar por separado según categoría, dificultad y modo de fallo. - **Ejemplo:** 85% global = 100% en fáciles + 40% en difíciles. - **Coste:** Los casos del conjunto necesitan etiquetas de categoría. - **Relaciones:** Muestra adónde ir en la **last mile**; depende de un **golden set** etiquetado. > **La pregunta de la medición:** «¿Qué propiedades concretas y puntuables definen una buena salida aquí — y corresponden de verdad a lo que cuesta el fallo a mis usuarios?» > «¿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 único número agregado. ## 3. Construir el conjunto de eval Una eval es tan honesta como los ejemplos que contiene. El dataset — las entradas y sus resultados conocidos como buenos — es el verdadero activo, y aquí se va la mayor parte del cuidado. ### 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. _Diagram: Un golden set es una tabla: una entrada real y su resultado conocido como bueno. Cada cambio se puntúa contra ella._ #### Golden Set (dataset de eval) - **Problema:** Sin referencia, las salidas se califican según el humor. - **Idea:** Entradas representativas, cada una con una buena respuesta o un criterio de éxito claro. - **Ejemplo:** «Cancela mi suscripción» → debe llamar a `cancel_subscription`; «asdf??» → una pregunta aclaratoria. - **Coste:** Trabajo real: decidir qué significa «correcto» en cada caso. - **Relaciones:** Lo llenan los **hard cases** y el **production sampling**; lo ejecuta la **offline eval**. ### 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. _Diagram: Un conjunto halagador son solo entradas típicas. Uno honesto añade casos ambiguos, límite, adversariales y bugs del pasado._ #### Hard Cases (casos límite, adversariales, de regresión) - **Problema:** Un conjunto de casos fáciles da una puntuación bonita e inútil. - **Idea:** Añadir a propósito lo ambiguo, lo límite, lo adversarial y todo lo que ya se rompió. - **Ejemplo:** Un bug llegó a producción → su entrada se convierte en un caso permanente del conjunto. - **Coste:** La puntuación baja — pero se vuelve honesta. - **Relaciones:** Parte del **golden set**; se obtienen mediante **production sampling**. ### 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. _Diagram: Usuarios → logs y feedback → elegir casos, sobre todo fallos → golden set._ #### Production Sampling (casos del uso real) - **Problema:** Los ejemplos inventados reflejan lo que piensas, no lo que hay. - **Idea:** Tomar entradas de logs y feedback, sobre todo donde algo salió mal. - **Ejemplo:** Una formulación desordenada de un usuario que jamás se te habría ocurrido. - **Coste:** Necesitas logs, y los datos de usuario deben limpiarse de datos personales. - **Relaciones:** Alimenta el **golden set**; las señales vienen del **user feedback**. ### 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. > **La pregunta del dataset:** «¿Mi conjunto de eval incluye los casos difíciles, raros y ya rotos — o solo los fáciles que halagan la puntuación?» > El golden set 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. ## 4. Cómo calificar Cuando ya tienes entradas y expectativas, necesitas una forma de puntuar cada salida. Los métodos van de lo barato y exacto a lo flexible y falible — y recurres al más barato que encaje. ### 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. _Diagram: La escalera de graders: barato y exacto a la izquierda, flexible, caro y falible a la derecha. Usa el escalón más bajo que encaje._ #### Code-based Grader (comprobación determinista, coincidencia exacta) - **Problema:** El criterio es caro y discutible donde bastaría con comparar. - **Idea:** Comprobar la salida en código: coincidencia, regex, esquema, la llamada correcta. - **Ejemplo:** La etiqueta de clase coincide; el JSON pasa el esquema; el agente llamó a la herramienta correcta. - **Coste:** Solo sirve para salidas acotadas — así no puedes calificar un ensayo. - **Relaciones:** El primer escalón; para salidas difusas — **LLM-as-judge**; para agentes — **step-level checks**. ### 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. _Diagram: El juez recibe la salida, el contexto y la rúbrica — y devuelve una puntuación con un motivo breve._ #### LLM-as-Judge (modelo como evaluador) - **Problema:** Las salidas abiertas no se pueden comparar con una cadena, y los humanos no escalan a miles. - **Idea:** Un segundo modelo puntúa la salida frente al contexto y una rúbrica explícita. - **Ejemplo:** «¿Es el resumen fiel a la fuente? Puntúa de 1 a 5 y explica en una frase.» - **Coste:** El propio juez se equivoca y tiene sesgos — hay que comprobarlo. - **Relaciones:** No es fiable sin **judge validation**; a menudo mide la **faithfulness**. ### 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. _Diagram: Humanos y juez califican la misma muestra. Si coinciden, se puede confiar en el juez. Vigila sus sesgos habituales._ #### Judge Validation (comprobar al juez frente a humanos) - **Problema:** Un juez prefiere respuestas largas y seguras y puede alejarse de tu intención. - **Idea:** Comparar las puntuaciones del juez con las humanas en una muestra antes de confiar en él. - **Ejemplo:** Unas docenas de casos calificados por personas; el juez coincide — así que se puede confiar en él. - **Coste:** Algo de etiquetado manual, y una nueva comprobación cada vez que cambie el juez o la rúbrica. - **Relaciones:** El compañero obligatorio del **LLM-as-judge**; usa la **human review**. ### 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. #### Human Review (revisión manual puntual) - **Problema:** Las puntuaciones automáticas pueden divergir en silencio de la calidad real. - **Idea:** Leer con regularidad una muestra de salidas reales, sobre todo los fallos. - **Ejemplo:** Una vez por semana, leer los casos donde bajó la puntuación y comprobar que estás de acuerdo. - **Coste:** Tiempo de personas — así que en dosis pequeñas, no en cada caso. - **Relaciones:** El último escalón de la escalera de graders; la base de la **judge validation**. > **La pregunta de la calificación:** «¿Es cada comprobación el método fiable más barato para lo que mide — y si un modelo hace de juez, ¿he verificado al juez frente a decisiones humanas?» > Califica de forma determinista donde puedas, usa un juez LLM para el resto difuso — y valida al juez, porque un evaluador sin comprobar es solo otra conjetura. ## 5. Evals a nivel de paso para agentes Los agentes necesitan más que una nota a la respuesta final, porque pueden llegar a una respuesta limpia por un proceso roto. Para confiar en un agente, mides el viaje, 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 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. _Diagram: El error ocurrió en el paso «Extract», pero el resumen es fluido — y una comprobación solo de la salida final lo deja pasar._ ### 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. _Diagram: Comprobar cada paso muestra exactamente dónde se rompió. Una comprobación solo final ve solo el último recuadro._ #### Trajectory Evaluation (calificar el camino de un agente) - **Problema:** Un final correcto puede esconder pasos erróneos. - **Idea:** Puntuar cada paso: herramienta, argumentos, contexto recuperado, razonamiento. - **Ejemplo:** Los pasos 1–2 son correctos; en el paso 3 el agente tomó el contexto equivocado — la eval señala el paso 3. - **Coste:** Hay que registrar y etiquetar los pasos, no solo la respuesta. - **Relaciones:** Se compone de **step-level checks**; la complementan las **operational metrics**. ### 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. #### Step-level Checks (comprobaciones de llamadas a herramientas) - **Qué es:** Comprobaciones en código sobre pasos concretos del agente, sin juez. - **Cómo funciona:** Verificar qué herramienta se llamó, con qué argumentos, qué documento se recuperó. - **Ejemplo:** Se llamó a `send_email`, el destinatario es correcto, no se excedió ningún permiso. - **Ventaja:** Barato, exacto, y apunta directo al paso que falla. - **Relaciones:** **Code-based graders** aplicados a la **trajectory**. ### 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. _Diagram: Las dos ejecuciones dieron la respuesta correcta. Pero una tardó tres pasos y la otra veinte, con bucles y reintentos._ #### Operational Metrics (pasos, bucles, latencia, coste) - **Problema:** Una puntuación de la respuesta final no ve lo que costó la respuesta. - **Idea:** Contar pasos, bucles y reintentos, latencia y coste por tarea. - **Ejemplo:** La respuesta correcta en 20 pasos caros donde bastaban tres. - **Coste:** Cada ejecución necesita trazado. - **Relaciones:** Complementa la **trajectory evaluation**; en producción la vigila la **online eval**. > **La pregunta del nivel de paso:** «¿Estoy comprobando cómo llegó este agente a su respuesta — las herramientas, las recuperaciones, los pasos — o solo si la salida final parecía correcta?» > Un agente puede llegar a una respuesta limpia por un proceso roto. Califica la trayectoria — las herramientas, las recuperaciones, los pasos — no solo el destino. ## 6. Offline y online 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 en marcha en producción. Necesitas ambas, porque el mundo no es tu conjunto de pruebas. ### 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. _Diagram: A la izquierda del lanzamiento — offline: golden set, puntuar frente a la línea base, puerta. A la derecha — online: tráfico real, muestreo, panel._ #### Offline Eval (eval previa al lanzamiento) - **Problema:** Necesitas saber que un cambio es seguro antes de que lo vean los usuarios. - **Idea:** Ejecutar el golden set en la versión nueva y comparar con la línea base. - **Ejemplo:** Prompt nuevo: 84% frente al 79% del anterior — seguro para lanzar. - **Coste:** Solo ve lo que hay en el conjunto — el mundo es más ancho. - **Relaciones:** Se ejecuta sobre el **golden set**; la automatiza el **CI gate**; va en pareja con la **online eval**. ### 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. _Diagram: Las salidas en vivo pasan por muestreo y puntuación hasta métricas de calidad que vigilas._ #### Online Eval (monitorización de calidad en producción) - **Problema:** Los usuarios y entradas reales no coinciden con el conjunto de pruebas. - **Idea:** Muestrear salidas en vivo, puntuarlas y vigilar las métricas. - **Ejemplo:** Una porción de las respuestas de producción pasa por el juez; el resultado va a un panel. - **Coste:** Infraestructura de puntuación en producción y el coste del juez sobre el tráfico. - **Relaciones:** Atrapa el **drift**; recoge **user feedback**; encuentra nuevos **hard cases**. ### 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. _Diagram: Un ciclo cerrado: la producción da señales, los fallos se vuelven casos, el conjunto protege el próximo lanzamiento._ #### User Feedback Signals (feedback implícito y explícito) - **Qué es:** Pulgar arriba/abajo, correcciones, reintentos, abandono, escalados. - **Por qué:** Una calificación gratuita y continua de quienes de verdad lo usan. - **Ejemplo:** Un pico de reintentos tras un lanzamiento es una alerta temprana. - **Ojo:** Las señales son ruidosas: un motivo para mirar, no una puntuación ya hecha. - **Relaciones:** Parte de la **online eval**; se convierte en **hard cases** del **golden set**. ### 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. _Diagram: La calidad se desliza en silencio tras una actualización del proveedor y un cambio de uso. Un umbral lo atrapa antes que las quejas._ #### Drift (deriva de calidad) - **Qué es:** Una caída lenta y silenciosa de calidad sin cambios de tu parte. - **Causas:** Una actualización del modelo del proveedor, datos que cambian, nuevos patrones de uso. - **Ejemplo:** Un poco peor cada semana — hasta que llega una queja antes que el panel. - **Remedio:** Seguir la calidad en el tiempo y fijar un umbral de alerta. - **Relaciones:** Lo atrapa la **online eval**; los fallos nuevos van al **golden set**. > **La pregunta online:** «Cuando esto se lance, ¿cómo sabré si baja su calidad en el mundo real — por una métrica que vigilo o por la queja de un cliente?» > Las evals offline controlan el lanzamiento; las online vigilan la realidad. La primera demuestra que un cambio es seguro, la segunda te dice qué está pasando de verdad. ## 7. Hacerlo bien Las evals son una práctica, no algo de una sola vez. La destreza está en empezar antes de sentirte listo, meter la medición en el ciclo y no dejar que el número se convierta en una meta que te miente. ### 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. #### Eval-driven Development (primero la eval, luego ajusta) - **Problema:** El prompt se retoca durante semanas; la eval es «luego, quizá». - **Idea:** Una eval pequeña antes de la primera optimización; cada cambio se mide. - **Ejemplo:** Diez casos hoy, ejecutados antes de cada edición del prompt. - **Coste:** Una hora al principio, cuando todavía nada «funciona». - **Relaciones:** El remedio contra el **tuning by vibes**; crece hasta un **CI gate**. ### 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. _Diagram: Cada cambio ejecuta la eval. Puntuación igual o superior al umbral — se lanza; si baja — bloqueado._ #### CI Gate (eval como puerta de CI) - **Problema:** Una eval ejecutada «cuando alguien se acuerda» no atrapará un prompt un poco peor. - **Idea:** Ejecutar en cada cambio; una puntuación bajo el umbral bloquea el lanzamiento. - **Ejemplo:** Un PR que edita un prompt no puede fusionarse hasta que la eval pase. - **Coste:** Tiempo y dinero para ejecutar el conjunto en cada PR. - **Relaciones:** Automatiza la **offline eval**; atrapa regresiones antes de producción. ### 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. _Diagram: La puntuación de la eval sube con cada iteración mientras el valor real se ha estancado. La brecha es el overfitting al conjunto._ #### Goodhart's Law (la medida se convierte en el objetivo) - **Qué es:** Cuando una medida se convierte en objetivo, deja de ser una buena medida. - **Cómo se nota:** El prompt se ajusta a los casos de la eval: la puntuación sube, la calidad no. - **Ejemplo:** +10 puntos en el conjunto, y los usuarios no notan diferencia. - **Defensa:** Casos held out, fallos frescos de producción, recordar que la puntuación es un proxy. - **Relaciones:** Se contrarresta con **production sampling** y **human review**. ### 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. _Diagram: El ciclo de la eval: criterios → conjunto → graders → puerta → online → casos nuevos → de vuelta al conjunto._ #### Antes de lanzar una función de IA - **¿Hay una eval siquiera** — un conjunto de entradas con una forma de puntuar las salidas? - **¿Las métricas encajan con el trabajo**, desglosadas por dificultad y tipo de fallo, y no una sola puntuación plana? - **¿Incluye el conjunto** los casos difíciles, raros y ya rotos, sacados del uso real? - **¿Es la calificación el método fiable más barato** — determinista donde se pueda, un juez validado donde no? - **En los agentes, ¿se califican los pasos**, no solo la respuesta final? - **¿Se ejecuta en CI**, y cómo medirás la calidad una vez en producción? #### Señales de que vuelas a ciegas - Ajustar prompts **leyendo unas pocas salidas** y lanzar cuando se siente mejor. - Una **única puntuación agregada** sin desglose por tipo de caso o dificultad. - Un conjunto de eval con solo entradas **fáciles y típicas** — sin casos límite ni fallos pasados. - Un **juez LLM que nunca validaste** frente a calificaciones humanas. - **Sin monitorización en producción** — te enterarías de una caída de calidad por una queja. #### Señales de que lo hiciste bien - Un **golden set** de entradas reales con resultados conocidos como buenos, concentrado en los casos difíciles. - Métricas que **encajan con 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 un **CI gate**, y una regresión añade un caso en lugar de colarse. - **Medición online y user feedback** devuelven los fallos nuevos al conjunto. ## Hoja de referencia: los 24 conceptos ### Bases - **Eval** (evaluación): Entradas + una forma de puntuar la salida + una ejecución en cada cambio. - **Tuning by Vibes** (ajuste a ojo): Mirar unas pocas salidas y lanzar. Las regresiones quedan invisibles. - **The Last Mile** (80% → 95%): 80% en una tarde; el 95% es casi todo el trabajo, caso por caso. ### Qué medir - **Eval Criteria** (propiedades medibles): «Bueno» dividido en propiedades concretas y comprobables. - **Task-specific Metrics** (métrica a medida del trabajo): RAG, clasificador, agente, resumen — cada uno tiene su propia vara. - **Faithfulness vs Correctness** (fundamentado vs correcto): ¿Viene del contexto — y es correcto? Mídelos por separado. - **Slicing** (desglose): Puntuar por categoría y dificultad: un promedio esconde los fallos. ### El conjunto de eval - **Golden Set** (dataset de eval): Entradas reales con resultados conocidos como buenos. El activo central. - **Hard Cases** (límite, adversarial, de regresión): Lo difícil, lo raro y lo ya roto — en el conjunto a propósito. - **Production Sampling** (casos de producción): Entradas de logs y feedback, sobre todo los fallos. ### Cómo calificar - **Code-based Grader** (comprobación determinista): Coincidencia, regex, esquema, la llamada correcta. Barato y exacto. - **LLM-as-Judge** (modelo como evaluador): Un segundo modelo puntúa lo difuso frente a una rúbrica. - **Judge Validation** (comprobar al juez): Comparar al juez con humanos antes de confiar en él. - **Human Review** (revisión manual puntual): Una dosis pequeña y regular de leer salidas reales. ### Agentes - **Trajectory Evaluation** (calificar el camino): Puntuar cada paso, no solo la respuesta final. - **Step-level Checks** (comprobaciones de llamadas): Comprobaciones en código de llamadas a herramientas, argumentos y recuperaciones. - **Operational Metrics** (pasos, latencia, coste): Cuántos pasos, bucles, segundos y dólares costó una tarea. ### Offline y online - **Offline Eval** (previa al lanzamiento): El golden set sobre la versión nueva — la puerta antes de lanzar. - **Online Eval** (en producción): Muestrear salidas en vivo, puntuarlas, vigilar métricas de calidad. - **User Feedback Signals** (señales de usuarios): Pulgares, ediciones, reintentos, abandono — una señal de eval gratuita. - **Drift** (deriva de calidad): La calidad cae en silencio con el tiempo. Solo la monitorización lo atrapa. ### Hacerlo bien - **Eval-driven Development** (primero la eval): Una eval pequeña antes de la primera optimización. - **CI Gate** (eval en CI): La eval en cada cambio; la puntuación baja — lanzamiento bloqueado. - **Goodhart's Law** (la medida se vuelve objetivo): Una medida que se vuelve objetivo deja de medir. La puntuación es un proxy. > Las evals no son una prueba de una sola vez. Son el ciclo — medir, encontrar los fallos, volver a meterlos — que convierte un componente no determinista en algo en lo que puedes confiar y que puedes mejorar. Fin del curso exprés · 7 capítulos · 24 conceptos Después viene la práctica: toma una función de IA y escribe hoy diez casos de eval para ella — entradas reales, resultados conocidos como buenos, una forma de puntuar cada uno — y ejecútalos antes de tu próximo cambio de prompt. Luego añade un caso cada vez que algo se rompa. Pero quédate con una idea por encima de las demás: la demo que funciona una vez es el 80% fácil. Todo lo que la convierte en un producto en el que puedes confiar — la subida al 95%, las regresiones atrapadas, el drift detectado — solo es posible si estás midiendo. Sin una eval, ajustas a ojo; con una, mejorar se vuelve un ciclo que puedes ejecutar.