Graph RAG: cómo dejar de tratar tus datos como islas y empezar a razonar sobre relaciones

Si alguna vez has intentado que un LLM responda preguntas sobre tu documentación, tus PDFs internos o tu base de datos, te has topado con la misma pared: el modelo no sabe nada que no estuviera en su entrenamiento, y su conocimiento tiene fecha de caducidad. RAG — Retrieval-Augmented Generation — es la técnica estándar de la industria para resolver esto. Y aunque el concepto es simple, las implementaciones robustas tienen más miga de lo que parece.

El problema base

Un LLM es, en esencia, un completador de texto muy bueno. Le das un prompt, te lo completa. Pero tiene tres problemas serios para uso empresarial:

• Conocimiento estático: lo que aprendió en el preentrenamiento, punto. No sabe nada posterior.
• Alucinaciones: cuando no sabe, inventa con una convicción alarmante.
• Sin fuentes: no puede decirte "esto lo saqué de aquí", porque no tiene concepto de fuente.

RAG ataca los tres problemas. La idea: en vez de pedirle al modelo que responda solo con lo que tiene en la cabeza, le das un contexto relevante extraído de tus datos, y le dices "responde basándote en esto".

Cómo funciona un RAG básico

El flujo en su forma más simple tiene tres pasos:

1. Indexación (offline)

Tus documentos se trocean en fragmentos (chunks) de unos 500-1000 tokens. Cada chunk se convierte en un vector (un embedding) usando un modelo de embeddings. Esos vectores se guardan en una base de datos vectorial (Pinecone, Weaviate, Qdrant, Milvus, Chroma...). Cuando un usuario hace una pregunta, el sistema busca los chunks cuyos vectores son más similares a la pregunta.

2. Recuperación (online)

El usuario pregunta. La pregunta se vectoriza con el mismo modelo. Se buscan los K chunks más similares (top-K, típicamente 3-10). Se concatenan al prompt del modelo junto con la pregunta original.

3. Generación

El LLM recibe: "Aquí tienes contexto. Responde a esta pregunta basándote solo en el contexto. Si no encuentras la respuesta, di que no la sabes." Y genera la respuesta, esta vez fundamentada en tus datos.

Lo que se rompe en producción

El flujo básico funciona en demos. En producción, cinco cosas se rompen sistemáticamente:

1. Chunks mal cortados

Si cortas por número de tokens sin respetar la estructura, metes ruido. Mejor: cortar por secciones semánticas (párrafos, headings) o usar semantic chunking.

2. Búsqueda semántica sola no basta

A veces la pregunta no es semánticamente similar al chunk correcto. Si el usuario busca "error 500 en el endpoint de login", y la documentación dice "internal server error en /api/auth/login", un embedding no los va a emparejar bien. Solución: búsqueda híbrida (semántica + BM25 keyword-based).

3. Contexto demasiado largo

Si metes 20 chunks en el prompt, el modelo se distrae, pierde el foco, y la respuesta se degrada. Re-ranking (usar un modelo cross-encoder para reordenar los candidatos por relevancia real) ayuda. También ayuda reducir top-K y usar compresión de contexto.

4. El modelo ignora el contexto

Por raro que parezca, los LLMs a veces ignoran el contexto que les pasas y responden basándose en su preentrenamiento. El prompt tiene que ser explícito: "Responde SOLO con información del siguiente contexto. Si no la encuentras, di 'no tengo información sobre esto'". Y aún así, hay que vigilarlo.

5. Alucinaciones sobre el contexto

El modelo puede usar el contexto pero añadir cosas que no están en él. La solución es pedirle que cite las fuentes y verificar las citas en una segunda pasada.

Graph RAG: cuando los datos están relacionados

El RAG clásico trata cada chunk como una unidad independiente. Pero la mayoría de datos empresariales no son así: están relacionados. Una persona trabaja en un proyecto, que pertenece a un cliente, que tiene un contrato, que vence en una fecha.

Graph RAG (popularizado por Microsoft Research) construye un grafo de entidades y relaciones, y la búsqueda recorre el grafo además de los vectores. Las preguntas multi-hop ("¿qué proyectos tienen Fernando y María?") se vuelven posibles.

El trade-off: Graph RAG es más potente pero más complejo de mantener. La indexación es más cara (hay que extraer entidades y relaciones con un LLM) y las queries son más lentas. Úsalo cuando la estructura de los datos lo justifique.

Evaluación: la pieza que casi nadie hace

El mayor error con RAG es desplegar sin medir. Necesitas un set de evaluación con preguntas y respuestas esperadas, y medir: ¿el sistema recupera los chunks correctos? ¿la respuesta final es fiel al contexto? ¿responde lo que el usuario quería?

Herramientas como RAGAS, DeepEval o Phoenix de Arize automatizan esto. Sin métricas, estás volando a ciegas.

Lo que está pasando en 2026

El estado del arte de RAG se está moviendo en varias direcciones:

• Long-context RAG: con modelos que aceptan 1M+ tokens, algunos equipos están metiendo documentos enteros en el prompt y saltándose la recuperación. Funciona para documentos medianos, no para bases de conocimiento grandes.
• Agentic RAG: en vez de un retrieve→generate lineal, un agente decide dinámicamente qué buscar, dónde, y cuántas veces.
• Multimodal RAG: recuperación de imágenes, tablas, gráficos. Ya no son solo textos.
• Self-RAG: el modelo marca sus propios chunks con tokens especiales indicando relevancia, soporte, y utilidad. El sistema usa esos tokens para filtrar y re-rankear.

RAG no va a desaparecer aunque los modelos tengan más contexto. Para knowledge bases grandes, para datos que cambian, para casos donde necesitas citar fuentes, sigue siendo la forma más práctica y barata de anclar un LLM a tus datos.

Si quieres implementarlo, empieza por: <em>llama-index o LangChain para el framework, Chroma o Qdrant para la vector store local, y un modelo de embeddings decente (BGE, Nomic Embed, o los de OpenAI). El primer RAG funcional lo puedes tener en una tarde.