Perché i modelli linguistici si "perdono" nella conversazione

Un nuovo documento di Microsoft Research e Salesforce rileva che anche i più capaci Grandi modelli linguistici (LLM) crollano quando vengono date istruzioni in più fasi piuttosto che tutto in una volta. Gli autori hanno scoperto che le prestazioni calano in media del 39% in sei attività quando viene richiesto un suggerimento diviso su più turni:

Una conversazione a turno singolo (a sinistra) ottiene i risultati migliori, ma risulta innaturale per l'utente finale. Una conversazione a più turni (a destra) fa sì che anche gli LLM più performanti e con il punteggio più alto perdano slancio efficace nella conversazione. Fonte: https://arxiv.org/pdf/2505.06120

Ancora più sorprendentemente, il problemi di delle risposte precipita, con modelli prestigiosi come CatGPT-4.1 e Gemelli 2.5 Pro oscillando tra risposte quasi perfette e fallimenti palesi, a seconda di come viene formulato lo stesso compito; inoltre, la coerenza dell'output può ridursi di oltre la metà nel processo.

Per esplorare questo comportamento, il documento introduce un metodo chiamato sharding*, che suddivide i prompt completamente specificati in frammenti più piccoli e li rilascia uno alla volta in una conversazione.

In parole povere, ciò equivale a dare un ordine unico, coerente e completo al ristorante, lasciando al cameriere null'altro da fare se non accettare la richiesta; oppure decidere di affrontare la questione in modo collaborativo:

Due versioni estreme di una conversazione al ristorante (non tratte dal nuovo articolo, solo a scopo illustrativo).

Per enfatizzare, l'esempio precedente forse mette il cliente in una luce negativa. Ma l'idea centrale rappresentata nella seconda colonna è quella di uno scambio transazionale che chiarisce un insieme di problemi prima di affrontarli – apparentemente un modo razionale e ragionevole di affrontare un compito.

Questa impostazione si riflette nel nuovo lavoro, alimentato a goccia, scheggiato approccio all'interazione LLM. Gli autori notano che gli LLM spesso generano risposte eccessivamente lunghe e poi continuano a fare affidamento sulle proprie intuizioni anche dopo che tali intuizioni si sono rivelate errate o irrilevantiQuesta tendenza, combinata con altri fattori, può far sì che il sistema perda completamente traccia dello scambio.

In effetti, i ricercatori notano ciò che molti di noi hanno trovato aneddoticamente – che il modo migliore per rimettere in carreggiata la conversazione è iniziare una nuova conversazione con l'LLM.

"Se una conversazione con un LLM non ha prodotto i risultati attesi, iniziare una nuova conversazione che ripete le stesse informazioni potrebbe produrre risultati significativamente migliori rispetto al continuare una conversazione in corso.

"Questo perché gli attuali LLM possono perdersi nella conversazione, e i nostri esperimenti dimostrano che insistere in una conversazione con il modello è inefficace. Inoltre, poiché gli LLM generano testo in modo casuale, una nuova conversazione può portare a risultati migliori."

Gli autori riconoscono che i sistemi agenti come autogeno or LangChain possono potenzialmente migliorare i risultati agendo come livelli interpretativi tra l'utente finale e l'LLM, comunicando con l'LLM solo quando hanno raccolto abbastanza risposte "frammentate" da coagulare in un'unica query coesa (a cui l'utente finale non sarà esposto).

Tuttavia, gli autori sostengono che non dovrebbe essere necessario un livello di astrazione separato, altrimenti dovrebbe essere integrato direttamente nel LLM sorgente:

Si potrebbe sostenere che le capacità multi-turn non siano una caratteristica necessaria degli LLM, in quanto possono essere trasferite al framework dell'agente. In altre parole, abbiamo bisogno del supporto multi-turn nativo negli LLM quando un framework dell'agente può orchestrare le interazioni con gli utenti e sfruttare gli LLM solo come operatori a turno singolo?…

Ma dopo aver testato la proposta in tutti gli esempi possibili, concludono:

"[Affidarsi] a un framework di tipo agente per elaborare le informazioni potrebbe essere limitante e sosteniamo che gli LLM dovrebbero supportare in modo nativo l'interazione multi-turn"

Questo interessante nuovo documento è intitolato Gli LLM si perdono in conversazioni multi-turne proviene da quattro ricercatori di MS Research e Salesforce,

Conversazioni frammentate

Il nuovo metodo scompone innanzitutto le istruzioni convenzionali a singolo turno in frammenti più piccoli, progettati per essere introdotti in momenti chiave durante un'interazione LLM, una struttura che riflette lo stile di coinvolgimento esplorativo e dinamico tipico di sistemi come ChatGPT o Google Gemini.

Ogni istruzione originale è un singolo prompt autonomo che esegue l'intero compito in un'unica soluzione, combinando una domanda di alto livello, il contesto di supporto e qualsiasi condizione rilevante. La versione frammentata la suddivide in più parti più piccole, ciascuna delle quali aggiunge una sola informazione:

Istruzioni accoppiate che mostrano (a) un prompt completo fornito in un singolo turno e (b) la sua versione frammentata utilizzata per simulare un'interazione multi-turno non specificata. Semanticamente, ciascuna versione fornisce lo stesso carico informativo.

Il primo frammento introduce sempre l'obiettivo principale del compito, mentre i restanti forniscono dettagli chiarificatori. Insieme, forniscono lo stesso contenuto del prompt originale, ma si distribuiscono naturalmente su più turni della conversazione.

Ogni conversazione simulata si svolge tra tre componenti: l' assistente, il modello in valutazione; il utente, un agente simulato con accesso alle istruzioni complete in forma frammentata; e sistema, che sorveglia 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, ad esempio richiesta di chiarimento o tentativo di risposta completa.

Se il modello effettua Ogni volta che si tenta una risposta, un componente separato estrae solo il frammento rilevante per la valutazione, ignorando qualsiasi testo circostante. A ogni nuovo turno, l'utente rivela un frammento aggiuntivo, che richiede un'altra risposta. Lo scambio continua finché il modello non indovina la risposta corretta o non ci sono più frammenti da rivelare:

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

I primi test hanno mostrato che i modelli spesso chiedevano informazioni non ancora condivise, quindi gli autori hanno abbandonato l'idea di rivelare i frammenti in un ordine fisso. Invece, è stato utilizzato un simulatore per decidere quale frammento rivelare successivamente, in base all'andamento della conversazione.

Il simulatore utente, implementato utilizzando GPT-4o-mini, ha quindi avuto pieno accesso sia all'intera istruzione sia alla cronologia della conversazione, con il compito di decidere, a ogni turno, quale frammento rivelare successivamente, in base all'andamento dello scambio.

Anche il simulatore utente riformulato ogni frammento per mantenere il flusso della conversazione, senza alterarne il significato. Ciò ha permesso alla simulazione di riflettere il "dare e avere" del dialogo reale, pur mantenendo il controllo sulla struttura del compito.

Prima dell'inizio della conversazione, all'assistente vengono fornite solo le informazioni di base necessarie per completare l'attività, come lo schema di un database o un riferimento API. Non viene specificato che le istruzioni saranno suddivise, né viene guidato verso una modalità specifica di gestione della conversazione. Questo è fatto intenzionalmente: nell'uso reale, ai modelli non viene quasi mai comunicato che un prompt sarà incompleto o aggiornato nel tempo, e omettere questo contesto aiuta la simulazione a riflettere il comportamento del modello in un contesto più realistico.

GPT-4o-mini è stato utilizzato anche per decidere come classificare le risposte del modello e per estrarre eventuali risposte definitive da tali risposte. Questo ha contribuito a mantenere la flessibilità della simulazione, ma ha introdotto errori occasionali: tuttavia, dopo aver controllato manualmente diverse centinaia di conversazioni, gli autori hanno scoperto che meno del cinque percento presentava problemi e meno del due percento mostrava un cambiamento nell'esito a causa di essi, e hanno ritenuto che questo fosse un tasso di errore sufficientemente basso entro i parametri del progetto.

Scenari di simulazione

Gli autori hanno utilizzato cinque tipi di simulazione per testare il comportamento del modello in condizioni diverse, ciascuna delle quali rappresenta una variazione nel modo e nel momento in cui vengono rivelate parti delle istruzioni.

Nel Lunga In questo caso, il modello riceve l'intera istruzione in un singolo giro. Questo rappresenta il formato di riferimento standard e funge da base di riferimento per le prestazioni.

. sharded L'impostazione suddivide l'istruzione in più parti e le fornisce una alla volta, simulando una conversazione più realistica e con dettagli non definiti. Questa è l'impostazione principale utilizzata per testare l'efficacia dei modelli nella gestione degli input multi-turn.

Nel Concat In questo contesto, i frammenti vengono ricuciti insieme in un unico elenco, preservandone la formulazione ma eliminando la struttura a turni. Questo aiuta a isolare gli effetti della frammentazione conversazionale causata dalla riformulazione o dalla perdita di contenuto.

. Ricapitolare l'impostazione funziona come sharded, ma aggiunge una svolta finale in cui tutti i frammenti precedenti vengono rielaborati prima che il modello fornisca una risposta definitiva. Questo verifica se un prompt di riepilogo può aiutare a recuperare il contesto perso.

Infine, Palla di neve va oltre, ripetendo tutti i frammenti precedenti ad ogni turno, mantenendo le istruzioni complete visibili durante lo svolgimento della conversazione e offrendo un test più indulgente delle capacità multi-svolta.

Tipi di simulazione basati su istruzioni suddivise in shard. Un prompt completamente specificato viene suddiviso in parti più piccole, che possono quindi essere utilizzate per simulare conversazioni a turno singolo (Completo, Concat) o a turno multiplo (Sharded, Recap, Snowball), a seconda della velocità con cui le informazioni vengono rivelate.

Attività e metriche

Sono stati scelti sei compiti di generazione per coprire sia i domini di programmazione che quelli del linguaggio naturale: i prompt di generazione del codice sono stati presi da Valutazione umana e LiveCodeBench; Le query da testo a SQL provengono da Spiders; Le chiamate API sono state costruite utilizzando i dati provenienti da Classifica delle chiamate di funzioni di Berkeley; i problemi di matematica elementare sono stati forniti da GSM8K; i compiti di didascalia tabellare erano basati su ToTTo; e i riassunti multi-documento sono stati tratti da Riassunto di un pagliaio set di dati.

Le prestazioni del modello sono state misurate utilizzando tre parametri fondamentali: prestazione media, attitudinee inaffidabilità.

Performance media ha catturato il rendimento complessivo di un modello nei vari tentativi; attitudine rifletteva i migliori risultati che un modello poteva raggiungere, in base ai suoi output con punteggio più alto; e inaffidabilità hanno misurato la variazione di tali risultati: divari più ampi tra i risultati migliori e quelli peggiori indicano un comportamento meno stabile.

Tutti i punteggi sono stati inseriti in una scala da 0 a 100 per garantire coerenza tra le attività e le metriche sono state calcolate per ogni istruzione, per poi calcolarne la media per fornire un quadro generale delle prestazioni del modello.

Negli esperimenti sono stati utilizzati sei task frammentati, che coprono sia la programmazione che la generazione di linguaggio naturale. Ogni task è illustrato con un'istruzione completamente specificata e la sua versione frammentata. Per ciascun task sono state adattate tra 90 e 120 istruzioni da benchmark consolidati.

Contendenti e test

Nelle simulazioni iniziali (con un costo stimato di 5000 dollari), 600 istruzioni suddivise in sei attività sono state suddivise e utilizzate per simulare tre tipi di conversazione: pieno, concate scheggiatoPer 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 permesso di acquisire sia le prestazioni complessive sia misure più approfondite di attitudine e affidabilità.

Sono stati testati quindici modelli, che coprono un'ampia 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 antropici erano Claude 3 Haiku (2024-03-07) e Claude 3.7 Sonetto (2025/02/19), accessibile tramite Amazon Bedrock.

Google ha contribuito Gemelli 2.5 Flash (anteprima-04-17) e Gemelli 2.5 Pro (anteprima-03-25). I meta modelli erano Lama 3.1-8B-Istruzione e Lama 3.3-70B-Istruzione, così come Lama 4 Scout-17B-16E, tramite Together AI.

Le altre voci erano OLMo 2 13B, Phi-4e Comando-A, tutti accessibili localmente tramite Ollama o Cohere API; e Ricerca profonda-R1, accessibile tramite Amazon Bedrock.

Per i due 'pensiero' modelli (o3 e R1), limiti di token sono stati aumentati a 10,000 per accogliere catene di ragionamento più lunghe:

Punteggi medi delle prestazioni per ciascun modello in sei attività: codice, database, azioni, conversione da dati a testo, matematica e riepilogo. I risultati sono mostrati per tre tipi di simulazione: completa, concat e sharded. I modelli sono ordinati in base al punteggio medio dell'impostazione completa. L'ombreggiatura riflette il grado di calo delle prestazioni rispetto all'impostazione completa, con le ultime due colonne che riportano i cali medi per concat e sharded rispetto a quella completa.

Riguardo a questi risultati, gli autori affermano^†:

'Ad alto livello, ogni modello vede le sue prestazioni degradare su ogni attività quando si confrontano le prestazioni COMPLETE e SHARDED, con una degradazione media del -39%. Chiamiamo questo fenomeno Perso nella conversazione: modelli che raggiungono prestazioni stellari (oltre il 90%) in un contesto di laboratorio di conversazione completamente specificata e a turno singolo sugli stessi identici compiti in un contesto più realistico quando la conversazione è poco specificata e articolata in più turni.

Concat i punteggi sono stati in media del 95 percento pieno, indicando che il calo delle prestazioni nell'impostazione frammentata non può essere spiegato dalla perdita di informazioni. Modelli più piccoli come Llama3.1-8B-Instruct, OLMo-2-13B e Claude 3 Haiku hanno mostrato un degrado più pronunciato in concat, suggerendo che i modelli più piccoli sono generalmente meno resistenti 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 in egual misura rispetto ai modelli più piccoli (Llama3.1-8B-Instruct, Phi-4)), con degradazioni medie del 30-40%. Ciò è in parte dovuto alle definizioni metriche. Poiché i modelli più piccoli raggiungono punteggi assoluti inferiori in FULL, hanno meno possibilità di degradazione rispetto ai modelli migliori.

"In breve, non importa quanto siano elevate le prestazioni di un LLM in modalità single-turn, osserviamo grandi cali di prestazioni nell'impostazione multi-turn."

Il test iniziale indica che alcuni modelli hanno retto meglio in compiti specifici: Comando-A sulle azioni, Claude 3.7 Sonnet e GPT-4.1 sul codice; e Gemini 2.5 Pro sulla conversione da dati a testo, a indicare che la capacità multi-turn varia a seconda del dominio. Modelli di ragionamento come o3 e Deepseek-R1 non hanno ottenuto risultati migliori nel complesso, forse perché le loro risposte più lunghe introducevano più presupposti, che tendevano a confondere la conversazione.

L’affidabilità

La relazione tra attitudine e affidabilità, evidente nelle simulazioni a giro singolo, sembrava venir meno in condizioni a giro multiplo. Mentre l'attitudine è diminuita solo modestamente, l'inaffidabilità raddoppiato In media. I modelli che erano stabili nei prompt in formato completo, come GPT-4.1 e Gemini 2.5 Pro, sono diventati altrettanto instabili quanto i 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 mostrato in un box plot (a), seguito dai risultati di affidabilità degli esperimenti con quindici modelli (b) e dai risultati del test di sharding graduale in cui le istruzioni sono state suddivise in uno-otto shard (c).

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

Il documento afferma^†:

"[Sebbene] i modelli migliori tendano ad avere una capacità di volo multi-giro leggermente superiore, tutti i modelli tendono ad avere livelli simili di inaffidabilità. In altre parole, in contesti multi-giro e sottospecificati, tutti i modelli che testiamo mostrano un'inaffidabilità molto elevata, con prestazioni che degradano del 50% in media tra la migliore e la peggiore esecuzione simulata per un'istruzione fissa. '

Per verificare se il degrado delle prestazioni fosse legato al numero di turni, gli autori hanno eseguito un esperimento di sharding graduale, suddividendo ogni istruzione in uno-otto shard (vedere la colonna più a destra nell'immagine sopra).

Con l'aumentare del numero di frammenti, l'inaffidabilità è aumentata costantemente, confermando che anche piccoli aumenti nel conteggio dei turni hanno reso i modelli più instabiliL'attitudine è rimasta per lo più invariata, rafforzando il fatto che il problema risiede in coerenza, non capacità.

Controllo della temperatura

Una serie separata di esperimenti ha verificato se l'inaffidabilità fosse semplicemente una conseguenza della casualità. Per farlo, gli autori hanno variato l'impostazione della temperatura sia dell'assistente che del simulatore utente su tre valori: 1.0, 0.5 e 0.0.

Nei formati monogiro come pieno e concat, riducendo la temperatura dell'assistente ha migliorato significativamente l'affidabilità, riducendo la variazione fino all'80 percento; ma nel scheggiato contesto, lo stesso intervento ha avuto scarso effetto:

Punteggi di inaffidabilità per diverse combinazioni di temperatura dell'assistente e dell'utente nelle impostazioni complete, concat e frammentate, con valori più bassi che indicano una maggiore coerenza di risposta.

Anche quando sia l'assistente che l'utente erano impostati a temperatura zero, l'inaffidabilità rimaneva elevata, con GPT-4o che mostrava una variazione intorno al 30 percento, suggerendo che l'instabilità osservata nelle conversazioni multi-turn non è solo rumore stocastico, ma una debolezza strutturale nel modo in cui i modelli gestiscono input frammentati.

Implicazioni

Gli autori descrivono le implicazioni delle loro scoperte in modo insolitamente lungo nella conclusione dell'articolo, sostenendo che le elevate prestazioni a giro singolo non garantiscono l'affidabilità a giro multiplo e mettendo in guardia dal fare eccessivo affidamento su parametri di riferimento completamente specificati quando si valuta la prontezza nel mondo reale (poiché tali parametri di riferimento mascherano l'instabilità nelle interazioni più naturali e frammentate).

Suggeriscono inoltre che l'inaffidabilità non è solo un artefatto di campionamento, ma un limitazione fondamentale nel modo in cui i modelli attuali elaborano l'input in evoluzione e suggeriscono che ciò solleva preoccupazioni per i framework degli agenti, che dipendono dal ragionamento sostenuto nei vari turni.

Infine, sostengono che la capacità multi-turn dovrebbe essere considerata una capacità fondamentale degli LLM, non qualcosa scaricato su sistemi esterni.

Gli autori notano che i loro risultati probabilmente sottovalutare la vera portata del problema e richiamare l'attenzione sulle condizioni ideali del test: il simulatore utente nella sua configurazione aveva pieno accesso alle istruzioni e poteva rivelare i frammenti in un ordine ottimale, il che forniva all'assistente un contesto irrealisticamente favorevole (nell'uso nel mondo reale, gli utenti forniscono spesso prompt frammentati o ambigui senza sapere cosa il modello ha bisogno di sentire dopo).

Inoltre, l'assistente è stato valutato subito dopo ogni turno, prima che la conversazione si svolgesse completamente, evitando che confusione o contraddizioni successive venissero penalizzate, il che avrebbe altrimenti peggiorato le prestazioni. Queste scelte, sebbene necessarie per il controllo sperimentale, implicano che i divari di affidabilità osservati nella pratica siano probabilmente ancora maggiori di quelli riportati.

Concludono:

"Riteniamo che le simulazioni condotte rappresentino un banco di prova favorevole per le capacità multi-giro dell'LLM. A causa delle condizioni di simulazione eccessivamente semplificate, riteniamo che il degrado osservato negli esperimenti sia molto probabilmente una sottostima dell'inaffidabilità degli LLM e della frequenza con cui gli LLM si perdono nelle conversazioni in contesti reali.'

Conclusione

Chiunque abbia trascorso un periodo significativo di tempo con un LLM riconoscerà probabilmente le questioni formulate qui, per esperienza pratica; e la maggior parte di noi, immagino, ha intuitivamente abbandonato le conversazioni LLM "perse" per quelle nuove, nella speranza che l'LLM possa "ricominciare" e smettere di ossessionarsi su materiale emerso in uno scambio lungo, tortuoso e sempre più esasperante.

È interessante notare che contestualizzare ulteriormente il problema non necessariamente lo risolve; anzi, è interessante osservare che l'articolo solleva più domande di quante risposte fornisca (tranne che per quanto riguarda i modi per aggirare il problema).

* Ciò crea confusione, ma non è correlato a il significato convenzionale di "sharding" nell'IA.

† Enfasi audaci degli autori.

Prima pubblicazione lunedì 12 maggio 2025