Perché più contesto può peggiorare le risposte dell'IA

Una finestra di contesto più ampia offre a un sistema di intelligenza artificiale una maggiore capacità. Tuttavia, non garantisce che il modello utilizzi tale capacità in modo efficace. Nelle conversazioni lunghe, nelle pipeline RAG, negli agenti di ricerca e nei flussi di lavoro ad alta intensità di strumenti, aggiungere ulteriore cronologia, più documenti, più output di strumenti o più memoria può rendere una risposta meno affidabile anziché più informata.

La capacità di contesto non coincide con l'usabilità del contesto

La finestra di contesto dichiarata di un modello descrive la quantità di input che può accettare. Non implica che ogni token all'interno di quella finestra riceva la stessa attenzione o contribuisca in egual misura alla risposta finale. La distinzione è fondamentale poiché i sistemi di produzione riempiono sempre più il contesto con cronologia delle conversazioni, documenti recuperati, risultati degli strumenti, memoria, stato strutturato, istruzioni e artefatti intermedi.

Il classico studio “Lost in the Middle” ha dimostrato che i modelli a contesto lungo possono offrire prestazioni peggiori quando le prove rilevanti compaiono al centro di un input lungo rispetto a quando si trovano vicino all'inizio o alla fine. La lezione ingegneristica più ampia non è che il contesto lungo sia dannoso, ma che la disponibilità all'interno del contesto non equivale a un uso affidabile.

Le linee guida di OpenAI sulla gestione del contesto giungono alla stessa conclusione operativa da un'altra prospettiva: perfino finestre di contesto molto ampie possono essere sopraffatte da cronologie non curate, output ridondanti degli strumenti e recuperi rumorosi. Allo stesso modo, Anthropic tratta il contesto come una risorsa finita che richiede una progettazione attiva anziché un accumulo passivo.

Cinque modi in cui il contesto aggiuntivo può ridurre la qualità della risposta

1. Diluizione del segnale: le prove rilevanti competono con tutto il resto

Supponiamo che una domanda possa essere risolta a partire da due brevi passaggi. Un sistema RAG recupera quei passaggi più altri diciotto vagamente correlati “per sicurezza”. La recall del recupero può migliorare, ma il generatore deve ora distinguere le prove decisive dal materiale di sottofondo. Se frasi simili compaiono in più documenti, il contesto aggiuntivo può rendere la risposta meno precisa.

Ciò crea una distinzione fondamentale tra recall del recupero e utilità del contesto. Una maggiore quantità di materiale recuperato può aumentare la probabilità che la risposta sia presente da qualche parte nel contesto, riducendo al tempo stesso la probabilità che il modello attribuisca il giusto peso alle prove corrette.

2. Conflitto di evidenze: più fonti possono significare più versioni della realtà

I contesti lunghi contengono spesso informazioni reciprocamente incompatibili: documentazione API vecchia e nuova, due versioni di una policy, preferenze utente precedenti e attuali, fonti web concorrenti, stati memorizzati nella cache o un riassunto generato dal modello che non corrisponde più alla fonte originale.

Il fallimento non è necessariamente un'allucinazione. Il modello potrebbe combinare fedelmente evidenze contraddittorie. L'architettura necessita quindi di regole di precedenza: autorità della fonte, versione, timestamp, giurisdizione, tenant, revisione del prodotto, stato dell'utente o metadati espliciti di sostituzione.

Senza tali regole, incrementare il contesto può aumentare le contraddizioni più rapidamente di quanto aumenti la conoscenza.

3. Sensibilità alla posizione: la posizione delle prove può cambiare il risultato

I risultati di “Lost in the Middle” hanno dimostrato che modificare solo la posizione delle informazioni rilevanti può cambiare concretamente le prestazioni del modello. Questa scoperta è particolarmente importante per i sistemi che concatenano molti passaggi recuperati o cronologie estese in un ordine fisso.

Un test di produzione dovrebbe quindi variare l'ordine dei documenti, non limitarsi a testare un unico prompt canonico. Se il sistema risponde correttamente solo quando la prova decisiva si trova all'inizio o alla fine, l'applicazione è più fragile di quanto suggerisca un singolo punteggio di benchmark.

4. Persistenza del contesto obsoleto: il modello vede la verità e la cronologia insieme

Gli agenti a esecuzione prolungata portano spesso avanti le conclusioni precedenti. Tale continuità è utile fino a quando un dato di fatto non cambia. Se il risultato di uno strumento di ieri indica che un deployment è integro e il risultato attuale indica che è degradato, entrambi potrebbero rimanere nel contesto a meno che il sistema non sostituisca o delimiti esplicitamente il vecchio stato.

Ecco perché lo stato operativo attuale dovrebbe normalmente provenire da una fonte autorevole, mentre la memoria preserva il contesto durevole come decisioni, preferenze o procedure. Una cronologia di conversazione più estesa non sostituisce la rilettura del presente.

5. Perdita da compressione: un contesto più piccolo può anche diventare un contesto peggiore

L'intervento opposto — comprimere il contesto — presenta anch'esso modalità di fallimento. I riassunti possono omettere eccezioni, questioni irrisolte, provenienza, identificatori precisi, prove contrarie o le condizioni in base alle quali una conclusione era valida.

Il lavoro di Microsoft Research sull'Agentic Context Engineering descrive un problema correlato definendolo brevity bias e context collapse: la riscrittura iterativa può rimuovere dettagli di dominio utili. L'obiettivo non è quindi “comprimere il più possibile”, ma ridurre il contesto preservando al contempo le informazioni che determinano le decisioni.

Il modello di Qualità del Contesto

Un contesto utile può essere valutato lungo sei dimensioni. Nessuna di queste è semplicemente il conteggio dei token.

Il Context Pressure Test

Per determinare se un'applicazione trae vantaggio da una maggiore quantità di contesto, testa le dimensioni del contesto come variabile sperimentale invece di dare per scontato che più grande sia meglio.

Cosa misurare al posto del conteggio dei token

RAG: perché aumentare il top-k può essere controproducente

Un pattern comune nell'ottimizzazione di RAG consiste nell'aumentare il top-k quando il sistema manca una risposta. Ciò può migliorare il richiamo dei candidati, ma rischia anche di incrementare il contesto irrilevante, le prove duplicate, i passaggi obsoleti e i documenti contrastanti.

La domanda migliore da porsi è se la prova decisiva sia assente nel retrieval o se stia semplicemente perdendo influenza dopo l'assemblaggio del contesto. Se il passaggio corretto appare già nell'insieme dei candidati, aumentare il top-k potrebbe risolvere il problema sbagliato.

Agenti a lunga esecuzione: la continuità non è accumulo

Un agente ha bisogno di continuità tra i passaggi, ma la continuità non richiede la riproduzione di ogni token precedente. OpenAI dimostra tecniche di trimming e compressione per il contesto delle sessioni a lunga esecuzione. Anthropic raccomanda compattazione, annotazione strutturata e altre tecniche per preservare le informazioni utili controllando al contempo l'inquinamento del contesto.

Una solida architettura a lunga esecuzione solitamente separa memoria durevole, stato corrente, artefatti esterni, retrieval e contesto rivolto al modello. Ciò consente al sistema di preservare ciò che conta senza forzare ogni dettaglio storico all'interno di ogni inferenza.

L'ordine del contesto deve essere intenzionale

La costruzione del contesto è un problema di architettura dell'informazione. Istruzioni critiche, stato corrente, prove decisive e vincoli specifici del task non dovrebbero essere collocati in modo arbitrario. Quando i sistemi concatenano le fonti meccanicamente, delegano implicitamente la definizione delle priorità agli effetti posizionali e all'attenzione del modello.

Non esiste un ordine universalmente ottimale per ogni modello e task, quindi l'ordinamento dovrebbe essere valutato empiricamente. Una suite di test efficace randomizza o varia sistematicamente la posizione dei documenti e misura se la medesima affermazione rimane stabile.

Preservare i confini decisionali durante la compattazione

Un riassunto che afferma “usa l'approccio X” è più debole di uno che preserva il motivo per cui X è stato scelto e cosa invaliderebbe la decisione. La compattazione del contesto dovrebbe conservare le variabili in grado di modificare la risposta: versione, data, presupposti, stato, autorevolezza, disaccordi irrisolti e provenienza delle prove.

Questo collega l'ingegneria del contesto direttamente alla validità della risposta. Se la compattazione preserva una conclusione ma ne rimuove il confine di validità, le risposte future possono rimanere internamente coerenti pur risultando errate all'esterno.

Una policy pratica per la costruzione del contesto

• Partire dal task attuale, non da tutto ciò che il sistema conosce.
• Rileggere lo stato volatile dai sistemi autorevoli prima di prendere decisioni rilevanti.
• Recuperare le prove per la domanda corrente invece di trascinare in avanti ampi corpora statici.
• Rimuovere l'output dei tool duplicato o di scarso valore.
• Mantenere versione della fonte, timestamp, autorevolezza e provenienza insieme alle prove importanti.
• Rendere esplicita la precedenza quando le informazioni attuali e quelle storiche entrano in conflitto.
• Preservare le regole insieme alle loro eccezioni e ai relativi prerequisiti.
• Memorizzare decisioni durature e procedure riutilizzabili all'esterno del contesto immediato quando non richiedono una riproduzione letterale.
• Compattare la cronologia solo tramite test che verifichino la conservazione di vincoli, identificatori, eccezioni e provenienza.
• Valutare la dimensione del contesto, l'ordinamento e il rumore con prove ripetute anziché con un singolo prompt.

Cosa cambierebbe questa risposta?

Il trade-off cambia in base all'architettura del modello, all'addestramento, al tipo di task e alla lunghezza del contesto. I modelli futuri potrebbero diventare sostanzialmente più robusti rispetto alla posizione, al rumore e alle informazioni contrastanti. Un task con un corpus ridotto e pulito può anche trarre beneficio dal semplice invio della fonte completa anziché dalla costruzione di una complessa pipeline di retrieval.

La raccomandazione cambia anche quando l'omissione è più rischiosa del rumore. Nei task di ricerca o discovery ad alto richiamo, un contesto candidato più ampio può essere giustificato prima di una successiva fase di filtraggio o sintesi. Nei sistemi di produzione sensibili alla latenza, potrebbe essere preferibile una selezione del contesto più rigorosa.

Il principio fondamentale cambierebbe solo se i modelli diventassero affidabilmente invarianti rispetto a informazioni irrilevanti, posizione, contraddizioni ed evidenze obsolete. Fino ad allora, il contesto deve essere trattato come una risorsa di esecuzione curata anziché come uno spazio di archiviazione passivo.

Limitazioni

Il comportamento su contesti lunghi varia notevolmente a seconda dei modelli e dei carichi di lavoro. Gli esperimenti originali su “Lost in the Middle” utilizzavano generazioni precedenti di modelli, quindi non si deve presumere che l'entità esatta dei loro effetti rappresenti i sistemi attuali. La scoperta rimane utile come pattern di errore da testare, non come curva di prestazioni fissa e universale.

Allo stesso modo, ridurre il contesto può eliminare evidenze necessarie. La compattazione introduce rischi legati alla sintetizzazione e un filtraggio aggressivo del retrieval può ridurre il richiamo. L'obiettivo non è ridurre i token al minimo a tutti i costi; è disporre di un contesto sufficiente, aggiornato e tracciabile per la decisione da prendere.

Conclusione

La domanda “Quanto contesto può accettare il modello?” è meno utile di “Quanto di questo contesto migliora la decisione?”. Un maggior numero di token può aggiungere prove, ma può anche introdurre distrazioni, contraddizioni, stati obsoleti, fragilità posizionale e debito di compressione.

Tratta il contesto come un working set ingegnerizzato. Inizia con le evidenze minime sufficienti. Aggiungi informazioni solo quando migliorano le prestazioni misurate. Testa esplicitamente rumore, conflitti, ordinamento e compattazione. Un'ampia finestra di contesto rappresenta la capacità; la qualità del contesto è architettura.

FAQ

Glossario

Fonti primarie e ulteriori letture