GUÍA TÉCNICA
Qué es RAG en IA: cómo funciona y qué papel tiene en un agente
Un modelo de lenguaje puede trabajar con la información que recibe en su contexto. RAG permite buscar conocimiento externo relevante y llevarlo hasta ese contexto justo cuando la tarea lo necesita.
Las siglas significan Retrieval-Augmented Generation, o generación aumentada por recuperación. La idea fundamental no consiste en «enseñar» todos los documentos al modelo ni en reentrenarlo cada vez que cambia una política. Consiste en buscar información relevante, incorporarla al contexto disponible para la tarea y generar a partir de esa evidencia.
Eso también explica su principal dificultad: RAG no mejora una respuesta por el simple hecho de existir. Si recupera la fuente equivocada, un fragmento incompleto o una política desactualizada, el modelo recibe un contexto defectuoso.
RESPUESTA RÁPIDA
RAG combina recuperación de información y generación con un modelo de lenguaje. Ante una consulta, el sistema busca contenido relevante en fuentes externas, selecciona la evidencia adecuada y la incorpora al contexto antes de generar. No modifica necesariamente los parámetros del modelo, no es sinónimo de memoria, no exige siempre una base vectorial y no convierte por sí solo un chatbot en agente.
Su utilidad depende tanto de la calidad del modelo como de algo menos visible: encontrar la evidencia correcta y respetar quién tiene permiso para verla.
¿Qué significa RAG?
RAG significa Retrieval-Augmented Generation, o generación aumentada por recuperación.
El nombre describe dos operaciones que ocurren juntas.
Retrieval — recuperación. El sistema localiza información que puede ser relevante para una consulta.
Augmented generation — generación aumentada. La información recuperada se añade al contexto que recibe el modelo para que pueda utilizarla al producir una respuesta, un análisis o una decisión.
El trabajo académico que popularizó el término en 2020 combinaba una memoria paramétrica —el conocimiento representado en los parámetros de un modelo— con una memoria no paramétrica recuperada desde una colección externa. Desde entonces, el término RAG se ha extendido a arquitecturas muy distintas.
Hoy puede aplicarse a documentación corporativa, manuales, procedimientos, contratos, tickets, artículos técnicos, catálogos, políticas internas o información obtenida desde sistemas externos.
La implementación concreta puede variar mucho. Lo importante no es una base de datos determinada ni una librería concreta.
consulta → recuperar evidencia → añadir contexto → generar
Por eso conviene pensar en RAG como una arquitectura de acceso a conocimiento, no como un producto.
RAG lleva evidencia al contexto en tiempo de ejecución
La recuperación ocurre antes de generar; no significa que los documentos se hayan incorporado a los parámetros del modelo.
Equivalente textual del diagrama
- FUENTES: Documentos · sistemas · datos.
- RECUPERACIÓN: Buscar y seleccionar evidencia.
- CONTEXTO: Añadir lo relevante a la tarea.
- MODELO: Interpretar la pregunta + evidencia.
- RESPUESTA: Generar con el contexto disponible.
El problema que RAG intenta resolver
Los modelos de lenguaje no tienen acceso automático a toda la información que una empresa necesita utilizar.
Parte de su conocimiento procede del entrenamiento. Pero una organización trabaja con información que puede ser privada, reciente, específica del negocio, cambiante, demasiado extensa, sometida a permisos o inexistente durante el entrenamiento del modelo.
Imagina una pregunta interna:
¿Cuál es el procedimiento actual para aprobar una compra por encima del límite establecido?
La respuesta puede depender de una política que cambió hace tres semanas y está almacenada en un repositorio interno.
Podríamos copiar toda la documentación al contexto cada vez que alguien pregunta, pero eso deja de ser práctico a medida que crecen el volumen, el número de fuentes y la frecuencia de actualización.
RAG introduce una capa intermedia. En lugar de enviar todo, intenta recuperar solo la información que parece relevante para esa consulta.
Así podemos separar dos problemas: encontrar la evidencia adecuada y utilizar esa evidencia para responder o continuar una tarea.
Esta separación es importante. Una respuesta incorrecta no siempre significa que «el modelo no sabe». Puede significar que el sistema nunca le mostró la fuente correcta.
Cómo funciona RAG paso a paso
Un sistema RAG suele tener dos momentos diferentes: preparar las fuentes y recuperarlas cuando llega una consulta.
1. Preparar las fuentes
Antes de responder preguntas, el sistema necesita saber con qué información puede trabajar.
Seleccionar fuentes. Definir qué repositorios, documentos, bases de datos o sistemas son válidos.
Extraer contenido. Un PDF, una página web, una hoja de cálculo y un registro de una aplicación no tienen la misma estructura. Hay que convertirlos en una representación utilizable.
Limpiar y normalizar. Eliminar ruido, detectar duplicados y conservar títulos, fechas, secciones, identificadores y otros metadatos relevantes.
Dividir el contenido cuando sea necesario. Los documentos largos suelen separarse en fragmentos, o chunks, para poder recuperar partes concretas.
Indexar. El contenido se prepara para poder buscarlo. Esa indexación puede utilizar palabras clave, representaciones vectoriales, campos estructurados o varias técnicas a la vez.
Conservar metadatos y permisos. Una política para dirección, un contrato confidencial y un manual público no deberían tratarse como si tuvieran el mismo acceso.
Este punto es fácil de pasar por alto: si durante la preparación destruimos estructura, contexto o permisos, el problema aparecerá después durante la recuperación.
2. Recuperar cuando llega una consulta
Cuando alguien hace una pregunta, comienza la fase de ejecución.
Pregunta → búsqueda → selección → contexto → modelo → respuesta
El sistema puede transformar o enriquecer la consulta. Después busca contenido relacionado. Los resultados pueden ordenarse o volver a puntuarse para intentar colocar primero los fragmentos más útiles.
Una selección de esos fragmentos se incorpora al contexto que recibe el modelo. El modelo genera entonces su respuesta utilizando la pregunta original y la evidencia recuperada.
En una implementación seria puede haber además filtros por usuario, fecha o identificador; combinación de varias fuentes; reranking; límites de contexto; instrucciones para citar; umbrales mínimos de relevancia y un comportamiento específico cuando no existe evidencia suficiente.
El dibujo sencillo sigue siendo útil, pero detrás puede existir bastante ingeniería.
RAG no es una base de datos vectorial
Una de las simplificaciones más frecuentes consiste en explicar RAG como:
Documentos → embeddings → base vectorial → búsqueda → LLM
Es una arquitectura muy habitual. No es la definición de RAG.
Búsqueda léxica
Busca coincidencias de palabras o términos. Puede ser especialmente útil cuando importan identificadores exactos, referencias, nombres técnicos o códigos.
Si alguien pregunta por TS-999, una coincidencia textual exacta puede ser más importante que encontrar fragmentos «semánticamente parecidos».
Búsqueda vectorial
Los textos se representan mediante embeddings, vectores numéricos que permiten comparar similitud semántica.
Esto ayuda a recuperar contenido relacionado aunque la consulta no utilice exactamente las mismas palabras. «¿Cómo se autorizan los gastos elevados?» podría encontrar una sección titulada «Procedimiento de aprobación de compras extraordinarias».
Búsqueda híbrida
Combina señales léxicas y vectoriales. Esta combinación puede ser útil precisamente porque los dos métodos fallan de manera distinta.
Filtros y consultas estructuradas
Algunos datos no necesitan búsqueda semántica. Si la pregunta depende de estado, fecha, cliente, categoría, identificador, permiso o relaciones entre registros, puede ser mejor filtrar, consultar SQL o utilizar una API.
RAG puede incorporar esos resultados igualmente.
RAG no significa «usar una base vectorial». Significa recuperar contexto relevante antes de generar.
El problema difícil: recuperar el contexto correcto
La generación es la parte más visible de RAG. La recuperación suele ser la parte que determina si la respuesta tiene una buena base.
Imagina que existen cinco documentos: una política actual, una versión antigua, una presentación que la resume parcialmente, una excepción para un departamento y un correo donde alguien interpreta la norma.
Todos contienen vocabulario parecido.
¿Cuál debe recuperar el sistema?
La fuente puede estar mal
El documento puede estar desactualizado, duplicado o no ser una fuente autorizada.
La extracción puede perder información
Tablas, notas, títulos o relaciones visuales pueden desaparecer durante el procesamiento.
El fragmento puede carecer de contexto
Un chunk aislado puede contener «Requiere aprobación previa» y haber perdido el encabezado que indicaba a qué tipo de compra se refiere.
Anthropic ha señalado precisamente este problema al explicar técnicas de recuperación contextual: dividir documentos ayuda a buscarlos, pero puede eliminar información que daba significado al fragmento.
La consulta puede ser deficiente
La pregunta del usuario puede ser ambigua o utilizar terminología distinta de la documentación.
El buscador puede recuperar algo parecido, pero incorrecto
La similitud semántica no equivale a relevancia.
El ranking puede ordenar mal los resultados
La fuente correcta puede existir y haber sido recuperada, pero quedar fuera de los fragmentos que finalmente llegan al modelo.
Varias fuentes pueden contradecirse
RAG no resuelve automáticamente qué documento tiene autoridad. Hay que definir jerarquías, vigencia o reglas de procedencia.
Por eso una evaluación seria no debería preguntar solo si la respuesta final parece buena. También debería preguntar: ¿Recuperamos la evidencia que necesitábamos?
Dónde puede fallar RAG
Una respuesta deficiente puede originarse antes de que el modelo empiece a escribir.
Equivalente textual del diagrama
- FUENTE: Obsoleta, duplicada o sin autoridad.
- EXTRACCIÓN: Se pierde estructura o contexto.
- CONSULTA: Ambigua o mal formulada.
- RETRIEVAL: Recupera algo parecido, no lo correcto.
- RANKING: La evidencia buena queda fuera.
- GENERACIÓN: Mezcla, extrapola o ignora evidencia.
Si recuperas el contexto equivocado, el modelo parte del problema equivocado.
¿RAG evita las alucinaciones?
No.
RAG puede reducir determinados errores porque ofrece al modelo información relevante y puede facilitar que la respuesta se apoye en fuentes conocidas.
Pero no crea una garantía de verdad.
El sistema puede recuperar información incorrecta, no encontrar la fuente relevante, recuperar una versión antigua, mezclar fragmentos incompatibles, interpretar mal la evidencia, extrapolar más allá de lo que dicen las fuentes o responder aunque no exista soporte suficiente.
Incluso mostrar citas no garantiza que una afirmación esté realmente respaldada por ellas. Una cita indica procedencia potencial; la correspondencia entre afirmación y evidencia también necesita evaluarse.
Por eso un diseño robusto puede definir qué hacer cuando la evidencia es insuficiente: reconocer que no se encontró información, pedir aclaración, realizar otra búsqueda, limitar la respuesta, escalar o permitir revisión humana.
Tener fuentes no es lo mismo que usar correctamente las fuentes.
RAG vs fine-tuning
RAG y fine-tuning resuelven problemas diferentes, aunque pueden combinarse.
Si una empresa actualiza cada semana procedimientos, tarifas o documentación, intentar «meter» todos esos cambios en los parámetros del modelo suele atacar el problema equivocado.
RAG permite mantener el conocimiento fuera del modelo y recuperarlo cuando hace falta.
Eso no significa que fine-tuning sea inútil. Puede tener sentido si queremos modificar cómo se comporta el modelo ante una tarea, el formato de sus salidas o determinados patrones.
Conocimiento recuperable y comportamiento aprendido no son la misma dimensión.
RAG vs memoria
RAG y memoria también suelen confundirse.
RAG describe un mecanismo de recuperación de información.
La memoria describe, de forma más amplia, cómo un sistema conserva y reutiliza información sobre estados, interacciones, preferencias, hechos o experiencias a lo largo del tiempo.
Una implementación de memoria puede utilizar recuperación. Por ejemplo, un agente podría almacenar resúmenes de interacciones y recuperarlos más adelante mediante búsqueda.
Pero también puede existir RAG sin memoria personal alguna: una persona pregunta por una política corporativa y el sistema recupera la documentación correspondiente.
Y puede existir estado o memoria de sesión sin un sistema RAG completo.
En memoria en agentes de IA desarrollamos esta diferencia de forma específica. Para este artículo basta con conservar la frontera:
Recuperar conocimiento externo no es lo mismo que recordar una experiencia anterior.
Qué papel tiene RAG dentro de un agente de IA
RAG puede ser una capacidad dentro de un sistema más amplio.
Imagina un agente que debe revisar una solicitud de compra. Recibe un objetivo:
Revisar la solicitud y preparar el siguiente paso permitido.
Antes de decidir, necesita conocer la política vigente, el nivel de autorización, las excepciones, la documentación del proveedor y quizá información del propio sistema de compras.
RAG puede ayudarle a recuperar la política y documentación relevantes.
Pero la recuperación no decide necesariamente qué hacer.
RAG aporta evidencia.
El agente decide cómo utilizar esa evidencia dentro del proceso autorizado.
Eso puede significar detectar que necesita consultar una política, formular una búsqueda, recuperar documentación, observar si la evidencia es suficiente, realizar otra búsqueda, consultar una herramienta diferente, preparar una recomendación, solicitar aprobación y ejecutar una acción solo si tiene permiso.
El mismo mecanismo RAG podría estar detrás de un chatbot que solo responde preguntas o de un workflow predefinido.
Lo que convierte el sistema en agéntico no es RAG. Es el control que recibe el modelo sobre cómo avanzar.
Si quieres profundizar en esa frontera, la guía sobre qué es un agente de IA y cómo funciona explica el sistema completo, mientras que agente de IA vs automatización desarrolla cuándo conviene mantener el recorrido determinista.
RAG dentro de un agente
RAG aporta evidencia; el comportamiento agéntico determina cuándo recuperarla y qué hacer después con ella.
Equivalente textual del diagrama
- OBJETIVO: El agente recibe una tarea.
- ¿EVIDENCIA?: Decide si necesita recuperar información.
- RAG / BÚSQUEDA: Consulta fuentes autorizadas.
- OBSERVAR: Lee la evidencia recuperada.
- DECIDIR: Elige el siguiente paso dentro de límites.
- SALIDA: Responde · usa herramienta · escala.
RAG clásico vs agentic RAG
A medida que las consultas se vuelven más complejas, también puede cambiar la forma de recuperar.
RAG clásico
Una arquitectura simplificada puede seguir esta ruta:
Consulta → búsqueda → resultados → contexto → respuesta
El sistema sabe de antemano que hará una recuperación y después llamará al modelo. Es predecible y puede ser suficiente para muchísimos casos.
Agentic RAG o recuperación agéntica
En una arquitectura más dinámica, el sistema puede analizar la pregunta, dividirla en subpreguntas, reformular consultas, buscar en varias fuentes, ejecutar búsquedas en paralelo, observar qué ha encontrado y decidir si necesita recuperar más.
Microsoft utiliza el término agentic retrieval para describir un patrón de este tipo en Azure AI Search.
La diferencia importante no es el nombre. Es que la propia estrategia de recuperación deja de estar completamente predefinida.
Eso puede aportar capacidad en preguntas complejas, pero también introduce más llamadas, latencia, coste, rutas de fallo y necesidades de observabilidad.
Por tanto, no deberíamos interpretar RAG clásico → agentic RAG como una evolución obligatoria.
Si una consulta sencilla puede resolverse con una búsqueda bien diseñada, añadir un agente para realizarla no mejora automáticamente la arquitectura.
Cuándo no necesitas RAG
RAG es útil, pero no debería convertirse en una respuesta por defecto a cualquier problema de conocimiento.
El material ya cabe razonablemente en el contexto
Si trabajas con un documento pequeño y la tarea es puntual, puede ser más sencillo entregar directamente ese documento al modelo. Los modelos con ventanas de contexto amplias hacen esta opción relevante en algunos escenarios.
La fuente ya está estructurada
Si necesitas conocer el estado exacto de una factura o el saldo de una cuenta, una consulta a una API o base de datos puede ser más adecuada que convertir esos datos en documentos para búsqueda semántica.
El problema se resuelve con una regla
No necesitas recuperación para aplicar una condición que ya conoces.
La tarea no necesita conocimiento externo
Un modelo puede transformar, resumir o clasificar información que ya viene incluida en la petición.
El corpus es pequeño y estable
La infraestructura de ingesta, indexación, actualización y evaluación puede costar más que el problema que resuelve.
Google Cloud señala precisamente la relación entre RAG y long context: cuando el material de referencia cabe de forma práctica en contexto, proporcionar esas fuentes directamente puede ser una alternativa; RAG gana valor cuando necesitamos recuperar selectivamente de conjuntos mayores o reducir el contexto enviado.
La pregunta no es «¿Podemos montar RAG?». Es ¿qué problema de acceso a información necesitamos resolver?
Permisos y seguridad: recuperar no significa poder verlo todo
Una arquitectura RAG introduce una pregunta que no puede dejarse al modelo:
¿Qué información tiene derecho a recuperar este usuario o proceso?
Si una persona no puede abrir un documento confidencial en el sistema original, RAG no debería filtrárselo porque un fragmento terminó en el mismo índice que otros documentos.
Los permisos necesitan mantenerse durante la recuperación.
También existe otro riesgo: el contenido recuperado puede contener instrucciones.
Un documento externo podría incluir texto que intenta modificar el comportamiento del modelo. Para el sistema, ese contenido debería tratarse como datos, no como una instrucción automáticamente confiable.
OWASP clasifica la inyección de instrucciones, incluida la indirecta desde contenido externo, como un riesgo importante en aplicaciones con modelos generativos. En sistemas que además disponen de herramientas, el impacto potencial puede ser mayor.
En una introducción a RAG basta con conservar dos principios:
El control de acceso debe aplicarse antes o durante la recuperación.
El contenido recuperado no debe adquirir autoridad solo por haber entrado en el contexto.
Qué debería revisar una empresa antes de implementar RAG
Antes de elegir una base vectorial, un framework o un proveedor, conviene responder preguntas más básicas.
¿Cuáles son las fuentes autorizadas?
Distingue documentación oficial, borradores, copias, versiones antiguas y contenido que no debería utilizarse como conocimiento operativo.
¿Quién puede ver cada fuente?
Los permisos forman parte de la arquitectura. La recuperación no debe ampliar el acceso que una persona ya tiene en los sistemas originales.
¿Cómo se actualiza la información?
Define cómo se detectan cambios, cómo se reindexan las fuentes y qué ocurre con versiones anteriores o contenido obsoleto.
¿Qué clase de búsqueda necesitamos?
Decide si importan coincidencias exactas, similitud semántica, filtros, datos estructurados, búsqueda híbrida o varias fuentes.
¿Cómo se conservará el contexto del documento?
Títulos, secciones, tamaño de fragmento y metadatos influyen en lo que puede recuperarse y comprenderse después.
¿Cómo sabremos si recuperamos lo correcto?
Evalúa retrieval por separado de la respuesta. Si la fuente adecuada nunca llega al modelo, cambiar el prompt puede no resolver el problema.
¿Qué hará el sistema cuando no encuentre evidencia?
Puede reconocer insuficiencia, pedir aclaración, repetir la búsqueda, consultar otra fuente o escalar, en lugar de responder por obligación.
¿Necesitamos mostrar fuentes?
Las citas pueden ayudar a revisar procedencia y evidencia, aunque no garantizan por sí solas que cada afirmación sea correcta.
¿La salida es informativa o puede activar acciones?
Cuando la evidencia influye en una acción externa aumentan las necesidades de permisos, controles y supervisión.
¿Cómo evaluaremos el sistema completo?
Mide recuperación, relevancia, cobertura, fidelidad a la evidencia, comportamiento sin respuesta, permisos, coste y latencia.
Al responder estas preguntas, la tecnología concreta resulta mucho más fácil de elegir.
Preguntas frecuentes
¿Qué significa RAG en inteligencia artificial?
RAG significa Retrieval-Augmented Generation, o generación aumentada por recuperación. El sistema recupera información externa relevante y la incorpora al contexto que recibe un modelo antes de generar una respuesta o continuar una tarea.
¿RAG necesita una base de datos vectorial?
No. La búsqueda vectorial es una técnica muy utilizada, pero RAG puede recuperar mediante palabras clave, búsqueda semántica, métodos híbridos, filtros, consultas estructuradas, APIs u otras combinaciones. Lo importante es recuperar evidencia útil.
¿RAG elimina las alucinaciones?
No. Puede reducir determinados errores al proporcionar información relevante, pero la recuperación puede fallar y el modelo puede interpretar mal, mezclar o extrapolar la evidencia. RAG reduce algunos riesgos; no convierte la generación en una fuente garantizada de verdad.
¿RAG es memoria?
No como sinónimo. RAG es un patrón de recuperación. La memoria se refiere de forma más amplia a cómo un sistema conserva y reutiliza información a lo largo del tiempo. Una memoria puede utilizar técnicas de recuperación, pero RAG también puede funcionar sin memoria personal o histórica.
¿RAG entrena al modelo con mis documentos?
Normalmente no. En un sistema RAG los documentos se preparan para búsqueda y los fragmentos recuperados se incorporan al contexto durante la tarea. Eso es distinto de modificar los parámetros del modelo mediante entrenamiento o fine-tuning.
¿RAG y fine-tuning se pueden combinar?
Sí. Un modelo puede estar ajustado para un determinado comportamiento y utilizar RAG para acceder a conocimiento privado o actualizado durante la ejecución. Resuelven dimensiones diferentes.
¿Un chatbot con RAG es un agente de IA?
No necesariamente. Puede existir un chatbot que recupere documentación y responda siguiendo un recorrido totalmente predefinido. Para hablar de comportamiento agéntico hay que observar qué control tiene el modelo sobre el proceso, las herramientas y los siguientes pasos.
¿Qué es agentic RAG?
Es un término utilizado para arquitecturas donde un agente participa activamente en la estrategia de recuperación: puede reformular consultas, dividir preguntas, consultar varias fuentes, revisar resultados y decidir si necesita buscar de nuevo. Añade flexibilidad, pero también complejidad, coste y nuevos modos de fallo.
Fuentes y lecturas recomendadas
Las fuentes siguientes sostienen la definición, los mecanismos de recuperación, los límites y la relación de RAG con agentes, fine-tuning, contexto y seguridad.
- 01Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (enlace externo)arxiv.org
Trabajo de 2020 que popularizó el término RAG y la combinación de memoria paramétrica con recuperación externa.
- 02IBM — ¿Qué es la generación aumentada por recuperación? (enlace externo)ibm.com
Explica los componentes fundamentales de RAG, recuperación, conocimiento externo y generación.
- 03AWS — ¿Qué es RAG? (enlace externo)aws.amazon.com
Introduce acceso a conocimiento externo, fuentes, búsqueda y actualización sin reentrenar el modelo para cada cambio.
- 04Microsoft Azure AI Search — RAG overview (enlace externo)learn.microsoft.com
Detalla retos de producción y diferencia RAG clásico de recuperación agéntica.
- 05Microsoft Foundry — Retrieval-Augmented Generation and indexes (enlace externo)learn.microsoft.com
Cubre búsqueda por palabras clave, semántica, vectorial e híbrida y la relación con fine-tuning y agentes.
- 06Google Cloud — Retrieval-Augmented Generation (enlace externo)cloud.google.com
Explica RAG, búsqueda vectorial y la relación entre recuperación selectiva y contextos amplios.
- 07Anthropic — Contextual Retrieval (enlace externo)anthropic.com
Analiza pérdida de contexto durante la fragmentación, búsqueda por embeddings y BM25, recuperación híbrida y reranking.
- 08OWASP — Prompt Injection y RAG Security Cheat Sheet (enlace externo)owasp.org
Documenta riesgos de inyección indirecta, permisos, poisoning y tratamiento de contenido recuperado.
Sobre el autor
Elvis Mendoza, fundador de Agentes Como Servicio. Trabaja en el diseño de producto, la arquitectura de soluciones, el diseño de agentes y flujos de trabajo y la construcción de software asistida por IA para conectar procesos, datos, herramientas y supervisión humana alrededor de necesidades empresariales concretas.
¿Tu IA necesita trabajar con conocimiento de tu empresa?
Antes de elegir una base vectorial, un framework o un agente, conviene definir qué fuentes son válidas, quién puede acceder a ellas, cómo se actualizan, cómo se recuperará la evidencia y qué debe hacer el sistema cuando esa evidencia no es suficiente.
En Agentes Como Servicio diseñamos estas arquitecturas alrededor del proceso real: conocimiento recuperable donde hace falta, permisos desde el principio y comportamiento agéntico solo cuando el trabajo necesita decisiones dinámicas.
Solicitar acceso