Qué es RAG: cómo un agente de IA "sabe" cosas que nunca aprendió

Le preguntas a un agente de IA sobre la política de devoluciones de tu propia empresa. Te responde rápido, seguro, con detalles específicos — plazos, excepciones, hasta un número de artículo del reglamento interno.

Ningún dato de eso existe. Lo inventó completo, con la misma confianza con la que te habría dado un dato real.

El modelo no está mintiendo a propósito. Simplemente nunca vio tu política de devoluciones — su conocimiento se cerró en una fecha de entrenamiento, mucho antes de que tú escribieras ese documento. Y cuando un modelo no sabe algo, por defecto no dice "no sé": improvisa. A resolver justo este problema —darle a un agente acceso a información que nunca aprendió, sin tener que reentrenarlo— se le llama RAG.

Qué es, en una frase

RAG (Retrieval-Augmented Generation, "generación aumentada por recuperación") es la técnica que hace que un modelo, antes de responder, busque información relevante en una fuente externa —documentos, una base de datos, tu código— y genere la respuesta apoyándose en lo que encontró, en vez de confiar solo en lo que memorizó durante su entrenamiento.

Busca primero. Responde después. Ese orden es todo el truco.

El chisme: nació en 2020, en un paper que resolvía cuatro problemas a la vez

El término lo acuñó un equipo de Facebook AI Research en 2020, en un paper que combinaba dos ideas: un modelo que sabe buscar información (entrenado sobre millones de fragmentos de Wikipedia) y un modelo que sabe escribir respuestas, trabajando juntos. Antes de eso, un modelo solo tenía lo que traía "de memoria" — el mismo problema que tiene tu agente con la política de devoluciones.

El dato curioso: uno de los autores de ese paper original, Douwe Kiela, hoy dirige una empresa que se dedica exclusivamente a mejorar RAG — llaman a su enfoque "RAG 2.0". El concepto que inventó hace seis años sigue siendo, literalmente, su trabajo de tiempo completo.

La analogía que lo explica todo: examen a libro cerrado vs. examen a libro abierto

Sin RAG, un modelo responde como un estudiante rindiendo un examen de memoria: solo tiene lo que estudió antes, y si no se acuerda de algo, improvisa con la misma seguridad que si lo supiera bien.

Con RAG, el modelo responde como un estudiante con el libro abierto sobre la mesa: antes de contestar, busca la página correcta, la lee, y recién ahí escribe la respuesta. No necesita haber memorizado el libro entero — solo necesita saber encontrar la página que le sirve.

Cómo funciona, en dos fases

Fase 1 — Preparar el libro (se hace una sola vez):

1. Cortar en pedazos. Los documentos se dividen en fragmentos pequeños ("chunks") — buscar dentro de un PDF de 80 páginas como si fuera un solo bloque no sirve de nada.
2. Convertir cada pedazo en un "mapa de significado". Cada chunk se transforma en un embedding — una lista de números que representa de qué trata ese texto, no las palabras exactas. Dos textos que significan cosas parecidas ("montaña" y "cerro") quedan cerca en ese mapa, aunque las palabras sean distintas.
3. Guardar todo en una base de datos vectorial — un tipo de base diseñada para encontrar, entre millones de esos "mapas", cuáles están más cerca del que le pidas.

Fase 2 — Responder una pregunta (pasa cada vez que alguien pregunta algo):

1. La pregunta del usuario también se convierte en un embedding, con el mismo criterio.
2. La base vectorial busca los fragmentos guardados más parecidos a esa pregunta.
3. Esos fragmentos se pegan al prompt, junto con la pregunta original.
4. El modelo genera la respuesta apoyándose en ese material — no en lo que recuerda de su entrenamiento.

Nota que el modelo nunca distingue "esto lo escribió el usuario" de "esto lo trajo la búsqueda" — para él es todo el mismo bloque de texto. Por eso importa tanto qué tan buena sea la búsqueda: si trae basura, el modelo va a construir la respuesta sobre esa basura igual.

RAG vs. fine-tuning: dos formas distintas de dar conocimiento nuevo

Esta es la confusión más común, así que vale la pena la tabla:

	RAG	Fine-tuning
Qué cambia	Lo que el modelo sabe	Cómo el modelo se comporta
Actualizar el conocimiento	Rápido y barato — cambias un documento	Lento y caro — hay que reentrenar
Qué tan fresco está	Tan fresco como tu base de datos, al minuto	Congelado en la fecha del último entrenamiento
Puede citar la fuente	Sí	No — el conocimiento queda difuso en los pesos del modelo
Sirve para	Datos que cambian seguido, información privada o reciente	Cambiar el tono, el estilo, o el formato de respuesta

La mejor respuesta, casi siempre, es combinar los dos: fine-tuning para que el modelo hable con el tono correcto, RAG para que sepa los hechos correctos.

Cómo se conecta con lo que ya viste en esta serie

Si leíste el blog de Context Engineering, ya conocías RAG sin saberlo — es la implementación concreta de una de las cuatro estrategias que vimos ahí:

Concepto ya visto	Cómo se relaciona con RAG
Context Engineering — Select	RAG es la forma principal de "seleccionar" qué información externa entra a la ventana de contexto en cada paso
MCP	Un servidor MCP puede exponer una herramienta de búsqueda que hace RAG por debajo — pero RAG es la técnica, MCP es el protocolo que la conecta al agente
Tool Calling	La búsqueda puede pasar antes de invocar al modelo (RAG clásico) o ser una tool call que el modelo decide hacer solo, en pleno razonamiento (RAG agéntico)

Dicho de otra forma: cuando el blog de MCP mencionaba que "las IAs ya no inventan tantas respuestas" gracias al acceso a datos reales, ese mecanismo tenía nombre — era RAG — y hoy lo cerramos.

El contrapunto que nadie espera: Claude Code dejó de usar RAG

Este dato vale la pena porque desarma la idea de que "RAG siempre es la respuesta correcta".

Cursor sí usa RAG sobre tu código: indexa tu repositorio completo, lo convierte en embeddings y busca los fragmentos relevantes cada vez que le preguntas algo sobre tu proyecto.

Claude Code, en cambio, empezó exactamente igual — con una base vectorial local — y lo abandonó. El creador de la herramienta lo contó así:

"Originalmente probamos versiones muy tempranas de Claude que usaban RAG... y eventualmente terminamos usando agentic search como la forma de hacer las cosas. Rindió mejor. Por mucho. Y esto fue sorprendente."

En vez de tener un índice pre-armado, Claude Code busca en vivo con herramientas normales — algo parecido a grep — cada vez que lo necesita. Las razones que dieron: rindió mejor en sus pruebas, evita que el índice se desactualice cada vez que el código cambia, y evita el riesgo de seguridad de tener un índice completo del código guardado en algún lado.

La lección no es "RAG es malo". Es que RAG es una herramienta con un caso de uso específico — cuando la información es grande, relativamente estable, y no cabe completa en el contexto. Cuando el contenido cambia todo el tiempo y lo que importa es la coincidencia exacta (un nombre de función, un mensaje de error), buscar en vivo puede ganarle.

Cuando RAG sale mal (y por qué)

Cortar los pedazos mal. Un chunk demasiado grande trae ruido de más; uno demasiado chico pierde el contexto necesario para entenderse solo. Cuando un sistema RAG rinde mal, casi nunca es culpa de la búsqueda — es culpa de cómo se cortaron los documentos.

Basura que entra, basura que sale. Si la búsqueda trae fragmentos irrelevantes, el modelo igual está obligado a construir una respuesta con eso. No hay un botón de "esto no me sirve, mejor no respondo" a menos que lo agregues tú mismo.

Perderse en el medio. Cuando metes muchos fragmentos recuperados de una, los modelos tienden a prestar mejor atención a lo que está al principio o al final del contexto — lo que queda en el medio se puede pasar por alto, aunque sea justo lo importante.

Información desactualizada o repetida en la base de conocimiento envenena las respuestas igual que una fuente equivocada.

El caso real que muestra las consecuencias de hacerlo mal

En 2024, un pasajero le preguntó al chatbot de una aerolínea si podía comprar un boleto a precio completo y pedir después el descuento por duelo familiar, dentro de los 90 días siguientes. El chatbot le dijo que sí. La política real de la aerolínea decía lo contrario — el descuento había que pedirlo antes de comprar, no después.

El pasajero llevó el caso a tribunal. La aerolínea argumentó que el chatbot era "una entidad separada", responsable de sus propias respuestas. El tribunal no lo aceptó: la empresa fue condenada a pagar la diferencia de tarifa más intereses y costas. Fue de los primeros casos donde una empresa tuvo que responder legalmente por lo que dijo su propio chatbot.

No sabemos si ese chatbot usaba RAG o no — pero el caso ilustra exactamente el riesgo que RAG bien implementado busca evitar: una respuesta con apariencia de autoridad, construida sobre información que nunca se verificó contra la fuente real.

Antes de decidir si necesitas RAG

# Checklist rápido

- [ ] ¿La información que necesita el agente cambia seguido
      (precios, inventario, políticas)? → RAG tiene sentido.
- [ ] ¿Necesitas que el agente pueda citar de dónde sacó el dato?
      → RAG tiene sentido.
- [ ] ¿Toda tu base de conocimiento cabe cómoda en un solo prompt
      (unas cientas de páginas)? → Puede que ni necesites RAG,
      basta con meterlo todo en el contexto.
- [ ] ¿Lo que necesitas es que el modelo cambie de TONO o FORMATO,
      no que sepa datos nuevos? → Eso es fine-tuning, no RAG.
- [ ] ¿El contenido cambia todo el tiempo y lo que importa es la
      coincidencia exacta (código, logs, nombres técnicos)? →
      considera búsqueda en vivo en vez de un índice pre-armado.

La próxima vez que un agente te responda algo que claramente no estaba en su entrenamiento —tu propia documentación, un dato de esta semana, una fila de tu base de datos— ya sabes exactamente qué pasó antes de que generara esa respuesta: alguien buscó primero.