Knowledge Graphs: cómo representar el conocimiento de una empresa

El knowledge graph no es una moda ni una solución universal. Es la
estructura que aparece cuando el conocimiento de una empresa es, por
naturaleza, una red de entidades y relaciones. Cuando lo es, no hay
alternativa razonable. Cuando no lo es, es sobreingeniería.

Introducción

Llevamos dos días preparando el terreno: las entidades (quién es quién,
ayer) y las relaciones (dónde vive el negocio, ayer). Hoy las unimos y les
damos el nombre que ya hemos ido mencionando: knowledge graph, grafo de
conocimiento.

Pero vamos a hacerlo con una advertencia desde el principio, porque es la
que más falta en las conversaciones de IA empresarial: un knowledge graph
no es una solución universal. No todos los problemas empresariales son
grafos. Y presentar el grafo como la respuesta a todo es el modo más rápido
de que un proyecto muera en piloto.

El problema

Una operadora energética gestiona miles de activos: turbinas,
transformadores, líneas, subestaciones. Cada activo tiene un historial de
mantenimiento, una normativa aplicable, un responsable técnico, una cadena
de repuestos y una relación con los activos colindantes (una turbina que
alimenta a una subestación que conecta con una línea).

Cuando falla un activo, la pregunta operativa no es «¿dónde está el
historial de la turbina T-12?» (eso es una búsqueda). Es una pregunta de
alcance y consecuencia:

«Si la turbina T-12 falla, qué otras instalaciones quedan afectadas, qué
normativa de seguridad se activa, qué repuestos hay disponibles y qué
técnicos están cualificados para esa reparación.»

Esa pregunta cruza: el activo y sus colindantes (red física), la normativa
aplicable a ese tipo de activo (regulación), el inventario de repuestos
(supply chain), y el personal cualificado (recursos). Ninguna de esas
piezas está en un solo lugar. Y la respuesta correcta no es un documento: es
una red recorrida.

El concepto

Un knowledge graph (KG) es una estructura de datos que representa el
conocimiento como un grafo:

• Nodos → entidades (una turbina, un contrato, un cliente, una
  normativa, un técnico).
• Aristas → relaciones con dirección y significado (alimenta,
  cubre, requiere, cualificado_para).

Su forma mínima es la tripla (sujeto, relación, objeto):
(turbina T-12, alimenta, subestación S-3). Un KG es, en el fondo, una
colección enorme de triplas coherentes.

Lo que distingue a un KG de una tabla o de un documento no es la forma, es
lo que permite hacer:

1. Recorrido (graph retrieval). Ir de un nodo a otro siguiendo
   relaciones, en uno o varios pasos. «T-12 alimenta a S-3, y S-3 conecta
   con L-7» — dos pasos, pero una sola operación.
2. Razonamiento multi-hop. Responder preguntas que requieren encadenar
   varias relaciones: «¿Qué técnicos están cualificados para reparar las
   turbinas que alimentan subestaciones de la zona norte?» — esto cruza
   activo→colindante→zona→técnico.
3. Inferencia. Derivar relaciones no explícitas a partir de las que
   están. Si «T-12 alimenta a S-3» y «S-3 conecta con L-7», se puede
   inferir que T-12 «aporta a» L-7, aunque nadie haya escrito esa tripla.
   (La inferencia la desarrollaremos con detalle el día de razonamiento.)

¿Cuándo aporta valor?

• Cuando el conocimiento es relacional y cruzado: entidades conectadas
  en red, no en línea ni en árbol.
• Cuando las preguntas son de alcance e impacto: «¿qué se ve afectado si
  falla X?», «¿quiénes tienen que saberlo?».
• Cuando hay reglas y dependencias entre entidades que se aplican en el
  momento de decidir.
• Cuando se necesita trazabilidad: cada respuesta tiene un camino de
  triplas que la justifica.

¿Cuándo NO aporta valor?

• Cuando el conocimiento es jerárquico simple: una taxonomía de
  productos, un organigrama. Un árbol basta.
• Cuando la pregunta es una búsqueda directa: «¿dónde está el contrato
  de X?» Un índice o un RAG lo resuelven sin grafo.
• Cuando el conocimiento es masivo y homogéneo: millones de registros
  tabulares sin relaciones cruzadas. Una base de datos relacional o
  analítica es más eficiente.
• Cuando la organización no puede mantener el grafo: si las relaciones
  no se actualizan, el grafo se estropea y da confianza falsa.

Un knowledge graph mal elegido es más caro que su ausencia, porque da la
ilusión de haber resuelto el problema.

Comparación con lo que ya tienen

Ninguna de estas estructuras es «mejor». Son respuestas a preguntas
distintas. La arquitectura que veremos más adelante combina las cuatro; hoy
solo importa saber cuál responde a qué.

Arquitectura

En el diagrama de la serie, el knowledge graph es la materialización del
conocimiento relacional:

                KNOWLEDGE
                     ↑
              KNOWLEDGE GRAPH   ← hoy: nodos + relaciones + recorrido + inferencia
                     ↑
          ┌──────────┴──────────┐
          ↓                     ↓
      ONTOLOGY          ENTITY RESOLUTION
   (tipos de relación)    (entidades canónicas)
                     ↑
                SEMANTICS / DATA

El KG es donde la ontología (tipos), las entidades canónicas (ayer) y las
relaciones concretas (día 6) se unen en una estructura consultable. Es la
capa «cuerpo de hechos» de la que hablamos el día de la ontología (el
esqueleto de significado era la ontología; el cuerpo de hechos es el grafo).

Caso de uso

La operadora energética, con su turbina T-12. Descomponemos:

1. Problema. Ante la posible avería de una turbina clave, el equipo no
   puede dimensionar rápido el alcance (qué instalaciones, qué normativa,
   qué repuestos, qué técnicos) porque la información está dispersa en
   cinco sistemas.
2. Decisión. Decidir el plan de contingencia y la ventana de
   intervención antes de que la avería se convierta en un corte.
3. Conocimiento necesario. La red de colindantes de T-12; la normativa
   aplicable a su tipo; los repuestos disponibles y su localización; los
   técnicos cualificados y su disponibilidad.
4. Datos. Fichas de activos, historial de mantenimiento, normativa,
   inventario, personal — en cinco sistemas, sin la red unida.
5. Relaciones. T-12 → alimenta → S-3 → conecta → L-7; T-12 → requiere →
   repuesto R-55; normativa N-9 → aplica_a → tipo_turbina; técnico T-3 →
   cualificado_para → tipo_turbina.
6. Contexto. Hay una ventana de mantenimiento en dos semanas; la
   normativa N-9 exige notificación a la autoridad antes de intervenir;
   dos técnicos están de baja.
7. Memoria. La última avería de una turbina igual llevó 11 días por
   falta de repuesto R-55; la lección (stockear R-55) está en el informe.
8. Razonamiento. Recorrer la red: qué instalaciones quedan afectadas;
   cruzar con el inventario (¿hay R-55?); cruzar con personal (¿hay técnicos
   disponibles?); aplicar la restricción normativa (notificación previa).
9. Acción. Generar el plan de contingencia con la ventana, los repuestos
   a reservar, los técnicos a asignar y la notificación regulatoria en
   cola.
10. Infraestructura. El grafo de activos+normativa+inventario+personal
    • el razonamiento multi-hop que cruza las cuatro sub-redes + la memoria
      del incidente previo. El grafo aparece como consecuencia de la necesidad
      (dimensionar el alcance), no como punto de partida.

Trade-offs

• Coste. Un KG útil cuesta construir: hay que decidir qué entidades y
  relaciones modelar, de dónde viene cada dato, y cómo se mantiene. No es un
  proyecto de semanas.
• Complejidad. Modelar mal (demasiadas o demasiado pocas relaciones)
  produce un grafo que o es inutilizable o es un caos. La ontología previa
  (día 4) es lo que evita el caos.
• Calidad y mantenimiento. Un grafo con relaciones desactualizadas da
  confianza falsa: el agente responde con seguridad sobre un mundo que ya no
  existe. El mantenimiento es parte del coste, no un extra.
• Latencia. Los recorridos multi-hop sobre grafos grandes son más
  costosos que una consulta SQL. Se mitiga precalculando los recorridos que
  importan y limitando la profundidad.
• Escalabilidad. Los grafos de millones de nodos/aristas requieren
  infraestructura específica (bases de grafos, particionado). Para muchas
  empresas, un grafo de decenas de miles de entidades bien modeladas es más
  útil que uno de cientos de millones mal modelados.
• Limitación honesta: el KG representa el conocimiento estructurado.
  La parte del conocimiento que está en prosa (manuales, políticas,
  informes) no entra en el grafo directamente: hay que extraerla, y eso es
  trabajo de RAG y de extracción (mañana y el día de RAG). El grafo y el RAG
  son complementarios, no rivales.

Implicación para la empresa

Para el CDO, el knowledge graph es la forma de representar el conocimiento
relacional de la empresa —el que hoy vive en la cabeza de la gente— de modo
que un sistema pueda recorrerlo. Y es un activo selectivo: conviene
construirlo donde hay relaciones cruzadas y decisiones de impacto, no en
todo por igual.

Para el equipo de IA, la lección es de ingeniería: no se trata de «poner un
grafo», sino de decidir cuál conocimiento merece ser grafo y cuál es
texto para el RAG. Esa decisión es la que separa un KG útil de un proyecto
hinchado.

Para la alta dirección, el mensaje es de capacidad: las preguntas de alcance
e impacto («¿qué pasa si falla X?») son las que hoy paralizan a la empresa,
y son las que un grafo bien hecho convierte en consultas.

Conclusión

Un knowledge graph es la estructura que aparece cuando el conocimiento de
una empresa es una red de entidades y relaciones: nodos, aristas con
significado, recorrido multi-hop e inferencia. Aporta valor cuando el
conocimiento es relacional cruzado y las decisiones son de impacto; no es
una solución universal, y presentarlo como tal es un error caro.

Hoy el grafo está construido y consultable. Pero hay un problema que aún no
hemos tocado: en el momento en que un agente necesita una respuesta, ¿cómo
llega a la parte exacta del grafo (o del corpus de documentos) que necesita?
Recuperar es una disciplina propia, y tiene nombres y trucos que
conviene conocer antes de dar por hecho que «el modelo lo encuentra».

Siguiente artículo

Mañana: RAG no es memoria: qué falta después de recuperar un documento. Veremos qué hace realmente el RAG, qué no hace, y por qué la
pregunta correcta no es «¿recuperamos el documento?», sino «¿recuperamos el
conocimiento necesario para tomar la decisión?».

Fuentes

• Definición de trabajo de la ICE: ver serie, Día 1.
• Microsoft Research (2024). GraphRAG. — Búsqueda global/local sobre grafos
  de conocimiento (contexto para la comparación con RAG).
• La representación en grafos y el razonamiento multi-hop son conceptos
  estándar de knowledge representation y semantic web (W3C).