Qué es un knowledge graph, explicado sin tecnicismos
Las empresas no tienen un reto de falta de datos. Tienen datos que no saben cómo se relacionan entre sí. Un knowledge graph, o grafo de conocimiento, es la forma de guardar justo eso: qué es cada cosa y cómo se conecta con las demás.
Supongamos que un proveedor avisa un lunes de que retrasará tres semanas una entrega de componentes.
La pregunta de dirección es inmediata: ¿qué clientes se ven afectados?
La respuesta existe. Está repartida entre el ERP, que sabe qué órdenes de compra dependen de ese proveedor y qué productos llevan esos componentes; el CRM, que sabe qué clientes son estratégicos; y los contratos, que dicen cuáles tienen penalizaciones por retraso.
Y aun así, responder puede llevar días. Varias personas cruzando exportaciones a mano.
No faltan datos. Faltan las relaciones.
Primero, qué es un grafo
Cuando en una empresa se habla de gráficos, se piensa en barras y quesitos. Un grafo es otra cosa.
Un grafo es una red. Tiene dos elementos:
- Nodos, que son las cosas: un cliente, un pedido, un producto, un proveedor.
- Relaciones, que son las conexiones entre ellas: este pedido es de este cliente, este producto lleva este componente.
Con eso, la pregunta del lunes cambia de naturaleza. Ya no hay que cruzar tablas. Basta con recorrer un camino: proveedor, componente, producto, pedido, cliente.
Lo que antes era una investigación se convierte en un recorrido.
Una tabla guarda registros. Un grafo guarda cómo se relacionan. Y casi todas las preguntas importantes de una empresa son preguntas sobre relaciones.
Lo que convierte un grafo en un grafo de conocimiento
Un grafo simple solo dice que dos cosas están conectadas. Eso se queda corto muy rápido.
En un grafo de conocimiento, cada relación tiene significado. No es lo mismo que una empresa nos compre, nos venda, sea filial de otra o sea competidora. Todas son conexiones. Ninguna significa lo mismo.
Y tampoco todos los nodos son iguales. Un cliente no es un proveedor. Un pedido no es una factura. Un contacto no es la empresa en la que trabaja.
Ese etiquetado explícito, qué es cada cosa y qué significa cada relación, es lo que se llama semántica. Y tiene consecuencias operativas muy concretas:
- En finanzas, una misma empresa puede ser a la vez cliente y proveedor. Si el sistema lo sabe, se puede ver la exposición neta con ella, no dos saldos aislados.
- En comercial, cuando un interlocutor clave cambia de empresa, la relación no se pierde: la persona sigue siendo un nodo, solo cambia su vínculo.
- En atención al cliente, un ticket deja de ser un texto suelto y pasa a estar unido al pedido, al producto y a las condiciones que se pactaron con ese cliente.
- En compras, un artículo que sustituye a otro queda marcado como tal, y el historial de consumo del antiguo no desaparece.
La ontología: el reglamento del negocio
Para que el significado sea coherente hace falta un reglamento. Eso es una ontología.
Suena a término académico, pero la idea es cercana. Una ontología es la descripción formal de cómo funciona el negocio. Por ejemplo:
- Un pedido pertenece a un único cliente.
- Una factura se emite por uno o varios pedidos.
- Un contrato marco cubre los pedidos de un cliente durante un periodo.
- Un producto se fabrica o se compra a partir de unos componentes.
Con estas reglas pasan dos cosas.
La primera: los datos se mantienen consistentes. Un pedido sin cliente, o una factura que apunta a un pedido inexistente, salta a la vista.
La segunda es menos evidente y más valiosa: el sistema puede deducir. Si un pedido está cubierto por un contrato con penalización por retraso, y uno de sus componentes depende del proveedor que ha avisado, ese cliente está en riesgo. Nadie lo ha escrito en ninguna parte. Se deduce de las relaciones.
La ontología no describe las tablas. Describe el negocio.
Por qué no basta con lo que ya tenemos
Toda empresa mediana tiene datos estructurados. ERP, CRM, herramienta de soporte, hojas de cálculo, almacén de datos.
El reto es que cada sistema es un jardín vallado. Cada uno guarda bien lo suyo y apenas sabe nada de los demás. Las relaciones entre sistemas viven en los procesos manuales y en la cabeza de las personas que llevan años en la empresa.
Que un dato esté estructurado no significa que tenga significado. Una columna llamada "cliente" en el ERP y otra llamada "cuenta" en el CRM pueden referirse a lo mismo, o no. Nadie lo ha dejado escrito.
Un grafo de conocimiento funciona como una capa de significado por encima de esos sistemas. No obliga a migrarlo todo ni a sustituir el ERP. Conecta lo que ya existe, con identificadores comunes y relaciones explícitas.
Por qué ahora importa más
Los modelos de IA generativa redactan con soltura y razonan cada vez mejor. Pero no conocen tu empresa. No saben que "cuenta" y "cliente" son lo mismo en tu caso, ni qué contrato está vigente, ni qué proveedor abastece a qué línea.
Cuando les falta ese conocimiento, rellenan el hueco con algo plausible.
Un grafo de conocimiento les da justo lo que no traen de serie: las entidades reales del negocio, sus relaciones y sus reglas. Y lo hace de forma trazable. Se puede seguir el camino por el que la IA llegó a una respuesta.
La capacidad de razonar se puede comprar. El significado del negocio no.
Cómo se empieza
No hace falta modelar toda la empresa. De hecho, es la forma más segura de no terminar nunca.
Se empieza por una pregunta de negocio que hoy cuesta responder. La del proveedor que se retrasa es un buen ejemplo. A partir de ahí:
- Identificar las entidades que intervienen. Normalmente no son más de ocho o diez.
- Nombrar las relaciones entre ellas, con verbos claros y acordados.
- Asegurar identificadores únicos para cada entidad, aunque viva en varios sistemas.
- Escribir las reglas que hoy aplica una persona de memoria.
Cada nueva pregunta reutiliza lo construido para la anterior. El grafo crece con el uso, no con un proyecto de dos años.
Un grafo de conocimiento no se diseña de una vez. Se gana pregunta a pregunta.
Esta es mi apuesta
Creo que los grafos de conocimiento van a dejar de ser un tema de especialistas para convertirse en una pieza normal de la arquitectura de datos de cualquier empresa que quiera usar IA en serio.
No porque sean una moda, sino porque responden a algo que siempre ha estado ahí: en la empresa todo está conectado, y los sistemas que usamos guardan las cosas por separado.
Los datos ya los tenemos. Lo que falta es conectarlos con su significado.