SAP Knowledge Graph: cuando las relaciones se convierten en datos

Una ontología para la empresa autónoma

Los nodos (Nodes) representan objetos empresariales reales, como clientes, ubicaciones, pedidos o facturas, mientras que los arcos (Edges) describen las relaciones explícitas entre estas unidades (por ejemplo: el cliente A inicia el pedido B). Sobre esta estructura se asienta el modelo formal de representación del conocimiento (propiedades), la denominada ontología. Esta define conceptos estandarizados, jerarquías y reglas para toda la empresa.

Desde el punto de vista técnico, este conocimiento suele representarse mediante el Resource Description Framework (RDF) en forma de tripletas, que siguen una estructura gramatical clara compuesta por sujeto, predicado y objeto (por ejemplo: el proveedor X suministra el producto Y). A diferencia de una mera tabla SQL, un grafo de conocimiento de este tipo puede interpretarse de forma lógica tanto por personas como por máquinas.

SAP Hana Cloud Vector Engine

En este sentido, la distinción con respecto a las bases de datos vectoriales (como SAP Hana Cloud Vector Engine) reviste una importancia fundamental. Una base de datos vectorial transforma datos no estructurados en vectores numéricos multidimensionales (embedding). De este modo, pueden surgir espacios con cientos de dimensiones —algo sencillo para el ordenador, pero inimaginable para las personas: normalmente nos quedamos en cuatro dimensiones: tres espaciales y la cuarta, la del tiempo—.

Las relaciones entre los puntos de datos se calculan de forma puramente matemática en espacios multidimensionales a partir de distancias espaciales (como la similitud coseno o las distancias euclidianas). Esto resulta ideal para la búsqueda de similitudes en textos no estructurados (Retrieval-Augmented Generation, RAG), pero sigue siendo una «caja negra» matemática para el usuario, ya que las relaciones calculadas surgen de forma implícita y no pueden explicarse de manera lógica.

Por el contrario, un grafo de conocimiento define las relaciones de forma explícita, transparente y basada en reglas. Mientras que los vectores representan la asociación matemática de la IA, el grafo de conocimiento encarna su conjunto de reglas lógicas y explicables.

Integración nativa de grafos en SAP HANA Cloud

Durante mucho tiempo, el uso práctico de las bases de datos de grafos en el entorno SAP se caracterizó por una molesta ruptura de medios. Quien quisiera analizar redes de relaciones complejas tenía que extraer laboriosamente los datos del sistema ERP y transferirlos a sistemas especializados de terceros, como Neo4j. Con la actualización estratégica de HANA en el primer trimestre de 2025, SAP ha subsanado esta carencia funcional. Desde entonces, la base de datos en memoria HANA Cloud ofrece compatibilidad nativa para el almacenamiento y la búsqueda en grafos de conocimiento.

Para ello, la base de datos utiliza la sintaxis RDF establecida y el lenguaje de consulta SPARQL. La mayor ventaja arquitectónica de este enfoque „multimodelo“ radica en la posibilidad de combinar datos directamente: los desarrolladores pueden vincular datos relacionales SQL con datos de grafos en una única consulta o conectarlos mediante uniones, sin necesidad de replicar los datos.

SAP Knowledge Graph y SAP Virtual Data Models

El SAP Knowledge Graph, de nivel superior, se basa en este motor de base de datos integrado. Accede al amplio conjunto de metadatos del SAP Virtual Data Model (VDM) y crea una ontología que representa las relaciones empresariales inherentes a S/4. Este grafo sirve de brújula para el asistente de IA Joule y los agentes autónomos. Cuando un usuario le pide a Joule en lenguaje natural: „Muéstrame los pedidos atrasados“, la IA ya no tiene que adivinar las estructuras de las tablas. El grafo de conocimiento navega por la red semántica, identifica las API correctas incluidas en la lista blanca, establece los parámetros de filtro adecuados y construye una consulta precisa. De este modo, se minimiza drásticamente el riesgo de obtener resultados imprecisos o irrelevantes en comparación con los enfoques basados exclusivamente en modelos de lenguaje grande (LLM).

Por muy elegante que suene el concepto en teoría, la práctica pone de manifiesto los obstáculos y riesgos que esta técnica entraña para los clientes actuales de SAP: un grafo de conocimiento operativo a nivel de toda la empresa no es un producto «llave en mano», sino el resultado de un proceso de modelización sumamente complejo. La creación y el mantenimiento continuo de ontologías y estructuras de grafos requieren profundos conocimientos semánticos y consumen una cantidad considerable de recursos informáticos. Quien crea que el software se encarga de la estructuración semántica de forma totalmente automática subestima enormemente la complejidad de los procesos personalizados y de las tablas personalizadas que se han ido desarrollando a lo largo del tiempo.

Calidad de los datos, unidades de capacidad y política de API

Un grafo de conocimiento no es la panacea para la mala calidad de los datos. Si la base de datos del sistema ERP es incompleta, obsoleta o incoherente, incluso el grafo más inteligente solo proporcionará afirmaciones erróneas perfectamente estructuradas. Los análisis complejos de grafos (como la búsqueda de rutas y bucles) en conjuntos de datos transaccionales masivos y altamente interconectados requieren un gran esfuerzo computacional. Las bases de datos en memoria alcanzan rápidamente sus límites físicos con este tipo de operaciones, lo que puede disparar sin piedad los costes de hardware de las instancias de HANA Cloud.

Desde el punto de vista técnico, el Knowledge Graph está magníficamente diseñado, pero, desde el punto de vista comercial, sirve a SAP como un «peaje» estratégico. Para aprovechar al máximo la tecnología de grafos, SAP obliga a sus clientes actuales a incorporarse al restrictivo ecosistema de la Business Data Cloud (SAP BDC) y la Business Technology Platform (BTP o BAIP, Business AI Platform). A través de modelos de facturación basados en el consumo (Capacity Units) y directrices restrictivas sobre las API, SAP intenta mantener el control sobre los contextos empresariales de sus clientes actuales y bloquear sistemáticamente la fuga sin licencia de estos valiosos metadatos hacia potentes más económicas de terceros o de hiperescaladores.

Alternativas autónomas más allá del monopolio de los sistemas ERP

Sin embargo, los clientes actuales de SAP no tienen por qué rendirse sin luchar ante este dominio monopolístico. El mercado de las consultas de IA específicas para bases de datos y las capas semánticas está evolucionando a un ritmo vertiginoso y ofrece alternativas potentes e independientes del fabricante:

Herramientas como vanna.AI ofrecen marcos flexibles para conectar aplicaciones de modelos de lenguaje directamente a bases de datos SQL existentes (desde Snowflake hasta PostgreSQL y Oracle). Al añadir DDL, documentación y ejemplos de consultas históricas, el sistema aprende las relaciones semánticas sin necesidad de adquirir licencias para una costosa infraestructura de SAP.

El marco WrenAI demuestra de forma impresionante cómo se puede crear un modelo semántico directamente a través de un editor gráfico, en el que las tablas se definen como nodos y las relaciones como aristas. WrenAI traduce este grafo de conocimiento a un formato estandarizado que evita las consultas redundantes y ambiguas y genera sentencias SQL precisas, sin necesidad de recurrir al costoso rodeo que suponen el SAP BTP Generative AI Hub o Datasphere.

Asimismo, plataformas especializadas en grafos, como Graphwise con GraphDB, demuestran cómo se pueden implantar sistemas de grafos de conocimiento a nivel empresarial basados en estándares abiertos (RDF, OWL, SPARQL). Estos sistemas pueden coordinar fuentes de datos heterogéneas y conectarse directamente con modelos de lenguaje modernos a través de complementos inteligentes (como el ChatGPT Retrieval Connector), mientras que el control sobre los datos sensibles permanece íntegramente en el ámbito de control propio.

Conclusión personal para la comunidad SAP

El Knowledge Graph es, sin duda, el paradigma técnicamente superior para el futuro de la IA empresarial, ya que tiende el puente que tanto se necesita entre la imprecisión estocástica de los modelos de lenguaje y la precisión determinista de los sistemas ERP de gestión empresarial. Sin embargo, como cliente actual de SAP que se precie, debería desvincular la implantación de esta tecnología de la doctrina comercial de SAP en materia de plataformas. Aproveche las capacidades multimodales del Hana Cloud Graph Engine para estructurar sus datos de forma clara. Pero opóngase de manera firme a que todo su mapa semántico empresarial quede encerrado exclusivamente en la costosa trampa de las licencias de SAP BTP. El futuro pertenece a los espacios de datos abiertos e interoperables, en los que la empresa conserva la soberanía absoluta sobre su contexto empresarial y su inteligencia artificial.