Accueil / Articles / RDF vers GraphRAG : couches ontologiques pratiques avec des exemples VOO

ontology rdf owl shacl graphrag knowledge-graph

RDF vers GraphRAG : couches ontologiques pratiques avec des exemples VOO

Des IRIs et des triples jusqu’au RDFS, OWL et SHACL : quand les ontologies surpassent les tables et comment elles aident GraphRAG à rester stable.

2162 mots

Vanguard S&P 500 ETF (VOO). Les documents publics indiquent que VOO vise à suivre l’indice S&P 500. Un système de connaissances doit comprendre au moins :

Ces trois phrases couvrent déjà tous les aspects principaux.

L’ontologie et le graphe de connaissances ne sont pas la même chose

L’ontologie définit les règles du monde. Le graphe de connaissances contient des faits sur ce monde.

L’ontologie peut déclarer ETF et AssetManager comme des types, managedBy comme un lien de l’ETF vers le gestionnaire, et tracksIndex comme un lien de l’ETF vers l’indice. Le graphe stocke ensuite des instances : VOO est un ETF ; VOO managedBy Vanguard ; VOO tracksIndex S&P500Index.

Pensez à la conception de jeux de plateau par rapport à la situation actuelle sur l’échiquier. Dire « ontologie ≈ schéma, graphe de connaissances ≈ données » est un raccourci utile — même si les ontologies peuvent coder une logique plus riche que les schémas de bases de données typiques.

Avez-vous toujours besoin d’une ontologie ?

Non. Les recherches par mot-clé exact sur quelques champs peuvent être gérées dans des tables ou du JSON. La création d’une ontologie implique des coûts en termes de conception, de gouvernance, de validation et d’entretien. Elle s’avère utile lorsque des problèmes tels que ceux-ci surviennent :

Problème 1. Différents systèmes utilisent des termes différents

fund provider, asset manager et management company peuvent désigner le même concept. Une ontologie choisit un terme préféré et établit des correspondances pour les alias.

Problème 2. Les utilisateurs posent des questions nécessitant des relations

« Quels ETF gérés par Vanguard suivent un indice boursier américain ? » exige une recherche à plusieurs étapes, et non simplement une correspondance par mot-clé.

Problème 3. Le système doit détecter les données invalides

Si managedBy doit faire référence à une organisation, VOO managedBy John Smith devrait échouer — même si John est un gestionnaire de portefeuille. Dans les industries réglementées, une seule erreur peut compromettre la conformité et les réponses générées par l’IA ; les contraintes de l’ontologie servent de garde-fous.

Problème 4. Le système doit déduire des faits qui n’ont jamais été stockés directement

Le raisonnement par sous-classes et propriétés inverses permet de mettre en évidence des types implicites ainsi que des liens inversés.

Problème 5. Un LLM a besoin d’une carte fiable du domaine

Les modèles inventent une structure fluide ; une ontologie fournit une carte vérifiée pour la décomposition, le ancrage et la validation — en particulier en complément de GraphRAG.

Un exemple, cinq couches technologiques

L’histoire du VOO traverse cinq couches : identifiants, triples RDF, schéma RDFS, sémantique OWL et validation SHACL.

Couche 1 : identifiants et noms de domaine

Les IRIs stables évitent les collisions de noms. Un gestionnaire peut être nommé :

https://example.org/finance/Vanguard

Les préfixes permettent de conserver la lisibilité des fichiers :

@prefix fin: <https://example.org/finance/> .

Cela permet d’élargir les noms locaux tels que :

fin:Vanguard

Niveau 2 : RDF représente les faits sous forme de triples

Chaque affirmation est composée de sujet–prédicat–objet :

Subject       Predicate       Object
VOO           managedBy       Vanguard
VOO           tracksIndex     S&P 500 Index

Forme Turtle :

@prefix fin: <https://example.org/finance/> .

fin:VOO fin:managedBy fin:Vanguard ;
        fin:tracksIndex fin:SP500Index .

JSON-LD peut transmettre le même graphe pour les stacks web :

{
  "@context": {
    "fin": "https://example.org/finance/",
    "managedBy": {
      "@id": "fin:managedBy",
      "@type": "@id"
    },
    "tracksIndex": {
      "@id": "fin:tracksIndex",
      "@type": "@id"
    }
  },
  "@id": "fin:VOO",
  "managedBy": "fin:Vanguard",
  "tracksIndex": "fin:SP500Index"
}

Niveau 3 : RDFS introduit un schéma de base

RDFS ajoute des classes, des propriétés, des domaines/ranges ainsi que des liens de sous-classe. Une taxonomie simple de produits :

@prefix fin:  <https://example.org/finance/> .
@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

fin:FinancialProduct a rdfs:Class .
fin:Fund             a rdfs:Class ;
                     rdfs:subClassOf fin:FinancialProduct .
fin:ETF              a rdfs:Class ;
                     rdfs:subClassOf fin:Fund .
fin:AssetManager     a rdfs:Class .
fin:MarketIndex      a rdfs:Class .
fin:managedBy a rdf:Property ;
    rdfs:domain fin:Fund ;
    rdfs:range fin:AssetManager .
fin:tracksIndex a rdf:Property ;
    rdfs:domain fin:ETF ;
    rdfs:range fin:MarketIndex .

Déclaration d’un ETF au sein de cet arbre :

FinancialProduct
└── Fund
    └── ETF

Niveau 4 : OWL ajoute des sémantiques plus riches

OWL permet de définir les inverses, la cardinalité et la disjointibilité. Si managedBy est l’inverse de manages, en stockant une direction, on peut en déduire l’autre :

fin:VOO fin:managedBy fin:Vanguard .

Sketch inverse :

@prefix fin: <https://example.org/finance/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

fin:managedBy a owl:ObjectProperty ;
    owl:inverseOf fin:manages .
fin:ETF owl:disjointWith fin:AssetManager .

Lecture humaine de l’implication :

If VOO is managed by Vanguard,
then Vanguard manages VOO.

Fact avéré :

fin:VOO fin:managedBy fin:Vanguard .

Inversion déduite :

fin:Vanguard fin:manages fin:VOO .

Niveau 5 : SHACL valide les données graphiques

Les formes détectent les erreurs d’instance qui préoccupent les concepteurs d’ontologies en environnement de production. Une description ETF valide :

@prefix fin: <https://example.org/finance/> .
@prefix sh:  <http://www.w3.org/ns/shacl#> .

fin:ETFShape
    a sh:NodeShape ;
    sh:targetClass fin:ETF ;
    sh:property [
        sh:path fin:managedBy ;
        sh:class fin:AssetManager ;
        sh:minCount 1 ;
        sh:maxCount 1
    ] ;

    sh:property [
        sh:path fin:tracksIndex ;
        sh:class fin:MarketIndex ;
        sh:minCount 1
    ] .

Instance valide et compacte :

fin:VOO a fin:ETF ;
    fin:managedBy fin:Vanguard ;
    fin:tracksIndex fin:SP500Index .

fin:Vanguard a fin:AssetManager .
fin:SP500Index a fin:MarketIndex .

Un type de gestionnaire invalide doit entraîner un échec de la validation :

fin:BrokenFund a fin:ETF ;
    fin:managedBy fin:Alice .

fin:Alice a fin:PortfolioManager .

Comment l’inférence crée de nouvelles connaissances

Les chaînes de sous-classes permettent d’élever les instances dans la hiérarchie :

fin:ETF rdfs:subClassOf fin:Fund .
fin:Fund rdfs:subClassOf fin:FinancialProduct .
fin:managedBy rdfs:range fin:AssetManager .
fin:managedBy owl:inverseOf fin:manages .

A partir d’une assertion de type restreinte :

fin:VOO a fin:ETF ;
    fin:managedBy fin:Vanguard .

Les moteurs d’inférence peuvent en déduire des types plus larges :

fin:VOO a fin:Fund .
fin:VOO a fin:FinancialProduct .
fin:Vanguard a fin:AssetManager .
fin:Vanguard fin:manages fin:VOO .

L’inférence comble les lacunes ; SHACL continue de protéger ce que les humains ou les outils d’extraction écrivent.

Questions de compétence : concevoir à partir des questions

Partez des questions auxquelles le système doit répondre — « Quels ETF Vanguard suivent les indices boursiers américains ? » — puis déterminez les types, les propriétés et les contraintes. Cela permet d’associer les ontologies à leur utilisation concrète, et non à une complétude philosophique.

Un flux de travail pratique pour le développement d’ontologies

Domain goals + user questions + source data
                  ↓
       Competency-question generation
                  ↓
       Concept and relationship extraction
                  ↓
         Initial ontology proposal
                  ↓
     Reasoning, SHACL, and query evaluation
                  ↓
       Human review and iterative revision

Itérez : objectifs et questions → modèle conceptuel → ontologie formelle → population du graphe → validation → requête/réflexion → révision.

Esquisse conceptuelle :

ETF ──managedBy──> AssetManager
ETF ──tracksIndex──> MarketIndex

Exemple de requête sous forme SPARQL :

SELECT ?etf
WHERE {
  ?etf a fin:ETF ;
       fin:managedBy fin:Vanguard ;
       fin:tracksIndex fin:SP500Index .
}

Rappel concernant la structure en couches :

RDF stores:
VOO managedBy Vanguard

RDFS understands:
VOO is a Fund, and Vanguard is an AssetManager

OWL can infer:
Vanguard manages VOO

SHACL checks:
Does VOO have exactly one valid AssetManager?
Does it track at least one MarketIndex?

Ce que les LLM peuvent automatiser — et ce qu’ils ne devraient pas décider seuls

Les modèles aident à rédiger des étiquettes, à suggérer des propriétés et à proposer des questions relatives aux compétences. Ils ne devraient pas prendre en charge seuls la gouvernance : les systèmes de types finaux, la cardinalité et les contraintes réglementaires nécessitent des responsables humains et des tests.

Où l’ontologie aide GraphRAG

1. Décomposition de la requête

Les relations typées indiquent aux planificateurs quels sauts sont pertinents.

2. Résolution des entités

Les IRIs partagés et les cartes de synonymes permettent d’unifier « Vanguard » et « The Vanguard Group ».

3. Contrôle de la récupération

Les ancrages et les filtres d’arête surpassent le cosinus pur lorsque les identifiants sont importants.

4. Validation des réponses

SHACL et les vérifications dérivées des schémas rejetent les réponses qui créent des arêtes illégales.

Cinq principes de conception à conserver

Séparer le schéma (ontologie) des données d’instance (graphe).
Concevoir à partir de questions pertinentes, et non de mots à la mode.
Préférer des contraintes petites et testables aux axiomes monolithiques.
Valider lors de l’écriture ; raisonner là où cela en vaut la peine.
Considérer l’aide des LLM comme un soutien à la rédaction sous supervision humaine.

Conclusion

Les ontologies sont des accords pouvant être vérifiés par machine. RDF stocke les faits ; RDFS et OWL ajoutent de la structure et des capacités d’inférence ; SHACL assure la qualité des instances ; GraphRAG utilise ces résultats comme une représentation plus fiable que les vecteurs seuls. L’exemple VOO est délibérément simple : si trois phrases peuvent impliquer cinq niveaux, un véritable catalogue de produits peut en faire autant — une fois que les questions relatives aux compétences et leurs responsables existent.

Tenez un registre de décisions d’une page pour chaque classe et propriété majeure : indiquez pourquoi elle existe, à quelle question de compétence elle répond, et quel schéma SHACL la protège. Les politiques IRI fonctionnent de manière similaire aux versions des routes dans les API ; un renommage sans redirections brise tous les joints GraphRAG ultérieurs. Lorsque des extracteurs proposent de nouveaux arêtes, exigez soit un schéma prédéfini, soit un graphe de sandbox explicite « non restreint », afin que les sorties bruitées des LLM ne contaminent pas le stock géré. Évaluez la valeur de l’ontologie en fonction de la couverture des questions et du taux d’erreur de validation, et non en fonction du nombre d’axiomes. Enfin, associez chaque déploiement en production de GraphRAG à un ensemble de fichiers de configuration contenant des triples légaux et illégaux, afin que les tests CI échouent si une modification de schéma « utile » élargit silencieusement le domaine/de la portée et permet à de mauvais gestionnaires d’accéder à nouveau aux fonds.

Dokumentez les questions de compétence à côté des fichiers SPARQL afin que les modifications de schéma ne s’éloignent pas des demandes auxquelles GraphRAG en production doit encore répondre.

Documenter les questions relatives aux compétences à côté des éléments SPARQL afin que les modifications du schéma ne s’éloignent pas des requêtes auxquelles GraphRAG doit encore répondre en environnement de production.

Documenter les questions relatives aux compétences à côté des éléments SPARQL afin que les modifications du schéma ne s’éloignent pas des demandes auxquelles GraphRAG doit encore répondre en environnement de production.

Tous les articles Envoyer le brief