Un registro te dice qué es una cosa. El negocio no está en las cosas:
está en lo que las une. Y esa red de conexiones —ownership, contratos,
dependencias, suministro— es exactamente donde un agente necesita
razonar.
Introducción
Ayer resolvimos la identidad: ahora sabemos que «ACME», «ACME LTD» y
«Customer #49281» pueden ser una misma entidad. Bien. Pero una entidad
aislada no es un negocio. Un cliente sin contratos, un producto sin
componentes, un proveedor sin cadena de suministro, son datos, no
operación.
El negocio vive en las relaciones: quién posee qué, qué contrato cubre
qué producto, qué componente depende de qué, quién suministra a quién. Y esa
red de relaciones es donde ocurren las decisiones que importan: el riesgo,
el impacto, la dependencia.
El problema
Una operadora logística gestiona flotas, almacenes, contratos de transporte
y una red de subcontratistas. Su sistema de pedidos tiene todos los datos:
pedidos, rutas, vehículos, conductores, facturas. Y sin embargo, cuando un
cliente importante pide una revisión de su servicio, el equipo necesita una
semana para responder a una pregunta que suena simple:
«¿Qué pasa con este cliente si el subcontratista X deja de operar?»
Porque la respuesta no está en ningún registro. Está en una cadena de
relaciones que nadie ha representado nunca:
CUSTOMER → owns → CONTRACT
CONTRACT → covers → PRODUCT (servicio de transporte)
PRODUCT → depends_on → COMPONENT (ruta, vehículo, subcontratista)
COMPONENT → supplied_by → SUPPLIER (subcontratista X)
Hasta que el equipo no reconstruye esa cadena a mano —consultando el
contrato, el catálogo de servicios, la asignación de rutas, los contratos
de subcontrata— no sabe: cuántos productos del cliente dependen de X, si
hay subcontratistas alternativos que cubren las mismas rutas, qué contratos
se activarían, y qué margen de tiempo hay antes de que el cliente se lo
note.
Los datos describen cada pieza por separado. El negocio es la red. Y la
red no está en ningún sistema: está en la cabeza de tres personas y en
cuarenta hojas de Excel.
El concepto
Una relación es un vínculo con significado explícito entre dos entidades:
cliente → posee → contrato, contrato → cubre → producto,
producto → depende de → componente, componente → suministrado por →. No es un campo de referencia; es una afirmación sobre cómo
proveedor
funciona el negocio.
Las relaciones que importan en una empresa son, en gran parte, de cinco
familias:
- Ownership / pertenencia. Quién posee o controla qué: empresa → filial,
cliente → contrato, contrato → póliza, proyecto → activo. - Cobertura / alcance. Qué documento o acuerdo cubre qué: contrato →
producto, póliza → riesgo, SLA → servicio. - Dependencia. Qué necesita de qué: producto → componente, servicio →
ruta, proceso → recurso. - Suministro / flujo. Quién provee a quién: proveedor → componente,
almacén → centro, fabricante → distribuidor. - Responsabilidad. Quién es responsable de qué: activo → técnico,
contrato → comprador, incidencia → equipo.
Cuando estas relaciones se representan explícitamente —entidades como
puntos, relaciones como líneas con dirección y significado— obtienes una
estructura con un nombre que ya conoces: un knowledge graph (grafo de
conocimiento). Lo vamos a desarrollar a fondo el próximo día; hoy solo
importa ver que el negocio, por su naturaleza, es un grafo: entidades
conectadas por relaciones con dirección y significado.
Y la consecuencia para los agentes es directa: muchas de las preguntas que
un agente empresarial tiene que responder no son búsquedas («¿dónde está el
contrato de X?»), sino recorridos («¿qué depende de X?»). Una búsqueda
encuentra un documento; un recorrido sigue una cadena de relaciones. Y las
decisiones de riesgo —el impacto de que un proveedor falle, el alcance de un
cambio regulatorio, la exposición de un grupo de clientes— son recorridos,
no búsquedas.
Arquitectura
En el diagrama de la serie, las relaciones son el contenido del conocimiento,
y su representación natural es el grafo:
KNOWLEDGE
↑
┌──────────┴──────────┐
↓ ↓
ONTOLOGY ENTITY RESOLUTION
(tipos de relación) (entidades canónicas)
↓ ↓
└──────────┬──────────┘
↓
RELATIONSHIPS → (próximo día: KNOWLEDGE GRAPH)
↓
SEMANTICS
↓
DATA
La ontología (día 4) define los tipos de relación permitidos (posee,
cubre, depende_de, suministrado_por). La entity resolution (ayer) proporciona
las entidades canónicas entre las que esas relaciones se establecen. Y las
relaciones concretas de la empresa —este contrato cubre este producto— son
los hechos que van a poblar el grafo.
Caso de uso
La operadora logística, con su pregunta del subcontratista. Descomponemos:
- Problema. El cliente importante pide una revisión de servicio y el
equipo no sabe qué impacto tendría la salida del subcontratista X. La
respuesta lleva una semana porque la cadena de dependencias no está
representada. - Decisión. Decidir si se renueva, sustituye o diversifica la
dependencia de X antes de la reunión con el cliente. - Conocimiento necesario. Qué productos del cliente dependen de X; qué
rutas cubre X; qué subcontratistas alternativos existen; qué contratos se
verían afectados; qué margen hay. - Datos. Pedidos, rutas, vehículos, contratos de subcontrata, catálogo
de servicios — cada uno en su sistema, sin la cadena unida. - Relaciones. La cadena completa: CUSTOMER → owns → CONTRACT → covers →
PRODUCT → depends_on → COMPONENT (ruta) → supplied_by → SUPPLIER (X). Y
las alternativas: otras rutas → supplied_by → otros subcontratistas. - Contexto. La reunión con el cliente es en dos semanas; hay un
contrato de X que expira el trimestre próximo; dos rutas están
saturadas. - Memoria. El año pasado, la salida de otro subcontratista obligó a
reasignar 30 rutas en cinco días; la lección está en el informe
post-incidente. - Razonamiento. Recorrer la cadena: cuántos productos del cliente
tocan a X; cuáles tienen alternativa; cuáles no; el coste y el plazo de
reasignar cada uno. - Acción. Presentar al cliente un plan de diversificación (renovación
parcial de X + reasignación de rutas críticas a subcontratistas B y C)
con el impacto en precio y plazo. - Infraestructura. El grafo de relaciones (cadena cliente→contrato→
producto→ruta→subcontratista) + las alternativas como rutas
alternas + la memoria del incidente previo + el razonamiento de
recorrido. La tecnología (un grafo) aparece como consecuencia de la
necesidad (recorrer la cadena), no como punto de partida.
Trade-offs
- Coste. Representar relaciones explícitamente cuesta: hay que decidir
qué relaciones modelar (no todas), de dónde vienen (qué sistema es la
fuente de cada relación) y cómo se mantienen. - Complejidad. No todo el conocimiento de una empresa merece estar en un
grafo. Modelar las relaciones de cada correo es sobreingeniería; modelar
las relaciones de contratos, productos y proveedores es lo que decide
decisiones. - Calidad de las relaciones. Una relación mal establecida (un contrato
que «cubre» un producto que no cubre) es más peligrosa que su ausencia,
porque el agente va a razonar sobre ella con confianza. Las relaciones
necesitan fuente y validación. - Mantenimiento. Las relaciones cambian: el contrato se renueva, la
ruta se reasigna, el proveedor cambia. Un grafo que no se actualiza es un
mapa del negocio de hace un año. - Escalabilidad. Recorrer cadenas largas en un grafo grande tiene coste
de cómputo. En la práctica, las cadenas que importan son limitadas y se
pueden precalcular; el problema aparece con recorridos arbitrarios sobre
grafos enormes, que es tema del día de los knowledge graphs. - Limitación honesta: el grafo captura las relaciones declaradas o
inferibles de los datos. La relación informal «en la práctica, si X
falla, llamamos a B» no está en ningún sistema hasta que alguien la
escribe. El grafo mejora lo explícito; no reemplaza al conocimiento
tácito.
Implicación para la empresa
Para el CDO, las relaciones son el activo que casi nadie ha inventariado:
los datos están catalogados, los dashboards existen, pero cómo se conectan
las cosas vive en la cabeza de la gente. Y es justo eso lo que un agente
necesita para razonar sobre riesgo e impacto.
Para operaciones, la implicación es concreta: las preguntas de impacto
(«¿qué pasa si falla X?») son las más caras de responder hoy, y son las más
valiosas para un agente. Representar las relaciones es lo que convierte una
semana de investigación manual en una consulta.
Para la alta dirección, el mensaje es de resiliencia: las relaciones de
dependencia son donde se esconde el riesgo operativo. Verlas, es el primer
paso para gestionarlas.
Conclusión
Las entidades (ayer) son los puntos. Las relaciones son las líneas que hacen
del conjunto un negocio. Y cuando los puntos y las líneas se representan
juntos, con significado y dirección, obtenemos la estructura que el
conocimiento empresarial necesita para ser recorrido: un grafo.
Pero un grafo no es solo una forma bonita de dibujar relaciones. Tiene
propiedades —multi-hop reasoning, inferencia, recuperación dirigida— que lo
hacen diferente de una tabla, de un vector y de un documento. Mañana
desarrollamos esa estructura a fondo.
Siguiente artículo
Mañana: Knowledge Graphs: cómo representar el conocimiento de una empresa. Veremos qué es exactamente un knowledge graph, cuándo aporta valor
(y cuándo no), y cómo se compara con SQL, una base de vectores y un
documento.
Fuentes
- Definición de trabajo de la ICE: ver serie, Día 1.
- La representación de conocimiento en grafos y el razonamiento multi-hop
son conceptos estándar de knowledge representation; se presentan en
términos operativos.
