Le caching : éviter de payer deux fois

Le principe du caching de prompt

Plusieurs fournisseurs (Anthropic pour Claude, OpenAI pour GPT, et d'autres) proposent un mécanisme de caching : si une partie identique d'un prompt (par exemple, un long contexte système réutilisé à chaque requête) est envoyée plusieurs fois, le fournisseur peut facturer cette partie à un tarif réduit lors des appels suivants, au lieu de la refacturer intégralement à chaque fois.

Où le caching apporte le plus de valeur

flowchart TD
    A[Prompt avec partie fixe\net partie variable] --> B{Partie fixe\nreutilisee ?}
    B -- Oui, meme contexte\na chaque requete --> C[Caching efficace:\ncout reduit sur\nla partie fixe]
    B -- Non, tout change\na chaque requete --> D[Caching peu utile]

Le caching est particulièrement rentable pour des systèmes qui réutilisent un long contexte système ou une base de connaissances identique à chaque requête (typiquement un système RAG avec un prompt système stable), moins pertinent pour des requêtes entièrement uniques à chaque fois.

Structurer un prompt pour maximiser le caching

Placer la partie stable et réutilisée (instructions système, contexte fixe) au début du prompt, et la partie variable (question spécifique de l'utilisateur) à la fin, maximise généralement l'efficacité du mécanisme de caching proposé par la plupart des fournisseurs.

[Partie fixe, mise en cache] Instructions système détaillées,
contexte de l'entreprise, exemples few-shot...

[Partie variable, jamais en cache] Question spécifique de
l'utilisateur pour cette requête précise

Cas concret

Un système de support client envoie à chaque requête un prompt système détaillé de plusieurs milliers de tokens (ton, procédures, exemples), suivi de la question spécifique du client, qui elle varie à chaque fois. Sans caching, chaque requête refacture intégralement ces milliers de tokens de contexte fixe. En activant le mécanisme de caching du fournisseur et en structurant le prompt avec la partie fixe en premier, l'entreprise réduit significativement son coût total sur un volume important de requêtes quotidiennes, la partie fixe n'étant facturée à taux plein qu'une seule fois par période de validité du cache.

Erreurs fréquentes

• Ne jamais activer ou structurer son prompt pour bénéficier du caching, alors que cette fonctionnalité, quand elle est pertinente, réduit significativement les coûts sans aucun compromis sur la qualité.
• Placer la partie variable du prompt avant la partie fixe, empêchant le mécanisme de caching de fonctionner efficacement pour la plupart des implémentations.
• Chercher à mettre en cache une partie du prompt qui change en réalité à chaque requête, un usage qui n'apporte aucun bénéfice réel de caching.

À retenir

• Le caching de prompt réduit le coût facturé pour la partie stable et réutilisée d'un prompt envoyé plusieurs fois.
• Le caching est particulièrement rentable pour des systèmes réutilisant un long contexte fixe (RAG, prompt système détaillé) à chaque requête.
• Placer la partie fixe en début de prompt et la partie variable à la fin maximise généralement l'efficacité du caching proposé par la plupart des fournisseurs.

Mini-exercice

Un système envoie un prompt système fixe de 3000 tokens suivi d'une question variable de 50 tokens, à chaque requête, plusieurs milliers de fois par jour. Quelle optimisation de structure de prompt maximiserait l'efficacité du caching ?

Réponse : structurer le prompt avec la partie fixe (les 3000 tokens de contexte système) en premier, suivie de la partie variable (la question de 50 tokens) à la fin, permettant au mécanisme de caching du fournisseur de reconnaître et facturer à taux réduit la partie fixe réutilisée à chaque requête.