Ontologies métier portables pour les agents IA

Le terme « ontologie » est aujourd’hui à la mode. Pourquoi ? Les agents, et les grands modèles de langage (LLM) qui les alimentent, ont besoin d’un contexte métier pertinent.

Avant d’adopter une ontologie, demandez au fournisseur : « Quand l’ontologie se trompe sur notre activité, comment nos équipes peuvent-elles la corriger — et de quoi dépend-on encore de vous ? » La réponse vous en dira long sur le modèle de l’entreprise que vous vous apprêtez à adopter. Elle met aussi en lumière des enjeux plus vastes : votre capacité à améliorer ce modèle à mesure que l’entreprise évolue et à préserver la valeur de cet investissement si vous changez de plateforme.

Il est utile de distinguer une ontologie d’un graphe de connaissances, même si les deux se recoupent souvent.

Ontologie : les types d’éléments qui existent, le sens des relations et les règles applicables. Équipements, composants, équipes, rôles, processus. Par exemple, une ontologie peut définir un type « Équipement » et une relation « Contient » avec un « Composant ». Un graphe de connaissances peut ensuite affirmer : « La pompe P-101 contient le joint S-7 » : deux entités spécifiques et la relation qui les unit.

Imaginez que vous demandiez à un agent : « Calcule la croissance des ventes à magasins comparables, mais présente-moi une comparaison côte à côte : d’abord avec tous les magasins, puis une autre en excluant ceux qui sont ouverts depuis moins de 2 ans ; ensuite, ventile les deux côtés entre ventes nationales, internationales et cumulées. »

Cette demande repose sur des détails qu’un agent ne peut pas deviner :

• les magasins existants et leur date d’ouverture
• leur emplacement
• la définition interne des « ventes à magasins comparables »

Une politique peut exclure les magasins jusqu’à ce qu’ils soient ouverts depuis un an ; le groupe demandé pour deux ans ajoute un filtre supplémentaire. Même dans ce cas, compare-t-on les mois calendaires dès qu’un magasin remplit le critère, ou ne l’inclut-on qu’après une année fiscale complète écoulée ?

L’ontologie doit relier ces magasins à la politique qui régit le calcul. Trouver des faits connexes est utile ; appliquer la bonne règle, voilà ce qui rend la réponse pertinente.

Avant de répondre à une question, un agent peut exploiter les relations du graphe pour récupérer le contexte pertinent. Et il n’est pas étonnant qu’ils soient utiles, car les domaines de connaissances peuvent facilement devenir très complexes.

Figure 1 : Graphe combinant des modèles SysML publics : TMT Thirty Meter Telescope (Open-MBEE/JPL, Apache-2.0), CubeSat System Reference Model (© 2022 INCOSE SSWG & OMG SDTF, CC BY 4.0), Architecting Spacecraft with SysML (Friedenthal & Oster, BSD-2-Clause), ainsi que du contenu fictif sur la constellation MDC et des spécifications publiques (IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Rendu dans Kamiwaza Kaizen.

Mais l’extraction peut aussi intégrer des erreurs. Les équipes peuvent employer des noms différents pour une même entité, ce qui crée des doublons. Les sources peuvent se contredire ou devenir obsolètes. Même une source fiable peut être mal interprétée par un LLM. Donner à ces erreurs une apparence officielle ne les rend pas moins dangereuses.

Ces risques s’accentuent lorsqu’un modèle de l’entreprise devient un système qui agit sur elle. Une relation erronée peut alors déclencher une mauvaise action, et pas seulement produire une mauvaise réponse.

Risques liés aux produits d’ontologie

Tout d’abord, méfiez-vous des modèles rigides. Sous prétexte de proposer une solution « prête à l’emploi », un fournisseur peut faire de ses propres entités des éléments de premier ordre tout en limitant les possibilités offertes par les vôtres. La personnalisation ne suffit pas si les types personnalisés ne bénéficient pas des fonctionnalités de recherche, de validation ou d’action.

Ensuite, cherchez un parcours qui mène de la découverte à la gouvernance. Un outil devrait vous permettre d’amorcer un graphe à partir de ce qu’un LLM détecte, puis de le valider au regard de contraintes explicites. Vous devriez pouvoir soumettre les exceptions à des personnes et préserver les connaissances exploratoires sans les traiter comme des données métier approuvées.

Le risque le plus important est de lier les processus métier à une plateforme que vous ne pouvez pas quitter. Votre ontologie représente votre entreprise : ses connaissances, ses processus et ses relations. Cet investissement dans la curation et la logique métier devrait rester utile même si vous changez d’outils. Pourquoi un fournisseur devrait-il pouvoir en garder les clés ?

L’utilité des plongements de graphes

Lorsque les graphes de connaissances deviennent très volumineux, il peut être judicieux de choisir un outil ou un fournisseur qui prend en charge les plongements de graphes. Ceux-ci sont très proches des plongements sémantiques qui alimentent de nombreuses applications RAG. Deux avantages méritent d’être pris en compte.

Tout d’abord, quelques sauts dans un graphe densément connecté peuvent faire apparaître trop d’entités à traiter. En apprenant des représentations numériques des entités et des relations, les plongements offrent un autre moyen de trouver les parties pertinentes du graphe. Pour certaines tâches, cette méthode peut être plus efficace que de parcourir le graphe.

Ensuite, les modèles de plongement peuvent classer les relations manquantes potentielles. Le même apprentissage peut révéler des motifs dans les attributs et les relations caractéristiques d’un type d’entité, contribuant ainsi à construire un graphe plus complet.

Pourquoi miser sur l’amélioration progressive

Pour garder la maîtrise de votre avenir, éviter la dépendance à un fournisseur et modéliser votre activité réelle plutôt qu’une caricature dictée par un fournisseur, comment commencer sans disposer d’une armée d’ingénieurs déployés sur le terrain ? C’est là que l’IA moderne, à mon avis, excelle, à condition que les outils permettent de passer de la découverte à la vérification.

Commencez par automatiser la découverte et l’extraction. À partir de documents d’entreprise, de politiques internes, de courriels ou de messages Slack, vous pouvez établir une première représentation d’un domaine. L’essentiel, c’est que vous ne pouvez pas la considérer comme exacte tant qu’elle n’a pas été vérifiée.

La vérification constitue la deuxième étape. Vos outils doivent vous permettre de passer facilement des éléments candidats extraits à des affirmations étayées par des sources, puis à des connaissances validées par une personne responsable ou un système faisant autorité. Conservez la source de chaque affirmation.

La mise à jour des connaissances est un travail continu. La procédure de traitement d’un ticket d’incident, ou la réponse à la question « Combien y a-t-il de magasins dans le New Jersey ? », peut différer aujourd’hui de ce qu’elle était il y a trois ans. Mais mettre à jour les connaissances actuelles ne doit pas effacer la réalité d’hier. La date à laquelle un fait a été enregistré peut différer de la période pendant laquelle il s’appliquait ; une ontologie utile doit permettre de répondre aux questions actuelles tout en offrant une vision historique exacte. Quelqu’un doit malgré tout veiller à ce que ces connaissances restent à jour.

Le champ d’application peut être immense. Commencez par un corpus plus restreint, cartographiez un domaine utile, puis élargissez progressivement votre représentation jusqu’à obtenir une vue d’ensemble, tout en créant de la valeur en chemin.

Le service client constitue un domaine d’application utile : appels entrants, courriels, système de gestion des tickets, résolutions automatisées, équipe d’assistance en mesure de répondre aux clients et procédure permettant de transmettre les véritables bogues à l’équipe d’ingénierie. Ce domaine relie les connaissances à l’action et met en évidence les mêmes risques et avantages, dans un cadre maîtrisable.

Le Common Service Data Model de ServiceNow illustre cette contrainte. Son livre blanc CSDM 5 avertit : « Sans ces données dans les tables prescrites, vous ne bénéficierez peut-être pas de toute la valeur de la ServiceNow AI Platform. » Cet avertissement crée lui-même une contrainte de conception et d’exploitation : adopter le modèle du fournisseur ou accepter un risque. Et si cela revenait à vouloir faire entrer votre cheville ronde dans son trou carré ?

Supposons maintenant qu’une plateforme d’ontologie fournisse également des fonctionnalités d’ingestion, de transformation, d’action et de gestion des règles métier. Vous pourrez peut-être exporter les entités, les attributs et les relations. Mais pourrez-vous aussi transférer les transformations et les chaînes d’actions qui exécutent des modifications dans vos bases de données, appellent des webhooks et produisent d’autres effets secondaires ? Des intégrations étroitement couplées peuvent rendre l’entreprise elle-même captive de la plateforme.

Pourquoi la flexibilité est essentielle aujourd’hui

Le logiciel dévore le monde, et l’IA dévore le logiciel. À mesure que les équipes se servent de l’IA à la fois pour développer des logiciels et pour les faire fonctionner, une part croissante de la logique métier risque de se retrouver liée à ces plateformes. Chaque automatisation utile peut aussi créer une dépendance supplémentaire lors d’une migration. Laisser un fournisseur s’interposer entre vous et votre agilité est dangereux.

Conclusion

C’est une époque extraordinaire pour être en vie ! Il n’est pas étonnant que les gens explorent les ontologies pour donner du contexte aux agents. Étendre ce contexte aux processus et aux intégrations peut créer une réelle valeur. Revenons à la question posée au début. Les corrections apportées par vos équipes devraient permettre au modèle de mieux refléter votre entreprise. Cette compréhension accumulée est trop précieuse pour être perdue lors d’un changement de plateforme. C’est aussi une époque terrible pour se retrouver enfermé dans une impasse.