L'ontologie comme juge d'un agent IA : sur UniProt, ses alertes d'erreur sont à peine plus fiables que le hasard

Des chercheurs du Sano Centre for Computational Medicine ont vérifié si l'on pouvait se fier à une ontologie comme juge d'un agent IA. Une ontologie est une description lisible par machine des types d'entités présents dans un graphe de connaissances et des façons dont elles peuvent être reliées. Un agent fondé sur un grand modèle de langage (LLM) répond à une question par une requête SPARQL sur le graphe, par exemple sur la base UniProt.

L'ontologie confronte la requête et le résultat, puis laisse passer la réponse ou lève un drapeau. Sur de vraies réponses d'agents, les drapeaux de l'ontologie d'experts d'UniProt se révèlent à peine plus précis que le hasard. C'est précisément cette comparaison avec des drapeaux aléatoires qui se cache derrière la formule « à peine mieux qu'un tirage au sort » du titre.

Pourquoi une fausse alerte est dangereuse

Le schéma de vérification est simple. L'agent écrit une requête, puis le contrôle la confronte, avec ses résultats, à l'ontologie. Si un drapeau est levé, l'agent dispose d'une seule nouvelle tentative. C'est là que réside le risque : lorsque le drapeau est faux, l'agent peut transformer une réponse correcte en réponse erronée. On a déjà observé un phénomène similaire lors de l'affinage de requêtes text-to-SQL. La précision finale ne le montre pas, car les erreurs détectées et les réponses correctes dégradées s'y mélangent. Les auteurs comptent donc séparément le nombre d'erreurs trouvées par le contrôle et le nombre de réponses correctes signalées à tort.

Les ontologies sont particulièrement sujettes aux faux positifs. Leurs axiomes se lisent comme des contraintes strictes, alors que les ontologies publiées ne décrivent pas les données de façon exhaustive. Dans un crawl de données liées (Linked Data), 14,3% des triplets utilisaient des propriétés absentes de tous les vocabulaires examinés. Un contrôle qui exigerait de déclarer chaque propriété rejetterait aussi des réponses correctes reposant sur ces propriétés.

Il existe aussi un exemple de contrôle réussi. Supposons que l'ontologie indique que la date de naissance ne concerne que les personnes, et que « ville » et « personne » sont des classes incompatibles. Une requête demandant la date de naissance d'une ville contredit alors l'ontologie, et le drapeau est justifié. Mais une requête peut s'exécuter sans erreur et répondre pourtant à une autre question que celle posée. Les contrôles de structure peuvent laisser passer ce type d'erreurs.

Trois sources d'ontologie et trois façons de les utiliser

Les chercheurs ont comparé trois types d'ontologies :

• Experte. Des humains l'ont rédigée à la main, et elle a été utilisée telle qu'elle est publiée. • Déduite des données. Elle a été extraite du graphe lui-même. • Écrite par un LLM. Le modèle l'a construite à partir d'un résumé du graphe dans lequel les identifiants sont remplacés par des noms opaques. Les auteurs voulaient ainsi écarter le cas où le LLM se contente de se remémorer des identifiants issus de graphes publics.

Chaque ontologie a servi de contexte dans la requête de l'agent, de contrôle de la réponse, ou des deux à la fois. Les chercheurs ont en outre examiné si la combinaison des sources aidait, et s'il était utile de montrer à l'agent le message précis du contrôle.

Comment l'expérience est organisée

Les agents ont été construits sur cinq modèles à poids ouverts et deux modèles propriétaires. La partie confirmatoire de l'étude a été menée sur UniProt. Les autres graphes publics et le graphe privé, dont le texte indique la taille comme « presque » un certain nombre de triplets, ont donné des résultats exploratoires. Le plan d'analyse a été enregistré à l'avance.

Pour que la comparaison soit équitable, les auteurs ont pris en compte trois éléments. Certaines erreurs sont détectées par l'exécution de la requête elle-même, par exemple un résultat vide ; elles ont été séparées des erreurs repérées par le contrôle. Les contrôles ont été testés à la fois sur de vraies réponses d'agents et sur des erreurs artificielles introduites dans des requêtes correctes. Enfin, chaque contrôle a été appliqué aux mêmes réponses et aux mêmes erreurs, et sa décision a été comparée à la bonne réponse connue à l'avance.

Ce que montrent les résultats

Sur UniProt, l'ontologie d'experts a signalé plus de réponses correctes que l'ontologie issue des données et que l'ontologie déduite par un LLM d'un résumé aux identifiants masqués. Sur de vraies réponses d'agents, ses drapeaux sont à peine plus précis que le hasard. Chaque source d'ontologie échange à sa manière des erreurs détectées contre des fausses alertes. L'ontologie d'experts, dans sa version publiée, contredit par endroits les données de son propre graphe. De plus, les contrôles de structure laissent passer une partie des erreurs.

Ce qu'il faut en retenir

Une ontologie d'experts toute prête ne fait pas encore un bon juge. Avant d'activer le contrôle, il faut mesurer deux choses : combien d'erreurs il détecte et combien de réponses correctes il dégrade par la nouvelle tentative. Un repère issu du génie logiciel : dans l'analyse statique de la revue de code chez Google, le taux effectif de faux positifs doit rester inférieur à 10%, faute de quoi les développeurs cessent de faire confiance à l'outil.

Les éditeurs de graphes gagneraient à confronter l'ontologie aux données avant publication. Les développeurs d'agents doivent décider séparément où l'ontologie est la plus utile : dans le contexte, dans le contrôle ou aux deux endroits. Les auteurs ont publié un jeu d'erreurs artificielles accompagnées de bonnes réponses connues à l'avance, le code, ainsi qu'un protocole qui compte les erreurs détectées et les fausses alertes sans exécuter l'agent.