La arquitectura dicta la eval

3.1Las zapatillas que sí se devolvían (según el bot)

Un cliente escribe a Aurora —la tienda online ficticia que ha sido tu banco de pruebas desde el Nivel 0—: "¿puedo devolver unas zapatillas que ya he usado?". El bot responde, seguro de sí mismo: "sí, tienes hasta 90 días".

La política real de Aurora dice otra cosa: 30 días, y solo si el producto está sin usar. La respuesta es fluida, segura y falsa. El cliente la guarda como prueba.

Tu juez de N2 —el evaluador LLM que calibraste y validaste— marca el caso como fallo de groundedness: la respuesta no se apoya en la política. Bien. Pero ese veredicto solo dice que está mal. No dice dónde nació el error.

Y hay tres lugares donde pudo nacer, con tres arreglos opuestos:

• ¿consultar_politica recuperó la política equivocada y el modelo respondió fielmente sobre basura?
• ¿La recuperó bien y el modelo la ignoró, inventando los 90 días?
• ¿El modelo nunca llamó a la tool y respondió de memoria?

Tres causas. Tres arreglos distintos. Una misma respuesta mala. Si tratas el fallo como una caja negra, arreglas a ciegas. Cambias el prompt cuando el problema estaba en el índice. O re-troceas la KB cuando estaba en el system prompt.

3.2Qué vas a poder hacer

Al terminar esta lección sabrás:

• Descomponer un fallo end-to-end del agente en tres capas de componente: retrieval, generación y orquestación.
• Atribuir una respuesta mala a la capa donde nació, leyendo la evidencia de su traza.
• Justificar por qué el veredicto agregado de un juez no localiza el fallo, y qué no puedes concluir solo con él.

Necesitas saber antes:

• De N0: qué es una traza explotable y qué spans tenía el agente (root, retrieval, LLM, tool).
• De N1: tu taxonomía de fallos y el dataset etiquetado que construiste.
• De N2: qué medía tu juez calibrado y por qué un score agregado no te dice dónde está el problema.

Esta lección no implementa métricas todavía. Aquí construyes el marco. Las métricas concretas —RAG triad, IR, trayectoria— llegan en L2 a L4. Sin este mapa, medirías sin saber qué aguja mirar primero.

3.3Recupera

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

1. De N0: la traza del agente Aurora tenía una jerarquía de spans. ¿Cuáles eran los tipos de span que instrumentaste?
2. De N1: tras revisar conversaciones reales, nombraste tus modos de fallo más frecuentes. ¿Cuáles eran los tres principales?
3. De N2: tu juez calibrado devolvía un veredicto por caso. ¿Qué te decía ese veredicto y qué no te decía?

Las respuestas anclan esta lección. La jerarquía de spans de N0 —root → retrieval → LLM → tool— es justo el árbol que ahora vas a medir por tramos. Sin esos spans separados, no podrías distinguir un fallo de retrieval de uno de generación: estarían fundidos en la misma caja negra.

Y el juez de N2 te daba un veredicto —"groundedness fail"— pero no su origen. Esa es la brecha exacta que abre el Nivel 3.

3.4El concepto: la arquitectura dicta dónde puede fallar

Empecemos por lo concreto y subamos a la idea general.

El agente tiene tres capas, y cada una falla distinto

El agente de Aurora no es un bloque monolítico. Es RAG más tool-calling: recupera contexto de una base de conocimiento y orquesta herramientas para actuar. Esa arquitectura tiene una consecuencia directa: sus fallos viven en tres capas distintas.

• Retrieval —la recuperación—. El paso que consultar_politica ejecuta sobre la KB. La pregunta de esta capa: ¿el contexto recuperado es relevante a la query? (corpus, frente D: context relevance, métricas IR).
• Generación —la producción de la respuesta dado ese contexto—. La pregunta: ¿cada afirmación de la respuesta se apoya en el contexto recuperado? (corpus: groundedness / faithfulness, answer relevance).
• Orquestación —la trayectoria de tool-calls—. Qué herramientas llamó, con qué argumentos, en qué orden. La pregunta: ¿llamó a las tools que debía, bien? (corpus, frente D: niveles de evaluación de agentes — trajectory).

Defino el término que sostiene el nivel.

La descomposición por componente es leer un fallo end-to-end —la caja negra que solo dice "respuesta mala"— como un fallo localizado en una capa concreta de la arquitectura. La analogía: en medicina, "el paciente tiene fiebre" es el síntoma end-to-end; "es una infección bacteriana en el oído izquierdo" es el diagnóstico por componente. El límite de la analogía: en un sistema LLM no hay un solo culpable garantizado. Dos capas pueden fallar a la vez. Por eso necesitas un orden de lectura, no una sola prueba.

El corpus (frente D) lo formula como tres niveles de evaluación de agentes. Outcome (caja negra: ¿completó la tarea?), trajectory (plan, pasos, tool calls, retries) y component (retrievers, modelos, sub-agentes, tools). El mapa de N3 baja del nivel outcome al nivel component.

Por qué una sola métrica no localiza

Aquí mucha gente se equivoca de instinto: cree que un score más alto o un único juez "mejor" resolverá el problema. No lo resuelve. Un veredicto end-to-end —"groundedness fail", "respuesta incorrecta"— es agregado por construcción. Comprime tres capas en un solo número. Por diseño, no puede decir en cuál de ellas nació el error.

Es la misma trampa que viste en N0 con el log plano frente a la traza. El log te dice que algo pasó; la traza estructurada te deja reconstruir cómo y por qué. Aquí pasa lo mismo un nivel más arriba. Un score te dice que la respuesta es mala; las métricas por componente te dejan reconstruir dónde.

Anthropic explica por qué los agentes son difíciles de evaluar precisamente por esto. Las capacidades que los hacen útiles —autonomía, uso de herramientas, estado— son las mismas que los hacen difíciles de medir. Los errores se propagan a lo largo de la cadena (Anthropic, Demystifying evals for AI agents, 9 ene 2026). Un fallo upstream contamina todo lo de abajo.

De ahí una heurística que ya viste en N1: fíjate en el primer fallo de la cadena. Si el retrieval recuperó basura, la generación "fiel a la basura" no es el problema de raíz; es un síntoma. El error upstream es la causa.

Contraejemplo: groundedness alta no es respuesta correcta

Cuidado con confundir dos cosas. Una respuesta puede estar perfectamente grounded —cada claim se apoya en el contexto recuperado— y aun así ser falsa. ¿Cómo? Si el contexto recuperado era el equivocado.

Imagina que consultar_politica recupera la política de envíos internacionales y el modelo genera una respuesta fielmente apoyada en ese chunk. La generación es impecable: cita el contexto al pie de la letra. Pero el contexto no responde la pregunta del cliente. Groundedness alta, respuesta mala. El fallo está en el retrieval, no en la generación.

Por eso ninguna métrica sola basta. Necesitas mirar las tres capas, y en el orden correcto.

3.5Míralo funcionar: una respuesta mala, tres traces

Vamos a ver el caso de las zapatillas en sus tres versiones. Misma pregunta del cliente, misma respuesta mala —"90 días"—, tres traces distintas que la produjeron. Lee primero las tres enteras. Después analizamos qué métrica distinguiría cada par.

Recuerda la jerarquía de spans de N0: root → retrieval → LLM → tool. Lo que cambia entre las tres traces es qué pasó en cada span.

Trace A — fallo de retrieval

1TRACE  conv_A  query="¿puedo devolver unas zapatillas usadas?"
2├─ tool  consultar_politica(tema="devoluciones")
3│    docs: [{chunk_id: "envios-intl-07", score: 0.29}]   ← política de ENVÍOS, no de devoluciones
4├─ llm  claude  in=query + 1 doc (envíos)  out="...90 días..."
5└─ respuesta  "Sí, tienes hasta 90 días."

El agente sí llamó a consultar_politica. Pero el paso de búsqueda recuperó el chunk equivocado: envios-intl-07, sobre envíos internacionales. El contexto es irrelevante a la pregunta. El modelo respondió sobre basura. El fallo nació en retrieval.

Trace B — fallo de generación

1TRACE  conv_B  query="¿puedo devolver unas zapatillas usadas?"
2├─ tool  consultar_politica(tema="devoluciones")
3│    docs: [{chunk_id: "devol-03", score: 0.88}]   ← política de DEVOLUCIONES correcta: 30 días, sin usar
4├─ llm  claude  in=query + 1 doc (devoluciones)  out="...90 días..."
5└─ respuesta  "Sí, tienes hasta 90 días."

Aquí el retrieval acertó: recuperó devol-03, el chunk correcto, con score alto. El contexto dice "30 días, sin usar". Pero el modelo inventó "90 días" e ignoró el contexto que tenía delante. La respuesta no se apoya en lo recuperado. El fallo nació en generación.

Trace C — fallo de orquestación

1TRACE  conv_C  query="¿puedo devolver unas zapatillas usadas?"
2├─ llm  claude  finish_reason=end_turn  (no se invocó ninguna tool)
3└─ respuesta  "Sí, tienes hasta 90 días."

No hay span de retrieval. El modelo nunca llamó a consultar_politica: respondió de memoria, sin consultar nada. El fallo nació en orquestación —la trayectoria de tools—.

Auto-explicación

Antes de leer el cierre, responde tú: ¿qué métrica distinguiría la Trace A de la Trace B? ¿Y la B de la C?

La A y la B se distinguen mirando el retrieval: en A el chunk recuperado es irrelevante; en B es correcto. Una métrica que mida la relevancia del contexto separa ambas. La B y la C se distinguen mirando si hubo retrieval: en B el agente llamó a la tool; en C no llamó a ninguna. Si no hubo retrieval, no hay contexto que medir —el fallo está en la trayectoria, y solo una evaluación de tool-calls lo detecta—.

Fíjate en lo que acabas de hacer: con el mismo veredicto end-to-end ("90 días, mal") has separado tres causas leyendo la estructura de la traza. Eso es la descomposición por componente, hecha tangible.

3.6Hazlo tú

Ejercicio 1 — andamiaje parcial

Un cliente pregunta a Aurora por el estado de su pedido. El bot responde "tu pedido llegó ayer", pero el cliente sigue esperándolo. Misma respuesta mala, tres orígenes posibles. Aquí tienes el cuadro a medio rellenar. Complétalo:

Ejercicio 2 — autónomo

Tienes tres traces de Aurora con el mismo síntoma: el bot afirma que un producto está en stock cuando no lo está. Sin mirar la solución, clasifica cada una en retrieval / generación / orquestación y nombra qué evidencia del span lo delata:

• Traza 1: no aparece span de tool; finish_reason=end_turn.
• Traza 2: buscar_pedido(order_id="ABC-123") devolvió "sin stock", pero la respuesta dice "en stock".
• Traza 3: consultar_politica recuperó un chunk de score 0.22 sobre "reposición de almacén", ajeno a la query.

Antes de seguir, una pregunta de interrogación elaborativa. Respóndela tú primero: ¿por qué empezar por la trayectoria —si llamó o no a las tools— antes que por la groundedness?

Porque los errores se propagan hacia abajo. Si el agente nunca llamó a consultar_politica, no hay contexto recuperado. Medir groundedness o relevancia del contexto no tiene sentido: no hay nada que medir. La trayectoria es el primer eslabón de la cadena. Si falla ahí, el resto del árbol de diagnóstico es ruido. Por eso se lee primero.

3.7Comprueba

Sin pistas. Te describo un fallo con su traza. Emite el veredicto de componente y di qué no podrías concluir solo con el veredicto end-to-end del juez.

Un cliente pide la política de garantía. El bot responde con la política de garantía de otra categoría de producto, plausible pero incorrecta para su caso. La traza muestra: consultar_politica(tema="garantía") recuperó el chunk garantia-electronica-02 con score 0.71; el cliente había comprado ropa, no electrónica. El modelo generó una respuesta fielmente apoyada en ese chunk. El juez de N2 marca "respuesta incorrecta".

3.8Conecta

Vuelve a las zapatillas. Hoy, ante el mismo veredicto "groundedness fail", ya no estás a ciegas. Sabes que detrás de esa etiqueta se esconden tres causas posibles —retrieval, generación, orquestación—, y que cada una pide un arreglo distinto. Lo que aún no tienes son los medidores para decidir cuál fue. Eso es el resto del nivel.

Este mapa es el esqueleto de N3:

• En L2 montarás la RAG triad: tres métricas que miden los vértices de retrieval y generación.
• En L3 harás zoom en el retriever con métricas IR clásicas: cómo de bien recupera, no solo si recuperó bien una vez.
• En L4 evaluarás la trayectoria: qué tools llamó el agente, con qué argumentos, y el principio outcome sobre transcript.
• En L5 unirás las tres familias en un árbol de diagnóstico que señala al culpable en orden.
• En L6 lo empaquetarás en la suite ejecutable que es el checkpoint C3.

¿Dónde lo aplicarías en tu trabajo? Piensa en cualquier sistema RAG o agéntico que hayas tocado. Cuando una respuesta sale mal, ¿sabrías decir si el fallo nació en lo que recuperó, en cómo generó, o en qué herramientas eligió? Si la respuesta es "no lo separo, lo trato como un fallo único", ya sabes qué te falta instrumentar.

Al final del nivel, ante el caso de las zapatillas, tu suite te dirá en segundos cuál de las tres causas fue.

3.9Reflexiona

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

• Con tus palabras: ¿por qué la arquitectura de un sistema "dicta" qué métricas necesitas para evaluarlo?
• ¿Por qué una respuesta puede estar perfectamente grounded y aun así ser falsa? ¿Qué capa falló entonces?
• ¿Qué sigue sin estar claro? Si es "cómo mido de verdad la relevancia del contexto o la calidad del retriever", es la pregunta correcta —la responden L2 y L3—.

Referencia rápida

• Tesis del nivel: la arquitectura dicta la eval. Una respuesta mala no es un fallo monolítico; puede nacer en tres capas, y métricas distintas localizan cada una.
• Las tres capas del agente Aurora:
  • Retrieval — ¿el contexto recuperado es relevante a la query? (lo mide context relevance / IR; L2-L3).
  • Generación — ¿la respuesta se apoya en ese contexto? (lo mide groundedness / answer relevance; L2).
  • Orquestación — ¿llamó a las tools correctas, con los args correctos? (lo mide tool-call / trajectory; L4).
• Tres niveles de evaluación de agentes (corpus, frente D): outcome (caja negra) → trajectory (pasos/tool calls) → component (retrievers/tools). N3 baja de outcome a component.
• Por qué los errores se propagan: autonomía + tools + estado; un fallo upstream contamina downstream (Anthropic, 9 ene 2026). De ahí: lee el primer fallo de la cadena primero.
• Contraejemplo clave: groundedness alta NO garantiza respuesta correcta si el contexto recuperado era el equivocado. Por eso ninguna métrica sola basta.
• Lo que un veredicto end-to-end NO te dice: en cuál de las tres capas nació el fallo. Por eso descompones por componente.