Sans contexte, pas d’agents IA : vers une couche sémantique universelle

Qu’est-ce que le contexte pour un agent IA ?

« En entreprise, nous pensons que l’IA ne souffre pas d’un problème d’intelligence. L’IA souffre d’un problème de contexte. »

Le contexte « désigne les informations structurées, la mémoire et les données contextuelles que les systèmes d’IA utilisent pour générer des réponses pertinentes et précises », explique Salesforce sur son site Web. « Cela inclut la requête immédiate, les interactions précédentes, l’intention de l’utilisateur et toutes les sources de données connectées qui aident le système à “comprendre” ce qui se passe ».

À l’échelle de l’agent IA, la mémoire est généralement divisée en espace à court, à moyen et à long terme. La mémoire à court terme renvoie aux précédents échanges ou actions prises au sein d’une session ou d’un thread avec un agent IA. La mémoire à long terme consolide les informations issues de plusieurs threads, ainsi que celles issues des sources de données.

La terminologie varie selon les éditeurs et il existe plus ou moins de couches ou de types de mémoires suivant les cas d’usage.

En ce sens, Salesforce définit cinq couches de contexte et de connaissances. Le contexte est activé « au moment de l’exécution de l’agent IA, par utilisateur par question ». Il inclut les capacités des agents (1) ; son prompt, son objectif, ses outils. Puis, il y a les données et les informations (2) à sa disposition pour « agir ».

Ces données proviennent de trois couches persistantes de connaissances : les données structurées ou non structurées (3), les modèles sémantiques qui renferme les définitions métiers des données (4) et l’ontologie (5), à savoir un métamodèle de données contenant les concepts et relations permettant de structurer le savoir de l’entreprise.

Pour Jim Allen Wallace, senior product marketing manager chez Redis, la couche de contexte combine les pipelines RAG, la mémoire à court et à long terme, les outils et leurs définitions, la gestion des permissions et la gouvernance, les définitions sémantiques ainsi que les instructions systèmes.

Les outils de la distribution du contexte

Dans tous les cas, il n’y a pas de miracle : les agents IA ont besoin des outils et d’un mode d’emploi pour exploiter ces informations.

Du côté des outils, un standard émerge, en premier lieu dicté par Anthropic. Les serveurs MCP, eux, incluent les outils (les fonctionnalités activables sur un système distant) et leur configuration de connexions. C’est le sujet du mode d’emploi qui coince. Sur ce point, les agents IA ne sont pas différents des collaborateurs : sans l’accès à la bonne documentation, le résultat sera largement perfectible.

En ce sens, les skills servent à documenter les flux de travail – l’enchaînement de l’utilisation de plusieurs outils ou de plusieurs serveurs MCP –, les bonnes pratiques et des exemples. Les conventions d’usage liées aux outils et au cas d’usage sont documentées dans les skills ou dans un autre fichier Markdown (Claude.md chez Anthropic), tandis que les règles globales et permanentes résident dans les instructions système.

Cette standardisation en cours et la relative nouveauté de la technologie permettent toutefois de généraliser l’approche. Concernant le code, un LLM exploitera au mieux la documentation quand elle est près du code, versionnée, structurée, stable et facile à relier à une fonction ou un module. Cela conduit à l’adoption de la logique du « monorepo » où le code et sa documentation sont réunis dans un même dépôt d’un système de gestion de versions de type Git.

Cela peut réclamer de retravailler sa documentation, mais un agent peut aussi accéder à la base de connaissances présente dans un serveur Jira ou depuis un Wiki. Quant à l’accès aux différentes « couches de connaissances », le moyen est tout trouvé. Les éditeurs et les entreprises déploient également des serveurs MCP à ces niveaux.

Des données et des connaissances éparpillées

La manière d’utiliser les outils prend forme. En revanche, les données elles-mêmes demeurent le véritable défi. La très grande majorité des informations collectées par les entreprises ne sont pas référencées. Si elles sont répertoriées, ces connaissances sont historiquement éparpillées au sein des systèmes des entreprises.

Dans le meilleur des cas, les entreprises et les éditeurs peuvent compter sur des efforts préalables. Il y a d’un côté la documentation des processus métier au sein de bases de connaissances ou plus rarement par le process mining. Si elles en ont déployé, elles peuvent aussi exploiter les systèmes RAG. Quand ils sont bien faits, ils contiennent les documents relatifs à un département ou à une fonction transverse.

De l’autre, il faut noter la standardisation de certains indicateurs clés de performance, de métriques au sein d’outils de visualisation et d’analytique, ainsi que la documentation des jeux de données clés à travers des catalogues de données et des plateformes de gouvernance.

Dans les catalogues, vivent généralement des définitions métier, des tables, des sources techniques (l’adresse d’un entrepôt de données), les règles d’usage et d’accès, la classification des données et l’historique des transformations de données (data lineage).

Les outils de gouvernance, eux, servent à centraliser les règles internes et de conformité, ainsi que la gestion des accès, puis à l’automatiser à travers une couche de métadonnées.

Sans oublier les plateformes BI et analytiques. Elles disposent d’une couche sémantique, une représentation métier des données utilisées pour constituer les rapports et les prédictions. Celle-ci inclut elle aussi des définitions métier, de relations entre les tables en provenance de diverses sources et des règles, mais à l’échelle d’un jeu de données ou d’un cas d’usage spécifique.

Si tous ces systèmes peuvent s’appuyer sur la même couche de métadonnées, ils ciblent des rôles différents au sein de l’entreprise. De ce fait, rares sont les entreprises qui peuvent donner accès à leurs agents IA de manière consistante et cohérente.

La couche sémantique au centre de l’attention

Quant à la couche sémantique évoquée plus haut, c’est une évolution récente du concept présenté par BusinessObjects en 1991. Les outils comme BO, Tableau, Power BI se sont longtemps cantonnés à leurs univers, signale Databricks. « Bien qu’elles soient optimisées pour les fonctionnalités spécifiques de leurs outils BI respectifs et qu’elles soient plus faciles à mettre en œuvre, elles sont limitées à l’écosystème de la plateforme. Cette limitation peut entraîner la création de silos sémantiques au sein des organisations utilisant plusieurs outils BI ».

Cette couche sémantique 2.0 doit, elle, centraliser les métriques métiers et leurs définitions. « Le fait de transférer les définitions des indicateurs de la couche BI vers la couche de modélisation permet aux équipes chargées des données d’avoir l’assurance que les différentes unités opérationnelles utilisent les mêmes définitions d’indicateurs, quel que soit l’outil qu’elles choisissent d’utiliser », vante pour sa part dbt. C’est un processus de configuration manuelle et qui sert avant tout les besoins de prise de décision humaine.

En réponse à cet enjeu, Databricks a présenté lors de son Data & AI Summit, Genie Ontology. Il s’agit « d’une couche contextuelle automatique qui ajoute une couche apprise par-dessus n’importe quel contexte dont vous disposez, que ce soit dans Unity Catalog ou dans l’un de vos modèles sémantiques ou outils de modélisation existants », a affirmé Ken Wong, directeur senior de la gestion produit chez Databricks lors du Data+AI Summit. Cet algorithme note les éléments d’autorités au sein des modèles sémantiques existants. Le mécanisme de Snowflake, Cortex Sense, est différent, mais vise le même objectif : générer cette ontologie.  

Tableau, lui, mise sur Auto Knowledge Graph. L’outil doit, à partir de modèles sémantiques existants en provenance de Tableau et d’autres plateformes BI, créer automatiquement « un graphe de connaissances ». Il faut davantage voir le mécanisme comme un moyen de constituer des métamodèles sémantiques.

Or, la méthode traditionnelle, celle dérivée des univers BO, a le mérite de maintenir des définitions métiers par département et les actifs correspondants. En ce sens, Starburst développe un graphe sémantique – c’est-à-dire un moyen de relier plusieurs modèles sémantiques – qui doit prendre en compte la notion de sous-domaines au sein d’une entreprise. Dans son cas, cela implique de gérer des métadonnées en provenance de différents systèmes. « La résolution de conflits est notre priorité », affirme Emma Tippet, chief of Staff chez Starburst. « Ce flux sera le plus automatisé possible, mais il restera sous la supervision des métiers ».

Chez Tableau et Salesforce, Auto Knowledge Graph, doit aussi indiquer les règles sémantiques et les définitions de données qui entrent en conflit. « Vous aurez la possibilité d’utiliser un modèle sémantique pour les métiers de la finance différent de celui des commerciaux », assure Mark Recher, vice-président exécutif et directeur général de Tableau & Analytics chez Salesforce, lors d’un point presse à Paris.

Salesforce et Tableau, Starburst, Databricks, DataHub, Dataiku, dbt, Atscale, soutiennent tous le projet ouvert de Snowflake, Open Semantic Interchange. Il vise à normaliser les échanges de modèles de données et donc intégrer des modèles sémantiques issus de différents outils.

Deux visions technico-commerciales de la couche sémantique

Or deux philosophies s’opposent.

Celle incarnée par Databricks, Starburst et Snowflake consiste à rapprocher la couche sémantique des données, en référençant les règles et les définitions métiers au niveau du catalogue de données intégré au lakehouse.

« Avec l’émergence des agents IA et la manière dont ils fonctionnent, il devient logique de placer ces modèles sémantiques directement là où se trouvent les données. »

« Avec l’émergence des agents IA et la manière dont ils fonctionnent, il devient logique de placer ces modèles sémantiques directement là où se trouvent les données », affirmait pour sa part Benoît Dageville, cofondateur et président du produit chez Snowflake. « C’est ainsi que l’on obtient les meilleurs résultats ».

Pour Craig Wiley, vice-président produit de l’IA chez Databricks, un agent IA « peut très bien agréger les données dispersées sur plusieurs tables ». La centralisation vise néanmoins à faciliter la compréhension humaine et l’interaction avec les agents IA. « Avec le temps, la couche de données elle-même pourrait ressembler beaucoup plus à quelque chose qui serait défini par l’agent, par rapport aux systèmes de données définis par l’humain que nous avons actuellement ».

L’autre philosophie – portée par dbt, Atscale et d’autres – propose de maintenir une couche de métadonnées indépendante de l’infrastructure de données, même quand elle est composée d’une myriade de dépôts. Les spécialistes de la BI veulent également faire partie dans cette deuxième catégorie.

« La couche sémantique infusée dans les lakehouses pose deux défis majeurs », affirme Southard Jones EVP et chief product officer de Tableau chez Salesforce. « D’abord, elle représente un coût architectural élevé puisque chaque requête LLM et SQL consomme des ressources cloud. Ensuite, cela implique un écart métier critique : la sémantique définie par les ingénieurs de données ne reflète pas toujours les besoins réels des utilisateurs métier », note-t-il.

Les vues sémantiques, qui seront à la base de l’outil de génération automatique d’ontologie de Snowflake visaient également à repousser la responsabilité du modèle métier vers les équipes techniques. En réalité, l’éditeur tente de pousser une double approche. Il veut faciliter la génération de ces vues sémantiques par des métiers à l’aide d’outils IA avant de les faire valider par des ingénieurs.

« Aujourd’hui, la réalité des entreprises est hybride : la sémantique existe dans Snowflake, Databricks et de nombreux autres systèmes. »

« C’est précisément ce fossé qui a fait le succès de Tableau : permettre aux analystes de créer leurs propres définitions de métriques », continue Southard Jones. « Aujourd’hui, la réalité des entreprises est hybride : la sémantique existe dans Snowflake, Databricks et de nombreux autres systèmes. L’approche pragmatique consiste à exploiter ces sources multiples plutôt que de tout centraliser dans un seul lakehouse ».

Et le dirigeant d’affirmer qu’Auto Knowledge Graph n’est pas dépendant de Data 360, la CDP de Salesforce. La fonctionnalité sera disponible dans Tableau Cloud, Desktop et Server. Certains clients de Tableau lui auraient déjà suggéré de vendre séparément sa couche sémantique, ce que l’éditeur est tenté de faire. Son concurrent (Micro)Strategy le fait déjà.

« Votre couche sémantique doit aider vos modèles d’IA et vos agents à construire du sens autour des sujets, des entités, de la propriété, de la pertinence et de la qualité, peu importe où se trouvent les données elles-mêmes », tranche Kevin Petrie, analyste chez BARC US, sur LinkedIn.

« L’approche pragmatique consiste à exploiter ces sources multiples plutôt que de tout centraliser dans un seul lakehouse. »

Cette insistance des acteurs de la gestion de données concernant la couche sémantique s’explique aisément. L’initiative se rapproche de ce que leurs clients ont déjà mis en place en matière de BI. Reste à voir les usages. L’automatisation des tableaux de bord et la réponse aux questions métiers sont les plus pertinentes actuellement. La notion « d’insight to actions », poussée par Tableau, se limite aux automatisations les plus simples : l’envoi d’alertes, la génération d’analyse et de recommandation, par exemple. D’autres acteurs comme Celonis imaginent pouvoir déclencher des flux logistiques (prises de commandes, entre autres), toujours sous le regard vigilant des employés.

Pour Kevin Petrie, la couche sémantique doit aussi « extraire des indicateurs et des informations depuis les fichiers non structurés, comme les documents, les images et les e-mails qui représentent le cœur battant de l’entreprise ».

Or, d’après Atlan, la couche de contexte « résout les définitions d’entités, applique les politiques d’accès et suit la lignée et la provenance, mais ne peut pas récupérer les documents non structurés lors de l’exécution ». Les systèmes RAG sont complémentaires, mais restent essentiellement non gouvernés. Au mieux, il est possible de l’inférer sur les métadonnées du document (titre, date de création, modification, etc.). Pour aller plus loin, il faudrait s’appuyer sur les données ingérées dans la base de données vectorielles et réappliquer les politiques de gouvernance après-coup. Les éditeurs cherchent encore à simplifier cette gestion des documents.

Qu’elles soient structurées ou non, l’ensemble des acteurs insistent sur la mise en qualité préalable des données. Cela implique que les entités métiers deviennent, s’ils ne le sont pas déjà, les garants des définitions métier, des métriques, des règles et des données associées. En clair, sans une gouvernance à la mode Data Mesh, il est peu probable que le contexte à la disposition des agents IA soit bon. « C’est un passage obligé, sinon les DSI et les CDO auront beaucoup de mal à déployer les agents IA à l’échelle », conclut Mark Recher.