Dix cas pour couvrir le spectre des Knowledge Graphs
Pourquoi ? Quel est l’enjeu et quels sont les bénéfices, pour qui ? Ce sont des questions à poser à l’initiation de tout projet, avant d’envisager les moyens. Les knowledge graphs industriels ne dérogent pas à cette règle. D’une part, ils ne conviennent pas à tous les besoins liés à l’exploitation ou à la production de connaissances. D’autre part, quand leur usage est justifié, l’architecture cible n’est pas unifiée pour tous les cas de figure. Le spectre des Knowledge Graph est large. En effet, les solutions dépendent de critères tels que la disponibilité et la qualité des sources, les volumes, la temporalité des informations (dont fréquence de mise à jour), le niveau de formalisation logique, l’enjeu d’interopérabilité en système ouvert, les accès et les modes d’exploration souhaités, etc.
Pour montrer à l’œuvre ces variations, cet article de la série des bonnes pratiques s’appuie sur dix cas d’usage industriels dont je publierai le détail au fil de cette fin d’été. C’est une façon concrète d’illustrer la nécessité de penser en termes de besoins et d’architecture logique avant de se focaliser sur des comparaisons de solutions. Celles-ci n’ont d’ailleurs de pertinence qu’une fois des exigences bien énoncées.
Définition prise d’un Knowledge Graph
Dans cet article, un Knowledge Graph est l’association d’un schéma de représentation logique d’une expertise et des faits en rapport avec cette représentation.
Le niveau de « connaissance » d‘un « knowledge graph », c’est la capacité à déduire de nouveaux faits à partir de données existantes en se basant sur des règles d’inférence ou des axiomes d’ontologies. Déclaratifs, et non calculés par des algorithmes, ces derniers ajoutent de nouvelles informations au jeu de données existant, apportant du contexte et des connaissances.
Stocker des données sous forme de graphe, en construisant un modèle après coup, par apprentissage d’une structure sur des volumes de relations entre données, est-ce que c’est constituer un Knowledge Graph ? Si on part du principe d’une structuration, via formalisme logique, de la connaissance préexistante sous forme de graphe orienté, avec consensus de la représentation chez les experts, non.
C’est une approche distincte de la « graph intelligence », basée sur l’apprentissage inductif sur les structures topologiques. En effet, des techniques d’IA permettent d’analyser, apprendre et extraire des motifs à partir de données structurées en graphes en utilisant des réseaux de neurones, des méthodes d’embedding et de l’apprentissage automatique basé sur les graphes. L’une est une approche de raisonnement sémantique et déductif, l’autre analytique.
L’ADN d’un knowledge Graph : interopérabilité et raisonnement sémantique
Un outil n’est bon que s’il est adapté aux besoins. Chaque approche a ses avantages et elles peuvent être combinées. L’une ne chasse pas l’autre puisqu’elles sont adaptées à des besoins différents. Le knowledge Graph répond au besoin de formaliser une expertise éprouvée d’un domaine, pour faire des diagnostics basés sur des connaissances démontrées, ou des recherches d’informations fiables, ou actionner des liens causals pour des agents autonomes. Le graph intelligence permet d’analyser des gros volumes de données avec une approche algorithmique, avec apprentissage ou non.
Avec des modèles standardisés du point de vue métier et technique, les Knowledge Graph sont champions de l’interopérabilité, contrairement aux approches ML. De plus, le raisonnement sémantique assure prédictibilité et explicabilité des résultats. C’est donc plutôt sur ces axes qu’on les attend. Toutefois, les différences entre un knowledge graph nommé tel comme Wikidata et les knowledge graphs utilisés par la Banca d’Italia, la SNCB, la NASA ou Festo, sont multiples. Elles se distribuent sur un spectre allant du simple graphe de données interrogeable en SPARQL jusqu’aux systèmes dotés d’un raisonnement logique complet (OWL-DL + règles + inférence).
Pourquoi la dimension logique reste centrale et pourquoi les LLM ne la remplacent pas
Si la notion de Linked Data a peu à peu fait son chemin sur la dernière décennie, notamment à travers les FAIR data et le partage des données scientifiques, force est de constater que le pendant ontologique et le raisonnement logique ont eu moins de succès. Nombreux sont d’ailleurs ceux qui espèrent encore pouvoir les enterrer avec les LLM et l’IA générative.
La raison est simple : structurer logiquement un domaine de connaissance sur la base d’un consensus prend du temps. Et comme je l’explique dans cet article, en pratique, en production, dès qu’on atteint des dizaines de milliers d’instances non triviales, on sacrifie l’expressivité d’OWL-DL au profit de profils OWL restreints (OWL 2 RL et OWL 2 EL). Il y a donc moins de richesse de déductions possibles que ce que promet la théorie.
Reste que les LLM, quand ils « infèrent » quelque chose, ne fournissent ni réplicabilité, ni justification logique, ni interopérabilité. Ils peuvent en outre présenter des « hallucinations » structurelles, la corrélation n’étant pas une déduction. Peu nombreuses, elles peuvent néanmoins conduire à des failles critiques. Les LLM reposent fondamentalement sur un mécanisme probabiliste, fonctionnant principalement par statistiques sur des connaissances acquises, sans compréhension causale profonde.
Si toutes les règles logiques de toutes les disciplines étaient déjà énoncées de façon cohérente et vérifiée, sans ambiguïté, dans l’ensemble de la documentation qui nourrit les LLM, le problème de construire des knowledge graphs ne se poserait pas. Mais il se pose bel et bien … Et par un effet de retour, ce sont justement les LLM qui poussent à s’intéresser davantage au niveau de formalisation logique.
Les cas d’usages et les axes d’analyse.
L’image ci-dessous positionne à grosses mailles sous forme de heatmap les dix cas choisis sur plusieurs axes d’analyse.
Pour couvrir une large partie du spectre des knowledge Graphs, j’ai choisi ces dix cas d’usage industriels car représentatifs de la diversité des besoins et des solutions. Ils présentent des niveaux distincts de formalisation logique du modèle et d’usage de raisonnement sémantique.
D’autres axes conditionneraient bien sûr une analyse plus rigoureuse du positionnement des cas : volume à traiter, streaming ou non, sources, nécessité de contrôle de la qualité et de la provenance, accessibilité de l’exploration, logique de maintenance, etc. Mais ils illustrent moins les spécificités des knowledge Graph.
En particulier, il faut différencier une approche visant à fournir à la machine des capacités de raisonnement déductif d’une approche axée sur l’exploration de données reliées entre elles. Il y a un monde entre Wikidata et le cas Banca d’Italia et stricto sensu, Wikidata n’est pas un knowledge Graph. Il m’a paru important d’illustrer pourquoi, d’où sa présence dans la liste.
Par ailleurs, pour clarifier le distinguo entre Knowledge Graph fondé sur une ontologie formalisée en description logique et un « knowledge » graph nommé tel se passant de logique déclarative, j’ai introduit l’analyse du cas Linkedin. Ce n’est pas non plus un Knowledge Graph au sens de la définition donnée. C’est un cas sans ontologie formelle et sans raisonneur, avec de l’apprentissage automatique. Le cas de la Banca d’Italia est à l’opposé : un graphe top-down orienté ontologie, avec le paradigme Warded Datalog+/-.
Nous allons par la suite analyser davantage l’axe de représentation des connaissances et raisonnement sémantique sur plusieurs niveaux de lecture.
Une grille de lecture en quatre niveaux
Cet article distingue quatre niveaux de « knowledge graph » construits sur des triple/quad stores, selon le niveau de sophistication du raisonnement associé. Toutefois, le système Vadalog, utilisé dans le cas de la Banca d’Italia, échappe à cette classification : il ne repose pas sur l’architecture triplestore + raisonneur OWL classique, mais offre un compromis différent entre complexité computationnelle et puissance expressive du raisonnement.
En termes d’expressivité logique, il est aussi avancé que le niveau 4, mais selon un autre paradigme : sa base d’entailment est OWL 2 QL (niveau 2), étendue par Warded Datalog+/-, qui ajoute récursion complète, quantification existentielle généralisée et agrégation, tout en garantissant une complexité PTIME en données. Cette combinaison n’est capturée par aucun des niveaux 1 à 4, puisqu’ils confondent implicitement « profondeur du profil OWL » et « puissance des règles ».
Ce qui n’est pas systématiquement abordé
Beaucoup des problématiques du pipeline d’ingestion des données dans un knowledge graph sont celles qu’on trouve en Business Intelligence. Résolution d’entité, nettoyage, fusion, mapping : ce ne sont pas des activités propres aux knowledge graphs. Cette approche illustrative se concentrera donc plutôt, sur les cas d’usage retenus, sur la validation de règles après nettoyage.
De même, la mise à jour et l’interrogation en temps réel de données émises par des sources vivantes ne seront pas traitées de façon structurée ici. Le streaming de flux appliqué à un knowledge graph conduit à considérer des outils comme Apache Flink, Kafka Streams et autres. Même si le sujet est évoqué dans certains cas, cela mérite, du point de vue de l’auteur, un article distinct sur le pipeline d’ingestion et de contrôle, avec un focus sur la problématique de flux continu en temps réel.
Quant à l’aspect socio-technique des knowledge graphs, qui soulève des questions de gouvernance de cette formalisation de la connaissance tout au long de son cycle de vie, ce n’est pas non plus l’objet de cette approche illustrative des architectures.
Positionnement général et liste des cas considérés
La liste ci-dessous pointera sur des articles distincts analysant chaque cas. Ils seront mis à jour progressivement.
Wikidata : Un graphe construit à partir de données en wikibase, projetées en RDF pour l’interrogation SPARQL, sans ontologie OWL ni raisonnement : l’archétype du niveau 1, utile pour la réconciliation d’entités mais pas pour la déduction.
LinkedIn : un contre-exemple volontairement hors standard, taxonomie pilotée par apprentissage automatique et gouvernance organisationnelle plutôt que par logique de description ; illustre l’arbitrage coût/bénéfice d’un raisonneur DL à très grande échelle.
NASA (Stardog) : niveau 3, réécriture de requêtes plutôt que matérialisation, dans un contexte où la traçabilité et la criticité des données priment.
SAREF/OfficeGraph : niveau 2, ontologie OWL légère + validation SHACL, cas IoT/bâtiment intelligent à volumétrie modérée mais exigence de contrôle forte.
Statoil (Ontop) : l’approche OBDA, pas de matérialisation, mapping virtuel vers des sources industrielles existantes (R2RML), illustre l’alternative à l’ETL classique.
JPMorgan (FIBO, GraphDB) : niveau 3, ontologie financière de référence dans un secteur régulé, gouvernance sémantique et interopérabilité inter-institutions.
Festo (RDFox) : niveau 3, matérialisation en mémoire pour du raisonnement quasi temps réel, contexte industriel/maintenance.
SNCB (ODASE) : niveau 4, le cas le plus riche en raisonnement (OWL-DL complet + SWRL étendu) : criticité ferroviaire et besoin de garanties logiques fortes.
ERA Rail Knowledge Graph (ERA KG) : niveau 2 partiel, angle interopérabilité réglementaire européenne. Une initiative de l’Agence de l’Union européenne pour les chemins de fer
Banca d’Italia (Vadalog) : le pôle opposé à LinkedIn, approche top-down orientée ontologie, paradigme Warded Datalog+/-, contexte réglementaire bancaire (proche des besoins type AnaCredit).
Le prochain article portera sur le premier cas, « Wikidata : un wiki déguisé en knowledge graph ».