Si has creado un sistema RAG clásico, conoces sus fortalezas: recupera fragmentos pertinentes, el LLM genera respuestas fundamentadas, el rendimiento es razonable y los costes son predecibles. Esto basta para la mayoría de las consultas sobre una base de conocimiento.
Pero algunas consultas exceden sus capacidades. Las preguntas de varios saltos —«¿qué clientes utilizan la funcionalidad X y han abandonado durante los últimos 6 meses?»—, las centradas en relaciones —«¿cómo se compara nuestro precio con el de los competidores A, B y C?»— y las de síntesis —«resume todo lo que sabemos sobre la trayectoria de este cliente»— exigen combinar información dispersa. La recuperación por fragmentos no realiza bien esa composición y el LLM termina perdiendo contexto.
Los enfoques «más allá de los fragmentos» —Graph RAG, RAG con agentes y RAG de contexto largo— abordan estos límites de formas diferentes. Este artículo explica qué aporta cada uno, cuándo resulta adecuado, cómo funciona en producción y qué compromisos conlleva.
Las limitaciones del RAG basado en fragmentos
Para entender qué estamos arreglando, las limitaciones:
Límite 1: No hay estructura de relaciones. Los fragmentos son unidades independientes. El hecho de que el fragmento A sea sobre la cuenta del cliente X y el fragmento B sea sobre una queja que el cliente X hizo se pierde — son simplemente dos fragmentos en un espacio vectorial, recuperados (o no) de forma independiente.
Límite 2: No hay razonamiento de varios saltos. «Clientes que utilizan la funcionalidad X y se quejaron de Y» requiere combinar dos fuentes mediante lógica de conjuntos. La recuperación por fragmentos no lo hace.
Límite 3: Síntesis limitada. “Resuma la relación de esta cuenta a lo largo del tiempo” necesita juntar muchos fragmentos en una narrativa coherente. Los fragmentos se presentan como fragmentos; el modelo de lenguaje de gran tamaño tiene que hacer la síntesis desde cero cada vez.
Límite 4: Rigidez del pipeline fijo. El RAG clásico siempre hace lo mismo: generar el embedding de la consulta → recuperar K → generar. Las consultas complejas que requieren recuperación iterativa o razonamiento de varios pasos no encajan.
Límite 5: Dilución del contexto. Los 5 primeros fragmentos podrían incluir algunos que coinciden con la consulta pero son off-topic. El modelo de lenguaje de gran tamaño se ve obligado a navegar entre ellos; la calidad sufre.
Cada variante que discutiremos aborda subconjuntos de estos límites.
Graph RAG
La idea consiste en representar los datos como un grafo de conocimiento. Las entidades —personas, productos, documentos o eventos— son nodos y sus relaciones son aristas. Las consultas recorren el grafo en lugar de, o además de, realizar una búsqueda vectorial.
Cuándo ayuda Graph RAG
Dominios con enfoque en relaciones. Estructuras de cuenta de cliente-contrato-interacción. Jerarquías de organización. Taxonomías de productos. Redes de citas. Cualquier cosa donde las conexiones entre entidades importan tanto como las entidades mismas.
Razonamiento de varios saltos. «¿Quién dirige el equipo que compró el producto X en el trimestre 3?» exige recorrer producto → contrato → equipo → responsable. Graph RAG gestiona este recorrido de forma natural.
Agregación. “¿Cuántos clientes en el segmento Y han integrado con el sistema Z?” requiere operaciones de conjunto entre entidades. SQL sobre un gráfico de conocimiento supera la recuperación de texto.
Citas y explicaciones. Las relaciones del gráfico son explícitas y auditables. El modelo de lenguaje de gran tamaño puede citar “John es el gerente del equipo Acme [arista: gestiona]” en lugar de “Creo que John gestiona el equipo Acme basado en el contexto.”
Cómo funciona realmente Graph RAG
El pipeline típico:
1. Extracción. Construye el gráfico desde tus datos. Dos enfoques comunes:
- Fuentes estructuradas (bases de datos, APIs estructuradas): importa directamente. Los clientes, productos y transacciones ya están en tablas.
- Fuentes no estructuradas (documentos, transcripciones, correos electrónicos): usa un modelo de lenguaje de gran tamaño para extraer entidades y relaciones. “Desde esta transcripción, extrae personas, organizaciones y las relaciones entre ellas.”
La salida: nodos (con tipos y propiedades) y aristas (con tipos y propiedades).
2. Almacenamiento. Una base de datos de gráficos — Neo4j, Memgraph, Postgres personalizado con tablas de aristas. La elección depende de los patrones de consulta y la escala.
3. Enriquecimiento con embeddings. Cada nodo recibe también una representación textual y un embedding. Esto permite un enfoque híbrido: recorrer el grafo y realizar búsqueda semántica.
4. Consulta en tiempo de recuperación. Tres patrones comunes:
- Consulta solo en gráfico. El modelo de lenguaje de gran tamaño (o una lógica de enrutamiento) genera una consulta de gráfico (Cypher, SQL). Ejecuta. Devuelve resultados al modelo de lenguaje de gran tamaño.
- Primero embeddings y después expansión en el grafo. Encuentra entidades pertinentes mediante embeddings y amplía después a sus vecinos y relaciones.
- Híbrido. Combina búsqueda vectorial + recorrido en gráfico en un solo pipeline.
5. Formato para el modelo de lenguaje de gran tamaño. Los resultados del gráfico se formatean como texto estructurado que el modelo de lenguaje de gran tamaño puede usar. Entidades con sus propiedades; relaciones explícitas.
Un ejemplo concreto
Una empresa SaaS con datos de clientes. Entidades: clientes, contratos, productos, tickets de soporte, interacciones, empleados.
Enfoque clásico de RAG: fragmentar documentos de clientes, incrustar, recuperar. Pierde la estructura relacional.
Enfoque de Graph RAG:
- Nodos: cliente, contrato, producto, ticket, interacción, empleado.
- Aristas: cliente→tiene→contrato, cliente→suscripto_a→producto, cliente→enviado→ticket, ticket→asignado_a→empleado, contrato→vendido_por→empleado.
Consulta: «¿Qué clientes del nivel SaaS tuvieron más de 3 tickets de soporte en Q1 y deben renovar en Q2?»
Esto es naturalmente una consulta de gráfico:
MATCH (c:Customer)-[:HAS]->(contract:Contract)
WHERE contract.tier = "SaaS"
AND contract.renewal_date BETWEEN "2026-04-01" AND "2026-06-30"
MATCH (c)-[:SUBMITTED]->(t:Ticket)
WHERE t.created BETWEEN "2026-01-01" AND "2026-03-31"
WITH c, count(t) as ticket_count
WHERE ticket_count > 3
RETURN c, ticket_count
El modelo de lenguaje de gran tamaño genera esta consulta (o selecciona de consultas predefinidas). Ejecuta. Formatea los resultados. Genera la respuesta.
El RAG clásico no puede responder fácilmente; Graph RAG lo resuelve de forma directa.
Compromisos
Ventajas:
- Maneja consultas relacionales naturalmente.
- Estructura explícita y auditada.
- Se combina con embeddings.
Desventajas:
- Construir el gráfico es un trabajo real de ingeniería. Especialmente para fuentes no estructuradas, la extracción es imperfecta.
- El diseño del esquema importa; esquemas malos te limitan.
- Mantenimiento: a medida que los datos evolucionan, el gráfico evoluciona.
- Herramientas menos maduras que la búsqueda vectorial.
Cuándo elegir:
Elige Graph RAG cuando las relaciones sean un elemento central del dominio. No lo adoptes solo porque parezca sofisticado: en muchos conjuntos documentales, el RAG clásico es más sencillo y ofrece la misma calidad.
GraphRAG de Microsoft y trabajos relacionados
El proyecto de código abierto GraphRAG de Microsoft (2024) popularizó un enfoque específico:
- Extraer entidades y relaciones de documentos (basado en LLM).
- Agrupar entidades en comunidades.
- Generar resúmenes por comunidad en múltiples niveles jerárquicos.
- En tiempo de consulta: recuperar resúmenes de comunidades relevantes; usarlos como contexto.
Funciona bien para preguntas “globales” que abarcan un corpus (por ejemplo, “¿cuáles son los temas principales en la historia de quejas de este cliente?”) en lugar de búsquedas específicas.
Variantes incluyen LightRAG, Graphiti y otras — cada una con elecciones arquitectónicas específicas.
RAG con agentes
La idea es sustituir el pipeline fijo de recuperar y después generar por un agente de IA que decida qué recuperar, cuándo hacerlo y cómo refinar la búsqueda. Puede lanzar consultas adicionales, examinar los resultados, determinar que no bastan y probar otros enfoques.
Cuándo ayuda el RAG con agentes
Consultas complejas que necesitan iteración. «Ayúdame a entender por qué aumentó nuestro abandono en Q1» exige examinar varias dimensiones —segmento, periodo, funcionalidades y competidores—. Un agente puede explorarlas de forma iterativa.
Consultas donde una recuperación no es suficiente. Si la respuesta requiere combinar información de múltiples recuperaciones distintas, un agente maneja esto naturalmente.
Consultas con lógica condicional. “Si X es verdadero según la recuperación 1, luego busca Y; de lo contrario busca Z.” Los agentes manejan ramificaciones; los pipelines fijos no.
Consultas ambiguas. El agente puede preguntar al usuario (o a los datos) para aclarar.
Cómo funciona el RAG con agentes
El pipeline:
User query
↓
Agent reasons about what it needs
↓
Agent calls retrieval tools (one or many)
↓
Agent reads results
↓
Agent decides: enough info? Or another retrieval?
↓
Loop until done
↓
Generate final answer
La implementación implica:
Recuperación como herramientas. Exponer funciones de recuperación al agente: search_documents(query), lookup_by_id(id), aggregate(field, filter). El agente las llama según sea necesario.
Memoria. El agente recuerda lo que ha recuperado en llamadas anteriores. Evita recuperar el mismo contenido de nuevo.
Toma de decisiones. El agente razona explícitamente sobre si tiene suficiente información. “¿Sé la respuesta a la pregunta del usuario? Si no, ¿qué más necesito recuperar?”
Terminación. El agente debe saber cuándo detenerse. Un presupuesto máximo de pasos. Un umbral de confianza. Una condición “he respondido”.
Un ejemplo concreto
Consulta: «¿Cuáles fueron las tres principales preocupaciones de los clientes en Q1? Incluye ejemplos».
Enfoque clásico de RAG: recuperar algunos fragmentos de comentarios de clientes, esperar que cubran el tema.
Enfoque de RAG con agentes:
Agent: I need to find Q1 customer concerns. Let me start by searching for customer complaints in that period.
> Tool: search_documents(query="customer complaints Q1 2026", filter={date_range: "Q1 2026"})
Agent: I got 25 results. Let me see what topics they cover.
> [reads results]
Agent: I see three main themes: pricing, slow support, and missing integrations. Let me get specific examples for each.
> Tool: search_documents(query="customer pricing complaints", filter={...})
> Tool: search_documents(query="customer support speed complaints", filter={...})
> Tool: search_documents(query="customer integration missing complaints", filter={...})
Agent: Now I have 3-5 specific examples per theme. Let me compile the answer.
Varias recuperaciones, refinadas iterativamente. El agente decide la estructura según lo que encuentra.
Compromisos
Ventajas:
- Maneja consultas complejas de múltiples pasos.
- Se adapta a la complejidad de la consulta (consultas simples no activan ejecuciones largas del agente).
- Puede aclarar ambigüedades preguntando.
Desventajas:
- Latencia más alta (múltiples recuperaciones).
- Costo más alto (múltiples llamadas al LLM).
- La fiabilidad del agente importa; agentes malos buclean o se rinden.
- Más difícil de evaluar (camino de ejecución más variado).
- Más difícil de controlar (el agente podría hacer cosas inesperadas).
Cuándo elegir:
Elige RAG con agentes cuando la complejidad de las consultas varíe mucho. Las sencillas pueden seguir una ruta rápida y las complejas activar el agente. Si todas son simples, el coste adicional no compensa.
Patrones del RAG con agentes
Algunos patrones comunes:
Patrón 1: ReAct (Razonar + Actuar). El agente razona explícitamente, luego actúa (recupera), luego observa, luego razona de nuevo. Se repite hasta terminar.
Patrón 2: Plan y ejecutar. El agente crea primero un plan de múltiples pasos (¿qué recuperar en qué orden), luego ejecuta el plan, posiblemente ajustándolo.
Patrón 3: Autocrítica. Después de la recuperación, el agente evalúa si la información recuperada es suficiente. Si no, refina la consulta y recupera de nuevo.
Patrón 4: Agente con muchas herramientas. El agente tiene muchas herramientas de recuperación (búsqueda de texto completo, consulta SQL, consulta de gráfico, llamadas a API) y elige entre ellas.
Diferentes patrones se adaptan a diferentes casos de uso. El agente con muchas herramientas funciona para fuentes de datos heterogéneas; ReAct funciona para consultas exploratorias; plan y ejecutar funciona cuando la estructura de una consulta compleja se puede planificar con anticipación.
RAG de contexto largo
La idea: con ventanas de contexto de 1M+ tokens (Gemini, GPT-5), ¿por qué recuperar fragmentos? Basta con incluir todo el corpus en el contexto.
Cuándo ayuda el RAG de contexto largo
Corpus pequeños. Un corpus de 100K tokens se ajusta fácilmente en una ventana de 1M tokens. No se necesita infraestructura de recuperación.
Comprensión de documentos completos. “Resuma este documento completo de 500 páginas.” Un modelo con contexto prolongado maneja esto directamente.
Consultas de documentos cruzados en conjuntos pequeños. “Compare estos 10 contratos.” Es más fácil colocarlos todos en el contexto que recuperar cuidadosamente.
Prototipado. El contexto prolongado es el camino más simple hacia un sistema funcional. Construye el prototipo con contexto prolongado; optimiza con recuperación más tarde si es necesario.
Cómo funciona el RAG de contexto largo
El pipeline es trivial:
[corpus, possibly 100K-1M tokens]
↓
+ [user query]
↓
LLM call
↓
[answer]
Sin almacén vectorial, fragmentación ni reranking.
En la práctica, aún podrías hacer una recuperación ligera para ajustar el corpus en el contexto (por ejemplo, para un corpus de 5M tokens, recupera un subconjunto de 500K tokens). Pero la recuperación es gruesa — el LLM hace el trabajo detallado de “encontrar las partes relevantes”.
El problema de la «degradación del contexto»
Una realidad de 2025-2026 es que los modelos de contexto largo no aprovechan bien las ventanas extensas.
Empíricamente:
- La calidad es más alta con aproximadamente 5-50K tokens de contexto — el patrón de atención posicional detrás de esto se documenta en Liu et al.’s “Lost in the Middle” y evaluaciones de contexto prolongado posteriores.
- La calidad disminuye notablemente a 100K+ tokens.
- A 500K+ tokens, a menudo se pierde o se aplica mal información importante.
Los modelos pueden procesar técnicamente contextos largos, pero las pruebas de «aguja en un pajar» exageran su rendimiento. En casos reales, la calidad se degrada.
Esto significa que el RAG de contexto largo funciona de forma fiable para corpus de hasta ~50K tokens. A partir de ahí, rinde peor que un buen sistema de recuperación.
Compromisos
Ventajas:
- Arquitectura más simple posible.
- No hay pipeline de recuperación que mantener.
- Mejor para tareas de comprensión de todo el corpus.
Desventajas:
- Degradación de calidad en tamaños grandes de contexto.
- Alto coste por consulta (pagas por todo el contexto cada vez).
- Alta latencia (contexto grande = respuesta más lenta).
- No escala más allá de corpora que se ajustan confiablemente.
Cuándo elegir:
Corpus pequeños (menos de 50K tokens). Análisis puntuales. Prototipos. NO para recuperación general de grandes bases de conocimiento.
Híbrido: recuperación + contexto prolongado
Un patrón común: recuperar un contexto más grande (50-200K tokens de contenido relevante) que el RAG clásico, pero más pequeño que el corpus completo. El LLM recibe suficiente contexto para manejar la consulta bien sin rotación del contexto.
Implementación: recuperar los 50 primeros fragmentos (en lugar de los 5 primeros), incluirlos todos, dejar que el LLM los revise.
Funciona bien cuando:
- Las consultas necesitan contexto amplio.
- Los modelos manejan bien contextos medianos (50-200K).
- El coste es aceptable.
Un punto dulce de 2026: recuperar agresivamente (50-100 fragmentos), incluirlos todos, dejar que el LLM use las partes relevantes. Intercambia coste por simplicidad y calidad.
Elegir la variante adecuada
Un marco de decisión:
Usa RAG clásico basado en fragmentos cuando:
- Los documentos son los datos principales.
- Las consultas son principalmente de recuperación.
- El volumen y el coste importan (más barato por consulta).
- Necesitas latencia predecible.
Usa Graph RAG cuando:
- Los datos tienen una estructura rica de entidades-relaciones.
- Las consultas implican razonamiento de varios saltos, operaciones de conjunto o agregación.
- Puedes invertir en construcción y mantenimiento del gráfico.
Usa RAG con agentes cuando:
- La complejidad de la consulta varía ampliamente.
- Algunas consultas necesitan exploración iterativa.
- Estás dispuesto a pagar mayor latencia/coste para consultas difíciles.
- Tienes observabilidad para depurar ejecuciones del agente.
Usa RAG de contexto largo cuando:
- El corpus es pequeño (menos de 50K tokens).
- Quieres la arquitectura más simple.
- Análisis puntuales o prototipos.
Combina cuando:
- La mayoría de los sistemas reales lo hacen.
- RAG clásico + Graph RAG para consultas relacionales.
- RAG clásico + agentes para consultas complejas.
- RAG clásico con recuperación más amplia (contexto medio) para casos límite.
La respuesta madura en 2026 es «todo lo anterior, aplicado según la consulta». Un enrutador elige la variante conforme a sus características.
Realidades de producción
Algunas observaciones de implementaciones reales:
La complejidad se compone. Cada variante añade complejidad. Un sistema que usa las cuatro es un esfuerzo de ingeniería significativo. Comienza con clásico; añade variantes solo cuando toques límites claros.
La evaluación es más difícil. Con múltiples caminos de recuperación, la evaluación debe cubrirlos todos. El conjunto de pruebas debe incluir consultas que ejerzan cada camino.
Los costes varían mucho. Graph RAG puede ser barato —una consulta de base de datos—. El RAG de contexto largo es caro. El RAG con agentes depende de la complejidad. Registra el coste de cada consulta.
La latencia varía de forma similar. Una respuesta de un RAG con agentes que tarda 30 segundos puede ser aceptable en ciertos casos y no en otros. Elige la variante conforme al contexto de UX.
Carga de mantenimiento. Los esquemas de grafos derivan, los prompts de agentes necesitan ajustes y los modelos de embeddings se actualizan. Cada variante conlleva su propio coste de mantenimiento.
El 80/20. El RAG clásico maneja adecuadamente el 80% de las consultas. Las variantes más allá de los fragmentos manejan el 20% difícil que el clásico no maneja bien. No reemplazar; ampliar.
Una arquitectura combinada
Una arquitectura práctica que usa múltiples variantes:
Query
↓
Router (classify the query)
├→ "Lookup" → Classic RAG (cheap, fast)
├→ "Relational" → Graph RAG
├→ "Complex / open-ended" → Agentic RAG
└→ "Whole-corpus / small corpus" → Long-context
Each variant produces an answer.
Observability tracks which path was used.
Eval suites cover all paths.
Esto es más complejo que cualquier variante individual pero maneja bien el rango completo de consultas. Para sistemas maduros con tipos de consulta diversos, esta es la arquitectura eventual.
Una implementación práctica
Si estás empezando desde un RAG clásico funcional y quieres expandir:
Añade primero el contexto largo. Exige menos esfuerzo de ingeniería, resulta útil para consultas concretas y suele aportar mejoras inmediatas.
Añade un agente para las consultas complejas. Identifica aquellas con las que el RAG clásico tiene dificultades, crea un agente que las gestione y enrútalas de forma condicional.
Añade Graph RAG al final. Es la opción con mayor coste de ingeniería y solo compensa si existen patrones claros de consultas relacionales.
Este orden coincide típicamente con el ROI. Contexto prolongado: bajo coste, valor real. Agente: coste moderado, aborda brechas reales. Gráfico: alto coste, casos de uso específicos.
Amplía, no reemplaza
El RAG clásico basado en fragmentos es la base de trabajo, pero tiene límites. Las variantes «más allá de los fragmentos» —Graph RAG, RAG con agentes y RAG de contexto largo— aportan capacidades diferentes.
El camino no consiste en sustituir el RAG clásico, sino en ampliarlo. Los sistemas maduros enrutan las consultas hacia distintas variantes según las capacidades de cada una.
La inversión es significativa — cada variante es un trabajo real de ingeniería. Pero para sistemas donde el RAG clásico se estanca, las ganancias en capacidad son reales. Un sistema que maneja bien solo consultas de “búsqueda” es mucho menos útil que uno que maneja también consultas relacionales, complejas y de todo el corpus.
Mapea tus consultas. Identifica las que el RAG clásico maneja mal. Elige la variante que se ajuste. Construye la ampliación. Itera.
Así evolucionan los sistemas RAG: de ser útiles para algunas consultas a responder con solvencia a la diversidad de preguntas reales.
