Correction du RAG à l’aide d’une ontologie et d’un graphe de connaissances dans les documents de semi-conducteurs
Les documents d’EDA pour les semi-conducteurs disposent désormais d’une ontologie RDF/OWL, d’un graphe de connaissances Neo4j ainsi que d’un système de recherche contraint par l’ontologie, ce qui réduit de 30 pour cent les questions supplémentaires générées par le RAG.
Sources: How I Built a Semantic Layer to Ground Our RAG System…And Why Ontology Was the Missing Piece
Où le RAG classique échoue
Un premier prototype de génération augmentée par récupération de données sur des documents de produit semble généralement prometteur. Un stockage vectoriel est utilisé, les documents sont divisés en blocs, quelques requêtes sont exécutées, et les réponses semblent plausibles. Puis un ingénieur en vérification demande quelle méthode utiliser pour une vérification adaptée aux contraintes énergétiques sur un bloc donné, et le système répond, avec une confiance totale, en mentionnant une méthode de vérification fonctionnelle. Le contenu est exact selon ses propres critères, mais incorrect pour la question posée.
La cause réside dans le vocabulaire. En vérification de semi-conducteurs, le terme « méthodologie » n’est pas courant. Il désigne des approches de vérification spécifiques, chacune liée à des outils, des étapes et des artefacts d’exécution particuliers. Le pipeline a récupéré du texte mais pas des connaissances. Il s’agit donc d’un problème de sens et non d’un problème de récupération, et un meilleur modèle d’embedding ne le résoudrait pas. Une couche sémantique, en revanche, le fait. Ce qui suit décrit comment une telle couche est conçue et construite pour un ensemble de documentation EDA : l’ontologie, le graphe de connaissances, la connexion au RAG, ainsi que les résultats mesurés.
La documentation en tant que désert du savoir
Il s’agit d’un logiciel de vérification d’entreprise, comprenant des milliers de sujets XML DITA répartis sur plusieurs lignes de produits, couvrant la configuration des outils, les workflows d’exécution et les directives méthodologiques. Ces documents existent, mais sous forme de texte brut plutôt que de connaissances structurées. Les étapes de vérification, les méthodologies et les outils se trouvent dans des documents séparés et ne sont reliés entre eux que par ce que le lecteur connaît déjà. Un ingénieur expérimenté disposant de dix ans d’expérience dans ce domaine s’en sort facilement. Un LLM cherchant le bon fragment se retrouve face à un véritable champ de mines.
L’objectif était de trouver une solution répondant simultanément à plusieurs besoins : RAG, recherche d’entreprise, découverte de contenu et gouvernance à long terme du contenu.
Comprendre d’abord le problème
Des semaines de discussions ont précédé la rédaction du moindre code d’ontologie, avec les chefs de produit, les experts en vérification, les responsables de la documentation, les ingénieurs en recherche et l’équipe de science des données derrière l’assistant GenAI. Trois questions ont guidé ces échanges.
Premièrement, quels sont les résultats commerciaux importants ? Les réponses étaient une plus grande précision de recherche, une couche de référence canonique pour les assistants LLM et des données unifiées entre les différentes lignes de produits. Deuxièmement, à quoi ressemble aujourd’hui l’échec ? La recherche par mots-clés affiche des résultats irrelevants, les utilisateurs envoient des requêtes supplémentaires car la première réponse manque de contexte, et le lien manuel des contenus ne suffit pas. Troisièmement, à quoi ressemblerait le succès ? Le système de récupération devrait comprendre qu’une requête concernant la vérification dynamique de conceptions gérées électroniquement nécessite des contenus liés à une méthode précise, à une étape de vérification donnée, utilisant des outils spécifiques, et non simplement n’importe quel document contenant ces mots-clés.
Ces bases permettent d’éviter l’enflure de l’ontologie, c’est-à-dire la tendance à modéliser tout ce qui semble intellectuellement intéressant plutôt que ce dont l’entreprise a réellement besoin.
Découverte des concepts et conception de l’ontologie
La conception de l’ontologie commence par la découverte des connaissances, et non avec Protégé ou un fichier Turtle. Quatre sources d’information y contribuent :
- Des entretiens avec des ingénieurs de vérification, qui ont décrit leur façon de concevoir les relations entre outils, l’ordre d’exécution et les points de décision, ce qui diffère de la manière dont fonctionnent réellement ces outils
- La documentation existante et les interfaces des outils, dont les termes récurrents ont révélé des concepts restés stables pendant des années
- Les journaux d’activité, les fichiers de configuration et les définitions des pipelines, qui montrent les véritables liens entre outils, étapes et résultats, et qui contredisent souvent la documentation
Le résultat a été un ensemble de concepts de domaine stables, en quelque sorte une taxinomie, qui a d’abord été consigné intentionnellement dans Excel. Le travail d’ontologie est collaboratif, et les personnes qui doivent vérifier le modèle — des experts du domaine et des gestionnaires de produit — ne lisent pas Turtle. Un tableau de calcul leur permet de le valider et de le perfectionner, ainsi que de créer une compréhension commune, bien avant que l’encodage formel ne commence.
Lorsque le modèle a été affiné au cours de plusieurs rounds d’examen, il a été formalisé à l’aide des normes du web sémantique :
- RDF exprime chaque entité et relation sous forme de triples
- OWL fournit des hiérarchies de classes, des contraintes de propriétés et des règles logiques
- SKOS standardise la terminologie entre les différentes lignes de produits grâce à des vocabulaires contrôlés
- Schematron vérifie l’utilisation correcte de l’ontologie lors de la création dans Oxygen XML
L’ontologie elle-même est stockée dans des fichiers TTL, tandis que les règles Schematron s’intègrent directement dans l’environnement de création. Ainsi, les auteurs ne peuvent pas introduire de concepts qui viendraient contredire l’ontologie, ce qui fait que la gouvernance fait partie intégrante du flux de travail et n’est pas une considération ultérieure. Chaque mise en correspondance est garantie par des métadonnées Prolog dans le XML DITA et par des vocabulaires contrôlés, sans utilisation de balises libres ni de solutions approximatives.
L’architecture du graphe de connaissances
L’ontologie a besoin d’un endroit où être stockée, un graphe qui puisse être consulté et parcouru. La conception se divise en plusieurs couches :
- Couche de schéma : définitions de l’ontologie dans des fichiers TTL
- Couche de terminologie : vocabulaire basé sur SKOS
- Couche d’instances : triples RDF générés à partir des métadonnées du contenu
- Couche d’infrastructure : Neo4j pour le stockage et les requêtes
Au sein de ces couches se trouvent des pipelines d’ingestion sémantique qui transforment le contenu créé en triples prêts à être intégrés dans un graphe et les chargent dans Neo4j, ainsi que des API de requête et de récupération qui mettent ce graphe à la disposition des utilisateurs, comme le pipeline RAG, et une infrastructure cloud Azure assurant l’échelle et l’intégration avec les services de plateforme existants.
Le pipeline allant de la création du contenu au graphe est ce qui fait de ce système bien plus qu’un simple exercice d’ontologie. Les auteurs écrivent en DITA au sein d’Oxygen XML. Schematron vérifie que les métadonnées respectent les exigences de l’ontologie au fur et à mesure de la saisie. Le contenu est publié via Adobe Experience Manager. Les métadonnées sémantiques restent intactes tout au long de ce processus et sont ingérées dans Neo4j, où les systèmes de recherche, d’analyse et d’intelligence artificielle peuvent les interroger. Il s’agit donc d’une gestion architecturale complète du flux de données, depuis l’outil de création jusqu’au graphe en passant par la couche API.
Intégration de la couche sémantique dans RAG
C’est ici que les efforts portent leurs fruits. Le RAG standard fragmente les documents, incorpore ces fragments, les stocke dans une base de données vectorielle, effectue des recherches par similarité et transmet les résultats à un LLM. Cette méthode fonctionne, mais elle est aveugle au sens, et trois modes de défaillance reviennent constamment :
- Confusion du contexte, où la recherche trouve le bon concept dans le mauvais contexte, comme cela a été décrit précédemment pour l’inadéquation de l’étape de vérification
- Désaccord de vocabulaire, où les ingénieurs utilisent des abréviations tandis que la documentation emploie des termes formels, ce qui fait que du contenu pertinent est manqué
- Hallucinations dues à l’ambiguïté, où des termes peu clairs dans un fragment permettent à l’LLM de combler les lacunes avec des connaissances pertinentes mais fausses dans le domaine
Avec le graphe de connaissances en tant que couche de référence, la recherche évolue de quatre manières.
Les règles de l’ontologie restreignent ce qui est récupéré. Lorsqu’une requête mentionne une méthode de vérification, la récupération commence par interpréter ce terme à l’aide de l’ontologie, puis limite la recherche aux contenus marqués avec cette méthode et ses relations valides. La recherche vectorielle se poursuit, mais sur un sous-ensemble filtré sémantiquement.
Un vocabulaire canonique est imposé. Les requêtes des utilisateurs sont d’abord mappées sur des termes contrôlés avant la récupération, de sorte que « power-aware sim » se traduit par le terme formel pour la simulation sensible à l’énergie, et le contenu approprié est retourné quel que soit la manière dont l’ingénieur a formulé sa question.
Les segments suivent les limites de l’ontologie plutôt qu’une taille fixe. Un passage concernant le rôle d’un outil dans une étape de vérification reste complet et n’est pas coupé au milieu d’un concept.
Les combinaisons invalides sont filtrées. L’ontologie indique quelles combinaisons d’outils, de méthodologies et d’étapes sont valables, de sorte que tout fragment impliquant une combinaison invalide est dégradé ou supprimé avant que le LLM ne le voie.
Les avantages se sont manifestés directement. Les réponses s’appuient sur du contenu vérifié et marqué par l’ontologie, plutôt que sur les suppositions du modèle concernant la vérification des semi-conducteurs. En restreignant ce que le modèle peut voir, on élimine une catégorie d’hallucinations causées par des recherches ambiguës ou dépourvues de contexte. Chaque fragment récupéré contient des métadonnées ontologiques, permettant ainsi au système d’expliquer son choix : quelle entité, quelle relation, quelle contrainte. De plus, les workflows agents peuvent parcourir le graphe pour planifier des tâches de vérification en plusieurs étapes en se basant sur des relations réelles entre entités, et non seulement sur la similarité textuelle.
Le stack technologique
- Création de contenu : Oxygen XML avec DITA
- Validation et gouvernance : Schematron et Schematron Quick Fix
- Encodage des ontologies : RDF, OWL et SKOS dans des fichiers Turtle
- Graphes de connaissances : Neo4j
- Publication : Adobe Experience Manager
- Cloud : Microsoft Azure
- Intégration RAG : API de recherche personnalisées combinant Neo4j et la recherche vectorielle
- Couche LLM : un assistant GenAI d’entreprise propriétaire
Résultats
Quatre indicateurs ont permis d’évaluer les performances après déploiement :
- Les requêtes ultérieures ont diminué de 30 %. La documentation sert désormais de référence fiable pour les assistants IA, permettant aux utilisateurs d’obtenir la bonne réponse dès la première tentative bien plus souvent. Cet indicateur était crucial car il reflète directement la qualité de la recherche.
- La réutilisation du contenu a augmenté de 25 %. Grâce aux balises sémantiques et à la compréhension des relations, le même contenu peut être utilisé dans plusieurs lignes de produits sans avoir à le copier manuellement.
- Le temps consacré aux liens manuels a été réduit de 60 %. Les fonctionnalités de contenu lié d’AEM fonctionnent désormais sur le graphe, de sorte que les liens autrefois créés manuellement sont générés à partir de relations ontologiques. Le service autonome pour les utilisateurs s’est également amélioré de 25 %.
- Les cycles d’audit du contenu manuel ont été raccourcis de 40 %. Les règles Schematron dérivées de l’ontologie détectent les problèmes dans Oxygen pendant que les auteurs travaillent, ce qui permet d’améliorer la qualité dès le début du processus.
Leçons pour des projets similaires
Modélisez le domaine avant de choisir la technologie. Les équipes ont souvent tendance à opter pour Neo4j ou une base de données vectorielle avant même d’avoir défini clairement leurs entités et leurs relations. C’est comme construire une maison avant d’avoir dessiné son plan. Consacrez du temps au début avec des experts du domaine dans un tableur. Cela manque peut-être de glamour, mais c’est là que réside la véritable valeur.
Considérez la gouvernance comme une structure. Une ontologie sans gouvernance se dégrade rapidement, car chaque nouvel auteur, produit ou cas particulier érode la cohérence. Intégrez la validation dans le flux de travail d’élaboration afin qu’elle se produise automatiquement, plutôt que par le biais d’audits périodiques qui arrivent toujours en retard.
RAG sans sémantique, c’est une recherche avec des étapes supplémentaires. La similarité vectorielle est nécessaire, mais elle est insuffisante pour la récupération d’informations au niveau enterprise. Lorsqu’un domaine présente des relations structurées, des hiérarchies et des contraintes, comme c’est le cas pour la plupart des domaines enterprise, une couche sémantique permet de passer de la recherche de textes similaires à celle de connaissances pertinentes.
Mesurez ce qui importe pour l’entreprise. « Nous avons créé un graphe de connaissances » n’est pas un résultat commercial. En revanche, « Les requêtes de suivi ont diminué de 30 % grâce à une recherche plus précise » l’est. Chaque choix architectural doit être lié à une métrique qui a de la valeur pour les personnes extérieures à l’équipe.
Que vient ensuite ?
La couche sémantique est la base, et non la limite. L’ontologie continue d’évoluer, avec de nouveaux concepts testés, validés et intégrés sans perturber les sémantiques existantes, et les progrès dans les outils d’LLM, la convergence entre graphes et intelligence artificielle ainsi que l’architecture agente peuvent s’appuyer sur elle. La leçon générale est que, dans la course vers la GenAI, l’investissement le plus sous-estimé n’est pas un modèle amélioré ou une fenêtre de contexte plus large. C’est une base sémantique plus solide. Les modèles viennent et partent, tandis que le sens persiste.
Lectures complémentaires
- Pourquoi les agents d’analyse IA ont besoin d’une couche sémantique plutôt que de SQL brut — La conversion texte en SQL sur des tables de entrepôt brutes invente des métriques et ignore les règles d’accès. Découvrez comment une couche sémantique comme Cube, associée à MCP, confère aux agents un sens métier structuré.
- De la version naïve à un pipeline RAG opérationnel pour les déclarations SEC 10-K : segmentation en blocs, recherche hybride — Pourquoi un pipeline RAG classique a échoué avec des documents de 300 pages, et les solutions : segmentation en blocs tenant compte des sections, recherche hybride, réclassement par encodage croisé, validation et citations de métadonnées.