Les entreprises investissent des milliards de dollars dans des agents et des infrastructures d’IA pour transformer leurs processus métier. Cependant, nous constatons un succès limité dans les applications du monde réel, souvent en raison de l’incapacité des agents à véritablement comprendre les données, les politiques et les processus de l’entreprise.
Même si nous gérons bien les intégrations avec des technologies telles que la gestion des API, le Model Context Protocol (MCP) et d’autres, les agents comprenant la « signification » des données dans un contexte commercial donné sont en réalité une autre histoire. Les données d’entreprise sont souvent cloisonnées dans des systèmes distincts sous forme structurée et non structurée et doivent être analysées dans une perspective métier spécifique à un domaine.
À titre d’exemple, le terme « client » peut faire référence à un groupe de personnes différent dans un système CRM de vente, par rapport à un système financier qui peut utiliser cette balise pour les clients payants. Un département peut définir le « produit » comme un SKU ; Une autre peut être représentée comme une famille de « produits » ; Troisièmement en tant qu’offre groupée marketing.
Les données sur les « ventes de produits » changent ainsi de sens sans qu’il y ait accord sur les relations et les définitions. Pour que les agents puissent intégrer des données provenant de plusieurs systèmes, ils doivent comprendre différentes représentations. Les agents doivent savoir ce que signifient les données dans leur contexte et comment trouver les bonnes données pour le bon processus. De plus, les changements de schéma et les problèmes de qualité des données dans le système lors de la collecte peuvent conduire à davantage d’ambiguïté et à l’incapacité des agents à savoir comment agir face à de telles situations.
De plus, la classification des données en catégories telles que les PII (informations personnellement identifiables) doit être strictement suivie pour maintenir la conformité aux normes telles que le RGPD et le CCPA. Cela nécessite que les données soient correctement étiquetées et que les agents soient capables de comprendre et de respecter cette classification. Nous pouvons donc voir qu’il est tout à fait possible de créer une superbe démo à l’aide d’agents – mais la production travaillant sur des données métier réelles est une toute autre histoire.
Une source de vérité basée sur l’ontologie
La création de solutions agentiques efficaces nécessite une source de vérité unique basée sur une ontologie. Une ontologie est une définition commerciale des concepts, de leur hiérarchie et de leurs relations. Il peut aider à définir les termes des champs du domaine métier, à établir une source unique de vérité pour les données, à capturer des noms de champs uniformes et à appliquer une classification aux champs.
Une ontologie peut être spécifique à un domaine (santé ou finance) ou spécifique à une organisation en fonction des structures internes. Définir une ontologie dès le départ prend du temps, mais peut aider à standardiser les processus métier et à jeter des bases solides pour l’IA agentique.
Les ontologies peuvent être réalisées en utilisant des formats interrogeables simples tels que les triplestores. Des règles métier plus complexes avec des relations multi-sauts peuvent utiliser des graphiques de propriétés étiquetés comme Neo4j. Ces graphiques peuvent aider les entreprises à découvrir de nouvelles relations et à répondre à des questions complexes. Des ontologies telles que FIBO (Finance Industry Business Ontology) et UMLS (Unified Medical Language System) sont disponibles dans le domaine public et peuvent constituer un très bon début. Cependant, ils doivent généralement être personnalisés pour capturer les détails spécifiques d’une entreprise.
Premiers pas avec l’ontologie
Une fois mise en œuvre, une ontologie peut être la force motrice des agents d’entreprise. Nous pouvons désormais demander à l’IA de suivre l’ontologie et de l’utiliser pour découvrir des données et des relations. Si nécessaire, nous pouvons disposer d’une couche agent qui peut servir les détails clés de l’ontologie et découvrir les données. Des règles et politiques métier peuvent être appliquées à cette ontologie pour que les agents puissent y adhérer. Il s’agit d’un excellent moyen de consolider vos agents et de mettre en place des barrières basées sur un contexte commercial réel.
Les agents ainsi conçus et réglés pour suivre une ontologie peuvent rester sur leurs gardes et éviter les hallucinations provoquées par leur pouvoir dans le grand modèle de langage (LLM). Par exemple, une politique commerciale peut définir que le statut du prêt doit être conservé à l’état « en attente », à moins que tous les documents liés au prêt n’aient l’indicateur vérifié défini sur « vrai ». Les agents peuvent contourner cette politique, déterminer les documents nécessaires et interroger la base de connaissances.
Voici un exemple de mise en œuvre :
(Image originale de l’auteur)
Comme illustré, nous avons des données structurées et non structurées traitées par un agent Document Intelligence (DocIntel) qui construit une base de données Neo4j basée sur une ontologie de domaines métier. Un agent de découverte de données dans Neo4j trouve et recherche les bonnes données et les transmet à d’autres agents gérant l’exécution des processus métier. La communication inter-agents s’effectue avec un protocole populaire tel que A2A (Agent to Agent). Un nouveau protocole appelé AG-UI (Agent User Interaction) peut aider ces agents à créer des écrans d’interface utilisateur plus simples pour capturer les actions et les réponses.
Avec cette approche, nous pouvons éviter les hallucinations en obligeant les agents à suivre des chemins basés sur des ontologies et à maintenir les classifications et les relations des données. De plus, nous pouvons facilement évoluer en ajoutant de nouvelles ressources, relations et politiques auxquelles les agents peuvent automatiquement obéir, et contrôler les hallucinations en définissant des règles pour l’ensemble du système plutôt que pour des entités individuelles. Par exemple, si un agent hallucine un « client » individuel, parce que les données associées au « client » halluciné ne seront pas vérifiables lors de la découverte de données, nous pouvons facilement identifier cette anomalie et planifier son élimination. Il aide les entreprises à gérer l’échelle du système agent et sa nature dynamique.
En effet, une architecture de référence comme celle-ci ajoute une surcharge à la découverte de données et aux bases de données graphiques. Mais pour une grande entreprise, il ajoute les bons rails et guide les agents pour orchestrer des processus métier complexes.
Dattaraj Rao est l’architecte de l’innovation et de la R&D Système permanent.
En savoir plus sur nous Auteur invité. Ou pensez à soumettre votre propre message ! nous voir Les directives sont ici.
