Qué es RAG (generación aumentada por recuperación)

¿Qué es RAG? RAG son las siglas en inglés de retrieval-augmented generation, en español generación aumentada por recuperación: una técnica en la que un sistema busca información relevante en una base de conocimiento externa y la añade al prompt antes de que un modelo de lenguaje responda. Amazon Web Services lo describe como optimizar la salida de un modelo para que consulte una base de conocimiento autorizada, ajena a sus datos de entrenamiento, antes de generar una respuesta. Esta guía explica qué es RAG, cómo funciona paso a paso, cuándo compensa montarlo y cuándo te lo puedes ahorrar, con las fuentes primarias que listamos al final (comprobadas el 6 de octubre de 2026).

¿Qué significa RAG y de dónde viene?

El nombre viene de un artículo de investigación de 2020, «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks» (Patrick Lewis y colegas, arXiv:2005.11401). Sus autores describen RAG como modelos que combinan memoria paramétrica preentrenada y memoria no paramétrica para generar lenguaje: la memoria paramétrica es lo que el modelo aprendió al entrenarse, y la no paramétrica, un almacén externo que puede consultar. Hoy la palabra suele referirse al patrón de producto más sencillo: buscar primero, preguntar después al modelo con los resultados en el prompt.

¿Cómo funciona RAG?

AWS enumera cuatro pasos que casi todos los sistemas RAG siguen de algún modo:

1. Crear los datos externos. Los documentos se convierten en representaciones numéricas (embeddings) y se guardan en una base de datos vectorial.
2. Recuperar la información relevante. La pregunta del usuario se convierte en un vector y se compara con los vectores guardados.
3. Aumentar el prompt. Los pasajes recuperados se añaden al prompt, con instrucciones sobre cómo usarlos.
4. Mantener los datos al día. Los documentos y sus embeddings se actualizan de forma programada o por lotes.

Después el modelo responde usando los pasajes que tiene delante. Como esos pasajes se pueden mostrar al lector, un sistema RAG puede citar de dónde sale una respuesta, algo que AWS cuenta entre sus principales ventajas para generar confianza.

Tabla: qué hace cada fase de un sistema RAG

¿Qué problema resuelve RAG?

Un modelo solo sabe lo que había en sus datos de entrenamiento y lo que está en el prompt. RAG resuelve tres límites, según AWS: evita reentrenar un modelo cada vez que cambia tu información, puede conectar el modelo con fuentes actuales y permite a los usuarios verificar las respuestas gracias a la atribución de fuentes. Además, mantiene tus documentos privados fuera de los pesos del modelo, porque viven en un almacén que controlas tú.

No hace infalible a un modelo. La recuperación puede fallar: Anthropic midió una tasa de fallo de partida del 5,7 % en su propio conjunto de pruebas, es decir, que en esas pruebas el pasaje correcto faltaba entre los primeros resultados aproximadamente una vez de cada dieciocho. Lo que se recupera solo es tan bueno como los documentos que hay detrás, y aun con buenos pasajes un modelo puede afirmar algo que no dicen, por eso basar las respuestas en citas y referencias es una de las medidas de nuestra guía de alucinaciones de los modelos.

¿Necesitas RAG o puedes pegarlo todo en el prompt?

La recomendación de Anthropic es prescindir de RAG cuando la base de conocimiento es pequeña: si es menor que unos 200.000 tokens (más o menos 500 páginas), inclúyela directamente en el prompt. Las ventanas actuales son mucho mayores, con 1M de tokens para los modelos Claude actuales y 1.050.000 para GPT-6.1 Sol, pero una ventana mayor no elimina dos problemas: pagas por cada token que envías y los fabricantes avisan de que la precisión puede bajar al llenarse la ventana. Nuestra guía sobre la ventana de contexto recoge las cifras y los costes.

Una regla sencilla: si todo tu material cabe cómodamente en un prompt y cambia poco, prueba primero con el prompt. Si es grande, cambia a menudo o hay que citarlo, usa recuperación.

¿Cómo mejorar un sistema RAG?

El trabajo de «recuperación contextual» de Anthropic da ideas medidas. El troceado tradicional «a menudo destruye el contexto», así que antepone una explicación de dónde sale cada trozo antes de calcular su embedding. Combinado con una función de ranking léxico llamada BM25, que se da bien con palabras, códigos e identificadores exactos, y con un paso de reordenación, reduce los fallos de recuperación frente al punto de partida:

Tabla: resultados que publica Anthropic en su conjunto de pruebas

Son cifras de Anthropic con sus datos. Tus documentos se comportarán de otra manera, así que mide tu propia recuperación: escribe una lista de preguntas reales, anota qué pasaje debería responder a cada una y comprueba con qué frecuencia se recupera antes de juzgar las respuestas del modelo.

RAG, fine-tuning y agentes

RAG pone conocimiento en el prompt en el momento de la pregunta. El fine-tuning cambia el propio modelo, y sirve para un estilo o una tarea fijos más que para hechos que cambian. No son alternativas en todos los casos y muchos sistemas usan las dos: nuestra guía de RAG vs fine-tuning da una guía para decidir. Un agente puede usar la recuperación como una de sus herramientas, y protocolos como MCP estandarizan cómo se conecta un modelo con un almacén de documentos o una base de datos.

Qué comprobar antes de montarlo

• Qué documentos entran y quién puede verlos: un almacén RAG puede exponer todo lo que indexes.
• Cómo se actualiza el conocimiento, porque unos embeddings desfasados dan respuestas desfasadas.
• Si las respuestas muestran sus fuentes, para que el lector pueda comprobarlas.
• Una batería de preguntas reales, para medir la recuperación por separado de la generación.
• El coste de los tokens adicionales, que puedes estimar con nuestra calculadora de costes de API.
• Si el sistema habla con clientes o empleados en la UE, qué te exige el Reglamento (UE) 2024/1689 (por ejemplo, avisar de que hablan con una máquina). Si hay datos personales de por medio, también cuenta el reglamento de protección de datos, que esta guía no cubre.