Les graphes de contexte suscitent beaucoup d’attention en ce moment, certains investisseurs les qualifiant d’« opportunité à mille milliards de dollars ». ;
En effet, même si les modèles IA peuvent désormais utiliser des outils, ils manquent encore des connaissances de processus nécessaires pour automatiser réellement le travail. Les systèmes d’enregistrement capturent les décisions, mais le travail réel se déroule dans les réunions, les discussions, les e-mails et les documents. Sans une vision structurée de la façon dont le travail est effectivement réalisé, l’IA ne peut pas l’automatiser de manière fiable. ;
Avec tout ce battage, les publications sur les réseaux sociaux tournent sans cesse autour des deux mêmes questions : qu’est-ce qu’un graphe de contexte, exactement, et comment en construire un ? Dans cet article, nous allons présenter l’approche de Glean pour construire des graphes de contexte et expliquer pourquoi nous avons choisi cette voie.
Qu’est-ce qu’un graphe de contexte ?
Un graphe de contexte est un modèle qui relie les entités de votre entreprise (personnes, documents, tickets, systèmes) aux traces temporelles des actions et des événements qui les relient. Il en tire ensuite des enseignements exploitables afin que l’IA comprenne comment le travail est réellement accompli.
Les graphes de contexte aident l’IA à répondre à des questions telles que :
- « Comment les incidents P1 sont-ils généralement résolus ici ? »
- « Quels sont les escalades les plus courantes concernant le produit X ? »
- « Que se passe-t-il généralement entre “pilot créé” et “contrat signé” ? »
- « Que signifie réellement “onboarding terminé” pour cette équipe ? »
- « Combien de temps dure généralement un déploiement et pourquoi ? »
Les agents actuels ont du mal avec les processus de bout en bout ou les tâches de longue durée (s’étalant sur des semaines ou des mois) qui exigent de synthétiser des connaissances provenant de plusieurs systèmes disparates. ;
Lorsque vous reliez plusieurs tâches qui traversent différents événements, vous devez réunir des informations provenant de diverses sources et de nombreuses personnes, chacune exécutant le travail un peu différemment, avec des exceptions locales et des cas particuliers intégrés à leur processus. Or, les systèmes d’enregistrement n’affichent généralement que l’état actuel et capturent rarement cette variabilité d’exécution ou le contexte historique complet s’appuyer sur cette vision incomplète peut donc créer des angles morts et conduire à des résultats sous-optimaux.
À l’inverse, disposer d’un modèle interne des vrais processus de votre organisation — un graphe de contexte construit à partir de traces réelles d’actions — devient le meilleur proxy pour apprendre à la fois la structure à suivre et l’intention derrière le travail. ;
Du « quoi » au « comment »
Un graphe de contexte décrit le flux du travail en passant de la description de ce qui existe à celle de la façon dont le changement se produit :
- « Quoi » : les systèmes traditionnels de données et de connaissances modélisent des choses : clients, tickets, docs, personnes, systèmes.
- « Comment » : un graphe de contexte modélise le comportement : qui a fait quoi, dans quelles applications, dans quel ordre, et avec quel effet.
Le « comment » est décrit en transformant les actions en entité de premier plan dans le graphe :
- Nœuds : (c.-à-d. actions d’utilisateur et d’agent avec des traces de données riches) « créé », « consulté », « approuvé », « escaladé », « commenté », « résolu », chacun avec des horodatages et des métadonnées riches sur les changements.
- Arêtes : les arêtes sont la causalité et la corrélation. « Le message A » a déclenché « la mise à jour B » avec une probabilité P.
Nous avons choisi de faire modéliser Glean de cette manière afin d’associer un pouvoir prédictif à une séquence d’activités, pour pouvoir suggérer quelle étape est susceptible de se produire ensuite sans coder en dur un flux. Ce que nous obtenons au final est une distribution de parcours probables, donnant à l’agent l’autonomie de choisir le plus probable pour la situation.
Ensuite, superposés à ces parcours de processus, se trouvent des enseignements dérivés — un raisonnement expliquant pourquoi le « parcours A » différait du « parcours B ». Cela nous permet d’encoder non seulement le « comment », mais aussi un « pourquoi » probable, qui peut être transmis à l’agent à l’exécution. ;
Après l’exécution de l’agent, ses actions deviennent de nouvelles traces pour le graphe de contexte. L’apprentissage par renforcement sur ces traces évalue alors si le parcours choisi était optimal et identifie des parcours alternatifs que l’agent pourra emprunter à l’avenir.
Comment construisons-nous un graphe de contexte ?
Investir dans des connecteurs profonds et l’observabilité
Les graphes de contexte nécessitent une base de connecteurs profonds et d’observabilité. Si nous ne pouvons pas voir comment le travail se déroule, nous ne pouvons pas le modéliser. Cela signifie une intégration au niveau des documents avec les applications où le travail a réellement lieu, ainsi qu’avec les données structurées : CRM et systèmes de ticketing, chat, docs, e-mail, calendriers, code, tableaux de bord et applications internes. ;
Nous comprenons comment chaque application est réellement utilisée — par exemple, les commentaires Jira deviennent rapidement obsolètes, tandis que les liens dans une description Jira sont généralement canoniques (c.-à-d. docs, maquettes, etc.). Nous capturons ces schémas dans un modèle de données centralisé, que nous plaçons ensuite dans notre index de recherche. ;
À partir de là, la partie difficile consiste à maintenir ce modèle en bonne santé dans le temps : traquer les API incohérentes, réconcilier les identités qui diffèrent selon les outils et faire respecter en permanence les permissions de contenu afin que chaque résultat soit à la fois pertinent et correctement sécurisé.
Il y a quelques années, nous sommes passés à la capture non seulement des données documentaires, mais de tous les événements de changement dans une application. Nous les normalisons ensuite et les exposons sous forme de traces, dans le but de construire un graphe de contexte.
Construire un graphe de connaissances unifié
Après avoir exploré et indexé les données, nous construisons un graphe de connaissances en exécutant un pipeline de machine learning pour inférer des entités de niveau supérieur comme les projets, clients, produits, équipes et personnes. Nous identifions également les relations entre elles — en déterminant quels docs, tickets, appels et tableaux de bord appartiennent à un produit ou à un compte donné.
Nous alimentons en continu le système avec des signaux d’activité (consultations, modifications, commentaires, etc.) pour comprendre comment l’information est réellement utilisée et comment les gens collaborent. C’est ainsi que Glean comprend que « ACME Inc » dans le CRM et « ACME » dans les tickets de support sont le même client. ;
Cela nous permet de regrouper les activités sous un même projet ou client canonique, avec un haut niveau de confiance sur ce qui se passe réellement.
C’est pourquoi les graphes de connaissances sont une base essentielle des graphes de contexte : les signaux d’activité, pris isolément, sont bruités il faut un graphe de connaissances sous-jacent pour leur donner du sens.
Créer un graphe personnel
En parallèle du graphe de connaissances, nous construisons un graphe personnel qui comprend vos tâches et vos projets afin d’offrir une aide proactive et personnalisée. Pour construire le graphe personnel, nous collectons et synthétisons des flux d’activité et des traces, nous assemblons ces signaux bruts en chronologies, puis nous les enrichissons avec des entités issues du graphe de connaissances :
- Pour chaque personne, une séquence chronologique d’actions à travers les outils, avec des métadonnées plus riches.
- À partir de là, nous commençons à regrouper les événements de bas niveau en tâches sémantiques. ; ; ;
C’est là que cela se complique. Le travail réel est chaotique : les gens changent constamment de contexte, réutilisent le même document pour plusieurs efforts, et laissent des fils en suspens pour les reprendre des jours plus tard. Un seul événement « modification d’un doc » peut appartenir à plusieurs flux de travail parallèles.
Pour en tirer du sens, nous combinons :
- Des signaux simples comme les titres partagés, les liens entre tickets et documents, les invitations de réunion, les noms de canaux et les fenêtres temporelles. ;
- Des LLMs qui examinent des séquences d’événements et infèrent : « ce groupe ressemble à une investigation d’alerte », ou « ces actions ensemble ressemblent à la rédaction et à la diffusion d’une spécification ».
L’objectif est de découper le flux en unités de travail cohérentes — tâches et projets de niveau supérieur — sur lesquelles le système peut raisonner.
À ce stade, nous n’avons examiné qu’une seule personne au travail. Et, comme nous préservons la confidentialité des utilisateurs, ces données ne sont visibles que par eux. Mais lorsque nous commençons à les analyser en agrégé, nous pouvons faire émerger des tendances. ;
Créer un graphe de contexte
Lorsque nous analysons les processus à grande échelle, nous prenons chaque graphe personnel et le normalisons en une séquence d’« étapes » anonymisées avec des libellés grossiers : ;
- type d’action (consultation, modification, commentaire, escalade)
- famille d’outil (docs, chat, tickets, code)
- entités du graphe de connaissances impliquées (type d’incident, produit, service, segment client)
- balises de processus dérivées de LLMs ou d’heuristiques (p. ex. « investigate_alert », « draft_spec », « negotiate_contract », « onboard_customer »)
- signaux temporels légers et résultats (p. ex. « P1 résolu, MTTR < ; 30 minutes » ou « contrat signé-gagné »)
Ce que nous n’amenons pas dans les traces abstraites, ce sont le texte brut (corps des docs, texte des messages), les identifiants d’utilisateur ou les secrets spécifiques à un client. Nous calculons ensuite la similarité entre les traces abstraites pour déterminer lesquelles sont susceptibles d’impliquer le même processus.
En plus de cela, nous ne considérons un schéma comme viable que s’il apparaît chez au moins k utilisateurs distincts et dans n traces indépendantes, toute occurrence trop rare étant écartée pour préserver l’anonymat.
En faisant cela, nous construisons une vue probabiliste de « ce qui a tendance à se produire », « dans quel ordre » et « pourquoi ce parcours diverge d’autres parcours similaires ». Nous utilisons ensuite le temps pour déterminer la valeur du processus. Si des groupes d’utilisateurs similaires mettent beaucoup de temps à effectuer un processus, il s’agit très probablement d’un processus à forte valeur. Cela devient le graphe de contexte du système — les playbooks sur lesquels les agents peuvent s’appuyer lorsqu’ils rencontrent une situation similaire.
Au fur et à mesure que nous avons construit ce graphe, nous avons évalué différentes façons de stocker les données d’événements pour la traversée. Les structures de graphe pures sont rigides le texte brut est flexible mais difficile à parcourir. Nous utilisons donc un modèle hybride : prendre du texte libre, le découper en segments plus petits et y intégrer des IDs d’entités. ;
Un incident, par exemple, devient de courts segments qui marquent les transitions — de « investigation » à « atténuation » — en les balisant avec des IDs comme incident_id=INC-123, channel_id=#p1-incidents, ou action_type=escalated. Cela permet à l’agent de parcourir le processus étape par étape avec des repères clairs, avec pour compromis que ce n’est pas optimisé pour raisonner sur des milliers d’incidents à la fois.
Apprendre à partir des traces agentiques ;
La dernière grande étape consiste à fermer la boucle avec l’exécution des agents. Si les agents s’exécutent en dehors de ce système, le graphe n’apprend jamais d’eux. S’ils s’exécutent à l’intérieur, chaque passage de l’agent devient une trace supplémentaire :
- Quels outils il a appelés, dans quel ordre, avec quelles entrées et sorties.
- Si l’exécution s’est terminée avec succès, son efficacité, et si l’utilisateur a donné un vote négatif ou positif à la réponse
Tous ces apprentissages sont limités à chaque entreprise et se concentrent sur la façon dont l’agent utilise les outils, plutôt que de stocker le contenu sous-jacent. ;
Hors ligne, nous rejouons ensuite les exécutions et testons des routes alternatives. Nous évaluons les alternatives selon leur exactitude, leur exhaustivité, le respect des consignes et l’efficacité. Nous traitons ces traces d’agents de la même manière que celles des humains :
- Les exécutions réussies renforcent les schémas que vous souhaitez voir privilégiés par le système, devenant des playbooks en langage naturel.
- Les exécutions nécessitant une intervention mettent en évidence des anti-patterns où davantage de contexte ou une meilleure utilisation des outils est nécessaire
Avec le temps, le graphe de contexte devient un modèle conjoint du comportement humain et agentique. Il ne décrit pas seulement comment le travail se faisait auparavant il reflète la manière dont le travail se déroule maintenant, à mesure que les humains et les agents en partagent davantage.
C’est pourquoi le graphe de contexte doit être détenu conjointement par la couche de données et la couche d’orchestration. Pour les flux à forte valeur — réponse aux incidents, contrats commerciaux, développement produit — vous avez besoin des deux : une couche de contexte qui capture un modèle structuré et sensible aux processus de l’entreprise, et une couche d’exécution capable de planifier, d’itérer et de générer des traces. Les séparer crée une dérive : le graphe évolue dans un sens, l’exécution des agents dans un autre, et vous vous retrouvez avec deux versions divergentes de la réalité.
Maintenir le graphe et l’orchestration dans un seul système garantit que les agents restent ancrés dans un modèle vivant et évolutif de la façon dont votre entreprise fonctionne réellement.
Construire des graphes de contexte chez Glean
Construire des graphes de contexte est un investissement important, et nous avons d’ailleurs testé le concept en interne avant de le développer. Nous avons créé manuellement un graphe de contexte pour Glean en nous appuyant sur une technologie que nous avions déjà construite : le graphe personnel.
Nous avons demandé aux employés de Glean de consentir au partage de leurs données de graphe personnel, qui retraçaient les projets sur lesquels ils travaillaient, la séquence d’étapes suivies et le temps passé. Avec l’élément temporel, nous avons pu distinguer les processus à faible valeur de ceux à forte valeur. Nous avons ensuite examiné les équipes qui avaient les mêmes processus répétitifs et à forte valeur, comme « cycle de transaction AE mid-market », « proof-of-concept SE », « réponse aux incidents on-call », « lancement de fonctionnalité PM », etc.
Nous avons pris les séquences d’événements associées à ce travail, et nous avons validé avec des experts métier la voie A par rapport à la voie D pour accomplir le travail, lorsqu’il existe des écarts, et pourquoi. Nous avons également examiné les zones d’ombre, ou les étapes manquantes, parce que nous n’avions pas exploré les bonnes données ou parce que nous n’avions pas les actions nécessaires pour prendre en charge une étape donnée. Ensuite, nous avons consacré des ressources à transformer ces processus à forte valeur (validés à la fois pour Glean et pour la demande client) en agents qui fonctionnent réellement dans Glean. ;
Bien que ces agents deviennent une représentation statique de l’état actuel, ce n’était pas notre objectif final. Nous voulions des graphes de contexte. En effet, les parcours optimaux évoluent, la propriété change, de nouveaux outils apparaissent, et ainsi de suite. Notre objectif avec le graphe de contexte n’est pas seulement de créer un ensemble statique d’agents, mais de continuer à alimenter les agents avec de nouvelles informations de processus issues du graphe et de transférer davantage de logique vers cette couche apprise, au lieu de dépendre en permanence d’instructions manuelles. C’est ainsi que, selon nous, on obtient des agents de longue durée qui opèrent de manière autonome. Et ici, chez Glean, nous sommes proches d’en faire une réalité.
Vous souhaitez en savoir plus sur les graphes de contexte ? Consultez notre précédent article de blog ici — ou inscrivez-vous dès aujourd’hui à une démo gratuite de Glean.
