¿Qué es RAG? Explicación de la generación aumentada por recuperación

La generación aumentada por recuperación (RAG) es una técnica en la que un sistema busca pasajes relevantes en un índice externo de documentos y los envía a un modelo de lenguaje antes de que genere una respuesta. En lugar de depender únicamente de los pesos fijados durante el entrenamiento, el modelo puede responder usando información privada, interna o actualizada recientemente.

Un modelo de lenguaje estándar solo conoce los datos con los que se entrenó hasta su fecha de corte. Si un usuario pregunta por la política interna de reembolsos de tu empresa, una especificación de API recién publicada o un registro de cuenta actualizado hace cinco minutos, el modelo base no puede conocer la respuesta solo de memoria. RAG cubre esa brecha al combinar una etapa de búsqueda con la de generación: primero recupera los hechos relevantes y después genera una respuesta basada en el texto recuperado.

¿Qué significa generación aumentada por recuperación?

La generación aumentada por recuperación consiste en combinar un sistema de recuperación de información con un modelo de generación de texto para que la respuesta se base en documentos externos recuperados en el momento de la consulta. En vez de esperar que una red neuronal memorice cada dato en sus parámetros, RAG trata un índice externo de texto como un libro abierto que el modelo puede consultar antes de responder.

A grandes rasgos, todo flujo de RAG sigue dos fases principales:

1. Recuperar: cuando un usuario envía un prompt, el sistema convierte la consulta en una búsqueda en un almacén externo de datos, como una base de datos vectorial, un índice de búsqueda por palabras clave o una combinación de ambos, y recupera los pasajes de texto más relevantes.
2. Generar: el sistema introduce los pasajes recuperados en el contexto del modelo junto con la pregunta original del usuario, y el modelo de lenguaje genera una respuesta basada en esos pasajes.

Como el texto de referencia se obtiene dinámicamente en cada solicitud, puedes actualizar lo que sabe el sistema modificando el índice de documentos en vez de volver a entrenar el modelo subyacente. Por eso, RAG es una de las técnicas habituales para crear asistentes de soporte, buscadores de documentación interna y herramientas de preguntas y respuestas especializadas. También se emplea en aplicaciones creativas donde los equipos usan herramientas de flujo de trabajo como AI Studio Video para producir contenido multimedia y API de texto para recuperar conocimiento.

¿En qué se diferenciaba el artículo sobre RAG de 2020 de la técnica actual?

El término «generación aumentada por recuperación» procede de un artículo de 2020 de Patrick Lewis y sus colegas (arXiv:2005.11401), que combinaba un modelo secuencia a secuencia preentrenado con un índice vectorial denso de Wikipedia. Actualmente, los desarrolladores suelen utilizar el término para referirse a un proceso más sencillo de construcción de prompts. Entender ambos enfoques ayuda a aclarar por qué «RAG» se describe de dos maneras ligeramente distintas en los artículos de investigación y en la documentación técnica.

La arquitectura de Lewis y colaboradores de 2020

En el artículo original de 2020 y en la publicación de investigación de Meta AI que lo acompañaba, los autores plantearon que los modelos de lenguaje tenían dos tipos de memoria:

• Memoria paramétrica: conocimiento almacenado en los pesos de la red neuronal, concretamente en un modelo BART secuencia a secuencia preentrenado.
• Memoria no paramétrica: conocimiento almacenado en un índice vectorial denso externo de artículos de Wikipedia, que se consulta mediante un recuperador neuronal llamado Dense Passage Retrieval (DPR).

En esa configuración de investigación, el recuperador y el generador se entrenaban conjuntamente de extremo a extremo. El artículo presentó dos formulaciones sobre cómo influían los pasajes recuperados en la generación:

• RAG-Sequence: el modelo utiliza los mismos pasajes recuperados para generar toda la secuencia de salida.
• RAG-Token: el modelo puede recurrir a distintos pasajes recuperados para cada token que genera.

En las pruebas de preguntas y respuestas de dominio abierto recogidas en las tablas del artículo (arXiv:2005.11401), RAG-Sequence alcanzó una puntuación de 44.5 Exact Match en Natural Questions, superando tanto a los modelos de referencia seq2seq exclusivamente paramétricos como a las arquitecturas de recuperación y extracción evaluadas en el estudio.

La técnica actual de ingeniería

En el desarrollo moderno de aplicaciones, los equipos rara vez entrenan conjuntamente un recuperador y un generador. En cambio, «RAG» casi siempre se refiere a un proceso que se ejecuta durante la inferencia y que utiliza modelos de embeddings disponibles comercialmente y API de LLM de propósito general:

1. Dividir los documentos en pasajes más pequeños o fragmentos.
2. Convertir esos fragmentos en embeddings vectoriales y almacenarlos en un índice.
3. Recuperar los fragmentos que mejor coincidan en el momento de la consulta.
4. Reordenar los resultados de forma opcional para mejorar su relevancia.
5. Introducir directamente los fragmentos recuperados en el prompt y pedir al LLM que responda.

Tanto la arquitectura neuronal de extremo a extremo de 2020 como el proceso actual que introduce texto en el prompt se denominan RAG. En la ingeniería de software cotidiana, salvo que se mencione expresamente el entrenamiento de un recuperador con un modelo seq2seq, se hace referencia al proceso moderno.

¿Cómo funciona paso a paso un proceso RAG moderno?

Un sistema RAG en producción divide su trabajo en dos flujos separados: un proceso de ingesta sin conexión que prepara e indexa los documentos y un proceso de consulta en línea que se ejecuta cada vez que un usuario hace una pregunta. Las guías de arquitectura, como la guía de AWS sobre generación aumentada por recuperación y la guía de RAG de AWS Generative AI Innovation Center, dividen estas etapas en componentes que se pueden ajustar de forma independiente.

1. El proceso de ingesta (indexación de datos)

Antes de que un usuario envíe un prompt, el sistema debe preparar los documentos de origen para que se puedan buscar:

• Carga y limpieza de documentos: extraer texto sin formato y metadatos (títulos, URL, marcas de tiempo y permisos de acceso) de PDF, wikis, bases de datos o archivos Markdown, eliminando formatos defectuosos y elementos repetitivos de las páginas.
• Fragmentación: dividir los documentos largos en segmentos más pequeños para recuperar solo pasajes relevantes en lugar de manuales completos. Si los fragmentos son demasiado pequeños, pierden el contexto circundante y cortan ideas a la mitad; si son demasiado grandes, incluyen información irrelevante y aumentan el consumo de tokens. Los equipos suelen solapar ligeramente los fragmentos adyacentes para que las frases en los límites no pierdan su sentido.
• Generación de embeddings: pasar cada fragmento por un modelo de embeddings para convertir su texto en un vector numérico denso que represente su significado semántico.
• Indexación: almacenar esos vectores, junto con el texto original y los filtros de metadatos, en una base de datos vectorial o en un buscador híbrido que combine similitud vectorial con coincidencia de palabras clave, como BM25.

2. El proceso de consulta (respuesta a preguntas)

Cuando un usuario hace una pregunta durante la ejecución, el proceso de consulta prepara el prompt:

• Procesamiento de la consulta y generación de embeddings: tomar la entrada del usuario, reescribirla o ampliarla opcionalmente para mayor claridad y convertirla en un vector con exactamente el mismo modelo de embeddings utilizado durante la ingesta.
• Recuperación: buscar en el índice los fragmentos cuyos vectores estén más cerca del vector de la consulta. A menudo se combinan la búsqueda semántica, las palabras clave y el filtrado por metadatos, por ejemplo, para limitar los resultados a documentos que el usuario actual tiene permiso para leer.
• Reordenación opcional: pasar los fragmentos candidatos iniciales por un modelo de reclasificación con codificador cruzado, que puntúa hasta qué punto cada pasaje responde directamente a la consulta y reduce la lista a las mejores coincidencias.
• Montaje del prompt y generación: insertar los pasajes mejor clasificados en una plantilla estructurada de prompt junto con la pregunta del usuario, enviar el conjunto al LLM y devolver la respuesta generada, a menudo con citas que apuntan a los metadatos de origen.

¿Cómo se compara RAG con las ventanas de contexto largas y el ajuste fino?

RAG, las ventanas de contexto largas y el ajuste fino resuelven partes distintas del problema de personalizar un modelo. Los sistemas en producción suelen combinarlos en lugar de tratarlos como opciones excluyentes. La elección adecuada depende de si necesitas hechos que cambian, una comprensión amplia en una sola sesión o cambios en el comportamiento del modelo.

Aspecto	Generación aumentada por recuperación (RAG)	Ventana de contexto larga	Ajuste fino
Objetivo principal	Proporcionar hechos relevantes de un corpus grande o cambiante para cada consulta	Permitir que el modelo lea una gran cantidad de texto en una solicitud	Cambiar el estilo, el tono, el formato o el comportamiento en tareas especializadas
Actualización del conocimiento	Actualizar o sustituir documentos del índice externo	Sustituir los documentos originales pegados en el prompt	Recopilar nuevos ejemplos y ejecutar otro entrenamiento
Impacto en tokens por solicitud	Bajo o moderado (solo se envían los fragmentos recuperados)	Alto (todos los documentos permanecen en el prompt)	Bajo (el conocimiento o comportamiento se incorpora a los pesos)
Atribución de fuentes	Es sencillo citar fragmentos recuperados concretos	Es posible, aunque más difícil de precisar en entradas enormes	Difícil; los pesos no registran citas explícitas de documentos
Control de acceso	Se aplica en cada consulta mediante filtros de metadatos del índice	Debe filtrarse antes de montar el prompt	Difícil de aislar; cualquier contenido de los pesos puede filtrarse a cualquier usuario

RAG frente a las ventanas de contexto largas

Como los modelos modernos admiten grandes ventanas de contexto, resulta tentador omitir la recuperación y pegar toda la base de conocimiento en cada prompt. Con unos pocos documentos cortos, eso funciona bien, especialmente si se combina con el almacenamiento en caché de prompts y una KV cache ya preparada, para no tener que procesar de nuevo los prefijos repetidos desde cero.

Sin embargo, cuando el corpus alcanza miles de archivos, introducirlo todo en el prompt tropieza con dos obstáculos:

1. Coste y latencia: enviar prompts enormes en cada turno aumenta el gasto de API y el tiempo hasta el primer token. Por eso, la recuperación selectiva sigue siendo una estrategia fundamental para reducir los costes de las API de IA.
2. Degradación de la atención: los modelos no prestan la misma atención a todas las partes de un prompt enorme. A medida que se acumula texto irrelevante en la ventana, la precisión suele disminuir, un fenómeno conocido como deterioro del contexto. RAG mantiene el prompt centrado al recuperar solo los pasajes importantes para la pregunta actual.

RAG frente al ajuste fino

El ajuste fino actualiza los pesos de un modelo con ejemplos seleccionados. Es eficaz cuando quieres que un modelo siga un esquema de salida estricto, adopte una voz de marca concreta o aprenda la sintaxis de un campo especializado. Es un mecanismo poco adecuado para enseñar al modelo hechos que cambian rápidamente.

El artículo de Lewis y colaboradores de 2020 (arXiv:2005.11401) demostró por qué la memoria no paramétrica es importante para los hechos cambiantes mediante un experimento de sustitución del índice en caliente. Los autores probaron su modelo con una copia de Wikipedia de diciembre de 2016 frente a una copia de Wikipedia de diciembre de 2018, utilizando preguntas sobre líderes mundiales que habían cambiado entre esas fechas:

• Cuando el año de la pregunta coincidía con el del índice, el modelo respondió correctamente al 70% de las preguntas sobre líderes de 2016 con el índice de 2016 y al 68% de las preguntas sobre líderes de 2018 con el índice de 2018.
• Cuando el índice no coincidía con las preguntas, la precisión bajó al 12% (índice de 2018 para líderes de 2016) y al 4% (índice de 2016 para líderes de 2018).

El simple hecho de sustituir el índice externo actualizó el conocimiento factual del sistema sobre el mundo sin volver a entrenar un solo peso del modelo.

¿Dónde falla RAG?

Añadir recuperación a un modelo de lenguaje reduce las conjeturas sobre temas privados o recientes, pero no elimina las alucinaciones de IA ni garantiza respuestas precisas. Como un sistema RAG tiene varias partes, los fallos pueden producirse tanto en la búsqueda como en la generación:

• Recuperación fallida: si el usuario formula una pregunta con términos distintos a los del documento fuente, o si la fragmentación separa una tabla de su encabezado, el recuperador puede no encontrar el pasaje que contiene la respuesta. Cuando el fragmento correcto no llega al prompt, el modelo trabaja a ciegas.
• Documentos irrelevantes o desactualizados: un índice depende de la calidad de los archivos que contiene. Si la base de conocimiento incluye las versiones de 2023 y 2026 de una guía de incorporación sin filtrar claramente las versiones obsoletas, el recuperador puede entregar instrucciones antiguas al modelo.
• Recuperación excesiva: obtener 25 fragmentos «por si acaso» suele ser contraproducente. Llenar el prompt de pasajes apenas relacionados diluye la respuesta, aumenta la latencia y puede provocar deterioro del contexto, por el que el modelo se distrae con detalles que casi encajan.
• Inyección indirecta de prompts mediante texto recuperado: si el índice ingiere contenido externo no fiable, como correos entrantes, páginas web públicas o solicitudes enviadas por usuarios, un atacante puede insertar instrucciones maliciosas en un documento. Al recuperarlo e introducirlo en el prompt, puede desencadenarse un ataque de inyección de prompts que desvíe el comportamiento del modelo.
• El modelo ignora o interpreta mal el contexto: incluso cuando el pasaje correcto está en el prompt, el generador puede interpretar mal una negación, mezclar incorrectamente dos fragmentos separados o dar prioridad a sus conocimientos previos frente al texto proporcionado cuando el pasaje recuperado contradice el conocimiento común.

Lista de comprobación para construir un sistema RAG fiable

Al pasar un prototipo RAG a producción, algunas prácticas de ingeniería disciplinadas evitan los fallos más habituales:

• Mantén el índice actualizado y sin duplicados: crea procesos automatizados que eliminen documentos borrados, archiven versiones sustituidas y asignen marcas de tiempo y URL de origen claras a cada fragmento indexado.
• Recupera menos, pero mejor: en vez de llenar el prompt con decenas de coincidencias poco relevantes, combina la búsqueda híbrida (vector + palabra clave) con filtros de metadatos y un reclasificador para enviar al generador solo un pequeño conjunto de pasajes útiles.
• Separa claramente el texto recuperado no fiable de las instrucciones del sistema: rodea los fragmentos recuperados con delimitadores estructurales explícitos, como etiquetas XML o bloques de documentos identificados, e indica en el prompt del sistema que trate esos bloques únicamente como datos de referencia pasivos, nunca como órdenes ejecutables.
• Indica al modelo que se abstenga si falta contexto: pídele que señale claramente cuándo los pasajes proporcionados no contienen información suficiente para responder. Una instrucción en el prompt no garantiza que el modelo siempre la cumpla, pero le ofrece una alternativa más clara que adivinar en silencio cuando la búsqueda no devuelve resultados.

Preguntas frecuentes

¿Siempre hace falta una base de datos vectorial para RAG?

No. La generación aumentada por recuperación solo requiere una forma de obtener texto relevante antes de llamar al modelo. Aunque las bases de datos vectoriales son populares para buscar por similitud semántica, muchos sistemas RAG en producción utilizan buscadores tradicionales por palabras clave, como BM25 en Elasticsearch o la búsqueda de texto completo de PostgreSQL, o búsquedas híbridas que combinan palabras clave y vectores.

¿Puede RAG impedir por completo que un LLM alucine?

No. RAG reduce las alucinaciones causadas por datos de entrenamiento ausentes o desactualizados porque proporciona el texto de referencia directamente en el prompt. Sin embargo, el modelo todavía puede interpretar mal un pasaje, combinar incorrectamente hechos de dos fragmentos sin relación o adivinar una respuesta cuando el recuperador trae documentos irrelevantes.

¿Debo usar RAG o ajuste fino para los documentos internos de mi empresa?

Empieza por RAG si tu objetivo es que un modelo responda preguntas sobre documentos internos que cambian con el tiempo. RAG permite añadir, editar o eliminar archivos del índice de inmediato y aplicar permisos de acceso por usuario en el momento de la consulta. El ajuste fino es más adecuado para enseñar formatos, tonos o flujos de trabajo coherentes.

Fuentes

• Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — arXiv:2005.11401
• Meta AI Research Blog — Retrieval-Augmented Generation: Streamlining the creation of intelligent natural language processing models
• AWS Prescriptive Guidance — Understanding LLMs and RAG
• AWS Machine Learning Blog — From RAG to fabric: Lessons learned from building real-world RAGs at GenAIIC – Part 1