Prompting per il Contesto Lungo
- Dove mettere i documenti lunghi in un prompt (in alto, non in basso) e perché conta fino a ~30%
- Come strutturare più documenti con i tag <document> / <source>
- Il trucco dell'estrazione delle citazioni che rende le risposte su documenti lunghi drasticamente più ancorate alla fonte
- Quando il contesto 1M è lo strumento sbagliato — e quando invece serve il retrieval o il chunking
- Come la consapevolezza del contesto e la compaction cambiano le regole del gioco su Sonnet 5
Il contesto lungo cambia le regole del gioco — e può anche rovinare silenziosamente le tue risposte. Da quando Sonnet 5, Opus 5 e Opus 4.6/4.7 hanno finestre da 1M token come default (nessun header beta), la tentazione è incollare tutto e sperare. Non farlo. Tutta la differenza fra un ottimo prompt long-context e uno scadente è la struttura — dove va ciascuna parte e come la etichetti.
Le quattro tecniche che spostano davvero l'ago
- Posiziona documenti lunghi e materiale di riferimento sopra le istruzioni e la query, non sotto. I test di Anthropic mostrano che le query alla fine possono migliorare la qualità della risposta fino al 30% — specialmente con input complessi e multi-documento. È la singola modifica con la leva più alta.
- Per input multi-doc, avvolgi ciascuno in <document index='N'> che contiene <source>nomefile</source> e <document_content>…</document_content>. I metadati permettono a Claude di citare quale doc ha usato e gli impediscono di contaminare le affermazioni fra documenti.
- Istruisci Claude a estrarre i passaggi rilevanti da ogni documento in tag <quotes> prima di rispondere. Questo forza l'attenzione sulle parti che contano davvero e taglia il rumore. Le risposte diventano tracciabili alle righe della fonte.
- Dopo un lungo blocco di contesto, riformula in una riga la richiesta (vedi anche: prompting/basics — anti-pattern 'Seppellire la richiesta'). La prima e l'ultima posizione hanno il peso maggiore.
La forma canonica
Il template ufficiale di Anthropic — copialo e sei già davanti alla maggior parte di chi usa le finestre da 1M:
Template multi-documento per contesto lungo
<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.Nota le tre mosse che questo prompt fa contemporaneamente:
- Documenti prima, domanda dopo — la richiesta vera vive sotto il materiale.
- Fonti nominate — ogni doc ha un nomefile che Claude può citare.
- Citazioni → risposta — Claude deve ancorarsi prima di raccomandare qualsiasi cosa.
Context rot: perché più token ≠ risposte migliori
Più contesto non è automaticamente meglio. Con la crescita del numero di token, accuratezza e recall degradano — Anthropic chiama questo fenomeno context rot. I modelli tendono a usare l'inizio e la fine di un input lungo in modo più affidabile della parte centrale (il classico effetto "lost in the middle").
Conseguenze pratiche:
- Sfoltisci prima di incollare. Un dump da 100k token con il 20% di sezioni irrilevanti spesso perde contro la versione curata da 60k token.
- Ordina per rilevanza. Metti per primo dentro
<documents>il documento che ha più probabilità di contenere la risposta. - Il prompt caching si ripaga in fretta. Un design con prefisso stabile (system prompt + documenti identici fra i turni) significa che il prefisso in cache viene letto a circa il 10% del prezzo dei token. Vedi Prompt Caching.
- Finestra 1M ≠ 1M token di attenzione utile. L'accuratezza degrada man mano che riempi la scrivania.
- Seppellisci la richiesta in mezzo a un mega-paste e sarà sotto-pesata.
- Sopra i 200k token di input su Sonnet 5 / Opus 5 sei sul pricing long-context — controlla la pagina del modello prima di incollare un intero repo.
Quando il contesto 1M è lo strumento SBAGLIATO
Il contesto lungo è allettante perché "basta incollare il codebase" sembra più semplice che costruire il retrieval. A volte lo è. Spesso non lo è. Scegli l'alternativa quando:
| Segnale | Meglio del paste da 1M |
|---|---|
| Ti serve lo stesso doc su migliaia di query | Retrieval + RAG — più economico, più veloce |
| Gli utenti portano i propri documenti a ogni turno | Files API con upload di documenti |
| La risposta richiede tutto il codebase ma la richiedi spesso | Prompt caching su uno snapshot del codebase a prefisso stabile |
| Ti servono citazioni verificabili con granularità di riga | Retrieval con chunk ID → cita il chunk, non "da qualche parte nel paste" |
| La latenza conta più della qualità one-shot | Chunk + rerank, poi passa solo i top-k |
Regola pratica: se esiteresti a ri-incollare la roba a ogni turno, probabilmente vuoi il retrieval.
Cosa cambia con Sonnet 5 (context awareness)
Sonnet 5, Sonnet 4.6, Sonnet 4.5 e Haiku 4.5 ora hanno la context awareness — l'API inietta un budget in tempo reale nel system prompt così il modello può regolarsi da solo:
<budget:token_budget>1000000</budget:token_budget>
Dopo ogni chiamata tool, l'API lo aggiorna:
<system_warning>Token usage: 350000/1000000; 650000 remaining</system_warning>
Questi tag non li mandi tu — li mette l'API. Effetto pratico: sui run agentici lunghi, Sonnet 5 riassumerà o passerà la palla proattivamente prima di sbattere contro il muro, invece di tirare a indovinare. Opus 4.7+, Fable 5 e Mythos 5 non ricevono i tag iniettati; dagli budget espliciti tramite i task budget (beta).
Errori comuni
- Incollare un doc dopo l'istruzione — l'errore singolo più comune. Spostalo sopra la richiesta.
- Nessun metadato
<source>— Claude cita "il documento" invece direport.pdf; i tool a valle non possono verificare. - Un unico megablocco
<document>— collassi più fonti in una e Claude non riesce a distinguerle; usane uno per file. - Chiedere direttamente la risposta su input lunghi — richiedi sempre prima le citazioni per qualsiasi cosa sopra i ~20k token di input.
- Assumere che il caching sia automatico — non lo è. Vedi Prompt Caching per i cache breakpoint e i TTL.
- Dimenticarsi della compaction — per run di agenti molto lunghi su Claude 4.6+, la compaction lato server riassume automaticamente i turni più vecchi.
Prova ora
Prendi un doc da 20k+ token che di solito incolleresti raw. Avvolgilo nel template qui sopra, metti la richiesta in fondo e aggiungi "Estrai prima le citazioni rilevanti" come prima istruzione. Confronta la risposta con il tuo vecchio prompt — la differenza di solito non è sottile.
Verifica te stesso
0/5- Dati lunghi in alto; richiesta in fondo — fino al ~30% meglio su input complessi.
- Avvolgi ogni doc in <document> con metadati <source>; chiedi le <quotes> prima della risposta.
- Contesto 1M ≠ gratis — il context rot è reale, e il pricing long-context scatta sopra i 200k token di input.
- Usa RAG quando lo stesso corpus serve molte query; usa compaction e prompt caching per rendere il long context economico.
Prossimi passi
- Token, Contesto e Memoria — il modello mentale dietro la scrivania
- Prompt Caching — come far funzionare l'economia del long-context
- Memory & Context Editing — compaction lato server e clearing su Claude 4.6+
- Retrieval-Augmented Generation — quando invece scegliere il RAG
- Tag XML per la struttura — l'abitudine al tagging che fa funzionare tutto questo