Comparer la retrieval, le routage et l’orchestration : impact sur l’utilisation des tokens

Les décisions d’architecture autour de la profondeur de retrieval, du routage des requêtes et de l’orchestration des workflows déterminent combien de tokens votre système d’IA consomme par requête. Ces décisions déterminent aussi si votre facture mensuelle d’API se situe à 50 000 $ ou à 500 000 $. Ces trois couches interagissent d’une manière qui rend les configurations statiques coûteuses et fragiles face aux charges de travail réelles en entreprise.

La tension centrale est simple. Une retrieval plus profonde fait remonter davantage de contexte dans le prompt, ce qui améliore l’ancrage factuel, mais augmente les coûts en tokens et la latence. Une retrieval superficielle économise des tokens, mais ne répond pas suffisamment aux questions complexes à étapes multiples.

Le routage décide quel modèle ou quelle stratégie de retrieval traite chaque requête. L’orchestration régit la façon dont des workflows multi-étapes enchaînent ces décisions, en contrôlant si l’utilisation des tokens croît linéairement ou reste bornée. Comprendre comment chaque couche pilote la consommation, c’est la différence entre un déploiement qui passe à l’échelle et un autre qui se retrouve bloqué par sa propre structure de coûts.

Comment la retrieval, le routage et l’orchestration affectent chacun la consommation de tokens

Le contexte récupéré est généralement la plus grande composante variable des tokens facturés dans tout système de retrieval-augmented generation (RAG). Une stratégie de dense retrieval top-10 extrait nettement plus de tokens de prompt qu’une approche top-3, et une retrieval systématiquement lourde augmente le total des tokens facturés de plus d’un tiers par rapport à un routage par requête. Pourtant, la relation entre profondeur de retrieval et qualité des réponses n’est pas linéaire.

Les requêtes définitionnelles obtiennent souvent des réponses exactes à partir de la seule connaissance paramétrique du modèle, ce qui signifie que la retrieval ajoute un coût sans améliorer la réponse. Les requêtes analytiques multi-hop, en revanche, ont réellement besoin d’un contexte plus profond pour produire des réponses solidement étayées. Une configuration de retrieval statique qui traite chaque requête de la même manière soit dépense trop sur les questions simples, soit dessert les plus complexes.

De récentes recherches CA-RAG (Mishra, 2026) montrent que le routage par requête permet d’obtenir 26 % de tokens facturés en moins que la retrieval systématiquement lourde, à qualité de réponse équivalente. Les économies se concentrent sur les requêtes plus simples comme les définitions et les classifications, où une retrieval complète n’apporte aucune valeur.

Les déploiements en entreprise ont atteint 500 000 $ à 1 M $ ou plus de coûts mensuels d’API. À cette échelle, une réduction de 26 % se traduit par des gains de token efficiency qui valent des centaines de milliers de dollars par an.

Le routage s’attaque à la deuxième couche de gaspillage. Sans routage par requête, chaque question est traitée par le même modèle avec la même profondeur de retrieval. « Quelle est notre politique de congés (PTO) ? » reçoit le même traitement que « Analysez les tendances de revenus du T3 sur l’ensemble des gammes de produits. » Adapter la complexité des requêtes au bon niveau de modèle et à la bonne stratégie peut réduire les coûts d’environ 80 %.

Le routage ne consiste pas seulement à choisir un modèle moins cher. Un routage efficace sélectionne un ensemble de stratégies : le modèle, la profondeur de retrieval, le template de prompt et la contrainte de longueur de réponse, tous ajustés ensemble.

Une fonction d’utilité qui met en balance la qualité, la latence et le coût en tokens peut prendre en charge plusieurs points de fonctionnement par simple ajustement des pondérations. Vous réglez le compromis pour différentes classes de requêtes sans reconstruire la pipeline.

L’orchestration est l’endroit où les coûts se cumulent ou restent maîtrisés. Dans les workflows agentiques multi-tours, chaque étape ajoute des tokens au contexte en cours. L’analyse 2026 de Gartner a constaté que les modèles agentiques nécessitent de 5 à 30 fois plus de tokens par tâche que les chatbots standard. Une seule erreur de routage à l’étape 1 se répercute sur chaque étape en aval, faisant grimper le coût sur l’ensemble du workflow.

Les décisions d’orchestration contrôlent quand résumer le contexte accumulé, quand supprimer l’état intermédiaire et quand checkpoint. Ces choix déterminent si un workflow en cinq étapes coûte cinq fois une requête unique ou quinze fois. Les chaînes d’outils séquentielles multiplient à la fois la latence et le coût en tokens, tandis que l’exécution parallèle avec un passage sélectif du contexte réduit les deux.

Glean’s Enterprise Graph et l’architecture de recherche hybride s’attaquent directement à la couche de retrieval. En combinant la dense retrieval et la sparse retrieval avec du reranking, le système récupère moins de passages mais avec une pertinence plus élevée par requête. Cette approche réduit le volume de tokens de prompt sans sacrifier l’ancrage factuel dont les workflows de raisonnement agentique dépendent.

La couche d’orchestration détermine ensuite comment le contexte récupéré circule à travers des plans multi-étapes. Elle résume lorsque c’est possible et ne transmet aux agents en aval que les fragments pertinents, évitant l’inflation de contexte qui transforme une pipeline de retrieval bien conçue en une pipeline coûteuse.

Pourquoi la profondeur de retrieval est le principal facteur de coût en tokens

Comment la profondeur de retrieval se traduit en tokens facturés

Chaque requête vers un système RAG génère trois catégories de tokens facturés. Les tokens de prompt couvrent les instructions système, la fenêtre de contexte récupérée et la requête utilisateur elle-même. Les tokens de complétion couvrent la réponse générée, et les tokens d’embedding couvrent l’encodage vectoriel utilisé pendant la retrieval.

Parmi ces trois catégories, le contexte récupéré est la variable qui fait le plus fortement varier le coût. Les instructions système et la requête elle-même sont relativement fixes, et la longueur de complétion varie dans une fourchette plus étroite. En revanche, les passages récupérés peuvent aller de zéro à des dizaines de milliers de tokens selon le nombre de documents que le système injecte dans le prompt.

Ajouter des passages présente des rendements décroissants. Après les trois à cinq premiers passages à forte pertinence, chaque passage supplémentaire contribue moins à la qualité de la réponse tout en ajoutant le même coût fixe en tokens de prompt. On obtient une courbe de qualité concave mais une courbe de coût linéaire, et l’écart se creuse à chaque passage supplémentaire récupéré.

Adapter la profondeur de retrieval à la complexité des requêtes

Toutes les requêtes n’ont pas besoin du même niveau de contexte, mais classifier les requêtes avant la phase de retrieval est en soi une décision de coût. Un deuxième appel au modèle pour évaluer la difficulté va à l’encontre de l’objectif s’il ajoute de la latence et des tokens.

Des signaux de classification légers évitent cette surcharge. Le nombre de mots, des mots-indices (« compare », « analyze », « summarize across ») et un simple scoring heuristique peuvent distinguer des recherches de faits uniques de tâches de raisonnement multi-étapes, sans invoquer un modèle. Une requête contenant trois entités nommées et un modificateur temporel (« Q3 2025 ») signale une complexité analytique, alors qu’une requête définitionnelle de cinq mots ne le fait pas.

Pour les requêtes qui nécessitent un retrieval, le reranking est la voie la plus directe vers moins de passages, mais de meilleure qualité. Un pipeline en deux étapes récupère un premier ensemble large, puis attribue un score à chaque passage selon sa pertinence pour la requête spécifique. Vous payez des tokens d’embedding pour la récupération large, mais des tokens de prompt uniquement pour le sous-ensemble reranké.

Le modèle de langage auto-apprenant de Glean s’adapte au fil du temps au vocabulaire interne et aux habitudes d’usage de chaque entreprise. Au cours des six premiers mois d’une entreprise sur la plateforme, la qualité de recherche s’améliore généralement de 20% grâce à l’apprentissage continu. Cette précision croissante signifie que le retrieval renvoie dès le départ des passages plus pertinents, réduisant le besoin de sur-récupérer comme couverture contre le risque de manquer le bon document.

Comment le routage par requête réduit le gaspillage de tokens sans sacrifier la qualité des réponses

Le routage par requête associe indépendamment chaque requête entrante au plus petit ensemble de stratégies efficace : le niveau de modèle, la profondeur de retrieval, le modèle de prompt et la contrainte de longueur de réponse capables de produire une réponse satisfaisante. Plutôt que d’appliquer un pipeline unique à chaque requête, le routage traite chaque question comme une décision d’allocation de ressources à part entière.

La réduction de 26% des tokens et l’amélioration de 34% de la latence du framework CA-RAG illustrent l’effet global, mais la répartition des économies compte plus que la moyenne. Les requêtes simples, qui constituent la majorité des charges de travail en entreprise, représentent une part disproportionnée de la réduction. Les économies proviennent du fait de ne pas appliquer un retrieval profond et des modèles à grande capacité à des questions qui n’en ont jamais eu besoin.

Une fonction d’utilité de routage consciente des coûts formalise cette décision. La fonction combine un a priori de qualité, estimé à partir des caractéristiques de la requête et des résultats historiques, avec des pénalités normalisées pour la latence et le total de tokens facturés. Le système sélectionne la stratégie la mieux notée dans l’ensemble candidat, et l’ajustement des poids de pénalité déplace le point de fonctionnement sans modifier le catalogue de stratégies.

Un routeur bien conçu exploite l’ensemble du catalogue des stratégies disponibles plutôt que de se réduire à une politique quasi fixe. Si vos logs de routage montrent que 95% des requêtes aboutissent à la même stratégie, le routeur ne route pas — il est devenu un pipeline statique avec une surcharge supplémentaire. Un routage efficace produit une distribution de sélections de stratégies qui reflète la diversité réelle des requêtes entrantes. En pratique, entre 70% et 80% des charges de travail d’entreprise en production s’exécutent de manière identique sur des modèles de niveau intermédiaire ou économique que sur des modèles premium, ce qui signifie qu’un routeur bien réglé peut diriger la majorité du trafic vers des modèles moins coûteux, sans perte de qualité.

L’étape de planification de requête de Glean réécrit chaque requête avec des connaissances propres à l’entreprise avant de la router. Le système comprend quelles sources de données sont disponibles, comment elles peuvent être interrogées, et ce que les termes spécifiques à l’entreprise signifient dans leur contexte. Cette étape de réécriture donne au routeur un meilleur signal de classification, car une requête réécrite avec la bonne terminologie interne est plus facile à classer avec précision qu’une question brute d’utilisateur pleine d’abréviations ambiguës.

Ce que la couche d’orchestration contrôle et que le retrieval et le routage ne peuvent pas

Accumulation de contexte sur des workflows multi-étapes

Le retrieval et le routage opèrent au niveau d’une requête unique. L’orchestration gouverne ce qui se passe à travers plusieurs requêtes dans un workflow multi-étapes, où les décisions à chaque étape façonnent le budget de tokens de toutes les étapes suivantes.

Chaque étape d’un workflow agentique ajoute sa sortie au contexte en cours. Une étape de recherche peut apporter 2 000 tokens de passages récupérés, une étape d’analyse ajoute ses conclusions intermédiaires, et une étape de rédaction inclut le contexte accumulé plus sa propre génération. Sans gestion active, le contexte croît linéairement à chaque étape.

Le problème cumulatif dépasse le coût. Lorsqu’une étape précédente récupère un contexte non pertinent ou produit une réponse intermédiaire faible, chaque étape aval hérite de ce bruit. Les appels ultérieurs au modèle dépensent des tokens à traiter des informations qui dégradent activement leur sortie — pas seulement un coût gaspillé, mais une valeur négative.

Les décisions d’orchestration déterminent si la croissance du contexte reste bornée ou s’emballe. Résumer les résultats intermédiaires entre les étapes compresse la fenêtre de contexte tout en préservant l’information essentielle. Écarter entièrement l’état intermédiaire après extraction supprime le bruit, et le checkpointing permet à un workflow de redémarrer depuis un état propre à une étape fiable connue, plutôt que de relancer depuis le début.

Séquençage, parallélisation et gestion des appels d’outils

L’exécution séquentielle est le comportement par défaut dans la plupart des architectures agentiques, et c’est le schéma le plus coûteux. Chaque étape attend que la précédente se termine, ce qui signifie que la latence et le coût en tokens s’additionnent tous deux de manière linéaire.

L’exécution parallèle brise ce schéma. Lorsque deux sous-tâches sont indépendantes, les exécuter simultanément élimine le chevauchement de latence et permet un passage sélectif du contexte. Chaque branche parallèle ne reçoit que le contexte dont elle a besoin, et les sorties sont fusionnées à un point de jonction, seules les portions pertinentes étant conservées pour la suite.

La gestion de l’état et de la mémoire détermine ce qui compte comme contexte essentiel versus redondant. Une couche d’orchestration bien conçue maintient une représentation compacte de l’état qui capture les faits clés, les décisions et les contraintes des étapes précédentes, sans transporter des passages récupérés bruts ni des sorties intermédiaires verbeuses.

Glean Agents utilisent une planification multi-étapes avec des sous-agents et la sélection d’outils pour gérer cette complexité. À mesure que les enterprise AI agents mûrissent, chaque sous-agent reçoit une tâche cadrée et le contexte minimal nécessaire pour l’accomplir, plutôt que l’historique complet de la conversation. Le

Agentic Engine coordonne le plan, assigne des sous-agents, sélectionne les outils et fusionne les résultats, tout en gardant chaque branche légère et spécifique à son objectif.

Mesurer le compromis coût-qualité : les métriques qui comptent

Mesurer l’efficacité des tokens exige de suivre les bonnes métriques, au bon niveau. Une seule métrique ne peut pas capturer l’interaction entre la récupération, le routage et l’orchestration. Le tableau ci-dessous associe des métriques clés à la couche d’architecture que chacune permet de diagnostiquer.

Le danger de se focaliser sur une seule métrique, c’est que les améliorations dans un domaine peuvent dégrader discrètement un autre. Réduire agressivement la profondeur de récupération baisse le coût en tokens par requête, mais peut introduire de l’ambiguïté dans le contexte récupéré. Un contexte ambigu produit des réponses plus longues et moins ciblées, qui parfois ne répondent pas à la question initiale, déclenchant des tentatives supplémentaires qui consomment plus de tokens qu’une récupération plus profonde ne l’aurait fait.

Le coût par tâche résolue capture mieux cette dynamique que le coût par requête. Une tâche résolue en une réponse bien étayée à 4 000 tokens coûte moins cher qu’une tâche qui nécessite trois tentatives superficielles à 1 500 tokens chacune. Mesurer au niveau de la tâche permet de voir si les économies de tokens au niveau de la requête sont réelles ou illusoires.

Le même catalogue de stratégies peut prendre en charge plusieurs points de fonctionnement via un ajustement des poids dans la fonction d’utilité de routage. Vous n’avez pas besoin d’une architecture différente pour du traitement par lot sensible aux coûts et des requêtes orientées utilisateur sensibles à la latence. Il vous faut des poids différents sur la même fonction.

Glean utilise un système d’évaluation basé sur un LLM pour noter à la fois la qualité de la récupération et la qualité de la génération. Le système évalue si les documents récupérés sont pertinents par rapport à la question de l’utilisateur et si la réponse générée extrait fidèlement des informations de ces documents. Les tests internes ont montré que les évaluateurs humains n’étaient d’accord entre eux que dans 79 % des cas, tandis que le système d’évaluation basé sur l’IA atteignait 74 % d’accord — démontrant une cohérence proche de celle des humains pour un suivi automatisé de la qualité à grande échelle.

Techniques pratiques pour optimiser l’efficacité des tokens sur les trois couches

Techniques au niveau de la couche de récupération

Définissez un budget de contexte explicite par requête comme une contrainte de premier ordre, et non comme une réflexion a posteriori. Définissez le nombre maximal de tokens disponibles pour le contexte récupéré avant le début de la récupération, et faites-le respecter lors de la sélection des passages.

Appliquez un reranking pour faire remonter rapidement les passages les plus pertinents, et arrêtez la récupération lorsqu’un signal suffisant est obtenu. Un pipeline de récupération en deux étapes qui cherche largement puis rerank précisément vous apporte les bénéfices de rappel d’une récupération large, avec l’efficacité en tokens de fenêtres de contexte plus étroites.

Utilisez un chunking tenant compte des tokens pour traiter en priorité les sections à forte valeur ajoutée des documents. Les en-têtes, résumés et sections de conclusion contiennent souvent la densité d’information dont une requête a besoin. Récupérez d’abord ces chunks à forte valeur, puis ajoutez des détails progressivement uniquement lorsque les chunks initiaux ne satisfont pas la requête.

Techniques au niveau de la couche de routage

Suivez le schéma « commencer petit, puis monter en puissance ». Acheminez chaque requête d’abord vers le plus petit modèle efficace et la profondeur de retrieval la plus faible, puis montez vers un modèle plus grand ou un retrieval plus profond uniquement lorsque la réponse initiale n’atteint pas les seuils de qualité. Une entreprise du mid-market a appliqué cette approche et a vu sa facture mensuelle d’IA passer de 42  ;k$ à 11  ;k$ — une réduction de 74  ;% — en acheminant 80  ;% du trafic vers des modèles d’entrée de gamme, tout en réservant les modèles premium aux raisonnements complexes.

Séparez les charges de travail selon leur profil de latence. Les requêtes orientées utilisateur ont besoin de réponses rapides et gagnent à être acheminées de manière agressive vers des modèles plus petits, tandis que les tâches de traitement batch peuvent tolérer une latence plus élevée et un retrieval plus profond. Faire transiter ces charges via des chemins distincts évite d’imposer les contraintes d’un profil à l’autre.

Journalisez chaque décision de routage et surveillez la dérive. Un routeur qui prenait de bonnes décisions le mois dernier peut se dégrader à mesure que les schémas de requêtes évoluent, que de nouvelles sources de données sont mises en service, ou que le comportement des modèles change après des mises à jour.

Techniques au niveau de la couche d’orchestration

Résumez l’historique de la conversation en un état compact entre les étapes du workflow. Une gestion intelligente du contexte — extraire et conserver sélectivement les faits clés plutôt que de transporter des transcriptions complètes — peut réduire drastiquement l’utilisation de tokens. L’essentiel est de compresser aux points de rupture naturels plutôt qu’à des limites de tokens arbitraires.

Utilisez un passage de contexte sélectif entre les étapes du workflow. Chaque sous-tâche d’un workflow en plusieurs étapes ne doit recevoir que le contexte dont elle a besoin, et non l’intégralité de l’historique accumulé. Définissez des contrats d’entrée explicites pour chaque étape, qui précisent exactement quels champs, faits ou contraintes elle requiert des étapes en amont.

Définissez des budgets de tokens explicites avec des garde-fous pour chaque étape du workflow. Un budget sans application n’est qu’une suggestion, et des garde-fous qui tronquent ou résument le contexte lorsqu’il dépasse le budget de l’étape empêchent une seule étape de consommer l’allocation de tokens prévue pour les étapes suivantes. Pour les charges de travail à forte répétition, le cache sémantique peut réduire les coûts d’API jusqu’à 73  ;% en stockant les embeddings de requêtes et en servant des réponses en cache pour des demandes sémantiquement similaires — éliminant entièrement l’appel au LLM en cas de hit cache.

L’écosystème de connecteurs de Glean ingère et indexe le contenu à travers des applications d’entreprise comme Salesforce, Jira, Confluence et Slack, ce qui permet à la couche de retrieval d’avoir une couverture étendue sans nécessiter d’appels d’outils redondants pendant l’orchestration. Les données sont déjà indexées et respectent les permissions, de sorte que la couche d’orchestration interroge un index unifié plutôt que d’effectuer des appels API séparés vers chaque système source et de traiter leurs réponses brutes.

Questions fréquentes

Combien le routage par requête peut-il réellement économiser par rapport à une stratégie de retrieval fixe  ; ?

Le routage par requête réduit généralement le total de tokens facturés de 20 à 30  ;%, avec des économies concentrées sur les requêtes les plus simples qui constituent la majorité des charges de travail en entreprise. La réduction exacte dépend de votre mix de requêtes  ; : les organisations ayant une forte proportion de requêtes définitionnelles ou de type recherche voient des économies plus importantes que celles dont la charge de travail est dominée par des questions analytiques complexes.

Réduire la profondeur de retrieval nuit-il toujours à la qualité des réponses  ; ?

Non. Pour de nombreux types de requêtes, un retrieval moins profond avec un meilleur reranking produit des réponses de qualité équivalente ou supérieure. La qualité ne se dégrade que lorsque vous réduisez la profondeur de retrieval pour des requêtes qui ont réellement besoin d’un contexte multi-documents, comme le recoupement ou l’analyse de tendances à travers plusieurs sources.

Quel rôle la couche d’orchestration joue-t-elle dans le coût des tokens à grande échelle  ; ?

L’orchestration contrôle la manière dont les tokens s’accumulent au fil des workflows en plusieurs étapes. Sans gestion active du contexte, chaque étape s’ajoute à une fenêtre de contexte croissante, et les étapes ultérieures paient le coût cumulé complet. La synthèse, le passage de contexte sélectif et l’exécution parallèle peuvent maintenir les workflows multi-étapes proches du coût de leurs étapes individuelles, plutôt que de le multiplier. Pour les équipes qui construisent des systèmes agentic RAG, la conception de l’orchestration est le levier principal pour maîtriser le coût à grande échelle.

Puis-je ajuster les arbitrages coût-qualité sans changer de modèle ni d’infrastructure de retrieval  ; ?

Oui. Une fonction d’utilité de routage avec des pondérations ajustables vous permet de basculer entre des points de fonctionnement orientés coût et orientés qualité en utilisant les mêmes modèles, le même pipeline de retrieval et le même catalogue de stratégies. Vous modifiez les poids de pénalité pour la latence et le coût en tokens, et le routeur sélectionne différentes stratégies en conséquence.

Quel est le changement le plus impactant pour réduire le coût en tokens  ; ?

Définir un budget de contexte explicite par requête et l’appliquer pendant le retrieval. Le contexte récupéré est la plus grande composante variable des tokens facturés, et la plupart des surcoûts proviennent du fait de récupérer plus de passages que la requête n’en a réellement besoin. Un budget de tokens strict, avec reranking pour prioriser les passages les plus pertinents dans ce budget, traite directement le principal facteur de coût.

Les décisions d’architecture que vous prenez autour de la profondeur de retrieval, du routage des requêtes et de l’orchestration déterminent directement si votre déploiement d’IA évolue efficacement ou devient un centre de coûts incontrôlable. Réussir ces trois couches n’est pas un exercice ponctuel — cela exige des mesures continues, des ajustements de routage et une gestion du contexte au fil de l’évolution de vos charges de travail. Demandez une démo pour découvrir comment nous pouvons vous aider à concevoir des systèmes d’IA qui fournissent des réponses fondées sans épuiser votre budget de tokens.