El acto fundacional: look at your data

1.1El dashboard que subió sin que nada mejorara

Es lunes. Cierras el Nivel 0 con un activo: ≥100 trazas explotables del agente de soporte de Aurora, capturadas en producción. Es el checkpoint C0. Aurora es la tienda online ficticia que será tu banco de pruebas todo el curso.

Tienes el agente delante. Combina cuatro herramientas que ya conoces:

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
4def responder(mensaje: str, historial: list[dict]) -> str: ...  # bucle que orquesta las tres

La tentación es inmediata. Tienes los datos; monta ya las métricas. Configuras un evaluador de "hallucination" y otro de "calidad" sobre una escala del 1 al 5. Lo lanzas sobre las trazas.

El dashboard marca 3,72 hoy. Mañana cambias el prompt y vuelves a lanzarlo: 4,2. ¿Mejoró el sistema? ¿En qué? ¿Para quién?

No tienes ni idea. El número subió 0,48 puntos, pero no se refiere a ningún fallo que de verdad le pase a Aurora. La dirección te pregunta "¿qué arreglaste?" y solo puedes señalar un score que flota. Has medido sin haber mirado.

1.2Qué vas a poder hacer

Al terminar esta lección sabrás:

• Explicar por qué el análisis cualitativo de fallos precede a montar cualquier métrica.
• Distinguir una métrica genérica (hallucination, toxicity) de un criterio que emerge de mirar un fallo real, y argumentar por qué la primera no detecta el segundo.
• Identificar el fenómeno de criteria drift y reconocer, ante un escenario, cuándo "definir la rúbrica antes de mirar datos" es el error.

Necesitas saber antes:

• El concepto de traza explotable de N0·L1: un registro con el que reconstruyes una request paso a paso.
• El dataset C0 de N0·L6: las ≥100 trazas reales del agente de Aurora. Son el insumo literal de hoy.

Esta lección no codifica ni clasifica nada todavía. Eso empieza en L2 (open coding). Aquí construimos el porqué: si montas la métrica antes de mirar, mides el número equivocado con total precisión.

1.3Recupera

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

1. En N0 produjiste ≥100 trazas del agente, no 3. ¿Por qué hacía falta ese volumen para el análisis que viene?
2. ¿Qué hacía a una de esas trazas explotable frente a un log plano?
3. Tienes un score de "calidad" que pasa de 3,72 a 4,2 entre dos versiones del agente. ¿Qué no puede decirte ese número por sí solo?

La respuesta a la 2 la fijaste en N0: una traza es explotable cuando te deja reconstruir qué entró, qué se recuperó, qué decidió el modelo y qué salió. La 3 es el corazón de hoy. Un número agregado no te dice qué fallo bajó. Tampoco te dice si el fallo que le importa a Aurora entró siquiera en la cuenta. Mide una media, no una comprensión.

1.4El concepto: los criterios emergen de los datos

Empecemos por lo concreto —el score que flota— y subamos hacia el principio que lo explica.

El antipatrón del número que flota

Un score de "3,72 hoy frente a 4,2 mañana" no te dice si el sistema mejoró ni en qué (Hamel Husain, erroranalysis office hours, 21 dic 2024). El consejo del corpus es directo: empieza con una hoja de cálculo de conversaciones, no con métricas.

Es común invertir el orden y arrancar midiendo. Casi todo el mundo lo hace la primera vez —incluido yo—. Un dashboard da una sensación de control que una hoja de trazas sin clasificar no da. Pero la sensación de control no es comprensión.

Por qué no puedes elegir la métrica antes de mirar

Aquí está la tesis que vertebra el nivel entero. El error analysis cualitativo precede a montar métricas:

"No puedes saber qué medir hasta que averiguas sistemáticamente cómo falla tu producto." (Traducción de "You cannot know what to measure until you systematically find out how your product fails" — Husain & Shankar, Lenny's Newsletter, 9 sep 2025.)

Lee la frase despacio. No dice "es mejor mirar antes". Dice que no puedes saber qué medir hasta haber mirado. La métrica correcta no está disponible para ti hasta que conoces los fallos reales. Por eso el corpus es operativo: revisa 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).

Por qué las métricas genéricas fallan

Las métricas de catálogo —"hallucination", "toxicity"— vienen prefabricadas. Esa es su trampa: se definieron sin haber visto tu producto. Empezar por ellas produce evals que no correlacionan con tus problemas reales (Husain & Shankar, 9 sep 2025).

Un detector de toxicidad busca lenguaje ofensivo. El agente de Aurora rara vez es tóxico; es educado y fluido incluso cuando se equivoca. Su fallo dominante no es decir algo grosero. Es citar la política equivocada con un tono impecable. Una métrica de toxicidad puntúa eso como un 10 sobre 10. El fallo real le es invisible por construcción, no por casualidad.

Criteria drift: el nombre del fenómeno

Defino el término que sostiene la lección.

Criteria drift es la observación de que los criterios de evaluación emergen de observar outputs reales —no se definen a priori— porque mirar las salidas cambia tu idea de qué cuenta como bueno o malo. Lo formaliza el paper "Who Validates the Validators?" (Shankar et al., arXiv:2404.12272, abr 2024).

El término "drift" —deriva— viene de imaginar tus criterios desplazándose: cada traza que lees mueve un poco tu noción de "fallo". La analogía tiene un límite: no es un ruido aleatorio que conviene corregir; es la señal misma del aprendizaje. Aquí la deriva es deseable, porque te acerca a los fallos que importan.

De ahí sale la dependencia circular que da título al paper: necesitas criterios para evaluar outputs, pero solo descubres los criterios correctos evaluando outputs (Shankar et al., 2404.12272). No se rompe definiendo la rúbrica antes de tiempo. Se rompe mirando primero y dejando que la rúbrica se forme.

Dónde encaja esto en el flywheel

Recuerda el ciclo de N0: Analizar → Medir → Mejorar (Shankar & Husain, Evals for AI Engineers, O'Reilly, Early Release). N0 fue ver —instrumentar para producir trazas—. Hoy empieza Analizar: el primer giro real del flywheel. Mirar los datos no es un preámbulo al trabajo de evals. Es el trabajo de evals que hace válido todo lo que viene después.

1.5Míralo funcionar: dos enfoques sobre las mismas trazas

Vamos a evaluar las mismas 5 trazas de Aurora de dos formas. La (a) aplica una métrica genérica de catálogo. La (b) mira la traza y anota qué falló de verdad. El sistema es el mismo; cambia solo qué pregunta le haces a los datos.

Lee primero el bloque entero. Después analizamos qué vio cada enfoque.

Cargamos las trazas del C0 en una hoja de trabajo con pandas, como harás en todo el nivel:

1import pandas as pd
2
3# Export de las trazas del C0 (Langfuse → CSV, o lista de dicts):
4df = pd.read_csv("trazas_aurora.csv")
5df[["trace_id", "user_query", "tool_llamada", "respuesta_final"]].head(5)

1trace_id  user_query                              tool_llamada        respuesta_final
2conv_01   "¿puedo devolver estas zapatillas?"     consultar_politica  "Sí, la electrónica..."
3conv_02   "¿dónde está mi pedido 8841?"           (ninguna)           "Tu pedido llegó ayer."
4conv_03   "horario de entrega los sábados"        escalar_a_humano    "Te paso con un agente."
5conv_04   "quiero cambiar la talla"               consultar_politica  "Claro, el cambio es..."
6conv_05   "¿hacéis envíos a Canarias?"            consultar_politica  "Sí, en 3-5 días..."

Enfoque (a): métrica genérica de toxicity / hallucination

Aplicas un evaluador prefabricado de toxicidad sobre respuesta_final. Resultado: las 5 pasan. Ninguna respuesta es ofensiva. Todas son educadas. Señal de fallo detectada: cero.

1# (Pseudocódigo del resultado de un evaluador de toxicidad de catálogo)
2df["toxicity_pass"] = [True, True, True, True, True]   # 5/5 pasan: ningún lenguaje ofensivo

Enfoque (b): mirar la traza y anotar el primer fallo

Abres conv_01. El cliente pregunta por devolver zapatillas. La respuesta empieza "Sí, la electrónica...". Lees la traza y ves qué recuperó el paso RAG:

1TRACE  conv_01
2├─ retrieval  consultar_politica(tema="devoluciones")   0.4s
3│    docs: [{chunk_id: "devol-electronica-7", score: 0.29}]   ← política de ELECTRÓNICA
4├─ llm  claude  finish_reason=end_turn
5└─ respuesta  "Sí, la electrónica admite devolución en 14 días..."

Anotas, en lenguaje concreto, qué falló:

1df.loc[df["trace_id"] == "conv_01", "nota_open_coding"] = (
2    "citó la política de devoluciones de ELECTRÓNICA para una consulta de CALZADO"
3)

Ahora la pregunta de auto-explicación. Antes de leer el análisis, respóndela: ¿qué problema real captó (b) que (a) no podía ver ni en teoría?

El enfoque (b) descubrió el fallo dominante del agente: el paso RAG recupera la política equivocada y el modelo responde fiel a un contexto malo. El enfoque (a) nunca lo iba a ver. No porque el evaluador esté mal calibrado, sino porque mide un eje —¿es ofensivo el texto?— que es ortogonal al fallo —¿es la política correcta?—. Una respuesta puede ser cortés al 100% y estar al 100% equivocada.

Ese es el coste de elegir la métrica antes de mirar: no mides mal, mides otra cosa. Y el criterio que de verdad importaba —"¿la política citada corresponde al producto de la consulta?"— solo apareció porque miraste la traza. Emergió. No estaba en ningún catálogo.

1.6Hazlo tú

Ejercicio 1 — andamiaje parcial

Te doy un par "métrica genérica + traza fallida". Tu tarea: argumentar por qué la métrica no detecta ese fallo.

Métrica: answer fluency (¿la respuesta está bien escrita, gramatical, coherente?). Traza: el cliente pregunta "¿dónde está mi pedido 8841?". El agente responde "Tu pedido llegó ayer, ¡que lo disfrutes!" — sin haber llamado a buscar_pedido. El pedido sigue en tránsito.

Completa el argumento. Te dejo el inicio resuelto y dos huecos:

• La métrica de fluency mide la forma del texto, no su veracidad.
• La respuesta es perfectamente fluida: gramatical, cálida, coherente. Por tanto, la métrica la marca como __________.
• El fallo real es que el agente __________ (pista: mira qué tool no llamó), así que su afirmación sobre el pedido no está fundamentada en ningún dato.

Ejercicio 2 — autónomo

Te doy solo una traza, sin métrica. Tu tarea: decir qué criterio emergería de mirarla —el criterio que usarías para evaluar este tipo de caso de ahora en adelante—.

Traza: el cliente pregunta "¿a qué hora entregáis los sábados?". El agente llama a escalar_a_humano(motivo="consulta de horario") y responde "Te paso con un agente humano". La base de conocimiento contenía la respuesta.

Escribe el criterio en una frase, en la forma "¿...? pass/fail". No mires la respuesta hasta tenerlo.

Antes de seguir, una pregunta de interrogación elaborativa. Respóndela tú primero: ¿por qué este criterio no podías haberlo escrito antes de mirar las trazas de Aurora?

Porque no sabías que el agente escalaba de más. "Escalar consultas que la KB ya responde" no es una métrica de catálogo: es un fallo específico del comportamiento de este agente, sobre este producto. Solo se vuelve un criterio cuando lo ves ocurrir. El criterio emergió de la traza —eso es criteria drift en acción—. Una posible formulación: "¿el agente intentó responder con la KB antes de escalar? pass/fail".

1.7Comprueba

Sin pistas. Aquí tienes tres escenarios. Decide en cuál se comete el error de "definir la rúbrica antes de mirar datos". Justifica por qué los otros dos no lo cometen.

Escenario A. Un equipo abre 80 trazas del agente, anota a mano qué falló en cada una y después nota que el patrón más común es "recupera la política equivocada". Construye su criterio de evaluación a partir de ese patrón.

Escenario B. Un equipo, antes de mirar ni una traza, copia una rúbrica de 5 puntos de un blog ("claridad, tono, precisión, completitud, seguridad") y la fija como la métrica oficial de calidad del agente.

Escenario C. Un equipo mira 30 trazas, define un criterio binario "¿la política citada corresponde al producto?", y al revisar 30 trazas más descubre un fallo nuevo —escalados innecesarios— y añade un segundo criterio.

1.8Conecta

Vuelve al dashboard del lunes que marcaba 3,72 y luego 4,2.

Hoy sabrías leerlo con honestidad: ese número no medía nada que le pasara a Aurora. Subió 0,48 puntos sobre un eje genérico que jamás vio el fallo dominante —la política equivocada— ni el escalado de más. Antes lo llamabas "mejora". Ahora lo llamas lo que es: ruido con dos decimales.

Has visto por qué mirar va primero. Pero mirar no es opinar. "Citó mal una política" en tu cabeza no es un dato hasta que lo registras de forma reproducible. El resto del nivel convierte el mirar en método:

• En L2 conviertes el "mirar" en open coding: anotas el primer fallo de cada una de tus ≥100 trazas, con notas concretas y reproducibles.
• En L3 agrupas esas notas en una taxonomía, las cuentas y priorizas el fallo nº1.
• En L4 y L5 ese fallo nº1 se vuelve un dataset etiquetado —el activo que N2 a N5 reutilizan—.

¿Dónde lo aplicarías en tu trabajo? Piensa en cualquier sistema LLM que evalúes hoy. ¿Tu métrica salió de mirar fallos reales, o la copiaste de un catálogo antes de ver un solo output? Si fue lo segundo, ya sabes cuál es tu primer giro del flywheel.

1.9Reflexiona

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

• Con tus palabras: ¿por qué "no puedes saber qué medir hasta averiguar cómo falla tu producto"?
• ¿Qué es la dependencia circular de criteria drift, y por qué no se resuelve fijando la rúbrica antes de tiempo?
• ¿Qué sigue sin estar claro? Si es "vale, ¿y cómo anoto los fallos de forma reproducible?", es la pregunta correcta —la responde L2—.

Referencia rápida

• Look at your data: 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). Operativo: revisa 50–100 conversaciones reales primero (Hamel Husain, evals-faq, ene 2026).
• Antipatrón del score flotante: "3,72 hoy vs 4,2 mañana" no dice si el sistema mejoró ni en qué (Hamel Husain, erroranalysis office hours, 21 dic 2024). Empieza con una hoja de trazas, no con métricas.
• Por qué fallan las métricas genéricas: hallucination/toxicity se definen sin ver tu producto → no correlacionan con tus problemas reales (Husain & Shankar, 9 sep 2025). El fallo dominante de Aurora (política equivocada) es invisible para un detector de toxicidad.
• Criteria drift: los criterios de evaluación emergen de observar outputs, no se definen a priori; dependencia circular (Shankar et al., "Who Validates the Validators?", arXiv:2404.12272, abr 2024).
• Flywheel: N0 fue ver; N1 abre Analizar, el primer giro real (Shankar & Husain, Evals for AI Engineers, O'Reilly, Early Release).
• No usar nunca: "el 85% de proyectos IA fallan (Gartner)" ni "el 80% (McKinsey)" — sin fuente primaria trazable.