Mapeo de RAG: etapas del pipeline, componentes clave y el panorama de variantes
Comprender cómo funciona la generación mejorada por recuperación de información de principio a fin, qué componentes necesita un sistema RAG y cómo las numerosas variantes de RAG encajan en un mismo esquema.
Fuentes: The Complete Guide to RAG — Part 1: What It Is, Why It Exists & How It Works
Un modelo de lenguaje puede razonar de manera impresionante y, aun así, no saber nada sobre su documentación interna, los cambios en las políticas de la semana pasada o el ticket presentado hace una hora. La generación mejorada por recuperación de información (RAG) resuelve esa brecha al permitir que el modelo busque datos en una fuente de conocimiento externa antes de responder. Esta guía explica los problemas que resuelve RAG y aquellos que no, las tres etapas de un sistema RAG, los componentes necesarios para crear uno y una forma de comprender la larga lista de variantes de RAG.
RAG en una frase
RAG combina dos procesos:
- Recuperación: localizar información relevante en una fuente de conocimiento externa.
- Generación: hacer que un modelo de lenguaje produzca una respuesta basada en lo recuperado.
En términos sencillos, RAG proporciona al modelo una biblioteca de referencia que puede consultar antes de responder. La investigación que introdujo este enfoque lo describió como la combinación de la memoria paramétrica del modelo, es decir, el conocimiento almacenado en sus pesos durante el entrenamiento, con una memoria no paramétrica, que es un índice externo que puede buscarse y actualizarse de forma independiente.
Una comparación útil es la de un examen con libros abiertos:
- El LLM es el estudiante.
- La base de conocimientos es el libro de texto.
- El sistema de recuperación es el estudiante que pasa las páginas adecuadas.
- La respuesta final es la respuesta del estudiante, escrita con esas páginas abiertas.
El modelo aporta razonamiento y un lenguaje fluido; el sistema de recuperación aporta los hechos relevantes para esa pregunta en particular.
Los problemas que RAG está diseñado para resolver
Depender únicamente del conocimiento integrado en un modelo enfrenta varios límites prácticos. Para cada uno de ellos, RAG ofrece una solución parcial.
Conocimiento que solo existe en el momento del entrenamiento
Un modelo no puede conocer nada que se haya añadido o modificado después de recopilarse sus datos de entrenamiento. Con RAG, la información actual se almacena en un repositorio externo que puedes actualizar cuando quieras, sin tocar el modelo.
Respuestas no respaldadas o inventadas
A veces los modelos generan afirmaciones que son incorrectas o carecen de fundamento. Las pruebas recuperadas proporcionan al modelo algo concreto en lo que basarse, lo que reduce las respuestas sin sustento. Sin embargo, no las elimina: la recuperación puede devolver pasajes erróneos, las fuentes mismas pueden ser inexactas, y el modelo aún puede hacer afirmaciones que las pruebas no respaldan.
Datos privados que el modelo nunca ha visto
Un modelo de uso general no tiene acceso a los documentos internos de su organización, al código propietario ni al conocimiento privado. RAG permite que una aplicación acceda a fuentes privadas autorizadas en el momento de realizar la consulta, sin necesidad de volver a entrenar al modelo con esos datos. El control de acceso sigue siendo importante aquí: el sistema de recuperación solo debe devolver lo que al usuario actual le está permitido leer.
Información que cambia con frecuencia
Las políticas, la documentación de productos y técnicos, así como los registros internos, cambian constantemente. Agregar o actualizar entradas en el índice de recuperación es mucho más económico y rápido que volver a entrenar un modelo de lenguaje cada vez que algo cambia.
Documentos demasiado grandes para enviar en su totalidad
Pegar documentos completos en cada solicitud desperdicia contexto y recursos. RAG envía solo las partes relevantes de la base de conocimientos, lo que mantiene las solicitudes más enfocadas y de menor tamaño.
Ruido proveniente de un contexto irrelevante
Demasiado material poco relacionado dificulta que el modelo encuentre las pruebas importantes. El filtrado, la reclasificación y la compresión de contexto existen para mejorar la calidad de lo que finalmente llega al modelo.
RAG mejora el anclaje en datos reales y reduce la tasa de alucinaciones, pero no garantiza respuestas precisas ni libres de alucinaciones. Considérelo una herramienta de fiabilidad, no una prueba de corrección.
Las tres etapas de un sistema RAG
A nivel más simple, todo sistema RAG realiza tres acciones: prepara los conocimientos, los recupera y genera con ellos.
Etapa 1: indexación
La indexación tiene lugar antes de que el usuario haga cualquier pregunta. El material de origen, como PDFs, páginas web, documentación o filas de bases de datos, se:
- carga en el sistema,
- se divide en fragmentos más pequeños,
El resultado es una representación buscable de su conocimiento. Conceptualmente, está creando un índice de búsqueda para sus propios datos.
Etapa 2: recuperación
Cuando llega una pregunta:
- la consulta se convierte en un embedding con el mismo modelo utilizado durante la indexación,
- se busca en la base de conocimientos los vectores más cercanos,
- se seleccionan los fragmentos más relevantes,
- el filtrado opcional o el reordenamiento perfeccionan la selección.
El flujo desde la pregunta hasta los fragmentos candidatos es el siguiente:
User Query
│
▼
[Embedding Model]
│
▼
[Query Vector]
│
▼
[Vector Database]
│
▼
[Relevant Chunks]
La propiedad importante es que las consultas y los documentos se encuentran en el mismo espacio vectorial. Por eso, el modelo de embedding utilizado en el momento de la consulta debe coincidir con el que se usó para crear el índice; mezclar modelos genera vectores que no pueden compararse de manera significativa.
Etapa 3: generación
Los fragmentos seleccionados se combinan con la pregunta del usuario para formar un prompt, y el modelo genera la respuesta:
User Query
+
Retrieved Context
│
▼
[Prompt / Context]
│
▼
[LLM]
│
▼
Final Answer
La respuesta resultante se basa en las capacidades generales del modelo y en las pruebas específicas extraídas de su fuente de conocimiento. La forma en que el prompt presenta esas pruebas, por ejemplo con etiquetas de fuente que el modelo puede citar, influye significativamente en cuán fielmente la respuesta se ajusta a ellas.
Dentro del proceso de indexación
La indexación es donde se determina la mayor parte de la calidad de un sistema RAG. Su estructura básica:
Raw Data
│
▼
Document Loader
│
▼
Text Chunking
│
▼
Embedding Model
│
▼
Vector Database
Datos brutos
El conocimiento puede provenir de casi cualquier lugar:
- PDFs
- Sitios web
- Documentación
- Documentos de texto
- Bases de datos
- APIs
- Archivos internos de la empresa
Cargadores de documentos
Un cargador de documentos lee un archivo de origen y lo convierte en una estructura uniforme que el resto del proceso puede procesar. En LangChain, por ejemplo, los cargadores comparten una interfaz común que genera objetos Document, y pueden ofrecer tanto la función load() como lazy_load(). La variante perezosa entrega los documentos uno por uno en lugar de cargar todo en memoria, lo cual es importante para colecciones grandes. LangChain y LlamaIndex son los dos ecosistemas con los que la mayoría de las personas comienzan.
División en fragmentos
Los documentos largos se dividen en partes más pequeñas llamadas chunks, ya que obtener la sección relevante de un documento suele ser más útil que entregarle todo al modelo. Una buena analogía es convertir un libro en una pila de tarjetas de índice, cada una dedicada a una idea.
No existen valores universalmente correctos para el tamaño y la superposición de los chunks. Dependen de cómo estén estructurados tus documentos, del tipo de preguntas que esperes, del modelo de embedding que utilices y de cuánto contexto puedas permitirte utilizar posteriormente. Los chunks demasiado pequeños pierden el significado contextual; los chunks demasiado grandes diluyen la información de esa única oración que es importante. Para conocer más sobre este equilibrio, consulta el método de chunking que preserva las pruebas.
Modelos de embedding
Cada fragmento se convierte en un embedding, es decir, una lista de números que representa su significado:
"RAG retrieves relevant information"
↓
[0.24, 0.87, 0.11, 0.62, ...]
Los embeddings permiten a un sistema medir cuán relacionados están dos fragmentos de contenido, y es esto lo que permite la búsqueda y recuperación semántica: los textos con significados similares terminan cerca uno del otro en el espacio vectorial, incluso si comparten pocas palabras.
En la familia text-embedding-3 de OpenAI, el modelo pequeño devuelve vectores de 1536 dimensiones por defecto, mientras que el modelo grande devuelve vectores de 3072.
Ambos aceptan un parámetro dimensions para solicitar vectores más cortos, sacrificando un poco de precisión a cambio de menos almacenamiento y una búsqueda más rápida. La gama de modelos cambia, por lo que confirme las opciones actuales en la documentación del proveedor.
Bases de datos vectoriales
Los embeddings se almacenan en una base de datos vectorial o índice vectorial diseñado para búsquedas rápidas de similitud. Algunas opciones comunes son:
- Qdrant
- Pinecone
- Chroma
- Weaviate
- FAISS
Un registro almacenado suele contener más que el vector; también guarda el texto original en fragmentos y metadatos como la fuente, el número de página, el ID del documento o la marca de tiempo. Es ese metadato lo que posteriormente permite filtrar por fecha o tipo de documento, así como indicar de dónde proviene una respuesta.
Los componentes básicos de una aplicación RAG
En conjunto, una aplicación RAG típica se compone de seis tipos de componentes:
- Fuente de conocimiento: proporciona la información, por ejemplo PDFs, sitios web, bases de datos SQL o APIs.
- Divisor de texto: divide los documentos en fragmentos manejables, utilizando los divisores de texto de LangChain o su propia lógica.
Un mapa de la familia RAG
Una vez que se comprende el flujo básico, el ecosistema de variantes existentes puede parecer abrumador. No existe una lista canónica única de tipos RAG; los artículos académicos y los blogs técnicos utilizan nombres superpuestos para referirse a arquitecturas, estrategias de recuperación, técnicas de contexto, fuentes de conocimiento y sistemas especializados. Agruparlos según sus diferencias hace que este panorama sea más manejable.
Arquitecturas básicas
- RAG ingenuo: el flujo directo de incrustación, búsqueda y generación.
- RAG avanzado: agrega pasos antes y después de la recuperación, como la reescritura de consultas y el reclasificado.
- RAG modular: trata cada etapa como un módulo intercambiable que puede recombinarse.
Estrategias de recuperación
- RAG de un solo paso: una recuperación por pregunta.
- RAG de múltiples consultas: genera varias formulaciones de la pregunta y realiza búsquedas para cada una.
- RAG iterativo: realiza búsquedas, razona y vuelve a buscar.
- RAG de múltiples saltos: enlaza búsquedas cuando la respuesta requiere conectar varios hechos.
- RAG híbrido: combina la búsqueda vectorial semántica con la búsqueda por palabras clave.
- Fusión RAG: combina los resultados de múltiples consultas en una única clasificación.
- RAG de autoconsulta: permite al modelo convertir la pregunta en una búsqueda junto con filtros de metadatos.
Enfoques de contexto y fragmentación
- RAG padre-hijo: hace coincidencias en fragmentos pequeños pero devuelve su sección parental más amplia.
- RAG de ventana de oración: recupera una oración junto con sus oraciones vecinas.
- RAG jerárquico: busca a través de niveles, desde documentos hasta pasajes.
- RAG contextual: enriquece los fragmentos con contexto a nivel de documento antes de incrustarlos.
- RAPTOR: construye un árbol de resúmenes recursivos y realiza búsquedas en sus niveles.
Enfoques autocorregibles y adaptativos
- Self-RAG: el modelo evalúa si es necesario realizar una recuperación de información y si sus resultados están respaldados.
- Corrective RAG (CRAG): analiza los resultados obtenidos y activa una nueva recuperación cuando estos son insuficientes.
- Adaptive RAG: dirige cada pregunta a la estrategia más adecuada según su nivel de complejidad.
- Feedback-based RAG: utiliza los comentarios de los usuarios o evaluadores para mejorar la recuperación de información con el tiempo.
Enfoques basados en agentes
- Agentic RAG
- Multi-Hop Agentic RAG
- Multi-Agent RAG
En estos enfoques, un agente decide cuándo y dónde realizar la recuperación de información, posiblemente utilizando varias herramientas o agentes colaboradores, en lugar de seguir un proceso fijo.
Variantes definidas por la fuente de conocimiento
Varios nombres simplemente describen de dónde proviene la evidencia. Vector RAG busca en un índice de embeddings, mientras que SQL RAG y Table RAG consultan datos relacionales o tabulares, a menudo haciendo que el modelo escriba la consulta. GraphRAG obtiene información de un grafo de conocimiento que contiene entidades y relaciones, Web o Search RAG extrae resultados en tiempo real de un motor de búsqueda, y Knowledge-Base RAG se basa en un corpus cuidadosamente seleccionado como un centro de ayuda o una wiki.
Variantes multimodales
Otras etiquetas se refieren al tipo de contenido que se obtiene. Text RAG es el caso por defecto; Image, Video y Audio RAG recuperan información de esos medios, generalmente a través de embeddings o transcripciones, y Multimodal RAG es el término general para los sistemas que combinan varios de ellos.
Variantes especializadas
Un último grupo de sistemas de nombres adaptados a requisitos específicos: un único campo como el derecho o la medicina (específico del dominio), preguntas sensibles al tiempo en las que la reciente fecha es importante (temporales), respuestas adaptadas a un usuario individual (personalizadas), consultas y fuentes en más de un idioma (multilingües), datos sensibles que deben permanecer protegidos (que preservan la privacidad), e índices distribuidos en varios sitios u organizaciones (distribuidos o federados).
Estos grupos se superponen libremente. Un sistema real de producción podría ser híbrido, basado en agentes y específico del dominio al mismo tiempo; las etiquetas describen elecciones de diseño, no productos mutuamente excluyentes.
De pipelines simples a avanzados
El pipeline más básico es una línea recta:
Query
↓
Embedding
↓
Vector Search
↓
Top-K Chunks
↓
LLM
↓
Answer
Esto es lo que la gente suele entender por naïve o RAG básico: incrustar la pregunta, tomar los fragmentos más cercanos del top-k y pasarlos al modelo. Es una primera versión razonable que a menudo es suficiente para corpus pequeños y ordenados.
Los sistemas más avanzados añaden etapas adicionales alrededor de la recuperación:
User Query
↓
Query Rewriting
↓
Query Routing
↓
Hybrid Retrieval
↓
Metadata Filtering
↓
Reranking
↓
Context Compression
↓
LLM
↓
Answer
Cada etapa aborda una debilidad específica. La reescritura de consultas corrige preguntas vagas o conversacionales, el enrutamiento envía la pregunta al índice o herramienta adecuados, la recuperación híbrida detecta términos exactos que la búsqueda vectorial pura pasa por alto, el filtrado de metadatos elimina documentos fuera del alcance, la reclasificación reordena las opciones con un modelo más preciso, y la compresión reduce lo que queda para ajustarse al presupuesto. Añada estas etapas solo cuando pueda medir el problema que resuelven; la complejidad no es un objetivo en sí mismo.
Por qué RAG es más que una base de datos vectorial más un LLM
Una suposición común entre los principiantes es que RAG significa “almacenar embeddings, consultarlos y llamar al modelo”. Un pipeline de producción suele tener un aspecto más similar a este:
Document Processing
↓
Chunking
↓
Metadata
↓
Embedding
↓
Vector / Keyword Retrieval
↓
Filtering
↓
Reranking
↓
Context Compression
↓
Prompt Construction
↓
LLM
↓
Validation
↓
Final Answer
Cada paso de esa cadena puede deteriorar la respuesta final: un análisis deficiente, un particionamiento descuidado, falta de metadatos, un modelo de embeddings inadecuado, un filtrado insuficiente o una prompt mal elaborada. Por eso, conectar un almacén de vectores a un modelo es solo el comienzo. Por más capaz que sea el modelo, no puede compensar por completo el hecho de recibir información incorrecta.
Cómo evaluar un sistema RAG
Producir una respuesta no es el criterio principal. Un buen sistema RAG recupera información verdaderamente útil y genera una respuesta que esté respaldada por las pruebas obtenidas. Las dimensiones que vale la pena medir son:
- Calidad de la recuperación: ¿se recuperan realmente los documentos o fragmentos relevantes?
Medir cada etapa por separado es lo que permite diagnosticar los fallos; el enfoque de evaluar RAG por etapa de fallo muestra cómo estructurar esto.
Siguientes pasos
La siguiente capa de profundidad es el propio camino de indexación: cómo un PDF se convierte en texto, la diferencia entre cargar, analizar y limpiar los datos, las compensaciones entre el particionamiento por caracteres, tokens, de forma recursiva, semántica y sensible a la estructura, qué efecto real tiene la superposición de bloques, cómo deben diseñarse los metadatos, cómo el texto se convierte en un vector, cuáles son las diferencias entre la similitud coseno, el producto escalar y la distancia euclidiana, y cómo una base de datos vectorial realiza búsquedas de similitud a gran escala.
Puntos clave
- RAG combina los conocimientos entrenados de un modelo con un almacenamiento externo buscable, de modo que las respuestas pueden reflejar información privada y actual sin necesidad de volver a entrenar el modelo.
- Reduce las respuestas no válidas, pero nunca garantiza la corrección; la recuperación de información, las fuentes y la generación de respuestas pueden fallar en cada caso.
Lecturas relacionadas
- Diseñando un pipeline RAG fundamentado en la realidad: fragmentación, filtrado y transmisión en tiempo real — Una guía completa sobre los fundamentos de un pipeline RAG basado en la realidad: fragmentación consciente de la estructura, división segura de tokens, filtrado en tres etapas durante la recuperación de información, reensamblaje de datos relacionados, diseño de prompts y transmisión en tiempo real.
- RAG explicado: cómo los sistemas AI recuperan conocimiento nuevo a demanda — Aprenda cómo funciona la generación reforzada por recuperación de información, desde la fragmentación y creación de embeddings hasta la búsqueda vectorial, para que los modelos AI puedan responder preguntas sin necesidad de ser reentrenados.