Al final de 04-04 dejamos tres preguntas incómodas sin responder: ¿recupera el pipeline los chunks correctos?, ¿el umbral de 0.45 es sabio o casualidad?, ¿las respuestas son fieles a lo recuperado? En 02-04 aprendimos a evaluar prompts con un conjunto de 30-50 preguntas, una rúbrica binaria y un CSV — pero un sistema RAG añade una dificultad nueva: tiene dos motores que pueden fallar por separado. Si DocuBot responde mal, ¿fue porque la recuperación trajo chunks equivocados o porque la generación ignoró unos chunks correctos? Sin separar las dos preguntas, cada respuesta mala es un misterio y cada "mejora" es una apuesta a ciegas. Esta lección extiende nuestra infraestructura de evaluación al mundo RAG: anotaremos qué chunks debería recuperar cada pregunta del conjunto, implementaremos las métricas clásicas de recuperación (recall@k, precision@k, MRR) en Python llano, extenderemos la rúbrica de 02-04 con los criterios específicos de la generación con contexto, y montaremos la tabla de diagnóstico y los experimentos (k, tamaño de chunk, solape) que convierten las decisiones de diseño de 04-03 y 04-04 en decisiones con datos.

1. Dos motores, dos evaluaciones
2. Ampliar el conjunto de 02-04: anotar los chunks esperados
3. Métricas de recuperación: recall@k, precision@k y MRR
4. Métricas de generación en RAG: la rúbrica extendida
5. Diagnóstico por componentes: la tabla de síntomas
6. Experimentos: k, tamaño de chunk y solape

Sigamos una respuesta mala hasta su origen. Un usuario pregunta "¿cuántos miembros admite el plan Pro?" y DocuBot responde algo vago sobre invitaciones. Hay dos historias posibles:

• Falló la recuperación: el top-4 no incluía el chunk de "Planes y facturación" con el límite de 25 miembros. El LLM hizo lo correcto con lo que tenía — el problema está en el chunking, el modelo de embeddings, k o los filtros.
• Falló la generación: el chunk correcto estaba en el bloque <documentacion>, pero el modelo lo ignoró, lo malinterpretó o lo adornó. El problema está en el prompt, el modelo o el formato del bloque.

Las curas son disjuntas: rehacer el chunking no arregla un problema de prompt, y afinar el prompt no arregla un top-k que no trae la respuesta. De ahí el principio de esta lección:

Evalúa la recuperación sin el LLM, y la generación con recuperación conocida. Solo después evalúa el conjunto de punta a punta.

La buena noticia es que la mitad del trabajo ya está hecho: el conjunto de 02-04 (30-50 preguntas con sus 4 tipos de casos), la rúbrica binaria, el registro CSV y la disciplina de 3 ejecuciones por caso siguen siendo válidos. Solo hay que extenderlos.

Para medir la recuperación necesitamos la verdad terreno: para cada pregunta, qué chunks del corpus contienen su respuesta. Es trabajo manual y es la inversión más rentable de la lección — se hace una vez y sostiene todos los experimentos posteriores.

El proceso práctico: para cada pregunta del conjunto, buscar (a mano, leyendo la doc, ayudándose de recuperar() como sugerencia pero verificando a ojo) los ids de los chunks que responden. Los ids deterministas de 04-03 hacen esto posible: son estables entre re-ingestas.

Tres notas de anotación que evitan disgustos:

• Los casos "sin respuesta" (~20% del conjunto) llevan lista vacía — y son los que calibran el UMBRAL_RELEVANCIA de 04-04: en ellos, la similitud del mejor chunk debería quedar por debajo del umbral.
• Los ambiguos suelen tener varios chunks esperados: cualquier subconjunto razonable puede bastar para responder; las métricas lo tendrán en cuenta.
• La anotación caduca con el chunking: si cambias chunking.py (y por tanto los ids), hay que revisar la anotación. Otro motivo para versionar la estrategia de chunking como hicimos con PROMPT_VERSION.

Con la verdad terreno anotada, evaluar la recuperación no necesita LLM: se ejecuta recuperar() y se comparan ids. Las tres métricas estándar, cada una respondiendo una pregunta distinta:

Implementación en Python simple, sin dependencias:

Cómo leer esos números de ejemplo:

• recall@4 = 0.91: en el 91% de los casos (ponderado por chunks) lo necesario llegó al contexto. Los casos fallidos son la lista de trabajo: mirarlos uno a uno suele revelar patrones (¿todos de la misma página? ¿todos con vocabulario de usuario muy alejado de la doc?).
• precision@4 = 0.47 parece bajo, pero es normal: si una pregunta necesita 1 chunk y recuperamos 4, la precisión máxima es 0.25. La precisión se compara entre configuraciones (¿sube al bajar k?), no contra un ideal de 1.0.
• MRR = 0.86: el primer chunk relevante suele salir 1º o 2º — bien para nuestro orden "mejor primero".
• Y los casos sin respuesta tienen su propia medición: qué fracción de ellos queda por debajo del UMBRAL_RELEVANCIA (deberían: todos) frente a qué fracción de los casos fáciles queda por encima (deberían: todos). Esas dos cifras son la calibración del umbral que 04-04 dejó pendiente.

Supongamos recall alto: lo correcto llega al contexto. Falta evaluar qué hace el modelo con ello. Los tres criterios específicos de la generación con contexto recuperado:

1. Fidelidad al contexto (groundedness): ¿todo lo afirmado en la respuesta está respaldado por los chunks del bloque <documentacion>? Una respuesta puede ser verdadera y aun así infiel (el modelo lo sabía "de memoria" — inaceptable para DocuBot, regla 2 de SYSTEM_DOCUBOT).
2. Relevancia de la respuesta: ¿responde a esta pregunta, o resume correctamente los chunks sin contestar lo que se preguntó?
3. Uso correcto de fuentes: ¿el campo fuentes apunta a los chunks realmente usados y la respuesta no atribuye a una fuente algo que no dice? (Desde 04-04 las URLs las pone el sistema, así que aquí se vigila la atribución del contenido, no la existencia de la URL.)

En lugar de inventar una rúbrica nueva, extendemos la de 02-04: a sus 6 criterios binarios se añaden estos 3, y la evaluación sigue el mismo protocolo — juicio humano, binario (cumple/no cumple, sin medias tintas), 3 ejecuciones por caso por el no determinismo (01-04), registro en CSV:

Truco de evaluación que ahorra horas: como el pipeline registra qué chunks recuperó (el consejo final de 04-04), el evaluador humano puede juzgar la fidelidad leyendo solo esos chunks, no toda la documentación. Evaluar el criterio 7 de un caso pasa de minutos a segundos.

Este proceso es manual y no escala a cientos de casos — lo sabemos. En 06-03 veremos cómo automatizarlo usando un LLM como juez (LLM-as-judge) con esta misma rúbrica como base; la versión manual de hoy no es trabajo desechable sino el patrón oro contra el que se validará ese juez automático.

Con métricas de recuperación y de generación separadas, cada patología apunta a su componente. Esta tabla es la herramienta de trabajo diario:

La disciplina que la tabla impone: ante una respuesta mala, mira primero las métricas de recuperación del caso. Es un vistazo al CSV (¿estaban los chunks esperados en el top-k?) y bifurca el diagnóstico en dos caminos que no se mezclan. Sin esta disciplina, el instinto es siempre "tocar el prompt" — que solo cura la mitad de las enfermedades.

Las decisiones de 04-03 y 04-04 (chunks de ~450 tokens, solape de 300 caracteres, k=4, umbral 0.45) fueron puntos de partida razonados. Ahora pueden ser conclusiones. El método experimental es el de 02-04 — cambiar una variable cada vez, medir sobre el conjunto completo, registrar en CSV:

Resultados típicos de un barrido de k (tus números variarán):

El patrón es casi universal: el recall crece con k pero se aplana (el "codo"), la precisión cae monótonamente, y el coste por pregunta crece linealmente con k. La decisión es un compromiso informado — y con esta tabla, k=4 deja de ser "lo que dijo el curso" para ser "el codo de nuestra curva".

Los otros dos experimentos canónicos siguen la misma mecánica, con una diferencia operativa importante:

• Tamaño de chunk (TAM_MAX: probar p. ej. 1000 / 1800 / 3000) y con/sin solape (SOLAPE: 0 / 300): cada variación exige re-ejecutar ingesta.py (nuevo troceo → nuevos embeddings → re-poblar la colección) y, si cambian los ids, revisar la anotación. Son experimentos caros — por eso se hacen menos a menudo y se registran con CHUNKING_VERSION, para no repetirlos por olvido.
• La variable de generación (prompt, temperature) se experimenta con la rúbrica extendida, no con recall/precision — cada motor con sus métricas.

• Evaluar solo de punta a punta. "La respuesta es mala" sin saber si falló recuperación o generación lleva a arreglar el componente equivocado. Las métricas separadas existen para bifurcar el diagnóstico.
• Optimizar precision@k en abstracto. Con 1 chunk relevante y k=4, la precisión máxima es 0.25 y no significa que nada vaya mal. Compárala entre configuraciones; el recall es quien manda en RAG.
• Anotar los chunks esperados usando solo recuperar() como oráculo. Si anotas lo que el sistema ya devuelve, medirás que el sistema devuelve lo que devuelve: recall de 1.0 garantizado y falso. La anotación exige leer la documentación.
• Cambiar dos variables a la vez (k y el prompt, o chunk y umbral): la mejora —o el empeoramiento— quedará sin causa asignable. Una variable, una medición, una fila de CSV. La lección la aprendimos en 02-04 y en RAG duele el doble porque hay el doble de mandos.
• Olvidar los casos sin_respuesta al evaluar. Un sistema que responde algo al 100% de las preguntas tiene métricas de recuperación estupendas y un problema grave de honestidad. Las dos cifras de calibración del umbral son parte del cuadro de mando, no un extra.
• Consejo: fija umbrales de alarma sobre el conjunto (p. ej. "recall@4 ≥ 0.85 y cero casos sin_respuesta respondidos con contenido") y re-ejecuta la evaluación tras cada re-ingesta o cambio de versión. Es la versión RAG del presupuesto con alerta de 03-04 — y en 06-04 veremos cómo vigilar estas señales en producción de forma continua.

1. Completa la medición del umbral. Escribe evaluar_umbral(umbral) que recorra el conjunto y devuelva dos cifras: fracción de casos sin_respuesta correctamente rechazados (mejor chunk por debajo del umbral) y fracción de casos facil correctamente aceptados (por encima). Ejecútala para umbrales 0.30, 0.45 y 0.60 y elige con datos.
2. MRR a mano. Sin ejecutar código: tres preguntas cuyos chunks relevantes aparecen en las posiciones 1, 3 y (no aparece) del top-4. Calcula el MRR y explica qué acción de la tabla de diagnóstico dispararías si ese fuera tu valor global.
3. El caso que engaña. La pregunta "¿cuántas tareas admite el plan Pro?" obtiene: recall@4 = 1.0 (el chunk de límites está en el top-4, posición 2) pero la respuesta dice "hasta 500 tareas y 50 miembros" cuando la doc dice 25 miembros. ¿Qué criterios de la rúbrica fallan, cuál es el diagnóstico según la tabla, y qué dos acciones concretas probarías primero?

1. Estructura de la función:

Resultado típico: con 0.30 se aceptan todos los fáciles pero se "cuelan" varios sin_respuesta; con 0.60 se rechaza todo lo dudoso pero empiezan a caer fáciles legítimos; 0.45 suele dejar ambas cifras altas. Si ningún umbral separa bien ambas poblaciones, el problema no es el umbral: es que hay chunks engañosamente parecidos a preguntas sin respuesta — vuelve al chunking o añade a la doc una página explícita ("Métodos de pago admitidos") que dé al sistema algo correcto que recuperar.

2. MRR = (1/1 + 1/3 + 0) / 3 = 0.444. Es bajo, pero la tabla exige mirar el porqué antes de actuar: el tercer caso no es un problema de orden sino de recall (el chunk no aparece en absoluto), así que la acción correcta empieza en la fila "recall@k bajo" (chunking, k, embeddings) para ese caso; el segundo caso (posición 3) sí es de orden y apuntaría a reranking solo si el patrón se repite. Moraleja: MRR nunca se diagnostica solo — siempre junto al recall.

3. Fallan el criterio 7 (fidelidad: "50 miembros" no está respaldado por el chunk, que dice 25) y posiblemente el 9 (atribuye a la fuente algo que no dice); el 8 se cumple (responde la pregunta). Con recall perfecto y fidelidad rota, la tabla señala generación: el contexto llegó y el modelo lo alteró. Dos primeras acciones: (a) reforzar en prompt_respuesta() la instrucción de copiar cifras y límites literalmente de la documentación (y re-evaluar sobre el conjunto completo, no solo este caso — regla de 02-04); (b) comprobar la temperature de la llamada (decisión de 01-03: baja para DocuBot) por si algún cambio la subió. Si persistiera, mirar si el chunk mezcla los límites de varios planes en una tabla que el modelo lee mal — lo que devolvería el problema, curiosamente, al chunking: los diagnósticos son probables, no infalibles, y por eso se registra todo.

Con esta lección, el módulo 4 queda completo — y DocuBot deja de ser un pipeline que funciona en las demos para ser un sistema RAG que sabemos medir y diagnosticar: el conjunto de 02-04 tiene ahora anotados los chunks esperados de cada pregunta (con los casos sin_respuesta como calibradores del umbral), eval_rag.py mide la recuperación sin gastar un token de LLM (recall@k como métrica reina, precision@k y MRR como acompañantes que se leen juntas), la rúbrica de 6 criterios creció a 9 con la fidelidad al contexto, la relevancia y el uso de fuentes, la tabla de síntomas bifurca cada respuesta mala hacia su verdadero culpable —recuperación o generación, cada uno con sus curas—, y los experimentos con registro CSV convirtieron k=4, el tamaño de chunk y el solape de valores heredados en el codo medido de nuestra propia curva. Mirando atrás, el módulo 4 cumplió la promesa que cerraba el módulo 3: los embeddings pasaron de intuición a herramienta (04-01, con el caché semántico de regalo), la colección docs_nubelia dio memoria persistente y filtrable a la búsqueda (04-02), ingesta.py convirtió cientos de páginas en chunks con oficio y fuentes trazables (04-03), y responder_con_rag() llenó por fin, automáticamente, aquel bloque <documentacion> que el SYSTEM_DOCUBOT exigía desde 02-01 — enterrando al DocuBot ingenuo que inventaba exportaciones a PDF. Pero fíjate en el verbo que define todo lo construido: DocuBot sabe. Sabe lo que dice la documentación y lo cuenta con fuentes. Lo que todavía no puede es hacer: si un usuario pregunta "¿cuántas tareas tiene ahora mismo mi proyecto Atlas?", la respuesta no está en ninguna wiki — está en la API de Nubelia, a una llamada de distancia que DocuBot no puede realizar. Darle manos además de memoria es el salto del módulo 5: empezando por el function calling (05-01) — el mecanismo por el que el LLM deja de solo redactar respuestas y empieza a invocar nuestras funciones —, y siguiendo hasta convertir a DocuBot en un agente que razona, actúa y observa en bucle. La documentación ya la domina; ahora va a aprender a usar el producto.