GraphRAG o RAG vectorial: cómo elegir la estrategia de recuperación según la pregunta
La búsqueda vectorial encuentra texto parecido, pero las preguntas multisalto necesitan relaciones. Cuándo encaja GraphRAG, la búsqueda híbrida o por palabras clave, y cuánto cuesta mantener un grafo.
La primera versión de una aplicación RAG suele parecer refrescantemente sencilla. Se procesa un documento, se parte el texto en chunks, se calcula el embedding de cada uno y se guardan los vectores en una base de datos. Cuando llega una pregunta, se recuperan los chunks más cercanos y se pasan al LLM. Todo el flujo en una imagen:
Documents
│
▼
Text Extraction
│
▼
Chunking
│
▼
Embeddings
│
▼
Vector Database
│
│
User Query ─────────┘
│
▼
Similarity Search
│
▼
Context
│
▼
LLM
│
▼
Answer
Para una gran parte de las preguntas, ese montaje funciona sorprendentemente bien. Pero el trabajo con documentos en una empresa deja ver pronto un segundo tipo de pregunta, en el que encontrar texto semánticamente parecido no basta. La dificultad ya no es «¿puede el sistema encontrar texto relevante?», sino «¿puede encontrar la información relevante y además entender cómo se conectan las piezas?». De esa brecha trata todo lo demás.
Una pregunta que abarca varios documentos
Tomemos una base de conocimiento empresarial simplificada. Un archivo describe una norma de ingeniería:
Document A
↓
Engineering Standard
↓
Requirement R1
Otro contiene la especificación de un proyecto:
Document B
↓
Project Specification
↓
Component C1Document C
↓
Validation Rule
↓
Rule V1
Ahora alguien pregunta qué requisito se aplica al componente C1, qué norma define ese requisito y qué regla de validación hay que usar. Ningún documento contiene la respuesta por sí solo. Responder bien obliga a enlazar varios hechos:
Component C1
│
│ governed by
▼
Requirement R1
│
│ defined by
▼
Engineering Standard
│
│ validated by
▼
Validation Rule V1
Una base de datos vectorial no sabe que esa estructura existe. Su trabajo es encontrar contenido semánticamente cercano a la consulta, y es un trabajo muy valioso. Lo que pasa es que la similitud semántica y el razonamiento sobre relaciones son cosas distintas.
Dónde la búsqueda vectorial es la herramienta adecuada
Antes de meter grafos en la conversación, conviene ser justos con la recuperación vectorial. Es una de las piezas más útiles de RAG, y el flujo típico es este:
User Query
│
▼
Query Embedding
│
▼
Vector Similarity Search
│
▼
Top-K Chunks
│
▼
Context Construction
│
▼
LLM
Si se pregunta «¿Qué requisitos hay para el espesor del firme de la carretera?» y la base de conocimiento tiene una sección justo sobre eso, la recuperación semántica normalmente la encontrará. La pregunta es local, así que no hace falta entender una red amplia de conexiones. La recuperación vectorial encaja mejor cuando:
- la respuesta está en un solo sitio
- la cercanía semántica sirve bastante bien como indicador de relevancia
- los documentos pueden tratarse casi siempre por separado
- unos pocos fragmentos bastan para responder
- mantener la recuperación simple es una prioridad
Así que «¿el RAG vectorial es bueno o malo?» es la pregunta equivocada. La útil es qué tipo de problema de recuperación hay realmente sobre la mesa, porque de esa respuesta depende si basta con la búsqueda por similitud o hace falta algo más rico.
El conocimiento suele estar conectado
El material de una empresa rara vez está aislado. Una norma define requisitos, y cada requisito remite a otras cosas:
Standard
│
├── defines → Requirement
│
├── references → Section
│
└── supersedes → Previous Standard
Requirement
│
├── applies_to → Component
├── depends_on → Condition
└── validated_by → RuleComponent
│
├── belongs_to → Project
└── uses → Material
Una pregunta que toca varios de estos vínculos exige recuperación multisalto. Puede que el sistema tenga que:
- encontrar el componente
- averiguar qué requisito se le aplica
- identificar la norma que lo rige
- reunir las condiciones asociadas
- localizar la regla de validación
- combinar todas las evidencias
Es un problema de recuperación distinto de traer el párrafo más cercano.
Qué aporta un grafo de conocimiento
Un grafo de conocimiento representa de forma explícita las entidades y sus relaciones. El pipeline habitual trata el conocimiento así:
Document → Chunk → Embedding
Un grafo añade una segunda representación a su lado:
Entity ──relationship──> Entity
Un ejemplo de cómo se ve en la práctica:
Standard
│
defines
│
▼
Requirement
│ │
applies_to validated_by
│ │
▼ ▼
Component Rule
│
belongs_to
│
▼
Project
El grafo no sustituye a los documentos. Siguen siendo el material de origen, y el grafo pasa a ser una capa estructurada que describe las entidades que contienen y cómo se relacionan.
GraphRAG en un párrafo
GraphRAG combina la generación aumentada por recuperación con la representación y la recuperación de conocimiento basadas en grafos. En lugar de apoyarse solo en la similitud semántica, el sistema sigue las relaciones entre entidades y conceptos para encontrar la información relevante. Conceptualmente:
User Query
│
▼
Query Understanding
│
┌──────────┴──────────┐
▼ ▼
Vector Retrieval Graph Retrieval
│ │
▼ ▼
Relevant Chunks Related Entities
│ │
└──────────┬──────────┘
▼
Evidence / Context
│
▼
LLM
│
▼
Answer
Las implementaciones varían mucho. Lo que no cambia es que la recuperación tiene acceso a relaciones, no solo a similitud.
Dos preguntas distintas
La forma más clara de separar ambos enfoques es fijarse en qué pregunta cada uno. La recuperación vectorial pregunta, más o menos, qué contenido se parece más a la consulta. La recuperación por grafo puede preguntar qué entidades están conectadas con los conceptos de la consulta y qué se aprende siguiendo esos vínculos.
Pueden trabajar en equipo:
Query
│
┌────────┴────────┐
▼ ▼
Semantic Structural
similarity relationships
│ │
▼ ▼
Chunks Entities
│ │
└────────┬────────┘
▼
Evidence
Por eso GraphRAG no es simplemente una base de datos vectorial mejor. Es otra estrategia de recuperación para otra clase de problemas.
Cuándo compensan las relaciones
Las relaciones explícitas suelen compensar en unas cuantas situaciones.
Preguntas de varios pasos. Una pregunta como «¿Qué normativa regula esta pieza y qué reglas de validación adicionales la acompañan?» solo se puede responder recorriendo varios vínculos seguidos:
Component
↓
Requirement
↓
Regulation
↓
Validation Rule
Dominios densos en relaciones. Algunos campos están llenos de conexiones: normativas, normas de ingeniería, entidades financieras, conocimiento científico, catálogos de productos, conocimiento organizativo y redes de dependencias. Ahí las propias relaciones tienen significado.
Evidencia repartida entre archivos. Un documento define un requisito, otro recoge una excepción y un tercero explica la validación. Lo difícil es unirlos correctamente.
Preguntas sobre una entidad completa. «¿Cuáles son todos los requisitos asociados a esta entidad?» encaja de forma natural con una recuperación que tenga en cuenta las relaciones.
El coste de añadir un grafo
Es tentador oír hablar de grafos de conocimiento y concluir que el RAG vectorial está anticuado y que GraphRAG es mejor. Como conclusión de ingeniería, es la equivocada. Los grafos traen complejidad extra, con más etapas que construir y operar:
Document Processing
↓
Entity Extraction
↓
Relationship Extraction
↓
Entity Resolution
↓
Graph Construction
↓
Graph Storage
↓
Graph Retrieval
↓
Context Construction
Cada etapa es un nuevo punto de fallo, y los errores se acumulan a medida que avanzan por el pipeline. ¿Y si la extracción de entidades se equivoca? ¿Y si dos entidades distintas comparten nombre? ¿Y si una relación se infiere mal, el grafo queda incompleto o mantenerlo se encarece a medida que cambian los documentos? Son problemas de ingeniería, no solo de IA.
El grafo hay que construirlo
Un grafo no aparece solo. Construirlo forma parte del trabajo, y un pipeline simplificado se ve así:
Documents
│
▼
Document Processing
│
▼
Text / Structure
│
▼
Entity Extraction
│
▼
Relationship Extraction
│
▼
Entity Resolution
│
▼
Knowledge Graph
Supongamos que una frase de un archivo fuente dice que R-102 es la regla para la pieza de puente B-17 siempre que se cumpla C-4. Convertido en estructura, podría quedar así:
(R-102)
│
applies_to
↓
(B-17)
(R-102)
│
requires_condition
↓
(C-4)
La recuperación puede entonces usar esos vínculos. Pero si la extracción produce por error
R-102 → applies_to → B-71
el grafo arrastrará información incorrecta. Por eso la calidad de la extracción de conocimiento pasa a formar parte de la calidad de la recuperación.
Vectores y grafo juntos
Los sistemas reales a menudo no necesitan elegir. El patrón puede combinar vectores y grafo:
Query
│
▼
Query Analysis
│
┌──────────┴──────────┐
▼ ▼
Vector Retrieval Graph Retrieval
│ │
▼ ▼
Relevant Chunks Related Entities
│ │
└──────────┬──────────┘
▼
Evidence Fusion
│
▼
Context Building
│
▼
LLM
La búsqueda vectorial encuentra fragmentos semánticamente relevantes, y la recuperación por grafo aporta el contexto de las relaciones. Juntas producen una evidencia más rica, lo que ayuda sobre todo cuando una pregunta combina «encuentra la información relevante» con «entiende cómo se conecta».
Palabras clave, vectores, híbrido y grafo
Pasar de la búsqueda por palabras clave a la vectorial y luego a GraphRAG no significa que cada paso jubile al anterior. Cada método responde a una necesidad distinta:
Keyword Search
│
└── Exact terms / identifiers
Vector Search
│
└── Semantic similarityHybrid Search
│
└── Exact + semantic relevanceReranking
│
└── Improve ordering of candidatesGraph Retrieval
│
└── Relationship-aware retrieval
Un sistema en producción puede combinar varios. La tarea de ingeniería es decidir qué señales importan para el problema concreto.
Empieza por la respuesta
En lugar de abrir con «¿deberíamos usar GraphRAG?», conviene empezar por lo que hay que recuperar para dar una respuesta correcta.
Si hace falta un único fragmento claramente relevante, esto puede bastar:
Query
↓
Vector Search
↓
Passage
Si importan los identificadores exactos, esto puede ayudar:
Query
↓
Keyword / Metadata Search
Si lo que se necesita es comprensión semántica, esto es útil:
Query
↓
Vector Search
Si hacen falta varias señales de recuperación, esto encaja mejor:
Query
↓
Hybrid Search
↓
Reranking
Si hay que recorrer relaciones, la recuperación por grafo empieza a ser interesante:
Query
↓
Entity Identification
↓
Graph Retrieval
↓
Related Evidence
Y si la propia estrategia de recuperación tiene que cambiar de una pregunta a otra, puede estar justificado un flujo de trabajo agéntico:
Query
↓
Decision / Planning
↓
Choose retrieval strategy
↓
Retrieve
↓
Evaluate evidence
↓
Retrieve again if necessary
↓
Answer
Con un grafo, esto se vuelve ingeniería de sistemas
Sin grafo, el sistema es simplemente:
Application
↓
Vector Database
↓
LLM
Con uno, se convierte en algo más parecido a esto:
Application
│
▼
Query Understanding
│
┌─────────┴─────────┐
▼ ▼
Vector Store Graph Store
│ │
└─────────┬─────────┘
▼
Retrieval Layer
│
▼
Context Builder
│
▼
LLM
Al equipo le cae una nueva lista de preocupaciones: cómo se construye el grafo, cómo mantenerlo sincronizado con los documentos, cómo indexarlo, la latencia de las consultas, la coherencia, lo bueno que es el grafo en realidad, cómo resolver entidades duplicadas, dónde se almacena, cómo monitorizarlo y cómo evaluarlo. En ese punto GraphRAG deja de ser una función del framework y pasa a ser un problema de ingeniería de sistemas.
Repensar qué es RAG
Trabajar con documentos cambia la manera de ver RAG. Al principio parece que se trata de recuperar los chunks correctos y dárselos al LLM. Una visión más amplia es diseñar una representación del conocimiento que permita al sistema traer la evidencia necesaria para responder. A veces esa representación son chunks y embeddings. A veces ayudan los metadatos, la recuperación híbrida o unas relaciones lo bastante importantes como para justificar un grafo. Y a veces el sistema tiene que decidir sobre la marcha cómo buscar. La arquitectura debe seguir las necesidades de información del problema, no la popularidad de una tecnología.
Un modelo de decisión sencillo
Reducida a un modelo mental, la elección queda así:
What does the question require?
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Exact terms Semantic meaning Relationships
│ │ │
▼ ▼ ▼
Keyword/ Vector Graph
Metadata Search Retrieval
│ │ │
└────────────────┼────────────────┘
▼
Hybrid System
│
▼
Reranking
│
▼
Context Building
│
▼
LLM
El objetivo no es la arquitectura más sofisticada, sino la más sencilla que resuelva el problema de recuperación de forma fiable.
La búsqueda vectorial es potente, pero la similitud no equivale a entender relaciones. Cuando las preguntas se vuelven multisalto, cruzan documentos, giran en torno a entidades o dependen mucho de relaciones, modelar el conocimiento de forma explícita añade otro mecanismo de recuperación potente. GraphRAG no es interesante porque supere a RAG, sino porque preguntas distintas piden estrategias de recuperación distintas. Primero hay que entender la pregunta y la estructura del conocimiento; la tecnología se elige después.