Ontology-Based Context Engineering: When RAG Is Not Enough

Résumé

Cet article vient d’un vrai système legacy: plus de deux millions de lignes de C et de C++, une couche PHP et PL/SQL importante, et des centaines de documents répartis sur des releases qui se contredisent. J’y avais passé des semaines à régler des pipelines de retrieval. La recherche vectorielle renvoyait des passages qui se ressemblaient, pris dans des releases différentes de la même spécification, et le modèle les fondait en des réponses qui avaient l’air justes sans l’être. Le déclic a été d’accepter que le problème n’était pas le retrieval, mais la représentation.

Le context engineering fondé sur une ontologie consiste à construire une carte du domaine lisible par la machine avant de donner quoi que ce soit au modèle, puis à s’en servir pour décider ce que le modèle a le droit de voir. Les embeddings capturent la similarité; une ontologie capture le sens. Les faits du graphe sélectionnent les artefacts, les documents et la release; la recherche par similarité trouve ensuite le bon passage dans cette sélection. Les deux techniques servent, et toute la conception tient dans cet ordre.

L’ontologie à laquelle je suis arrivé est petite: une douzaine de classes et dix relations, des modules C et des packages PL/SQL jusqu’aux documents de spécification et aux règles métier, avec un graphe nommé par release pour qu’un raisonneur ne mélange jamais les faits de deux versions. Quelques centaines de lignes de Turtle écrites à la main; des collecteurs déterministes ont produit le reste, une barrière SHACL a mis en quarantaine ce qui ne validait pas, et chaque changement passe par une pull request, comme du code.

Le RAG n’est pas mort, il est seulement insuffisant quand le sens d’un système est éclaté entre le code, la base, les documents et les releases. RDF, RDFS, SKOS et SHACL forment une pile pragmatique, OWL restant réservé aux endroits où l’inférence paie. La modélisation initiale a coûté du temps, bien moins que celui perdu sur des pipelines qui ne pouvaient pas fonctionner, et chaque réponse arrive désormais avec un chemin qu’un développeur peut vérifier.

Idées clés

• Les embeddings capturent la similarité, les ontologies capturent le sens: le graphe décide quels artefacts et quelle release sont sur la table, la recherche par similarité trouve le passage.
• Le sens d’un système legacy n’est jamais à un seul endroit: une question sur une facture traverse un module C, des packages PL/SQL, une table et deux spécifications contradictoires.
• Garder l’ontologie petite et la traiter comme du code: une douzaine de classes, dix relations, des fichiers Turtle dans Git, une validation SHACL et des pull requests.
• Un graphe nommé par release, pour qu’un raisonneur ne mélange jamais les faits de 2022 avec ceux de 2024.
• Commencer par un seul sous-système: la valeur se prouve en quelques semaines, et l’ontologie grandit ensuite.

Pourquoi j’ai écrit cet article