Aller au contenu principal

Prompter pour le long contexte

Intermédiaire
What you'll learn
  • Où mettre les documents longs dans un prompt (en haut, pas en bas) et pourquoi cela compte jusqu'à ~30 %
  • Comment structurer plusieurs documents avec les tags <document> / <source>
  • L'astuce d'extraction de quotes qui rend les réponses long-doc dramatiquement plus ancrées
  • Quand le contexte 1M est le mauvais outil — et quand retrieval ou chunking est le bon
  • Comment la conscience du contexte et la compaction changent la donne sur Sonnet 5

Le long contexte change la donne — et peut aussi ruiner silencieusement vos réponses. Puisque Sonnet 5, Opus 5 et Opus 4.6/4.7 livrent des fenêtres 1M tokens par défaut (pas de header beta), la tentation est de tout coller et d'espérer. N'y cédez pas. Toute la différence entre un excellent prompt long-contexte et un prompt bâclé est la structure — où chaque partie va et comment vous l'étiquetez.

Les quatre techniques qui bougent vraiment l'aiguille​

Guided walkthrough1 of 4
  1. Placez les documents longs et le matériel de référence au-dessus de vos instructions et de votre requête, pas en dessous. Les propres tests d'Anthropic montrent que les requêtes à la fin peuvent améliorer la qualité de réponse jusqu'à 30 % — surtout avec des inputs complexes multi-documents. C'est le changement à plus haut levier.

La forme canonique​

Le propre template d'Anthropic — copiez-le et vous êtes déjà en avance sur la plupart des gens qui utilisent des fenêtres 1M :

Template long-context multi-document

<documents>
<document index="1">
  <source>annual_report_2025.pdf</source>
  <document_content>
    {{ANNUAL_REPORT}}
  </document_content>
</document>
<document index="2">
  <source>competitor_analysis_q2.xlsx</source>
  <document_content>
    {{COMPETITOR_ANALYSIS}}
  </document_content>
</document>
</documents>

Find quotes from the two documents that are relevant to identifying strategic advantages we can press on in Q3. Place them in <quotes> tags with the source filename. Then, based only on those quotes, recommend three focus areas with a one-line justification each. Place your recommendations in <recommendations> tags.

Remarquez les trois manœuvres que ce prompt fait à la fois :

  1. Docs d'abord, question en dernier — l'ask réel vit sous le matériel.
  2. Sources nommées — chaque doc a un filename que Claude peut citer.
  3. Quotes → réponse — Claude doit s'ancrer avant de recommander quoi que ce soit.

Context rot : pourquoi plus de tokens ≠ meilleures réponses​

Plus de contexte n'est pas automatiquement mieux. À mesure que le compte de tokens grandit, l'accuracy et le recall se dégradent — Anthropic appelle cela le context rot. Les modèles tendent à utiliser le début et la fin d'un input long plus fiablement que le milieu (l'effet classique « perdu au milieu »).

Conséquences pratiques :

  • Trimmez avant de coller. Un dump de 100k tokens avec 20 % de sections non pertinentes perd souvent contre la version curée de 60k tokens.
  • Ordonnez par saillance. Mettez le doc le plus susceptible de contenir la réponse en premier dans <documents>.
  • Le prompt caching se rentabilise vite. Un design à préfixe stable (system prompt + docs identiques à travers les tours) signifie que le préfixe caché est lu à ~10 % du prix de token. Voir Prompt Caching.
Watch out
  • Fenêtre 1M ≠ 1M tokens d'attention utile. L'accuracy se dégrade à mesure que vous remplissez le bureau.
  • Enterrez la demande au milieu d'un énorme coller et elle sera sous-pondérée.
  • Au-dessus de 200k tokens d'input sur Sonnet 5 / Opus 5, vous êtes sur le tarif long-contexte — vérifiez la page du modèle avant de coller un repo.

Quand le contexte 1M est le MAUVAIS outil​

Le long contexte est tentant parce que « juste coller le codebase » se sent plus simple que construire du retrieval. Parfois ça l'est. Souvent non. Choisissez l'alternative quand :

SignalMieux qu'un coller 1M
Vous avez besoin du même doc à travers des milliers de requêtesRetrieval + RAG — moins cher, plus rapide
Les utilisateurs apportent leurs propres documents à chaque tourFiles API avec uploads de documents
La réponse exige tout le codebase mais vous re-demandez souventPrompt caching sur un snapshot de codebase à préfixe stable
Vous avez besoin de citations auditables à la granularité de ligneRetrieval avec chunk IDs → citer le chunk, pas « quelque part dans le coller »
La latence compte plus que la qualité one-shotChunk + rerank, puis ne passer que le top-k

Règle de pouce : si vous hésiteriez à recoller ceci à chaque tour, vous voulez probablement du retrieval à la place.

Ce qui change avec Sonnet 5 (conscience du contexte)​

Sonnet 5, Sonnet 4.6, Sonnet 4.5 et Haiku 4.5 ont maintenant la conscience du contexte — l'API injecte un budget courant dans le system prompt pour que le modèle puisse se rythmer :

<budget:token_budget>1000000</budget:token_budget>

Après chaque appel d'outil, l'API le met à jour :

<system_warning>Token usage: 350000/1000000; 650000 remaining</system_warning>

Vous n'envoyez pas ces tags — l'API le fait. Effet pratique : sur les runs agentiques longs, Sonnet 5 va résumer ou passer la main proactivement avant de frapper le mur, au lieu de deviner. Opus 4.7+, Fable 5 et Mythos 5 n'ont pas de tags injectés ; donnez-leur des budgets explicites via les task budgets (beta) à la place.

Erreurs courantes​

  • Coller un doc après l'instruction — la miss la plus commune. Déplacez-le au-dessus de l'ask.
  • Pas de metadata <source> — Claude cite « le document » au lieu de report.pdf ; les outils en aval ne peuvent pas vérifier.
  • Un blob <document> géant — regroupez plusieurs sources en un et Claude ne peut pas les distinguer ; utilisez-en un par fichier.
  • Demander la réponse directement sur des inputs longs — demandez toujours les quotes d'abord pour tout au-dessus de ~20k tokens d'input.
  • Supposer que le caching est automatique — il ne l'est pas. Voir Prompt Caching pour les cache breakpoints et TTLs.
  • Oublier que la compaction existe — pour les runs d'agents très longs sur Claude 4.6+, la compaction server-side résume automatiquement les tours plus anciens.

Essayez maintenant​

Prenez un doc de 20k+ tokens que vous colleriez normalement brut. Enveloppez-le dans le template ci-dessus, mettez votre ask en bas, et ajoutez « Extract relevant quotes first » comme première instruction. Comparez la réponse à votre ancien prompt — la différence n'est habituellement pas subtile.

Vérifiez-vous

0/5
  1. Où doivent aller les documents longs dans un prompt long-contexte ?
  2. Quelle est la technique d'extraction de quotes ?
  3. Vous avez un codebase de 900k tokens et attendez 500 requêtes similaires par jour. Qu'est-ce qui bat un coller 1M brut ?
  4. Qu'est-ce que le 'context rot' ?
  5. Sur Sonnet 5, qui injecte le tag <budget:token_budget> ?
Key takeaways
  • Données longues en haut ; l'ask en bas — jusqu'à ~30 % de mieux sur les inputs complexes.
  • Enveloppez chaque doc dans <document> avec metadata <source> ; demandez les <quotes> avant la réponse.
  • Contexte 1M ≠ gratuit — le context rot est réel, et le tarif long-contexte s'enclenche au-dessus de 200k tokens d'input.
  • Utilisez RAG quand le même corpus sert de nombreuses requêtes ; utilisez la compaction et le prompt caching pour rendre le long contexte économique.

Suite​