Pourquoi optimiser : coût, latence, performance
Trois raisons majeures motivent l’optimisation du contexte :- Coût : les APIs LLM facturent au token. Un contexte deux fois plus court coûte deux fois moins cher, à volume d’usage constant, cela peut représenter des milliers d’euros par mois
- Latence : moins de tokens à traiter signifie une réponse plus rapide. La latence de génération est en partie proportionnelle à la longueur du contexte d’entrée
- Performance : les modèles ont une attention limitée. Un contexte surchargé de bruit dilue les informations utiles et dégrade la qualité des réponses, phénomène parfois appelé lost in the middle
Il existe un arbitrage fondamental entre qualité et coût. Supprimer trop agressivement le contexte peut priver le modèle d’informations nécessaires et dégrader les réponses. L’objectif n’est pas d’avoir le contexte le plus court possible, mais le contexte minimalement suffisant pour la tâche. Mesurez toujours l’impact sur la qualité avant de déployer une optimisation en production.
Stratégies d’optimisation
Compression par résumé
Remplacez les longs documents ou l’historique de conversation par des résumés concis. Un résumé bien rédigé peut conserver 90 % de la valeur informationnelle en utilisant 20 % des tokens originaux.
Extraction ciblée
Plutôt que d’injecter un document entier, extrayez uniquement les passages directement pertinents à la question. Combinez avec le RAG pour une sélection automatique et précise.
Prompt caching
Réutilisez les préfixes de contexte coûteux (instructions système, documents de référence) grâce aux mécanismes de caching natifs des APIs. Réduction de coût pouvant atteindre 90 % sur les tokens mis en cache.
Sélection dynamique
Ne construisez pas un contexte statique universel. Sélectionnez dynamiquement les chunks, exemples ou outils pertinents en fonction de chaque requête spécifique.
Compression de contexte : techniques concrètes
Résumé de l’historique de conversation : Au lieu de conserver tous les échanges passés, résumez régulièrement les tours de conversation anciens. Une approche courante consiste à résumer les échanges au-delà d’un certain seuil (ex. : au-delà de 10 tours) :Prompt caching : réutiliser les préfixes coûteux
Le prompt caching est l’une des optimisations les plus efficaces disponibles aujourd’hui. Les principaux fournisseurs (Anthropic, OpenAI, Google) proposent des mécanismes permettant de mettre en cache la portion répétitive de vos prompts. Structure optimale pour le caching :Sélection dynamique du contexte
L’idée est simple : ne fournir au modèle que ce dont il a besoin pour cette requête précise, pas un contexte universel couvrant tous les cas. Sélection d’outils dynamique (pour les agents) :Mesurer l’efficacité : qualité vs tokens
Toute optimisation doit être mesurée. Construisez un tableau de bord minimal avec ces métriques :
Ne déployez une optimisation que si la qualité reste stable ou s’améliore sur votre set de test.
Checklist d’optimisation du contexte
1
Auditer le contexte actuel
Loggez vos prompts en production et analysez leur composition. Quelle part est l’instruction système ? Les documents ? L’historique ? La question ? Identifiez le poste le plus coûteux.
2
Éliminer le bruit
Supprimez les informations non pertinentes à la tâche courante : métadonnées inutiles, répétitions, instructions redondantes. Vérifiez que chaque token a une raison d’être présent.
3
Activer le prompt caching
Réorganisez votre prompt pour placer les éléments stables en tête. Activez le caching via les paramètres d’API de votre fournisseur. Mesurez le taux de cache hit après déploiement.
4
Implémenter la sélection dynamique
Remplacez les contextes statiques par une sélection basée sur la requête (RAG pour les documents, sélection sémantique pour les exemples et les outils).
5
Compresser l'historique
Mettez en place une stratégie de résumé de l’historique de conversation pour les sessions longues. Définissez un seuil de tours au-delà duquel les échanges sont résumés.
6
Mesurer et itérer
Comparez les métriques avant/après chaque optimisation : coût, latence, et surtout qualité. Utilisez un set de test représentatif. N’optimisez pas à l’aveugle : chaque décision doit être validée par les données.
