RAG (Retrieval-Augmented Generation): definición y funcionamiento

El RAG es una de las piezas técnicas que alimentan a los agentes de IA autónomos de hoy, junto con la llamada a herramientas y la memoria persistente. La sigla viene de un artículo de investigación publicado en mayo de 2020 por un equipo de Facebook AI Research (hoy Meta), con Patrick Lewis a la cabeza. En ese momento, el diagnóstico era sencillo: los grandes modelos de lenguaje almacenan una cantidad impresionante de conocimiento en sus parámetros, pero no pueden actualizarlo fácilmente ni señalar con precisión una fuente. El RAG propone una solución: dejar que el modelo vaya a buscar la información en una base externa en el momento de responder, en lugar de hacer descansar todo sobre su memoria fijada en el entrenamiento.

Definición detallada

Retrieval-Augmented Generation, o generación aumentada por recuperación, designa una arquitectura que combina dos piezas distintas: un mecanismo de búsqueda (retrieval) que va a buscar pasajes pertinentes en una base documental externa, y un modelo de generación de texto que redacta la respuesta final a partir de esos pasajes. En el artículo fundacional de Lewis y sus coautores (NeurIPS 2020), el RAG combina una memoria paramétrica (el conocimiento interno del modelo preentrenado) y una memoria no paramétrica (una base de documentos consultada al vuelo), para mejorar el rendimiento en tareas que exigen conocimientos precisos.

El consenso en torno a esta definición es amplio: ya sea en la literatura académica o en las explicaciones para el público general como la de NVIDIA, el RAG siempre remite a esta misma mecánica en dos tiempos, buscar y luego generar. Las divergencias tienen que ver sobre todo con la implementación técnica (tipo de base vectorial, método de fragmentación de los documentos, número de pasajes recuperados), no con la definición del principio en sí.

El RAG responde a dos límites conocidos de los modelos de lenguaje: las alucinaciones, cuando el modelo inventa una respuesta plausible pero falsa, y la obsolescencia, cuando una información ha cambiado desde la fecha de entrenamiento del modelo. Al anclar la generación en documentos reales y actualizados, el RAG reduce estos dos problemas sin necesidad de reentrenar el modelo.

Cómo funciona

El desarrollo típico de una solicitud RAG sigue tres pasos. Primero, la pregunta del usuario (o la necesidad de un agente) se transforma en una búsqueda en una base documental, a menudo mediante una búsqueda de similitud sobre representaciones vectoriales del texto, a veces combinada con una búsqueda por palabras clave clásica. Después, los pasajes más pertinentes que arroja esa búsqueda se inyectan en el contexto enviado al modelo de lenguaje, además de la pregunta inicial. Por último, el modelo genera su respuesta apoyándose en esos pasajes, idealmente citándolos o alineándose con su contenido en lugar de improvisar.

Esta mecánica se presta bien al uso por un agente de IA autónomo: la búsqueda documental puede exponerse como una herramienta que el agente llama él mismo, en el momento en que considera que la necesita, en lugar de activarse sistemáticamente antes de cada respuesta. Esa es la diferencia entre un RAG «estático», conectado antes de cada solicitud, y un RAG «agéntico», donde el modelo decide cuándo buscar, qué buscar, y si debe volver a buscar si el primer resultado no basta.

Ejemplo concreto con Atako

La documentación pública de Atako no detalla la arquitectura interna de búsqueda documental que usan sus agentes, así que no es posible afirmar aquí que Atako use RAG en el sentido estricto del artículo de Lewis et al. Lo que sí está documentado, en cambio, es el mecanismo más cercano: cada agente dispone de una biblioteca de archivos compartida por la empresa, organizada en carpetas, con formatos previsualizables (Markdown, CSV, JSON, PDF, HTML, imágenes, texto, código fuente). Estos archivos pueden compartirse con un agente en lectura, o añadirse directamente en una carpeta dedicada al agente, por una persona o por el propio agente.

Esta biblioteca de archivos, combinada con la memoria persistente de un agente que sobrevive a reinicios y pausas, cumple el papel de base de conocimiento externa que el agente puede consultar antes de responder o actuar, lo que se corresponde en espíritu con el principio del RAG: ir a buscar información real en lugar de apoyarse únicamente en lo que el modelo memorizó en el entrenamiento. Un agente configurado para el soporte al cliente, por ejemplo, puede consultar archivos de documentación de producto compartidos en su carpeta antes de responder a un ticket, en lugar de adivinar la respuesta.

Errores frecuentes

Primera confusión frecuente: creer que el RAG es una funcionalidad que se activa con un clic, como un botón en un software. En realidad es una arquitectura, con decisiones técnicas concretas (cómo fragmentar los documentos, cómo indexarlos, cuántos pasajes recuperar) que determinan directamente la calidad de las respuestas.

Segundo error: pensar que el RAG elimina totalmente las alucinaciones. Las reduce anclando la generación en documentos verificables, pero un modelo aún puede interpretar mal un pasaje, o generar una respuesta a partir de documentos no pertinentes que trajo una búsqueda imperfecta. El RAG desplaza el riesgo, no lo suprime.

Tercer error: confundir RAG y fine-tuning. El fine-tuning modifica de forma duradera el modelo reentrenándolo con datos específicos; el RAG deja el modelo intacto y le añade una base externa consultada en cada solicitud, lo que resulta más rápido de actualizar y generalmente menos costoso.

Por último, subestimar la importancia de la calidad de la base documental es un error clásico. Un sistema RAG conectado a documentos obsoletos, mal estructurados o incompletos producirá respuestas de mala calidad, sea cual sea la potencia del modelo de generación usado detrás.