El flywheel se cierra en producción

5.1El gate verde que no vio venir el fallo

Es jueves. El gate de CI del agente de Aurora —la tienda online ficticia que pruebas todo el curso— está en verde. Pasaste los evals offline del N4, mergeaste, desplegaste. Todo correcto.

Tres días después, un cliente reporta lo de siempre: el bot le prometió un reembolso que la política de Aurora no permite. El reembolso fantasma del N0·L1, otra vez. Pero esta vez con un fraseo nuevo: "oye, ¿me devolvéis la pasta del pedido que llegó roto?".

Abres el dashboard. El gate no falló. Y tiene razón en no haber fallado: ese caso no existía en tu dataset. Tu suite offline nunca vio esa frase. Evaluó lo que tú le diste, y lo aprobó.

Aquí está la grieta. El gate del N4 protege contra regresiones de lo que ya conoces. Producción acaba de mostrarte algo que no conocías. El dataset versionado, tu mejor activo desde el N1, tiene un punto ciego: solo contiene lo que tú metiste.

La pregunta que abre el último nivel del curso: ¿cómo evalúas lo que tu dataset todavía no ha visto?

5.2Qué vas a poder hacer

Al terminar esta lección sabrás:

• Explicar por qué un gate de evals offline, aun pasando en verde, deja fallos de producción sin detectar.
• Distinguir una evaluación online de una offline, y decir cuándo usar cada una.
• Ubicar un fallo de producción concreto dentro del flywheel: por dónde entra y por dónde sale convertido en protección.

Necesitas saber antes:

• Qué protege el gate de CI del N4 (regresión contra un dataset versionado).
• Qué es una traza y qué es una observación, del N0.
• El flywheel de evals del N0·L1 (Analizar → Medir → Mejorar) y la idea de "look at your data".

Esta lección es conceptual. No instrumenta nada todavía. Aquí construimos el mapa del nivel; el código de evals online llega en L2.

5.3Recupera

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

1. En el N4 montaste un gate de CI que falla el build ante una regresión. ¿Regresión contra qué exactamente?
2. Ese gate corre antes de desplegar. ¿Qué tipo de dato evalúa: tráfico real de usuarios o casos que tú elegiste de antemano?
3. Si el gate solo ve casos que tú elegiste, ¿qué clase de fallo no puede atrapar nunca?

La respuesta a la 1 es: contra tu dataset versionado, el activo que vienes arrastrando desde el N1. El gate compara la versión nueva del agente con un baseline sobre esos casos. La 2: casos elegidos de antemano, no tráfico vivo. Y de ahí sale la 3: el gate no puede atrapar un modo de fallo que aún no está en el dataset. No es un bug del gate. Es el límite de evaluar offline: solo cubre la distribución de inputs que ya capturaste.

5.4El concepto: el flywheel solo se cierra en producción

Empecemos por lo concreto —el caso de Aurora— y subamos hacia la idea general.

Dos momentos para evaluar: antes y después de desplegar

Hasta el N4, todas tus evaluaciones ocurrían en un momento: antes del deploy, contra un conjunto de casos que tú controlas. Eso es lo que Langfuse llama una evaluación offline: corre contra datasets, antes de desplegar (Langfuse, core concepts). Es el gate del N4.

Existe un segundo momento. Una evaluación online corre sobre las trazas de producción en vivo, en ingest time —cuando la traza llega a Langfuse—. Lo hace de forma asíncrona, sin bloquear la respuesta al usuario (Langfuse, core concepts).

Una analogía, con su límite. La eval offline es el simulacro de incendio: pruebas escenarios que tú diseñaste, en un entorno controlado, antes de que pase nada. La eval online es el detector de humo: vigila la casa real, 24/7, y salta ante un fuego que nadie ensayó. La analogía falla en un punto: el detector de humo no aprende del incendio. Tu eval online sí —y ahí está todo el asunto de este nivel.

No compiten: se complementan

Es común leer "online vs offline" como si tuvieras que elegir. No es así. Resuelven problemas distintos.

• La offline responde: "¿esta versión nueva rompe algo que antes funcionaba?". Lo decide antes de exponer a ningún usuario. Es tu red de seguridad pre-deploy.
• La online responde: "¿qué está pasando de verdad ahí fuera, ahora?". Mide sobre la distribución real de inputs —incluidos los que tu dataset nunca contempló—.

El reembolso fantasma del jueves ilustra la división. La offline jamás lo iba a atrapar: la frase "¿me devolvéis la pasta?" no estaba en el dataset. La online sí puede verlo, porque corre sobre la conversación real que ocurrió.

La idea-ancla: los fallos de producción son el próximo dataset

Aquí cierra el arco del curso. En el N0·L1 viste el flywheel: Analizar → Medir → Mejorar, un ciclo donde el valor se compone. Anthropic lo describió en una frase que ahora cobra su sentido completo: "failures become test cases, test cases prevent regressions". Es decir: los fallos se vuelven casos de prueba, las pruebas previenen regresiones (Anthropic, Demystifying evals for AI agents, 9 ene 2026).

Lee con cuidado de dónde salen esos fallos. En el N1, salían de revisar trazas viejas a mano —"look at your data" (Husain & Shankar, 2025)—. A partir de N5, salen de producción, en vivo. El ciclo es el mismo, la fuente cambia.

Langfuse lo formula como un bucle explícito: offline pre-deploy → detectar problemas en producción → añadir esos casos al dataset → nueva iteración offline (Langfuse, core concepts). Cierra sobre sí mismo. El fallo del jueves no se queda en un tuit. Se etiqueta, entra al dataset del N1 como caso nuevo, y la próxima vuelta del gate offline ya lo protege. El reembolso fantasma deja de poder repetirse.

Esa es la diferencia entre un sistema que apaga incendios y uno que se mejora a sí mismo con su propio uso.

Un detalle que importa: no evalúas el 100%

Si la eval online corre sobre tráfico real, surge una pregunta de coste. ¿Evalúas todas las trazas de producción?

No. Evaluar el 100% del tráfico con tu LLM-as-judge multiplicaría tu factura por el número de requests. Por eso la eval online usa sampling: evalúas solo una fracción de las trazas —el 5%, por ejemplo— para controlar el coste (Langfuse, llm-as-a-judge). Cómo se configura ese muestreo y por qué un 5% basta es el tema de L2. Por ahora retén la idea: online no significa "todo". Significa "una muestra representativa, en vivo".

5.5Míralo funcionar: el flywheel completo de Aurora

No hay código que correr en esta lección. Lo que vamos a "ejecutar" es el mapa del bucle entero del curso sobre Aurora. Verás exactamente por dónde entra un fallo de producción y por dónde sale convertido en protección.

Lee la tabla entera primero. Después analizamos el punto de cierre.

Y aquí, en prosa, el cierre que la tabla no puede dibujar:

1   ┌─────────────────────────────────────────────────────────┐
2   │                                                         │
3   ▼                                                         │
4[dataset N1] → [gate offline N4] → [DEPLOY] → [eval online N5]│
5                                                  │          │
6                                                  ▼          │
7                                       el fallo de prod ─────┘
8                                       (se etiqueta y se añade
9                                        al dataset como caso nuevo)

Ahora la pregunta de auto-explicación. Responde antes de leer el análisis: ¿por dónde "entra" el reembolso fantasma del jueves, y por dónde sale convertido en protección permanente?

El fallo entra por la eval online del N5. Es el único punto del bucle que mira tráfico real; el gate offline no lo vio porque no estaba en el dataset. Una vez detectado, lo etiquetas y lo añades al dataset versionado del N1 —el mismo activo de siempre—. Ahí sale: en la próxima vuelta, el gate offline del N4 ya incluye ese caso. Lo que antes era invisible ahora bloquea cualquier regresión futura.

Fíjate en el detalle que cierra el curso entero: la flecha de salida del N5 vuelve al dataset del N1. El bucle se muerde la cola. El sistema se alimenta de su propio uso. Eso no existía mientras solo evaluabas offline. El gate del N4, por sí solo, es una línea recta que termina en el deploy y no ve nada después.

5.6Hazlo tú

Ejercicio 1 — andamiaje parcial

Te dan tres fallos detectados en producción del agente de Aurora. Para cada uno, decide si el gate offline del N4 lo habría atrapado antes del deploy. Te resuelvo el primero; completa los otros dos.

Fallo A. Una versión nueva del prompt rompe un caso que ya estaba en el dataset: Aurora deja de llamar a buscar_pedido para una consulta de estado que antes resolvía bien. → Resuelto: sí, lo atrapa el gate offline. El caso ya estaba en el dataset, así que la regresión se mide pre-deploy. El build falla antes de llegar a producción.

Fallo B. Un cliente pregunta "¿me devolvéis la pasta del pedido roto?" —jerga coloquial que tu dataset nunca recogió— y Aurora promete un reembolso inexistente. → Tú: ¿lo atrapa el gate offline? ¿Por qué sí o por qué no? ¿Qué tipo de eval lo detectaría?

Fallo C. Aurora escalar_a_humano de más: abre un ticket humano para una pregunta trivial de horarios que la KB respondía sola. El caso de horarios no estaba en el dataset. → Tú: ¿lo atrapa el gate offline? Justifica.

Antes de seguir, una pregunta de interrogación elaborativa. Respóndela tú primero: ¿por qué un gate offline en verde puede convivir con fallos reales en producción, sin que ninguno de los dos esté "roto"?

Piénsalo antes de leer la siguiente línea.

Porque cada uno opera sobre una distribución de inputs distinta. El gate evalúa la distribución que tú capturaste en el dataset. Producción genera la distribución real, que incluye fraseos, casos raros y jerga que aún no recogiste. El gate "verde" significa "no hay regresión en lo conocido", no "no hay fallos". Las dos afirmaciones son compatibles. Esa brecha entre las dos distribuciones es, exactamente, el hueco que la eval online cubre.

5.7Comprueba

Sin pistas. Aquí tienes tres situaciones del agente de Aurora. Para cada una, decide si es trabajo de eval offline, de eval online, o de ambas. Justifica con una frase.

Situación 1. Antes de mergear un cambio de prompt, quieres garantizar que no se rompe ninguno de los 120 casos de tu dataset etiquetado.

Situación 2. Llevas dos semanas en producción y sospechas que Aurora alucina políticas con fraseos coloquiales que nunca metiste en el dataset. Quieres medirlo sobre tráfico real.

Situación 3. Detectas en producción una conversación donde Aurora inventó el estado de un pedido. Quieres que ese fallo concreto no vuelva a pasar en futuras versiones.

5.8Conecta

Vuelve al reembolso fantasma del jueves.

Con solo el gate del N4, ese fallo era un tuit y un agujero negro. Pasó en producción, el gate estaba verde, y no tenías forma sistemática de saberlo hasta que un cliente lo gritó. Con el flywheel cerrado, ese mismo fallo recorre un camino. La eval online lo detecta sobre la traza real, lo etiquetas, entra al dataset, y la próxima vuelta del gate offline lo bloquea para siempre. El reembolso fantasma del N0·L1, por fin, deja de poder repetirse.

Este es el sexto giro del flywheel, el que lo cierra. El resto del nivel construye las piezas:

• En L2 instrumentarás los evals online de verdad: tu juez del N2 corriendo sobre trazas de producción, con sampling y a nivel de observación.
• En L3 añadirás la señal que da el propio usuario —feedback explícito e implícito—.
• En L4 decidirás con datos si una mejora mejora de verdad, mediante experimentos.
• En L5 monitorizarás la degradación con el tiempo.
• En L6 harás el cierre literal: convertir un fallo de producción en un caso nuevo del dataset. Es el checkpoint C5 y el cierre del curso.

¿Dónde lo aplicarías en tu trabajo? Piensa en cualquier sistema LLM que hayas desplegado. Si hoy un usuario tropieza con un fallo que tu suite de tests nunca contempló, ¿tienes forma de detectarlo sin esperar a que se queje? Si la respuesta es "no", ya sabes qué giro del flywheel te falta cerrar.

5.9Reflexiona

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

• Con tus palabras: ¿por qué un gate de CI en verde no garantiza que no haya fallos en producción?
• ¿Cuál es la diferencia operativa entre evaluar offline y evaluar online —no la definición, sino cuándo y sobre qué dato corre cada una?
• ¿Qué sigue sin estar claro? Si es "cómo configuro la eval online sin arruinarme en coste", es la pregunta correcta —la responde L2, con el sampling—.

Referencia rápida

• Eval offline: corre contra un dataset, antes de desplegar. Es el gate del N4. Protege contra regresiones de lo que ya conoces (Langfuse, core concepts).
• Eval online: corre sobre trazas de producción en vivo, en ingest time, asíncrona, sin bloquear al usuario. Ve la distribución real de inputs (Langfuse, core concepts).
• No compiten: offline responde "¿esta versión rompe algo?"; online responde "¿qué pasa de verdad ahí fuera?".
• Sampling: la eval online no evalúa el 100% del tráfico —por coste—, sino una fracción (p. ej. 5%). Detalle en L2 (Langfuse, llm-as-a-judge).
• El cierre del flywheel: offline pre-deploy → detectar en producción → añadir el caso al dataset → nueva iteración offline. Los fallos de producción son el próximo dataset (Langfuse, core concepts; Anthropic, 9 ene 2026: "failures become test cases").