La promesse des coworkers IA est que les employés peuvent accomplir davantage lorsque l'IA est connectée à leurs sources de données externes, notamment Google Docs, Gmail, Google Calendar, Salesforce et Atlassian. Cette connexion permet l'analyse de données à grande échelle, une gestion plus intelligente des boîtes de réception et des calendriers, une création de contenu plus rapide et une meilleure récupération d'informations. Cependant, concrétiser cette promesse nécessite une IA dont la sortie puisse être reprise et utilisée presque telle quelle par un employé, avec un coût en jetons proportionné à la tâche.
Chez Glean, nous voulions comprendre comment la couche de contexte façonne l'efficacité et l'efficience des coworkers IA pour générer ces résultats « prêts à reprendre et utiliser ». Il est bien établi que la qualité du contexte sous-jacent, les indexes et les graphes de connaissances, détermine la précision des réponses. Ce qui est moins bien compris, c'est le compromis économique des indexes avec une meilleure pertinence et un meilleur classement : les indexes échangent un faible coût initial de stockage des données contre une moindre dépendance aux coûts de calcul, qui augmentent rapidement dans l'entreprise à mesure que la consommation de jetons des frontier models croît.
Pour prouver la valeur de la couche de contexte, nous avons benchmarké Glean face à des outils MCP standard, en isolant le contexte grâce à une normalisation du harness sur Claude Cowork. Avec Claude Cowork comme constante, nous avons comparé le serveur MCP distant de Glean, qui inclut l'accès à des outils de recherche et d'écriture, aux serveurs MCP standard disponibles dans Cowork sur environ 175 requêtes. Nous avons constaté que :
- Glean a été préféré environ 2,5 fois plus souvent que les outils MCP standard
- Les outils MCP standard ont consommé environ 30 % de jetons de plus que Glean
L'impôt en jetons de la recherche fédérée
Le Model Context Protocol (MCP) est une norme ouverte qui permet aux modèles IA de se connecter à des outils externes pour accéder aux données et agir via une interface cohérente. MCP standardise la connectivité des outils, offrant aux modèles une manière cohérente d'appeler des systèmes externes. Cependant, MCP ne standardise pas la qualité des outils sous-jacents eux-mêmes. La conception d'un outil façonne la qualité de la réponse qu'il permet et le nombre d'appels d'outils et de boucles de raisonnement nécessaires pour y parvenir.
Il existe traditionnellement deux approches pour répondre au besoin de contexte d'entreprise : la fédération et l'indexation. La fédération repose sur la recherche fournie nativement par chaque connecteur individuel, en interrogeant chaque système indépendamment à l'aide de sa propre stratégie de récupération. L'indexation centralisée adopte une approche différente : les données de toutes les sources sont ingérées et normalisées dans une couche unique, ce qui permet des signaux inter-applications et un classement cohérent, quelle que soit l'origine des données.
Plusieurs défis bien connus accompagnent l'adoption d'une approche uniquement fédérée :
- La qualité de la recherche sous-jacente varie considérablement, certains outils ne prenant en charge qu'une récupération lexicale ou sémantique, mais pas les deux.
- Le nombre d'appels d'outils nécessaires pour rassembler les données augmente, car chaque outil doit être appelé individuellement, puis le modèle doit normaliser et agréger ces données.
- L'accès aux données est limité aux signaux spécifiques à l'utilisateur, ce qui signifie que vous perdez la visibilité sur la manière dont ces données sont utilisées à l'échelle de l'entreprise : l'autorité de l'auteur, les liens entre documents et d'autres signaux de classement inter-applications. Cela affecte la précision des résultats.
- La latence se cumule rapidement lorsque vous devez gérer plusieurs appels API vers différents outils. Chaque outil a sa propre latence et vous êtes donc tributaire de l'appel d'outil le plus lent.
La recherche fédérée compense souvent en sur-récupérant les données via plusieurs appels d'outils et en s'appuyant sur plusieurs boucles de raisonnement pour synthétiser les résultats. Les deux constituent des contournements coûteux en termes de latence et d'utilisation de jetons, et ils ont malgré tout tendance à produire des réponses inexactes. Les modèles disposent d'une fenêtre de contexte fixe et d'une capacité d'attention finie. Sur-récupérer des données risque de diluer cette fenêtre et même d'agréger des informations contradictoires ou obsolètes, ce qui rend plus difficile pour le modèle de raisonner sur les informations pertinentes.
À mesure que l'IA prend en charge des tâches plus longues et multi-étapes, ces limites deviennent de plus en plus coûteuses. Chaque récupération manquée ou incorrecte peut se répercuter d'une étape à l'autre jusqu'à ce que l'artefact final ou l'action d'écriture reflète des données incorrectes. Pendant ce temps, les coûts en jetons augmentent à mesure que les tarifs des frontier models augmentent et que la consommation s'accélère, des équipes d'ingénierie chez des entreprises comme Uber et ServiceNow épuisant apparemment leurs budgets annuels d'outils de codage IA au cours des premiers mois de l'année. C'est ce qui rend la bonne couche de contexte de plus en plus importante à l'ère de Cowork.
Conception de l'évaluation
Notre benchmark a été conçu pour isoler le contexte, en conservant Claude Cowork comme harness avec Claude Sonnet 4.6 comme modèle par défaut, et en ne faisant varier que la couche de contexte : des serveurs MCP standard contre le serveur MCP distant de Glean, qui utilise des indexes centralisés et une technologie de graphe de connaissances. Nous avons évalué des serveurs MCP standard courants comme Atlassian Rovo, GCP (pour les logs), GitHub (MCP local), Gmail, Google Calendar, Google Drive, Salesforce (MCP local) et Slack.
Pour mesurer l'efficience, nous avons conservé les modèles constants et examiné les différences d'utilisation de jetons entre le serveur MCP distant de Glean et les outils MCP standard. Des évaluateurs ont exécuté les mêmes environ 175 requêtes de type Cowork sur les deux configurations et ont noté les réponses selon une échelle de préférence à 5 points sur quatre métriques :
- Utilité : quelle réponse utiliseriez-vous réellement dans votre travail ? Mesure le niveau de retouche nécessaire avant qu'une réponse soit prête à l'emploi.
- Exactitude : quelle réponse est la plus exacte factuellement ou logiquement ? Mesure si les affirmations sont étayées par des sources vérifiées, citées et à jour.
- Exhaustivité : quelle sortie a mené la tâche jusqu'au bout ? Mesure si toutes les sous-requêtes ont été traitées, si l'analyse était exhaustive et si les réponses étaient exploitables.
- Fidélité des outils : le système a-t-il utilisé les bons appels d'outils lors de la réponse ? Cette métrique mesure l'intégrité de l'exécution : si les bons outils ont été invoqués, s'ils se sont exécutés avec succès et si des problèmes tels que des timeouts, des demandes OAuth répétées ou d'autres interruptions ont nécessité une intervention manuelle de l'utilisateur ou des nouvelles tentatives pour produire une réponse.
Comment la qualité du contexte impacte la consommation de jetons
Les outils MCP standard ont utilisé 30 % de jetons de plus que Glean, mais la conclusion la plus révélatrice est venue de l'examen de la manière dont la consommation de jetons évoluait en fonction de la qualité du résultat. Quel que soit le résultat, l'usage des jetons par Glean est resté stable dans une fourchette d'environ 42k à 44k jetons, tandis que la consommation des MCP prêts à l'emploi a augmenté pour gagner.
Lorsqu'un coworker produisait une réponse plus correcte avec des outils prêts à l'emploi, il consommait environ 83k jetons contre 43k pour Glean, soit presque le double des jetons utilisés par Glean pour l'emporter. Parvenir à une victoire avec des outils prêts à l'emploi relevait d'une recherche par force brute, d'un plus grand nombre d'appels d'outils et de boucles de raisonnement supplémentaires, plutôt que d'une récupération de contexte plus efficace. C'est un schéma cohérent avec les inconvénients connus des approches fédérées.
Le rôle du contexte dans la préparation au travail
L'efficacité en jetons n'explique qu'une partie de l'histoire. Ce qui détermine si un AI coworker peut prendre le relais, c'est à quel point le résultat est proche d'être prêt pour le travail : combien un humain doit le modifier et combien d'invites de suivi sont nécessaires. Pour déterminer cela, nous avons évalué Glean sur un large éventail de tâches de type Cowork qui reflètent la diversité du travail en entreprise :
- Génération de contenu : création de fichiers, notamment des documents, du HTML et des diapositives, suffisamment précis pour être utilisés ou partagés avec un minimum de retouches.
- Préparation des calendriers et des réunions : gestion des calendriers, préparation des réunions et garantie que les bons interlocuteurs et le bon contexte soient inclus.
- Gestion de la boîte de réception et des communications : rédaction d'e-mails et de messages Slack qui reflètent le bon ton et le bon public, tout en synthétisant les listes de tâches issues des communications récentes et des priorités stratégiques pour faire ressortir ce qui doit être fait.
- Analyse de données à grande échelle : analyse de données à grande échelle pour faire ressortir les tendances métier, prévoir les résultats et soutenir la prise de décision à l'échelle des fonctions.
- Recherche d'informations : synthèse d'informations, cartographie des processus, identification du responsable d'un travail et mise en avant du document canonique ou de la définition d'une métrique, une classe de requêtes qui reste très pertinente à l'ère des AI coworkers.
Glean a surpassé les serveurs MCP prêts à l'emploi dans toutes les catégories, démontrant la puissance du contexte pour permettre à l'IA de gérer avec précision l'éventail des besoins de productivité personnels et professionnels en entreprise.
Découper par catégorie de requête était un angle d'analyse des résultats, mais nous voulions aussi comprendre comment l'importance du contexte évoluait à mesure que la complexité des tâches augmentait. Des caractéristiques comme le nombre de jetons de réponse, le nombre de boucles de raisonnement et le nombre d'appels d'outils de lecture ou d'écriture ont servi de proxys de complexité, nous donnant un moyen de segmenter les tâches au-delà de la seule catégorie. Sur les tâches simples, Glean a gagné 66 % du temps, mais à mesure que la complexité augmentait, ce chiffre est passé à 73 %. Cela illustre à quel point un contexte bien conçu devient de plus en plus important lorsque le travail exige davantage d'étapes et davantage de sources pour être mené à bien.
3 requêtes illustrant la puissance du contexte
Consulte les publications de lancement récentes et les communications clients, résume les principales observations et enseignements, et donne-moi une newsletter HTML que je puisse partager avec l'équipe design.
Lorsqu'il s'agit de créer des artefacts HTML interactifs, la qualité du contexte sous-jacent façonne directement la richesse du résultat. Dans une tâche nécessitant un résumé des publications de lancement récentes et des communications clients, Glean a fait ressortir six fonctionnalités livrées, contre deux pour les serveurs MCP prêts à l'emploi, et a étayé son analyse par des citations directes de clients mettant en évidence des thèmes significatifs sur l'expérience produit. Les MCP prêts à l'emploi manquaient du signal client, produisant un résultat plus superficiel qui nécessitait beaucoup plus d'édition pour être exploitable par une équipe de design produit, un écart qui découle directement de la capacité de Glean à synthétiser les signaux à travers les sources.
Identifie les thèmes les plus récents des retours clients sur la page d'accueil et crée un document résumant les 5 principaux thèmes avec des citations d'exemple.
Lorsqu'on lui a demandé de faire ressortir les thèmes les plus récents des retours clients, Glean a synthétisé des données issues de plusieurs sources pour identifier les principales demandes des clients, notamment une vue unifiée et le besoin de rendre la fonction de recherche plus facile à trouver. Les outils MCP prêts à l'emploi, à l'inverse, ont fait remonter des demandes produit sans rapport avec le nouveau déploiement de la page d'accueil, mais plutôt des problèmes de connecteurs, comme l'absence d'affichage des événements de calendrier et des contrôles d'indexation des données. Les outils prêts à l'emploi ont également été insuffisants en matière d'exhaustivité, ne fournissant pas d'exemples précis de clients mais plutôt des extraits de tickets de support. L'un des défis tenait à la qualité des outils, car les serveurs prêts à l'emploi ont rencontré des erreurs pendant l'exécution qui ont empêché l'appel réussi de tous les outils pertinents, limitant ainsi la couverture et la qualité.
À partir des résultats de recherche, voici ce que j'ai trouvé pour les alertes SSAT de la semaine dernière (semaine du 28/04 au 04/05, couvertes par Alex Chen) :
- Maxium Corp — Les documents indexés dans Google Drive ont connu une forte hausse, avec une hausse correspondante de l'incidence dans les 10 premiers résultats. Le suivi de la cause racine était lié dans le fil ssat-alerts.
- Ironbridge Health et Provo Systems — Tous deux ont baissé pendant une journée, puis se sont rétablis d'eux-mêmes. La note indique qu'ils examineront cela plus en détail si cela persiste.
Cela provient d'un document de veille à l'astreinte / qualité de recherche sur Drive. Voulez-vous que je développe l'un de ces points, par exemple les fils Slack liés ?
Le canal #ssat-alerts a eu des alertes presque tous les jours la semaine dernière. Le message du 29 avril a reçu 13 réponses — laissez-moi creuser ce fil et les autres pour trouver quels déploiements précis ont été signalés. Chaque alerte contient un fichier CSV avec la liste des déploiements. Laissez-moi essayer de les télécharger pour obtenir les noms exacts. Le contenu du CSV ne se charge pas directement. Laissez-moi essayer de récupérer les fichiers et aussi rechercher toute mention directe de noms de déploiements dans le canal. Le contenu du CSV n'est pas accessible directement. Laissez-moi consulter le fil Maxium Corp qui a été mentionné, et aussi essayer de trouver d'autres mentions de clients / déploiements. D'après les fils que j'ai lus, voici ce que j'ai trouvé pour la semaine dernière (28 avril–2 mai) :
- Maxium Corp prod était le déploiement signalé dans les alertes SSAT, apparaissant dans les 5 CSV d'alerte quotidiens du bot Acme dans #ssat-alerts. L'alerte a duré plusieurs jours consécutifs, ce qui a déclenché l'escalade.
- La discussion dans le fil s'est concentrée sur la cause : une hausse des documents indexés dans Google Drive qui a fait surreprésenter les résultats Google Drive, dégradant la qualité de recherche. Jordan Park a enquêté et a relayé l'information dans #internal-maxium-corp, où Marcus Reyes a confirmé qu'un support Google Drive supplémentaire avait été récemment activé pour le déploiement Maxium Corp — cela a élargi ce qui était exploré et a modifié la répartition des résultats.
Une remarque : le CSV du 1er mai était nettement plus volumineux (~446 octets contre ~208 octets pour les autres jours), il se peut donc que d'autres déploiements aient été signalés ce jour-là en particulier, mais ces noms n'apparaissent pas dans la discussion Slack — ils figureraient dans le CSV joint à ce message.
Cette réponse a été légèrement modifiée et des pseudonymes ont été utilisés pour protéger les noms des clients et les données sensibles.
Alors que le MCP prêt à l'emploi a pu creuser en profondeur une alerte spécifique pour un client, il n'a pas d'abord su prendre de la hauteur pour identifier l'ensemble des clients concernés par l'alerte avant de commencer le dépannage. Étant donné que l'objectif principal de la requête était une analyse exhaustive des données sur tous les clients affectés, la capacité de Glean à faire apparaître la vue d'ensemble avant d'approfondir en a fait la réponse la plus exacte et la plus complète.
Contexte à l'ère de Cowork
Les index centralisés et le graphe de connaissance de Glean ont surpassé les serveurs MCP prêts à l'emploi à la fois en qualité et en efficacité. Sur l'utilité, la justesse, l'exhaustivité et la qualité d'exécution, Glean a été préféré environ 2,5 fois plus souvent, l'écart se creusant à mesure que la complexité de la tâche augmentait. En matière de consommation de jetons, les serveurs MCP prêts à l'emploi ont nécessité en moyenne 30 % de jetons supplémentaires, tandis que Glean maintenait une consommation de jetons stable quel que soit le niveau de qualité du résultat. Le MCP prêt à l'emploi a consommé presque deux fois plus de jetons à mesure qu'il devait travailler davantage pour produire une réponse correcte.
À mesure que les entreprises déploient l'IA à l'échelle sur des travaux plus longs et plus complexes, dans une période de hausse rapide des coûts des modèles de pointe, la conception de la couche de contexte devient un facteur direct de la qualité et de l'économie de l'IA au travail. Avec Glean, les entreprises indexent leurs données et construisent leurs graphes de connaissance une seule fois, puis utilisent MCP pour connecter ce contexte à chaque surface où le travail se fait, de Claude Cowork pour la productivité personnelle aux AI-IDEs pour l'ingénierie, amplifiant ainsi le retour sur cet investissement à l'échelle de l'entreprise.
