¿Qué es RAG (Generación Aumentada por Recuperación)?

RAG es un sistema donde un LLM consulta documentos externos antes de responder. En vez de contestar solo con lo que aprendió durante el entrenamiento, el modelo recibe además fragmentos de una fuente controlada por el operador del sistema.

El nombre viene del inglés Retrieval-Augmented Generation. Se propone en el paper Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks de Lewis et al.

La idea es combinar dos memorias. La memoria paramétrica del modelo (lo que aprendió durante el entrenamiento, comprimido en sus pesos) con una memoria no paramétrica (una base de documentos que el sistema consulta en tiempo de inferencia).

Las Tres Fases

Un sistema RAG tiene tres fases claras:

Retrieval: el sistema busca en la base de documentos los fragmentos que más se parecen a la pregunta del usuario.

Augmentation: los fragmentos seleccionados se añaden al prompt junto con la pregunta.

Generation: el modelo genera la respuesta usando la pregunta y los fragmentos como contexto.

El modelo no cambia. Lo que cambia es la entrada. Cuando la decisión de cuándo recuperar se delega en el propio modelo dentro de un bucle iterativo, RAG deja de ser una fase fija y pasa a ser una herramienta de un agente.

Cómo se Preparan los Documentos

Antes de que el sistema pueda buscar, los documentos se preprocesan:

Chunking: cada documento se divide en trozos llamados fragmentos o chunks. Fragmentos muy grandes diluyen la relevancia. Fragmentos muy pequeños pierden contexto.

Embedding: cada fragmento se transforma en un vector numérico llamado embedding usando un modelo separado. El vector representa el significado del fragmento en un espacio de alta dimensión. Fragmentos con temas parecidos acaban con vectores próximos.

Indexado: los vectores se guardan en una base de datos vectorial que permite buscar por proximidad. Cualquier índice de aproximación de vecinos más cercanos (ANN) sirve. Implementaciones habituales: FAISS, Milvus, Weaviate, Pinecone, Chroma.

Cómo Funciona una Consulta

Cuando llega una pregunta del usuario:

1. La pregunta se convierte en un embedding con el mismo modelo que se usó para los documentos.
2. La base de datos devuelve los top-k fragmentos cuyos embeddings son más cercanos al de la pregunta.
3. Los fragmentos se insertan en el prompt del LLM, normalmente antes de la pregunta.
4. El LLM genera la respuesta condicionado por esos fragmentos.

La medida de cercanía suele ser el coseno o el producto escalar. Fragmentos con vectores próximos hablan de temas parecidos.

Contextual Retrieval

Una variante que reduce los fallos de recuperación se llama contextual retrieval. Antes de generar el embedding, se le añade a cada fragmento un párrafo corto que sitúa el fragmento dentro del documento completo. Con eso, el embedding captura no solo el contenido del fragmento sino su contexto original.

Está descrito en Introducing Contextual Retrieval de Anthropic Engineering.

Por Qué RAG No Elimina las Alucinaciones

Tener documentos disponibles no garantiza que el modelo se ciña a ellos. El benchmark RAGTruth, descrito en RAGTruth: A Hallucination Corpus for Developing Trustworthy Retrieval-Augmented Language Models de Niu et al., documenta tres tipos de fallo del modelo cuando trabaja con contexto recuperado:

Contradicción con la fuente: el modelo dice algo que contradice el fragmento que tiene delante.

Extrapolación: el modelo añade conclusiones que la fuente no sostiene.

Ignorancia del contexto: el modelo ignora el fragmento y responde con su memoria paramétrica.

RAG mejora la precisión factual pero no la garantiza. La alucinación sigue siendo posible.

Fallos Posibles del Sistema

Un pipeline RAG puede romperse en varios puntos:

Recuperación irrelevante: los top-k fragmentos no contienen la respuesta. La pregunta se responde sin evidencia útil.

Recuperación de versión antigua: hay varias versiones del mismo documento indexadas. El sistema devuelve una obsoleta.

Fragmento cortado a mitad de idea: el chunking parte una frase clave y pierde el matiz.

Colisión semántica: dos documentos con vectores parecidos pero temas distintos aparecen juntos y el modelo mezcla.

Ventana rebasada: los fragmentos recuperados no caben en la ventana de contexto del modelo y algunos se descartan silenciosamente. Priorizar qué fragmentos entran y dónde se colocan es un problema de ingeniería de contexto.

Groundedness y Trazabilidad

Para verificar una respuesta RAG hay dos conceptos:

Groundedness: cada afirmación de la respuesta se puede localizar en los fragmentos recuperados. Si algo no está en los fragmentos, no debería estar en la respuesta.

Trazabilidad: la respuesta cita explícitamente qué fragmento respalda cada afirmación. Permite a un humano verificar el origen.

El documento NIST AI 600-1: Generative AI Profile recomienda ambos criterios para sistemas de generación con IA en contextos donde el operador asume responsabilidad por la salida.

Qué pasa en la práctica

• Un pipeline RAG con embeddings genéricos funciona sorprendentemente bien para la mayoría de los casos. La cola larga requiere ajuste.
• La calidad de los documentos indexados impone un techo. Basura entra, basura sale.
• Cambiar el modelo de embedding sin reindexar rompe la recuperación.
• Los fragmentos muy grandes ahorran llamadas pero diluyen relevancia. El equilibrio es empírico.
• Pedir al modelo que cite el fragmento fuente en su respuesta mejora la trazabilidad sin cambiar el modelo.

Error común

Creer que RAG hace al modelo “más inteligente” o “actualizado”. No. El modelo sigue siendo el mismo. Lo que cambia es el contexto que recibe en cada llamada. Un modelo mediocre con RAG sigue siendo un modelo mediocre.

Para el uso práctico y ejemplos concretos de una tienda que atiende clientes con RAG: Guía sobre RAG: inteligencia artificial con consulta de fuentes.

---

Comparte si te ha sido útil

Compartir