Anatomía del pipeline RAG de extremo a extremo

Antes de escribir una sola línea de chunking o embeddings, necesitas el mapa mental completo: qué piezas tiene un sistema RAG, en qué orden se conectan, cómo fluyen los datos entre ellas y qué hito de este proyecto construye cada una. Sin ese mapa es fácil perderse en los detalles de una etapa y no entender por qué existe.

En la lección anterior ya viste una respuesta con citas salir del corpus de NimbusTech en dos minutos. Eso fue el sistema terminado funcionando como una caja negra. Aquí abrimos la caja: al terminar esta lección podrás dibujar de memoria el pipeline entero, explicar por qué RAG reduce las alucinaciones frente a preguntarle directamente a un modelo, y reconocer cada término clave (chunk, embedding, top-k, recall@k, MRR, re-ranking, groundedness, abstención) cuando aparezca en los siguientes hitos.

La idea en una frase: RAG separa dónde vive el conocimiento (tus documentos, indexados) de quién redacta la respuesta (el modelo generador). El modelo ya no inventa de memoria: cita lo que el sistema le puso delante.

El pipeline como grafo

Un sistema RAG no es una línea recta: tiene dos caminos que se encuentran. Uno se ejecuta antes de que llegue ninguna pregunta (indexación offline) y otro se ejecuta cada vez que un usuario pregunta (consulta online). Explora el grafo —puedes desplazarlo y hacer zoom— y fíjate en dónde se cruzan ambos caminos: en la recuperación, cuando la pregunta se compara contra el índice que preparaste de antemano.

Camino A — Indexación offline (se hace una vez)

Es todo el trabajo de preparación que ocurre antes de que exista ninguna pregunta. El objetivo es transformar documentos crudos en algo que se pueda buscar por significado.

1. Ingesta y limpieza — cargar los documentos y normalizar el texto (quitar ruido, espacios raros, caracteres de control) para que las etapas siguientes trabajen sobre texto uniforme.
2. Chunking — trocear cada documento largo en fragmentos (chunks) manejables, con un pequeño solapamiento para no cortar una idea a la mitad. Se busca por chunk, no por documento entero.
3. Embeddings — convertir cada chunk en un vector numérico que captura su significado. En este proyecto los embeddings vienen precomputados y deterministas (igual que en el curso de embeddings), así todo corre en tu navegador sin llamar a una API.
4. Índice vectorial — guardar todos esos vectores en una estructura en memoria que permita, dado el vector de una pregunta, encontrar rápido los chunks más parecidos.

Camino B — Consulta online (se hace en cada pregunta)

Es lo que ocurre en tiempo real cuando alguien pregunta algo.

5. Recuperación (retrieval) — se calcula el embedding de la pregunta y se comparan contra el índice para traer los top-k chunks más relevantes por similitud coseno. Aquí se cruzan los dos caminos.
6. Re-ranking — se re-ordenan esos candidatos con un criterio más fino que la primera búsqueda, para que los fragmentos verdaderamente pertinentes queden arriba.
7. Generación con citas — se arma un prompt que le da al modelo solo los chunks recuperados como contexto y le pide responder citando la fuente. Si el contexto no contiene la respuesta, el sistema debe abstenerse en vez de inventar.
8. Evaluación — de forma transversal, medimos qué tan bien recupera (recall@k, MRR) y qué tan fiel es la respuesta al contexto (groundedness), para iterar con datos y no con corazonadas.

Qué hito construye cada pieza

Este proyecto está organizado para que ensambles el pipeline pieza por pieza, y cada hito deja una parte funcionando y probada. Esta tabla es tu índice de referencia para todo el proyecto:

No tienes que memorizar la tabla: la idea es que cuando estés en, digamos, el Hito 4 eligiendo k, tengas claro que estás en el camino de consulta y que lo que traigas alimenta directamente al re-ranking y luego a la generación.

¿Por qué RAG reduce las alucinaciones?

Un LLM por sí solo responde a partir de lo que "recuerda" de su entrenamiento. Ese conocimiento es paramétrico: está comprimido en sus pesos, es difuso, tiene fecha de corte y no incluye tus documentos internos. Cuando le preguntas por la política de trabajo remoto de NimbusTech, el modelo no la conoce, así que rellena el hueco con algo que suena plausible pero es inventado. Eso es una alucinación.

RAG ataca el problema de raíz cambiando la fuente de la respuesta:

• Sin RAG (solo-prompting): la respuesta sale de la memoria del modelo → no verificable, puede estar desactualizada, puede ser inventada.
• Con RAG: la respuesta se fundamenta en fragmentos reales recuperados de tu corpus, que se le entregan al modelo en el prompt → verificable, actualizable (cambias el índice, no reentrenas) y citable.

La recuperación se apoya en comparar significados como vectores. La cercanía entre la pregunta y un chunk se mide con la similitud coseno:

$\text{sim}(\mathbf{q}, \mathbf{c}) = \cos(\theta) = \frac{\mathbf{q}\cdot\mathbf{c}}{\lVert\mathbf{q}\rVert\,\lVert\mathbf{c}\rVert}$

Un valor cercano a $1$ significa "apuntan en la misma dirección semántica"; cercano a $0$, "no tienen que ver". Sobre esa medida se construye toda la recuperación del Hito 4.

La clave conceptual: RAG no hace al modelo más inteligente, lo hace más honesto. Le da material verificable y le pide ceñirse a él. Y cuando ese material no contiene la respuesta, un buen sistema RAG se abstiene ("no encuentro esto en la base de conocimiento") en vez de rellenar el vacío.

¿Cuándo aporta valor RAG y cuándo no?

RAG no es siempre la respuesta correcta. Usa este árbol de decisión mental antes de meter todo en un pipeline RAG:

RAG brilla cuando: el conocimiento es tuyo (documentos internos, privados), cambia con el tiempo, es demasiado grande para caber en un solo prompt, y necesitas que cada afirmación sea rastreable hasta su fuente. Ese es exactamente el escenario de NimbusTech: cientos de políticas, manuales y FAQs que evolucionan, y respuestas que un empleado debe poder verificar. Por eso construimos un pipeline completo y no un simple prompt.

Vocabulario del proyecto

Estos términos aparecerán en cada hito. Repásalos con las tarjetas —el sistema te las volverá a mostrar justo antes de que las olvides— para que lleguen al teclado sin fricción cuando estés programando.

Comprueba tu mapa mental

Antes de pasar al Hito 1, responde estas preguntas en tu cabeza (o en voz alta) y solo después despliega la respuesta. Recuperar cuesta más que releer, y por eso fija mejor lo aprendido.

Chunking y embeddings (junto con la ingesta y la construcción del índice) son offline. La recuperación y la generación ocurren online, en cada consulta. La recuperación es el punto donde ambos caminos se cruzan.

Porque la respuesta se fundamenta en fragmentos reales recuperados del corpus y entregados al modelo en el prompt, en lugar de salir de su memoria paramétrica. Eso la hace verificable, citable y actualizable sin reentrenar. RAG no hace al modelo más listo, lo hace más honesto.

Abstenerse: responder que no encuentra esa información en la base de conocimiento, en vez de inventar una política. Es precisamente el comportamiento que buscamos y que mediremos con las preguntas de categoría sin_respuesta en el Hito de evaluación.

Necesitas el índice vectorial construido en el Hito 3 (que a su vez depende del chunking del Hito 2 y de los embeddings). Tus resultados top-k alimentan el re-ranking (Hito 5) y luego la generación con citas (Hito 6).

Si respondiste las cuatro con seguridad, ya tienes el mapa que necesitas. En el siguiente hito dejamos la teoría y empezamos a cargar y limpiar el corpus real de NimbusTech.

Puntos clave

• Un pipeline RAG tiene un camino offline (ingesta → chunking → embeddings → índice) y un camino online (recuperación → re-ranking → generación citada), que se cruzan en la recuperación.
• RAG reduce alucinaciones al fundamentar la respuesta en documentos recuperados y verificables, no en la memoria del modelo; y se abstiene cuando no hay evidencia.
• Elige RAG cuando el conocimiento es privado, cambiante, grande y necesita citas; para tareas de conocimiento general y estable, el solo-prompting basta.
• Cada hito de este proyecto construye una pieza concreta del grafo; ese grafo es tu mapa para no perderte.