RAG se convirtió en la respuesta automática para todo. "¿Cómo hago que la IA sepa sobre mis datos?" — "¡RAG!". "¿Cómo reduzco la alucinación?" — "¡RAG!". Y la mayoría de las veces está bien — pero RAG también es una de las cosas más mal usadas del momento, lanzada a problemas que no la piden. Este post es la guía honesta: qué es RAG realmente, cuándo resuelve, y cuándo estás construyendo infraestructura cara para nada.
Qué es RAG, sin el hype
Un modelo de lenguaje sabe lo que estaba en los datos de entrenamiento y nada más. No conoce tus documentos internos, tu catálogo, la política de tu empresa. Y su contexto es limitado — no puedes simplemente pegar 10 mil páginas en la conversación.
RAG (Retrieval-Augmented Generation) resuelve esto buscando, en el momento de la pregunta, los pedazos de información relevantes e inyectándolos en el contexto del modelo. El flujo:
- Divides tu base de conocimiento en pedazos (chunks) y generas embeddings — representaciones numéricas del significado de cada pedazo.
- Guardas esos vectores en una base de datos vectorial.
- Cuando llega una pregunta, la conviertes en vector y buscas los pedazos más semánticamente cercanos.
- Inyectas esos pedazos en el prompt y el modelo responde con base en ellos.
El resultado: el LLM responde sobre tus datos, actualizados, citando la fuente — sin inventar. Es "darle al modelo el machete correcto antes del examen".
Cuándo RAG resuelve de verdad
RAG brilla cuando tienes mucho conocimiento externo, que cambia, y que el modelo necesita consultar:
- Base de conocimiento / soporte: cientos de artículos, manuales, FAQs. El agente busca el fragmento correcto y responde con precisión.
- Documentos que cambian: políticas, catálogos, precios. Como RAG no entrena nada, actualizas el documento y la respuesta cambia al instante.
- Conocimiento privado: datos de tu empresa que nunca estuvieron en ningún entrenamiento.
- Necesidad de citar la fuente: RAG sabe de dónde sacó la respuesta, lo que da trazabilidad.
Si tu problema es "la IA necesita responder con base en muchos documentos míos que cambian", RAG es la herramienta.
Cuándo NO usar RAG (la parte que nadie cuenta)
Aquí está el contrapunto que ahorra meses de trabajo innecesario:
Si la información cabe en el contexto, no necesitas RAG. Los modelos modernos tienen ventanas de contexto enormes. Si tu conocimiento es un documento de 20 páginas, ponlo en el prompt y listo. RAG para eso es matar moscas a cañonazos.
Si la respuesta viene de un sistema, usa function calling, no RAG. "¿Cuál es el estado de mi pedido?" no es una pregunta de búsqueda semántica — es una consulta a una base de datos. La herramienta correcta es function calling: el agente llama a buscar_pedido(id) y obtiene el dato exacto. RAG buscaría "documentos parecidos a la pregunta", lo cual es incorrecto para datos estructurados.
Si no tienes muchos documentos, RAG es over-engineering. Embeddings, base de datos vectorial, pipeline de ingesta, reindexación — es infraestructura de verdad. Solo vale la pena cuando el volumen lo justifica.
La pregunta filtro: ¿mi respuesta depende de buscar significado en muchos textos, o de consultar un dato específico? Si es buscar en textos, RAG. Si es consultar un dato, function calling.
Los detalles que deciden si tu RAG funciona
Un RAG mal hecho es peor que no tener RAG — trae el pedazo equivocado con confianza. Lo que separa a un RAG que funciona:
- Chunking inteligente. Cómo divides los documentos importa más de lo que parece. Chunks demasiado grandes diluyen la relevancia; demasiado pequeños pierden el contexto. Respeta la estructura del documento (secciones, párrafos).
- Calidad del embedding. El modelo de embedding define qué significa "similar". Un buen modelo de embedding es la mitad de la batalla.
- Recuperar lo suficiente, no el máximo. Inyectar 50 chunks atasca el contexto y confunde al modelo. Recupera los pocos más relevantes.
- Reranking. Una segunda pasada que reordena los resultados por relevancia real mejora mucho la precisión.
- Evaluar. Si no mides si el RAG está trayendo los fragmentos correctos, no sabes si funciona. Mídelo.
La visión de producto
RAG no es un objetivo — es un medio, como toda tecnología de IA. El error que más veo es equipos construyendo un pipeline de RAG elaborado antes de preguntarse si el problema lo pide. Muchas veces, lo que resuelve es function calling a un sistema, o simplemente poner el documento en el contexto. RAG entra cuando el conocimiento es grande, textual y mutable — y ahí sí es poderoso.
Como siempre: la pregunta correcta no es "¿qué técnica de IA de moda voy a usar?". Es "¿cuál es el problema, y cuál es la herramienta más simple que lo resuelve?". A veces es RAG. Muchas veces no lo es. Saber la diferencia es lo que separa a quien entrega de quien solo sigue el hype.
Construyo sistemas de IA que resuelven el problema correcto con la herramienta correcta — RAG, agentes, integración — en producción. Si estás en duda de si necesitas RAG, hablemos.