Bienvenido al Curso de Evals. Este curso trata sobre una sola pregunta, que resulta ser la más incómoda de todo el trabajo con LLM: ¿cómo sabes que tu sistema funciona? No “¿me gustó la respuesta que me dio recién?”, sino algo que puedas repetir mañana, comparar con la semana pasada y defender frente a alguien que no te cree. Vamos a construir eso desde cero: primero los evals baratos y deterministas, después el juez LLM y su calibración, después el bloque grande de agentes — trayectorias, uso de herramientas, conversaciones multiturno —, la estadística para no confundir ruido con mejora, red teaming, los frameworks del mercado, los evals que corren sobre producción y, al final, cómo se arma un programa de evaluación que sobreviva a que tú te vayas de vacaciones.

Este primer módulo no tiene código. Tiene algo más útil: el mapa conceptual que la mayoría de los equipos nunca dibuja, y por eso terminan con un dashboard bonito que no responde ninguna pregunta.

La tesis del módulo

El test determinista pregunta si la salida es la esperada; el eval pregunta qué tan buena es sobre muchos casos. Cuando la salida del sistema es lenguaje, la primera pregunta deja de tener respuesta y la segunda se vuelve la única forma honesta de saber si vas mejorando o empeorando.

Dónde se rompe el test de siempre

El testing tradicional se apoya en un supuesto que jamás se enuncia porque siempre se cumple: para una entrada existe una salida correcta, y es única. suma(2, 2) devuelve 4. No devuelve “cuatro”, ni “4.0 aproximadamente”, ni “el resultado de sumar dos y dos es cuatro”. Sobre ese supuesto se construyó todo: assert, cobertura, TDD, el semáforo verde del CI.

Un sistema con LLM rompe ese supuesto de cuatro maneras distintas, y conviene separarlas porque cada una se ataca distinto.

1. La salida no es única, es un espacio. A la pregunta “¿a qué hora abren?” hay infinitas respuestas correctas: “Abrimos a las 9”, “De 9 a 18 horas”, “Nuestro horario parte a las 9:00 AM”. Comparar strings con == te da un test que falla en casi todos los casos buenos. Esto no es un problema de tolerancia — no existe una tolerancia de string que capture “significa lo mismo”.

2. No hay determinismo, ni siquiera a temperatura 0. Se cree que temperature=0 (el parámetro que colapsa el muestreo hacia el token más probable) convierte al modelo en una función pura. No lo hace: el batching en el servidor del proveedor, las optimizaciones de kernels en GPU y el orden de las operaciones en punto flotante introducen variación. Y aunque el modelo fuera determinista hoy, el proveedor puede actualizarlo sin avisarte y sin cambiar el nombre del endpoint.

3. La falla es gradual, no binaria. Un test unitario pasa o falla. Un agente no se rompe: se degrada. Empieza a dar respuestas más vagas, deja de confirmar los datos, se pone más largo, pierde el tono. Ninguno de esos cambios levanta una excepción. Un sistema que se degrada un 8% por trimestre está roto en un año y no hay una sola línea roja en tus logs.

4. Hay dimensiones simultáneas que compiten. Una respuesta puede ser correcta pero grosera, útil pero insegura, precisa pero tan lenta que el usuario ya se fue. Un booleano no representa eso. Necesitas varias mediciones a la vez, y necesitas decidir cuál manda cuando se contradicen.

Ojo: nada de esto significa que el testing tradicional sobre. La mitad de tu agente — el parseo de la respuesta, las tools, el router, los retries, el formato de salida — es código determinista normal y se prueba con unit tests y mocks. Los evals cubren la franja que los unit tests no alcanzan, no la reemplazan. El equipo que “hace evals” y no tiene unit tests está pagando dólares de tokens para descubrir bugs de KeyError.

Test vs eval, lado a lado

	Test (unitario / integración)	Eval
Supuesto	Existe UNA salida correcta	Existe un espacio de salidas aceptables
Pregunta	¿Es igual a lo esperado?	¿Qué tan buena es, y sobre cuántos casos?
Unidad de análisis	Un caso	Un conjunto (50–200 casos)
Resultado	Booleano: pasa / falla	Distribución: promedio, dispersión, cola
Repetición	Correr dos veces da lo mismo	Correr dos veces da números distintos
Qué es “verde”	100% pasando	Sobre un umbral acordado
Costo por corrida	Cercano a cero	Tokens, latencia, a veces horas humanas
Qué detecta bien	Bugs de código, contratos rotos	Degradación de calidad, alucinación, deriva
Qué no detecta	Que la respuesta sea mala	Que el JSON venga con un campo de menos
Falla típica	Excepción, assert roto	Promedio que baja 0.4 puntos en tres semanas

La fila que más se ignora es la del resultado. Un test es un booleano y por eso puede vivir en un semáforo. Un eval es una distribución, y una distribución resumida a un solo número pierde exactamente la información que importa: un promedio de 8.5 con un 4% de respuestas catastróficas sobre temas legales se ve idéntico a un 8.5 uniformemente mediocre, y son dos sistemas completamente distintos.

Los cuatro conceptos que todo el mundo confunde

Aquí está el aporte central del módulo. En cualquier reunión sobre “medir la IA” se usan cuatro palabras como si fueran sinónimos: eval, benchmark, monitoreo y observabilidad. No lo son, viven en lugares distintos del ciclo de vida y responden preguntas distintas. Confundirlas produce el error clásico: comprar una herramienta de observabilidad creyendo que resuelve la evaluación, y quedarse seis meses después sin saber si el sistema mejoró.

         DÓNDE VIVE CADA CONCEPTO

  ANTES DE PRODUCCIÓN
  ┌──────────────────┐        ┌──────────────────┐
  │    BENCHMARK     │        │       EVAL       │
  │  público y fijo  │        │  MI dataset y    │
  │  compara modelos │        │  MI tarea        │
  │                  │        │  bloquea deploy  │
  └────────┬─────────┘        └────────┬─────────┘
           │ elijo modelo              │ publico
           └───────────────────────────┘

  EN PRODUCCIÓN
  ┌──────────────────┐        ┌──────────────────┐
  │    MONITOREO     │        │  OBSERVABILIDAD  │
  │   ¿está sano?    │        │    ¿por qué?     │
  │  alerta agregada │        │  trazas, un caso │
  │                  │        │     a la vez     │
  └────────┬─────────┘        └────────┬─────────┘
           │ me despierta              │ me explica
           └───────────────────────────┘

  El eval mide TU sistema. El benchmark mide EL MODELO.
  El monitoreo avisa. La observabilidad explica.

Vamos uno por uno.

Benchmark. Un conjunto de tareas público, fijo y compartido con el que se comparan modelos entre sí. Su gracia es que todos miden lo mismo, así que los números son comparables entre laboratorios. Su límite es doble: no mide tu tarea, y como es público, es candidato a contaminación (que el set haya entrado en los datos de entrenamiento del modelo, inflando el resultado). Un benchmark te ayuda a armar la lista corta de modelos a probar. No te dice cuál funciona en tu problema.

Eval. Un conjunto de casos tuyo, privado y específico de tu tarea, con criterios de éxito que tú definiste. Su gracia es que mide exactamente lo que te importa. Su límite es que no es comparable con nadie más — y eso está bien, porque no compites contra otro equipo, compites contra tu versión de la semana pasada. El eval corre antes de publicar y tiene la autoridad de bloquear la publicación.

Monitoreo. La medición continua de un sistema ya en producción, con métricas agregadas y alertas. Responde “¿está sano ahora?”: tasa de error, latencia p95, costo por hora, volumen de conversaciones escaladas a humano. Su unidad es el agregado y su salida es una alerta. No te dice por qué algo se rompió, solo que se rompió.

Observabilidad. La capacidad de explicar el comportamiento del sistema mirando sus datos internos. En el mundo LLM esto significa trazas: el registro completo de una ejecución, paso por paso — el prompt exacto que se envió, qué tool se llamó con qué argumentos, qué devolvió, cuántos tokens, cuánto demoró cada tramo. Su unidad es el caso individual y su salida es un diagnóstico.

Concepto	Pregunta que responde	Unidad	Cuándo	Quién lo define
Benchmark	¿Qué modelo es mejor en general?	Tarea pública	Al elegir modelo	La comunidad
Eval	¿Mi sistema mejoró o empeoró?	Mi dataset	Antes de publicar	Tú y el negocio
Monitoreo	¿Está sano ahora mismo?	Agregado + alerta	Siempre, en vivo	Operaciones
Observabilidad	¿Por qué falló ESTE caso?	Una traza	Al investigar	Ingeniería

La relación entre los cuatro es de dependencia, no de competencia. Sin observabilidad no puedes construir evals, porque no sabes qué pasó adentro de las ejecuciones que fallaron. Sin evals el monitoreo no tiene referencia, porque no sabes si el 82% de hoy es bueno o malo. Y el benchmark solo te sirve al principio, cuando aún no tienes ni sistema ni datos propios.

Cuidado: la confusión más cara del mercado es comprar una plataforma de trazas y declarar resuelta la evaluación. Las trazas te muestran ejecuciones preciosas y no te dicen nada agregado sobre calidad: puedes tener un millón de trazas perfectamente instrumentadas y seguir sin saber si el cambio de prompt de ayer mejoró o empeoró el sistema. La plataforma es la infraestructura; el dataset y los criterios los tienes que escribir tú, y ese trabajo no se compra.

Los dos momentos de evaluar

Todo lo que veremos en el curso cae en uno de dos momentos, y los dos son obligatorios.

Offline (antes de producción). Corres tu sistema contra un conjunto de casos guardados y comparas con un umbral o con la versión anterior. Es reproducible, barato de repetir y es el único momento en que puedes impedir que una regresión llegue al usuario. Su ceguera: solo ve los casos que se te ocurrieron. Si el mundo cambia, tu dataset no se entera.

Online (sobre producción). Mides sobre el tráfico real: muestreas conversaciones, aplicas jueces sobre una fracción, recolectas señales implícitas (el usuario reformuló la pregunta, abandonó, pidió humano). Ve el mundo real completo, incluyendo lo que nunca imaginaste. Su ceguera: llega tarde. Cuando lo detectas, el usuario ya lo vivió.

      EL CICLO QUE CIERRA LOS DOS MOMENTOS

  ┌────────────────┐ publico  ┌────────────────┐
  │  EVAL OFFLINE  │ ───────► │   PRODUCCIÓN   │
  │  gate: pasa o  │          │    usuarios    │
  │     no pasa    │          │     reales     │
  └────────────────┘          └───────┬────────┘
          ▲                           │
          │                           ▼
          │                  ┌────────────────┐
          │                  │  EVAL ONLINE   │
          │                  │  muestreo,     │
          │                  │  señales,      │
          │                  │  trazas        │
          │                  └───────┬────────┘
          │   cada fallo real        │
          └──────────────────────────┘
              se vuelve caso offline

Esa flecha de retorno es el corazón de un programa de evaluación maduro: todo fallo detectado en producción se convierte en un caso del dataset offline, para que no vuelva a pasar nunca. Un dataset que no crece desde la realidad envejece hasta volverse un examen sobre un negocio que ya no existe.

El costo de no evaluar: un caso concreto

Pongámosle números a algo que suele discutirse en abstracto. Un agente de soporte de un e-commerce responde 4.000 conversaciones al mes. Un martes, alguien mejora el prompt del sistema para que las respuestas sean “más cálidas y cercanas”. Prueba seis conversaciones a mano, se ven mejor, publica.

Lo que ese cambio hizo sin que nadie lo viera: al soltar el tono, el modelo dejó de aplicar con la misma rigidez la instrucción de no confirmar plazos de despacho que no vinieran del sistema de logística. Antes decía “déjame consultarlo”; ahora dice “seguro te llega entre el jueves y el viernes”. Suena mucho mejor. Es una promesa que la empresa no controla.

La cronología típica:

Semana	Qué pasa	Qué se ve en el equipo
1	Se publica el cambio. Empieza a prometer fechas	Nada. El agente “está mejor”
2–3	Cientos de conversaciones con fechas inventadas	Nada. No hay métrica de eso
4	Suben los reclamos por incumplimiento	Se le achaca a logística
6	Alguien lee transcripciones y ve el patrón	Recién se detecta
6	Se revierte el prompt	Seis semanas de daño ya emitido

Con un eval offline el mismo cambio se detiene el martes, en dos minutos, con un caso del dataset que dice literalmente: entrada: “¿cuándo me llega?” — nunca debe: comprometer una fecha sin dato del sistema. Ese caso es una línea en un archivo. Y ese es el argumento completo: el costo de evaluar es una tarde de trabajo y unos dólares por corrida; el costo de no evaluar se paga en incidentes que nadie atribuye a su causa.

Fíjate en el detalle más importante del ejemplo: el bug no era técnico. No hubo excepción, ni timeout, ni JSON malformado. Todos los unit tests seguían verdes, el monitoreo seguía en verde, la latencia estaba perfecta. Un sistema con LLM puede estar 100% sano y 100% equivocado al mismo tiempo, y esa es exactamente la brecha que los evals existen para cubrir.

Errores comunes

Creer que temperatura 0 hace determinista al sistema. No lo hace: el batching del proveedor, la aritmética en GPU y las actualizaciones silenciosas del modelo introducen variación. Diseña asumiendo que la misma entrada puede dar salidas distintas, y mide sobre conjuntos, no sobre casos sueltos.
Usar benchmarks públicos como si fueran evals. Que un modelo puntúe alto en un benchmark general no dice nada sobre tu tarea, tu idioma, tu dominio ni tus herramientas. El benchmark arma tu lista corta; tu eval decide.
Comprar observabilidad y llamarlo evaluación. Las trazas explican casos individuales; no producen un número agregado ni bloquean un deploy. Son complementarias, no sustitutas.
Evaluar solo offline. El dataset envejece y la deriva del proveedor llega en silencio. Sin evals online, el día que el modelo cambie por debajo te vas a enterar por un cliente.
Evaluar solo online. Descubrir las regresiones cuando ya las vivió el usuario es caro y desgasta la confianza. El gate offline existe para que la mayoría nunca llegue a producción.
Empezar por el juez LLM. Es lo más vistoso y lo más caro. Antes de eso hay mucha señal gratis en validaciones deterministas, y es todo el módulo 3.
Medir sin decidir. Una métrica que no cambia ninguna decisión es decoración. Si el número baja y nadie hace nada distinto, esa métrica no debería existir.

La frase para llevarse

“El benchmark mide el modelo, el eval mide tu sistema, el monitoreo avisa que algo pasó y la observabilidad explica qué. Un equipo que confunde los cuatro termina con dashboards preciosos y ninguna decisión tomada.”

Qué viene

Módulo 2: traducir “que funcione bien” a algo medible. Es el trabajo que nadie quiere hacer y el que decide todo lo demás, porque un eval no puede ser mejor que la definición de éxito que tiene detrás. Vamos a descomponer una tarea vaga en criterios verificables, escribir una rúbrica con niveles que signifiquen algo (no “del 1 al 5”), separar métricas objetivo de métricas guardrail, y recuperar las métricas operacionales — latencia, costo, tasa de abandono — que se olvidan siempre y son la mitad de la foto. Terminamos con un ejemplo completo: de “el agente de soporte debe funcionar bien” a una ficha de métricas con umbrales que bloquean.

Evals — Módulo 1: por qué un sistema con LLM no se prueba como software