Módulo 8: RAG Evaluation + Proyecto Integrador
Introducción al Módulo: RAG Evaluation
Descripción de la cápsula
Llegaste al módulo final de la guía. Ya tienes un sistema RAG avanzado: chunking inteligente, query optimization, hybrid search, re-ranking, metadata filtering, infraestructura productiva en Pinecone con multi-tenancy. Tu sistema funciona, sirve tráfico real, escala y respeta aislamiento.
Pero hay una pregunta que no puedes contestar todavía: ¿responde bien?
No "¿es rápido?" — esa la contestaste con benchmarks en M07. Tampoco "¿es seguro?" — esa la cubriste con TenantContext y namespaces. La pregunta es la más fundamental y la más difícil de medir: ¿las respuestas que devuelve son correctas, fundamentadas en los documentos correctos y útiles para el usuario?
Sin un sistema de evaluación, la respuesta a "¿responde bien?" es opinión. "Probé tres queries y se vio bien" no es evaluación. "El equipo de producto dice que está bueno" no es evaluación. "Los usuarios no se quejan" definitivamente no es evaluación — los usuarios callados no son usuarios satisfechos, son usuarios que ya se fueron a otro producto.
Este módulo te enseña a transformar tu sistema RAG de un demo impresionante a un producto profesional con evaluación continua, métricas reproducibles, golden datasets versionados y quality gates en CI/CD que bloquean degradaciones antes de que toquen producción.
Al terminar tendrás la disciplina operacional que separa equipos que envían modelos a producción y rezan, de equipos que envían modelos con confianza basada en datos.
Objetivos del módulo 8
Al cerrar este módulo vas a poder:
- ✅ Explicar por qué la evaluación manual no escala y cómo se ve "evaluación rigurosa" para un sistema RAG
- ✅ Implementar las métricas core de RAGAS: faithfulness, answer relevancy, context precision, context recall
- ✅ Construir un golden dataset representativo del tráfico real, no de queries inventadas
- ✅ Automatizar el pipeline de evaluación para que corra en minutos, no horas
- ✅ Definir thresholds defendibles que bloqueen degradaciones reales sin generar ruido
- ✅ Integrar evaluación en GitHub Actions para que cada PR muestre impacto en calidad
- ✅ Entregar un proyecto integrador que reúne todo lo aprendido en la guía
Roadmap del módulo
| Cápsula | Tema | Resultado |
|---|---|---|
| 01 | Introducción | Mapa de cierre del sistema |
| 02 | Fundamentos de evaluación | Marco mental: qué medir y por qué |
| 03 | Métricas RAGAS core | Faithfulness, relevancy, precision, recall |
| 04 | Golden dataset | Dataset versionado con ground truth |
| 05 | Pipeline automatizado | Script reproducible de evaluación |
| 06 | Regression testing | Thresholds y quality gates |
| 07 | CI/CD con GitHub Actions | Evaluación en cada PR |
| 08 | Proyecto final | Advanced RAG System con evaluación |
Contexto de cierre de la guía
Tu progreso a través de la guía cubre cuatro fases:
- M1-M3: fundamentos de RAG avanzado (arquitectura, chunking, query optimization)
- M4-M6: precisión de retrieval (re-ranking, hybrid search, metadata filtering)
- M7: infraestructura de producción (Pinecone, multi-tenancy, benchmarking)
- M8: medición sistemática y disciplina operacional
Sin este último módulo, todo lo anterior es código bonito sin garantías. Con este módulo, tienes un sistema que mejora con evidencia, no con esperanza.
El problema que resuelve este módulo
Considera el escenario típico de un equipo sin evaluación sistemática:
Lunes: alguien hace un PR cambiando el prompt de generación. CI verde, tests unitarios pasan. Merge.
Miércoles: usuarios reportan que las respuestas se sienten "más vagas".
Jueves: el equipo bisecta git buscando el cambio. Tres PRs sospechosos. Nadie sabe cuál.
Viernes: revierten a ciegas y rezan. Lunes siguiente: vuelve el problema con un PR distinto.
Versus un equipo con evaluación sistemática:
Lunes: PR cambiando el prompt. CI corre evaluación contra golden dataset.
Lunes 14:23: bot comenta "faithfulness bajó 0.87 → 0.79 (-9%)". PR bloqueado.
Lunes 14:25: autor revisa, encuentra que el nuevo prompt acepta inferencias no soportadas. Ajusta.
Lunes 14:40: faithfulness 0.88. Verde. Merge.
La diferencia no es talento ni esfuerzo: es disciplina operacional traducida en automatización.
Conexión con el proyecto final
Tu proyecto del módulo es Advanced RAG System: la consolidación de toda la guía en un repositorio production-ready.
Entregables:
- Pipeline RAG completo integrado (chunking + expansion + hybrid + rerank + filter + generate)
- Golden dataset versionado con 100+ queries representativas y ground truth
- Pipeline de evaluación automatizada con RAGAS
- Thresholds calibrados y quality gates en GitHub Actions
- Dashboard de métricas históricas para detectar drift
Este es el portfolio piece que diferencia "estudié RAG" de "operé RAG con disciplina".
Límites del módulo
Para mantener el módulo enfocado, no cubrimos:
- ❌ Entrenamiento de evaluadores propios (LLM-as-judge fine-tuned). Usaremos GPT-4o-mini como juez, suficiente para 95% de casos.
- ❌ Benchmarking académico multi-dataset (BEIR, MTEB). Tu golden dataset es específico a tu producto.
- ❌ Observabilidad full-stack de infraestructura (tracing distribuido, profiling). Cubrimos métricas de calidad RAG, no de sistema.
- ❌ Human evaluation a escala (anotación con paneles). Asumimos que mantienes 100-200 queries con ground truth manual; herramientas como Label Studio están fuera de alcance.
Evidencia de éxito
Sabrás que dominaste el módulo cuando:
- ✅ Puedes correr la evaluación completa en menos de 5 minutos sobre 100 queries
- ✅ Detectas degradaciones de calidad antes de merge, no después de deploy
- ✅ Tu README final reporta métricas baseline (RAG simple) vs avanzado (este sistema) con números concretos
- ✅ Puedes contar la "historia cuantitativa" de la guía: "M3 query expansion +12% recall, M4 reranking +8% precision, M5 hybrid +5% recall en queries técnicas..."
- ✅ Cualquier PR que toque retrieval o generación dispara evaluación automática
Resumen
- La evaluación es parte del producto, no una tarea final opcional
- Métricas reproducibles + golden dataset + automatización = disciplina operacional
- CI/CD con quality gates previene degradaciones silenciosas
- Este módulo cierra la guía con un sistema portfolio-ready y profesional
- La diferencia entre "demo impresionante" y "producto serio" es exactamente esto
Recursos adicionales
- RAGAS Documentation - Framework oficial de evaluación RAG.
- RAG Evaluation - Humanloop - Enfoque práctico para producción.
- OpenAI Evals - Framework general de evaluación LLM.
- GitHub Actions Documentation - Automatización en repositorio.
- Hidden Technical Debt in ML Systems - Por qué evaluación importa más que arquitectura.
- Evaluating LLM Applications - Guía exhaustiva de Eugene Yan.
Creado: Marzo 13, 2026
Versión: 2.0