latent
Los modelos de lenguaje saben mucho. Los knowledge graphs saben lo que es realmente cierto. La combinación es lo que me resulta interesante.
Qué es un knowledge graph
Un knowledge graph almacena información como entidades y relaciones en un grafo estructurado. Cada pieza de conocimiento es una tripleta: sujeto, predicado, objeto.
(Albert Einstein) --[born_in]--> (Ulm, Germany)
(Albert Einstein) --[developed]--> (General Relativity)
(General Relativity) --[is_a]--> (Physical Theory)
(Ulm) --[located_in]--> (Baden-Württemberg)
Esa estructura te ofrece algo que el texto no estructurado nunca te dará: un recorrido (traversal) preciso. Puedes preguntar por "todas las teorías desarrolladas por personas nacidas en Alemania" y obtener una respuesta sin ambigüedades. Las relaciones son explícitas, tipadas y legibles por máquinas.
Existen dos variantes que aparecen con mayor frecuencia. RDF, el estándar del W3C basado en URIs y consultado con SPARQL, utilizado por Wikidata, DBpedia y la mayoría de las plataformas semánticas empresariales. Y los property graphs, donde los nodos y las aristas (edges) contienen propiedades de clave-valor, consultados con Cypher en Neo4j o Gremlin en otros sistemas. Los property graphs suelen ser más intuitivos para los desarrolladores de aplicaciones.
El Knowledge Graph de Google alimenta los paneles de información en los resultados de búsqueda. Wikidata tiene más de 100 millones de elementos con relaciones estructuradas. Estos no son ejercicios académicos; son infraestructura de producción.
Por qué los LLMs alucinan
Los LLMs generan texto prediciendo el siguiente token más probable dado un contexto. No buscan hechos en una base de datos. Realizan una coincidencia de patrones contra distribuciones estadísticas aprendidas durante el entrenamiento.
Eso funciona sorprendentemente bien la mayor parte del tiempo. El modo de falla es específico: cuando el modelo no tiene una señal de entrenamiento fuerte para un hecho particular, produce un texto que suena verosímil pero que es erróneo con total seguridad.
El modelo no distingue entre "sé esto con alta confianza" y "esto suena como algo que podría ser cierto". Ambos se presentan como prosa fluida. La alucinación es invisible sin una verificación externa.
El problema es más agudo con fechas específicas, números y estadísticas; relaciones entre entidades (quién trabaja dónde, quién reporta a quién); eventos recientes posteriores al corte de entrenamiento; y conocimiento de cola larga (long-tail) que apareció raramente en los datos de entrenamiento. Ese es exactamente el territorio donde más necesitas que el modelo sea preciso.
Cómo los knowledge graphs fundamentan a los LLMs
Combinar knowledge graphs con LLMs te ofrece un sistema donde la capacidad de lenguaje del modelo está anclada a hechos verificables. Hay tres patrones de integración que he visto funcionar en la práctica.
Patrón 1: recuperación basada en grafos
En lugar de una búsqueda por similitud de vectores (o junto a ella), se recuperan subgrafos estructurados que son relevantes para la consulta. El modelo recibe hechos explícitos en lugar de fragmentos (chunks) de texto que pueden o no contener la respuesta.
# RAG tradicional: la búsqueda vectorial devuelve chunks de texto
chunks = vector_db.similarity_search("Who founded Tesla?", k=5)
# Devuelve párrafos que mencionan a Tesla; pueden o no contener la respuesta
# Recuperación aumentada por grafos: hechos estructurados
triples = knowledge_graph.query("""
MATCH (p:Person)-[:FOUNDED]->(c:Company {{name: 'Tesla'}})
RETURN p.name, p.role, c.founded_date
""")
# Devuelve: [("Elon Musk", "CEO", "2003"), ("Martin Eberhard", "Co-founder", "2003"), ...]La recuperación estructurada elimina la ambigüedad. El modelo no tiene que extraer hechos de la prosa; los recibe directamente.
Patrón 2: inyección de contexto estructurado
Se le entrega al LLM un subgrafo serializado como parte de su contexto. El modelo razona sobre relaciones explícitas en lugar de inferirlas de texto no estructurado.
Contexto:
- Persona: Jane Chen | Rol: VP de Ingeniería | Empresa: Acme Corp | Desde: 2022
- Persona: Jane Chen | Reporta a: Marcus Webb (CTO)
- Persona: Jane Chen | Dirige: Equipo de Plataforma (12 ingenieros)
- Empresa: Acme Corp | Industria: FinTech | Fundada: 2019
Pregunta: ¿A quién reporta la VP de Ingeniería en Acme?
Este formato reduce drásticamente las alucinaciones en consultas sobre relaciones porque los hechos no son ambiguos.
Patrón 3: consultas a grafos generadas por LLM
El patrón más potente es permitir que el LLM escriba consultas contra el knowledge graph. El modelo traduce el lenguaje natural a SPARQL o Cypher, lo ejecuta e interpreta los resultados.
user_query = "¿Qué investigadores en el MIT han publicado artículos sobre mecanismos de atención?"
# El LLM genera la consulta Cypher
generated_query = """
MATCH (r:Researcher)-[:AFFILIATED_WITH]->(i:Institution {{name: 'MIT'}})
MATCH (r)-[:AUTHORED]->(p:Paper)-[:ABOUT]->(t:Topic {{name: 'Attention Mechanisms'}})
RETURN r.name, p.title, p.year
ORDER BY p.year DESC
"""
results = graph_db.run(generated_query)
# El LLM luego formatea los resultados en una respuesta en lenguaje naturalEsto le da al LLM todo el poder del grafo mientras mantiene los hechos fundamentados en datos estructurados.
GraphRAG: El enfoque de Microsoft
GraphRAG de Microsoft Research construye un knowledge graph automáticamente a partir de documentos fuente y luego lo utiliza para la recuperación. El proceso se ejecuta en etapas.
Primero, la extracción de entidades y relaciones. Un LLM lee los documentos fuente y extrae entidades y sus relaciones en un grafo. Luego, la detección de comunidades: el algoritmo de Leiden identifica clústeres de entidades densamente conectadas. Cada comunidad recibe un resumen generado por LLM que describe sus entidades y temas clave. Al momento de la consulta, las preguntas se comparan con esos resúmenes de comunidad y los subgrafos relevantes se recuperan como contexto.
Lo interesante es que GraphRAG maneja preguntas globales —consultas que necesitan síntesis a través de muchos documentos— mucho mejor que la búsqueda vectorial tradicional. "¿Cuáles son los temas principales en este corpus?" es una pregunta que la similitud de vectores no puede responder realmente. Un grafo con estructura de comunidad sí puede.
Casos de uso en producción
La gestión del conocimiento empresarial es el más obvio. Las organizaciones con miles de documentos internos, políticas y conocimiento táctico obtienen mucho de la recuperación estructurada en grafos. "¿Cuál es nuestra política sobre X?" se convierte en un recorrido del grafo en lugar de una apuesta de palabras clave.
Las ontologías médicas son otro caso. El sector salud ya cuenta con conocimiento estructurado en SNOMED CT, ICD-10 y bases de datos de interacciones farmacológicas. Los LLMs conectados a esos grafos pueden responder consultas clínicas fundamentadas en conocimiento médico verificado en lugar de lo que sea que el modelo haya absorbido durante el pre-entrenamiento.
Las redes de documentos legales encajan en el mismo molde. La jurisprudencia es intrínsecamente un grafo: los casos citan otros casos, los estatutos mencionan otros estatutos, las regulaciones hacen referencias cruzadas. Un LLM respaldado por un KG puede rastrear cadenas de razonamiento legal que la búsqueda vectorial pasaría por alto por completo.
También la detección de fraude. Redes de transacciones financieras modeladas como grafos, con una interfaz de LLM para que los investigadores consulten patrones de relación complejos en lenguaje sencillo.
Limitaciones
Los knowledge graphs no son gratuitos.
El costo de construcción es real. Crear un KG exhaustivo es costoso, ya sea que se haga manualmente o con extracción asistida por LLM. El control de calidad es un trabajo continuo, no un esfuerzo único.
La obsolescencia es el siguiente problema. Los grafos necesitan mantenimiento. Las entidades cambian, las relaciones evolucionan y mantener el grafo actualizado requiere una inversión en el pipeline que nadie presupuesta inicialmente.
Habrá brechas de cobertura. Ningún KG lo captura todo. Cuando el grafo no tiene la respuesta, el sistema debe retroceder de manera elegante (fallback) en lugar de deslizarse silenciosamente de nuevo hacia la generación de un LLM sin anclaje.
Y la rigidez del esquema eventualmente te afecta. Decidir los tipos de entidades y los esquemas de relaciones de antemano limita lo que el grafo puede representar. La evolución del esquema en grafos de producción es un proceso doloroso.
Herramientas y plataformas
- Neo4j: la base de datos de property graphs dominante, con fuertes integraciones de LangChain y LlamaIndex.
- Amazon Neptune: base de datos de grafos gestionada que soporta tanto RDF como property graphs.
- NebulaGraph: base de datos de grafos distribuida de código abierto, buena cuando se necesita escalabilidad.
- Wikidata: el knowledge graph abierto más grande, útil como capa fundacional.
- LangChain GraphQAChain: cadena preconfigurada para la integración de LLM y bases de datos de grafos.
¿Qué sigue?
La frontera que estoy observando son los LLMs que no solo consultan knowledge graphs sino que los extienden. Un LLM lee nuevos documentos, extrae entidades y relaciones, propone adiciones al grafo y un validador humano o automatizado aprueba los cambios.
Eso crea un bucle útil. El grafo hace que el LLM sea más preciso y el LLM mantiene el grafo actualizado. Aún no estamos totalmente ahí —la calidad de la extracción y la calibración de la confianza todavía necesitan trabajo— pero las piezas están llegando.
El objetivo final no son los LLMs ni los knowledge graphs por sí solos. Son sistemas que combinan la fluidez de los modelos de lenguaje con la precisión del conocimiento estructurado. Esa combinación es donde realmente reside la IA confiable.