Arquitectura de un RAG: Indexing y Retrieval Pipeline
- Dacadev
- Ia generativa
- 14 de julio de 2026
Tabla de Contenido
En el artículo anterior de esta serie se habló de qué es un RAG y cómo ayuda a proveer de conocimiento privado y actualizado a los LLMs. Ahora abordemos el tema de “cómo se estructura internamente un sistema RAG (Retrieval Augmented Generation)”.
Note
Este es el segundo artículo de la serie RAGs. Al terminar comprenderás la arquitectura de un RAG: el indexing pipeline que prepara el conocimiento, el retrieval pipeline que responde en tiempo real, y el componente de evaluación que garantiza la calidad en producción. 🚀
Los dos pipelines de un sistema RAG
Un sistema RAG se puede descomponer en dos pipelines complementarios: el indexing pipeline (pipeline de indexación) y el retrieval pipeline (pipeline de recuperación).
La distinción es fundamentalmente temporal. El indexing pipeline se ejecuta de forma offline o asíncrona, preparando la base de conocimiento. El retrieval pipeline se ejecuta en tiempo real y es el encargado de responder a cada petición del usuario consumiendo el conocimiento ya indexado.
El indexing pipeline
El indexing pipeline es el responsable de tomar los datos crudos, dividirlos en fragmentos procesables, convertirlos en vectores numéricos —los embeddings— y almacenarlos en una base de datos, típicamente una base de datos vectorial.
El flujo parte de la fuente de datos y encadena cuatro etapas de procesamiento hasta almacenar el conocimiento en la base de datos vectorial:
flowchart LR
F["📄 Fuente de datos"] --> CA["📥 Carga"]
CA --> FR["✂️ Fragmentación"]
FR --> CO["🧮 Conversión"]
CO --> AL[("🗄️ Almacenamiento")]
Cada nodo del diagrama se corresponde con una etapa lógica bien definida:
- Fuente de datos: el origen de la información cruda —bases de datos, APIs, archivos o páginas web— que alimenta el sistema.
- Carga: se conecta a las fuentes externas, extrae los documentos y parsea su contenido a texto plano.
- Fragmentación: divide los documentos extensos en piezas más pequeñas y manejables, denominadas chunks.
- Conversión: transforma cada chunk en un vector numérico —el embedding— que captura su significado semántico.
- Almacenamiento: persiste los embeddings en una base de datos vectorial, lista para la fase de recuperación.
Info
El indexing pipeline no se ejecuta en cada consulta. Su activación depende de la volatilidad de la fuente de datos y suele responder a disparadores concretos: la carga de un documento nuevo, la actualización de un registro o una reindexación programada. Al ser un proceso offline, podemos permitirnos operaciones costosas sin afectar la latencia de respuesta al usuario.
Tanto la estrategia de chunking como la generación de embeddings son decisiones de diseño con un impacto directo en la calidad del sistema. Las abordaremos en profundidad más adelante en la serie.
El retrieval pipeline
El retrieval pipeline es el que opera en tiempo real. Su responsabilidad es analizar la petición del usuario, recuperar de la base de datos vectorial los fragmentos de información más relacionados con ella, inyectarlos en el prompt junto con la consulta original, enviar el resultado al LLM y devolver la respuesta.
flowchart LR
U["👤 Usuario<br/>(prompt)"] --> R["🔎 Retriever"]
R -->|"search query"| DB[("🗄️ Vector DB<br/>memoria no paramétrica")]
DB -->|"fetch information"| R
R -->|"prompt + contexto"| L["🧠 LLM<br/>memoria paramétrica"]
L --> RESP["💬 Respuesta"]
Este flujo introduce una distinción conceptual relevante entre dos tipos de memoria:
- Memoria paramétrica: el conocimiento codificado en los pesos del LLM durante su entrenamiento.
- Memoria no paramétrica: el conocimiento externo almacenado en la base de datos vectorial, que el sistema consulta dinámicamente.
El retrieval pipeline es, en esencia, el mecanismo que combina ambas memorias para producir una respuesta fundamentada y este se organiza en tres fases secuenciales, cada una soportada por un componente:
flowchart LR
A["🔎 Retrieval<br/>recupera contexto"] --> B["🧩 Augmentation<br/>construye el prompt"]
B --> G["🧠 Generation<br/>genera la respuesta"]
- Retrieval: el Retriever es el componente central del RAG. Busca en la base de conocimiento y recupera los fragmentos relevantes para la consulta.
- Augmentation: la capa de gestión de prompts combina la información recuperada con la petición original para construir el prompt final.
- Generation: el componente LLM genera la respuesta definitiva. Puede apoyarse en modelos fundacionales o afinados, de código abierto o cerrado.
Tip
La calidad de la respuesta está acotada por la fase de Retrieval. Si el Retriever recupera fragmentos irrelevantes, ninguna capacidad del LLM compensará ese contexto deficiente. Optimizar la recuperación suele rendir más que cambiar a un modelo más potente.
Arquitectura completa
Ambos pipelines no operan de forma aislada; convergen en la base de conocimiento. El indexing pipeline la construye y la mantiene actualizada, mientras que el retrieval pipeline la consulta para fundamentar cada respuesta.
Esta arquitectura desacoplada es lo que confiere al patrón RAG su principal ventaja operativa: actualizar el conocimiento del sistema no requiere reentrenar el modelo, sino únicamente ejecutar el indexing pipeline sobre los nuevos datos.
Evaluación
Hasta aquí hemos descrito los dos componentes estructurales del sistema. Sin embargo, en un entorno de producción es crucial incorporar un tercer componente: la evaluación, encargada de medir si las respuestas que entrega el sistema son correctas y relevantes.
Un punto de partida sólido es el RAG Triad propuesto por TruEra, un marco que evalúa la coherencia entre las tres piezas de una interacción: la consulta del usuario, el contexto recuperado y la respuesta generada.
El marco define tres validaciones, una por cada arista del triángulo:
- Context relevance: ¿el contexto recuperado de la base de conocimiento es relevante para la consulta del usuario? Evalúa la calidad de la fase de Retrieval.
- Groundedness: ¿la respuesta del LLM se apoya fielmente en el contexto recuperado, en lugar de alucinar? Evalúa que el modelo utilice la información proporcionada.
- Answer relevance: ¿la respuesta final responde efectivamente a la consulta del usuario? Evalúa la utilidad del resultado.
Warning
Un sistema RAG sin evaluación es un sistema opaco. Sin medir context relevance, groundedness y answer relevance no podrás distinguir si un fallo proviene de una recuperación deficiente o de una generación defectuosa, lo que vuelve la depuración prácticamente imposible.
Conclusión y próximos pasos
La arquitectura de un RAG se sostiene sobre dos pipelines desacoplados —indexación offline y recuperación en tiempo real— que convergen en una base de conocimiento vectorial, más un componente transversal de evaluación que garantiza su fiabilidad en producción.
Con este mapa arquitectónico claro, las próximas entregas de la serie RAGs profundizarán en cada pieza:
- Estrategias de chunking: cómo fragmentar los documentos sin perder contexto.
- Embeddings: qué son, cómo se generan y cómo capturan el significado semántico.
- Bases de datos vectoriales: indexación y búsqueda por similitud.
- Métricas y herramientas para evaluar sistemas RAG de forma rigurosa.
En el siguiente artículo comenzaremos a construir el indexing pipeline, empezando por la fase de carga y fragmentación de datos.
