Comparer la récupération, le routage et l’orchestration : impact sur l’utilisation des tokens

Les décisions d’architecture autour de la profondeur de récupération, 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 atteint 50 000 $ ou 500 000 $. Ces trois couches interagissent de manière à rendre les configurations statiques coûteuses et fragiles face aux charges de travail réelles des entreprises.

La tension fondamentale est simple. Une récupération plus profonde injecte davantage de contexte dans le prompt, ce qui améliore l’ancrage factuel mais augmente les coûts en tokens et la latence. Une récupération superficielle économise des tokens, mais répond moins bien aux questions complexes en plusieurs étapes.

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

Comment la récupération, le routage et l’orchestration influencent 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 récupération dense top-10 injecte nettement plus de tokens de prompt qu’une approche top-3, et une récupération systématiquement intensive 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 récupération 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 récupération ajoute du coût sans améliorer la réponse. Les requêtes analytiques en plusieurs étapes, à l’inverse, ont réellement besoin d’un contexte plus profond pour produire des réponses correctement étayées. Une configuration de récupération statique qui traite toutes les requêtes de la même façon soit dépense trop pour des questions simples, soit répond insuffisamment aux questions complexes.

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

Des 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 d’efficacité des tokens valant 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 envoyée au même modèle avec la même profondeur de récupération. « Quelle est notre politique de congés payés (PTO) ? » est traité de la même manière que « Analysez les tendances du chiffre d’affaires du T3 sur l’ensemble des gammes de produits. » Faire correspondre 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égie : le modèle, la profondeur de récupération, le template de prompt et la contrainte de longueur de réponse, le tout réglé de façon cohérente.

Une fonction d’utilité qui équilibre qualité, latence et coût en tokens peut prendre en charge plusieurs points de fonctionnement en ajustant uniquement les pondérations. Vous réglez le compromis pour différentes classes de requêtes sans reconstruire le pipeline.

L’orchestration est l’endroit où les coûts se composent ou restent contenus. Dans les workflows agentiques en plusieurs tours, chaque étape ajoute des tokens au contexte en cours. L’analyse de Gartner en 2026 a révélé que les modèles agentiques nécessitent 5 à 30 fois plus de tokens par tâche que les chatbots standard. Une seule erreur de routage à la première étape se propage à toutes les étapes en aval, augmentant les coûts 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 faire des checkpoints. Ces choix déterminent si un workflow en cinq étapes coûte cinq fois une requête unique ou 15 fois. Les chaînes d’outils séquentielles multiplient à la fois la latence et le coût en tokens, tandis que l’exécution en parallèle avec un passage sélectif du contexte réduit les deux.

L’Enterprise Graph de Glean et l’architecture de recherche hybride traitent directement la couche de récupération. En combinant récupération dense et clairsemée avec reranking, le système récupère moins de passages, mais plus pertinents, par requête. Cette approche réduit le volume de tokens de prompt sans sacrifier l’ancrage factuel dont dépendent les workflows de raisonnement agentique.

La couche d’orchestration détermine ensuite comment le contexte récupéré circule dans des plans en plusieurs étapes. Elle résume lorsque c’est possible et ne transmet aux agents en aval que des fragments pertinents, évitant ainsi le gonflement de contexte qui transforme un pipeline de récupération bien conçu en pipeline coûteux.

Pourquoi la profondeur de récupération est le principal moteur du coût en tokens

Comment la profondeur de récupération 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é 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é lors de la récupération.

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

L’ajout de passages a des rendements décroissants. Après les trois à cinq premiers passages de 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. Le résultat est une courbe de qualité concave mais une courbe de coût linéaire, et l’écart s’élargit à chaque passage supplémentaire récupéré.

Adapter la profondeur de récupération à la complexité des requêtes

Toutes les requêtes n’ont pas besoin de la même quantité de contexte, mais classifier les requêtes avant la récupération est en soi une décision de coût. Un second 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 indicateurs (« compare », « analyze », « summarize across ») et un scoring heuristique simple peuvent distinguer les recherches à fait unique des tâches de raisonnement multi-étapes, sans appeler un modèle. Une requête contenant trois entités nommées et un modificateur temporel (« Q3 2025 ») signale une complexité analytique, tandis qu’une requête définitionnelle de cinq mots ne le fait pas.

Pour les requêtes qui nécessitent une recherche, 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 large ensemble initial, puis évalue chaque passage selon sa pertinence pour la requête spécifique. Vous payez des tokens d’embedding pour la recherche 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 la recherche renvoie davantage de passages pertinents dès le départ, réduisant la nécessité de sur-récupérer comme filet de sécurité pour éviter de passer à côté du 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 de manière indépendante chaque requête entrante au plus petit ensemble de stratégies efficace : le niveau de modèle, la profondeur de recherche, 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 sa propre décision d’allocation de ressources.

La réduction de 26% des tokens et l’amélioration de 34% de la latence du framework CA-RAG illustrent l’effet agrégé, mais la distribution 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 viennent du fait de ne pas appliquer une recherche profonde et des modèles à grande capacité à des questions qui n’en avaient jamais eu besoin.

Une fonction d’utilité de routage tenant compte 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 ayant le score le plus élevé 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 de 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 utilisent 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 enterprise en production s’exécutent à l’identique sur des modèles de milieu de gamme ou économiques que sur des modèles premium, ce qui signifie qu’un routeur bien calibré peut dévier la majorité du trafic vers des modèles moins chers sans perte de qualité.

L’étape de planification de requête de Glean réécrit chaque requête avec des connaissances spécifiques à 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 signifient les termes propres à l’entreprise dans leur contexte. Cette étape de réécriture donne au routeur un meilleur signal pour la classification, car une requête réécrite avec la bonne terminologie interne est plus facile à classer précisément qu’une question utilisateur brute remplie de raccourcis ambigus.

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

Accumulation de contexte dans les workflows multi-étapes

La recherche et le routage opèrent au niveau d’une requête unique. L’orchestration régit ce qui se passe d’une requête à l’autre 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 antérieure récupère un contexte non pertinent ou produit une réponse intermédiaire faible, chaque étape en aval hérite de ce bruit. Les appels de modèle suivants dépensent des tokens à traiter des informations qui dégradent activement leur sortie — non 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 les informations essentielles. Supprimer entièrement l’état intermédiaire après extraction élimine le bruit, et le checkpointing permet à un workflow de redémarrer depuis un état propre à une étape connue comme fiable plutôt que de tout 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’empilent tous deux linéairement.

L’exécution parallèle casse 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 de contexte sélectif. 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 conserver des passages récupérés bruts ni des sorties intermédiaires verbeuses.

Glean Agents utilise une planification multi-étapes avec des sous-agents et une sélection d’outils pour gérer cette complexité. À mesure que les agents d’IA pour l’entreprise gagnent en maturité, chaque sous-agent reçoit une tâche cadrée et le minimum de contexte nécessaire pour la mener à bien, plutôt que l’historique complet de la conversation. L’Agentic Engine coordonne le plan, assigne les sous-agents, sélectionne les outils et fusionne les résultats, en maintenant chaque branche légère et orientée vers un objectif précis.

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

Mesurer l’efficacité des tokens nécessite de suivre les bons indicateurs au bon niveau. Un seul indicateur ne peut pas capturer l’interaction entre la recherche, le routage et l’orchestration. Le tableau ci-dessous associe les indicateurs clés à la couche d’architecture que chacun permet de diagnostiquer.

Le danger d’une focalisation sur un seul indicateur est que les améliorations dans un domaine peuvent, en silence, dégrader un autre. Réduire agressivement la profondeur de recherche diminue 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 nouvelles tentatives qui consomment plus de tokens qu’une recherche plus profonde n’en aurait consommé.

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 seule 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 l’ajustement des poids dans la fonction d’utilité de routage. Vous n’avez pas besoin d’une architecture différente pour un traitement batch sensible aux coûts et pour des requêtes côté utilisateur sensibles à la latence. Vous avez besoin de poids différents sur une même fonction.

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

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

Techniques au niveau de la recherche

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 même de lancer la recherche, puis appliquez ce budget lors de la sélection des passages.

Appliquez un reranking pour faire remonter rapidement les passages les plus pertinents, et arrêtez la recherche dès que vous obtenez un signal suffisant. Un pipeline de recherche en deux étapes, qui recherche largement puis reranke avec précision, vous offre les bénéfices de rappel d’une recherche large avec l’efficacité en tokens de fenêtres de contexte étroites.

Utilisez un découpage en chunks « token-aware » 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 n’ajoutez des détails supplémentaires que progressivement, uniquement lorsque les chunks initiaux ne satisfont pas la requête.

Techniques au niveau du routage

Suivez le pattern « commencer petit, puis escalader ». Routez chaque requête vers le plus petit modèle efficace et la profondeur de recherche la plus faible dans un premier temps, puis escaladez vers un modèle plus grand ou une recherche plus profonde uniquement lorsque la réponse initiale ne répond pas aux seuils de qualité. Une entreprise mid-market a appliqué cette approche et a vu sa facture IA mensuelle passer de 42 000 $ à 11 000 $

— une réduction de 74% — en redirigeant 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 workloads selon leur profil de latence. Les requêtes côté utilisateur ont besoin de réponses rapides et bénéficient d’un routage agressif vers des modèles plus petits, tandis que les tâches de traitement par lots peuvent tolérer une latence plus élevée et une recherche plus approfondie. Faire passer ces workloads par des chemins distincts évite d’imposer à l’un les contraintes de l’autre.

Journalisez chaque décision de routage et surveillez les dérives. 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 ligne 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 conversation en un état compact entre les étapes du workflow. Une gestion intelligente du contexte — en extrayant et en conservant sélectivement les faits clés plutôt qu’en transportant des transcriptions complètes — peut réduire drastiquement l’usage de tokens. L’essentiel est de compresser aux points de rupture naturels plutôt qu’à des limites de tokens arbitraires.

Utilisez une transmission sélective du contexte 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’historique complet 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 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 étape unique de consommer l’allocation de tokens prévue pour les étapes suivantes. Pour les workloads à forte répétition, le caching sémantique peut réduire les coûts d’API jusqu’à 73% en stockant des embeddings de requêtes et en servant des réponses mises en cache pour des requêtes sémantiquement similaires — en éliminant entièrement l’appel au LLM en cas de cache hit.

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 signifie que la couche de retrieval bénéficie d’une couverture étendue sans nécessiter d’appels d’outils redondants durant l’orchestration. Les données sont déjà indexées et avec prise en compte des permissions, de sorte que la couche d’orchestration récupère depuis un index unifié plutôt que d’effectuer des appels d’API distincts vers chaque système source et de traiter leurs réponses brutes.

Questions fréquemment posées

Combien le routage par requête peut-il réellement faire é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 simples qui constituent la majorité des workloads 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 consultation voient de plus grandes économies que celles dont le workload est dominé 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 nécessitent réellement un contexte multi-documents, comme le recoupement d’informations ou l’analyse de tendances à travers plusieurs sources.

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

L’orchestration contrôle la manière dont les tokens s’accumulent dans des workflows en plusieurs étapes. Sans gestion active du contexte, chaque étape s’ajoute à une fenêtre de contexte qui grossit, et les étapes ultérieures paient le coût cumulatif complet. La synthèse, la transmission sélective du contexte et l’exécution parallèle peuvent maintenir le coût des workflows multi-étapes proche de celui 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 les coûts à 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 pondérations 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 unique le plus impactant pour réduire le coût en tokens ?

Définir un budget de contexte explicite par requête et l’appliquer lors du retrieval. Le contexte récupéré est la plus grande composante variable des tokens facturés, et la plupart des dépassements proviennent de la récupération de 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 moteur de coûts.

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 IA passe à l’échelle efficacement ou devient un centre de coûts incontrôlé. Bien maîtriser ces trois couches n’est pas un exercice ponctuel : cela exige des mesures continues, des ajustements de routage et une gestion du contexte à mesure que vos workloads évoluent. Demander une démo pour découvrir comment nous pouvons vous aider à construire des systèmes IA qui fournissent des réponses ancrées dans les faits sans épuiser votre budget de tokens.