Generación aumentada por recuperación (RAG), desde primeros principios

La generación aumentada por recuperación se presenta normalmente como una canalización de productos: un modelo de embeddings, una base de datos vectorial, un recuperador, un generador. Ese encuadre está al revés. RAG es una sola idea, y las herramientas son solo una forma de implementarla. La idea: antes de que el modelo responda, dale el material específico del que necesita responder. Todo lo demás es ingeniería.

El término viene de un artículo de 2020 de Lewis y colegas, que combinó un recuperador con un generador para que un modelo pudiera incorporar pasajes externos en lugar de depender únicamente de lo que sus pesos habían memorizado. La motivación de entonces es la motivación de ahora, y entenderla desde primeros principios sobrevivirá a cualquier herramienta particular.

El problema que RAG resuelve

Un modelo de lenguaje sabe solo lo que estaba en sus datos de entrenamiento, congelado en un punto del tiempo, mezclado en sus pesos. Eso crea dos límites:

• No puede conocer tu información privada o reciente. Los documentos de tu empresa, las notas de la versión de la semana pasada, el contenido de un PDF específico: nada de eso está en el modelo.
• El recuerdo desde los pesos es con pérdida. Incluso para cosas que están "en" el modelo, los detalles exactos pueden salir mal. El modelo está reconstruyendo a partir de una memoria comprimida, no consultando nada.

RAG aborda ambos cambiando la pregunta de "¿qué recuerda el modelo?" a "¿qué podemos poner delante del modelo ahora mismo?". Ese cambio —de la memoria a la evidencia— es todo el quid.

El mecanismo en tres pasos

En su núcleo, RAG son tres movimientos:

1. Indexar. Divide tu material fuente en pasajes y almacénalos para que puedan buscarse. La mayoría de los sistemas hacen esto convirtiendo cada pasaje en un embedding —un vector que coloca cerca los significados similares— y almacenando esos vectores.
2. Recuperar. Cuando llega una pregunta, encuentra los pasajes más relevantes para ella. Con embeddings, eso significa convertir la pregunta en un vector y traer los pasajes más cercanos.
3. Generar. Pon los pasajes recuperados en el contexto del modelo junto con la pregunta, y pídele que responda usando ese material.

Ese es el arco completo. El modelo todavía escribe la respuesta, pero ahora está leyendo de evidencia suministrada en lugar de recordar de memoria. Todo lo sofisticado en RAG es un refinamiento de uno de estos tres pasos.

Por qué embeddings, y por qué no son magia

Los embeddings te permiten buscar por significado en lugar de por palabras exactas, de modo que una pregunta sobre "tiempo libre" puede recuperar un pasaje sobre "política de vacaciones" aunque no compartan palabras clave. Eso es genuinamente útil, y es por lo que la búsqueda semántica sustenta la mayoría de los sistemas RAG. Pero dos salvedades honestas:

• La búsqueda semántica no es búsqueda exacta. Para identificadores precisos —un código de producto, un número de cláusula específico, una cadena de error— la búsqueda por palabra clave a menudo supera a los embeddings. Muchos sistemas fuertes combinan ambas, un patrón que suele llamarse búsqueda híbrida.
• La calidad de la recuperación limita todo lo que viene después. Si el paso 2 devuelve los pasajes equivocados, el modelo responde del material equivocado y suena igual de seguro. Este es el hecho más importante sobre RAG, y es el que las demos ocultan.

Fragmentación: la decisión poco glamorosa que decide la calidad

Cómo divides tus documentos en pasajes determina silenciosamente cuán bien funciona la recuperación. Los fragmentos demasiado largos diluyen la relevancia: la frase útil queda enterrada entre otras no relacionadas, y el embedding se vuelve un promedio de demasiadas ideas. Los fragmentos demasiado cortos pierden el contexto que los hace significativos. El consejo duradero es fragmentar a lo largo de fronteras naturales —secciones, párrafos, unidades lógicas— en lugar de cortar en conteos de caracteres arbitrarios. La buena fragmentación es trabajo aburrido, y rinde más que cambiar a un modelo más sofisticado.

Qué requiere realmente un buen RAG

La versión ingenua —incrusta todo, trae los pocos mejores, métrelos— funciona en una demo y decepciona en producción. Las partes que lo hacen real:

• Fragmentación sensata, como arriba.
• Suficiente contexto, pero no demasiado. Recuperar más pasajes no siempre es mejor. Los pasajes irrelevantes distraen al modelo y empujan los útiles fuera de la atención. Hay un punto óptimo, y normalmente es más pequeño de lo que la gente espera.
• Instrucciones de anclaje (grounding). Dile al modelo que responda solo a partir del material proporcionado y que diga claramente cuándo el material no contiene la respuesta. Esto es lo que convierte la recuperación en respuestas confiables en lugar de suposiciones seguras.
• Mostrar las fuentes. Devolver qué pasajes se usaron permite que un humano verifique la respuesta: esencial para cualquier cosa de alto riesgo, y un constructor de confianza silencioso en todo lo demás.

Cómo saber si tu RAG es bueno

Como la mayoría de los fallos son fallos de recuperación, evalúa la recuperación por separado de la generación. Dos preguntas, hechas sobre ejemplos reales:

1. ¿Se recuperó siquiera el pasaje correcto? Si la respuesta no está en el conjunto recuperado, ningún prompting ingenioso salvará el paso de generación.
2. Dado el pasaje correcto, ¿lo usó el modelo fielmente? Si la recuperación fue buena pero la respuesta se desvió, el problema es el anclaje, no la búsqueda.

Dividir la evaluación de este modo te dice qué mitad arreglar. Juntarlas te dice solo que "está mal", lo cual no es accionable.

Lo que RAG no arregla

RAG ancla las respuestas en texto suministrado. No hace que un modelo razone mejor, y no garantiza la verdad: si tus documentos fuente están equivocados o desactualizados, la respuesta estará confiadamente equivocada con exactamente la misma voz. También añade piezas móviles: un paso de indexación, un paso de recuperación y sus propios modos de fallo que monitorizar. RAG es la herramienta correcta cuando las respuestas deben reflejar información específica, cambiante o privada. Es excesiva cuando el modelo ya sabe lo suficiente y solo necesitas un mejor prompt.

Hacia dónde va RAG

La frontera de RAG trata sobre todo de hacer la recuperación más inteligente: decidir cuándo recuperar, recuperar en múltiples pasadas, dejar que el modelo emita sus propias consultas de búsqueda y reordenar los resultados antes de que lleguen al generador. Estas añaden capacidad y complejidad a partes iguales. La visión de primeros principios sigue siendo válida por debajo de todo ello: todas son formas de poner mejor material delante del modelo antes de que responda.

En resumen

Olvida la pila de productos por un momento. RAG es la disciplina de dejar que el modelo lea el material correcto antes de responder. Los embeddings y los almacenes vectoriales son una implementación popular, no la esencia. Acierta con la recuperación, fragmenta con cuidado, e instruye al modelo a mantenerse anclado, y RAG convierte un modelo que adivina de memoria en uno que responde a partir de evidencia, con fuentes que puedes comprobar.