Ontologie des données définie : la couche de contexte qui manque à vos agents d'IA

Demandez à cinq personnes d'une même entreprise ce que signifie le mot "chiffre d'affaires" et il y a de fortes chances que vous obteniez cinq réponses différentes, chacune correcte dans son propre contexte et incompatible avec les autres. Tant qu'un analyste humain s'est trouvé entre cette ambiguïté et le rapport final, l'ambiguïté a été gérable. C'est un savoir informel : le genre de chose qu'un bon analyste sait, tout simplement.

Les agents d'AI ne le savent pas. Et c'est là tout le problème.

Richard Tomlinson a passé sa carrière à réfléchir à la couche de données d'entreprise qui n'apparaît jamais vraiment dans le schéma. Dans cette conversation, il explique pourquoi cette couche, l'ontologie, est soudainement la pièce d'infrastructure la plus importante que la plupart des entreprises n'ont pas encore construite, pourquoi la dernière génération de tentatives pour la concevoir a largement stagné, et ce qui doit caractériser une ontologie pour qu'elle tienne la route dès lors que les agents commencent à s'appuyer sur elle.

Pourquoi les agents d'AI ont-ils besoin d'un contexte métier qu'un schéma ne peut pas fournir ?

Quelle est l'hypothèse concernant les données d'entreprise que les agents d'AI sont discrètement en train de remettre en question ?

Richard Tomlinson : Depuis des décennies, l'architecture des données d'entreprise repose sur une hypothèse implicite : si vous organisez correctement les données, un utilisateur intelligent peut en comprendre le sens. Les tables, les schémas, les catalogues et les tableaux de bord fournissent la structure, tandis que les humains apportent le contexte manquant. Un analyste sait à laquelle des cinq tables de chiffre d'affaires la Finance fait confiance, ce que signifie "client actif" ce trimestre, ou pourquoi un calcul devrait être utilisé plutôt qu'un autre.

Les agents d'AI rompent cette hypothèse car il n'y a parfois aucun humain qualifié entre les données et la décision. L'agent doit découvrir le sens par lui-même. Donner à un agent l'accès à plus de données ne résout pas ce problème. Il a besoin du contexte métier que les humains ont historiquement gardé en tête : définitions, relations, calculs, sources faisant autorité, expertise et autorisations. C'est pourquoi le contexte d'entreprise devient aussi important pour l'architecture d'AI que les données elles-mêmes.

Qu'est-ce qu'une ontologie de données, et en quoi est-elle différente d'un schéma ?

Comment définissez-vous une ontologie de données, et que capture-t-elle qu'un schéma ne pourrait jamais saisir ?

Richard Tomlinson : Un schéma décrit la manière dont les données sont structurées. Une ontologie décrit ce que ces données signifient dans le contexte de l'entreprise. Elle relie les actifs techniques tels que les tables, les métriques et les requêtes à des concepts métier : définitions, relations, calculs, sources d'expertise et règles sur la façon dont ces concepts doivent être interprétés.

Un schéma peut indiquer à un agent qu'une table contient net_rev, gross_rev et recog_rev. Une ontologie peut l'aider à comprendre quelle définition du chiffre d'affaires s'applique à la question, quelle source la Finance considère comme faisant autorité, comment le calcul est normalement effectué et si la personne qui pose la question est même autorisée à y accéder. Le schéma est la carte des données. L'ontologie est plus proche d'une carte de la manière dont l'organisation comprend et utilise ces données.

Pourquoi les couches sémantiques et les graphes de connaissances ont-ils eu du mal à passer à l'échelle ?

Les couches sémantiques et les graphes de connaissances d'entreprise promettaient "une version unique de la vérité" il y a des années et sont pour la plupart restés au placard. Que doit-il en être d'une ontologie pour qu'elle ne subisse pas le même sort ?

Richard Tomlinson : Je nuancerais légèrement ce postulat. Les couches sémantiques et les graphes de connaissances ont apporté une réelle valeur, en particulier pour les concepts critiques pour l'entreprise. Le problème survient lorsque les organisations essaient de modéliser manuellement l'ensemble de l'entreprise. Les connaissances métier évoluent trop rapidement et sont réparties dans trop d'endroits. La logique importante peut se trouver dans un tableau de bord, une requête SQL, un notebook, un ticket ou simplement dans la façon dont une équipe travaille de manière répétée. Aucune équipe centrale ne peut documenter tout cela et le maintenir à jour.

Le modèle le plus évolutif consiste à "modéliser la tête et apprendre la traîne". Les humains doivent définir et gouverner explicitement le petit ensemble de concepts qui ne peuvent pas être erronés, comme le chiffre d'affaires, les règles de conformité et les KPI principaux. L'ontologie plus large doit continuellement apprendre la longue traîne à partir du fonctionnement de l'organisation, tout en classant les connaissances par autorité et en respectant la gouvernance. Si la maintenance de l'ontologie devient un projet distinct de modélisation des données d'entreprise, elle finira par être en retard sur l'activité qu'elle est censée décrire.

Que se passe-t-il lorsqu'un agent d'AI manque de contexte métier ?

Pouvez-vous décrire un moment où un agent a donné une réponse erronée avec assurance parce qu'il manquait de contexte métier réel ? Qu'est-ce qui l'a rendue suffisamment convaincante pour que quelqu'un y croie presque ?

Richard Tomlinson : Un exemple issu de nos propres tests internes a consisté à demander à plusieurs systèmes d'AI de préparer un briefing pour un prochain Product Advisory Board. Un assistant a produit un rapport soigné presque immédiatement et a déclaré que 24 clients y participaient. Il incluait le genre de détails que l'on attend d'une note de synthèse, de sorte qu'au premier coup d'œil, la réponse semblait crédible. Lorsque nous avons demandé au système d'expliquer d'où venait le chiffre 24, il a admis qu'il l'avait inventé.

C'est le mode de défaillance dangereux. La réponse n'est pas manifestement absurde. Elle est fluide, précise et présentée aux côtés d'informations légitimes. Le problème est que le modèle ne sait pas quelle source interne contient la vérité de terrain, il comble donc le vide par déduction. Dans l'AI d'entreprise, une réponse plausible peut être plus dangereuse que pas de réponse du tout.

Comment savoir si votre organisation manque d'une couche de contexte ?

Si un responsable des données voulait savoir si sa propre organisation rencontre ce problème, que devrait-il chercher ? Y a-t-il un signe révélateur qui indique l'absence de couche de contexte ?

Richard Tomlinson : Le signal le plus clair est la fréquence à laquelle une question métier simple nécessite d'être traduite par une personne qualifiée avant que les données ne puissent y répondre. Si quelqu'un demande : "Quel était le chiffre d'affaires le trimestre dernier ?" et que l'analyste répond immédiatement par "Quel chiffre d'affaires ?" ou "Pour quelle unité commerciale ?", cette étape de traduction constitue le contexte métier. Il en va de même lorsque les analystes savent à quel tableau de bord faire confiance, quelle table est obsolète ou quelle définition une équipe utilise par rapport à une autre.

D'autres signes révélateurs : des tableaux de bord dupliqués, des définitions de KPI contradictoires, des analystes répondant à plusieurs reprises aux mêmes questions et des utilisateurs métier qui se méfient du self-service car différents outils renvoient des réponses différentes. Le problème sous-jacent n'est souvent pas que l'entreprise manque de données. C'est que les connaissances requises pour interpréter les données résident dans le savoir informel, des artefacts déconnectés et des experts individuels, plutôt que dans une couche de contexte que l'AI peut utiliser de manière fiable.

Combien coûte aujourd'hui aux entreprises l'absence de contexte métier ?

Combien cela coûte-t-il aux entreprises aujourd'hui, avant même qu'elles n'aient déployé des agents à grande échelle ? S'agit-il de décisions plus lentes, d'un travail d'analyste dupliqué, d'une confiance érodée dans les tableaux de bord ?

Richard Tomlinson : Tout ce qui précède. Les organisations paient déjà une "taxe sur le contexte". Les analystes passent du temps à redécouvrir des définitions, à localiser des sources faisant autorité, à concilier des rapports contradictoires et à expliquer une logique métier qui existe ailleurs dans l'organisation. Différentes équipes recréent la même sémantique au sein de différents outils de BI. Les utilisateurs métier attendent les analystes car le self-service cesse de fonctionner dès que la question devient nuancée.

L'AI rend ce problème existant plus visible. Sans contexte, les agents répètent une grande partie du même processus de découverte par le calcul : exploration de schémas, lecture de documents, essai de requêtes et réévaluation d'hypothèses. Cela crée une latence supplémentaire, une consommation de jetons et des coûts sans garantir la bonne réponse. Le coût le plus important, cependant, est la confiance. Une fois que les utilisateurs découvrent qu'un tableau de bord ou un assistant d'AI peut produire un chiffre erroné avec assurance, ils recommencent à s'adresser à un humain.

Qu'est-ce qui change lorsque l'on peut faire confiance aux agents d'AI pour agir, et pas seulement pour faire des rapports ?

Qu'est-ce qui change pour une entreprise à partir du moment où l'on peut faire confiance à ses agents pour agir, et pas seulement pour faire des rapports ?

Richard Tomlinson : La valeur de l'AI change radicalement. Le reporting fait gagner le temps nécessaire pour trouver une réponse. Une action de confiance peut éliminer des étapes entières d'un flux de travail. Un agent peut calculer les derniers chiffres, préparer la revue d'activité hebdomadaire, enquêter sur une anomalie, mettre à jour un ticket, contacter les bonnes personnes et répéter ce processus chaque lundi sans que quelqu'un n'orchestre manuellement chaque étape.

Cela modifie également l'économie de l'expertise. Un expert financier, un chef de produit ou un responsable des opérations peut coder des méthodes critiques une seule fois et les combiner avec un agent qui comprend le contexte métier plus large. Son expertise peut ensuite être appliquée à un nombre bien plus important de décisions et de flux de travail que cette personne ne pourrait en prendre en charge personnellement. Le qualificatif clé est "de confiance" : l'autonomie ne devient utile que lorsque l'agent comprend suffisamment bien l'entreprise, et est encadré de manière assez stricte, pour agir dans des limites appropriées.

Quelle est la bonne façon de commencer à construire une ontologie de données ?

Quelle est la mauvaise façon de commencer, l'instinct qui mène à un autre projet resté au placard, par opposition à la bonne première étape ?

Richard Tomlinson : Le mauvais réflexe est de se dire : "Avant de pouvoir utiliser l'AI, nous devons modéliser l'ensemble de l'entreprise." Cela transforme le contexte métier en un projet de documentation pluriannuel. Le temps que chaque terme, relation et règle soit modélisé, une grande partie du modèle est déjà obsolète.

La meilleure approche consiste à commencer par les connaissances que vous possédez déjà. Gouvernez le petit nombre de concepts qui ne peuvent absolument pas être erronés, tels que les KPI critiques et les définitions métier, puis laissez la couche de contexte plus large apprendre des tableaux de bord, des requêtes, des notebooks, des documents et de l'activité opérationnelle que vos équipes produisent déjà. N'exigez pas de l'entreprise qu'elle documente tout avant que l'AI ne devienne utile. Laissez l'utilisation réelle aider à construire et à améliorer continuellement la compréhension métier que les agents consomment.

Comment les leaders des données doivent-ils repenser l'architecture des données pour les agents AI ?

Comment un leader des données doit-il penser différemment son architecture des données maintenant que le contexte, et pas seulement la structure, est l'élément dans lequel il vaut la peine d'investir ?

Richard Tomlinson : Pendant des années, l'architecture des données s'est fortement concentrée sur la mise à disposition de données accessibles, fiables et gouvernées. Ces aspects restent essentiels, mais l'AI ajoute une autre exigence : l'architecture doit également rendre le sens métier accessible. Un agent doit non seulement savoir où se trouvent les données, mais aussi comment l'organisation les interprète, quelles relations importent, quelles définitions font autorité et quelles preuves les soutiennent.

Cela signifie que des actifs qui étaient auparavant considérés principalement comme des infrastructures de gouvernance ou d'analyse deviennent des actifs AI stratégiques. Les définitions de métriques, la documentation, le lignage, les certifications, les modèles d'utilisation et les glossaires métier apprennent collectivement à l'AI comment l'entreprise fonctionne. L'architecture émergente n'est donc pas seulement un plan de données plus un modèle AI. Elle a également besoin d'une couche de contexte partagée capable de fournir la même compréhension métier à de nombreux agents et applications.

L'ontologie des données améliore-t-elle réellement la précision des agents ?

Richard Tomlinson : Une ontologie en soi ne rend pas magiquement un agent précis. Ce qui améliore la précision, c'est de fournir à l'agent le bon contexte faisant autorité au moment où il raisonne. Si l'ontologie peut dire à l'agent quelle définition s'applique, où se trouvent les données de confiance et quels calculs ou relations importent, l'agent passe moins de temps à deviner et à explorer des pistes incorrectes.

Nous avons la preuve de cet effet avec Genie Ontology, la couche de contexte automatique sous-jacente de Genie One et Genie Agents de Databricks. Dans un benchmark interne de Databricks utilisant 28 questions réelles d'analyse de données d'entreprise, Genie avec Ontology a répondu correctement à 84,5 % dès la première tentative. Le plus performant des agents de codage à usage général dans la même évaluation a obtenu un score de 52,4 %. Genie était également environ deux fois plus rapide que cet agent. Il s'agit d'un benchmark interne plutôt que d'une garantie de précision universelle, mais cela illustre le principe fondamental : un meilleur contexte d'entreprise peut importer autant, voire plus, que le simple fait de donner plus de temps au modèle pour raisonner.

Devez-vous créer une ontologie formelle à partir de zéro ?

Richard Tomlinson : Non, et exiger cela recréerait le problème d'évolutivité que nous essayons de résoudre. La plupart des entreprises ont déjà créé une grande partie de leur compréhension métier. Elle existe dans les définitions de métriques, les données certifiées, les tableaux de bord, les requêtes, les notebooks, la documentation et les manières répétées dont les équipes utilisent ces actifs.

L'objectif devrait être de préserver le contrôle humain sur les concepts qui comptent le plus tout en apprenant automatiquement une grande partie de la longue traîne. Avec Genie Ontology, cela signifie modéliser explicitement les KPI critiques et les termes métier tandis que la couche déduite apprend des définitions, règles, relations et sources faisant autorité supplémentaires à partir du travail existant. Vous tirez de la valeur des connaissances que l'organisation possède déjà, plutôt que d'attendre la fin d'un projet d'ontologie distinct.

Quel rôle joue la gouvernance dans un agent AI basé sur une ontologie ?

Comment la gouvernance s'intègre-t-elle dans un agent basé sur une ontologie ?

Richard Tomlinson : La gouvernance a deux rôles. Le plus évident est l'accès : l'ontologie ne doit jamais devenir une porte dérobée pour contourner les autorisations existantes. Si un utilisateur ne peut pas accéder aux informations sources, l'agent ne devrait pas être en mesure de récupérer le contexte qui en découle. Avec Genie Ontology, les autorisations sont appliquées lors de la récupération, en utilisant la gouvernance des sources sous-jacentes, y compris Unity Catalog. Deux employés peuvent donc poser la même question et recevoir, de manière appropriée, des réponses différentes en fonction de ce que chacun est autorisé à voir.

Le second rôle est tout aussi important : la gouvernance aide l'AI à comprendre à quoi faire confiance. La certification, les définitions faisant autorité, le lignage, l'utilisation, l'expertise et la provenance des sources deviennent des signaux qui aident à distinguer la définition officielle du chiffre d'affaires d'un calcul ponctuel créé par quelqu'un il y a six mois. À l'ère de l'AI, la gouvernance ne consiste plus seulement à contrôler les données. Elle fait de plus en plus partie du mécanisme qui apprend à l'AI quelles connaissances métier font autorité.

Pourquoi l'ontologie des données devient-elle une infrastructure AI ?

Le mot "ontologie" appartenait autrefois aux équipes de modélisation sémantique et aux débats sur la taxonomie. Il devient rapidement quelque chose de plus proche d'une infrastructure : la couche qui décide si la réponse d'un agent reflète le fonctionnement réel de l'entreprise, ou s'il s'agit simplement d'une supposition plausible présentée comme telle. Les organisations qui traitent le contexte comme un élément à gouverner et à apprendre en continu, et non comme un élément documenté une fois pour toutes et laissé à l'abandon, seront celles dont on pourra s'assurer que les agents agissent, et ne se contentent pas de faire des rapports.

Découvrez comment Genie Ontology fonde les réponses de l'AI sur ce que signifie réellement votre entreprise. Explorez Genie.

À lire ensuite :

• Présentation d'OfficeQA : un benchmark pour le raisonnement ancré de bout en bout
• Présentation d'OfficeQA Pro V2 : un nouveau benchmark pour le raisonnement ancré en entreprise
• Page produit de Genie One
• Présentation de Genie Ontology

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original