Cerrar el flywheel: el checkpoint C5

6.1El reembolso fantasma vuelve, esta vez de verdad

Es lunes por la mañana. Llevas semanas con Aurora en producción simulada, con todo lo que montaste en este nivel funcionando: evals online sobre tráfico real, feedback de usuario entrando como scores, un monitor de drift.

El monitor de drift que montaste en L5 dispara una alerta: la groundedness de Aurora cayó esta semana. Nadie tocó el código. Ningún deploy tuyo.

Abres las trazas —gracias al N0, las tienes y son explotables—. Filtras por groundedness baja y encuentras una conversación. Un cliente preguntó por su devolución. El paso RAG recuperó la política de envíos en lugar de la de reembolsos, y el agente prometió un reembolso que no corresponde.

Es el reembolso fantasma del N0·L1. Pero ya no es un ejemplo de apertura. Es real, está en producción, y ocurrió hoy.

Aquí está la pregunta que cierra el curso entero. No es "¿cómo lo arreglo?" —eso lo sabes desde N1—. Es esta:

¿Qué haces con ese fallo para que no vuelva a pasar nunca, de forma automática, sin depender de que tú estés mirando el dashboard el lunes correcto?

Esa pregunta tiene una sola respuesta honesta. Y construirla es el checkpoint C5.

6.2Qué vas a poder hacer

Al terminar esta lección sabrás:

• Componer las cinco piezas de N5 —evals online, feedback, experimento, drift y cierre— en un único flujo operativo sobre el agente de Aurora en producción.
• Convertir un fallo de producción en un caso nuevo del dataset versionado del C1, disparando otra vuelta del ciclo offline.
• Auto-evaluar tu entrega contra la rúbrica de cinco dimensiones del checkpoint C5, sabiendo qué se ve cuando fallas cada una.

Esta es la lección de mastery gate: la práctica es el checkpoint C5. No hay concepto nuevo. Hay integración — las piezas de los seis niveles ensambladas en un solo bucle que gira solo.

Necesitas saber antes:

• Haber completado L1–L5 de este nivel (o tener su equivalente: evals online, captura de feedback, plan de experimento, monitor de drift).
• Tener el dataset versionado del C1, el juez validado del C2 y el gate de CI del C4 en tu repo.
• El agente de Aurora instrumentado con Langfuse del C0, recibiendo tráfico simulado.

Si te falta alguna pieza, vuelve a la lección o al nivel que la construye antes de seguir. Este flywheel no se cierra a medias: un eslabón roto y el bucle no gira.

6.3Recupera: repaso mezclado de todo el curso

Antes de integrar, recupera. Este repaso cruza los seis niveles a propósito — el cierre del flywheel usa piezas de todos a la vez. Responde mentalmente; no mires lo de abajo hasta tener respuesta.

1. (L1 / N4) El gate de CI del C4 está verde y desplegaste. ¿Por qué eso no garantiza que Aurora no falle en producción?
2. (L2) Quieres evaluar la groundedness sobre tráfico real sin multiplicar tu factura. ¿Qué dos palancas usas, y qué tienes que verificar del juez antes de soltarlo en prod?
3. (L3) Un usuario pulsa el pulgar abajo; otro reformula la misma pregunta en el turno siguiente. ¿Cuál de las dos señales es más fiable y cuál más abundante?
4. (L4) Cambiaste el prompt y los thumbs up subieron del 71% al 74% en un día. ¿Por qué eso todavía no es razón para desplegar?
5. (L5) La groundedness cae sin que tú hayas tocado nada. ¿Qué campo de span te deja descartar que el proveedor cambió el modelo bajo tus pies?
6. (N1 / N2) Tienes un fallo de producción etiquetado. ¿En qué activo del curso entra como caso nuevo, y qué pieza decide si tu arreglo mejora de verdad?

Las respuestas, en orden:

1. Porque un eval offline solo conoce lo que ya está en tu dataset. Producción ve inputs con un fraseo que tu dataset nunca contempló — el gate no falla porque el caso no existía (corpus E.3; 03-arquitectura.md N5: los fallos de producción son el próximo dataset).
2. Sampling (p. ej. evaluar el 5% del tráfico) y evals a nivel de observación en vez de traza entera. Antes de prod, verifica que el juez supera TPR y TNR del 90% y que soporta structured output (corpus E.3; Langfuse, 12 sep 2025).
3. El pulgar abajo (feedback explícito) es más fiable pero de baja adopción; el retry (feedback implícito) es más abundante pero ruidoso — "informative yet noisy as a learning signal" (corpus E.6; Liu, Zhang & Choi, jun 2025).
4. Tres puntos en un día puede ser una mejora real o ruido de muestreo. La regla honesta: desplegar si el 95% CI bootstrap del delta pareado está sobre 0, no porque la media subió (corpus E.5).
5. El campo modelo + versión del span (lo capturaste en N0·L4). Un model update silencioso del proveedor es drift de output sin que toques nada; sin ese campo, no lo distingues de tu propio cambio (corpus E.4).
6. Entra en el dataset versionado del C1 como caso nuevo. Si tu arreglo es significativo, lo decide un experimento (A/B con CI), no tu opinión (corpus A.1, E.5).

Si dudaste en alguna, vuelve a su lección. Estas seis respuestas son los seis eslabones que vas a soldar hoy en un solo bucle.

6.4El concepto: el flywheel se cierra cuando el fallo vuelve al dataset

No hay pieza nueva. Hay una sola idea, la que sostiene el curso entero. Un fallo de producción no termina en un parche: se convierte en un caso permanente del dataset, que dispara otra vuelta del ciclo offline. Eso es cerrar el flywheel.

Veámoslo de lo concreto a lo abstracto.

El bucle completo del curso, sobre Aurora

Concretamente, esto es lo que recorre un fallo desde que ocurre hasta que queda imposible:

1PRODUCCIÓN (N5)
2   monitor de drift dispara (L5)  ──►  groundedness cae
3        │
4        ▼
5   localizas la traza culpable (L2: observation-level eval, N0: trazas explotables)
6        │
7        ▼
8   etiquetas el fallo y lo añades al DATASET VERSIONADO (C1, N1)  ◄── el cierre literal
9        │
10        ▼
11   corre el GATE OFFLINE con el caso nuevo (C4, N4)  ──►  build rojo: la regresión está capturada
12        │
13        ▼
14   propones la mejora y la validas con un EXPERIMENTO A/B (L4)  ──►  CI del delta sobre 0
15        │
16        ▼
17   el caso queda como REGRESIÓN PERMANENTE  ──►  el reembolso fantasma ya no puede volver

Cada flecha la construiste en un nivel. Hoy las conectas y compruebas que la última —el caso queda permanente— ocurre de verdad. El flywheel no es un diagrama bonito: es este recorrido, soldado.

Qué significa "cerrar el flywheel"

Defino el término que sostiene el checkpoint. El flywheel de evals es el ciclo iterativo Analizar → Medir → Mejorar que viste en el N0·L1; cada vuelta deja más fácil la siguiente porque el valor se compone. Cerrarlo significa que la última vuelta vuelve al principio: la salida del ciclo (un fallo detectado en producción) se convierte en la entrada del siguiente (un caso nuevo del dataset).

La analogía: un termostato. El termómetro que mide la temperatura es solo un monitor. El sistema se cierra cuando esa medición acciona la calefacción, que cambia la temperatura, que se vuelve a medir. Esa analogía tiene un límite: un termostato corrige solo. Tu flywheel todavía exige trabajo humano deliberado en cada vuelta —etiquetar, proponer la mejora, validar el experimento—. No hay inercia gratis.

Anthropic lo enmarca con precisión: los fallos se vuelven casos de prueba, las pruebas previenen regresiones, las métricas reemplazan a las corazonadas. (Traducción de "failures become test cases, test cases prevent regressions, and metrics replace guesswork" — Anthropic, "Demystifying evals for AI agents", 9 ene 2026.) La frase clave es la del medio: previenen regresiones. Ahí está el cierre — un fallo capturado como caso ya no vuelve.

"Look at your data", ahora sobre datos de producción

El acto fundacional del N0·L1 reaparece, transformado. Allí "mira tus datos" significaba revisar trazas para descubrir cómo falla el producto antes de medir (corpus A.2). Aquí significa lo mismo, pero la fuente de datos cambió: ya no son sesiones simuladas que tú generaste, sino el uso real del sistema.

El error analysis no terminó en N1. Se volvió continuo. Cada fallo de producción es una traza más que mirar — y el flywheel cerrado convierte ese mirar en un caso de eval, automáticamente versionado.

El contraejemplo: monitorizar no es cerrar

Aquí está el error que esta lección evita, y es el más común en entregas de C5.

• No es cerrar el flywheel tener un dashboard que avisa de la caída de groundedness. Eso es detectar. El monitor de L5 hace su trabajo, pero un fallo detectado y luego parcheado a mano —editas el prompt, despliegas, y el caso no queda registrado— vuelve a colarse con otro fraseo. Sin el caso en el dataset, no hay regresión que el gate del C4 pueda prevenir.
• No es cerrar el flywheel arreglar el fallo. Arreglar es necesario, no suficiente. El cierre exige que el fallo quede como caso permanente que dispara una iteración offline y queda protegido por el gate. La diferencia entre parchear y cerrar: el parche te protege de ese fallo hoy; el caso en el dataset te protege de su reaparición mañana.

6.5Míralo funcionar: el flujo end-to-end sobre Aurora

Esta es la demostración del flywheel cerrado. Es densa porque junta cuatro piezas de niveles distintos en una sola línea de tiempo. La estrategia: lee el flujo entero primero, luego sigue cada paso por separado. Nada aquí es API nueva — todo salió de L2–L5 y de los niveles previos.

El código usa solo la API verificada del SDK Python v4 de Langfuse. Importas el cliente con get_client(), que lee tus variables de entorno.

Paso 1 — la alerta dispara y localizas la traza

El monitor de drift de L5 ya disparó. Ahora localizas la conversación culpable. La groundedness baja la mide el eval online de L2 a nivel de observación, sobre el span de generación. Para que ese score llegara, tu instrumentación de producción usó propagate_attributes() — sin él, los filtros del evaluador por metadata no aplican sobre observaciones (corpus E.3; api-nivel5 §7c).

1from langfuse import get_client, propagate_attributes
2
3langfuse = get_client()
4
5with langfuse.start_as_current_observation(
6    as_type="span", name="soporte-aurora", input=mensaje
7) as root:
8    with propagate_attributes(
9        user_id=user_id,
10        session_id=session_id,
11        metadata={"env": "prod"},   # el evaluador online filtra por esto
12        version="1.2.0",
13    ):
14        with langfuse.start_as_current_observation(
15            as_type="generation", name="claude", model="claude-sonnet-4-6"
16        ) as gen:
17            # ... llamada al LLM del agente ...
18            gen.update(output=resp, usage_details={"input_tokens": a, "output_tokens": b})
19    root.update(output=final)
20langfuse.flush()

Self-explanation, antes de seguir: ¿por qué el eval online evalúa el span de generación y no solo la traza entera? Porque a nivel de observación localizas dónde falló. Es la localización del N3 llevada a producción: el span de retrieval o el de generación. ¿El fallo está en lo que se recuperó o en lo que se generó?

Paso 2 — etiquetas el fallo como score y como caso del dataset

Encontraste la traza. Dos cosas pasan con ella. Primero, registras el veredicto humano como score sobre esa traza concreta — esto deja constancia de que la revisaste, igual que un thumbs down explícito (L3). La firma de create_score es la verificada en api-nivel5 §3:

1# Etiquetas el fallo localizado: un score BOOLEAN sobre la traza culpable
2langfuse.create_score(
3    name="groundedness-fail",
4    value=0,                       # 0 = False: la respuesta NO estaba fundamentada
5    trace_id=trace_id_culpable,
6    data_type="BOOLEAN",
7    comment="Reembolso prometido sobre política de envíos mal recuperada",
8)
9langfuse.flush()

Segundo —y este es el cierre literal— conviertes la conversación en un caso nuevo del dataset versionado del C1. El input es lo que el cliente preguntó; el expected_output es lo que el agente debió responder (no lo que respondió). La firma es la de api-nivel5 §9a:

1# El CIERRE del flywheel: el fallo de prod entra al dataset del C1 como caso nuevo
2langfuse.create_dataset_item(
3    dataset_name="aurora-eval-dataset",       # el mismo dataset del C1
4    input={"mensaje": "¿Me devolvéis el dinero del pedido 12345?"},
5    expected_output={
6        "texto": "Ese pedido queda fuera del plazo de devolución de Aurora.",
7        "no_promete_reembolso": True,
8    },
9    metadata={"origen": "prod", "modo_fallo": "reembolso_fantasma", "fecha": "2026-06-08"},
10)

Self-explanation: ¿por qué el expected_output es lo que el agente debió decir y no lo que dijo? Porque el dataset define la verdad de referencia. Si guardas la respuesta errónea como esperada, conviertes el fallo en el objetivo — el bug se vuelve la especificación.

Paso 3 — el gate offline corre con el caso nuevo

El caso ya está en el dataset. Ahora corre el gate del C4 (N4) sobre el dataset ampliado. Con el prompt actual, el caso nuevo falla — el agente todavía comete el fallo, así que el build se pone rojo. Eso es exactamente lo que quieres: la regresión está capturada y el gate la ve.

1✕  Aurora evals gate — failing
2   pass rate 97.5% < 100% (1 caso nuevo de prod falla)
3   · groundedness "reembolso_fantasma (prod 2026-06-08)" → 0.35 < 0.70  FAIL
4   merge bloqueado hasta que se arregle

El caso de producción se ha vuelto un test. No depende de que recuerdes el incidente: el gate lo recuerda por ti.

Paso 4 — propones la mejora y la validas con un experimento

Arreglas la causa: el prompt ahora obliga a consultar consultar_politica con el tema correcto antes de prometer cualquier reembolso. Pero un arreglo que pasa el caso nuevo podría romper otros. Por eso lo validas con un experimento offline sobre el dataset entero, comparando dos variantes del prompt. La firma de run_experiment es la de api-nivel5 §9b:

1dataset = langfuse.get_dataset("aurora-eval-dataset")
2
3def run_variante_b(*, item, **kwargs):
4    """Variante B: el prompt mejorado consulta la política antes de responder."""
5    return call_aurora_agent(item.input, prompt_version="v2")
6
7result_b = dataset.run_experiment(
8    name="aurora-fix-reembolso-fantasma",
9    task=run_variante_b,
10)
11# Comparas result_b con el run de la variante A (prompt actual) en la UI de Langfuse:
12# Experiments → seleccionar ambos runs.

En producción, la decisión final entre A y B es un A/B con criterio estadístico (L4). Despliegas la variante B solo si el 95% CI bootstrap del delta pareado de groundedness está sobre 0. Estratificas por tipo de request para no caer en la paradoja de Simpson (corpus E.5). Recuerda: los porcentajes de rollout y los parámetros del cálculo muestral son heurísticos de blog, no doctrina.

El cierre

El caso queda en el dataset como regresión permanente. El reembolso fantasma del N0·L1 ya no puede volver: si un futuro PR lo reintroduce, el gate del C4 se pone rojo antes del merge, porque ahora el caso existe en el dataset.

Self-explanation final: ¿qué propiedad tiene este bucle que un parche manual no tiene? El parche protege de ese fallo hoy. El bucle cerrado protege de su reaparición mañana, automáticamente, sin que nadie recuerde el incidente. Esa es la diferencia entre apagar un fuego y montar un detector de humos.

6.6Hazlo tú: opera el flywheel de Aurora y ciérralo

Esta es la práctica, y es el checkpoint C5. El entregable, fiel al enunciado de 03-arquitectura.md: un dashboard de producción + un informe del experimento con veredicto basado en datos + un fallo de prod convertido en caso de eval (flywheel cerrado).

Paso 1 — andamiaje: completa la captura del caso de prod

Te doy el esqueleto del cierre. Rellena los dos huecos con criterio, no a ojo:

1# Un fallo de prod localizado: lo conviertes en caso del dataset del C1
2langfuse.create_dataset_item(
3    dataset_name="aurora-eval-dataset",
4    input={"mensaje": "<lo que el cliente preguntó>"},
5    expected_output={
6        # HUECO A: ¿qué pones aquí — lo que el agente respondió,
7        #          o lo que DEBIÓ responder? ¿por qué?
8        "texto": __________,
9    },
10    metadata={"origen": "prod", "modo_fallo": __________},   # HUECO B
11)

Interrogación elaborativa, antes de mirar la guía: ¿por qué el expected_output no puede ser la respuesta que dio el agente? Respóndelo tú primero.

Porque el dataset es la verdad de referencia contra la que mides. Si guardas la salida errónea como esperada, el gate del C4 dará por bueno justo el comportamiento que quieres prevenir — convertirías el bug en la especificación. El expected_output es lo que el agente debió decir según la política de Aurora.

Paso 2 — autónomo: monta las cuatro piezas de producción

Sin esqueleto. Sobre tu agente de Aurora en producción simulada:

1. Evals online (L2): configura en la UI de Langfuse un evaluador de groundedness sobre Live Observations, con sampling (p. ej. 5%) y filtro por metadata.env = prod. Verifica que tu instrumentación usa propagate_attributes(), o los filtros no aplicarán.
2. Feedback (L3): captura al menos una señal explícita (thumbs down como score BOOLEAN sobre la traza) y una implícita (un retry: el cliente reformula la misma pregunta).
3. Experimento (L4): compara dos variantes de una mejora con el CI bootstrap del delta pareado; decide con la regla "CI sobre 0", no con la media.
4. Drift (L5): define un monitor de input o output drift con su métrica (p. ej. PSI sobre la distribución de tipos de pregunta) y un umbral de alerta — marcando que el umbral PSI es heurístico.

Paso 3 — autónomo: cierra el flywheel

1. Toma un fallo detectado por tu monitor de drift o por un thumbs down.
2. Localiza la traza culpable a nivel de observación.
3. Etiquétalo como score y añádelo al dataset del C1 como caso nuevo (expected_output = lo que debió responder).
4. Corre el gate offline del C4 con el dataset ampliado y confirma que el caso nuevo falla con el prompt actual (build rojo).
5. Propón la mejora, valídala con el experimento del paso 2, y deja el caso como regresión permanente.

Si tu gate offline sale verde con el caso nuevo recién añadido, revisa dos cosas. Que el caso esté realmente en el dataset que corre el harness, y que el expected_output exija el comportamiento correcto (no el erróneo). Es un fallo común; lo normalizamos para que lo busques en el sitio correcto.

6.7Comprueba: la rúbrica C5

Este es el gate de maestría. Tu entrega se evalúa contra las cinco dimensiones del checkpoint C5, copiadas fiel de 03-arquitectura.md. Necesitas las cinco para superar el nivel y el curso.

Checkpoint C5: sobre el agente-hilo en "producción" (tráfico simulado): (a) evals online en Langfuse con sampling; (b) feedback de usuario (explícito/implícito) como scores; (c) un experimento (shadow/A-B) de una mejora, decidido con datos (CI/significancia); (d) un monitor de drift. Entregable: dashboard de producción + informe del experimento con veredicto basado en datos + un fallo de prod convertido en caso de eval (flywheel cerrado).

Rúbrica C5:

1. Online evals — sampling, observation-level, sobre trazas reales.
2. Feedback — explícito+implícito como scores; interpretación (ruido, reward hacking).
3. Experimento — shadow/canary/A-B; decisión por datos (CI bootstrap/significancia), no vibes.
4. Drift — qué monitoriza (input/output/semantic; PSI) + umbral/alerta.
5. Cierre del flywheel — un fallo de prod → caso nuevo del dataset → nueva iteración.

Feedback formativo por dimensión

Lee esto antes de entregar. Te dice qué se ve cuando fallas cada dimensión y cómo cerrar la brecha. Auto-evalúate con honestidad — el gate no te aprueba; te lo apruebas tú con evidencia.

Dimensión 1 — Online evals.

• Si está completo: tu evaluador corre sobre Live Observations (no traza entera), con sampling configurado, sobre trazas reales de prod filtradas por metadata. Y validaste el juez (TPR/TNR > 90%, structured output) antes de soltarlo.
• Si falla: síntoma típico — evalúas al 100% del tráfico (factura disparada) o a nivel de traza en vez de observación (no localizas el fallo). Otro síntoma: los filtros por metadata no aplican porque tu instrumentación no usa propagate_attributes() (corpus E.3; api-nivel5 §7c). Brecha: vuelve a L2, baja el sampling y mueve el score a observation-level. Siguiente paso: comprueba que el score aparece colgado de la observación, no solo de la traza.

Dimensión 2 — Feedback.

• Si está completo: capturas al menos una señal explícita (thumbs como score) y una implícita (retry/abandono), y en tu informe distingues cuál es fiable y cuál ruidosa — y nombras el riesgo de reward hacking.
• Si falla: síntoma — solo capturas thumbs (poca cobertura) o tratas un retry como verdad dura sin caveat. Otro síntoma más grave: optimizaste por la señal de feedback y subió, pero la groundedness del juez bajó — eso es reward hacking (corpus E.6; RLUF logró +28% Love Reactions con ese riesgo explícito). Brecha: añade la interpretación a tu informe — qué sesgo/ruido tiene cada señal. Siguiente paso: cruza la señal de feedback con el score del juez online; si divergen, no te fíes del feedback solo.

Dimensión 3 — Experimento.

• Si está completo: comparaste dos variantes con una regla de decisión estadística — el 95% CI bootstrap del delta pareado sobre 0 — y estratificaste por tipo de request. Tu veredicto cita el CI, no la media.
• Si falla: síntoma nº1 — decidiste "subió 3 puntos, desplegamos". Tres puntos en un día puede ser ruido de muestreo; esa es exactamente la vibe que el curso combate. Otro síntoma: agregaste todos los tipos de request y un estrato empeoró sin que lo vieras (paradoja de Simpson, corpus E.5). Brecha: calcula el CI bootstrap del delta y decide por "CI sobre 0". Recuerda el matiz: los porcentajes de rollout y los parámetros del tamaño muestral son heurísticos de blog (corpus E.5), no doctrina — márcalo en tu informe. Siguiente paso: estratifica y mira cada estrato.

Dimensión 4 — Drift.

• Si está completo: tu monitor declara qué mide (input, output o semantic), con una métrica concreta (p. ej. PSI sobre la distribución de tipos de pregunta) y un umbral que dispara alerta — y marcas el umbral PSI como heurístico.
• Si falla: síntoma — "monitorizo la calidad" sin definir qué distribución, qué métrica ni qué umbral; eso no es un monitor, es una intención. Otro síntoma: citas los cortes de PSI (<0.1, 0.1–0.2, >0.2) como estándar — son heurística de ML clásico tier 4, úsalos con caveat (corpus E.4; api-nivel5 §12). Brecha: vuelve a L5 y fija métrica + umbral + acción de alerta. Siguiente paso: añade el campo modelo+versión del span a tu monitor, para distinguir un model update del proveedor de tu propia regresión.

Dimensión 5 — Cierre del flywheel.

• Si está completo: un fallo de prod concreto entró en el dataset del C1 como caso nuevo, hizo el gate offline rojo, y quedó como regresión permanente tras validar la mejora. El bucle vuelve al principio.
• Si falla: síntoma más común — detectaste el fallo y lo parcheaste a mano, pero no lo añadiste al dataset. Eso es apagar un fuego, no cerrar el flywheel: el fallo vuelve con otro fraseo y nada lo previene. Otro síntoma: guardaste como expected_output la respuesta errónea (convirtiendo el bug en la especificación). Brecha: añade el caso con el expected_output correcto y confirma que el gate del C4 lo ve rojo antes del fix (corpus A.1, A.2). Siguiente paso: verifica que un PR que reintroduce el fallo ahora se bloquea.

Gate de maestría: necesitas las cinco dimensiones. La 3 y la 5 son las que más entregas fallan — la 3 separa una decisión por datos de una vibe, y la 5 separa monitorizar de aprender. Sin la 5, todo lo demás es un dashboard sofisticado que no cierra nada.

6.8Conecta: cierras el curso

Vuelve por última vez al reembolso fantasma. Apareció en el N0·L1, a las 9:14 de un martes, como un tuit que no podías explicar — no tenías datos, tenías vibes.

Recorre lo que ha cambiado:

• En N0 lo hiciste visible: instrumentaste a Aurora con trazas explotables. El agujero negro se volvió un registro.
• En N1 lo nombraste: error analysis sobre esas trazas, taxonomía y dataset etiquetado.
• En N2 construiste un juez validado contra humanos para medirlo a escala.
• En N3 montaste la suite que, ante un fallo, dice en qué componente está.
• En N4 lo convertiste en un gate que falla el build antes del deploy.
• En N5 cerraste el bucle: ese mismo fallo, ahora detectado en producción, vuelve al dataset y queda imposible.

El reembolso fantasma recorrió el curso entero y, en la última vuelta, dejó de ser un fallo recurrente para volverse un caso permanente. Eso es el viaje completo: de "no tienes datos, tienes vibes" a un sistema que se mejora a sí mismo con datos de su propio uso.

El flywheel ya gira solo en este sentido: cada fallo de producción que captures alimenta la próxima vuelta. No gira sin trabajo —cada vuelta exige que mires los datos, etiquetes y decidas con criterio—, pero ya no parte de cero. El valor se compone.

¿Dónde lo aplicarías en tu trabajo? Cualquier sistema LLM que hayas tocado es candidato a este bucle. La pregunta del N0 sigue siendo la prueba de fuego: si hoy llega una queja sobre una respuesta concreta, ¿puedes reconstruir qué pasó, medirlo, y convertirlo en un caso que impida que vuelva? Si la respuesta es "todavía no", ya sabes qué giro del flywheel te falta.

6.9Reflexiona

Tómate dos minutos. Estas preguntas miden si tu flywheel cierra o solo monitoriza — son la cara honesta de la dimensión 5:

• ¿Qué fallo de un sistema LLM real que conozcas habría quedado imposible con este bucle cerrado? Nómbralo. Si no se te ocurre ninguno, ¿es porque tu sistema no falla, o porque sus fallos nunca vuelven al dataset?
• De las cinco piezas de C5, ¿cuál te costó más montar? Esa es la que peor dominas — anótala como tu siguiente foco.
• ¿Qué sigue sin estar claro? Si es "cómo automatizo el etiquetado de fallos de prod a escala", es la pregunta correcta — es el frente abierto de la disciplina, y tu siguiente proyecto.

Terminaste el curso. No celebramos con confeti: lo que tienes ahora es una habilidad medible —eval literacy— que separa a quien construyó con LLMs de quien vio vídeos. El siguiente paso no es otra lección. Es aplicar este bucle a tu propio sistema.

Referencia rápida

• Cerrar el flywheel: que la salida del ciclo (un fallo en prod) vuelva a ser la entrada (un caso nuevo del dataset del C1). Monitorizar ≠ cerrar; parchear ≠ cerrar (corpus A.1: failures become test cases, test cases prevent regressions).
• El flujo C5: monitor dispara (L5) → localizas la traza (L2 observation-level + N0) → score + caso al dataset (create_score, create_dataset_item) → gate offline rojo (C4/N4) → mejora validada con experimento (L4) → regresión permanente.
• expected_output = lo que el agente DEBIÓ responder, nunca lo que respondió. Guardar la respuesta errónea convierte el bug en la especificación.
• API verificada (api-nivel5): create_dataset_item(dataset_name, input, expected_output, metadata); create_score(name, value, trace_id, data_type, comment); dataset.run_experiment(name, task); propagate_attributes(...) es obligatorio para que los filtros del evaluador online apliquen.
• Heurísticos marcados (no doctrina): porcentajes de rollout y parámetros del tamaño muestral (corpus E.5); cortes de PSI <0.1/0.1–0.2/>0.2 (corpus E.4, tier 4).
• Reward hacking: optimizar por la señal de feedback puede subir el feedback y bajar la calidad real (corpus E.6, RLUF). Cruza siempre feedback con el score del juez.
• No usar nunca: "85% de proyectos IA fallan (Gartner)" ni "80% (McKinsey)" — sin fuente primaria trazable.