Durante la indexación, un LLM lee cada documento y extrae dos listas: las entidades que aparecen (personas, organizaciones, productos, fechas, lugares) y las relaciones entre ellas, cada una con su tipo. Con eso se monta un grafo dirigido.
"TechCorp fue fundada en 2015 en Madrid.
María González es la CEO de TechCorp desde 2021."
"TechCorp lanzó CloudSync en agosto de 2024."
↓ extracción
[María González] --es_CEO_de--> [TechCorp] --lanzó--> [CloudSync]
|
fundada_en
↓
[Madrid]Lo importante no es el grafo en sí, es que ninguna de esas aristas estaba en un solo documento. El camino de María González a CloudSync cruza dos textos distintos, y es exactamente el tipo de respuesta que un retriever por similitud no puede componer.
Responder con un grafo son cuatro pasos, y el segundo es el que aporta lo que no había:
| Paso | Qué hace |
|---|---|
| 1 · Extraer entidades de la consulta | Otra llamada al LLM, para saber de qué se está preguntando |
| 2 · Recorrer el grafo | Desde cada entidad, tomar los nodos a una o dos aristas de distancia |
| 3 · Buscar por similitud | El retrieval de siempre, en paralelo |
| 4 · Combinar | Se le pasan al modelo las dos cosas: las relaciones encontradas y los documentos |
Ese recorrido tiene un parámetro que decide casi todo: la profundidad. A una arista se obtienen los vecinos directos; a dos, los vecinos de los vecinos, que en un grafo denso puede ser medio corpus. Subirla parece dar más contexto y lo que suele dar es ruido, porque el número de nodos alcanzables crece muy deprisa.
// profundidad 2 en un grafo denso puede alcanzar casi todo: más contexto no es mejor contexto| Úsalo cuando… | No lo uses cuando… |
|---|---|
| Necesitas razonar sobre relaciones entre entidades | Las consultas van sobre contenido, no sobre conexiones |
| Aparecen preguntas del tipo «¿cómo se relaciona X con Y?» | Los documentos no tienen entidades claras |
| El dominio tiene una ontología definida (legal, médico) | El dominio es muy general y sin estructura |
| Hay que explicar el porqué de una respuesta | Solo hace falta recuperar información |
La segunda fila de la derecha es la que más proyectos hunde. Graph RAG depende por completo de que la extracción de entidades funcione, y esa extracción es un LLM devolviendo JSON: si el dominio no tiene entidades nítidas, el grafo sale lleno de nodos casi duplicados —«TechCorp», «Tech Corp», «la empresa»— que no se conectan entre sí, y el recorrido no encuentra nada.
De ahí que la resolución de entidades —decidir que dos nombres son la misma cosa— sea el trabajo real de un grafo de conocimiento, y no la parte que ningún tutorial enseña.
try/except que, si falla, devuelve dos listas
vacías e imprime un aviso — es decir, un documento cuya extracción falle desaparece del grafo
en silencio, y el grafo queda incompleto sin que nada lo indique. Dos: las entidades de la
consulta se cruzan con las del grafo por coincidencia parcial de cadenas en minúsculas, lo
que empareja «Madrid» con «Madrid Real» y no empareja «TechCorp» con «Tech Corp». Tres: no
hay ningún paso de resolución de entidades, que es justamente el problema difícil. ¿Cuántos
nodos duplicados tendría tu grafo tras extraer de cien documentos reales? Merece la pena
contarlo antes de decidir que esta técnica te conviene.
Coge tres documentos tuyos y extrae las entidades y relaciones a mano, en una hoja. Diez minutos. Después mira el dibujo y pregúntate: ¿alguna de mis consultas reales necesita recorrer una arista para responderse?
Si el grafo sale con muchas entidades y pocas relaciones, o si tus consultas se responden todas mirando un solo nodo, ya sabes que esta familia no es la tuya — y te has ahorrado la parte cara, que es descubrirlo después de indexar el corpus entero.