Qualité logicielle et qualité ontologique
Dans cet article je vais un peu plus développer les meilleures pratiques liées à la validation d’un développement ontologique. Non du côté logique formelle, ce qui a été abordé dans un autre article, avec les raisonneurs, mais avec le parti pris de l’assurance qualité de l’ingénierie logicielle. Précédemment, il s’agissait de vérifier la cohérence logique de la construction des concepts et de leurs liens. Il y avait également une approche d’architecture pour structurer l’ontologie de façon à ce qu’elle soit réutilisable, évolutive, maintenable et réutilise elle-même les bonnes pratiques de conception, ou les standards éprouvés.
La question fondamentale pour toute construction d’une ontologie est pourquoi la construire ? A quels besoins d’explicitation et de partage des connaissances correspond-t-elle, pour qui, sur quelle période et comment va-t-on l’utiliser ? Le choix d’une ontologie par rapport à une autre approche est déjà un implicite. Il y a besoin d’un vocabulaire qui clarifie les concepts de manière explicite, pour éviter les ambiguïtés et qui est compréhensible par les machines, pour faire des liens entre des données hétérogènes provenant de sources variées qui seront qualifiées par des métadonnées pour pouvoir les associer ou réconcilier, ou pour faire des inférences logiques. Ce pourquoi les ontologies ont d’abord été proposées dans le cadre des Systèmes d’information pour résoudre des problématiques d’intégration. Il y a d’autres usages que je décrirai avec des exemples concrets et récents dans un prochain article.
Cela étant dit, ce que je viens de décrire sont des exigences non fonctionnelles associées à l’architecture du système qu’on veut construire. Une ontologie est aussi et surtout, une spécification exécutable formalisant clairement et sans ambigüité des exigences fonctionnelles. Ces exigences portent sur la connaissance qu’on veut représenter et interroger. Mais comment valider qu’une ontologie est une « bonne » ontologie au regard des besoins qualifiés?
Précision et couverture à quoi reconnaître une bonne ontologie ?
Évaluer la qualité d’un Knowledge Graph commence par cette question : comment reconnaître une bonne ontologie ? Ainsi que l’explique C.Maria Keet dans [1] l’interaction entre la précision et la couverture « concerne à la fois le langage que l’on utilise pour l’ontologie et une bonne modélisation. »
Au-delà de l’aspect logique de la description choisie, la représentation, pour être de qualité, doit se faire au juste nécessaire. C.Maria Keet écrit à ce propos [1], “Tout comme on peut écrire du bon et du mauvais code, on peut avoir de bonnes et de mauvaises ontologies. Leur qualité, ou leur défaut, est cependant un peu plus complexe qu’avec le code logiciel.[…] Avec l’interaction entre la logique que l’on utilise pour représenter la connaissance dans une ontologie et la signification des entités dans le domaine sujet, nous pouvons montrer schématiquement une notion de bonnes et de mauvaises ontologies. » (traduction libre].
De mauvaises ontologies seront à côté de la réalité que l’on souhaite décrire, faute d’une bonne correspondance du modèle conçu avec cette dernière, ou seront peut-être restreintes par le langage utilisé.
Si on peut vérifier quasi automatiquement la cohérence de la logique, la validité de la signification des entités dans le domaine sujet est plus complexe. On peut avoir une ontologie logiquement cohérente qui décrit un monde irréel. Pourquoi pas, s’il s’agit d’une ontologie de films de super héros qui contient une classification de pouvoirs fantastiques. Dans la réalité de domaines d’ingénierie complexes, où la conception de l’ontologie doit permettre de faire des diagnostics fiables ou d’avoir des réponses pertinentes à des questions spécifiques, la précision et la couverture exacte sont essentielles. La validation requiert à la fois de l’expertise du domaine et de la modélisation.
Competency Questions (CQs) et ontologie : élicitation et spécificité
La première étape permettant la démarche de validation d’une ontologie est de faire exprimer, en langage naturel, par les experts, les questions de compétences (Competency Questions, CQ), point de départ de l’élicitation des exigences ontologiques. Elles aident à définir les capacités de « connaissance » du système que l’on veut construire avec l’ontologie. Puisque ce système devra permettre d’y répondre avec plus ou moins de précision, selon l’usage fonctionnel souhaité. Une même question peut conduire à des granularités de concept et des explorations différentes, suivant qui la pose. L’African Wildlife Ontology (AWO) évoquée par C. Maria Keet pourrait avoir une tout autre allure selon qu’elle supporte un documentaire de la BBC pour la jeunesse, ou une étude scientifique très précise sur les impacts des changements climatiques sur l’écosystème des animaux sauvages en Afrique, leur reproduction, leur alimentation et leur espérance de vie. Si on pose la question, « quels sont les types d’animaux qui vivent en Afrique ? », le niveau de taxonomie et les caractéristiques suivies ne seront probablement pas les mêmes.
Il résulte de cela que les questions de compétences se traduisent en concepts et relations différentes suivant la perspective choisie et le niveau de connaissance de la communauté derrière. Il s’agit de partir d’une question, d’aller vers des sous-questions, et de construire progressivement les concepts en explorant les liens qui s’ouvrent entre eux et qui amènent à réfléchir à d’autres concepts intermédiaires nécessaires pour formaliser correctement un réseau de connaissance.
Il y a un travail d’élicitation, d’abstraction et de modélisation derrière chaque question pour comprendre les concepts qui permettent d’y répondre et ce que signifie vraiment chaque « chose » conceptualisée et ses relations avec d’autres, par rapport à ce qu’on veut mais aussi ce qu’on peut en dire dans un univers du discours précis. En effet, une ontologie n’a pas pour objet de créer de la connaissance. Elle sert à formaliser un modèle d’une connaissance existante, qui fait consensus parmi les experts du sujet. Sur la base de cette connaissance, des informations disparates, pourront ensuite, rapprochées, faire « sens ». C’est-à-dire aider à déduire quelque chose, logiquement.
Automatiser la génération de CQs : apports et limites des LLMs
L’intelligence de l’ontologie est celle des liens que les experts savent faire entre objets déterminant de leur système de connaissance. Ces liens qui caractérisent les interactions entre concepts servent d’intelligence « artificielle » à la machine. Ils lui servent à reconnaitre qu’une chose est de telle nature, ou si elle est déclarée de telle nature, ce que cela implique. Valider l’adéquation sémantique revient à vérifier que l’ontologie produit, sur un corpus de référence, les mêmes réponses qu’un expert interrogé sur ce même corpus. Automatiser la validation à partir des questions de compétences une fois raffinées ne sera pas satisfaisant. Il faut avant de pouvoir faire cette validation :
- Valider si les questions de compétences ont bien été traduites en concepts et relations dans toutes leurs implications et qu’on a généré l’ensemble des sous-questions auxquelles elles doivent mener ;
- Valider qu’on dispose de ressources représentatives de la réalité couvrant toutes les questions et sous-questions auxquelles la base doit savoir répondre.
Ensuite, il faudrait faire une double validation, propre au test d’une ontologie OWL : à chaque question posée à un expert sur un pool de ressources, faire l’interrogation de la base et comparer les résultats.
Récemment, de nouveaux outils sont apparus, nés la tentation d’utiliser les LLMs pour faciliter la construction des CQs. Des chercheurs dans le domaine académique (cf Keet) ont investigué cette piste avec l’idée de faire gagner du temps aussi bien aux experts des domaines métiers considérés qu’aux ingénieurs ontologues. Mais jusqu’à quel point l’approche CQs est-elle automatisable ? Il faut distinguer les outils dédiés à la construction des CQ (élicitation, formulation, raffinement) et ceux dédiés au test et à la validation (vérification que l’ontologie ou le knowledge graph répond effectivement aux CQ). En observant les essais réalisés sur le domaine, force est de constater que la volonté d’automatisation se heurte aux temps nécessaires de l’élicitation et de la compréhension.
LLMs en élicitation directe : catalyseur ou raccourci ?
L’analyse des CQs ressort typiquement d’un processus d’élicitation. Elle part sur la formulation de quelque chose qui n’a pas déjà été exprimé et qu’il faut concevoir. Utiliser un LLM semble curieux ici. A priori un système basé sur des statistiques probabilistes ne devrait pas pouvoir formuler quelque chose qui ne figure pas dans son corpus d’entraînement, à moins que cela soit du domaine du bon sens. On peut arguer que les LLMs en combinant des concepts distants servent de catalyseurs pour réaliser des connexions existantes. A contrario, ils pourraient aussi conduire à formaliser pourquoi cela ne peut pas exister et clarifier la raison logique. Le LLM dans ce cas déclenche le processus de création.
Mais il y a également fort à parier deux choses qui limiteraient ces éventuels bénéfices. D’une part, si les données d’entraînement sont très loin du domaine de connaissance initial, le temps passé à corriger les erreurs ou les raccourcis logiques du LLM dépassera celui du bénéfice qu’il pourrait apporter. D’autre part, si pour obtenir un bon résultat il est nécessaire d’apprendre à formuler correctement son prompt avec un accompagnateur, est-ce qu’on est certain de gagner du temps par rapport à l’élicitation guidé par un ontologue ?
Les recherches actuelles militent clairement pour garder une chaine de validation humaine rigoureuse. « Les LLM manquent souvent de la profondeur de connaissances nécessaire pour une modélisation précise dans les domaines scientifiques spécialisés, ce qui peut conduire à des représentations superficielles ou incorrectes. Par conséquent, les recherches actuelles soutiennent le rôle des LLM en tant que technologies d’assistance au sein de processus dirigés par des experts, où une validation rigoureuse par des spécialistes du domaine est essentielle pour garantir l’exactitude et la fiabilité scientifique des ontologies résultantes. » [2]
Tester une ontologie: l'humain dans la boucle
L’idée de la plupart des systèmes de formulation de CQs avec des LLMs, c’est de passer par une étape intermédiaire plus proche de celles que connaissent les utilisateurs futurs du système de connaissance qu’on construit. En l’occurrence, il s’agit de les aider à formuler des user stories. Si ces dernières sont bien connues du paradigme de développement logiciel actuel pour collecter leurs exigences, elles ne servent ici que de « sas » d’entrée. Des outils comme les frameworks d’Ontology Requirements Engineering (ORE) OntoChat et IDEA (Infer, Design, creAte) proposent des templates de « user stories » qui seront ensuite traduites en CQs par les LLMs. Il y a toujours un humain dans la boucle : l’utilisateur.
Toutefois les retours d’expérience témoignent d’une certaine difficulté des utilisateurs avec ces framework, même avec des modèles, ils ont du mal à formuler efficacement leurs prompts. D’autres études proposent dès lors un accompagnement spécifique le « participatory prompting ». On peut se demander alors ce que le processus apporte de plus qu’un accompagnement direct à formuler les concepts de manière logique. On perd ici la spécificité de faire une spécification sans ambiguïté, en termes logiques, ce qui est la nature même des étapes d’élicitation des CQs. Il est donc nécessaire de repasser par des validateurs humains pour la logique.
RAG pour la génération de CQs : gains de couverture, risques de superficialité
Pour réduire le risque évoqué précédemment, que les données d’entraînement soient trop loin du domaine de connaissance, il semble naturel que des travaux se soient focalisé sur l’usage du RAG pour le développement des CQs. Les auteurs de [3] ont testé de façon empirique deux corpus avec du RAG pour évaluer l’effort comparé à celui d’experts construisant eux-mêmes les CQs. KG‑EmpiRE (ontology d’ingénierie des exigences) et HCIO (ontology de référence en interaction humain-machine) ont servi l’un à générer des CQs pour construire un graphe de connaissances, l’autre à évaluer la pertinence sur une ontologie existante.
Les mesures pour évaluer les questions produites ont été :
- Précision et rappel : comparaison avec des questions de compétence (CQs) manuelles de référence
- Couverture : nombre de CQs distincts produits
- Ratings experts : pertinence, complétude, qualité linguistique (notés subjectivement)
L’avantage principal relevé portait sur la couverture, l’argument étant que le système peut produire plus de questions variées (+30-45%) en moins de temps, tout en maintenant une qualité comparable à celle d’un expert humain. Cependant les failles de l’approche sont probablement liées à la qualité et la complétude des sources en entrée ainsi qu’au paramétrage du LLM (GPT4, température, nombre de documents) et au phrasage des prompts (cf. problématique OntoChat et autres). En outre l’échantillon (deux ontologies de faible taille) ne permet pas de généraliser l’approche. Par ailleurs, le système générera forcément quelques hallucinations occasionnelles, du fait même du recours à un LLM. Quant à la reproductibilité des questions générées suite à un nombre conséquent d’essais, la question n’a pas été traitée.
Donc si a priori l’approche pourrait réduire l’effort manuel d’élicitation, le risque demeure que la génération automatique produise des CQ superficielles ou incorrectes dans des domaines très spécialisés. Cela nécessite toujours une validation experte
Ironiquement, l’usage de LLMs pour gagner du temps à générer automatiquement des CQs, conduit à créer des outils pour gagner du temps à les corriger.
Ainsi VSPO (Validating Semantic Pitfalls in Ontology via LLM-Based CQ Generation) cible la validation de pièges sémantiques dans la génération de CQ par LLMs. L’outil génère des CQ ciblant spécifiquement les incohérences sémantiques de l’ontologie (confusion entre définition de classe et axiomes, par exemple) pour lesquelles GPT-4.1 échoue. Toutefois, l’outil en question n’a pas été évalué en conditions industrielles et nécessite une API LLM (cf [4]).
CLaRO, AgOCQs, Bench4KE : vers une standardisation mesurable
Claro
Une autre approche consiste à faire passer les questions de compétences au filtre d’un langage contrôlé pour les exprimer de façon standardisée. Ce qui facilitera par la suite leur formalisation en logique descriptive et la traduction de ces questions dans un langage de requête tel que SPARQL. CLaRO (Competency question Language for specifying Requirements for an Ontology) est un langage naturel contrôlé (CNL) basé sur des templates pour la rédaction des CQ. Selon Keet et Antia [5], il a été « conçu à partir d’un dataset de 234 CQ analysées en 106 patterns linguistiques, il propose 93 templates couvrant environ 90 % des constructions syntaxiques rencontrées en pratique ».
Si CLaRO permet une rigueur linguistique et aide à détecter les questions mal formulées, il nécessite une familiarisation avec la grammaire contrôlée, ce qui peut sembler contraignant pour les experts métiers non techniciens. Là également, il y a besoin d’accompagnement.
Dans cette optique, le pipeline AgOCQs est un système développé par Antia & Keet (2023) qui automatise la génération de CQ pour des ontologies existantes avec cLaRO tout en s’inscrivant dans les approches basées sur le NLP pour assister les ingénieurs de la connaissance (cf Keet blog).
AgOCQs
.L’idée initiale de Mary-Jane Antia étant de partir d’un corpus limité de textes initiaux dans le domaine de connaissance visé, des modèles ClaRO de structure de questions, et le modèle de langage T5 (Text-to-Text Transfer Transformer). Ce dernier, présenté dans l’article [6] est un modèle seq2seq de transfert d’apprentissage basé sur l’architecture Transformer de Vaswani et al. (2017).
Mais comment valider que les questions produites sont de bonnes qualités ? Le test pour le pipeline AgOCQs [7] a consisté à demander à des humains ce qu’ils pensaient de la qualité des questions produites et si, à leur sens, elles étaient à la fois pertinentes, si on pouvait y répondre, et si elles pouvaient être utiles pour plus d’une ontologie dans le même domaine élargi. Si les réponses ont été clairement davantage oui que non ou incertain, cela reste une approche empirique. Par contre, on ne sait pas si le passage par le pipeline permet d’identifier toutes les questions qui devraient être posées et jusqu’à quel point cela a raccourci l’effort d’élicitation. Il faudrait un benchmark pour cela.
Bench4KE
Bench4KE (Benchmarking Automated CQ Generation) est un système de benchmarking standardisé conçu pour évaluer l’automatisation de l’ingénierie des connaissances, en particulier la génération automatique de questions de compétences (CQ) par les grands modèles de langage. Pour pallier le manque actuel de rigueur méthodologique et de reproductibilité, Bench4KE propose une API extensible s’appuyant sur un corpus de référence issu de quatre projets réels et utilise des métriques de similarité pour mesurer la qualité des résultats.
« Bench4KE provides a curated gold standard consisting of CQ datasets from four real-world ontology projects. It uses a suite of similarity metrics to assess the quality of the CQs generated.” [8] Son utilité est démontrée via une analyse comparative de quatre systèmes existants, établissant ainsi une base fiable pour de futures recherches tout en préparant l’outil à intégrer d’autres tâches comme la génération de requêtes SPARQL. Le code et les données sont publiés librement pour favoriser la collaboration scientifique.
Tester une ontologie sur les CQs : une chaîne encore fragmentée
Une fois la qualité des CQs validées par des experts, la qualité de l’ontologie en réponse peut être validée par des requêtes SPARQL déduites de ces CQs, voire un peu plus car SPARQL ne couvre pas tout. Malheureusement, dans ce domaine également l’automatisation n’est pas si simple. Si un langage tel que ClaRO a été utilisé, la traduction en SPARQL peut être faite, même si on peut perdre un peu de la logique descriptive d’OWL-DL se faisant.
CQChecker, est un outil qui existe depuis 2015, qui vérifie si des CQ rédigées en langage naturel contrôlé sont satisfaites par une ontologie OWL-DL. Il traite les limites de SPARQL. En effet, ainsi que l’indiquent les auteurs de [9] : « SPARQL est un langage de requête aussi expressif que l’algèbre relationnelle ce qui engendre une insuffisance de puissance expressive et de capacités de raisonnement pour vérifier les ontologies OWL. Autrement dit, SPARQL n’est pas conçu pour produire une réponse qui pourrait être déduite par l’ontologie via la subsomption si elle n’est pas rendue explicite dans celle-ci ». En utilisant la logique de description sous-jacente. CQChecker analyse la CQ, la classe selon le type de réponse attendue (classes ou instances), puis la convertit et la vérifie.
Mais ClaRO n’est guère utilisé dans le domaine industriel, pas plus que CQChecker ou Tawny-OWL qui utilise Clojure. Ces outils exigent une expertise technique significative et ne bénéficient pas d’un écosystème de support commercial.
ROBOT est un outil open-source industriel majeur, largement adopté par la communauté OBO. Il sert d’outil sur tout le pipeline de construction d’une ontologie OWL (extraction, merge, convert, diff). Ces capacités de test reposent sur des requêtes SPARQL, mais il n’offre aucune assistance pour traduire les questions de compétences en requêtes formelles. Cette étape nécessite systématiquement l’intervention d’un expert humain, sans processus d’aide à la rédaction ou de suggestion semi-automatisée.
La gouvernance des CQs comme artefacts de projet
Dans le domaine industriel, la plupart des plateformes commerciales (GraphDB, Stardog) offrent des capacités de requêtages SPARQL, mais sans gestion native des CQs.
Même lorsque les CQ ont été spécifiées, il n’existe pas d’outils pour exécuter automatiquement des tests de validation correspondant (SPARQL et raisonnement) de manière fiable, ce qui affecte directement le test des exigences de l’ontologie.
Par ailleurs, dans les projets réels impliquant plusieurs parties prenantes (experts métier, ingénieurs de la connaissance, validateurs, commanditaires), les CQ ne sont pas juste des phrases en langage naturel mais des artefacts de gestion de projet qui ont un cycle de vie, des auteurs, des statuts d’approbation et des liens vers les exigences opérationnelles. Exactement comme pour des exigences fonctionnelles d‘un projet logiciel.
L’outil open source CQ Ferret (développement personnel de Jonathan Vajda et Aaron Damio), [10] développé dans le cadre de OntoEagle, répond à cette problématique avec un outil, qui s’il n’est pas industriel, comble un vide réel dans la chaîne d’outils de vérification et de validation.
Conclusion : vers un KG Engineering Lifecycle Management
Il apparaît, pour conclure, que tester l’adéquation sémantique d’une ontologie au métier requiert une chaîne de traitement complète qui pour l’heure est fragmentée dans divers outils. Par ailleurs, il ne s’agit pas de la seule dimension qualité d’une ontologie à tester dans la construction d’un Knowledge Graph. Il faut aussi considérer la qualité formelle/logique, la qualité structurelle, la conformité des instances aux formes attendues, etc. Quant à la qualité du Knowledge Graph lui-même, elle est aussi tributaire des sources, ce qui sera développé ultérieurement.
L’industrialisation du « Knowledge Graph Engineering LifeCycle Management » n’en est qu’à ses débuts. Si elle fait bien de s’inspirer des cycles de vie et de l’assurance qualité du logiciel, elle ne doit pas oublier l’ancrage sémantique et la logique formelle qui fait sa spécificité, sauf à n’être qu’une couche technologique en plus.
En effet, l’acquisition de la connaissance et la formulation de cette dernière n’est ni un processus simple à portée de tous, ni un processus compliqué qu’un expert seul pourrait découper en morceaux maîtrisables. Il s’agit d’une approche systémique, où la représentation de la connaissance s’enrichit de la compréhension consensuelle et partagée de différentes perspectives et interrelations. La tentation d’automatiser cela par le recours aux LLMs ou à une sorte d’algorithme universel, revient à vouloir traduire des textes eux-mêmes éventuellement ambigus, incomplets, en oubliant qu’il s’agit de les clarifier au-delà de ce qui est écrit. Il ne s’agit pas tant de traduire que d’expliciter ce qui ne l’est pas, d’où la nécessite du recours à une validation humaine rigoureuse.
Références
[1] Keet, C. Maria. “An Introduction to Ontology Engineering.” (2018).
[2] LLM-supported collaborative ontology design for data and knowledge management platforms Published in Frontiers in Big Data Machine Learning and Artificial Intelligence, novembre 2025
[3] A RAG Approach for Generating Competency Questions in Ontology Engineering, Xueli Pan and Jacco van Ossenbruggen and Victor de Boer and Zhisheng Huang, 2025
[4] VSPO: Validating Semantic Pitfalls in Ontology via LLM-Based CQ Generation Hyojun Choi, Seokju Hwang, Kyong-Ho Lee* School of Computing, Yonsei University {gywns2184, hsjtjrwn, khlee89}@yonsei.ac.kr
[5] Keet, C.M., Mahlaza, Z., Antia, MJ. (2019). CLaRO: A Controlled Language for Authoring Competency Questions. In: Garoufallou, E., Fallucchi, F., William De Luca, E. (eds) Metadata and Semantic Research. MTSR 2019. Communications in Computer and Information Science, vol 1057. Springer, Cham. https://doi.org/10.1007/978-3-030-36599-8_1
[6] Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer par Colleen Raffel et al. (2020)
[7] “Automating the Generation of Competency Questions for Ontologies with AgOCQs” 2023, in the proceedings of the 5th Iberoamerican conference on Knowledge Graphs and Semantic Web (KGSWC’23), and presented at the conference in Zaragoza, Spain, in November 2023.
[8] Bench4KE: Benchmarking Automated Competency Question Generation
[9] Verifying Description Logic Ontologies based on Competency Questions and Unit Testing Camila Bezerra, Fred Freitas
[10] https://www.linkedin.com/pulse/lowering-barrier-competency-driven-ontology-cq-ferret-aaron-damiano-kabxe/ et CQ Ferret Tutorial - OntoEagle Tutorials