De ce modelele de limbaj se pierd în conversație

O nouă lucrare de cercetare de la Microsoft Research și Salesforce a descoperit că, chiar și cele mai capabile modele de limbaj mari (LLM) se destramă atunci când instrucțiunile sunt date etapizat, și nu toate odată. Autorii au constatat că performanța scade, în medie, cu 39% la șase sarcini, atunci când o instrucțiune este împărțită în mai multe părți:

O conversație cu un singur tur (stânga) obține cele mai bune rezultate, dar este nenaturală pentru utilizatorul final. O conversație cu mai multe tururi (dreapta) găsește chiar și modelele LLM de înaltă performanță pierzând impulsul eficient într-o conversație. Sursa: https://arxiv.org/pdf/2505.06120

Mai mult, fiabilitatea răspunsurilor scade brusc, cu modele prestigioase, cum ar fi ChatGPT-4.1 și Gemini 2.5 Pro, care variază între răspunsuri aproape perfecte și eșecuri evidente, în funcție de modul în care aceeași sarcină este formulată; în plus, consistența ieșirii poate scădea cu mai mult de jumătate în proces.

Pentru a explora acest comportament, lucrarea introduce o metodă numită sharding*, care împarte instrucțiunile complet specificate în fragmente mai mici și le eliberează una câte una într-o conversație.

În termeni foarte simpli, acest lucru este echivalent cu a da o comandă coerentă și cuprinzătoare la un restaurant, lăsând chelnerul să nu aibă nimic de făcut, decât să confirme solicitarea; sau, altfel, să abordeze problema în mod colaborativ:

Două versiuni extreme ale unei conversații de restaurant (nu din lucrarea nouă, doar pentru ilustrare).

Pentru a sublinia, exemplul de mai sus pune, poate, clientul într-o lumină negativă. Dar ideea de bază prezentată în coloana a doua este cea a unui schimb tranzacțional care clarifică un set de probleme, înainte de a aborda problemele – aparent, un mod rațional și rezonabil de abordare a unei sarcini.

Acest setup este reflectat în abordarea nouă, bazată pe sharding, a interacțiunii LLM. Autorii notează că LLM-urile adesea generează răspunsuri prea lungi și apoi continuă să se bazeze pe propriile insight-uri chiar și după ce aceste insight-uri au fost demonstrate a fi incorecte sau irelevante. Această tendință, combinată cu alți factori, poate face ca sistemul să piardă complet urma schimbului.

Într-adevăr, cercetătorii notează ceea ce mulți dintre noi am descoperit din experiență – că cel mai bun mod de a readuce conversația pe linia de plutire este de a începe o nouă conversație cu LLM.

‘Dacă o conversație cu un LLM nu a condus la rezultatele așteptate, începerea unei noi conversații care repetă aceeași informație poate duce la rezultate semnificativ mai bune decât continuarea unei conversații în curs.

‘Acest lucru se datorează faptului că LLM-urile actuale se pot pierde în conversație, iar experimentele noastre arată că persistarea într-o conversație cu modelul este ineficientă. În plus, deoarece LLM-urile generează text cu aleatoriu, o nouă conversație poate duce la rezultate îmbunătățite.’

Autorii recunosc că sistemele agenților, cum ar fi Autogen sau LangChain, pot îmbunătăți rezultatele, acționând ca straturi interpretative între utilizatorul final și LLM, comunicând cu LLM doar atunci când au colectat suficiente răspunsuri “shardate” pentru a se contopi într-o singură întrebare coerentă (pe care utilizatorul final nu o va vedea).

Cu toate acestea, autorii susțin că un strat de abstracție separat nu ar trebui să fie necesar, sau ar trebui să fie construit direct în LLM sursă:

‘Se poate argumenta că capacitățile multi-tur nu sunt o caracteristică necesară a LLM-urilor, deoarece pot fi externalizate către framework-ul agent. În alte cuvinte, avem nevoie de suport nativ pentru interacțiune multi-tur în LLM-uri, atunci când un framework de agent poate orchestra interacțiunile cu utilizatorii și utiliza LLM-urile doar ca operatori cu un singur tur?…’

Dar, după ce au testat această propunere într-o serie de exemple, ei concluzionează:

‘[Dependența] de un framework de agent pentru a procesa informații poate fi limitativă, și susținem că LLM-urile ar trebui să suporte în mod nativ interacțiunea multi-tur’

Această lucrare interesantă nouă se numește LLM-urile se pierd în conversațiile multi-tur, și provine de la patru cercetători de la MS Research și Salesforce,

Conversații fragmentate

Metoda nouă împarte mai întâi instrucțiunile convenționale cu un singur tur în fragmente mai mici, proiectate pentru a fi introduse la momente cheie în timpul unei interacțiuni LLM, o structură care reflectă stilul de implicare exploratoriu și schimbul de informații văzut în sisteme cum ar fi ChatGPT sau Google Gemini.

Fiecare instrucțiune originală este un prompt unic, autoconținut, care livrează întreaga sarcină deodată, combinând o întrebare de nivel înalt, contextul de susținere și orice condiții relevante. Versiunea “shardată” împarte acest lucru în mai multe părți mai mici, cu fiecare fragment adăugând doar o singură bucată de informație:

Instrucțiuni pereche care arată (a) un prompt complet livrat într-un singur tur și (b) versiunea sa shardată, utilizată pentru a simula o interacțiune multi-tur, sub-specificată. Semantic, fiecare versiune livrează aceeași încărcătură informațională.

Primul fragment introduce întotdeauna obiectivul principal al sarcinii, în timp ce restul oferă detalii clarificatoare. Împreună, ele livrează același conținut ca promptul original, dar răspândit în mod natural pe mai multe tururi în conversație.

Fiecare conversație simulată se desfășoară între trei componente: asistentul, modelul supus evaluării; utilizatorul, un agent simulat cu acces la instrucțiunea completă în formă shardată; și sistemul, care supraveghează și punctează schimbul.

Conversația începe cu utilizatorul care dezvăluie primul fragment și asistentul care răspunde liber. Sistemul clasifică apoi răspunsul în una dintre mai multe categorii, cum ar fi o cerere de clarificare sau o încercare de răspuns complet.

Dacă modelul încearcă un răspuns, o componentă separată extrage doar intervalul relevant pentru evaluare, ignorând orice text înconjurător. La fiecare tur nou, utilizatorul dezvăluie un fragment suplimentar, provocând un alt răspuns. Schimbul continuă până când modelul obține răspunsul corect sau nu mai sunt fragmente de dezvăluit:

Diagrama unei simulări de conversație shardată, cu modelul evaluat evidențiat în roșu.

Testele inițiale au arătat că modelele adesea întrebau despre informații care nu fuseseră împărtășite încă, așa că autorii au abandonat ideea de a dezvălui fragmente într-o ordine fixă. În schimb, un simulator a fost utilizat pentru a decide care fragment să fie dezvăluit următor, pe baza modului în care conversația se desfășura.

Simulatorul de utilizator, implementat utilizând GPT-4o-mini, a avut astfel acces complet la instrucțiunea completă și la istoricul conversației, fiind însărcinat să decidă, la fiecare tur, care fragment să fie dezvăluit următor, pe baza modului în care schimbul se desfășura.

Simulatorul de utilizator a reformulat de asemenea fiecare fragment pentru a menține fluxul conversațional, fără a altera sensul. Acest lucru a permis simulării să reflecte “dă și ia” dintr-un dialog real, în timp ce păstra controlul asupra structurii sarcinii.

Înainte de a începe conversația, asistentul primește doar informațiile de bază necesare pentru a completa sarcina, cum ar fi un schema de bază de date sau o referință API. Nu i se spune că instrucțiunile vor fi fragmentate și nu este îndrumat către un mod specific de a gestiona conversația. Acest lucru se face intenționat: în utilizarea reală, modelele rareori sunt informate că un prompt va fi incomplet sau actualizat în timp, și omisiunea acestui context ajută la reflectarea modului în care modelul se comportă într-un context mai realist.

GPT-4o-mini a fost utilizat și pentru a decide cum ar trebui clasificate răspunsurile modelului și pentru a extrage orice răspunsuri finale din acestea. Acest lucru a ajutat simularea să rămână flexibilă, dar a introdus ocazional erori: cu toate acestea, după verificarea mai multor sute de conversații manual, autorii au constatat că mai puțin de cinci procente au avut probleme și mai puțin de două procente au arătat o schimbare a rezultatului din cauza lor, și au considerat acesta un nivel de eroare suficient de mic în cadrul proiectului.

Scenarii de simulare

Autorii au utilizat cinci tipuri de simulare pentru a testa comportamentul modelului în diferite condiții, fiecare variind modul în care și când părțile instrucțiunii sunt dezvăluite.

În setarea Completa, modelul primește întreaga instrucțiune într-un singur tur. Acesta reprezintă formatul standard de benchmark și servește ca punct de referință pentru performanță.

Setarea Shardată împarte instrucțiunea în fragmente mai mici și le livrează una câte una, simulând o conversație mai realistă și sub-specificată. Acesta este principala setare utilizată pentru a testa modul în care modelele gestionează intrările multi-tur.

În setarea Concat, fragmentele sunt reunite într-o listă unică, păstrându-și formularea, dar eliminând structura turului cu turul. Acest lucru ajută la izolarea efectelor fragmentării conversaționale de re-formularea sau pierderea de conținut.

Setarea Rezumat rulează ca Shardată, dar adaugă un tur final în care toate fragmentele anterioare sunt reiterate înainte ca modelul să ofere un răspuns final. Acest lucru testează dacă un prompt de rezumat poate ajuta la recuperarea contextului pierdut.

În final, Zăpadă merge mai departe, repetând toate fragmentele anterioare la fiecare tur, păstrând întreaga instrucțiune vizibilă pe parcursul conversației – și oferind un test mai permisiv al capacității multi-tur.

Tipuri de simulare bazate pe instrucțiuni shardate. O instrucțiune complet specificată este împărțită în părți mai mici, care pot fi utilizate pentru a simula fie conversații cu un singur tur (Completa, Concat), fie conversații multi-tur (Shardată, Rezumat, Zăpadă), în funcție de viteza cu care informația este dezvăluită.

Sarcini și metrice

Șase sarcini de generare au fost selectate pentru a acoperi atât domeniul de programare, cât și cel al limbajului natural: prompturile de generare de cod au fost luate de la HumanEval și LiveCodeBench; interogările Text-to-SQL au fost preluate de la Spider; apelurile API au fost construite utilizând date de la Berkeley Function Calling Leaderboard; problemele matematice elementare au fost furnizate de GSM8K; sarcinile de capturare tabulară au fost bazate pe ToTTo; și rezumatele multi-document au fost preluate de la Summary of a Haystack dataset.

Performanța modelului a fost măsurată utilizând trei metrice de bază: performanță medie, aptitudine și nefiabilitate.

Performanță medie a capturat modul în care un model a funcționat în general pe mai multe încercări; aptitudine a reflectat cele mai bune rezultate pe care un model le putea atinge, pe baza ieșirilor sale cu punctaje ridicate; și nefiabilitate a măsurat cât de mult variază aceste rezultate, cu lacune mai mari între cele mai bune și cele mai slabe rezultate, indicând un comportament mai puțin stabil.

Toate punctajele au fost plasate pe o scară de la 0 la 100 pentru a asigura coerența pe sarcini, și metricele au fost calculate pentru fiecare instrucțiune – și apoi mediate pentru a oferi o imagine generală a performanței modelului.

Șase sarcini shardate utilizate în experimente, care acoperă atât generarea de cod, cât și cea de limbaj natural. Fiecare sarcină este prezentată cu o instrucțiune complet specificată și versiunea sa shardată. Între 90 și 120 de instrucțiuni au fost adaptate de la benchmark-uri stabilite pentru fiecare sarcină.

Concurenți și teste

În simulările inițiale (cu un cost estimat de 5000 de dolari), 600 de instrucțiuni care acoperă șase sarcini au fost shardate și utilizate pentru a simula trei tipuri de conversații: completă, concat și shardată. Pentru fiecare combinație de model, instrucțiune și tip de simulare, zece conversații au fost rulate, producând peste 200.000 de simulări – un schema care a făcut posibilă capturarea atât a performanței generale, cât și a măsurilor mai profunde de aptitudine și fiabilitate.

Cincisprezece modele au fost testate, acoperind o gamă largă de furnizori și arhitecturi: modelele OpenAI GPT-4o (versiunea 2024-11-20), GPT-4o-mini (2024-07-18), GPT-4.1 (2025-04-14), și modelul de gândire o3 (2025-04-16).

Modelele Anthropic au fost Claude 3 Haiku (2024-03-07) și Claude 3.7 Sonnet (2025-02-19), accesate prin Amazon Bedrock.

Google a contribuit cu Gemini 2.5 Flash (preview-04-17) și Gemini 2.5 Pro (preview-03-25). Modelele Meta au fost Llama 3.1-8B-Instruct și Llama 3.3-70B-Instruct, precum și Llama 4 Scout-17B-16E, prin Together AI.

Alte intrări au fost OLMo 2 13B, Phi-4, și Command-A, toate accesate local prin Ollama sau Cohere API; și Deepseek-R1, accesat prin Amazon Bedrock.

Pentru cele două ‘modele de gândire’ (o3 și R1), limitele de token au fost ridicate la 10.000 pentru a acomoda lanțuri de raționament mai lungi:

Punctaje de performanță medie pentru fiecare model la șase sarcini: cod, bază de date, acțiuni, date-text, matematică și rezumat. Rezultatele sunt prezentate pentru trei tipuri de simulare: completă, concat și shardată. Modelele sunt ordonate după punctajul mediu din setarea completă. Umbrirea reflectă gradul de scădere a performanței de la setarea completă, cu ultimele două coloane raportând scăderi medii pentru concat și shardată în raport cu completă.

În ceea ce privește aceste rezultate, autorii afirmă^†:

‘La un nivel înalt, fiecare model prezintă o scădere a performanței la fiecare sarcină, atunci când se compară performanța completă și shardată, cu o scădere medie de -39%. Denumim acest fenomen Pierdut în conversație: modele care ating o performanță excelentă (90%+) într-un mediu de laborator, cu instrucțiuni complet specificate și conversații cu un singur tur, se confruntă cu dificultăți pe aceleași sarcini într-un mediu mai realist, atunci când conversația este sub-specificată și multi-tur.’

Concat punctajele au fost, în medie, 95% din completă, indicând faptul că scăderea performanței în setarea shardată nu poate fi explicată prin pierderea de informații. Modelele mai mici, cum ar fi Llama3.1-8B-Instruct, OLMo-2-13B și Claude 3 Haiku, au prezentat o scădere mai accentuată a performanței sub concat, sugerând că modelele mai mici sunt, în general, mai puțin robuste la re-formularea decât cele mai mari.

Autorii observă^†:

‘Surprinzător, modelele mai performante (Claude 3.7 Sonnet, Gemini 2.5, GPT-4.1) se pierd la fel de mult în conversație, în comparație cu modelele mai mici (Llama3.1-8B-Instruct, Phi-4), cu scăderi medii de 30-40%. Acest lucru se datorează, în parte, definițiilor metrice. Deoarece modelele mai mici ating punctaje absolute mai scăzute în setarea completă, ele au mai puțină marjă de scădere decât modelele mai bune.

‘În scurt, indiferent cât de puternică este o LLM, observăm scăderi mari ale performanței în setarea multi-tur.’

Testul inițial indică faptul că unele modele au rezistat mai bine în sarcini specifice: Command-A pe Acțiuni, Claude 3.7 Sonnet și GPT-4.1 pe cod; și Gemini 2.5 Pro pe Date-text, indicând faptul că abilitatea multi-tur variază în funcție de domeniu. Modelele de raționament, cum ar fi o3 și Deepseek-R1, nu au avut o performanță mai bună în general, probabil din cauza faptului că răspunsurile lor mai lungi au introdus mai multe ipoteze, care au tendința de a confunda conversația.

Fiabilitate

Relația dintre aptitudine și fiabilitate, clară în simulările cu un singur tur, a părut să se destrame în condiții multi-tur. În timp ce aptitudinea a scăzut doar moderat, nefiabilitatea sa dublat în medie. Modele care au fost stabile în prompturi complete, cum ar fi GPT-4.1 și Gemini 2.5 Pro, au devenit la fel de eratice ca și modelele mai slabe, cum ar fi Llama3.1-8B-Instruct sau OLMo-2-13B, odată ce instrucțiunea a fost fragmentată.

Prezentare generală a aptitudinii și nefiabilității, urmată de rezultatele experimentelor cu 15 modele și rezultatele testului de shardare graduală, în care instrucțiunile au fost împărțite în 1-8 fragmente.

Răspunsurile modelului au variat adesea cu până la 50 de puncte pe aceeași sarcină, chiar și atunci când nu s-a adăugat nimic nou, sugerând că scăderea performanței nu a fost cauzată de o lipsă de abilitate, ci de faptul că modelul a devenit din ce în ce mai instabil pe parcursul tururilor.

Lucrarea afirmă^†:

‘[Deși] modelele mai bune au tendința de a avea o aptitudine multi-tur puțin mai mare, toate modelele au niveluri similare de nefiabilitate. În alte cuvinte, în setarea multi-tur, sub-specificată, toate modelele testate prezintă o nefiabilitate foarte ridicată, cu o scădere a performanței de 50 de puncte, în medie, între cea mai bună și cea mai slabă simulare pentru o instrucțiune fixă.’

Pentru a testa dacă scăderea performanței este legată de numărul de tururi, autorii au efectuat un experiment de shardare graduală, împărțind fiecare instrucțiune în 1-8 fragmente (vezi coloana din dreapta a imaginii de mai sus).

Pe măsură ce numărul de fragmente a crescut, nefiabilitatea a crescut constant, confirmând faptul că chiar și creșterile minore ale numărului de tururi fac modelele mai instabile. Aptitudinea a rămas în mare măsură neschimbată, consolidând ideea că problema constă în consistență, și nu în capacitate.

Controlul temperaturii

Un set separat de experimente a testat dacă nefiabilitatea este doar un produs al aleatorismului. Pentru a face acest lucru, autorii au variat setarea de temperatură a asistentului și a simulatorului de utilizator pe trei valori: 1,0, 0,5 și 0,0.

În formatele cu un singur tur, cum ar fi completă și concat, reducerea temperaturii asistentului a îmbunătățit semnificativ fiabilitatea, reducând variația cu până la 80%: însă, în setarea shardată, aceeași intervenție a avut un efect mic:

Punctaje de nefiabilitate pentru diferite combinații de temperatură a asistentului și a simulatorului de utilizator, în setările completă, concat și shardată, cu valori mai mici indicând o consistență mai mare a răspunsurilor.

Chiar și atunci când atât asistentul, cât și utilizatorul au fost setați la o temperatură de zero, nefiabilitatea a rămas ridicată, cu GPT-4o arătând o variație de aproximativ 30%, sugerând că instabilitatea observată în conversațiile multi-tur nu este doar zgomot stohastic, ci o slăbiciune structurală în modul în care modelele gestionează intrările fragmentate.

Implicații

Autorii scriu despre implicațiile descoperirilor lor la o lungime neobișnuită, la sfârșitul lucrării, argumentând că o performanță puternică într-un singur tur nu garantează fiabilitatea în conversații multi-tur, și avertizând împotriva încrederii excesive în benchmark-urile complet specificate atunci când se evaluează pregătirea pentru lumea reală (deoarece astfel de benchmark-uri maschează instabilitatea în interacțiunile mai naturale și fragmentate).

Ei sugerează, de asemenea, că nefiabilitatea nu este doar un artefact de eșantionare, ci o limitare fundamentală în modul în care modelele actuale procesează intrările în evoluție, și sugerează că acest lucru ridică îngrijorări pentru cadrele de agenți, care depind de raționamentul susținut pe tururi.

În cele din urmă, ei argumentează că abilitatea multi-tur ar trebui să fie considerată o capacitate de bază a LLM-urilor, și nu ceva care să fie externalizat către sisteme externe.

Autorii notează că rezultatele lor probabil subestimează adevărata amploare a problemei, și atrag atenția asupra condițiilor ideale ale testului: simulatorul de utilizator din setup-ul lor a avut acces complet la instrucțiune și a putut dezvălui fragmente într-o ordine optimă, ceea ce a oferit asistentului un context neobișnuit de favorabil (în utilizarea reală, utilizatorii adesea furnizează prompturi fragmentate sau ambigue, fără a ști ce are nevoie modelul să audă următor).

În plus, asistentul a fost evaluat imediat după fiecare tur, înainte ca conversația să se desfășoare în întregime, prevenind confuzia sau auto-contradicția ulterioară de a fi penalizată, ceea ce ar fi înrăutățit și mai mult performanța. Aceste alegeri, deși necesare pentru controlul experimental, înseamnă că lacunele de fiabilitate observate în practică sunt probabil să fie și mai mari decât cele raportate.

Ei conchid:

‘[Noi] credem că simulările efectuate reprezintă un mediu de testare benign pentru capacitățile multi-tur ale LLM-urilor. Deoarece condițiile de simulare sunt excesiv de simplificate, credem că degradarea observată în experimente este probabil o subestimare a nefiabilității LLM-urilor și a frecvenței cu care LLM-urile se pierd în conversații în setări reale.’

Concluzii

Oricine a petrecut o perioadă semnificativă de timp cu un LLM probabil va recunoaște problemele formulate aici, din experiență practică; și majoritatea dintre noi, cred, am abandonat conversații “pierdute” cu LLM-uri pentru altele noi, în speranța că LLM-ul poate “începe de la capăt” și să înceteze să se obsedeze cu materialul care a apărut într-un schimb lung, sinuos și din ce în ce mai enervant.

Este interesant de remarcat că aruncarea mai multor context la problema nu poate rezolva neapărat problema; și, de asemenea, observați că lucrarea ridică mai multe întrebări decât oferă răspunsuri (cu excepția modalităților de a ocoli problema).

* Confuz, aceasta nu are legătură cu înțelesul convențional al ‘shardării’ în AI.

† Accentuările autorilor.

Publicat pentru prima dată luni, 12 mai 2025