De vibes a datos: por qué empezamos por ver

1.1El reembolso que nunca existió

Son las 9:14 de un martes. El agente de soporte de Aurora —una tienda online ficticia que será tu banco de pruebas todo el curso— lleva una semana en producción.

Un cliente tuitea una captura. En ella, el bot le promete un reembolso de 80 € por un pedido que, según la política de Aurora, no es reembolsable. El tuit acumula respuestas. Otros clientes preguntan cómo conseguir "su" reembolso.

Abres el código. El agente combina tres herramientas:

1def buscar_pedido(order_id: str) -> dict: ...   # estado/tracking de un pedido
2def consultar_politica(tema: str) -> str: ...   # recupera de la base de conocimiento (RAG)
3def escalar_a_humano(motivo: str) -> str: ...   # abre ticket humano

Y un bucle que las orquesta:

1def responder(mensaje: str, historial: list[dict]) -> str:
2    # bucle: LLM -> (¿tool_use?) -> ejecuta tool -> LLM -> ... -> texto final
3    ...

Quieres saber qué pasó en esa conversación. ¿Llamó a consultar_politica? ¿Recuperó la política correcta? ¿O se inventó la respuesta sin consultar nada?

No puedes responder. No hay registro de los pasos internos. Tienes el tuit y tienes el código, pero entre ambos hay un agujero negro.

No tienes datos. Tienes vibes.

1.2Qué vas a poder hacer

Al terminar esta lección sabrás:

• Explicar por qué la observabilidad va antes que las métricas en el ciclo de mejora de un sistema LLM.
• Definir qué hace que una traza sea "explotable": que con ella reconstruyas qué pasó en una request concreta.
• Distinguir un registro inservible de uno explotable, y justificar la diferencia.

Necesitas saber antes:

• Python a nivel de leer funciones y diccionarios.
• Haber llamado al menos una vez a una API de LLM (cualquier proveedor).

Esta lección no instrumenta nada todavía. Eso llega en L3, L4 y L5. Aquí construimos el porqué: si no entiendes qué hace falta ver, instrumentarás a ciegas y capturarás ruido.

1.3Recupera

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

1. Tienes un servicio web normal (sin IA) y una request devuelve un error 500. ¿Qué miras primero para depurarlo?
2. Ese método —logs, stack trace, breakpoints— se apoya en una propiedad del código. ¿Cuál?
3. El agente de Aurora "falló" pero no lanzó ninguna excepción. Devolvió texto fluido y plausible. ¿Por qué tu método de depuración de siempre no sirve aquí?

La respuesta a la 2 es determinismo: el mismo input produce el mismo camino de ejecución. Por eso un stack trace señala la línea culpable. Un LLM rompe esa propiedad. El fallo de Aurora no es una línea que peta; es una decisión —llamar o no a una tool, recuperar un chunk u otro— tomada dentro del modelo. No hay excepción que atrapar. El "error" es una respuesta perfectamente bien formada que dice algo falso.

1.4El concepto: ver es el primer giro del flywheel

Empecemos por lo concreto y subamos hacia la idea general.

El ciclo que hace que los evals se compongan

Los equipos que evalúan en serio no tratan la calidad como un acto único. La tratan como un ciclo. La metodología dominante lo estructura en tres fases iterativas: Analizar → Medir → Mejorar (Shankar & Husain, Evals for AI Engineers, O'Reilly, Early Release). Shankar y Husain son los autores de ese libro de O'Reilly y del curso de referencia del sector sobre evals; su material es la base técnica de este curso. (En su curso de Maven, los mismos autores nombran el ciclo "Build → Measure → Improve"; es el mismo ciclo con otra etiqueta.)

Llamamos a este ciclo el flywheel —volante de inercia—: cada vuelta deja más fácil la siguiente. La analogía con un volante físico tiene un límite: aquí no hay inercia gratis; cada giro requiere trabajo deliberado. Pero captura lo esencial: el valor se compone.

Anthropic lo describe con precisión. Los equipos con evals "actualizan modelos en días donde otros tardan semanas". El motivo, en sus palabras: los fallos se vuelven casos de prueba, las pruebas previenen regresiones y 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.)

Lee esa última frase otra vez: las métricas reemplazan a las corazonadas. Ese es el viaje de todo el curso, de vibes a datos. Y empieza por una pieza concreta.

"Look at your data" es el acto fundacional

Aquí mucha gente se equivoca de orden. La tentación es montar primero un dashboard de métricas genéricas —tasa de alucinación, toxicidad— y declarar victoria.

No funciona. El error analysis cualitativo precede a montar métricas: "no puedes saber qué medir hasta que averiguas sistemáticamente cómo falla tu producto" (Husain & Shankar, Lenny's Newsletter, 9 sep 2025). Empezar por métricas genéricas produce evals que no correlacionan con tus problemas reales.

Es común invertir el orden y empezar midiendo. Casi todo el mundo lo hace la primera vez. La diferencia clave: una métrica te da un número, no una comprensión. Un score de "3,72 hoy frente a 4,2 mañana" no te dice si el sistema mejoró ni dónde (Hamel Husain, erroranalysis office hours, 21 dic 2024).

El consejo operativo es contundente: empieza revisando 50–100 conversaciones reales y encuentra los modos de fallo más comunes. "Haz tú mismo el error analysis" (Hamel Husain, evals-faq, ene 2026).

Y ahí está la trampa que motiva todo el Nivel 0: para revisar 100 conversaciones reales, necesitas tenerlas registradas de forma que puedas reconstruir qué pasó. El tuit de Aurora demuestra que hoy no las tienes. Por eso el primer giro del flywheel no es medir. Es ver.

Qué hace una traza "explotable"

Defino el término que sostiene el nivel entero.

Una traza es el registro de qué ocurrió internamente al procesar una request. Una traza es explotable cuando te permite reconstruir esa request paso a paso. Es decir: qué entró, qué se recuperó, qué decidió el modelo, qué herramienta llamó, qué devolvió y qué salió.

La prueba de fuego es directa. Tomas el tuit de Aurora, abres la traza de esa conversación y respondes: ¿el bot llamó a consultar_politica? Si la traza te deja contestar con certeza, es explotable. Si te deja adivinando, es ruido.

Esto contrasta con un print() o un log plano. Un log de texto te dice que algo pasó. Una traza explotable te deja reconstruir cómo y por qué, con la estructura intacta.

El coste de no ver

Esta parte es la que convence a quien firma los presupuestos. Cuidado: el mercado de evals está lleno de cifras llamativas sin fuente. Usaremos solo datos con fuente primaria trazable.

Cuando un sistema LLM falla, rara vez explota de forma ruidosa. El modo de fallo dominante es silencioso. En la Stack Overflow Developer Survey 2025, la frustración nº1 con las herramientas de IA fue que el resultado es "casi correcto, pero no del todo" —el 66% lo señaló (SO Developer Survey 2025).

"Casi correcto, pero no del todo" describe exactamente el reembolso fantasma de Aurora: una respuesta fluida, segura y falsa. Ese es el fallo que no lanza excepciones y que, sin trazas, no sabes ni que ocurrió hasta que un cliente lo tuitea.

Los errores también existen en el sentido clásico, y son medibles. La telemetría de Datadog registró un 5% de llamadas a LLM con error en febrero de 2026, bajando al 2% en marzo (Datadog, "State of AI Engineering", abr 2026). Es telemetría de sus clientes, no del mercado entero; aun así marca el orden de magnitud. Si no ves esos spans de error, no puedes ni contarlos.

La conclusión une las dos cifras. Una parte de tus fallos grita (errores) y otra susurra ("casi correcto"). Sin trazas explotables, los ruidosos los descubres tarde y los silenciosos no los descubres nunca.

1.5Míralo funcionar: dos registros del mismo fallo

Vamos a ver, lado a lado, dos formas de registrar la conversación del tuit. Es el mismo fallo las dos veces. Cambia solo qué quedó grabado.

Lee primero ambos bloques enteros. Después analizamos qué pregunta puedes responder con cada uno.

Registro A — un log plano

1[2026-06-09 09:14:02] INFO  request recibida: "quiero el reembolso de mi pedido"
2[2026-06-09 09:14:05] INFO  respuesta enviada: "Claro, he tramitado tu reembolso de 80 €."
3[2026-06-09 09:14:05] INFO  request completada en 3.1s

Registro B — una traza estructurada

1TRACE  conv_8f3a  session=user_4471  total=3.1s
2├─ retrieval  consultar_politica(tema="reembolsos")        0.4s
3│    query: "reembolsos"
4│    docs: [{chunk_id: "envios-12", score: 0.31}]   ← política de ENVÍOS, no de reembolsos
5├─ llm  claude  in=téxt+1 doc  out=42 tokens          2.6s
6│    finish_reason: end_turn
7│    (no se invocó buscar_pedido)
8└─ respuesta  "Claro, he tramitado tu reembolso de 80 €."

Ahora la pregunta de auto-explicación. Antes de leer el análisis, responde: ¿qué pregunta puedes contestar con B que con A no?

Con el Registro A sabes dos cosas: el cliente pidió un reembolso y el bot dijo que sí. Nada más. No sabes si consultó la política, cuál recuperó, ni por qué decidió prometer el reembolso. Para depurar, te quedan las vibes: "a lo mejor el prompt está mal… probemos otro".

Con el Registro B reconstruyes la cadena causal:

• El agente sí llamó a consultar_politica. Descartas la hipótesis "se lo inventó sin consultar".
• Pero recuperó el chunk envios-12 —la política de envíos— con un score de 0,31. El paso de búsqueda recuperó el documento equivocado: trajo contenido que no responde a la pregunta del cliente. En N1 pondremos nombre a este tipo de fallo.
• El modelo respondió sobre ese contexto erróneo y nunca llamó a buscar_pedido, así que no verificó si el pedido existía.

Fíjate en el salto. Con A tienes una opinión. Con B tienes un diagnóstico con un sospechoso concreto: el retrieval. Esa es la diferencia entre vibes y datos, hecha tangible.

Un matiz honesto: en el Nivel 0 no arreglamos este fallo ni lo clasificamos formalmente. Eso es el trabajo del Nivel 1. Aquí solo lo hacemos visible. Una vez visible, es analizable. Mientras sea invisible, no existe para ti.

1.6Hazlo tú

Ejercicio 1 — andamiaje parcial

Un cliente reporta: "el bot me dijo que mi pedido había llegado, pero sigo esperándolo". Sospechas que el agente inventó el estado del pedido sin consultarlo.

Aquí tienes media lista de lo que necesitarías haber registrado. Complétala con los dos huecos:

• Si el agente llamó o no a buscar_pedido.
• El order_id que se pasó como argumento.
• __________ (pista: lo que la tool devolvió).
• __________ (pista: lo que el cliente vio al final).

Ejercicio 2 — autónomo

El agente de Aurora escaló de más: abrió un ticket humano para una pregunta trivial sobre horarios de entrega, que podía responder con la KB.

Sin mirar la solución, lista qué necesitarías haber registrado para diagnosticar por qué escaló en lugar de responder. Apunta al menos cuatro elementos.

Antes de seguir, una pregunta de interrogación elaborativa. Respóndela tú primero: ¿por qué registrar el finish_reason del modelo ayuda a entender un caso de "escaló de más"? Piénsalo antes de leer la siguiente línea.

Porque distingue por qué terminó el turno. ¿Eligió el modelo la herramienta escalar_a_humano deliberadamente? ¿Se cortó por límite de tokens? ¿Paró por otra causa? Sin ese campo, "escaló de más" y "se quedó sin espacio para responder" se confunden.

1.7Comprueba

Sin pistas. Aquí tienes tres registros de la misma conversación fallida. Decide cuál es explotable y justifica por qué los otros dos no lo son.

Registro 1

1{"nivel": "INFO", "msg": "respuesta generada", "duracion_ms": 2900}

Registro 2

1TRACE  conv_22b1  session=user_903
2├─ llm  claude  in=... out=...   finish_reason=tool_use
3│    tool_calls: [escalar_a_humano(motivo="cliente molesto")]
4├─ tool  escalar_a_humano  -> "ticket #5512 creado"
5└─ respuesta  "He pasado tu caso a un agente humano."

Registro 3

1print("entré al bucle de tools")
2print("salí del bucle")

1.8Conecta

Vuelve al tuit del martes a las 9:14.

Si la conversación del reembolso fantasma hubiera dejado una traza como el Registro B, no estarías adivinando. Abrirías esa traza y leerías, en treinta segundos, que el paso RAG recuperó la política de envíos en lugar de la de reembolsos. El agujero negro se vuelve un informe.

Eso es lo que vas a construir en este nivel. Esta lección plantó el porqué. El resto del Nivel 0 construye el cómo:

• En L2 modelarás la anatomía de una traza —los niveles que viste en el Registro B tienen nombres y jerarquía—.
• En L3, L4 y L5 instrumentarás el agente de Aurora de verdad, hasta producir trazas explotables del flujo RAG + tools completo.
• En L6 generarás el volumen —≥100 trazas reales— que el error analysis necesita. Ese dataset es el checkpoint C0, y es el insumo del Nivel 1.

Recuerda la idea que sostiene todo esto: no puedes mejorar lo que no puedes ver. La observabilidad no es un dashboard bonito; es la materia prima del análisis.

¿Dónde lo aplicarías en tu trabajo? Piensa en cualquier sistema LLM que hayas tocado. Si hoy llegara una queja sobre una respuesta concreta, ¿podrías reconstruir qué pasó en esa request? Si la respuesta es "no", ya sabes cuál es tu primer giro del flywheel.

1.9Reflexiona

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

• ¿Qué propiedad del código deja de cumplirse en un LLM y por eso el stack trace ya no basta?
• Con tus palabras: ¿qué hace que una traza sea "explotable" frente a un log cualquiera?
• ¿Qué sigue sin estar claro? Anótalo. Si es "qué campos exactos capturar", es la pregunta correcta —la responde L4—.

Referencia rápida

• Flywheel de evals: ciclo iterativo Analizar → Medir → Mejorar (los mismos autores lo etiquetan "Build → Measure → Improve" en su curso de Maven; es el mismo ciclo). El valor se compone: los fallos se vuelven casos de prueba (Anthropic, 9 ene 2026; Shankar & Husain, O'Reilly).
• Look at your data: el análisis cualitativo precede a las métricas. Revisa 50–100 conversaciones reales primero (Husain & Shankar, 2025–2026).
• Traza explotable: registro con el que reconstruyes una request paso a paso (entrada → retrieval → decisión del modelo → tool → salida).
• Prueba de fuego: ante una queja sobre una respuesta, ¿puedes contestar "¿llamó a X tool? ¿qué recuperó?" con certeza? Sí → explotable. No → ruido.
• Coste de no ver: 66% "casi correcto, pero no del todo" (SO Developer Survey 2025); 5% de llamadas con error en feb 2026 (Datadog).
• No usar nunca: "el 85% de proyectos IA fallan (Gartner)" ni "el 80% (McKinsey)" — cifras sin fuente primaria trazable.