Context Length Exceeded : réduire la requête et vérifier le résultat
Mesurez chaque élément du contexte, supprimez les doublons et l'historique inutile, réservez de la place pour la réponse et vérifiez les faits essentiels.
Sommaire
Context Length Exceeded : réduire la requête et vérifier le résultat
Ne corrigez pas Context length exceeded en supprimant au hasard la moitié du prompt. Calculez le budget total, identifiez le modèle et mesurez chaque composant. Retirez ensuite les doublons mécaniques, l’historique non pertinent et les résultats d’outils lourds. Après le nouvel envoi, vérifiez que l’erreur a disparu et que les faits obligatoires ainsi qu’une réponse complète ont été conservés.
Ce qui remplit la fenêtre de contexte
Le contexte est la mémoire de travail d’une requête entière, et non le seul dernier prompt utilisateur. En version simplifiée :
system instructions
+ conversation history
+ current message
+ images and documents
+ tool definitions
+ tool results
+ output / thinking budget
= total context usageLa documentation d’Anthropic sur les fenêtres de contexte inclut explicitement le prompt système, tous les messages, les images, les documents, les définitions d’outils, les résultats d’outils et la réponse générée. Le prompt caching modifie le coût des jetons réutilisés, mais ne les retire pas de la fenêtre.
N’inscrivez pas une « limite universelle » dans le code : la taille de la fenêtre et le comportement en cas de dépassement dépendent du modèle et de l’API sélectionnés. Consultez la fiche du modèle le jour même de la configuration.
Trouver le composant le plus lourd
| Composant | À mesurer | Réduction sûre |
|---|---|---|
| Instructions système | Règles répétées et exemples longs | Fusionner les doublons et conserver les contraintes obligatoires |
| Historique | Jetons par message et anciennes branches | Retirer les branches inutiles ou les remplacer par un résumé vérifiable |
| Fichiers et fragments RAG | Taille de chaque document, doublons et fragments peu pertinents | Réduire top_k, dédupliquer et ne transmettre que les sections nécessaires |
| Définitions d’outils | Outils inutilisés et descriptions trop longues | Ne transmettre que les outils nécessaires à l’étape actuelle |
| Résultats d’outils | JSON complets, journaux, HTML, base64 et réponses répétées | Garder les champs, liens et identifiants requis ; stocker les gros volumes hors prompt |
| Budget de sortie | max_tokens et budget de réflexion | Réserver une marge réaliste ou découper un long résultat en étapes |
Claude propose une API de comptage des jetons qui tient compte des messages et des outils avant l’envoi. Pour un autre fournisseur, utilisez son compteur s’il existe. Un tokenizer local peut alerter tôt, mais son estimation ne garantit pas le calcul côté serveur d’un autre modèle.
Ouvrez la documentation API BetterToken actuelle, lancez une courte requête test et retrouvez-la dans Dashboard. Comparez les tokens d’entrée, de sortie et de cache avant et après réduction du contexte : une baisse des tokens d’entrée confirme que la correction atteint l’appel réel. Dashboard n’affiche pas le prompt complet et ne remplace pas le comptage préalable.
Réduire la taille sans perdre le sens
1. Supprimer les doublons mécaniques
Recherchez les règles système répétées, le même fichier dans plusieurs messages, les fragments RAG dupliqués, les schémas insérés plusieurs fois et les journaux complets recollés. C’est l’étape la plus sûre, car elle réduit le volume sans modifier la tâche.
2. Retirer l’historique non pertinent
Séparez les faits durables du déroulé temporaire de la conversation. Conservez les objectifs, les décisions validées, les contraintes obligatoires et les questions ouvertes. Les anciens raisonnements, options rejetées et résultats d’outils déjà exploités peuvent être supprimés ou condensés dans un résumé structuré.
Un mauvais résumé dit : « nous avons discuté de l’intégration ». Un bon résumé indique le endpoint choisi, la version du schéma, les contraintes validées, les faits confirmés et la prochaine étape.
3. Compacter fichiers, RAG et résultats d’outils
Transmettez les sections pertinentes au lieu d’un document entier. Dans un résultat d’outil, gardez les champs requis pour l’étape suivante plutôt que toute la réponse HTTP ou tout le journal. Ne supprimez pas des sources ou données obligatoires simplement pour faire entrer la requête : découpez plutôt le travail en plusieurs étapes vérifiables.
4. Laisser de la place pour la réponse
L’entrée et la sortie partagent le même budget. Si la requête remplit presque la fenêtre, le modèle peut ne plus avoir assez de place pour répondre complètement. Réduisez l’entrée facultative, choisissez un budget de sortie réaliste ou scindez le résultat. Ne retirez les faits critiques qu’après les doublons mécaniques.
5. Changer de modèle seulement après mesure
Un modèle à contexte plus large peut convenir à un document impossible à découper sans risque. Passer à une fenêtre plus grande sans supprimer les doublons ne fait que reporter la prochaine erreur et peut diminuer la densité d’information.
Vérification minimale avant l’envoi
components = count_by_section(request)
estimated_input = sum(components)
reserved_output = requested_output_budget
if estimated_input + reserved_output approaches current_model_window:
remove exact duplicates
drop irrelevant history
compact tool results and retrieved chunks
count again
send only after required facts and constraints remain presentLe mot approaches n’est volontairement pas remplacé par un pourcentage fixe. La marge nécessaire dépend de la précision du compteur, du modèle, du raisonnement et du comportement de l’API concernée.
Vérifier la correction
Comparez la nouvelle requête à cette liste de contrôle :
- L’API ne renvoie plus
context length exceededniprompt is too long. - La réponse se termine normalement au lieu d’être coupée par le budget de sortie.
- La réponse contient tous les faits obligatoires, contraintes et le format demandé.
- Les citations ou liens correspondent toujours aux sources transmises.
- Les appels d’outils utilisent les bons arguments et aucun résultat important n’a été perdu lors de la compaction.
- La nouvelle consommation d’entrée est réellement inférieure à celle d’origine.
Si l’erreur disparaît mais que le modèle oublie une contrainte essentielle, la correction a échoué. Restaurez le bloc obligatoire et libérez de la place en retirant de l’historique moins pertinent ou un résultat d’outil volumineux. Si la réponse est coupée, examinez séparément le budget de sortie : c’est une autre partie de la même fenêtre totale.
En bref
La séquence efficace est la suivante : identifier le modèle → compter les composants → supprimer les doublons exacts → extraire l’historique non pertinent → compacter fichiers et résultats d’outils → laisser de la place pour la réponse → renvoyer la requête → vérifier la qualité. Elle traite la cause sans transformer le contexte en un ensemble de faits tronqués arbitrairement.
