Perché i Modelli Linguistici Si Perdono nella Conversazione

Un nuovo studio di ricerca di Microsoft Research e Salesforce ha scoperto che anche i più potenti Modelli Linguistici di Grande Scala (LLM) si disintegrano quando le istruzioni vengono date a stage anziché tutte in una volta. Gli autori hanno scoperto che le prestazioni calano in media del 39% su sei compiti quando un prompt viene diviso su più turni:

Una conversazione a un solo turno (a sinistra) ottiene i migliori risultati, ma è innaturale per l’utente finale. Una conversazione a più turni (a destra) trova anche i modelli LLM più performanti e classificati che perdono l’impulso efficace nella conversazione. Fonte: https://arxiv.org/pdf/2505.06120

Meno sorprendentemente, l’affidabilità delle risposte subisce un crollo, con modelli prestigiosi come ChatGPT-4.1 e Gemini 2.5 Pro che oscillano tra risposte quasi perfette e fallimenti manifesti, a seconda di come lo stesso compito viene formulato; inoltre, la coerenza dell’output può calare di più della metà nel processo.

Per esplorare questo comportamento, lo studio introduce un metodo chiamato sharding, che divide i prompt completamente specificati in frammenti più piccoli e li rilascia uno alla volta nella conversazione.

In termini più basilari, questo è equivalente a dare un ordine coerente e comprensivo in un ristorante, lasciando al cameriere nulla da fare se non confermare la richiesta; o decidere di affrontare la questione in modo collaborativo:

Due versioni estreme di una conversazione in un ristorante (non dal nuovo studio, a scopo illustrativo).

Per enfasi, l’esempio sopra forse mette il cliente in una luce negativa. Ma l’idea fondamentale rappresentata nella seconda colonna è quella di uno scambio transazionale che chiarisce un set di problemi, prima di affrontarli – apparentemente un modo razionale e ragionevole per affrontare un compito.

Questo setup è riflesso nel nuovo lavoro con un approccio a gocce, sharded, all’interazione con LLM. Gli autori notano che gli LLM spesso generano risposte troppo lunghe e continuano a fare affidamento sulle proprie intuizioni anche dopo che quelle intuizioni sono state dimostrate essere errate o irrilevanti. Questa tendenza, combinata con altri fattori, può far perdere al sistema la traccia dello scambio intero.

In effetti, i ricercatori notano ciò che molti di noi hanno trovato in modo aneddotico – che il modo migliore per riportare la conversazione sulla giusta strada è iniziare una nuova conversazione con l’LLM.

‘Se una conversazione con un LLM non ha portato ai risultati attesi, iniziare una nuova conversazione che ripete le stesse informazioni potrebbe produrre risultati significativamente migliori rispetto al proseguimento di una conversazione in corso.

‘Ciò è perché gli attuali LLM possono perdere la traccia della conversazione, e i nostri esperimenti mostrano che persistere in una conversazione con il modello è inefficace. Inoltre, poiché gli LLM generano testo con casualità, una nuova conversazione potrebbe portare a risultati migliori.’

Gli autori riconoscono che i sistemi agente come Autogen o LangChain possono potenzialmente migliorare i risultati agendo come strati interpretativi tra l’utente finale e l’LLM, comunicando con l’LLM solo quando hanno raccolto abbastanza risposte “sharded” per coagulare in una singola query coerente (che l’utente finale non sarà esposto):

‘Un argomento potrebbe essere fatto che le capacità multi-turn non sono una caratteristica necessaria degli LLM, poiché possono essere esternalizzate al framework dell’agente. In altre parole, dobbiamo avere un supporto nativo per l’interazione multi-turn negli LLM quando un framework di agente può orchestrare le interazioni con gli utenti e sfruttare gli LLM solo come operatori a un solo turno?…’

Ma dopo aver testato la proposta attraverso la loro serie di esempi, concludono:

‘[Dipendere] da un framework di agente per elaborare le informazioni potrebbe essere limitante, e noi arguiamo che gli LLM dovrebbero supportare nativamente l’interazione multi-turn’

Questo interessante nuovo studio è intitolato LLM Get Lost In Multi-Turn Conversation, e proviene da quattro ricercatori di MS Research e Salesforce,

Conversazioni Fragmentate

Il nuovo metodo inizia dividendo le istruzioni convenzionali a un solo turno in frammenti più piccoli, progettati per essere introdotti in momenti chiave durante un’interazione con LLM, una struttura che riflette lo stile di coinvolgimento esplorativo e di andata e ritorno visto in sistemi come ChatGPT o Google Gemini.

Ogni istruzione originale è un prompt singolo e autocontenuto che consegna l’intero compito in un solo passaggio, combinando una domanda di alto livello, contesto di supporto e qualsiasi condizione rilevante. La versione sharded la divide in più parti più piccole, con ogni frammento che aggiunge solo un pezzo di informazione:

Istruzioni accoppiate che mostrano (a) un prompt completo consegnato in un solo turno e (b) la sua versione sharded utilizzata per simulare un’interazione multi-turno underspecificata. Semanticamente, ogni versione consegna lo stesso carico informativo.

Il primo frammento introduce sempre l’obiettivo principale del compito, mentre il resto fornisce dettagli di chiarimento. Insieme, consegnano lo stesso contenuto del prompt originale, ma distribuito naturalmente su più turni nella conversazione.

Ogni conversazione simulata si svolge tra tre componenti: l’assistente, il modello sotto valutazione; l’utente, un agente simulato con accesso al prompt completo in forma sharded; e il sistema, che invigila e valuta lo scambio.

La conversazione inizia con l’utente che rivela il primo frammento e l’assistente che risponde liberamente. Il sistema classifica quindi la risposta in una delle diverse categorie, come una richiesta di chiarimento o un tentativo di risposta completa.

Se il modello cerca di rispondere, un componente separato estrae solo la span rilevante per la valutazione, ignorando qualsiasi testo circostante. In ogni nuovo turno, l’utente rivela un altro frammento, sollecitando un’altra risposta. Lo scambio continua fino a quando il modello non ottiene la risposta giusta o non ci sono più frammenti da rivelare:

Diagramma di una simulazione di conversazione sharded, con il modello valutato evidenziato in rosso.

I primi test hanno mostrato che i modelli spesso chiedevano informazioni che non erano state condivise, quindi gli autori hanno abbandonato l’idea di rivelare i frammenti in un ordine fisso. Invece, un simulatore è stato utilizzato per decidere quale frammento rivelare dopo, in base a come procedeva la conversazione.

Il simulatore dell’utente, implementato utilizzando GPT-4o-mini, è stato quindi dato pieno accesso sia all’intero prompt che alla storia della conversazione, incaricato di decidere, ad ogni turno, quale frammento rivelare dopo, in base a come si stava svolgendo lo scambio.

Il simulatore dell’utente ha anche parafrasato ogni frammento per mantenere il flusso conversazionale, senza alterare il significato. Ciò ha permesso alla simulazione di riflettere il ‘dare e avere’ del vero dialogo, mantenendo il controllo sulla struttura del compito.

Prima che la conversazione inizi, all’assistente vengono fornite solo le informazioni di base necessarie per completare il compito, come uno schema di database o un riferimento API. Non gli viene detto che le istruzioni saranno divise, e non gli viene indicato un modo specifico per gestire la conversazione. Questo è fatto di proposito: in uso reale, i modelli sono quasi mai informati che un prompt sarà incompleto o aggiornato nel tempo, e omettere questo contesto aiuta la simulazione a riflettere come il modello si comporta in un contesto più realistico.

GPT-4o-mini è stato utilizzato anche per decidere come classificare le risposte del modello e per estrarre eventuali risposte finali da quelle risposte. Ciò ha aiutato la simulazione a rimanere flessibile, ma ha introdotto occasionali errori: tuttavia, dopo aver verificato diverse centinaia di conversazioni a mano, gli autori hanno scoperto che meno del 5% avevano problemi, e meno del 2% mostravano un cambiamento nel risultato a causa di essi, e hanno considerato questo un tasso di errore sufficientemente basso all’interno dei parametri del progetto.

Scenari di Simulazione

Gli autori hanno utilizzato cinque tipi di simulazione per testare il comportamento del modello in condizioni diverse, ognuno una variazione su come e quando vengono rivelate le parti dell’istruzione.

Nel setting Full, il modello riceve l’intero prompt in un solo turno. Ciò rappresenta il formato di benchmark standard e serve come baseline per le prestazioni.

Il setting Sharded divide l’istruzione in più pezzi e li consegna uno alla volta, simulando una conversazione più realistica e underspecificata. Questo è l’impostazione principale utilizzata per testare come i modelli gestiscono l’input multi-turno.

Nel setting Concat, i frammenti vengono cuciti insieme come un elenco singolo, preservando la loro formulazione ma rimuovendo la struttura turno-per-turno. Ciò aiuta a isolare gli effetti della frammentazione conversazionale dalla riformulazione o dalla perdita di contenuto.

Il setting Recap funziona come Sharded, ma aggiunge un turno finale in cui tutti i frammenti precedenti vengono ripetuti prima che il modello dia una risposta finale. Ciò testa se un prompt di riepilogo possa aiutare a recuperare il contesto perduto.

Infine, Snowball va oltre, ripetendo tutti i frammenti precedenti ad ogni turno, mantenendo l’intero prompt visibile mentre la conversazione si svolge – e offrendo un test più permissivo della capacità multi-turno.

Tipi di simulazione basati su istruzioni sharded. Un prompt completamente specificato viene diviso in parti più piccole, che possono quindi essere utilizzate per simulare sia conversazioni a un solo turno (Full, Concat) che conversazioni multi-turno (Sharded, Recap, Snowball), a seconda di come velocemente le informazioni vengono rivelate.

Compiti e Metriche

Sono stati scelti sei compiti di generazione per coprire sia il dominio della programmazione che quello del linguaggio naturale: i prompt di generazione di codice sono stati presi da HumanEval e LiveCodeBench; le query Text-to-SQL sono state prese da Spider; le chiamate API sono state costruite utilizzando dati da Berkeley Function Calling Leaderboard; i problemi di matematica elementare sono stati forniti da GSM8K; i compiti di didascalia tabellare sono stati basati su ToTTo; e le sintesi di multi-documento sono state tratte dal set di dati Summary of a Haystack.

Le prestazioni del modello sono state misurate utilizzando tre metriche fondamentali: prestazione media, attitudine e inaffidabilità.

Prestazione media ha catturato quanto bene un modello abbia fatto nel complesso su più tentativi; attitudine ha riflesso i migliori risultati che un modello poteva raggiungere, in base ai suoi output con punteggio più alto; e inaffidabilità ha misurato quanto quei risultati variassero, con lacune più grandi tra i migliori e i peggiori risultati che indicavano un comportamento meno stabile.

Tutti i punteggi sono stati posizionati su una scala da 0 a 100 per assicurare la coerenza attraverso i compiti, e le metriche sono state calcolate per ogni istruzione – e poi mediate per fornire un quadro generale delle prestazioni del modello.

Sei compiti sharded utilizzati negli esperimenti, coprendo sia la generazione di codice che la generazione del linguaggio naturale. Ogni compito è mostrato con un prompt completamente specificato e la sua versione sharded. Tra 90 e 120 istruzioni sono state adattate da benchmark stabiliti per ogni compito.

Concorrenti e Test

Nelle simulazioni iniziali (con un costo stimato di $5000), 600 istruzioni che coprivano sei compiti sono state sharded e utilizzate per simulare tre tipi di conversazione: full, concat e sharded. Per ogni combinazione di modello, istruzione e tipo di simulazione, sono state eseguite dieci conversazioni, producendo oltre 200.000 simulazioni in totale – uno schema che ha reso possibile catturare sia le prestazioni generali che misure più profonde di attitudine e affidabilità.

Sono stati testati quindici modelli, che coprivano una vasta gamma di provider e architetture: i modelli OpenAI GPT-4o (versione 2024-11-20), GPT-4o-mini (2024-07-18), GPT-4.1 (2025-04-14), e il modello di pensiero o3 (2025-04-16).

I modelli Anthropic sono stati Claude 3 Haiku (2024-03-07) e Claude 3.7 Sonnet (2025-02-19), accessibili tramite Amazon Bedrock.

Google ha contribuito con Gemini 2.5 Flash (preview-04-17) e Gemini 2.5 Pro (preview-03-25). I modelli Meta sono stati Llama 3.1-8B-Instruct e Llama 3.3-70B-Instruct, così come Llama 4 Scout-17B-16E, tramite Together AI.

Gli altri ingressi sono stati OLMo 2 13B, Phi-4, e Command-A, tutti accessibili localmente tramite Ollama o Cohere API; e Deepseek-R1, accessibile tramite Amazon Bedrock.

Per i due modelli di “pensiero” (o3 e R1), ‘limiti di token’ sono stati aumentati a 10.000 per accommodare catene di ragionamento più lunghe:

Punteggi di prestazione media per ogni modello su sei compiti: codice, database, azioni, dati-testo, matematica e riassunto. I risultati sono mostrati per tre tipi di simulazione: full, concat e sharded. I modelli sono ordinati in base al loro punteggio medio nel setting full. L’ombreggiatura riflette il grado di calo delle prestazioni dal setting full, con le ultime due colonne che riportano cali medi per concat e sharded rispetto al full.

Riguardo a questi risultati, gli autori affermano^†:

‘A un livello alto, ogni modello vede le proprie prestazioni peggiorare in ogni compito quando si confrontano le prestazioni FULL e SHARDED, con un degrado medio del -39%. Chiamiamo questo fenomeno Lost in Conversation: i modelli che raggiungono prestazioni stellari (90%+) in un ambiente di laboratorio con conversazioni a un solo turno, completamente specificate, lottano nei medesimi compiti in un ambiente più realistico quando la conversazione è underspecificata e multi-turno.’

Le prestazioni concat sono state in media il 95% di quelle full, indicando che il calo delle prestazioni nel setting sharded non può essere spiegato dalla perdita di informazioni. I modelli più piccoli come Llama3.1-8B-Instruct, OLMo-2-13B e Claude 3 Haiku hanno mostrato un degrado più pronunciato sotto concat, suggerendo che i modelli più piccoli sono generalmente meno robusti alla riformulazione rispetto a quelli più grandi.

Gli autori osservano^†:

‘Sorprendentemente, i modelli più performanti (Claude 3.7 Sonnet, Gemini 2.5, GPT-4.1) si perdono nella conversazione tanto quanto i modelli più piccoli (Llama3.1-8B-Instruct, Phi-4), con degradi medi del 30-40%. Ciò è in parte dovuto alle definizioni delle metriche. Poiché i modelli più piccoli raggiungono punteggi assoluti più bassi nel FULL, hanno meno possibilità di degrado rispetto ai modelli migliori.

‘In breve, non importa quanto forte sia la prestazione a un solo turno di un LLM, noi osserviamo grandi degradi delle prestazioni nel setting multi-turno.’

Il test iniziale indica che alcuni modelli hanno retto meglio in compiti specifici: Command-A su Azioni, Claude 3.7 Sonnet e GPT-4.1 su codice; e Gemini 2.5 Pro su Dati-Testo, indicando che la capacità multi-turno varia per dominio. I modelli di ragionamento come o3 e Deepseek-R1 non hanno fatto meglio nel complesso, forse perché le loro risposte più lunghe hanno introdotto più ipotesi, che tendevano a confondere la conversazione.

Affidabilità

La relazione tra attitudine e affidabilità, chiara nelle simulazioni a un solo turno, sembra disintegrarsi nelle condizioni multi-turno. Mentre l’attitudine è calata solo modestamente, l’inaffidabilità è raddoppiata in media. I modelli che erano stabili in prompt full-format, come GPT-4.1 e Gemini 2.5 Pro, sono diventati altrettanto erratici come modelli più deboli come Llama3.1-8B-Instruct o OLMo-2-13B una volta che l’istruzione è stata frammentata.

Panoramica dell’attitudine e dell’inaffidabilità come mostrata in un grafico a box (a), seguita dai risultati dell’affidabilità degli esperimenti con quindici modelli (b), e dai risultati del test di sharding graduale dove le istruzioni sono state divise in uno a otto frammenti (c).

Le risposte del modello spesso variavano di fino a 50 punti nello stesso compito, anche quando nulla di nuovo era stato aggiunto, suggerendo che il calo delle prestazioni non era dovuto a una mancanza di abilità, ma al fatto che il modello diventava sempre più instabile attraverso i turni.

Il documento afferma^†:

‘[Sebbene] i modelli migliori tendano ad avere un’attitudine multi-turno leggermente più alta, tutti i modelli tendono ad avere livelli di inaffidabilità simili. In altre parole, in multi-turno, in condizioni underspecifiche, tutti i modelli che testiamo mostrano un’incredibile inaffidabilità, con prestazioni che degradano di 50 punti in media tra il miglior e il peggior run simulato per un’istruzione fissa.’

Per testare se il degrado delle prestazioni era legato al numero di turni, gli autori hanno eseguito un esperimento di sharding graduale, dividendo ogni istruzione in uno a otto frammenti (vedi colonna più a destra nell’immagine sopra).

Man mano che il numero di frammenti aumentava, l’inaffidabilità saliva costantemente, confermando che anche piccoli aumenti nel numero di turni rendevano i modelli più instabili. L’attitudine è rimasta sostanzialmente invariata, rafforzando l’idea che il problema risiede nella coerenza, non nella capacità.

Controllo della Temperatura

Un insieme separato di esperimenti ha testato se l’inaffidabilità fosse semplicemente un sottoprodotto della casualità. Per farlo, gli autori hanno variato l’impostazione di temperatura sia dell’assistente che del simulatore dell’utente su tre valori: 1,0, 0,5 e 0,0.

Nel formato a un solo turno come full e concat, ridurre la temperatura dell’assistente ha migliorato significativamente l’affidabilità, riducendo la variazione fino al 80%; ma nel setting sharded, la stessa intervento ha avuto poco effetto:

Punteggi di inaffidabilità per diverse combinazioni di temperatura dell’assistente e dell’utente attraverso impostazioni full, concat e sharded, con valori più bassi che indicano maggiore coerenza delle risposte.

Anche quando sia l’assistente che l’utente erano impostati su zero temperatura, l’inaffidabilità è rimasta alta, con GPT-4o che mostrava una variazione intorno al 30%, suggerendo che l’instabilità osservata nelle conversazioni multi-turno non è solo rumore stocastico, ma una debolezza strutturale nel modo in cui i modelli gestiscono l’input frammentato.

Implicazioni

Gli autori scrivono a lungo delle implicazioni dei loro risultati alla fine del documento, sostenendo che una forte prestazione a un solo turno non garantisce l’affidabilità multi-turno, e mettono in guardia contro un eccessivo affidamento su benchmark completamente specificati quando si valuta la prontezza per il mondo reale (poiché tali benchmark mascherano l’instabilità in interazioni più naturali e frammentate).

Essi suggeriscono anche che l’inaffidabilità non è solo un artefatto di campionamento, ma una limitazione fondamentale nel modo in cui i modelli attuali elaborano l’input in evoluzione, e suggeriscono che ciò solleva preoccupazioni per i framework di agente, che dipendono da un ragionamento sostenuto attraverso i turni.

Infine, sostengono che la capacità multi-turno dovrebbe essere trattata come una capacità fondamentale degli LLM, e non qualcosa che può essere esternalizzato a sistemi esterni.

Gli autori notano che i loro risultati probabilmente sottostimano la vera portata del problema, e attirano l’attenzione sulle condizioni ideali del test: il simulatore dell’utente nel loro setup aveva accesso completo all’istruzione e poteva rivelare i frammenti in un ordine ottimale, il che ha dato all’assistente un contesto irrealisticamente favorevole (in uso reale, gli utenti spesso forniscono prompt frammentati o ambigui senza sapere cosa il modello debba sentire dopo).

Inoltre, l’assistente è stato valutato immediatamente dopo ogni turno, prima che la conversazione completa si svolgesse, impedendo che confusione o auto-contraddizione successive venissero penalizzate, il che altrimenti avrebbe peggiorato le prestazioni. Queste scelte, sebbene necessarie per il controllo sperimentale, significano che i gap di affidabilità osservati nella pratica sono probabilmente ancora più grandi di quelli segnalati.

Concludono:

‘[Noi] crediamo che le simulazioni condotte rappresentino un terreno di prova benigno per le capacità multi-turno degli LLM. Perché delle condizioni di simulazione eccessivamente semplificate, noi crediamo che il degrado osservato negli esperimenti sia probabilmente una sottostima dell’inaffidabilità degli LLM, e di quanto spesso gli LLM si perdono nella conversazione in ambienti reali.’

Conclusione

Chiunque abbia trascorso un periodo di tempo significativo con un LLM probabilmente riconoscerà i problemi formulati qui, dall’esperienza pratica; e la maggior parte di noi, immagino, ha abbandonato conversazioni “perse” con LLM per iniziare conversazioni nuove, nella speranza che l’LLM possa “ricominciare” e smettere di ossessionarsi con il materiale che è emerso in uno scambio lungo e sempre più infuriante.

È interessante notare che aggiungere più contesto al problema potrebbe non necessariamente risolverlo; e in effetti, osservare che il documento solleva più domande di quante ne fornisca risposte (ad eccezione dei modi per aggirare il problema).

* Confusamente, questo non è correlato al significato convenzionale di ‘sharding’ in AI.

† Enfasi dei propri autori.

Pubblicato per la prima volta lunedì, 12 maggio 2025