Pourquoi ce sujet est important
Une grande fenêtre de contexte ne dispense pas de sélectionner l’information. Plus de tokens augmentent coût et latence, et peuvent diluer les instructions importantes. Une application robuste gère le contexte comme une ressource limitée.
Comprendre le budget
La fenêtre inclut instructions, historique, outils, documents et sortie attendue. Réservez toujours un budget de génération et une marge pour les schémas d’outils. Comptez avec le tokenizer du modèle ou l’estimation officielle ; les caractères ne correspondent pas directement aux tokens.
Prioriser les informations
Classez instructions système, demande actuelle, état métier, outils et documents. Les règles essentielles doivent rester proches et non noyées. Retirez duplications, HTML, navigation et anciennes réponses inutiles. Utilisez une structure explicite avec provenance.
Utiliser le RAG
Au lieu d’envoyer tout le corpus, récupérez les passages pertinents. Contrôlez nombre de chunks, redondance et tokens totaux. Ajoutez recherche hybride ou reranking lorsque le retrieval ramène trop de bruit. Citez les sources et permettez une réponse “information absente”.
Résumer sans perdre les faits
Un résumé réduit l’historique mais peut introduire des erreurs. Séparez faits structurés, décisions et résumé conversationnel. Conservez les éléments critiques dans un état typé. Versionnez le résumé et régénérez-le lorsque le format change.
Gérer lost in the middle
Les modèles peuvent accorder moins d’attention aux éléments au milieu d’un long contexte. Placez instructions et preuves les plus importantes clairement, groupez par thème et demandez des citations. Testez la récupération de faits à différentes positions.
Réduire coût et latence
Profitez du cache de prompt lorsqu’il existe, stabilisez les préfixes et évitez de renvoyer les mêmes pièces. Compressez les outils et métadonnées. Mesurez coût par tâche acceptée, pas seulement tokens moyens.
Prévoir les dépassements
Avant l’appel, calculez le budget. Si le contexte dépasse, appliquez une politique déterministe : retirer éléments faibles, résumer, refaire le retrieval ou demander de préciser. Ne tronquez pas silencieusement le début ou la fin.
Exemple concret
Un assistant projet conserve objectifs et décisions dans un état structuré, résume les échanges anciens et récupère les documents à la demande. Avant chaque appel, il réserve 20 % pour la sortie. Lorsque trop de documents sont pertinents, il demande à l’utilisateur de choisir la période.
Les erreurs fréquentes
- utiliser toute la fenêtre parce qu’elle existe
- tronquer sans journaliser
- résumer des décisions critiques en texte libre
- envoyer des chunks redondants
- confondre mémoire et historique complet
- ne pas réserver de tokens de sortie
Checklist
- [ ] Budget par composant défini
- [ ] Tokenizer ou estimation fiable
- [ ] Priorités de contexte explicites
- [ ] État structuré séparé du résumé
- [ ] Retrieval et redondance mesurés
- [ ] Politique de dépassement testée
- [ ] Coût et latence surveillés
FAQ
Une fenêtre plus grande améliore-t-elle toujours la qualité ?
Non. Le bruit, la position et le coût peuvent dégrader le résultat.
RAG ou contexte long ?
Souvent les deux : le RAG sélectionne et la fenêtre contient les passages nécessaires.
Peut-on résumer indéfiniment ?
Les erreurs s’accumulent. Conservez faits structurés et vérifiez périodiquement contre les sources.
Comment fixer le budget de sortie ?
À partir du format attendu et des mesures réelles, avec une marge pour les cas longs.