Por qué un eval que no falla el build no sirve

4.1El PR del viernes

Llevas tres niveles montando algo serio. Tienes un dataset etiquetado de los modos de fallo de Aurora —la tienda online ficticia que es tu banco de pruebas todo el curso—. Tienes un juez LLM validado contra humanos. Tienes una suite que mide el RAG y la trayectoria del agente. Y corre verde en tu portátil.

Un viernes por la tarde, un compañero abre un PR: "mejora el prompt del agente". Cambia el system prompt de Aurora para que suene "más cálido". Lo lee otro compañero por encima, parece razonable, se mergea. Buen fin de semana.

El lunes vuelve el reembolso fantasma. El agente promete reembolsos que la política de Aurora prohíbe. Ahora en tres conversaciones distintas.

Lo más amargo es esto: tu suite habría detectado la regresión. Tenías el caso exacto en el dataset. Pero nadie la corrió antes de mergear. Vivía en un notebook que nadie abre cuando hay prisa un viernes.

Tenías el eval. No tenías el gate.

4.2Qué vas a poder hacer

Al terminar esta lección sabrás:

• Distinguir un eval que gobierna (puede bloquear un merge) de uno que solo informa (imprime un número).
• Situar cualquier eval de Aurora en la pirámide de coste y cadencia L1/L2/L3, y decir cuál puede ser un gate de CI hoy.
• Explicar la diferencia entre un eval offline —contra tu dataset, antes de deploy— y uno online —sobre tráfico real—, y cómo encajan en un mismo ciclo.

Necesitas saber antes:

• Lo que produjiste en los checkpoints C1 (dataset etiquetado), C2 (juez validado) y C3 (suite por arquitectura). Esta lección los industrializa.
• Qué es un sistema de integración continua (CI) que corre tests en cada cambio. No hace falta dominarlo; sí saber que existe.

Esta lección no escribe YAML ni workflows todavía. Eso llega en L2 a L5. Aquí construimos el porqué: sin él, montarás un gate que parece verde y no frena nada.

4.3Recupera

Antes de seguir, responde mentalmente. No mires lo de abajo hasta tener una respuesta.

1. ¿Qué tres activos produjiste en C1, C2 y C3? Nómbralos.
2. ¿Dónde viven hoy esos tres activos —en qué archivo, en qué máquina—?
3. Cuando tu compañero abrió el PR del viernes, ¿quién o qué tendría que haber corrido tu suite antes del merge? ¿Ocurrió?

La respuesta a la 1, en bloque: un dataset etiquetado de los modos de fallo de Aurora (C1). Un juez LLM validado contra humanos para el fallo nº1 (C2). Una suite de métricas por arquitectura, el RAG triad y la trayectoria del agente (C3). La 2 y la 3 duelen porque apuntan al mismo agujero. Ese trabajo vive en un notebook, y la decisión de ejecutarlo depende de que un humano se acuerde. El viernes, nadie se acordó.

4.4El concepto: informar no es gobernar

Empecemos por lo concreto y subamos hacia la idea general.

La idea que sostiene todo el nivel

Un eval que no puede frenar nada solo describe el pasado. La fiabilidad de un sistema LLM se demuestra en CI, no en un notebook (objetivo del Nivel 4, 03-arquitectura.md).

Distingo dos roles con un término cada uno. Un eval informa cuando produce un número que alguien puede leer —o ignorar—. Un eval gobierna cuando su resultado puede bloquear una acción: aquí, impedir un merge. La diferencia no está en el código del eval. Está en quién toma la decisión cuando el eval falla.

Cuando un eval informa, la decisión la toma la disciplina humana: alguien tiene que abrir el notebook, correrlo, leer el número y decidir no mergear. El PR del viernes demuestra cómo termina eso. Cuando un eval gobierna, la decisión la toma una máquina: el build se pone rojo y el merge se bloquea sin pedir permiso.

Esto es eval-driven development: escribir los evals de las capacidades antes o junto al código, no después (Anthropic, "Demystifying evals for AI agents", 9 ene 2026). El gate convierte esa disciplina en algo estructural, no voluntario. Es la diferencia entre "deberíamos correr los evals" y "no se puede mergear sin pasarlos".

La pirámide de coste y cadencia, revisitada

Ya viste esta pirámide al elegir entre evals deterministas y de juez. Ahora la usamos para decidir dónde vive un gate. Husain define tres niveles de coste creciente (Hamel Husain, Your AI Product Needs Evals, 29 mar 2024):

• L1 — assertions y unit tests. Baratos, deterministas, rápidos. Corren en cada cambio. Un regex que verifica el formato de un order_id. Un check de que la respuesta no contiene la palabra "reembolso" cuando la política lo prohíbe.
• L2 — evaluación humana y model-graded. El LLM-as-judge entra aquí. Más caro, más lento, ruidoso. Corre con cadencia periódica, no en cada commit trivial.
• L3 — A/B testing en producción. El más caro y lento de todos. Solo tras cambios significativos, sobre tráfico y usuarios reales.

La regla que ordena la pirámide es de coste: L3 > L2 > L1. El coste dicta la cadencia. Lo barato corre siempre; lo caro corre cuando compensa. Esta analogía tiene un límite: L1 no "sostiene" a L2 físicamente. Lo que cae a medida que sube el coste es la frecuencia con que ejecutas cada nivel.

El Nivel 4 vive en L1 y L2 como gate antes del deploy. Eso es lo que cabe en CI: assertions baratas en cada PR, más el juez con una cadencia razonable. El L3 —el A/B en producción— es el Nivel 5; no cabe en un gate de merge porque necesita usuarios reales.

Offline frente a online

Aquí muchos confunden dos cosas que parecen lo mismo. La diferencia es el cuándo y el sobre qué.

Un eval offline corre contra tu dataset versionado, antes de desplegar. Un eval online corre sobre el tráfico de producción, en vivo (Langfuse, Evaluation core concepts). El offline pregunta "¿este cambio rompe algo que ya sé que importa?". El online pregunta "¿qué está pasando ahí fuera que aún no había previsto?".

No compiten. Forman un ciclo (Langfuse, Evaluation core concepts):

1  ┌──────────────────────────────────────────────┐
2  │                                                │
3  ▼                                                │
4offline (pre-deploy)                               │
5  contra el dataset versionado                     │
6  │                                                │
7  ▼  pasa el gate → deploy                          │
8online (producción)                                │
9  detecta un fallo nuevo en tráfico real           │
10  │                                                │
11  ▼                                                │
12añade ese fallo como caso nuevo al dataset ────────┘

El Nivel 4 construye la primera mitad: el gate offline. El Nivel 5 cierra la segunda mitad en producción. El reembolso fantasma del lunes, si lo hubieras detectado online, se convertiría en un caso nuevo del dataset, y la próxima vuelta del gate offline lo atraparía para siempre. Así es como "los fallos se vuelven casos de prueba": el ciclo lo hace concreto.

4.5Míralo funcionar: dos líneas de tiempo del mismo PR

Vamos a ver, lado a lado, qué le pasa al PR "prompt más cálido" en dos mundos. Es el mismo cambio, el mismo dataset, el mismo fallo latente. Cambia una sola cosa: si existe el gate.

Lee primero las dos líneas de tiempo enteras. Después analizamos qué propiedad tiene una que la otra no.

Línea A — sin gate

1viernes 16:40  PR "prompt más cálido" abierto
2viernes 16:55  revisión humana por encima → "parece razonable" → aprobado
3viernes 17:10  merge a main
4                (la suite NO corre: vive en un notebook, nadie lo abre)
5lunes  09:14   reembolso fantasma en producción, 3 conversaciones
6lunes  09:30   un cliente tuitea la captura
7lunes  --      semana de fuego: revert, hotfix, post-mortem

Línea B — con gate

1viernes 16:40  PR "prompt más cálido" abierto
2viernes 16:41  CI arranca: corre la suite del C3 sobre el dataset del C1
3viernes 16:44  faithfulness del agente cae bajo el umbral en el caso de reembolso
4viernes 16:44  build ROJO → el merge queda bloqueado
5viernes 16:45  el autor ve el check rojo en el PR, con la métrica que cayó señalada
6                (nunca llegó a producción; coste total: 4 minutos)

Ahora la pregunta de auto-explicación. Antes de leer el análisis, respóndela: ¿qué propiedad tiene la línea B que la A no?

En la línea A, la única barrera era una persona leyendo el PR un viernes a las cinco. Esa persona no podía ver la regresión: el cambio "parecía razonable" precisamente porque el reembolso fantasma no es un error de código, es una respuesta fluida y falsa. El eval existía, pero como un número que nadie consultó.

En la línea B, la decisión de no mergear no la toma un humano cansado. La toma una máquina, contra un caso del dataset, sin pedir permiso. Esa es la propiedad: el gate mueve la decisión de "la disciplina humana" a "el mecanismo". Por eso un eval que gobierna frena lo que uno que informa deja pasar.

Un matiz honesto: en esta lección no montamos la línea B. Eso es el trabajo de L2 a L5 —promptfoo, pytest, GitHub Actions, umbrales—. Aquí solo establecemos por qué B vale y A no. Sin entender esto, montarás el YAML como un ritual y no como una barrera.

4.6Hazlo tú

Ejercicio 1 — andamiaje parcial

Tienes tres evals de Aurora. Clasifica cada uno en L1, L2 o L3. Los dos primeros están resueltos; completa el tercero y justifica.

• Un assert que comprueba que el argumento order_id pasado a buscar_pedido tiene el formato correcto. → L1 (determinista, barato, en cada cambio).
• El juez validado del C2 que detecta si la respuesta "promete reembolsos inexistentes". → L2 (model-graded, ruidoso, cadencia periódica).
• Un experimento de satisfacción de usuario que sirve el prompt nuevo al 5% del tráfico real y compara métricas. → L____ porque __________.

Ejercicio 2 — autónomo

De los tres evals anteriores, decide cuáles pueden ser un gate de CI hoy y cuál no. Para el que no puede, explica por qué en una frase.

Antes de responder, una pregunta de interrogación elaborativa. Respóndela tú primero: ¿por qué el A/B de satisfacción no puede vivir en el gate de un merge, aunque sea un eval legítimo? Piénsalo antes de leer la siguiente línea.

Porque mide sobre tráfico y usuarios reales, y eso solo existe después de desplegar. Un gate de CI corre antes del deploy, contra un dataset fijo. El A/B es L3, online; pertenece al Nivel 5, no a la barrera del merge. Pedirle a un gate offline que ejecute un A/B es pedirle que mida algo que aún no ha ocurrido.

4.7Comprueba

Sin pistas. Un compañero te dice:

"Tranquilo, tenemos evals. Corren en un notebook y dan 100% verde."

En tres frases, explica por qué eso todavía no gobierna nada y qué falta para que lo haga.

4.8Conecta

Vuelve al PR del viernes a las 16:40.

Este es el "porqué" de todo el Nivel 4. Lo que sigue construye el "cómo", pieza a pieza:

• En L2 correrás la suite con una sola orden usando promptfoo: assertions deterministas (L1) y el juez del C2 (L2) sobre el dataset del C1.
• En L3 verás el mismo gate desde pytest y DeepEval, para que una regresión sea un test rojo más, igual que un bug de código.
• En L4 moverás esa orden a GitHub Actions, para que se dispare sola en cada PR y ponga el check en rojo.
• En L5 decidirás los umbrales con criterio, distinguiendo lo determinista estricto del juez con margen.
• En L6 lo demostrarás: un PR con una regresión inyectada que se queda en rojo, y un PR que mejora que pasa en verde. Es el checkpoint C4.

Al final del nivel, ese PR del viernes no llega a mergearse. La máquina lo frena el viernes a las 16:44, no el cliente el lunes a las 09:14.

¿Dónde lo aplicarías en tu trabajo? Piensa en tu CI actual. Si hoy alguien degrada la calidad de un sistema LLM —no rompe el código, solo lo empeora—, ¿tu build se pone rojo? Si la respuesta es "no, eso no lo detecta nada", ya sabes qué barrera te falta.

4.9Reflexiona

Tómate dos minutos. Estas preguntas consolidan más que releer.

• ¿Qué cambio "que parecía mejor" has mergeado tú alguna vez que un gate offline habría frenado? Sé concreto.
• ¿Tus evals actuales podrían fallar un build, o solo imprimen un número que alguien decide mirar?
• ¿Qué sigue sin estar claro? Anótalo. Si es "cómo hago que un eval ponga el build en rojo de verdad", es la pregunta correcta —la responden L2 a L4—.

Referencia rápida

• Informar vs gobernar: un eval informa si produce un número que alguien puede ignorar; gobierna si su resultado bloquea una acción (un merge). La diferencia es quién decide: la disciplina humana o el mecanismo.
• Pirámide L1/L2/L3 (Husain, 29 mar 2024): L1 assertions/unit tests, en cada cambio · L2 humano + model-graded (el juez), cadencia periódica · L3 A/B en producción, tras cambios significativos. El coste dicta la cadencia (L3 > L2 > L1).
• Dónde vive N4: L1 + L2 como gate offline antes del deploy. El L3 online es N5.
• Offline vs online (Langfuse, Evaluation core concepts): offline = contra el dataset versionado, antes de deploy; online = sobre tráfico real, en vivo. Forman un ciclo: offline → deploy → fallo en prod → caso nuevo al dataset → offline.
• Eval-driven development (Anthropic, 9 ene 2026): escribir los evals antes o junto al código. El gate hace esa disciplina estructural, no voluntaria.