Votre document juridique de 50 pages est téléchargé dans Claude, et le modèle renvoie une analyse basée sur la page 3. Le reste existe dans un vide de tokens. Ce n’est pas un problème d’hallucination, c’est un problème de fenêtre de contexte, et cela casse plus de systèmes de production que les mauvais prompts.
La fenêtre de contexte est un espace immobilier. Chaque token que vous utilisez — prompt, documents, historique de conversation, instructions système — occupe un espace qui pourrait servir à votre tâche réelle. Dépasser la limite, et le modèle cesse de répondre ou, pire, commence à ignorer les informations les plus anciennes pour faire place à de nouvelles entrées. Comprendre comment gérer cet espace fait la différence entre un système qui fonctionne et un système qui échoue mystérieusement le jeudi quand votre document s’est allongé.
Comprendre votre budget de contexte
Commencez par savoir exactement ce que vous avez.
Claude 3.5 Sonnet vous offre 200 000 tokens. GPT-4o vous offre 128 000 tokens (ou 4 096 si vous utilisez le modèle de base plus ancien). Mistral Large propose 32 000 tokens. Ces chiffres semblent importants jusqu’à ce que vous commenciez à mesurer le contenu réel.
Une page typique de texte commercial représente environ 250 à 350 tokens. Un document de 50 pages vous coûte 12 500 à 17 500 tokens avant même d’avoir écrit une seule instruction. Une longue conversation avec 20 échanges consomme 4 000 à 8 000 tokens. Il vous reste donc un espace de travail réel mesuré par ce qui reste — votre « budget de traitement ».
Calculez votre coût exact en tokens avant le déploiement. Utilisez le tokenizer du fournisseur du modèle :
# Exemple Python utilisant le tokenizer d'Anthropic
import anthropic
client = anthropic.Anthropic()
with open('document.txt', 'r') as f:
doc_text = f.read()
response = client.messages.count_tokens(
model="claude-3-5-sonnet-20241022",
messages=[{"role": "user", "content": doc_text}]
)
print(f"Tokens du document : {response.input_tokens}")
print(f"Budget restant : {200000 - response.input_tokens}")Ce n’est pas une option. Les estimations vous coûtent des requêtes échouées et des dépenses API gaspillées.
Les trois techniques de compression qui fonctionnent vraiment
Vous avez trois leviers : extraire ce qui compte, résumer stratégiquement, ou diviser le travail en morceaux. La plupart des gens essaient de passer directement à la synthèse et échouent car ils résument les mauvaises parties.
1. Extraction avant synthèse
Ne résumez pas tout. Extrayez d’abord les sections pertinentes pour votre question réelle.
Si vous analysez un contrat pour les conditions de paiement, vous n’avez pas besoin de résumés de l’historique de l’entreprise ou des spécifications du produit. Récupérez les clauses pertinentes, transmettez-les au LLM, et gardez 80 % de votre fenêtre de contexte libre.
Mauvaise approche :
# Résumer l'intégralité du document de 50 pages
Prompt: "Résume ce document juridique en 500 mots."
[Document de 50 pages]
"Quelles sont les conditions de paiement ?"Bonne approche :
# Extraire les sections pertinentes, puis répondre
Prompt: "Extrais toutes les sections mentionnant 'paiement', 'facture', 'date d'échéance',
ou 'termes'. Garde la formulation exacte."
[Document de 50 pages]
# Puis dans un second appel ou le même appel avec le texte extrait :
Prompt: "Basé sur ces sections, quelles sont les conditions de paiement et quand les factures sont-elles dues ?"
[Sections extraites uniquement - ~2000 tokens au lieu de 15000]Utilisez l’extraction par mots-clés, les expressions régulières, ou un passage de recherche léger (Claude Mini sur les documents plus courts) pour identifier les morceaux pertinents avant de les transmettre à votre modèle d’analyse principal.
2. Synthèse hiérarchique
Si l’extraction n’est pas viable — disons, si vous avez besoin de tout le contexte — résumez en couches. Ne résumez pas 50 pages en 500 mots en une seule passe. Résumez des morceaux en résumés, puis résumez ces résumés.
Divisez le document en morceaux de 5 à 10 pages. Résumez chaque morceau à 150–200 tokens. Ensuite, résumez ces résumés. Vous compressez 15 000 tokens à 500–800 tout en préservant la structure et les relations.
Cela préserve mieux les nuances qu’une seule synthèse agressive car le modèle ne rejette jamais de détails arbitrairement — il condense proportionnellement à chaque couche.
3. Traitement par fenêtre glissante pour les conversations
Les longues conversations remplissent le contexte rapidement. Ne conservez pas tout l’historique. Gardez les échanges récents (les 5–10 derniers) plus les résumés des anciens.
# Gestion du contexte de conversation
conversation = [
{"role": "user", "content": "Parlez-moi des prix AWS"},
{"role": "assistant", "content": "Les prix AWS sont..."}
# ... 15 échanges supplémentaires ...
]
# Avant l'appel API, tronquer et résumer
if conversation_token_count > 100000:
# Garder les 5 derniers échanges
recent = conversation[-10:] # 5 paires utilisateur/assistant
# Résumer tout ce qui précède
older_summary = summarize_conversation(conversation[:-10])
# Reconstruire avec un marqueur d'historique explicite
trimmed = [
{"role": "system",
"content": "Plus tôt dans cette conversation : " + older_summary}
] + recent
Température et échantillonnage : problèmes de contexte cachés
Vous pouvez également gérer l’efficacité du contexte par le comportement du modèle, pas seulement par la taille de l’entrée.
Une température plus basse (0,3–0,5) amène le modèle à se concentrer sur ce qu’il sait déjà — utile pour l’extraction de faits à partir du contexte fourni. Une température plus élevée (0,7–1,0) augmente le caractère aléatoire, ce qui consomme des tokens pour des sorties moins prévisibles.
Pour les tâches riches en contexte (« répondez uniquement à partir de ce document »), utilisez une température de 0,3–0,4. L’attention du modèle reste sur votre entrée, pas sur l’exploration de formulations alternatives.
Le paramètre max_tokens est également important. Définissez-le délibérément. Si vous extrayez des conditions de paiement, vous n’avez pas besoin de sorties de 4 096 tokens. Définissez max_tokens=500. Cela réserve le budget pour votre tâche réelle au lieu de laisser le modèle divaguer dans un espace vide.
La vraie configuration : un schéma de production
Voici ce qui fonctionne réellement à grande échelle :
- Couche d’extraction : Utilisez des expressions régulières, une recherche par mots-clés ou un modèle rapide (Claude 3.5 Haiku) pour extraire les sections pertinentes des grands documents. Coût : minimal.
- Vérification du budget de tokens : Comptez les tokens des sections extraites. Si c’est inférieur à 30 000 tokens avec Claude Sonnet, continuez. Sinon, résumez.
- Synthétiser si nécessaire : Synthèses hiérarchiques de morceaux, pas une compression agressive en une seule passe.
- Interroger avec le contexte : Transmettez le matériel extrait ou résumé plus des instructions explicites : « Répondez uniquement sur la base de ces sections. N’utilisez pas de connaissances externes. »
- Troncature de conversation : Après 10 messages utilisateur, enregistrez un instantané de la conversation, résumez-la et démarrez une nouvelle fenêtre.
Le goulot d’étranglement est rarement le modèle. C’est le travail préparatoire avant l’appel API.
Commencez par le comptage de tokens, pas par la synthèse
Aujourd’hui : mesurez vos documents réels. Faites-les passer par le tokenizer du modèle que vous utilisez. Calculez combien de tokens restent après le téléchargement de votre document. Ce nombre restant est votre budget de travail réel.
S’il est inférieur à 30 000 pour Claude Sonnet ou inférieur à 50 000 pour un travail de production, vous devez extraire, pas résumer. S’il est négatif, vous avez besoin d’une approche complètement différente — diviser les documents, utiliser la recherche vectorielle pour récupérer uniquement les sections pertinentes, ou utiliser un modèle avec une fenêtre plus grande.
La plupart des problèmes de contexte ne sont pas résolus par de meilleurs prompts. Ils sont résolus en ne demandant pas au modèle de traiter plus qu’il n’en a besoin.
