Mise en cache du contexte : le répété ne se paie qu'une fois
CoûtOptimisationArchitectureProduction2024-08-1410 min
La plupart des systèmes renvoient le même contexte à chaque requête. Le facturer une seule fois divise la note, à condition d'avoir rangé le prompt dans le bon ordre.
Le constat qui rend l'optimisation évidente
Dans un système documentaire ordinaire, la majeure partie de ce qui est envoyé au modèle est identique d'une requête à l'autre. Consigne système, description des outils, exemples, règles métier : ce bloc ne change pas, et il est refacturé à chaque appel.
Sur les systèmes que je reprends, ce préfixe stable représente couramment les trois quarts des jetons envoyés. La question réellement posée par l'utilisateur en représente moins de cinq pour cent.
La mise en cache du contexte permet de facturer ce préfixe une fois et de le réutiliser ensuite à tarif réduit. L'économie est directe et n'exige aucun changement de modèle ni de qualité.
Ce que le cache impose à la structure du prompt
Le cache fonctionne sur un préfixe exact : tout ce qui varie doit être placé après tout ce qui est stable. C'est la seule contrainte, et elle suffit à empêcher l'optimisation quand elle n'est pas respectée.
L'erreur la plus commune consiste à insérer un élément variable au début, la date du jour, le nom de l'utilisateur, un identifiant de session. Cet élément casse le préfixe, et rien n'est réutilisé.
La restructuration à faire est mécanique. D'abord la consigne système, les règles, la description des outils, les exemples. Ensuite seulement le contexte variable : les extraits récupérés, l'historique, la question.
Ce rangement a un mérite indépendant du cache : il rend le prompt lisible et modifiable. Un prompt où le stable et le variable sont mêlés devient impossible à faire évoluer, ce qui est le sujet d'écrire un prompt système qui tient six mois.
Où le gain est le plus fort
- Les assistants à consigne longue, où les règles métier représentent des milliers de jetons répétés à chaque question.
- Les agents outillés, dont la description des outils est volumineuse et invariable. Voir le protocole qui rend les agents branchables.
- Les traitements par lot sur un même document, où l'on pose vingt questions sur le même contrat.
- Les conversations longues, où le début de l'échange devient un préfixe stable au fil des tours.
Les limites qu'il faut connaître avant de compter dessus
Un cache a une durée de vie courte et un seuil minimal de taille, ce qui le rend inutile sur les usages peu fréquents. Il faut donc vérifier que le profil d'usage s'y prête avant d'en faire une hypothèse budgétaire.
La durée de vie se compte en minutes. Un système consulté trois fois par jour ne bénéficiera d'aucune réutilisation : chaque requête paiera le plein tarif. Un système consulté en continu par une équipe en bénéficiera presque toujours.
Le seuil de taille exclut les prompts courts. En dessous d'un certain nombre de jetons, le préfixe n'est pas mis en cache du tout.
Enfin, le cache ne change rien à la latence de génération ni à la qualité des réponses. C'est une optimisation purement économique, et elle ne dispense pas de réduire le contexte envoyé, le raisonnement de une grande fenêtre reste une facture reste entièrement valable.
La vérification à faire avant d'annoncer une économie
Mesurer le taux de réutilisation réel du cache sur une semaine, pas sur un test. Un système dont l'usage est irrégulier peut afficher un taux très bas, et l'économie annoncée en réunion n'arrivera jamais sur la facture.
Ce que ça change dans la conception d'un agent
Une fois le préfixe mis en cache, ajouter des exemples et des règles détaillées devient presque gratuit, ce qui change l'arbitrage de conception. C'est la conséquence la plus intéressante et la moins exploitée.
Jusqu'ici, allonger la consigne système avait un coût proportionnel au nombre d'appels, ce qui poussait à la concision au détriment de la précision. Beaucoup d'équipes ont raccourci leurs consignes pour des raisons budgétaires, en dégradant le comportement du système.
Avec un préfixe mis en cache, cet arbitrage disparaît en grande partie. On peut donner dix exemples au lieu de deux, expliciter les cas limites, détailler le comportement attendu en cas de doute.
La contrainte redevient alors la bonne : la clarté de la consigne, pas son coût. C'est un déplacement sain, à condition de se rappeler qu'une consigne longue reste plus difficile à maintenir qu'une consigne courte.
L'ordre dans lequel appliquer les optimisations
Réduire le contexte d'abord, mettre en cache ensuite, router en dernier : cet ordre donne le meilleur résultat et il est rarement suivi. L'inverse, router d'abord, produit des systèmes complexes qui envoient encore trop.
La raison est arithmétique. Réduire de moitié le contexte envoyé divise la facture par deux sur tous les paliers à la fois. Mettre en cache un contexte déjà réduit économise sur une base plus petite mais reste très rentable. Router en dernier optimise ce qui reste.
Commencer par le routage donne l'impression d'agir, mais laisse en place le gaspillage principal. Voir une grande fenêtre reste une facture.
Questions fréquentes
- Comment structurer un prompt pour profiter du cache ?
En plaçant tout ce qui est stable au début, consigne, règles, description des outils, exemples, et tout ce qui varie à la fin. Un seul élément variable en tête casse le préfixe et annule la réutilisation.
- Le cache réduit-il aussi la latence ?
Marginalement au mieux. C'est une optimisation économique : elle ne change ni la qualité des réponses ni le temps de génération, et elle ne dispense pas de réduire le contexte envoyé.
- Sur quels usages le gain est-il nul ?
Sur les systèmes peu consultés : la durée de vie d'un cache se compte en minutes, donc un service utilisé trois fois par jour paiera le plein tarif à chaque requête.
- Faut-il en profiter pour allonger la consigne système ?
Oui, dans une certaine mesure : le coût des exemples devient marginal, ce qui permet d'expliciter les cas limites. La limite redevient la maintenabilité, pas le budget.