RAGs · DacaCode

Arquitectura de un RAG: Indexing y Retrieval Pipeline

Dacadev — Tue, 14 Jul 2026 00:00:00 -0500

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.

RAG: Qué es y Cómo Funciona Retrieval Augmented Generation

Dacadev — Mon, 13 Jul 2026 00:00:00 -0500

Tabla de Contenido

Supongamos que debemos desplegar un asistente conversacional sobre la documentación interna de una organización: manuales técnicos, contratos y políticas que se actualizan cada semana. El modelo base responde con fluidez sobre conocimiento general, pero desconoce por completo esos documentos privados e inventa respuestas con total seguridad cuando se le pregunta por ellos. Aquí es donde RAG (Retrieval Augmented Generation) se convierte en la aproximación arquitectónica más rentable para dotar a un LLM de información precisa, privada y actualizada.

Note

Este es el primer artículo de la serie RAGs. Al terminar podrás explicar qué es un RAG, cómo funciona a alto nivel y por qué se ha vuelto una pieza central en el diseño de aplicaciones de IA generativa. 🚀

Las limitaciones estructurales de los LLMs

Antes de definir qué es un RAG, es crucial entender las limitaciones de los LLMs que esta técnica resuelve. Un modelo de lenguaje, por potente que sea, arrastra tres restricciones inherentes a la forma en que fue entrenado.

Alucinaciones

Las alucinaciones son uno de los problemas más severos de los LLMs. Consisten en que el modelo responde con información incorrecta o inventada, pero con un nivel de confianza que induce al usuario a asumirla como válida.

En aplicaciones comerciales esto representa un riesgo directo: si la información de entrada es incorrecta, todo el proceso que dependa de ella heredará el error. Consideremos un asistente en el dominio médico; una respuesta errónea sobre la dosificación de un medicamento puede tener consecuencias fatales. La confianza aparente del modelo no es un indicador de veracidad.

Conocimiento con fecha de corte

Los LLMs se entrenan con grandes volúmenes de datos públicos —libros, artículos, páginas web— hasta una fecha de corte determinada. Todo evento posterior a esa fecha queda fuera de su conocimiento.

Si un modelo fue entrenado con datos hasta 2025, no dispone de información sobre hechos ocurridos después. Ante una consulta de este tipo, el modelo o bien reconoce su desconocimiento, o bien alucina para completar la respuesta.

Ausencia de conocimiento privado

Al entrenarse sobre datos públicos, los LLMs no tienen acceso a datos privados: manuales internos, contratos, bases de conocimiento corporativas o historiales de clientes. Esta es una limitación esperada, pero decisiva.

La alternativa que uno creeria de adjuntar todos los documentos privados en cada conversación no es técnicamente viable, implica un consumo desmedido de tokens y latencia en cada llamada, además de chocar contra los límites de la ventana de contexto.

flowchart TD
 L[🧠 LLM entrenado con datos públicos]
 L --> A[❌ Alucinaciones<br/>respuestas inventadas]
 L --> B[❌ Fecha de corte<br/>sin datos recientes]
 L --> C[❌ Sin conocimiento privado<br/>manuales, contratos, datos internos]

Alternativas antes de llegar a RAG

RAG no es la única técnica para inyectar conocimiento en un LLM. Es importante situarla frente a otras dos aproximaciones habituales y comprender sus contrapartidas.

Agentes

Los agentes han ganado tracción gracias a las amplias ventanas de contexto actuales, que permiten al modelo procesar grandes cantidades de información para resolver tareas complejas de manera autonoma. Sin embargo, cuando el volumen documental es elevado, el agente debería leer toda la información en cada ejecución.

Incluso apoyándose en mecanismos de caché, el costo en tokens y tiempo escala de forma prohibitiva. Procesar íntegramente un manual extenso solo para resolver una consulta puntual es análogo a recorrer una biblioteca completa para responder una única pregunta: funciona, pero es ineficiente.

Fine-tuning

El fine-tuning consiste en reentrenar un LLM sobre datos específicos para ajustar sus pesos y especializarlo en un dominio. Esta técnica genera una nueva versión del modelo con el conocimiento incorporado directamente en sus parámetros.

El problema es su costo operativo: requiere tiempo, recursos y datos de entrenamiento cuidados. Además, cada vez que la información cambia, es necesario reentrenar. En un escenario donde los datos se actualizan cada semana, o cada día, el fine-tuning se vuelve inviable como estrategia principal.

Info

Estas alternativas no son deficientes; simplemente resuelven problemas distintos. Los agentes son idóneos para explorar código o ejecutar flujos de trabajo dinámicos, y el fine-tuning brilla cuando el conocimiento es estable y muy específico. RAG destaca precisamente donde estas fallan: conocimiento amplio, cambiante y verificable.

Qué es un RAG (Retrieval Augmented Generation)

Un RAG (Retrieval Augmented Generation) es una técnica que recupera información relevante desde una fuente de datos externa y la incorpora al contexto del LLM en tiempo de inferencia, de modo que el modelo pueda responder con información verídica y actualizada.

La idea central es desacoplar el conocimiento del modelo. En lugar de codificar los datos en los pesos, como hace el fine-tuning, o de arrastrar todo el corpus en cada llamada, como hace un agente, el RAG selecciona únicamente los fragmentos pertinentes para cada consulta y los añade al prompt.

Analicemos un caso concreto. Supongamos un modelo cuyo conocimiento llega hasta mayo de 2026 y le preguntamos por un evento posterior a esa fecha:

prompt: ¿Qué equipos jugarán la semifinal de la Copa del Mundo 2026?

LLM: Lo siento, no dispongo de información sobre los equipos que jugarán
 la semifinal de la Copa del Mundo 2026. Mi conocimiento está
 actualizado hasta mayo de 2026.

Ahora enriquezcamos ese mismo prompt con un bloque de contexto recuperado desde una fuente externa:

prompt: ¿Qué equipos jugarán la semifinal de la Copa del Mundo 2026?

----- contexto inyectado -----
Contexto: Los equipos que disputarán la semifinal de la Copa del Mundo 2026 son:
- Francia
- España
- Inglaterra
- Argentina
----- fin del contexto -----

LLM: Los equipos que jugarán la semifinal de la Copa del Mundo 2026 son
 Francia, España, Inglaterra y Argentina.

La diferencia está en el campo de contexto. Ese bloque, recuperado dinámicamente, es lo que permite al modelo responder con precisión sin haber sido entrenado con esa información. En esto consiste, en esencia, un RAG: obtener el conocimiento relevante desde una fuente de datos y aumentar con él el contexto del LLM.

Si pensamos esto en el caso de la documentación extensa, un RAG permite extraer las secciones pertinentes de un manual o contrato y añadirlas al prompt, de modo que el modelo pueda responder con información verídica y actualizada sin necesidad de reentrenar ni de procesar todo el documento en cada consulta. Es decir que solo cargamos una parte del documento y no todo su contenido.

Cómo funciona un RAG a alto nivel

Su nombre describe con exactitud las tres fases del proceso: Retrieval (recuperación), Augmented (aumento) y Generation (generación).

Retrieval (Recuperación): ante una consulta del usuario, el sistema busca en una base de conocimiento externa los fragmentos de información más relevantes. Esta búsqueda suele apoyarse en similitud semántica, un mecanismo que abordaremos en detalle más adelante en la serie.
Augmented (Aumento): los fragmentos recuperados se combinan con la consulta original para construir un prompt enriquecido. El modelo recibe así, junto a la pregunta, el contexto necesario para responderla.
Generation (Generación): el LLM genera la respuesta final apoyándose en el contexto inyectado, no solo en su conocimiento paramétrico.

Tip

La calidad de un RAG depende directamente de la fase de recuperación. Si los fragmentos recuperados son irrelevantes o incompletos, el modelo generará una respuesta pobre por muy capaz que sea. En RAG, la máxima “basura entra, basura sale” aplica con especial fuerza.

Ventajas de adoptar un RAG

Más allá de mitigar las limitaciones descritas, el patrón RAG ofrece beneficios concretos de ingeniería:

Eficiencia y costo: aporta conocimiento profundo y específico al modelo sin el costo de reentrenar ni de procesar el documento completo en cada llamada.
Información verificable: al recuperar fragmentos de fuentes reales, el modelo puede citar su origen, de modo que el usuario contraste la respuesta con la fuente original.
Actualización simple: mantener el sistema al día se reduce a actualizar la base de conocimiento, sin tocar el modelo.
Reducción de alucinaciones: al fundamentar la respuesta en datos recuperados, disminuye de forma significativa la probabilidad de que el modelo invente información.

Warning

Un RAG reduce las alucinaciones, pero no las elimina por completo. El modelo aún puede malinterpretar el contexto recuperado o combinarlo con su conocimiento paramétrico de forma incorrecta. El diseño del prompt y la evaluación rigurosa siguen siendo responsabilidad del ingeniero.