La plupart des équipes d'IA d'entreprise optimisent le mauvais levier. Elles se concentrent sur l'hygiène des prompts — instructions plus courtes, moins de verbiage, formulation compressée — alors que les véritables gains en efficacité des tokens proviennent de ce qui se passe avant même que le modèle ne voie un prompt : la qualité de la récupération, la sélection du contexte et la conception de l'orchestration.
L'efficacité des tokens dans l'IA d'entreprise, c'est la capacité à obtenir des réponses de haute qualité en utilisant le minimum de contexte et de calcul nécessaires. Dans les systèmes en production, cela signifie que les plus grandes opportunités ne se trouvent généralement pas dans le prompt lui-même, mais dans ce qui est récupéré, sélectionné et transmis au modèle en amont de la génération.
Pour les équipes d'entreprise, l'efficacité des tokens dépasse le simple impact budgétaire. Elle influe sur la latence, la qualité des réponses, la confiance et la capacité d'un système d'IA à tenir la charge à mesure qu'il se déploie auprès des utilisateurs et des workflows. Un système qui envoie moins de bruit au modèle tend à être à la fois moins coûteux, plus rapide, mieux étayé et plus digne de confiance. Une stratégie de tokens intelligente cherche davantage à obtenir le meilleur résultat par token qu'à réduire le nombre de tokens à tout prix.
Ce que signifie réellement l'efficacité des tokens pour l'IA d'entreprise
Définir l'efficacité des tokens comme le fait d'« utiliser moins de tokens » passe à côté de l'essentiel. Voici une définition plus utile : l'efficacité des tokens est la capacité à accomplir une tâche avec le moins de contexte et de calcul possible, tout en produisant un résultat solide. Il s'agit donc autant d'un indicateur métier que d'un indicateur de modèle.
Dans les environnements d'entreprise, une meilleure efficacité des tokens signifie généralement :
- Un coût d'inférence réduit
- Des réponses plus rapides pour les utilisateurs
- Des réponses plus fiables et mieux étayées
- Un meilleur passage à l'échelle entre les équipes, les workflows et les cas d'usage
- Moins de bruit à traiter par le modèle
Plus de contexte ne signifie pas automatiquement un meilleur contexte. Une large fenêtre de contexte peut masquer une conception système défaillante pendant un temps, mais elle ne corrige pas les problèmes de fond. Si le système continue de transmettre des informations non pertinentes, le modèle doit toujours traiter du bruit avant de pouvoir trouver le signal. C'est pourquoi l'efficacité des tokens dans l'IA d'entreprise est, en définitive, à la fois un problème de qualité, de latence et de coût.
D'où vient réellement le gaspillage de tokens
Les prompts gaspillent effectivement des tokens. Mais dans les systèmes d'entreprise, la longueur du prompt pèse souvent moins qu'il n'y paraît. Les principales sources de gaspillage comprennent :
- Récupérer trop de documents
- Envoyer de longs extraits alors que seul un court passage compte
- Dupliquer la même information d'un outil, d'un tour ou d'une étape de workflow à l'autre
- Transmettre des documents entiers alors que seules quelques lignes sont pertinentes
- Demander au modèle de raisonner sur des preuves bruyantes ou mal classées
- Répéter le contexte dans des workflows en plusieurs étapes au lieu de résumer les états intermédiaires
Prenons un scénario courant : un assistant IA doit répondre à une question sur une politique RH, expliquer une règle financière ou résumer un problème d'assistance interne. Le système récupère huit longs documents, dont seuls deux courts passages sont réellement pertinents. Que le prompt soit formulé efficacement ou non, le problème n'est pas le prompt. Le gaspillage de tokens a commencé en amont, lorsque le système a fourni trop de preuves avec trop peu de sélectivité.
Pourquoi la récupération compte plus que la longueur du prompt
Si un prompt plus épuré peut économiser quelques tokens, une meilleure récupération peut transformer entièrement le profil économique et qualitatif d'un système d'IA. Imaginez deux ajustements sur un même workflow : raccourcir un prompt de 15 % et réduire de 60 % le contexte récupéré non pertinent.
Le premier aide un peu. Le second améliore généralement le coût, la latence et la qualité des réponses en même temps — parce que la récupération détermine ce que le modèle doit lire avant de pouvoir réfléchir. De mauvais documents, des extraits mal délimités ou un classement médiocre font que le modèle dépense des tokens à traiter un contexte qui n'apporte rien à la réponse. Dans certains cas, ce contexte supplémentaire dégrade la réponse, entraînant le modèle vers des digressions, du contenu obsolète ou des preuves contradictoires.
Pour la génération augmentée par récupération et les systèmes agentiques, les enjeux sont plus élevés. Le gaspillage de tokens se cumule d'une étape à l'autre. Une première étape de récupération surchargée reporte ses coûts sur l'étape suivante, et celle d'après. Au moment où le workflow s'achève, le système a payé maintes fois pour un mauvais contexte.
Les équipes d'entreprise devraient aborder l'optimisation des tokens d'abord comme un problème de récupération, et seulement ensuite comme un problème de prompting.
À quoi ressemble un système d'IA d'entreprise bien conçu
Résoudre l'efficacité des tokens à grande échelle exige une couche de contexte qui connaît ce que connaît votre entreprise — une couche qui récupère des connaissances à jour dans tous vos outils, respecte fidèlement les autorisations et fait remonter des passages précis plutôt que des documents entiers.
La plateforme Work AI de Glean s'articule autour du Contexte d'entreprise — un système de contexte partagé qui aide l'IA à récupérer de meilleures preuves, à respecter les autorisations et à agir sur les connaissances actuelles de l'entreprise. Plutôt que de traiter chaque document comme un bloc de texte isolé, Glean relie la récupération aux relations, autorisations et structures de connaissances qui existent déjà dans les systèmes d'une organisation. Le résultat est une fondation où la qualité de la récupération s'améliore en premier, et où les décisions de chunking, de prompting et d'orchestration partent toutes de meilleures preuves.
Le cadre d'entreprise pour l'efficacité des tokens
Les meilleures équipes d'IA d'entreprise optimisent l'ensemble de la pile technologique. On peut concevoir cette optimisation comme composée de quatre couches :
Couche 1 : récupérer moins, mais récupérer mieux
Commencez par la qualité de la récupération. Le système doit trouver le plus petit ensemble de preuves capable de soutenir une réponse solide — ce qui signifie améliorer la précision, et pas seulement le rappel. Un meilleur classement et reclassement sont ici essentiels, tout comme la réduction de l'espace de recherche à l'aide des métadonnées, des autorisations, de la propriété, de la récence et du contexte de la tâche.
Réussir la récupération exige une couche de contexte solide. Les systèmes doivent savoir quel contenu est pertinent pour l'utilisateur, quelle version est à jour, quels artefacts sont liés et quelles informations l'utilisateur est réellement autorisé à consulter. Glean ancre la récupération dans les connaissances à jour de l'entreprise, les autorisations et les relations entre systèmes — pour que moins de tokens non pertinents n'atteignent jamais le prompt.
Couche 2 : ne transmettre que les preuves qui comptent
Une fois les bonnes sources récupérées, la tâche suivante consiste à éviter la tentation de tout transmettre. Les systèmes d'entreprise devraient recourir à des capacités de chunking et de sélection de passages pour éviter d'envoyer des documents entiers lorsque quelques passages suffisent. L'objectif : des chunks sémantiquement pertinents, une sélection au niveau du passage, la déduplication et une compression sélective. Un assistant qui répond à une question de politique ou qui traite un cas d'assistance n'a pas besoin de la page wiki entière, du fil Slack complet et de l'intégralité de la fiche CRM. Il a besoin des passages précis qui étayent la réponse.
C'est l'une des différences les plus nettes entre un prototype et un système en production. Les prototypes entassent du contexte par sécurité. Les systèmes en production apprennent à être sélectifs.
Niveau 3 : structurer les prompts pour le contrôle, pas pour la compression
La conception des prompts reste importante, mais ce n'est pas votre levier principal. Un bon prompt d'entreprise confie au modèle une tâche claire, un format de sortie clair et le minimum de contexte nécessaire. Il évite les instructions répétées, les textes de politique dupliqués et le contexte large qui a sa place ailleurs dans le système. L'ingénierie de prompts la plus durable concerne le contrôle, pas la compression :
- Énoncez clairement la tâche.
- Précisez le format de sortie.
- Contraignez la réponse là où c'est nécessaire.
- Évitez de répéter des instructions que le système connaît déjà.
- Gardez le modèle concentré sur les preuves récupérées.
Si le système environnant est bruité, un prompt parfaitement concis ne le sauvera pas.
Niveau 4 : orchestrer intelligemment à chaque étape
L'efficacité des tokens dépend aussi de la conception du flux de travail. Dans les systèmes agentiques ou multi-étapes, une source fréquente de gaspillage consiste à envoyer le même contexte brut à répétition à chaque étape. Une meilleure approche consiste à découper le travail en phases, à résumer les sorties intermédiaires, à acheminer les tâches vers les bons outils et à éviter de recharger des informations identiques à moins qu'elles ne soient réellement nécessaires à nouveau.
Bien gérée, l'orchestration devient un véritable accélérateur de performance. Un système qui décide quoi récupérer, quoi résumer, quoi mettre en cache et quoi ne pas répéter surpassera souvent un système doté d'une fenêtre de contexte plus grande mais d'une coordination plus faible. Au-delà de l'accès au modèle, les agents d'entreprise ont besoin d'une récupération fiable, d'un contexte respectueux des autorisations et d'une logique de flux de travail qui empêche le contexte non pertinent d'atteindre le modèle.
Comment mesurer l'efficacité des tokens sans sacrifier la qualité des réponses
La mauvaise façon de mesurer l'efficacité des tokens est d'optimiser uniquement pour un minimum de tokens. Couper de manière trop agressive — en supprimant des preuves nécessaires, en condensant un contexte important — produit des réponses à la fois moins chères et plus faibles. La meilleure question à se poser est : quel résultat obtenez-vous par token ?
Un ensemble pratique d'indicateurs d'évaluation comprend :
- Les tokens par tâche réussie
- La latence par tâche
- Le coût par tâche
- La précision de la récupération
- La qualité ou l'ancrage factuel des réponses
- Le taux d'utilisation du contexte
Le taux d'utilisation du contexte est particulièrement utile. Si le système transmet systématiquement de grandes quantités de contexte qui n'influencent jamais la réponse finale, le système paie pour du bruit. Les équipes doivent savoir non seulement combien de tokens elles ont utilisés, mais aussi si ces tokens ont amélioré le résultat. Les systèmes qui font apparaître des citations, des liens vers les sources et des chaînes de preuves claires facilitent cette inspection et cette amélioration au fil du temps.
Les erreurs courantes des équipes d'entreprise
Quelques schémas reviennent régulièrement.
Considérer les prompts plus courts comme le levier principal. Cela pousse les équipes à trop se concentrer sur la réduction des mots tout en ignorant des problèmes plus importants : une mauvaise récupération, des fragments surdimensionnés et un contexte redondant.
Supposer que de grandes fenêtres de contexte résolvent le problème. Des fenêtres plus grandes peuvent retarder les choix de conception difficiles, mais elles n'éliminent pas l'impact du contexte non pertinent sur le coût, la latence ou la qualité. Elles rendent simplement le coût moins visible.
Optimiser uniquement pour le coût. Une réponse moins coûteuse n'est pas meilleure si elle est plus difficile à valider, moins ancrée factuellement ou moins utile à la personne qui pose la question.
Mesurer le nombre de tokens sans mesurer la qualité de la récupération. Les chiffres de tokens à eux seuls n'expliqueront pas pourquoi les réponses sont coûteuses ou incohérentes si la couche de récupération est la véritable source du problème.
Compresser le contexte de manière trop agressive. La compression du contexte n'aide que si le détail important survit. Supprimez la preuve exacte dont dépend une réponse, et le système coûte moins cher mais offre des réponses plus faibles.
Toutes ces erreurs reflètent la même méprise : traiter l'efficacité des tokens comme un exercice d'édition de prompts plutôt que comme une discipline de conception de systèmes.
Concevoir pour de meilleurs résultats par token
L'efficacité des tokens dans l'IA d'entreprise est un problème d'architecture déguisé en problème de prompting. Les équipes qui se concentrent sur le raccourcissement des prompts peuvent récupérer quelques tokens à la marge. Les équipes qui améliorent la récupération, la sélection du contexte et l'orchestration peuvent améliorer ensemble le coût, la vitesse et la qualité des réponses. Mais cela nécessite de concevoir des systèmes d'IA qui n'envoient que le bon contexte au bon moment.
Pour un examen plus approfondi de la façon dont les équipes d'IA d'entreprise améliorent la qualité et l'efficacité des réponses grâce à une meilleure récupération et à un meilleur ancrage, explorez la plateforme Glean.
Questions fréquentes
Quelle est la différence entre l'efficacité des tokens et la taille de la fenêtre de contexte ?
La taille de la fenêtre de contexte est une capacité du modèle — la quantité de texte qu'un modèle peut techniquement recevoir et traiter. L'efficacité des tokens est une discipline de conception de systèmes — la part de cette capacité que vous devez réellement utiliser pour obtenir une réponse solide. Une fenêtre de contexte plus grande donne à un système plus de marge de manœuvre, mais elle ne rend pas le système plus efficace. Les équipes qui comptent sur de grandes fenêtres pour absorber une mauvaise récupération ou un contexte redondant paient pour un espace dont elles ne devraient pas avoir besoin. L'objectif est d'utiliser la plus petite fenêtre nécessaire pour produire la bonne réponse, et non de remplir la plus grande fenêtre disponible.
Quelles sont les limites de l'optimisation des tokens dans l'IA d'entreprise ?
L'optimisation des tokens a un plancher. En dessous d'un certain seuil, la suppression de contexte commence à retirer les preuves dont le modèle a besoin pour produire des réponses précises et ancrées factuellement, et le système devient à la fois moins coûteux et moins fiable. L'optimisation ne peut pas non plus compenser une couche de récupération fondamentalement faible ou une orchestration mal conçue. Les équipes qui se concentrent étroitement sur le nombre de tokens sans mesurer la qualité des réponses, la précision de la récupération et l'utilisation du contexte finissent souvent avec des systèmes plus légers mais de moins bonne qualité.
Pourquoi la qualité de la récupération affecte-t-elle autant le coût des tokens ?
La qualité de la récupération contrôle directement la quantité de contexte qui atteint le modèle — ce qui en fait l'une des variables à plus fort effet de levier dans tout système d'IA d'entreprise. Lorsque la récupération est imprécise, le modèle reçoit plus de tokens qu'il n'en a besoin : trop de documents, des fragments mal délimités ou des preuves faiblement classées qui n'apportent rien à la réponse. Dans les systèmes de génération augmentée par récupération en particulier, le problème s'aggrave. Un pipeline RAG qui renvoie de larges correspondances de similarité plutôt que des passages spécifiques et respectueux des autorisations oblige le modèle à traiter du bruit à chaque étape. Traitez la précision de la récupération comme une contrainte de conception de premier ordre, et non comme une réflexion après coup, et l'efficacité des tokens tend à suivre.
En quoi la recherche d'entreprise diffère-t-elle du RAG standard en matière d'efficacité des tokens ?
De nombreuses implémentations RAG basiques reposent fortement sur la recherche par similarité, tandis que la recherche d'entreprise superpose des signaux supplémentaires comme les autorisations, la récence, la propriété et les relations entre systèmes. Ces signaux supplémentaires permettent à la recherche d'entreprise de restreindre la récupération avec plus de précision — en renvoyant moins de passages, mais plus pertinents, plutôt qu'une large correspondance par similarité. Pour l'efficacité des tokens, cette distinction compte énormément. La recherche d'entreprise de Glean est construite autour de ces couches, c'est pourquoi elle tend à réduire le gaspillage de tokens dès l'étape de récupération plutôt qu'à le compenser en aval par des prompts plus longs ou des fenêtres de contexte plus larges.
Comment Glean aide-t-il à réduire le gaspillage de tokens dans les systèmes d'IA d'entreprise ?
Glean réduit le gaspillage de tokens en ancrant la récupération dans les connaissances actualisées de l'entreprise, les contrôles d'accès entre systèmes et les relations entre contenus, de sorte que les systèmes d'IA récupèrent un ensemble de preuves plus restreint et plus pertinent plutôt que de larges déversements de documents. Parce que Glean comprend qui pose la question, ce que cette personne est autorisée à voir et comment les contenus entre les différents outils se rapportent à la requête, il peut renvoyer des passages précis plutôt que des documents entiers. Cela réduit le bruit qui parvient au modèle, ce qui améliore généralement à la fois le coût, la latence et la qualité des réponses.
