Plan del curso — Fundamentos de RAG

Fecha: 2026-06-02

Documentos fuente: course.brief.md, research/rag-ecosystem-2026.md, decisions.md

Estado: Plan inicial aprobado para desarrollo de unidades

---

1. Datos generales

---

2. Propósito y promesa

Propósito (del brief): Que los participantes comprendan, implementen y evalúen sistemas RAG desde sus fundamentos teóricos hasta su puesta en práctica, integrando LLMs con motores de búsqueda vectorial.

Promesa de aprendizaje: Al finalizar, el estudiante será capaz de diseñar, implementar y evaluar un sistema RAG funcional que tome documentos de dominio específico y responda preguntas en lenguaje natural con respuestas relevantes y fieles al contenido fuente, usando embeddings, índices vectoriales y un LLM integrado en un pipeline completo.

---

3. Ruta de aprendizaje — Secuencia de unidades

Mapa de la ruta

---

Unidad 1: Introducción a RAG — De la Recuperación a la Generación

• Tipo de experiencia: conceptual-clarity (75%) + guided-practice (25%)
• Promesa de aprendizaje: Comprender qué es RAG, por qué es necesario y cómo se compara con búsqueda tradicional y LLMs puros.
• Evidencia observable: El estudiante explica con sus palabras la arquitectura RAG en 3 fases, identifica escenarios donde RAG supera a LLM puro y a búsqueda tradicional.
• Formato del artefacto: Markdown (source/units/unit-1.md)
• Contenido mínimo:

1. Problema: LLMs alucinan, tienen conocimiento estático, no acceden a datos privados.
2. Solución RAG: Retrieve → Augment → Generate.
3. Arquitectura general: ingestion pipeline vs. query pipeline.
4. Comparación: RAG vs. búsqueda tradicional vs. fine-tuning vs. prompting largo.
5. Ejemplo walkthrough: asistente FAQ sobre manual de producto.
6. Configuración del entorno: Python 3.11+, dependencias (langchain, chromadb, faiss-cpu, ollama).

• Conexión con anterior: (primera unidad)
• Conexión con siguiente: La Unidad 2 materializa el primer componente técnico: embeddings e índices.
• Decisiones de diseño reflejadas: LangChain como framework (#4), chunk size 256-512 como referencia (#11).

---

Unidad 2: Embeddings y Búsqueda Semántica

• Tipo de experiencia: guided-practice (70%) + conceptual-clarity (30%)
• Promesa de aprendizaje: Implementar un motor de búsqueda semántica con embeddings e índices vectoriales, comprendiendo las propiedades de los modelos de embedding.
• Evidencia observable: El estudiante indexa un conjunto de documentos en FAISS, ejecuta consultas en lenguaje natural y mide precision@k y recall@k.
• Formato del artefacto: Notebook Jupyter (source/units/unit-2.ipynb)
• Contenido mínimo:

1. Qué es un embedding: representación densa, espacio semántico, similitud coseno.
2. Modelos de embedding: BAAI/bge-small-en-v1.5 como default ejecutable en CPU; BGE-M3 y OpenAI text-embedding-3-small como alternativas de producción/API.
3. Indexación vectorial: FAISS con índice plano (brute-force) vs. HNSW (aproximado).
4. Ejercicio: indexar documentos, hacer consultas, medir precision@k, recall@k y relevancia parcial.
5. Discusión: trade-off open-source vs. API, rendimiento vs. costo.

• Conexión con anterior: Unidad 1 introdujo el pipeline; aquí se construye el primer componente real.
• Conexión con siguiente: Unidad 3 enseña cómo segmentar documentos antes de embedderlos.
• Decisiones de diseño reflejadas: embeddings locales con Sentence-Transformers (#6), chunk size inferido (#11), FAISS como índice vectorial (#8).

---

Unidad 3: Estrategias de Chunking

• Tipo de experiencia: decision-lab (60%) + guided-practice (40%)
• Promesa de aprendizaje: Segmentar documentos con distintas estrategias y medir experimentalmente su impacto en recall y precisión de recuperación.
• Evidencia observable: El estudiante ejecuta un experimento comparativo (fixed-size, recursive, semantic) sobre el mismo corpus y presenta una tabla con recall por estrategia.
• Formato del artefacto: Notebook Jupyter con experimentos documentados (source/units/unit-3.ipynb)
• Contenido mínimo:

1. Por qué chunking importa: contexto de LLM, granularidad de recuperación.
2. Estrategias: fixed-size, recursive splitting y semantic chunking.
3. Experimento comparativo: mismo corpus, mismo retriever, misma consulta; medir recall@k.
4. Metadata-enriched chunking: añadir título, sección, fecha como metadata.
5. Análisis: ¿cuándo cada estrategia gana? Referencia Vecta Benchmark (recursive 69% vs semantic 54%).

• Conexión con anterior: Unidad 2 estableció embeddings; ahora se aprende a preparar los documentos fuente.
• Conexión con siguiente: Unidad 4 usa los chunks producidos para construir retrievers avanzados.
• Decisiones de diseño reflejadas: Chunking como módulo central (#5), chunk size 256-512 (#11), recursive vs. semantic benchmark (#5).

---

Unidad 4: Retrieval — Denso, Disperso e Híbrido

• Tipo de experiencia: guided-practice (65%) + decision-lab (35%)
• Promesa de aprendizaje: Construir retrievers denso (FAISS), disperso (BM25) e híbrido (RRF), añadir reranking con cross-encoders, y medir la mejora de cada combinación.
• Evidencia observable: El estudiante implementa 4 variantes (dense-only, sparse-only, hybrid-RRF, hybrid+reranker) y reporta P@k, recall@k y MRR.
• Formato del artefacto: Notebook Jupyter (source/units/unit-4.ipynb)
• Contenido mínimo:

1. Retrieval denso (FAISS HNSW): búsqueda semántica.
2. Retrieval disperso (BM25 con rank_bm25): matching exacto de términos.
3. Fusión híbrida con Reciprocal Rank Fusion (RRF).
4. Reranking con cross-encoder (cross-encoder/ms-marco-MiniLM-L-6-v2) como opción ligera en CPU.
5. Benchmark comparativo: P@k, recall@k, MRR e interpretación de métricas en cero.

• Conexión con anterior: Unidad 3 produjo chunks; ahora se construyen retrievers sobre esos chunks.
• Conexión con siguiente: Unidad 5 integra los retrievers con un LLM para completar el pipeline.
• Decisiones de diseño reflejadas: Hybrid retrieval (BM25 + Dense + RRF) (#10), reranking como módulo propio (#9), FAISS como índice (#8).

---

Unidad 5: Integración con LLMs — Locales y Cloud

• Tipo de experiencia: guided-practice (70%) + conceptual-clarity (30%)
• Promesa de aprendizaje: Orquestar un pipeline RAG completo con un LLM local (Ollama) y una alternativa cloud opcional (OpenAI), comparando respuesta y diagnóstico de contexto.
• Evidencia observable: El estudiante ejecuta un pipeline RAG end-to-end, inspecciona chunks recuperados y documenta diferencias entre LLM puro y RAG.
• Formato del artefacto: Notebook Jupyter (source/units/unit-5.ipynb)
• Contenido mínimo:

1. Arquitectura del pipeline: query → retrieve → augment → generate.
2. Prompt templates para RAG: instrucción, contexto y pregunta.
3. LLM local con Ollama: gemma4:latest u otro modelo disponible.
4. LLM cloud con OpenAI: GPT-4o-mini como alternativa opcional.
5. Diagnóstico: consulta → chunks recuperados → prompt → respuesta.
6. Comparación: LLM puro vs RAG, consultas literales/inferenciales/fuera de contexto.

• Conexión con anterior: Unidad 4 construyó retrievers; aquí se añade el generador.
• Conexión con siguiente: Unidad 6 evalúa formalmente el pipeline completo.
• Decisiones de diseño reflejadas: LangChain como framework (#4), Ollama + API cloud (#8), swap de modelo (#8).

---

Unidad 6: Evaluación de Sistemas RAG

• Tipo de experiencia: decision-lab (60%) + guided-practice (40%)
• Promesa de aprendizaje: Evaluar un pipeline RAG con métricas de respuesta y contexto, diagnosticar fallos y proponer mejoras.
• Evidencia observable: El estudiante define consultas con evidencia esperada, ejecuta evaluación con DeepEval cuando esté disponible y calcula métricas manuales de contexto.
• Formato del artefacto: Notebook Jupyter (source/units/unit-6.ipynb)
• Contenido mínimo:

1. Cuatro dimensiones: faithfulness, answer relevancy, context precision, context recall.
2. Construcción de consultas con evidencia esperada.
3. Evaluación con DeepEval para métricas de respuesta cuando el runtime lo permita.
4. Cálculo manual de métricas de contexto.
5. Diagnóstico de discrepancias entre respuesta y contexto.
6. Estrategias de mejora: chunk size, retrieval, reranking, prompt engineering.

• Conexión con anterior: Unidad 5 proveyó el pipeline a evaluar.
• Conexión con siguiente: Unidad 7 consolida todo en un proyecto completo.
• Decisiones de diseño reflejadas: DeepEval para métricas de respuesta (#12), RAGAS como referencia conceptual (#7), métricas manuales de contexto.

---

Unidad 7: Proyecto Final — Asistente RAG sobre Corpus Real

• Tipo de experiencia: project-builder (100%)
• Promesa de aprendizaje: Implementar un sistema RAG completo sobre un corpus de elección del estudiante, evaluarlo formalmente y documentar resultados, decisiones y limitaciones.
• Evidencia observable: El estudiante entrega un notebook ejecutable con el pipeline completo, un informe estructurado, y una tabla de métricas de evaluación.
• Formato del artefacto: Notebook Jupyter + informe Markdown (source/units/unit-7.ipynb, source/units/unit-7-report.md)
• Rúbrica de evaluación:
• Pipeline completo funcional (ingestión, chunking, embeddings, retrieval, generación) → 30%
• Evaluación con DeepEval y/o evaluación manual de contexto → 20%
• Análisis de decisiones de diseño (chunking, retrieval, modelo) → 20%
• Calidad del informe (claridad, estructura, hallazgos) → 20%
• Reproducibilidad (requirements.txt, seeds, instrucciones) → 10%
• Conexión con anterior: Integra todas las habilidades de Unidades 1–6.
• Conexión con siguiente: (unidad final)
• Decisiones de diseño reflejadas: Todas las 10 decisiones, más evaluación auténtica (#3).

---

4. Distribución de tipos de experiencia

Progresión pedagógica: conceptual-clarity → guided-practice → decision-lab → project-builder. Las primeras unidades tienen más carga conceptual; las intermedias son prácticas guiadas; las finales son de decisión y proyecto autónomo.

---

5. Stack tecnológico detallado

Requisitos de hardware (mínimo para ejercicios locales)

---

6. Riesgos identificados y mitigaciones

---

7. Criterios de éxito del curso

---

8. Mapa de trazabilidad: decisiones de diseño → unidades

---

Fin del plan del curso. Siguiente paso recomendado: crear source/units/unit-1.md (Unidad 1, formato Markdown, tipo conceptual-clarity).