L’ingénierie de contexte basée sur les ontologies lorsque le RAG vectoriel ne suffit pas.
Lorsque le sens s’étend à des systèmes de données, les embeddings seuls ne permettent pas de réaliser des jointures. L’ingénierie de contexte basée sur les ontologies valide les faits typés, la provenance ainsi que les outils de voisinage pour obtenir des réponses fiables issues de modèles de langage grand public.
Une règle métier est souvent dispersée dans le code et les documents. Une ontologie transforme ces fragments en un parcours navigable pour l’ingénierie contextuelle.
Les gros systèmes hérités — des millions de lignes de code en C et C++, PHP MVC, PL/SQL, ainsi que des centaines de documents non structurés versionnés — rendent inefficace la recherche basée uniquement sur des vecteurs, car le sens est relationnel et lié à un contexte de déploiement spécifique. L’ingénierie contextuelle basée sur des ontologies comble cette lacune : comparez-la à RAG et GraphRAG, examinez les normes RDF/OWL/SKOS/SHACL et autres standards associés, choisissez une solution pragmatique, puis appliquez-la à un véritable système de plusieurs millions de lignes.
1. Le problème : le sens n’est jamais en un seul endroit
Les applications modernes neuves dotées de documents bien organisés ne ressentent pas ce problème. Les systèmes hérités, en revanche, oui. Le sens d’un même concept est fragmenté :
- En C/C++, on montre comment les valeurs sont calculées, mais rarement pourquoi.
Demandez ce qui arrive à une facture lorsque un client modifie son contrat au milieu du mois. La réponse ne se trouve pas dans un seul fichier : elle concerne un module C, des packages PL/SQL, une table, une spécification de 2017 et une note de correction de 2021. Aucun fragment de texte ne contient l’information complète. La réponse existe sous forme de chemin parmi divers artefacts et doit être modélisée avant que l’on puisse confier cette information à un LLM.
2. Qu’est-ce que l’ingénierie de contexte basée sur l’ontologie ?
L’ingénierie du contexte prépare ce que le modèle pourra voir. L’ingénierie du contexte basée sur une ontologie utilise un graphe explicite de types et de relations — modules, paquets, tables, documents, versions, dépréciations — pour sélectionner des artefacts avant que la recherche de similarité ne classe les paragraphes à leur intérieur. Ce graphe indique quels objets et versions sont pris en compte ; les embeddings choisissent ensuite des formulations au sein de cette portée.
Et les embeddings ?
Les embeddings capturent la similarité ; les ontologies captent le sens. Un stockage vectoriel repère des paragraphes qui « ressemblent ». Une ontologie peut enregistrer des relations structurées : quel paquet utilise quelle table, quel moteur invoque ce paquet, quelle édition de la spécification documente la règle, et quelle version indique que le paquet est déprécié. Ce sont des faits. Ces techniques s’associent dans un ordre fixe : les faits déterminent ce que le modèle peut examiner ; la similarité détermine quel paragraphe au sein de cette sélection est pertinent. Cet ordre constitue la conception.
3. Le paysage : RAG, GraphRAG et ontologies
Au lieu de s’engager dans l’utilisation d’ontologies, la plupart des équipes essaient d’abord des sources plus simples. Vector RAG se révèle efficace pour les questions nécessitant une seule étape de recherche et est moins coûteux à mettre en place. Il échoue cependant lorsque les relations et les versions constituent eux-mêmes le sens : quelle spécification de version prend le pas sur une autre, quel paquet implémente quelle règle, quel document reste applicable. GraphRAG ajoute une structure graphique aux données, mais peut encore ne pas modéliser correctement les politiques de versionnement et les relations typées, à moins que le schéma ne soit conçu exprès pour cela. Les ontologies font des types, des prédicats et des contraintes des éléments centraux, permettant ainsi aux requêtes de filtrer en fonction de la version et des relations, plutôt que d’espérer que la proximité entre les éléments suffise à le faire.
Vector RAG n’est pas « mauvais ». Il est simplement incomplet lorsque le sens réside dans des liens et des versions anciennes.
4. Les normes : RDF, OWL et autres
Les termes liés au Web sémantique peuvent sembler complexes ; en réalité, les idées qu’ils représentent sont gérables.
- RDF : des triples
sujet → prédicat → objeten tant que modèle de données (:BillingEngine :appelle :PKG_INVOICE). - RDFS : schéma simplifié — classes, sous-classes, domaines, plages — suffisant pour des ontologies simples.
- OWL : constructions plus riches en logique de description pour l’inférence (disjonction, cardinalité, transitivité, équivalence).
- OWL 2 DL : fragment décidable utilisé par des moteurs d’inférence tels que HermiT ; expressif mais nécessitant une courbe d’apprentissage.
- OWL 2 EL : profil adapté aux grandes ontologies et à l’inférence échelleable (par ex. ELK), au détriment d’une partie de l’expressivité.
- OWL 2 QL : profil destiné à la réponse aux requêtes sur de grandes quantités de données relationnelles.
- SKOS : vocabulaires, synonymes, taxonomies pour les glossaires d’entreprise.
Alors, lequel est le meilleur ?
C’est la mauvaise question. Il s’agit d’une approche par couches de normes. Une stack héritée réaliste comprend : RDF pour les faits, RDFS pour une hiérarchie légère, SKOS pour les termes métier, SHACL pour la validation, SPARQL pour les requêtes, R2RML pour exposer la base de données, et OWL uniquement là où l’inférence est utile (analyse d’impact, liens dérivés, règles de suppression). L’utilisation généralisée d’OWL rend les projets fragiles ; un pragmatisme par couches permet de les maintenir fonctionnels.
Comment choisir : critères de décision
- Besoin d’inférence automatique ? Utilisez RDF/RDFS pour la plupart des faits ; réservez OWL aux cas spécifiques qui bénéficient d’une classification automatisée.
- Besoin de garanties de qualité avec de nombreux contributeurs ? Adoptez SHACL dès le début et validez en continu.
- Où réside la vérité ? Modèles relationnels (Oracle + PL/SQL) → R2RML/OBDA en tant que graphe de connaissances virtuel. Documents → chargement en RDF (éventuellement avec OWL) ou en graphe de propriétés ; rien à virtualiser.
- Besoin d’un glossaire métier ? Les synonymes hérités conviennent parfaitement à SKOS.
- Interopérabilité contre productivité lors de la navigation dans les graphes ? Les graphes partagés à long terme privilégient la pile W3C ; les outils internes nécessitant des algorithmes de graphe peuvent intégrer une projection en graphe de propriétés synchronisée à partir de la source sémantique de vérité.
Où se trouvent les normes
Les artefacts sont du texte. OWL, SKOS, SHACL et R2RML peuvent exister sous forme de fichiers Turtle dans git. Un arbre ontology/ définit ce qui existe — classes, relations, hiérarchie, métadonnées — souvent en utilisant uniquement des déclarations OWL de base ainsi qu’un usage prudent de rdfs:range. N’oubliez pas : une plage n’est pas une contrainte. L’émission de :writesTable vers un élément qui n’est pas une table peut amener le moteur de raisonnement à inférer que la cible est un :DbTable au lieu de la rejeter. Les vérifications réelles d’appartenance relèvent de SHACL. Le choix du profil dépend du moteur qui l’utilise, et non magiquement uniquement du fichier lui-même.
5. Expérience avec une base de code héritée massive
Le système concret comprenait deux millions de lignes de code en C/C++, une couche PHP importante, d’importantes quantités de PL/SQL contenant beaucoup de logique métier, ainsi que des centaines de documents non structurés au fil des versions. Certains documents décrivaient des comportements obsolètes ; d’autres n’étaient valables qu’entre les versions X et Y ; rien ne signalait ce qui était « valable aujourd’hui ».
Qu’a été tenté en premier (et pourquoi cela n’a pas suffi)
Vector RAG appliqué aux codes et documents fragmentés permettait de répondre à des questions simples, mais échouait face aux questions nécessitant une analyse croisée entre différents artefacts ou dépendant de la version — en mélangeant les spécifications v2 et v3 sans règles claires. Naive GraphRAG, ne tenant pas compte des spécificités de version, restituait également des passages contradictoires. Les prompts élaborés manuellement ne permettaient pas une expansion suffisante. Le mode d’échec était constant : similitude sans relations ni contraintes liées aux versions.
L’approche par ontologie
Modèles de modules, de paquets, de tables, de documents, de versions, d’appels, d’écritures, d’implémentations, de remplacements, de critères d’application aux versions et de dépréciations. Collecte des données provenant d’analyseurs et de dictionnaires, validation avec SHACL, stockage de graphes nommés par version, mise à disposition de SPARQL (et d’outils MCP) via un service contextuel qui filtre selon la version de l’utilisateur avant toute étape d’incorporation.
Les douze classes : comment les trouver
Les classes ont été identifiées en analysant les familles d’artefacts, et non en listant tous les noms. Les éléments clés typiques incluent les modules, fonctions, paquets, tables, colonnes, documents, sections, versions, jobs par lots, API, écrans d’interface utilisateur et termes métier (concepts SKOS). Les relations ont été extraites à partir de graphes d’appels, de ALL_DEPENDENCIES / PL/Scope, des routes PHP et des métadonnées de documents. Des ateliers sectoriels ont défini les synonymes, qui ont ensuite été formalisés par SKOS.
Ce que le répertoire crée
Le dépôt d’ontologie contient des fichiers Turtle pour les ontologies, les formes, SKOS, les requêtes et les mappages. L’automatisation de build valide les propositions de modification à l’aide d’échantillons SHACL, de tests de cohérence du moteur de raisonnement et de vérifications de profils. Les collecteurs envoient les faits candidats vers l’étape de préparation ; les formes mettent en quarantaine les violations en générant des rapports. Un magasin de faits accumule les faits acceptés ainsi que les décisions humaines concernant la quarantaine — le seul élément que une reconstruction ne peut pas recréer. Le magasin de triples représente la sortie du processus de build, issue du dépôt, du magasin de faits et du raisonnement. Les systèmes sources restent la source autorisée de la vérité brute ; le dépôt est la source autorisée pour la représentation et la validation.
Les versions virtuelles via R2RML s’attachent à chaque schéma Oracle (chacun étant une version), en écrivant dans les mêmes graphes nommés que les faits collectés, permettant ainsi au service de contexte de fusionner les données par version sans nécessiter de suivi supplémentaire. Les versions obsolètes conservent les faits collectés mais sans version virtuelle active.
Comment le graphe est initialisé
Auparavant, il faut déterminer quel standard représente chaque famille — le contrat pour chaque extracteur. Ensuite, on analyse le code C/C++ (appels, accès aux tables), les dictionnaires Oracle pour PL/SQL, le routage PHP et les dépôts de documents. On y indique l’origine, les dates et les versions détectables. On fait correspondre ces éléments aux termes de l’ontologie, on fusionne les doublons via SKOS, et éventuellement on laisse un LLM proposer des classifications de documents à valider par des humains. Les portes SHACL sont chargées. Les analyses ambiguës (SQL dynamique, pointeurs de fonction) portent des marques de fiabilité et sont considérées comme moins fiables.
Comment le graphe est mis à jour
Les deltas suivent les principes de gouvernance logicielle : proposition → PR sur Turtle → vérifications automatisées SHACL/reasoner/profile → revue → fusion → reconstruction des graphes affectés. Les collecteurs relancent chaque version ; de nouveaux faits sont intégrés en phase de préparation ; le tri en quarantaine distingue les bugs des collecteurs, les corrections de formes/ontologies trop strictes, ou les faits faux qui restent exclus. Les bases de référence initiales nécessitaient de nombreuses itérations — une dizaine de cycles de collecte/ correction sur plusieurs semaines — avec un LLM utilisé uniquement pour regrouper les familles de violations, jamais pour accepter des faits. Les documents restent l’exception, où les modèles proposent du contenu à la révision humaine.
Comment l’LLM l’utilise
Pendant la phase de questions : liens entre entités → parcours du graphe → assemblage du contexte. Associez la question aux entités à l’aide des étiquettes/synonymes SKOS ; exécutez un SPARQL filtré par la version spécifiée par l’utilisateur ainsi que par les graphes partagés (documents filtrés selon :appliesToRelease) ; puis transmettez les faits connectés et les sections exactes au LLM. La recherche vectorielle continue de trouver des paragraphes dans les documents autorisés. Le graphe détermine quels documents et artefacts de code sont pris en compte afin que les versions ne se mélangent pas.
La différence est frappante pour des questions comme celle de savoir quelle spécification régit la facturation proportionnelle dans la version 2022.2. Les vecteurs retournés sont SPEC_INV_V2 et V3 sans indication de validité ; le graphique choisit V3 car il s’applique à 2022.2 et prime sur v2 selon les règles en vigueur, et il désigne PKG_INVOICE comme responsable de la mise en œuvre. Les réponses disposent d’un chemin traçable : module → package → tableau → document → version — ce qui permet aux développeurs de les vérifier, contrairement à un ensemble d’éléments similaires non structurés.
Aperçu du pipeline
- Analyse. Détermination des normes par famille d’artefacts ; création d’une ontologie de base et d’une table de décision en tant que contrats de collecte.
- Collecte. Analyse statique, extraction de données du dictionnaire, chemins PHP, dépôts de documents — chaque fait est accompagné de son origine, de sa date et, le cas échéant, de la version concernée.
Les étapes 1 à 4 relèvent de l’ingénierie des données (l’étape 1 est une décision ; les étapes 2 à 4 font partie du CI à chaque publication). Les étapes 5 à 6 relèvent de l’ingénierie du contexte. L’ontologie constitue le contrat entre ces deux domaines.
Costs et séquencement
Les coûts initiaux de modélisation prennent du temps, mais ils sont inférieurs à ceux d’un ajustement continu de RAG qui ne permet pas d’encoder les versions. La valeur réside dans des pipelines qui maintiennent le graphe à jour, et non dans un fichier Turtle statique. Commencez par un sous-système ; démontrez sa valeur en quelques semaines, puis élargissez progressivement la couverture.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix : <https://example.com/legacy#> .
<https://example.com/legacy> a owl:Ontology ;
owl:versionInfo "1.4.0" .
:CModule a owl:Class ; rdfs:label "C module" .
:PlsqlPackage a owl:Class ; rdfs:label "PL/SQL package" .
:BusinessRule a owl:Class ; rdfs:label "Business rule" .
:DbTable a owl:Class ; rdfs:label "Database table" .
:calls a owl:ObjectProperty . # no range on purpose: a call crosses PHP, C and PL/SQL
:writesTable a owl:ObjectProperty ; rdfs:range :DbTable .
:implementsRule a owl:ObjectProperty ; rdfs:range :BusinessRule .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix : <https://example.com/legacy#> .
# a module that calls a package implementing a rule reaches that rule
:reachesRule a owl:ObjectProperty ;
owl:propertyChainAxiom ( :calls :implementsRule ) .
:implementsRule rdfs:subPropertyOf :reachesRule .
# a specification that supersedes a superseded one supersedes it as well
:supersedes a owl:ObjectProperty , owl:TransitiveProperty .
@prefix : <https://example.com/legacy#> .
@prefix g: <https://example.com/legacy/graph/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
# structural facts, as collected from the sources of release 2022.2
g:R2022_2 {
:BillingEngine a :CModule ;
rdfs:label "Billing engine (C)" ;
:calls :PKG_INVOICE ;
:readsTable :T_CONTRACT .
:PKG_INVOICE a :PlsqlPackage ;
rdfs:label "PKG_INVOICE" ;
:hasProcedure :CALC_PRORATA ;
:writesTable :T_INVOICE ;
:implementsRule :ProRataRule ;
:describedBy :SPEC_INV_V3 .
:CALC_PRORATA a :PlsqlProcedure ;
rdfs:label "CALC_PRORATA" ;
:implementsRule :ProRataRule .
}
# facts that span releases: documents, business rules, lifecycle
g:shared {
:PKG_INVOICE
:deprecatedInRelease :R2024_1 ;
:replacedBy :PKG_INVOICE_V2 .
:SPEC_INV_V3 a :SpecificationDocument ;
:appliesToRelease :R2021_1, :R2022_2 ;
:supersedes :SPEC_INV_V2 .
:ProRataRule a :BusinessRule ;
rdfs:label "Mid-month contract change is invoiced pro rata" .
}
6. Conclusion
- RAG n’est pas mort. Il s’avère insuffisant lorsque le sens se répartit entre du code, des bases de données, des documents et des versions.
- Les ontologies sont pratiques. RDF + RDFS + SKOS + SHACL forment une stack fonctionnelle ; conservez OWL uniquement là où les règles de classification justifient leur complexité.
- Les graphes typés fournissent ce dont ont besoin les assistants de compréhension sémantique. Les modèles linguistiques restent efficaces pour la formulation des phrases ; l’ontologie contrôle quels faits entrent dans le prompt, pour quelle version, avec un parcours auditable.
Cette présentation s’arrête avant d’aborder l’ensemble des aspects de l’ingénierie d’extraction : graphiques fiables issus de C/C++, PL/SQL, ainsi que des documents accumulés au fil des décennies, fournis sans chaos opérationnel — un domaine qui mérite des analyses approfondies dédiées.
Conseils pratiques pour faire face à la production
Nommez les graphes en fonction des versions publiées de manière cohérente dans les collections et R2RML (rr:graph). Ne permettez jamais à la sortie d’un LLM non contrôlé d’écrire des triples. Gardez la structure de quarantaine lisible : nœud, forme, contrainte. Faites des sauvegardes compulsives du stockage de faits. Traitez les profils de raisonneur comme des choix de déploiement testés en CI. Documentez la politique de suppression dans l’ontologie afin que la « spécification la plus récente applicable » puisse être consultée, et non rester une information interne. Évaluez la qualité des réponses à l’aide de questions d’or spécifiques à chaque version qui permettent de résoudre des problèmes que RAG n’a pas pu traiter auparavant.
Lorsque les parties prenantes demandent uniquement des embeddings, montrez une erreur liée à une version mixte côte à côte avec un chemin dans le graphes. L’adoption suit la vérifiabilité. Lorsque les ingénieurs craignent la complexité d’OWL, présentez l’architecture en couches avec OWL en option. Lorsque les équipes opérationnelles craignent l’ajout d’une autre base de données, rappelez-leur que le stockage de triples peut être reconstruit ; le stockage de faits et l’ontologie Git constituent les trésors les plus précieux.
L’ingénierie de contexte basée sur l’ontologie concerne moins les technologies d’intelligence artificielle exotiques et plus la détermination de l’endroit où réside le sens — ainsi que son codage afin que les modèles ne puissent pas mélanger discrètement des périodes incompatibles d’un système.
Notes plus approfondies sur les collecteurs et la confiance
L’analyse statique de C et C++ permet d’identifier les liens de appel ainsi que certains points d’accès aux tableaux ; en revanche, les requêtes SQL générées à l’exécution et les appels indirects via des pointeurs de fonction restent incomplets. L’attribution de scores de confiance permet d’éviter des graphes excessivement optimistes. L’extraction en PL/SQL à l’aide des dictionnaires Oracle fournit plus d’informations sur les dépendances, mais nécessite néanmoins une révision humaine lorsque le SQL dynamique prédomine. Le routage PHP relie les points d’entrée visibles par l’utilisateur aux symboles du backend, permettant ainsi aux questions relatives aux écrans d’être traitées au sein des packages.
Les collecteurs de documents qui n’intègrent que des PDF sans étiquetage de version reproduisent l’échec initial. Préférez des pipelines capables de détecter les plages « applicables à la version » — proposées par heuristique et confirmées par des humains — avant de relier les sections aux paquets.
La quarantaine en tant que fonctionnalité du produit
Une grande quantité de contenu en quarantaine est un signal, pas un scandale. Les bugs des collecteurs, les formes irrégulières et les extractions erronées exigent chacun des responsables différents. Diriger l’aide des LLM vers les familles de violations sort accélère le triage sans accorder d’autorité d’écriture. Une fois la situation de base stabilisée, le volume en quarantaine devrait diminuer ; des pics après une nouvelle version indiquent soit de nouvelles constructions linguistiques, soit des formes qui ont évolué.
Pourquoi les graphes nommés sont importants
En l’absence de graphes nommés, les triples des versions 2019 et 2024 coexistent sans étiquettes et les requêtes ne peuvent pas être ciblées avec précision. Avec des graphes nommés, le service de contexte ajoute un schéma de graphe ou une discipline FROM NAMED liée à la version en cours d’utilisation par l’utilisateur, ainsi que des faits partagés et immuables. Ce mécanisme unique empêche plus efficacement la confusion entre les spécifications SPEC v2/v3 que les avertissements affichés.
MCP et expérience des développeurs
Fournir des enveloppes SPARQL sélectionnées sous forme d’outils MCP permet aux agents de codage de demander « quelle fonction appelle ce package en 2022.2 ? » sans avoir à créer de requêtes SQL pour l’environnement de production. Il convient de garder ces outils en mode lecture seule et paramétrés par la version utilisée. Enregistrez les arguments des outils aux fins d’audit lorsque leurs réponses influencent des modifications en production.
Rapport avec BMAD et spécifications vivantes
Le contexte ontologique complète les cadres de processus qui garantissent la correction du code généré par l’IA : le graphe fournit des faits fiables et versionnés que ces processus peuvent citer. Les spécifications dynamiques deviennent des nœuds liés à des paquets d’implémentation plutôt que des pages wiki orphelines.
Anti-modèles à éviter
- Intégrer des ontologies entières dans les prompts au lieu de les interroger.
- Omettre SHACL parce que « les collecteurs sont fiables ».
- Utiliser la cardinalité OWL partout dès le début.
- Créer uniquement un graphe de propriétés, puis avoir besoin de sémantiques au niveau OWL plus tard sans stratégie de synchronisation.
- Permettre à la recherche vectorielle de fonctionner sans filtrage sur toutes les versions « au cas où ».
Évitez ces pratiques pour que l’architecture reste expliquable tant pour les architectes que pour les développeurs qui doivent vérifier les chemins.
Exemple concret : modification de contrat à mi-mois
Revenons à la question de la facture. Dans le graphe, le nœud du moteur de facturation est lié aux paquets qui calculent les frais proportionnels ; ces paquets écrivent des tables de facturation. Les documents qui :appliesToRelease la version publiée par l’utilisateur et :describes ces paquets sont sélectionnés ; les éditions remplacées sont exclues en vertu de la politique. Le paquet contextuel peut inclure les noms des procédures PL/SQL, les colonnes de table concernées, ainsi que deux paragraphes de la spécification applicable — et non cinq PDFs contradictoires. L’LLM explique ensuite le comportement en utilisant des citations qui correspondent aux arêtes du graphe que les développeurs peuvent cliquer.
Sans le graphe, la recherche renvoie le fragment de PDF le plus proche de « modification du contrat de facturation », souvent une note obsolète. Le modèle semble confiant ; le chemin suivi est cependant impossible à vérifier.
Modèles de conception pour les collecteurs
C/C++ : analyser les unités de traduction en vue des appels et des littéraux de chaîne SQL lorsque c’est possible ; enregistrer l’origine des fichiers et des symboles ; marquer les appels indirects non résolus. PL/SQL : s’appuyer sur les vues de dictionnaire et PL/Scope pour identifier les dépendances ; prendre en compte la granularité des packages/procédures. PHP : associer les routes et les contrôleurs aux symboles d’entrée du backend. Documents : extraire les sections, les titres et les étiquettes de version potentielles ; ne pas valider automatiquement des liens spéculatifs.
Émettre des triples d’origine accompagnant les faits : qui a collecté, quand, depuis quel chemin, à quelle étiquette git de la source. Lorsqu’une quarantaine est déclenchée, l’origine indique quel collecteur ouvrir.
Exemples de formes SHACL en prose
Les schémas pourraient exiger que chaque bord :writesTable cible un :DbTable, que chaque document contienne au moins un élément :appliesToRelease, et que chaque package dispose d’une étiquette non vide. Les violations indiquent le nœud concerné ainsi que la contrainte en cause. Les équipes améliorent progressivement les schémas au fil de leur découverte des particularités du corpus — les assouplissements temporaires passent par la même revue que les classes ontologiques afin que l’historique reste traçable.
Utilisation du raisonneur sans dogme
Mettez en place des vérifications de cohérence sur les PR pour détecter tôt les violations de cohérence. Utilisez avec prudence la matérialisation des calls transitifs ; de gros blocs de données peuvent provoquer une surcharge des bases de données. Préférez les chemins de propriétés au moment de la requête pour certaines traversées. Le profilage (EL vs DL) doit figurer dans la matrice de CI : ce qui est valable avec ELK peut différer des attentes de HermiT — fixez donc la version du moteur.
Projection du graphe de propriétés
Si des algorithmes tels que la détection de communautés aident à regrouper des paquets étroitement liés, projetez périodiquement un graphe de propriétés étiqueté. Conservez le RDF comme source de vérité ; considérez le LPG comme un index dérivé. Documentez le retard de synchronisation afin que personne ne corrige des erreurs d’ontologie sur une projection obsolète.
Files d’examen humain
Les propositions de classification des documents apparaissent sous forme d’éléments dans la file : liens vers des paquets suggérés, plages de versions, types de sections. Les examinateurs acceptent, modifient ou rejettent ; les décisions sont enregistrées dans le stock de faits. Les métriques relatives aux taux d’acceptation aident à déterminer s’il est nécessaire d’améliorer les prompts ou les heuristiques. Ne contournez jamais la file pour des cas « évidents » — c’est ainsi que les erreurs silencieuses se glissent dans le système.
Détails de la couche de service
Le service de contexte authentifie l’utilisateur, détermine sa version en cours d’utilisation, effectue le lien entre les entités (recherche par chaîne de caractères, SKOS altLabels, éventuellement un encodage léger uniquement sur les étiquettes), sélectionne des modèles SPARQL dans queries/, les exécute sur les graphes nommés appropriés, assemble un paquet de tokens limité et le renvoie avec des métadonnées de chemin. Des plafonds stricts imposés aux triples et aux caractères de section empêchent les inondations de requêtes. Les contextes assemblés sont mémorisés temporairement sous la clé (version, ensemble d’entités, modèle de requête) afin de gérer les questions répétées depuis l’IDE.
Aperçus du catalogue d’outils MCP
Exemples : lookup_symbol, list_writers_of_table, governing_specs_for_package, impact_of_deprecating. Chaque outil indique obligatoirement la version utilisée. Les réponses comprennent des URIs ainsi que des étiquettes lisible par l’homme. Les agents enchaînent les outils ; le serveur maintient néanmoins un SPARQL en lecture seule.
Tableau de comparaison sous forme narrative
Vector RAG : peu coûteux, mais faible en termes de gestion des versions. GraphRAG-lite : meilleure structure, mais risque d’émissions mal spécifiées. Ontologie complète + SHACL + graphes nommés : coût de développement élevé, chemins vérifiables, contexte sûr pour les mises à jour. Hybride : portail d’ontologie + vecteurs intégrés dans les documents — généralement la solution gagnante pour les systèmes existants.
Calendrier de gouvernance
Chaque série de mises à jour : exécution des collecteurs, tri et quarantaine, fusion des propositions d’ontologie, reconstruction du stockage de triples, tests sur des questions types, publication du schéma MCP en cas de changement d’outils. Attribution de responsables pour les formes, les collecteurs et les files d’attente des documents. Sans calendrier, le graphe se détériore tout comme le wiki qu’il remplace.
Sécurité et accès
Certains paquets ou documents sont confidentiels. Encodez les autorisations dans le graphe ou filtrez via le service de contexte en fonction des rôles de l’utilisateur. Ne saisissez pas de sous-graphe non restreint dans les demandes destinées à des utilisateurs qui ne peuvent pas lire les fichiers sources.
Exercices de défaillance
Supprimez le stockage de triples en phase de test et reconstruisez-le à partir du repo+stockage de faits pour prouver la capacité de récupération. Restaurez régulièrement les sauvegardes du stockage de faits. Simulez un déploiement défaillant d’un collecteur et assurez-vous que le système de quarantaine l’identifie avant chargement. Ces exercices transforment les diapositives d’architecture en compétences opérationnelles concrètes.
Intégration d’un second sous-système
Copiez la table de décision, n’ajoutez des classes que lorsque les collecteurs en ont besoin, réutilisez les modèles SHACL, et conservez des schémas de concepts SKOS distincts par domaine en cas de conflit de labels. Évitez une seule méga-ontologie qui ralentirait chaque modification ; les importations modulaires avec un vocabulaire supérieur limité s’adaptent mieux.
Métriques importantes
- Taux de précision des questions critiques par version
- Taux de quarantaine par collecteur
- Taille médiane des paquets contextuels
- Part des réponses avec des chemins complets
- Délai entre l’ajout de la version et la mise à jour du graphique
- Délai de révision humaine dans les files d’attente des documents
Préférez ces indicateurs aux simples comptages de triples bruts. Un graphique volumineux et peu fiable est pire qu’un graphique petit mais fiable.
Élargissement de la carte des normes intermédiaires
SKOS ConceptSchemes regroupe les termes professionnels par domaine (facturation, prise en charge, provisionnement). AltLabels recueille les trois noms anciens que tout le monde continue d’utiliser. ExactMatch permet de relier les schémas lorsque des projets d’intégration le requièrent. SHACL peut exiger que les étiquettes de concepts soient disponibles en deux langues si l’organisation est bilingue — ce qui est souvent le cas en Europe.
Les mappages R2RML doivent être examinés comme les vues SQL : une valeur incorrecte de rr:class contamine les inférences de type. Conservez les mappages à côté des migrations de schéma afin que les DBA puissent les voir. Lorsqu’une colonne est supprimée, les mappages ainsi que les axiomes de dépréciation de l’ontologie doivent faire partie de la même version.
Les bibliothèques de requêtes SPARQL situées dans queries/ constituent du code produit. Paramétrisez les URI de version et d’entité. Faites-les examiner par des pairs. Ajoutez des requêtes ASK pour les vérifications de fonctionnement (“ce graphe de version existe-t-il ?”) utilisées par le service contextuel au démarrage.
Pourquoi l’ordre des techniques est-il constamment réaffirmé
Les équipes tentent à plusieurs reprises d’“ajouter un graphe” après l’utilisation d’embeddings sans changer l’ordre récupération-lecture. Si les vecteurs choisissent toujours d’abord des documents parmi toutes les versions, le graphe ne sert qu’à la décoration. Inversez ce processus : travaillez d’abord par graphe, puis effectuez la lecture. Écrivez cette phrase dans le README de l’architecture jusqu’à ce qu’elle soit bien ancrée.
Pont de liaison vers des analyses approfondies d’extraction
Les outils de collecte pour les macros C, le code généré et les encodages multi-octets méritent leurs propres manuels. Il en va de même pour les PDFs traités par OCR et les notes de version scannées. La carte ontologique ci-dessus part du principe que ces outils d’extraction existent ou existeront ; sans eux, le fichier OWL le plus propre ne peut pas générer de faits. Investissez en proportion : clarté du modélisation, réalisme des outils d’extraction et mécanismes de validation.
Élargissement de la description du problème avec des symptômes opérationnels
Lorsque le sens est dispersé, les tickets de support ont tous le même aspect : l’interface affiche un statut, le traitement par lots en montre un autre, et l’entrepôt un troisième. Les ingénieurs ouvrent trois repositories sans pouvoir déterminer quel artefact est fiable pour une journée commerciale donnée. La recherche vectorielle dans ces repositories renvoie des phrases qui semblent pertinentes car elles partagent un vocabulaire avec le ticket, mais les paragraphes obtenus décrivent des flux obsolètes. L’approche basée sur l’ontologie ne unifie pas magiquement les repositories ; elle exige une carte explicite indiquant quelle classe possède quels faits et quel collecteur a le droit de les affirmer.
Les significations dispersées se manifestent également dans le temps d’intégration. Les nouveaux employés passent des semaines à apprendre des cartes internes qui n’existent que dans l’historique des conversations. Un graphique tapé avec des contraintes SHACL devient alors une carte navigable : on part de « Contract », on suit le lien « hasParty » vers « Counterparty », puis « governedBy » vers « PolicyVersion », pour arriver au module de code qui applique cette politique. Ce chemin est auditable. Un score de similarité, lui, ne l’est pas.
Les embeddings revisités avec les modes de défaillance
Les embeddings compressent les co-occurrences locales. Ils sont efficaces lorsque la réponse est un paragraphe qui énonce déjà le fait. Ils échouent lorsque la réponse nécessite une jonction entre différents systèmes : quelle version de politique a été appliquée à quel contrat à quelle date, alors qu’un indicateur de migration n’était que partiellement déployé. Les arêtes du graphe codent ces jonctions. Les embeddings peuvent encore classer les nœuds candidats ou les explications après que le graphe ait réduit l’ensemble des possibilités. Considérer les embeddings comme seul outil de récupération explique pourquoi de nombreuses démonstrations RAG fonctionnent bien sur des corpus de FAQ mais peinent sur les plateformes legacy.
La dimensionnalité et la taille des blocs interagissent avec ces échecs. Les blocs courts améliorent le taux de rappel des mots-clés mais réduisent celui des procédures multi-phrases. Les blocs longs diluent le vecteur avec du texte générique. Aucune de ces configurations ne crée une clé étrangère qui n’existait pas dans le texte. Les collecteurs d’ontologie inventent – ou plutôt déclarent – ces clés à partir de parseurs, de fichiers de configuration et de tables de migration.
GraphRAG comparé sans slogans
Les pipelines de type GraphRAG extraient les entités et les relations du texte pour les intégrer dans un graphe, puis récupèrent des sous-graphes à utiliser comme prompts. Cela est utile lorsque le corpus constitue le système de référence. Dans les systèmes hérités, le système de référence est souvent composé de code, de bases de données et de manuels d’opération. L’extraction de texte seule ne permettra pas de détecter les paramètres par défaut non mentionnés dans la configuration. L’ingénierie de contexte basée sur des ontologies part de l’intention du schéma : il faut d’abord définir les douze classes, puis écrire des outils de collecte qui savent où se trouve chaque prédicat. L’extraction à partir de textes en prose constitue une solution de secours pour les connaissances moins structurées, et non le fondement des contraintes strictes.
Les conceptions hybrides sont valables : utilisez GraphRAG sur les îlots de documentation, des collecteurs d’ontologies sur les noyaux transactionnels, puis unifiez les deux en graphes nommés avec des informations sur leur provenance. La couche de service doit indiquer quels triples proviennent de quelle méthode afin que le modèle préfère les faits issus de collecteurs fiables aux suppositions extraites.
Élargissement du choix des normes
RDF est idéal lorsque vous avez besoin d’identifiants globaux, de SPARQL et d’échanges. Les graphes de propriétés se révèlent utiles lorsque l’expérience d’utilisation lors de la navigation et la familiarité des développeurs sont primordiales. OWL fournit un vocabulaire pour les contraintes et les types inférés ; utilisez un profil réellement pris en charge par votre moteur de raisonnement. JSON-LD constitue un pont pratique pour les API. SHACL valide les données d’instance sans nécessiter de raisonnement complet OWL. Choisissez l’ensemble le plus minimal capable de répondre aux besoins : pouvons-nous valider les données hebdomadairement, interroger des sous-graphes pour générer des prompts, et exporter des données pour les auditeurs ?
Critères de décision en pratique :
- Compétences de l’équipe : qui sait écrire en SPARQL, Cypher ou utiliser des méthodes de parcours personnalisées ?
- Interopérabilité : les partenaires doivent-ils utiliser des fichiers RDF ?
- Rythme de validation : une vérification SHACL nocturne suffit pour de nombreux projets.
- Besoins en inférence : les vérifications dans un monde fermé évitent souvent les surprises liées à OWL dans un monde ouvert.
- Outils : le serveur MCP comprend-il déjà votre système de stockage ?
Le fait que les normes existent importe moins que leur versionnement au sein du répertoire, à côté des outils de collecte. Les écarts entre les fichiers d’ontologie et le code des outils de collecte représentent une panne silencieuse.
Douze classes : script pour l’atelier d’élaboration
Organisez un atelier d’une demi-journée avec les responsables du domaine. Demandez des noms qui apparaissent dans les rapports d’incidents, les listes de contrôle de déploiement et les questionnaires réglementaires. Groupez les doublons. Pour chaque classe restante, demandez : ce qui identifie de manière unique un élément, qui peut le créer, quels prédicats doivent toujours exister, et quels systèmes le modifient. Douze n’est pas un chiffre magique ; c’est une taille adaptée à la mémoire de travail. Si vous en découvrez trente, regroupez-les en contextes définis et créez des graphes fédérés plutôt que de tout fusionner en un seul ensemble.
Dokumentez chaque classe avec : étiquette préférée, étiquettes alternatives, politique d’identification, états du cycle de vie et propriétaire collecteur. Sans propriétaire, le graphique se détériore.
Structure du répertoire qui reste facile à maintenir
Séparez les modules d’ontologie, les paquets de collecte, les tâches de validation, l’API de service et les modèles de prompts. Gardez les triples générés hors de git ; conservez les formes et les fixtures dans git. Le CI doit échouer lorsque SHACL ne fonctionne pas avec des fixtures de référence. Étiquetez les versions d’ontologie selon le format semver, même si les triples sont éphémères, car les modèles de prompts fixent les noms de prédicats.
Décryptage approfondi de l’initialisation
Ordre de démarrage : charger TBox (classes et propriétés), charger les individus de référence qui ne proviennent jamais des collecteurs (par exemple, les noms d’environnements canoniques), exécuter les collecteurs pour les données à changement lent, puis ceux pour les données transactionnelles rapides, ensuite SHACL, enfin publier un identifiant de snapshot pour le graphe nommé. Le LLM ne lit jamais une HEAD en mouvement sans un point de référence de snapshot ; la reproductibilité prime sur l’apparence de fraîcheur.
Décryptage approfondi de la mise à jour
Préférez des collecteurs incrémentaux identifiés par des marques d’eau. Lors d’un changement de schéma, migrez d’abord les formes, puis les collecteurs, et enfin complétez le reste. Mettez en quarantaine les triples qui ne respectent pas les formes au lieu de les supprimer silencieusement. Émettez des métriques : triples ajoutés, mis en quarantaine, violations de formes par classe. Informez les humains lorsque le taux de quarantaine augmente après un déploiement.
Décryptage approfondi de l’utilisation des LLM
Plan de récupération : résolvez les entités présentes dans le texte de l’utilisateur à l’aide d’un NER restreint par rapport à des IRIs connus, élargissez le voisinage en utilisant des limites de saut et des listes d’autorisation de prédicats, serializez les résultats en un tableau Turtle compact ou en markdown, ajoutez des informations sur l’origine et le degré de confiance, puis appelez le modèle à l’aide d’outils capables d’exécuter un saut supplémentaire sur demande. Interdisez l’utilisation de SPARQL libre dans le modèle en production tant qu’une étape d’évaluation n’existe pas ; proposez plutôt des outils paramétrés.
Détail des étapes du pipeline
- Ingérer l’événement ou planifier un déclenchement.
- Le collecteur récupère les données et les normalise.
En sautant n’importe quelle étape, vous reconstruisez une démonstration RAG fragile.
Réalisme de la séquenciation des coûts
Les coûts liés aux utilisateurs dominent. Commencez par trois catégories qui posent le plus de problèmes. Automatisez leurs collecteurs. Mesurez le déviation des tickets et les taux de réponses incorrectes. Étendez la couverture des catégories uniquement lorsque les délais de réponse et les validations restent satisfaisants. Les dépenses en GPU pour les embeddings sont généralement inférieures aux semaines passées par les ingénieurs à débattre de synonymes sans fichier de vocabulaire.
Conseils pratiques pour survivre en production
Indiquer les identifiants des captures d’écran dans les prompts en cas d’incident. Enregistrer l’hash du sous-graphe avec chaque réponse du modèle. Fournir un panneau « Pourquoi ce contexte » pour les utilisateurs internes. Traiter les demandes de modification d’ontologie comme des demandes API : reviewers, notes de compatibilité et périodes de désactivation pour les prédicats obsolètes.
Collecteurs et évaluation de la confiance
La confiance n’est pas une impression subjective. La déduire de la priorité des sources (base de données principale > cache secondaire > wiki), du niveau de fraîcheur et de la certitude de la parsing. Multiplier soigneusement les scores ; ne pas annuler l’effet d’un signal faible et critique par une moyenne. Fournir la confiance au modèle sous forme de métadonnées structurées, et non comme une série d’adjectifs dans le prompt.
Expérience utilisateur pour la quarantaine
La quarantaine est un produit. Afficher les triples en attente, les formes défaillantes, les propriétaires suggérés, ainsi que des liens pour valider ou corriger en un clic. Sans une bonne expérience utilisateur, la quarantaine devient un tiroir à ordures et la confiance s’effondre.
Graphes nommés en tant que contrats
Chaque collecteur écrit dans son graphe nommé. La vue de fusion est un graphe de graphes doté de politiques explicites. Le retrait signifie la suppression d’une version de graphe nommé, et non une archéologie dans un dump monolithique de triple store.
Ergonomie MCP
Les outils doivent refléter des classes telles que getContract, listPoliciesForContract et getDeploymentAffecting. Les arguments sont des IRIs ou des clés métier résolubles en IRIs. Les réponses ne contiennent que des prédicats autorisés. Les délais d’attente et les limites de taille en octets protègent la fenêtre de contexte.
Spécifications vivantes
Les classes ontologiques doivent être en adéquation avec les ADR et les spécifications vivantes. Lorsqu’une spécification modifie une règle, la structure ainsi que les tests du collecteur évoluent dans la même demande de pull request. Les assistants qui lisent à la fois le graphe et la spécification réduisent les conflits entre « documentation » et « code ».
Anti-modèles développés
- Une seule classe géante « Thing » avec des propriétés libres.
Récit d’un exemple concret
Au milieu du mois, les conditions de paiement d’un contrat changent. Le responsable des contrats voit une nouvelle ligne de version. Les entités nécessitent les champs effectiveFrom et approvedBy. La mise à jour est stockée dans le graphe dédié aux contrats. Une question de support demande quels termes s’appliquent le lendemain. La résolution des entités identifie l’IRI du contrat, la récupération du voisinage renvoie les deux versions avec leurs dates respectives, le prompt ne comprend que la version applicable ainsi que l’origine du changement, et la réponse cite l’ID d’approbation. Le RAG vectoriel seul pourrait récupérer le fragment PDF ancien encore présent dans la wiki.
Modèles de collecteurs
Les téléchargements JDBC marqués d’une watermark, les outils d’analyse de l’arborescence Git pour la configuration, les outils d’analyse OpenAPI pour les cartes de services, les collecteurs d’étiquettes de métriques en temps réel, ainsi que les téléversements CSV manuels pour gérer les exceptions. Chaque modèle nécessite des clés idempotentes et un mécanisme de gestion des messages non traités.
SHACL en langage opérationnel
Les règles définissent : chaque Contrat doit avoir exactement un statut actuel issu d’un enum ; chaque PolicyVersion doit faire référence à un hash binaire ; chaque Déploiement doit citer un Service. Les violations se traduisent par des tickets actionnables, et non par du bruit dans les journaux.
Raisonneurs
Utilisez la classification lorsque cela permet d’éliminer les étiquetages manuels redondants. Évitez les inférences complexes dans un monde ouvert qui inventent des entités inconnues. Préférez les règles SPARQL ou SHACL-SPARQL pour la gestion interne dans un monde fermé, si OWL surprend vos opérateurs.
Projection du graphique de propriétés
Si les développeurs pensent en termes de chemins, exportez le RDF vers un graphique de propriétés chaque nuit afin d’en explorer le contenu, tout en conservant le RDF comme source d’échange et de validation. Documentez quels prédicats deviennent des arêtes et lesquels restent des propriétés.
Files d’attente pour révision humaine
Certains prédicats nécessitent toujours une intervention humaine : étiquettes d’interprétation juridique, indicateurs d’exception et fusion de parties dupliquées. Créez des files d’attente avec des SLA. Le graphique n’est pas complet tant que ces files ne sont pas vides ou qu’une exemption explicite n’a pas été accordée.
Couche de service
Mémorisez les sérialisations des voisins en fonction de (iri, snapshot, hop, hash de la liste autorisée). Comprimez les données pour des réponses rapides. Supprimez les préfixes inutilisés. Proposez à la fois des profils de débogage détaillés et des profils compacts pour le fonctionnement en production.
Esquisses de catalogue d’outils
- resolve_entity(text, class_hint)
- get_neighborhood(iri, hops, predicates)
- diff_snapshots(id_a, id_b, class)
- list_quarantine(class, since)
Chaque outil renvoie un JSON indiquant sa provenance.
Comparaison narrative des options
RAG vectoriel pur : rapide à démontrer, mais faible pour les jointures. Document GraphRAG : meilleure capacité à relier les entités dans les domaines riches en prose. Collecteurs d’ontologies : idéaux lorsque les systèmes de données sont structurés et que le sens est transversal. La plupart des équipes matures utilisent une combinaison avec des priorités clairement définies.
Calendrier de gouvernance
Triage hebdomadaire des données, révision mensuelle du vocabulaire, ateliers trimestriels sur les classes, ainsi que notes de version pour l’ontologie. Planifiez ces dates dans un calendrier géré par une personne désignée à ce titre.
Sécurité
Les entrepôts de triples contiennent des informations sensibles sur les relations commerciales. Appliquez des ACL par graphe désigné, masquez les données dans les profils de service, et n’insérez jamais de secrets dans les prompts. Auditez les appels aux outils.
Exercices de simulation d’échecs
Brisez délibérément un collecteur en phase de test. Vérifiez que la quarantaine s’active, que les services continuent de fonctionner sur le dernier snapshot fiable, et que des alertes sont déclenchées. Pratiquez la restauration. Si l’exercice est effrayant, la situation en production sera encore pire.
Intégration du deuxième sous-système
Copiez le modèle de collecteur, enregistrez un nouveau graphique nommé, ajoutez des formes, insérez trois questions clés, et effectuez une écriture parallèle pendant une semaine avant de transférer progressivement les assistants. Évitez d’intégrer plusieurs sous-systèmes en même temps.
Métriques qui orientent réellement
Taux d’erreurs sur l’ensemble de questions clés, nombre moyen d’étapes parcourues, taux de quarantaine, retard du collecteur, âge du snapshot au moment de la réponse, et taux d’intervention humaine. Les métriques superficielles comme le comptage triple induisent en erreur.
Synthèse finale sans slogans
L’ingénierie de contexte basée sur l’ontologie est une méthode structurée d’assemblage de contexte : entités typées, faits validés, provenance, ainsi que des outils permettant de récupérer uniquement les éléments nécessaires pour obtenir une réponse fondée. Les embeddings restent utiles au sein de cette approche. Ils ne remplacent pas la connaissance du système qui détient telle ou telle signification.