Réduire de moitié le contexte envoyé
CoûtOptimisationTutorielProduction2025-10-0710 min
Sur les systèmes que je reprends, la moitié du contexte envoyé ne sert jamais. Le retirer divise la facture et améliore souvent la qualité des réponses.
Le constat, mesuré et non supposé
Sur la plupart des systèmes en production, une moitié du contexte envoyé à chaque requête n'intervient jamais dans la réponse. Ce n'est pas une estimation : cela se mesure en une journée.
Le contexte d'une requête se compose en général de quatre blocs : la consigne système, des exemples, les extraits récupérés, et l'historique de conversation. Chacun a été ajouté pour une bonne raison, et aucun n'a été revu depuis.
Les exemples sont le cas le plus net. Ajoutés au démarrage pour orienter le modèle, ils restent en place alors que les modèles suivants n'en ont plus besoin. Ils coûtent à chaque appel, indéfiniment.
La mesure qui identifie le gras, en une journée
Retirer un bloc, relancer le jeu de tests, comparer le taux d'erreur : si rien ne bouge, le bloc ne servait pas. C'est la seule méthode fiable, et elle est mécanique.
La démarche prend une journée pour quatre blocs. On retire les exemples, on mesure. On réduit le nombre d'extraits de dix à cinq, on mesure. On tronque l'historique à cinq tours, on mesure. On raccourcit la consigne, on mesure.
À chaque étape, deux résultats possibles. Le taux d'erreur ne bouge pas : le retrait est acquis, l'économie aussi. Le taux d'erreur monte : on remet, et on sait désormais que ce bloc sert.
Cette démarche suppose évidemment un jeu de tests. Sans lui, chaque retrait devient un pari, et la prudence conduit à ne rien retirer, ce qui est exactement ce que je constate sur les systèmes sans mesure.
Les quatre coupes qui rapportent le plus
- Les exemples devenus inutiles, souvent des milliers de jetons répétés à chaque appel pour un effet nul sur les modèles récents.
- Le nombre d'extraits récupérés, presque toujours trop élevé. Cinq bien choisis valent mieux que vingt. Voir le RAG, la seule architecture qui tienne.
- L'historique de conversation, dont le coût croît de façon quadratique s'il n'est pas tronqué ou résumé.
- Les métadonnées inutilisées jointes aux extraits : chemins de fichiers, identifiants techniques, horodatages complets.
Pourquoi réduire améliore souvent la qualité
Retirer du contexte inutile augmente fréquemment le taux de bonnes réponses, ce qui surprend les équipes et rend la démarche facile à défendre. Le mécanisme est documenté.
Un modèle qui reçoit vingt extraits dont deux sont pertinents dispose de dix-huit occasions de se tromper de source. En réduisant à cinq extraits mieux choisis, on ne perd pas d'information utile et on retire du bruit.
S'y ajoute l'effet de position : l'information placée au milieu d'un long contexte est moins bien exploitée que celle placée aux extrémités. Un contexte plus court réduit mécaniquement la part d'information mal placée.
La conséquence pratique va contre le réflexe naturel. Face à une réponse insatisfaisante, la tentation est d'envoyer davantage. Le bon geste est presque toujours d'envoyer moins, mieux sélectionné, le raisonnement de une grande fenêtre reste une facture.
L'ordre dans lequel appliquer les optimisations
Réduire d'abord, mettre en cache ensuite, router en dernier : cet ordre donne le meilleur résultat et il est rarement suivi. La raison est arithmétique.
Réduire de moitié le contexte divise la facture par deux sur tous les paliers à la fois, et le gain persiste quel que soit le modèle ensuite choisi.
Mettre en cache un contexte déjà réduit économise sur une base plus petite, mais reste très rentable, le mécanisme décrit dans le contexte répété ne se paie qu'une fois.
Router en dernier optimise ce qui reste, sur un système déjà sobre.
Commencer par le routage donne l'impression d'agir tout en laissant en place le gaspillage principal. C'est pourtant l'ordre que je rencontre le plus souvent, parce que le routage est plus intéressant techniquement que la suppression de blocs devenus inutiles.
La mesure à afficher pour tenir l'acquis
Le nombre moyen de jetons envoyés par requête, suivi dans le temps. Sans cet indicateur, le contexte regrossit en six mois : chaque incident produit une consigne supplémentaire, et personne ne retire jamais rien.
Ce qu'il faut protéger dans la réduction
Deux éléments ne doivent jamais être coupés : la consigne de refus et l'indication des sources. Ils coûtent peu et leur retrait dégrade fortement l'exploitation.
La consigne de refus définit ce que le système répond quand il ne sait pas. Elle représente quelques dizaines de jetons et conditionne le comportement le plus important en production. La retirer parce qu'elle « ne change rien sur le jeu de tests » est une erreur : le jeu de tests contient rarement assez de questions hors périmètre.
L'indication des sources permet à l'utilisateur de vérifier. Elle coûte peu et constitue le principal facteur de confiance dans un système documentaire.
J'ajoute donc au jeu de tests, avant toute campagne de réduction, une dizaine de questions hors périmètre. Sans elles, l'optimisation supprime précisément ce qui protège.
Questions fréquentes
- Comment savoir ce qui peut être retiré ?
En retirant un bloc, en relançant le jeu de tests et en comparant le taux d'erreur. Si rien ne bouge, le bloc ne servait pas. La démarche prend une journée pour quatre blocs.
- Réduire le contexte dégrade-t-il les réponses ?
Souvent l'inverse. Vingt extraits dont deux sont pertinents donnent dix-huit occasions de se tromper de source ; cinq extraits mieux choisis retirent du bruit sans perdre d'information.
- Dans quel ordre optimiser ?
Réduire, puis mettre en cache, puis router. Réduire divise la facture sur tous les paliers à la fois et le gain persiste quel que soit le modèle choisi ensuite.
- Que ne faut-il jamais couper ?
La consigne de refus et l'indication des sources. Elles coûtent quelques dizaines de jetons et conditionnent le comportement le plus important en production ainsi que la confiance des utilisateurs.