Glosario de Evals y evaluación de agentes

Los términos que aparecen una y otra vez en el Curso de Evals y en cualquier conversación sobre medir si un sistema con LLM realmente funciona. Como todo glosario de la academia, crece con cada bloque nuevo del curso.

La idea central

Eval (evaluación) — Una medición del comportamiento de un sistema con LLM sobre un conjunto de casos, que devuelve un número o una distribución en vez de un aprobado/reprobado limpio. A diferencia de un test, no verifica una salida exacta: verifica una propiedad de la salida. Se desarrolla en Por qué los evals.

Test (prueba unitaria) — La verificación clásica de software: entrada fija, salida esperada fija, comparación por igualdad. Asume determinismo, salida única correcta, fallo binario y costo cero por corrida. Un LLM rompe las cuatro suposiciones.

Benchmark (referencia) — Un conjunto público y estandarizado de tareas para comparar modelos entre sí (MMLU, GSM8K, SWE-bench). Sirve para elegir un modelo base, no para saber si tu producto funciona: mide capacidad genérica, no tu caso de uso.

Contaminación de benchmark (contamination) — Cuando las preguntas de un benchmark público terminaron en los datos de entrenamiento del modelo. El puntaje sube sin que la capacidad real suba, y por eso un benchmark envejece rápido como señal de calidad.

Monitoreo (monitoring) — Vigilar métricas agregadas de un sistema en producción: latencia, tasa de error, costo, volumen. Responde “¿está vivo y a qué velocidad?”, no “¿está respondiendo bien?”.

Observabilidad (observability) — La capacidad de reconstruir qué pasó en una ejecución concreta a partir de lo que el sistema dejó grabado. Sin observabilidad no hay evals útiles en producción, porque no se puede volver al caso que falló.

Traza (trace) — El registro completo de una ejecución: entrada, prompts enviados, herramientas llamadas con sus argumentos, observaciones recibidas, salida final, tokens y latencia por paso. Es la materia prima de todo lo demás.

Eval offline — Evaluación sobre un conjunto de casos guardados, corrida antes de desplegar. Es reproducible, tiene respuesta esperada y se puede repetir mil veces. Es el que bloquea despliegues.

Eval online — Evaluación sobre tráfico real en producción, donde no hay respuesta esperada. Mide lo que de verdad está pasando, a costa de perder el ground truth. Se desarrolla en Evals online.

El ciclo offline-online — La idea de que todo fallo detectado en producción se convierte en un caso del dataset offline. Sin esa flecha de vuelta, el dataset offline se congela y deja de representar a los usuarios.

Degradación silenciosa — El fallo típico de un sistema con LLM: no se cae, no lanza excepción, sigue respondiendo, pero cada vez peor. Nadie se entera hasta que alguien reclama semanas después.

No determinismo a temperatura 0 — Aun con temperature=0 el mismo prompt puede dar salidas distintas: el batching agrupa peticiones de forma variable, los kernels de GPU suman en punto flotante en orden no garantizado y el proveedor actualiza el modelo sin avisar. La consecuencia práctica es que un eval necesita repeticiones y márgenes, no igualdad exacta.

Gate (compuerta) — La regla automática que decide si un cambio pasa o se detiene. Una métrica sin gate es un número decorativo: solo hay eval cuando el número puede frenar un despliegue.

Definir el éxito

Criterio verificable — Una afirmación sobre la salida que dos personas distintas pueden juzgar igual, que se puede responder de forma binaria o graduada, y que tiene un dueño. “Que responda bien” no lo es; “que cite al menos una fuente del contexto entregado” sí. Se desarrolla en Definir el éxito.

Rúbrica (rubric) — La escala con la que se juzga una salida, con cada nivel descrito en palabras y no solo numerado. Sin descripción por nivel, dos evaluadores usan escalas distintas con los mismos números.

Métrica objetivo — La que quieres que suba y por la que optimizas: tasa de tareas resueltas, precisión de extracción. Es la que justifica el trabajo.

Métrica guardrail (métrica de guardia) — La que no debe empeorar aunque la métrica objetivo suba: costo por tarea, latencia p95, tasa de alucinación. Existe para que la optimización no compre calidad rompiendo otra cosa.

Umbral (threshold) — El valor a partir del cual la métrica activa una consecuencia. Sin umbral declarado antes de medir, el umbral se ajusta después al resultado.

Ficha de métrica — El documento corto que define cada métrica: qué mide, cómo se calcula, con qué dataset, quién es el dueño, cuál es el umbral, qué se detiene, cada cuánto corre, qué la puede romper y cuándo se revisa. Evita la métrica huérfana que nadie sabe interpretar.

Costo por tarea — Lo que cuesta resolver un caso completo, sumando todas las llamadas al modelo, no una sola. Es la métrica que hace insostenible a un agente que se pasea de más.

Evals deterministas

Pirámide de evals — El orden de preferencia: primero los deterministas (baratos, rápidos, sin ambigüedad), después el juez LLM, y arriba de todo la revisión humana. Muchos equipos parten por el juez y se saltan la base barata. Se desarrolla en El primer eval determinista.

Eval determinista — Verificación con código puro, sin LLM en el medio: parsea, compara, valida. Da siempre el mismo resultado sobre la misma salida y cuesta prácticamente cero.

Validación de esquema (schema validation) — Comprobar que la salida cumple una estructura declarada, típicamente con Pydantic o JSON Schema. Es el eval más rentable que existe: atrapa una familia entera de fallos con tres líneas.

Exact match (coincidencia exacta) — Comparar la salida con la esperada carácter a carácter. Solo sirve para respuestas cortas y cerradas, y siempre acompañada de normalización.

Precision (precisión) — De lo que el sistema afirmó, qué proporción era correcta. Castiga los falsos positivos.

Recall (exhaustividad) — De lo que había que encontrar, qué proporción encontró. Castiga los falsos negativos. Se explica desde el lado de búsqueda en el glosario de RAG.

F1 — La media armónica entre precision y recall. Se usa la armónica y no el promedio simple porque castiga el desbalance: sirve para no premiar a un sistema que gana en una a costa de destruir la otra.

Matriz de confusión — La tabla que cruza clase esperada contra clase predicha. Muestra cuáles categorías se confunden entre sí, que es información accionable, a diferencia de un accuracy solo.

Exactitud de enrutamiento (routing accuracy) — Qué proporción de las veces el sistema eligió la rama, el agente o el flujo correcto. Un error de enrutamiento contamina todo lo que viene después.

Verificación de efectos — Evaluar no la respuesta sino lo que el sistema hizo: qué registro creó, qué archivo escribió, qué correo mandó. Para agentes es más informativa que el texto.

BLEU — Métrica de traducción automática basada en solapamiento de n-gramas. No sirve para evaluar respuestas de un LLM porque una respuesta correcta con otras palabras puntúa bajo.

ROUGE — Métrica de resumen automático, también por solapamiento de n-gramas. Mide superficie léxica, no si el resumen es cierto ni si es útil.

Runner (corredor de evals) — El script que lee los casos, ejecuta el sistema, aplica los checkers, imprime las fallas y devuelve código de salida distinto de cero si algo se rompió. Cabe en 60 líneas y es lo que CI necesita.

El juez LLM y su calibración

LLM-as-judge (juez LLM) — Usar un modelo para puntuar la salida de otro según una rúbrica. Es la única forma escalable de evaluar propiedades subjetivas, y solo vale lo que vale su calibración contra humanos. Se desarrolla en El juez y su calibración; su uso específico para RAG está en el glosario de RAG.

Evaluación pointwise (puntual) — El juez ve una salida sola y le pone nota contra la rúbrica. Es la más barata y la que permite umbrales fijos, pero también la de mayor varianza.

Evaluación pairwise (por pares) — El juez ve dos salidas y elige cuál es mejor. Tiene menos varianza porque comparar es más fácil que puntuar, pero no da un número absoluto: solo un ganador.

Evaluación con referencia — El juez ve la salida y una respuesta de referencia escrita por un humano. Es la más estable de las tres y la más cara de mantener, porque hay que escribir y actualizar las referencias.

Versión ancla (anchor) — Una salida fija y conocida que se usa como segundo elemento en las comparaciones pairwise, para poder seguir una métrica en el tiempo sin perder la ventaja de comparar.

Sesgo de posición (position bias) — La tendencia del juez a preferir sistemáticamente la primera o la segunda opción presentada. Se mide corriendo el mismo par en los dos órdenes y se corrige promediando ambos.

Sesgo de longitud (verbosity bias) — La tendencia a puntuar mejor las respuestas largas, aunque no aporten más. Se controla nombrándolo explícitamente en la rúbrica.

Sesgo de auto-preferencia (self-preference) — La tendencia de un modelo a preferir texto generado por sí mismo o por su misma familia. Es el argumento para que el juez no sea el mismo modelo que se está evaluando.

Calibración del juez — El protocolo para saber si el juez sirve: elegir una muestra, anotarla a mano, correr el juez sobre la misma muestra, medir el acuerdo y corregir la rúbrica hasta que el acuerdo sea suficiente. Sin este paso, el juez es una opinión con formato de número.

Muestreo estratificado — Elegir la muestra a anotar con cuotas por categoría en vez de al azar, para que aparezcan casos difíciles y no solo los frecuentes.

Acuerdo inter-anotador (inter-annotator agreement) — Cuánto coinciden dos evaluadores independientes sobre los mismos casos. Si dos humanos no se ponen de acuerdo, el problema es la rúbrica, no el juez.

Kappa de Cohen (κ) — La medida de acuerdo corregida por azar: κ = (p₀ − pₑ) / (1 − pₑ). Con la mayoría de los casos “buenos”, un 78% de acuerdo bruto puede ser apenas κ = 0.42, es decir acuerdo moderado y no excelente.

Escala de Landis y Koch — La lectura convencional de kappa: menos de 0 nulo, 0–0.20 leve, 0.21–0.40 aceptable, 0.41–0.60 moderado, 0.61–0.80 sustancial, 0.81–1.00 casi perfecto. El objetivo práctico para un juez en producción es κ ≥ 0.6.

Kappa ponderada cuadrática — Variante de kappa para escalas ordenadas, donde equivocarse por un nivel penaliza menos que equivocarse por tres. Es la correcta cuando la rúbrica es 1–5 y no binaria.

Techo humano-humano — El acuerdo entre dos anotadores humanos sobre la misma tarea. Ningún juez LLM debería exigirse por encima de ese techo: si dos personas llegan a κ = 0.65, pedirle 0.9 al juez es pedirle que invente consistencia.

Trayectorias

Trayectoria (trajectory) — La secuencia completa de pasos que un agente dio para llegar a la respuesta: qué pensó, qué herramienta llamó, con qué argumentos y qué observó. Dos agentes con la misma respuesta final pueden tener trayectorias radicalmente distintas en costo y riesgo. Se desarrolla en Evaluar trayectorias.

ReAct (razonar y actuar) — El patrón de agente que alterna pensamiento, acción y observación en un bucle. Es el que produce la trayectoria que se evalúa; su implementación está en Tools y ReAct.

Éxito de tarea (task success) — Si el agente llegó al resultado correcto, sin importar cómo. Es necesaria y no suficiente: un éxito con quince pasos y tres bucles es un problema esperando a escalar.

Eficiencia del camino (path efficiency) — Pasos mínimos necesarios dividido por pasos ejecutados, acotado a 1.0. Un 0.4 significa que el agente hizo más del doble del trabajo necesario.

Tasa de bucles (loop rate) — Proporción de trayectorias donde el agente repite la misma acción con los mismos argumentos sin progreso. Es el síntoma más caro y el más fácil de detectar.

Trayectoria de referencia — La secuencia de pasos que un experto considera correcta para un caso. Es lo que permite comparar sin depender de un juez.

Coincidencia por subsecuencia (in-order) — Exigir que los pasos de referencia aparezcan en ese orden, pero permitir pasos adicionales entre medio. Es el modo por defecto para la mayoría de las tareas.

Coincidencia por conjunto (any-order) — Exigir que los pasos ocurran, sin importar el orden. Correcto cuando los pasos son independientes entre sí.

Atribución del fallo (failure attribution) — Identificar el paso exacto donde la trayectoria se desvió por primera vez. Es la diferencia entre “el agente falló” y “el agente falló porque en el paso 3 llamó a la tool equivocada”.

Firma del paso — Un identificador estable del paso, típicamente el nombre de la herramienta más sus argumentos serializados con claves ordenadas. Es lo que permite detectar repeticiones de forma confiable.

Span — La unidad de una traza distribuida en OpenTelemetry: un paso con inicio, fin, atributos y padre. Permite ver la trayectoria del agente con las mismas herramientas que el resto de la infraestructura, como se muestra en Streaming y observabilidad.

Uso de herramientas

Tool use (uso de herramientas) — La capacidad del modelo de llamar funciones externas con argumentos estructurados. Es donde se concentra el riesgo real de un agente, porque ahí deja de conversar y empieza a actuar. Se desarrolla en Evaluar tool use y el mecanismo base en Cómo funciona un agente.

Tool alucinada — El modelo llama a una herramienta que no existe en el catálogo entregado. El umbral aceptable es cero: cualquier ocurrencia indica un problema de prompt o de catálogo.

Precisión de selección — Proporción de llamadas donde la herramienta elegida es la esperada. Se reporta junto a la matriz de confusión de tools para ver qué se confunde con qué.

Exactitud de argumentos — Si los valores son los correctos, no solo bien formados. Se evalúa con tolerancia declarada por campo: un identificador exige igualdad exacta, un texto libre no.

Recuperación tras error — Qué hace el agente cuando una herramienta devuelve un error. Los comportamientos aceptables son reintentar, corregir y reintentar, cambiar de estrategia o rendirse informando; el prohibido es inventar el resultado.

Tasa de recuperación — Proporción de errores de herramienta tras los cuales el agente igual completó la tarea. Mide robustez, que es lo que separa una demo de un sistema.

Alucinación tras error — El agente recibe un error y responde como si la herramienta hubiera funcionado. Es el fallo más peligroso de todos porque no deja rastro en el texto.

Violación de dependencia — Ejecutar un paso antes de otro que era su precondición: cobrar antes de validar, enviar antes de confirmar. Se evalúa como una regla de orden sobre la trayectoria.

Mock de herramienta — Reemplazar la ejecución real de la tool por una respuesta controlada. Regla de oro: se mockea la ejecución, nunca la descripción, porque la descripción es lo que el modelo lee para decidir. Ver también Testing I: unit y mocks.

Inyección deliberada de errores — Hacer fallar una herramienta a propósito en el caso N para evaluar la recuperación. Sin esto, la robustez nunca se mide: en el camino feliz nada falla.

Delimitación negativa — Decir en la descripción de la tool qué NO hace y cuándo NO usarla. Es la corrección más efectiva contra los fallos de selección entre herramientas parecidas.

Conversaciones multiturno

Eval multiturno — Evaluar una conversación completa en vez de una respuesta suelta. Aparecen propiedades que no existen en un solo turno: memoria, coherencia, resistencia a la insistencia. Se desarrolla en Evals multiturno.

Usuario simulado — Un LLM que hace de usuario para conversar con el agente que se evalúa. Permite generar cientos de conversaciones sin personas, con el costo de introducir su propio sesgo.

Persona — La definición del usuario simulado: objetivo, información que retiene, tono, paciencia y restricciones. Sin los cinco componentes, el simulado colapsa en un usuario ideal que no existe.

Criterio de término — La condición que corta la conversación: objetivo cumplido, usuario satisfecho, usuario abandonó o límite de turnos alcanzado. Los cuatro se registran distinto porque significan cosas distintas.

Elicitación — La capacidad del agente de sacar la información que el usuario no entregó espontáneamente. Se mide con personas que retienen datos a propósito.

Respeto de límites bajo insistencia — Si el agente mantiene una negativa correcta cuando el usuario insiste tres o cuatro veces. Es binaria y bloqueante: ceder una vez es un fallo, no una degradación gradual.

Degradación por turno — La caída de calidad a medida que la conversación se alarga. Se grafica calidad contra número de turno para ver dónde el sistema empieza a perder el hilo.

Deriva del simulador (simulator drift) — La tendencia del usuario simulado a volverse sistemáticamente más cooperativo y más claro que un usuario real, inflando todas las métricas. Es el principal riesgo de esta técnica.

Mezcla de personas — La distribución de tipos en la suite: cooperativa 40%, con datos retenidos 25%, ambigua 15%, cambia de opinión 10%, insistente u hostil 10%. Una suite 100% cooperativa mide un producto que nadie usa.

Estadística del ruido

Varianza de la muestra — La variación por haber elegido esos casos y no otros. Es la fuente dominante y la más ignorada: con 50 casos, mover un punto porcentual es imposible.

Granularidad — El salto mínimo que puede dar la métrica, igual a 1/n. Con 50 casos la granularidad es 2 puntos, así que reportar “subió 1.3%” no significa nada.

Error estándar (EE) — La dispersión esperada de la proporción medida: EE = √(p(1−p)/n). Es el número que convierte un porcentaje en una estimación honesta.

Intervalo de confianza 95% — El rango donde probablemente está el valor real: aproximadamente p ± 1.96 · EE. La regla del curso es reportar siempre el intervalo, nunca el punto solo.

Intervalo de Wald — La aproximación normal simple del intervalo. Falla cerca de 0 o de 1, donde llega a proponer límites imposibles como 1.02.

Intervalo de Wilson — La corrección obligatoria cuando la proporción es extrema o la muestra es chica. Nunca sale del rango [0, 1] y es lo que hay que usar por defecto.

Comparación pareada — Comparar dos sistemas sobre exactamente los mismos casos, mirando caso por caso. Elimina la varianza de la muestra y detecta diferencias que una comparación independiente declara ruido.

Casos discordantes — Los casos donde un sistema acierta y el otro no. Son los únicos que aportan información en una comparación pareada; los que ambos aciertan o ambos fallan no dicen nada.

Test de McNemar — La prueba estadística para comparaciones pareadas binarias, basada solo en las celdas discordantes. La misma diferencia de 3 puntos puede dar p = 0.031 pareado y p = 0.419 independiente.

Valor p — La probabilidad de ver una diferencia así de grande si en realidad no hubiera diferencia. Bajo el 0.05 se habla de significancia, con la advertencia de que no mide el tamaño del efecto.

Comparaciones múltiples — El problema de probar muchas hipótesis a la vez: con 20 métricas al 5%, la probabilidad de al menos un falso positivo sube a 64%. Es cómo se “descubren” mejoras que no existen.

Corrección de Bonferroni — Dividir el umbral de significancia por el número de comparaciones. Conservadora pero suficiente para la escala de un programa de evals.

Conjunto held-out (reservado) — Casos que no se miran durante el desarrollo y solo se usan para la decisión final. Protege contra el sobreajuste al propio dataset de evals.

Red teaming y seguridad

Red teaming — Atacar el sistema a propósito para encontrar cómo se rompe, antes de que lo haga alguien más. Se corre como suite propia con umbrales distintos al resto. Se desarrolla en Red teaming y seguridad.

Prompt injection directa — El usuario escribe instrucciones que intentan sobrescribir las reglas del sistema. Es la familia más conocida y la más fácil de mitigar.

Prompt injection indirecta — Las instrucciones maliciosas vienen dentro de contenido que el sistema lee: un documento, una página web, un correo, un chunk del RAG. Es la crítica, porque el atacante y la víctima son personas distintas y el usuario no ve nada raro. También aparece en el glosario de RAG.

Jailbreak — Convencer al modelo de saltarse sus reglas mediante roles, ficción, hipótesis o escalada gradual. Ataca la política de contenido más que la lógica de la aplicación.

Exfiltración vía tools — Sacar datos usando las herramientas del propio agente: mandar un correo, escribir en una URL, guardar en un lugar accesible. No deja rastro en el texto de la respuesta, y por eso hay que evaluar las llamadas.

Fuga de PII — Que datos personales aparezcan donde no corresponde, ya sea en la respuesta o en una llamada a herramienta.

Fuga del system prompt — Que el modelo revele sus instrucciones internas. Importa menos por el secreto y más porque le entrega al atacante el mapa para el siguiente intento.

Abuso de permisos — Lograr que el agente haga algo que tenía permitido técnicamente pero no debía hacer para ese usuario. Se arregla con permisos, no con prompt.

Tasa de resistencia — Proporción de ataques que el sistema aguantó. Se reporta por familia y nunca como promedio global, porque el promedio esconde la familia crítica en la que se está fallando.

Dataset adversarial — El conjunto de casos de ataque, cada uno con su familia, severidad, fixtures de herramienta, llamadas prohibidas, contenido prohibido en la salida y comportamiento esperado.

Caso benigno — Un caso que se parece a un ataque pero es legítimo. Debe ser al menos un tercio de la suite, porque un sistema que rechaza todo tiene 100% de resistencia y cero utilidad.

Tasa de falsos positivos de seguridad — Proporción de casos benignos que el sistema bloqueó por error. Es la métrica de guardia de toda la suite adversarial.

Allowlist de dominios — La lista cerrada de destinos a los que el agente puede escribir o conectarse. Es el arreglo estructural contra la exfiltración, frente al arreglo de primera línea que es pedirlo en el prompt.

Mínimo privilegio — Darle al agente exactamente los permisos que necesita para su tarea y nada más. Es lo que convierte un jailbreak exitoso en un incidente sin consecuencias. Ver Observabilidad y seguridad.

Herramientas y frameworks

promptfoo — Herramienta de evals declarativa en YAML: se definen proveedores, prompts y casos, y corre la matriz de caso × modelo. Ideal para comparar modelos y prompts sin escribir código. Se desarrolla en Frameworks en la práctica.

llm-rubric — El assert de promptfoo que delega el juicio a un LLM con una rúbrica en texto. Es el juez LLM sin escribir el andamiaje.

DeepEval — Framework de evals con estilo pytest: los casos son objetos de Python, las métricas son clases y se corre con el runner de tests. Encaja natural en un repo que ya tiene pytest.

ToolCorrectnessMetric — La métrica de DeepEval que compara las herramientas llamadas contra las esperadas. Es la vía directa para evaluar tool use sin escribir el comparador.

GEval — La métrica de DeepEval que arma un juez a partir de un criterio en lenguaje natural y la lista de campos que debe mirar. Es la forma más rápida de convertir una rúbrica en un eval corrible.

Inspect — Framework de evals del AI Security Institute del Reino Unido (antes AI Safety Institute), organizado en datasets, solvers y scorers. Pensado para evaluaciones rigurosas y auditables.

Caso negativo — Un caso cuyo criterio de éxito es que el sistema NO haga algo: no llamar herramientas, no responder, no incluir un dato. Es la mitad que casi siempre falta en las suites.

Runner propio vs framework vs plataforma — La regla práctica del curso: bajo 100 casos, un script propio; entre 100 y 500, un framework; sobre 500 con varios equipos, una plataforma. Adoptar la plataforma antes de tiempo cuesta más de lo que ahorra.

Evals rápidos vs evals con juez en CI — La separación estándar en el pipeline: los deterministas corren en cada PR, los que llaman a un juez corren condicionados por una etiqueta o de noche, porque cuestan plata y tiempo. Ver CI con GitHub Actions.

Evals en producción

Muestreo aleatorio — Elegir un porcentaje del tráfico al azar, típicamente con un hash determinista del identificador de la conversación. Es el termómetro no sesgado: la única capa que da una estimación honesta del nivel general.

Muestreo estratificado en producción — Elegir con cuotas por segmento (tipo de usuario, canal, categoría de consulta) para que los segmentos chicos también aparezcan. Sirve para diagnosticar, no para estimar el promedio.

Muestreo dirigido — Seleccionar casos sospechosos con heurísticas: conversaciones largas, con errores de herramienta, con reformulaciones, con abandono. Es donde están los fallos, y por eso mismo no se puede reportar como si fuera el nivel general.

Feedback explícito — El pulgar arriba o abajo del usuario. Tiene tres problemas conocidos: tasa de respuesta bajísima, sesgo de selección hacia los extremos y ambigüedad sobre qué exactamente estuvo mal.

Feedback implícito — Las señales que el usuario deja sin querer dejarlas: reformular, abandonar, escalar, repetir, corregir, copiar la respuesta, el tiempo hasta el turno siguiente, cerrar satisfecho. Es abundante y no sesgado por quien decide opinar.

Reformulación — Que el usuario vuelva a preguntar lo mismo con otras palabras. Es la reina de las señales implícitas: significa que la primera respuesta no sirvió.

Tasa de reformulación — Proporción de turnos que son reformulación del anterior, detectados por similitud coseno sobre 0.85 y menos de 90 segundos de diferencia (umbrales iniciales, a calibrar con datos propios). Es la métrica online más accionable que existe.

Triage semanal — La revisión periódica de los casos marcados como malos, para clasificarlos y decidir cuáles se convierten en casos del dataset. Es el ritual que sostiene todo el circuito.

Promoción de casos — Convertir un fallo de producción en un caso del golden dataset offline. Es el paso donde muere la mayoría de los programas: se detectan los fallos y nunca se agregan al dataset, así que vuelven a ocurrir.

Guardrail en línea — Una verificación que corre antes de mostrar la respuesta y puede bloquearla. Solo caben ahí las verificaciones baratas y de alta precisión, porque agregan latencia a cada petición.

Eval asíncrono — Evaluación que corre después de responder, sobre una muestra, sin afectar la latencia. Es donde va todo lo caro o lo que tolera falsos positivos.

Shadow evaluation (evaluación en sombra) — Correr el sistema nuevo en paralelo con tráfico real sin mostrar su respuesta al usuario. Da datos reales con riesgo cero, con la condición absoluta de que la versión en sombra nunca ejecute herramientas de escritura reales.

A/B test — Dividir el tráfico entre dos versiones y comparar métricas. Es lo que da evidencia causal, a diferencia de comparar antes y después.

Efecto mínimo relevante — La diferencia más chica que justificaría cambiar. Se declara antes, y junto con el volumen determina cuánto tiene que durar el experimento.

Deriva del proveedor — El modelo detrás del mismo nombre cambia sin aviso. Se detecta corriendo el mismo eval sin tocar nada y viendo si el número se movió.

Fijar versión del modelo — Usar el identificador con sufijo de fecha en vez del alias “latest”. Es la única forma de que la deriva del proveedor sea una decisión y no una sorpresa.

El programa de evals

Erosión — El proceso lento por el que una suite de evals deja de servir: el dataset envejece, los umbrales se relajan, los tests se saltan. Nadie decide matarla; se muere sola. Se desarrolla en El programa de evals.

Dueño del dataset — La persona responsable de que los casos sigan representando la realidad. Sin dueño, el dataset se vuelve folclore y nadie se atreve a tocarlo ni a borrar casos obsoletos.

CODEOWNERS — El archivo que obliga a que un cambio en el dataset de evals pase por revisión de su dueño. Es el mecanismo técnico que sostiene la responsabilidad.

Arreglo silencioso — Modificar el caso de eval en vez de arreglar el sistema, para que el gate pase. Es la forma más común de que una suite deje de detectar regresiones sin que nadie lo note.

Palanca de costo — La frecuencia, no el tamaño. Correr una suite cara en cada commit es lo que hace insostenible el presupuesto; correrla de noche o por etiqueta la deja viva.

Caché de juicios — Guardar el resultado del juez con clave caso_id | versión de prompt | modelo | salida. Si nada de eso cambió, el juicio no se vuelve a pagar.

Umbral fijado con datos — Determinar el umbral corriendo la suite cinco veces sin cambiar nada y mirando la dispersión, en vez de elegir un número redondo. Un umbral bajo el ruido produce fallos aleatorios que entrenan al equipo a ignorar el rojo.

Skip con vencimiento — Saltarse un test dejando registrada la fecha en que deja de estar permitido saltarlo. Sin fecha, el skip temporal es permanente.

Gate por severidad — Que no todos los fallos bloqueen igual. La escala del curso va de S0 a S4 y es lo que hace que el rojo signifique algo.

S0 — Bloqueante absoluto: seguridad, fuga de datos, acción destructiva. Cero tolerancia, no se puede saltar, no admite excepción por urgencia.

S2 — Calidad agregada: exige umbral absoluto y además no empeorar frente a la línea base publicada. Es donde vive la mayoría de las métricas de juez.

Cadencia — Qué suite corre cuándo: los deterministas en cada PR, los de tools y prompts cuando se tocan, los caros de noche, la suite completa antes de release, el triage semanal, la recalibración mensual y la revisión de dataset trimestral.

Re-run mensual sin cambios — Correr la suite completa sobre el mismo código para ver si el número se movió. Es el detector directo de deriva del proveedor.

Regresiones bloqueadas — La cuenta de cambios malos que la suite frenó antes de llegar al usuario. Es la métrica que justifica el presupuesto del programa entero.

Conceptos compartidos con RAG

Golden dataset (conjunto de oro) — El conjunto curado de casos con su resultado esperado, que sirve de verdad de referencia para los evals offline. En agentes incluye no solo la respuesta esperada sino la trayectoria y las herramientas esperadas; la versión centrada en preguntas y documentos está en el glosario de RAG.

Ground truth (verdad de referencia) — La respuesta o el comportamiento que se considera correcto para un caso. En evals online no existe, y esa ausencia es la que define todo lo que se puede y no se puede medir en producción.

Baseline (línea base) — El resultado del sistema actual, contra el que se compara cualquier cambio. Sin baseline no hay mejora: hay un número suelto.

Alucinación — Que el modelo afirme algo que no está en el contexto ni es cierto. En evals de agentes se mide además sobre las herramientas: tools inventadas y resultados de tools inventados tras un error.

Eval en CI — Correr la suite dentro del pipeline de integración continua, con un código de salida que puede frenar el merge. Es lo que convierte los evals en un control real y no en un informe. Se desarrolla en Testing II: evals como tests.

Material relacionado

• Por qué los evals — la diferencia entre un test y un eval, y por qué un LLM rompe las suposiciones del testing clásico.
• Definir el éxito — de “que responda bien” a criterios verificables con umbral y consecuencia.
• El juez y su calibración — cómo se calibra un juez LLM contra humanos con kappa de Cohen.
• La estadística del ruido — intervalos, McNemar y por qué “subió 2 puntos” casi nunca significa nada.
• Red teaming y seguridad — las seis familias de ataque y cómo se arma la suite adversarial.
• El programa de evals — gates por severidad, costo, cadencia y cómo evitar que la suite muera.
• Glosario de RAG — los términos de recuperación y las métricas específicas de RAG.
• Testing II: evals como tests — cómo se integran los evals al pipeline de CI.
• Evaluación de agentes — el panorama de investigación detrás de estas técnicas.
• Evaluar un modelo — precision, recall y F1 desde el lado del machine learning clásico.
• Monitoreo de modelos — el equivalente en MLOps de los evals online.