¿Qué es RAG y qué problema resuelve?

El problema que probablemente ya tuviste

Imaginate esto: armás un chatbot con un LLM bueno, lo conectás a tu empresa, y le hacés una pregunta sobre tu producto interno. ¿Qué te contesta?

Una de tres cosas, casi siempre:

Te dice que no sabe.
Inventa una respuesta que suena bien pero está mal.
Te tira info vieja, de cuando se entrenó el modelo, no de cuando vos preguntás.

Y vos pensás: “pero si el LLM es enorme, ¿cómo no sabe esto?”. La respuesta es simple: el modelo no sabe lo que pasa adentro de tu empresa. No leyó tus docs internos, no vio tus tickets de soporte, no tiene los PDFs de tus clientes.

Bien. Bienvenido al problema que resuelve RAG.

La idea de RAG en una frase

RAG significa Retrieval-Augmented Generation. Y la idea es así de simple: en lugar de re-entrenar el modelo cada vez que cambia tu información, le traés el contexto relevante en el momento de la pregunta.

Antes de generar la respuesta, el sistema:

Busca en TU base de conocimiento los fragmentos más relevantes a la pregunta.
Se los pasa al LLM como contexto.
Le pide que responda basándose en eso.

Resultado: el LLM contesta con tu información, citando tus fuentes, sin alucinar (o al menos, alucinando mucho menos).

¿Y por qué no fine-tuning?

Buena pregunta. Y te la voy a anticipar porque la vas a tener.

Fine-tuning está bueno, pero tiene tres problemas serios para este caso:

Es caro. Cada vez que cambia tu contenido, re-entrenás. ¿Vas a re-entrenar cada vez que un cliente actualiza un PDF? No.
Es lento. De minutos a horas, dependiendo del modelo.
No es citeable. El modelo “absorbe” la info, pero después no te puede decir “esto lo saqué del documento X, página 4”.

RAG resuelve los tres. Actualizás contenido en segundos (re-indexás), citás fuentes naturalmente, y no tocás el modelo.

Lo que viene

Ahora que entendés el qué y el por qué, vamos a ver el cómo. En la próxima página te muestro la anatomía de un pipeline RAG: los 4 stages que todo sistema RAG ejecuta, sin excepciones.