Prompting für Long Context
- Wohin mit langen Dokumenten in einem Prompt (nach oben, nicht nach unten) und warum das bis zu ~30 % ausmacht
- Wie du mehrere Dokumente mit <document>- / <source>-Tags strukturierst
- Der Zitat-Extraktions-Trick, der Antworten auf langen Dokumenten dramatisch fundierter macht
- Wann 1M Kontext das falsche Werkzeug ist — und Retrieval oder Chunking richtig ist
- Wie Kontextbewusstsein und Compaction das Spiel auf Sonnet 5 verändern
Long Context verändert das Spiel — und kann deine Antworten auch still ruinieren. Da Sonnet 5, Opus 5 und Opus 4.6/4.7 standardmäßig 1M-Token-Fenster ausliefern (ohne Beta-Header), ist die Versuchung groß, alles reinzuwerfen und zu hoffen. Tu es nicht. Der ganze Unterschied zwischen einem großartigen Long-Context-Prompt und einem lahmen ist Struktur — wo jedes Stück hinkommt und wie du es beschriftest.
Die vier Techniken, die wirklich etwas bewirken
- Platziere lange Dokumente und Referenzmaterial über deinen Instruktionen und deiner Anfrage, nicht darunter. Anthropics eigene Tests zeigen, dass Anfragen am Ende die Antwortqualität um bis zu 30 % verbessern können — besonders bei komplexen Multi-Dokument-Inputs. Das ist die einzelne Änderung mit dem höchsten Hebel.
- Bei Multi-Doc-Inputs wickle jedes in <document index='N'> mit <source>filename</source> und <document_content>…</document_content>. Metadaten erlauben Claude zu zitieren, welches Dokument er benutzt hat, und verhindern das gegenseitige Vermischen von Aussagen.
- Weise Claude an, die relevanten Passagen aus jedem Dokument in <quotes>-Tags zu ziehen, bevor er antwortet. Das erzwingt Aufmerksamkeit auf die wirklich wichtigen Teile und senkt das Rauschen. Antworten werden bis auf Quellzeilen rückverfolgbar.
- Nach einem langen Kontextblock: einzeilige Wiederholung der Bitte (siehe auch: prompting/basics — Anti-Pattern 'Die Bitte vergraben'). Die erste und letzte Position tragen das meiste Gewicht.
Die kanonische Form
Anthropics eigenes Template — kopiere das und du bist den meisten Nutzern von 1M-Fenstern schon voraus:
Long-Context-Template für mehrere Dokumente
<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.Beachte die drei Bewegungen, die dieser Prompt gleichzeitig macht:
- Dokumente zuerst, Frage zuletzt — die eigentliche Bitte steht unter dem Material.
- Benannte Quellen — jedes Dokument hat einen Dateinamen, den Claude zitieren kann.
- Zitate → Antwort — Claude muss sich verankern, bevor er irgendetwas empfiehlt.
Context Rot: warum mehr Tokens ≠ bessere Antworten
Mehr Kontext ist nicht automatisch besser. Mit wachsender Token-Zahl degradieren Accuracy und Recall — Anthropic nennt das Context Rot. Modelle nutzen den Anfang und das Ende eines langen Inputs zuverlässiger als die Mitte (der klassische "Lost in the middle"-Effekt).
Praktische Konsequenzen:
- Kürzen, bevor du einfügst. Ein 100k-Token-Dump mit 20 % irrelevanten Abschnitten verliert oft gegen die kuratierte 60k-Version.
- Nach Salienz sortieren. Setze das Dokument, das am wahrscheinlichsten die Antwort enthält, als erstes in
<documents>. - Prompt Caching zahlt sich schnell aus. Stable-Prefix-Design (System-Prompt + Dokumente über Turns identisch) heißt: Das gecachte Präfix wird zu ~10 % des Token-Preises gelesen. Siehe Prompt Caching.
- 1M-Fenster ≠ 1M Tokens nützlicher Aufmerksamkeit. Accuracy degradiert, wenn du den Tisch füllst.
- Die Bitte in der Mitte eines riesigen Pastes zu vergraben lässt sie untergewichtet werden.
- Über 200k Input-Tokens auf Sonnet 5 / Opus 5 bist du in Long-Context-Preisen — prüfe die Modellseite, bevor du ein Repo reinwirfst.
Wann 1M-Kontext das FALSCHE Werkzeug ist
Long Context ist verlockend, weil "einfach die Codebasis reinwerfen" einfacher wirkt als Retrieval zu bauen. Manchmal ist es das. Oft nicht. Wähle die Alternative, wenn:
| Signal | Besser als 1M-Paste |
|---|---|
| Du brauchst dasselbe Dokument über Tausende von Abfragen | Retrieval + RAG — günstiger, schneller |
| Nutzer bringen jedes Turn eigene Dokumente mit | Files API mit Dokument-Uploads |
| Die Antwort braucht die ganze Codebasis, aber du fragst oft nach | Prompt Caching auf einem Stable-Prefix-Codebasis-Snapshot |
| Du brauchst auditierbare Zitate auf Zeilengenauigkeit | Retrieval mit Chunk-IDs → Chunk zitieren, nicht "irgendwo im Paste" |
| Latenz zählt mehr als One-Shot-Qualität | Chunk + Rerank, dann nur die Top-k übergeben |
Faustregel: Wenn du zögern würdest, das jedes Turn erneut zu pasten, willst du wahrscheinlich Retrieval.
Was sich mit Sonnet 5 ändert (Kontextbewusstsein)
Sonnet 5, Sonnet 4.6, Sonnet 4.5 und Haiku 4.5 haben jetzt Kontextbewusstsein — die API injiziert ein laufendes Budget in den System-Prompt, damit das Modell sich selbst pacen kann:
<budget:token_budget>1000000</budget:token_budget>
Nach jedem Tool-Call aktualisiert die API es:
<system_warning>Token usage: 350000/1000000; 650000 remaining</system_warning>
Du schickst diese Tags nicht — die API tut es. Praktischer Effekt: Bei langen Agent-Läufen wird Sonnet 5 proaktiv zusammenfassen oder übergeben, bevor er an die Wand fährt, statt zu raten. Opus 4.7+, Fable 5 und Mythos 5 bekommen keine injizierten Tags; gib ihnen stattdessen explizite Budgets über Task Budgets (Beta).
Häufige Fehler
- Ein Dokument nach der Instruktion einfügen — der häufigste Fehltritt. Verschiebe es über die Bitte.
- Keine
<source>-Metadaten — Claude zitiert "das Dokument" stattreport.pdf; nachgelagerte Tools können nicht verifizieren. - Ein riesiger
<document>-Blob — mehrere Quellen zu einer zusammenlegen, und Claude kann sie nicht auseinanderhalten; nimm eine pro Datei. - Die Antwort direkt auf langen Inputs anfordern — verlange bei allem über ~20k Input-Tokens immer zuerst Zitate.
- Annehmen, dass Caching automatisch ist — ist es nicht. Siehe Prompt Caching für Cache-Breakpoints und TTLs.
- Compaction vergessen — bei sehr langen Agent-Läufen auf Claude 4.6+ fasst serverseitige Compaction ältere Turns automatisch zusammen.
Probier es jetzt aus
Nimm ein 20k+-Token-Dokument, das du sonst roh reinwerfen würdest. Wickle es in das Template oben, setze deine Bitte nach unten, und füge "Extrahiere zuerst relevante Zitate" als erste Instruktion hinzu. Vergleiche die Antwort mit deinem alten Prompt — der Unterschied ist meist nicht subtil.
Prüfe dich selbst
0/5- Lange Daten nach oben; die Bitte nach unten — bis zu ~30 % besser bei komplexen Inputs.
- Wickle jedes Dokument in <document> mit <source>-Metadaten; bitte um <quotes> vor der Antwort.
- 1M Kontext ≠ gratis — Context Rot ist real, und Long-Context-Preise greifen über 200k Input-Tokens.
- Nimm RAG, wenn derselbe Korpus viele Abfragen bedient; nimm Compaction und Prompt Caching, um Long Context wirtschaftlich zu machen.
Weiter
- Tokens, Kontext & Speicher — das mentale Modell hinter dem Tisch
- Prompt Caching — wie Long-Context-Ökonomie funktioniert
- Memory & Context Editing — serverseitige Compaction und Clearing auf Claude 4.6+
- Retrieval-Augmented Generation — wann man stattdessen zu RAG greift
- XML-Tags für Struktur — die Tagging-Gewohnheit, die das alles möglich macht