Finestra di contesto e context rot: perché le chat lunghe peggiorano

Il context rot può rendere un agente meno accurato anche quando il suo input rientra nella finestra di contesto dichiarata. Lo studio di Chroma su 18 modelli linguistici ha rilevato che l’affidabilità variava con la lunghezza dell’input. La risposta pratica consiste nel conservare le informazioni che servono a fondare l’azione successiva, riducendo la cronologia irrilevante.

Che cos’è il context rot nell’IA?

Il context rot è il calo di affidabilità che si verifica quando aumentano le informazioni fornite a un modello linguistico. Può manifestarsi con fatti ignorati, associazioni sbagliate o risposte che smettono di rispettare una decisione già presa. Il modello può continuare ad accettare una conversazione lunga e, al tempo stesso, fare più fatica a usarne correttamente il contenuto.

La finestra di contesto è lo spazio di lavoro di cui il modello dispone per una richiesta. Può contenere istruzioni, cronologia della conversazione, documenti e risultati degli strumenti. Un token è un’unità di contenuto elaborata dal modello, spesso un frammento di parola. La nostra guida alla finestra di contesto spiega che cosa occupa questo spazio.

Immaginiamo una sala operativa in cui sulla parete convivono il piano attuale, ipotesi abbandonate, ricostruzioni degli eventi ormai superate e vecchi log. Allargare la parete permette di conservare più materiale. Non dice però a chi arriva dopo quale decisione debba ancora guidare il lavoro.

La distinzione conta quando si cerca la causa di un errore dell’agente. Se l’informazione necessaria è stata rimossa prima che il modello ricevesse la richiesta, occorre indagare sul troncamento dell’input o sul recupero delle informazioni. Se invece era presente, ma la risposta l’ha ignorata o usata male, bisogna esaminare come il modello ha gestito il contesto ricevuto. Nessuno dei due sintomi, da solo, dimostra che il problema dipenda dalla lunghezza.

Documentazione verificata il 24 ottobre 2026: le indicazioni del produttore riportate di seguito sono state controllate sulla documentazione online di Anthropic. Gli esempi di workflow sono proposte progettuali, non risultati osservati in produzione.

Lo studio sul context rot: che cosa mostrano i dati

Il rapporto di Chroma, pubblicato il 14 luglio 2025, ha rilevato che corrispondenze semantiche più difficili da riconoscere e distrattori apparentemente pertinenti rendevano meno affidabile il recupero delle informazioni negli input più lunghi. I suoi test controllati offrono riscontri utili, ma non sono un benchmark del proprio agente. Studio originale.

Nella versione ripulita del benchmark conversazionale LongMemEval, Chroma ha confrontato 306 prompt lunghi in media circa 113,000 token con versioni mirate di circa 300 token in media. Gli input mirati hanno ottenuto punteggi migliori su tutti i modelli valutati. C’è però un punto essenziale: quegli input brevi provenivano da passaggi etichettati come pertinenti e da aggiustamenti manuali, non da un sistema di recupero delle informazioni valutato automaticamente. Metodi e risultati dello studio.

Quali sono i limiti dei risultati di Chroma?

Il rapporto non identifica il meccanismo alla base del fenomeno, né una soglia universale di token al di sotto della quale si possa stare tranquilli. Inoltre, nel suo esperimento sul testo ripetuto, l’output cresce insieme all’input, a differenza dei test di recupero delle informazioni con risposte brevi. Limiti della ricerca e descrizione dei test.

Per chi sviluppa, la domanda utile è se il proprio sistema sappia trovare e conservare le informazioni necessarie a fondare la risposta. Un grafico che confronta informazioni selezionate con cura e cronologia completa non dice se l’indice di ricerca, i filtri o il sistema di sintesi sapranno scegliere correttamente quelle informazioni. La selezione richiede una valutazione specifica.

Perché una finestra di contesto più ampia non basta

Il materiale pertinente deve essere distinguibile da tutto ciò che lo circonda. Un vecchio piano di rilascio può somigliare al piano attuale più di quanto gli somigli un documento estraneo. Il rischio non è soltanto non trovare una frase: è applicare alla situazione presente quella sbagliata.

Le indicazioni di Anthropic sul context engineering citano i vincoli architetturali e l’addestramento su sequenze prevalentemente più brevi tra i fattori che rendono difficile gestire contesti lunghi. Descrivono una perdita graduale di precisione, non un’unica soglia oltre la quale la capacità scompare. Sono spiegazioni su cui ragionare, non la prova di una ricostruzione causale completa.

Prendiamo un agente di assistenza la cui cronologia contiene una diagnosi iniziale, una soluzione provvisoria fallita e una correzione successivamente confermata. Se una chiamata a uno strumento restituisce poi una versione più vecchia della guida alla risoluzione dei problemi, la risposta successiva deve tenere conto sia dell’ordine degli eventi sia dell’autorevolezza delle fonti. Il testo aggiuntivo ha complicato la decisione, anche se la domanda dell’utente è rimasta identica.

Occorre rendere esplicito questo lavoro di riconciliazione: identificare lo stato attuale, segnare la diagnosi precedente come scartata e conservare la fonte che giustifica la correzione accettata. L’obiettivo è avere informazioni sufficienti e distinguere chiaramente quelle ancora valide da quelle superate, non costruire il prompt più corto possibile.

Da dove iniziare i controlli, per chi sviluppa e chi gestisce

Prima di attribuire l’errore al modello, confrontare la stessa decisione con contesti diversi. Per chi sviluppa, significa acquisire la richiesta effettivamente assemblata dall’applicazione. La chat visibile può non mostrare istruzioni di sistema, risultati del recupero delle informazioni o risposte degli strumenti che sono arrivati al modello.

Chi gestisce il sistema deve individuare un requisito concreto ignorato o un’azione sbagliata. «La chat sembra peggiorata» è difficile da indagare; «ha consigliato la soluzione provvisoria già scartata nel registro dell’incidente» offre un caso da riprodurre.

Su un esempio salvato, seguire questa sequenza diagnostica:

1. 1

   Fissare la decisione da valutare

   Mantenere invariati la domanda, la configurazione del modello e il risultato richiesto. Salvare l’input originale e le fonti autorevoli su cui fondare la risposta. Ripetere il caso senza eseguire azioni esterne, così che il confronto non possa modificarne le condizioni.

2. 2

   Verificare che le informazioni siano arrivate

   Cercare il passaggio necessario nella richiesta effettiva. Se manca, correggere prima il recupero delle informazioni, il troncamento o il caricamento dello stato. Se è arrivata invece una fonte obsoleta, correggere la selezione delle fonti e la verifica del loro aggiornamento.

3. 3

   Preparare un confronto con un input mirato

   Conservare le stesse istruzioni del compito e tutte le informazioni necessarie a rispondere, eliminando la cronologia estranea e i risultati obsoleti degli strumenti. Non inserire la risposta attesa e non semplificare il compito. Confrontare correttezza, uso delle fonti e rispetto dei vincoli su ripetizioni rappresentative del caso.

4. 4

   Scegliere la correzione in base all’errore

   Se l’input mirato aiuta, indagare sulla selezione e sull’organizzazione del contesto. Se entrambe le versioni falliscono, esaminare il compito, le istruzioni, la qualità delle informazioni e le capacità del modello. Se gli errori iniziano dopo una sintesi, verificare che cosa è andato perso nel riassunto.

Questo confronto è uno strumento diagnostico, non la prova che la sola lunghezza abbia causato l’errore: togliere materiale ne cambia anche la composizione. Per verificare più rigorosamente l’effetto della lunghezza, mantenere sotto controllo le informazioni pertinenti e la loro posizione mentre si aggiunge materiale estraneo. Non generalizzare sulla base di una singola ripetizione riuscita per caso.

È il momento di intervenire quando l’aumento della cronologia si accompagna ripetutamente a errori evitabili. Un workflow breve e circoscritto, che supera i controlli di correttezza, può mantenere un’architettura più semplice. Aggiungere orchestrazione quando c’è un errore concreto che le dia una funzione.

Come ridurre il context rot in un agente

Scegliere l’intervento in base al materiale che causa il problema. La compattazione gestisce la cronologia accumulata; il recupero delle informazioni seleziona gli elementi su cui fondare la risposta; i sottoagenti circoscrivono l’esplorazione; l’ordine chiarisce il compito; risposte concise degli strumenti riducono l’input superfluo. Sono controlli complementari, ciascuno con rischi di errore diversi.

Compattare la cronologia senza perdere lo stato del lavoro

La compattazione sostituisce le parti più vecchie della conversazione con un resoconto più breve da cui proseguire. La documentazione online di Anthropic sulla compattazione spiega perché è utile mantenere ridotto il contesto attivo: «la qualità delle risposte peggiora man mano che la conversazione si allunga». La sua API supporta sia la compattazione richiesta dall’applicazione sia quella attivata al raggiungimento di una soglia di token configurata.

Progettare il passaggio di consegne attorno a ciò che serve per l’azione successiva. Nell’esempio dell’incidente, conservare l’obiettivo attuale, la causa confermata, la soluzione provvisoria scartata e il motivo dello scarto, le incertezze residue, i riferimenti alle fonti e l’azione successiva. Preservare identificatori o testi esatti quando da questi dipende la correttezza.

Un passaggio di consegne debole dice: «Il problema è stato analizzato e sono stati fatti progressi». Uno utile dice: «La soluzione provvisoria è stata scartata perché compromette il comportamento richiesto; la correzione accettata è registrata nel documento dell’incidente; la verifica è ancora da eseguire». Il secondo permette di proseguire senza ripercorrere l’intera indagine.

Il limite: un riassunto può eliminare un dettaglio che diventerà importante in seguito. Mantenere accessibile la documentazione originale e verificare che l’agente, una volta ripreso il lavoro, sappia ancora rispondere alle domande che richiedono quel dettaglio. Salvare uno stato persistente e scegliere che cosa ricaricare sono attività distinte, trattate nella guida alla memoria degli agenti.

Recuperare le informazioni quando il compito le richiede

Conservare i riferimenti alle fonti estese e caricarne le parti pertinenti quando servono. Anthropic descrive questo approccio come contesto just-in-time: l’agente può mantenere percorsi di file, query o link e recuperare il materiale al momento del bisogno. Indicazioni sul recupero del contesto.

Per un agente che gestisce incidenti, partire dal registro dell’incidente in corso e dalla documentazione pertinente del servizio. Recuperare un incidente precedente quando la diagnosi lo richiede. Restituire ogni passaggio con la fonte, la versione o la data se disponibili, e abbastanza testo circostante da permettere di interpretare un’eccezione.

Il limite: il recupero può omettere la clausola decisiva o restituire una corrispondenza plausibile ma superata. Verificare la presenza delle informazioni necessarie prima di misurare la qualità della risposta. Dare all’agente la possibilità di ampliare la ricerca o leggere la fonte completa quando un estratto non basta a chiarire il punto.

Un insieme più piccolo di risultati è utile soltanto se conserva ciò che serve alla decisione. «Recuperare invece di riversare tutto nel prompt» è un criterio di selezione, non un invito a nascondere il contesto scomodo.

Affidare ai sottoagenti compiti circoscritti e contesti puliti

Usare un contesto separato per le esplorazioni di cui l’agente principale non ha bisogno di ricevere tutti i risultati grezzi. La documentazione di Anthropic sui sottoagenti di Claude Code descrive agenti che lavorano nelle proprie finestre di contesto e restituiscono i risultati alla conversazione principale.

Un sottoagente incaricato di analizzare un log può ricevere la domanda specifica, i dettagli pertinenti del servizio e un riferimento al log. Chiedergli di restituire il risultato, il punto della fonte che lo supporta, le incertezze e le eventuali dipendenze irrisolte. L’agente principale può usare quel risultato senza portarsi dietro l’intero percorso di ricerca.

Il limite: isolare il lavoro significa anche rinunciare a parte delle conoscenze condivise. Includere i vincoli necessari al sottoagente e richiedere che la conclusione sia accompagnata da riscontri. Verificare che cosa gli passi davvero il framework di orchestrazione: copiare l’intera cronologia dell’agente principale vanificherebbe la separazione. Incollare nella conversazione principale la trascrizione completa di ogni sottoagente vi ricrea lo stesso accumulo.

Usare questo schema per indagini separabili. Una decisione le cui parti sono strettamente interdipendenti e richiedono una documentazione condivisa può essere più semplice da gestire nel contesto principale, recuperando in modo mirato le informazioni.

Disporre con criterio i documenti e la richiesta attuale

Rendere il compito attuale facilmente distinguibile dal materiale che lo supporta. Le indicazioni di Anthropic sui prompt con contesto lungo consigliano di collocare i documenti lunghi verso l’inizio del prompt, distinguerne le fonti e inserire la domanda dopo di essi. Raccomandano inoltre di individuare le citazioni pertinenti prima di rispondere a domande sui documenti.

Nell’applicazione, mantenere le istruzioni vincolanti nel canale di istruzioni previsto. All’interno dell’input del compito, contrassegnare il registro dell’incidente attuale separatamente dalle note storiche, quindi formulare chiaramente la domanda e l’output richiesto. Spostare il testo recuperato non deve trasformarlo in istruzioni vincolanti.

Il limite: cambiare l’ordine non può ripristinare informazioni mai caricate, e nessuna disposizione offre garanzie per ogni modello e compito. Confrontare diverse disposizioni sui propri esempi. Evitare di ripetere un intero regolamento a ogni turno quando basta una formulazione concisa e aggiornata del compito.

Restituire output selettivi, mantenendo accessibile il contenuto completo

Restituire il risultato necessario alla decisione successiva, insieme a un modo per risalire al contenuto completo. Le indicazioni di Anthropic sulla progettazione degli strumenti raccomandano risposte significative e controlli quali filtri, paginazione e troncamento. Separatamente, la documentazione sulla modifica del contesto descrive la rimozione dei risultati più vecchi degli strumenti dalla cronologia della conversazione.

Per una verifica fallita, restituire il problema, l’estratto pertinente dell’errore e il percorso del rapporto salvato. Per una ricerca, restituire i passaggi pertinenti e le relative fonti. Per un’operazione riuscita, restituire lo stato e gli identificatori necessari a proseguire. Evitare di incorporare il rapporto completo soltanto perché lo strumento lo ha prodotto.

Il limite: un troncamento indiscriminato può eliminare l’errore decisivo o una precisazione essenziale. Segnalare le omissioni e consentire all’agente di richiedere altro materiale. Conservare l’output completo fuori dal contesto attivo quando servirà per un’ispezione.

Queste scelte vanno implementate nel livello che assembla la richiesta. La guida al context engineering spiega più in generale come si combinano istruzioni, memoria, strumenti e materiale recuperato.

Che cosa viene esagerato nel dibattito sul context rot?

Non esiste un numero universale di messaggi, né una percentuale della finestra, che indichi a ogni agente quando ripartire da zero. Una soglia che impedisce richieste troppo grandi è un’impostazione di capacità. Il punto in cui uno specifico workflow diventa inaffidabile va misurato sui compiti che svolge davvero.

Nemmeno ogni risposta sbagliata in una chat lunga dimostra la presenza di context rot. Informazioni mancanti, istruzioni contraddittorie, uno strumento guasto o un compito non supportato possono produrre sintomi simili. Un rapporto utile sull’incidente identifica la decisione sbagliata e registra ciò che il modello ha ricevuto.

La compattazione comporta perdite, e la memoria esterna non garantisce automaticamente la pertinenza. Trattarle entrambe come componenti i cui output richiedono controlli. Conservare più efficientemente una conclusione sbagliata può portare un workflow a sbagliare con regolarità.

Infine, la cache interviene su un altro piano. Una KV cache riutilizza il calcolo dell’attenzione; non decide quale documento conti e non elimina la cronologia superata. Una richiesta gestita bene dalla cache può comunque contenere materiale inadatto alla decisione successiva.

Una breve lista di interventi per questa settimana

Applicare questi passaggi a un agente con un errore ricorrente:

• Acquisire l’input effettivo nel momento della decisione sbagliata e identificare le informazioni di cui aveva bisogno.
• Ripetere il compito con informazioni mirate e requisiti invariati; confrontare la correttezza su casi rappresentativi.
• Sostituire la risposta dello strumento più carica di rumore con un estratto pertinente e un riferimento al contenuto completo.
• Definire un passaggio di consegne per la compattazione che conservi decisioni, approcci scartati, vincoli, fonti e lavoro incompiuto.
• Isolare un’indagine separabile nel contesto pulito di un sottoagente, se l’accumulo di materiale deriva dall’esplorazione.
• Rilasciare la modifica soltanto se, alla ripresa, il workflow conserva i fatti necessari e migliora il problema preso di mira; mantenere ripristinabile il comportamento precedente.

Partire dall’errore che si riesce a riprodurre. In questo modo la modifica ha un criterio di accettazione chiaro, anziché misurare il successo con «meno contesto».

Domande frequenti sul context rot

Il context rot è ancora un problema?

La documentazione attuale di Anthropic sulla compattazione descrive ancora esplicitamente il calo di qualità delle risposte man mano che le conversazioni si allungano. Questo giustifica continuare a gestire il contesto, ma non stabilisce come si comporti ogni modello attuale. Valutare il modello e il workflow effettivamente utilizzati.

Come si evita il context rot?

Conservare le istruzioni attuali e le informazioni necessarie, rimuovere il materiale obsoleto o ridondante, compattare con cura la cronologia e recuperare i dettagli quando servono. Dove utile, isolare le attività secondarie che producono molto rumore. Verificare che ogni modifica preservi i fatti richiesti per l’azione successiva.

Da che cosa dipende il context rot?

La lunghezza del contesto, la pertinenza del materiale circostante e il modo in cui le informazioni sono presentate possono influire sull’affidabilità. Lo studio originale non identifica un unico meccanismo alla base del fenomeno. Nel caso di un agente, esaminare le informazioni fornite e lo stato del lavoro prima di scegliere una correzione.

Iscriviti alla newsletter per ricevere guide pratiche su come sviluppare e gestire workflow di IA.