De ce modelele lingvistice se „pierd” în conversație

Un nou studiu realizat de Microsoft Research și Salesforce constată că până și cei mai capabili Modele de limbaj mari (LLM-urile) se destramă atunci când se dau instrucțiuni în etape mai degrabă decât toate deodată. Autorii au descoperit că performanța scade în medie cu 39% la șase sarcini atunci când este aplicată o solicitare împărțit pe mai multe ture:

O conversație cu o singură tură (stânga) obține cele mai bune rezultate, dar este nefirească pentru utilizatorul final. O conversație cu mai multe ture (dreapta) constată că până și cei mai bine clasați și mai performanți LLM-uri pierd impulsul eficient într-o conversație. Sursa: https://arxiv.org/pdf/2505.06120

Mai frapant, încredere numărul răspunsurilor scade brusc, cu modele prestigioase precum ChatGPT-4.1 și Gemini 2.5 Pro oscilând între răspunsuri aproape perfecte și eșecuri evidente, în funcție de modul în care este formulată aceeași sarcină; în plus, consecvența rezultatului poate scădea cu mai mult de jumătate în acest proces.

Pentru a explora acest comportament, lucrarea introduce o metodă numită sharding*, care împarte solicitările complet specificate în fragmente mai mici și le lansează pe rând într-o conversație.

În termeni simpli, aceasta este echivalentă cu a da o singură comandă coerentă și cuprinzătoare la un restaurant, lăsându-l pe chelner fără nimic de făcut decât să accepte cererea; sau altfel, să decidă să abordeze problema în colaborare:

Două versiuni extreme ale unei conversații la restaurant (nu sunt din noul ziar, doar cu titlu ilustrativ).

Pentru a sublinia acest lucru, exemplul de mai sus îl pune probabil pe client într-o lumină negativă. Însă ideea centrală descrisă în a doua coloană este cea a unui schimb tranzacțional care clarifică un set de probleme, înainte de a le aborda – aparent o modalitate rațională și rezonabilă de a aborda o sarcină.

Această configurație se reflectă în alimentația prin picurare a noii lucrări, ascuțit abordarea interacțiunii cu LLM. Autorii observă că LLM-urile generează adesea răspunsuri prea lungi și apoi continuă să se bazeze pe propriile perspective chiar și după ce s-a dovedit că acele observații sunt incorecte sau irelevanteAceastă tendință, combinată cu alți factori, poate face ca sistemul să piardă complet evidența schimbului.

De fapt, cercetătorii observă ceea ce mulți dintre noi am descoperit anecdotic – că cea mai bună modalitate de a readuce conversația pe făgașul cel bun este de a începe o nouă conversație cu LLM-ul.

„Dacă o conversație cu un master în drept nu a dus la rezultatele așteptate, începerea unei noi conversații care repetă aceleași informații ar putea genera rezultate semnificativ mai bune decât continuarea unei conversații în desfășurare.”

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

Autorii recunosc că sistemele agențice, cum ar fi Autogen or LangChain pot îmbunătăți potențialul rezultatelor acționând ca straturi interpretative între utilizatorul final și LLM, comunicând cu LLM doar atunci când au adunat suficiente răspunsuri „fragmentate” pentru a se coagula într-o singură interogare coerentă (la care utilizatorul final nu va fi expus).

Cu toate acestea, autorii susțin că un strat de abstractizare separat nu ar trebui să fie necesar sau, altfel, ar trebui să fie încorporat direct în LLM-ul sursă:

„S-ar putea argumenta că capabilitățile multi-turn nu sunt o caracteristică necesară a LLM-urilor, deoarece pot fi transferate către framework-ul de agenți. Cu alte cuvinte, avem nevoie de suport nativ multi-turn în LLM-uri atunci când un framework de agenți poate orchestra interacțiunile cu utilizatorii și poate utiliza LLM-urile doar ca operatori cu o singură tură?...”

Dar, după ce au testat propoziția în gama lor de exemple, ei concluzionează:

„[Bazarea] pe un cadru de tip agent pentru procesarea informațiilor ar putea fi limitativă, iar noi susținem că LLM-urile ar trebui să suporte nativ interacțiunea multi-turn”

Interesant hârtie nouă se intitulează LLM-urile se pierd în conversații pe mai multe rânduriși provine de la patru cercetători din MS Research și Salesforce,

Conversații fragmentate

Noua metodă descompune mai întâi instrucțiunile convenționale cu o singură tură în fragmente mai mici, concepute pentru a fi introduse în momente cheie în timpul unei interacțiuni LLM, o structură care reflectă stilul exploratoriu, de interacțiune reciprocă, observat în sisteme precum ChatGPT sau Google Gemini.

Fiecare instrucțiune originală este o singură instrucțiune de sine stătătoare care livrează întreaga sarcină dintr-o dată, combinând o întrebare de nivel înalt, contextul justificativ și orice condiții relevante. Versiunea fragmentată împarte aceasta în mai multe părți mai mici, fiecare fragment adăugând o singură informație:

Instrucțiuni pereche care prezintă (a) o solicitare completă livrată într-o singură tură și (b) versiunea sa fragmentată utilizată pentru a simula o interacțiune subspecificată, cu mai multe ture. Semantic, fiecare versiune furnizează aceeași sarcină informațională.

Primul fragment introduce întotdeauna scopul principal al sarcinii, în timp ce restul oferă detalii clarificatoare. Împreună, acestea oferă același conținut ca și solicitarea inițială, dar se distribuie în mod natural pe parcursul mai multor etape ale conversației.

Fiecare conversație simulată se desfășoară între trei componente: asistent, modelul evaluat; utilizator, un agent simulat cu acces la instrucțiunea completă în formă fragmentată; și sistem, care supraveghează și punctează schimbul.

Conversația începe cu utilizatorul care dezvăluie primul fragment, iar asistentul răspunde liber. Sistemul clasifică apoi răspunsul respectiv într-una din mai multe categorii, cum ar fi... cerere de clarificare sau un încercare de răspuns complet.

Dacă modelul face În cazul în care încercați să oferiți un răspuns, o componentă separată extrage doar intervalul relevant pentru evaluare, ignorând orice text din jur. La fiecare nouă rundă, utilizatorul dezvăluie un fragment suplimentar, determinând un alt răspuns. Schimbul continuă până când modelul dă răspunsul corect sau nu mai există fragmente de dezvăluit:

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

Primele teste au arătat că modelele întrebau adesea despre informații care nu fuseseră încă partajate, așa că autorii au renunțat la ideea de a dezvălui fragmentele într-o ordine fixă. În schimb, s-a folosit un simulator pentru a decide ce fragment să fie dezvăluit în continuare, în funcție de evoluția conversației.

Simulatorul de utilizator, implementat folosind GPT-4o-mini, a primit, așadar, acces deplin atât la întreaga instrucțiune, cât și la istoricul conversațiilor, fiind însărcinat să decidă, la fiecare pas, ce fragment să dezvăluie în continuare, în funcție de modul în care se desfășura schimbul.

Simulatorul de utilizator, de asemenea, reformulat fiecare fragment pentru a menține fluxul conversațional, fără a altera sensul. Acest lucru a permis simulării să reflecte schimbul de idei din dialogul real, păstrând în același timp controlul asupra structurii sarcinii.

Înainte de începerea conversației, asistentului i se oferă doar informațiile de bază necesare pentru a finaliza sarcina, cum ar fi o schemă a bazei de date sau o referință API. Nu i se spune că instrucțiunile vor fi împărțite și nu este îndrumat către o modalitate specifică de gestionare a conversației. Acest lucru se face intenționat: în utilizarea în lumea reală, modelelor aproape niciodată nu li se spune că o solicitare va fi incompletă sau actualizată în timp, iar omiterea acestui context ajută simularea să reflecte modul în care modelul se comportă într-un context mai realist.

GPT-4o-mini a fost folosit și pentru a decide cum ar trebui clasificate răspunsurile modelului și pentru a extrage răspunsurile finale din aceste răspunsuri. Acest lucru a contribuit la flexibilitatea simulării, dar a introdus ocazional greșeli: cu toate acestea, după verificarea manuală a câtorva sute de conversații, autorii au descoperit că mai puțin de cinci procente au avut probleme și mai puțin de două procente au prezentat o schimbare a rezultatului din cauza acestora, considerând aceasta o rată de eroare suficient de scăzută în cadrul parametrilor proiectului.

Scenarii de simulare

Autorii au folosit cinci tipuri de simulări pentru a testa comportamentul modelului în diferite condiții, fiecare reprezentând o variație a modului și momentului în care sunt dezvăluite părți ale instrucțiunii.

În Complet În această setare, modelul primește întreaga instrucțiune într-o singură rundă. Aceasta reprezintă formatul standard de referință și servește drept referință pentru performanță.

Zdrobit Setarea împarte instrucțiunea în mai multe părți și le livrează pe rând, simulând o conversație mai realistă, subspecificată. Aceasta este setarea principală utilizată pentru a testa cât de bine gestionează modelele inputul multi-turn.

În Concat În această setare, fragmentele sunt reîmpărțite într-o singură listă, păstrându-și formularea, dar eliminând structura pas cu pas. Acest lucru ajută la izolarea efectelor fragmentării conversaționale de reformulare sau pierderea de conținut.

Recapitulare setarea funcționează ca Zdrobit, dar adaugă o rundă finală în care toate fragmentele anterioare sunt reformulate înainte ca modelul să ofere un răspuns final. Aceasta testează dacă o solicitare de rezumat poate ajuta la recuperarea contextului pierdut.

În cele din urmă, Bulgăre de zăpadă merge mai departe, repetând toate fragmentele anterioare în fiecare rundă, menținând instrucțiunile complete vizibile pe măsură ce conversația se desfășoară – și oferind un test mai indulgent al abilității de a juca mai multe ture.

Tipuri de simulare bazate pe instrucțiuni fragmentate. Un prompt complet specificat este împărțit în părți mai mici, care pot fi apoi utilizate pentru a simula conversații cu o singură tură (Full, Concat), sau cu mai multe ture (Sharded, Recap, Snowball), în funcție de cât de repede sunt dezvăluite informațiile.

Sarcini și metrici

Au fost alese șase sarcini de generare pentru a acoperi atât domeniul programării, cât și cel al limbajului natural: solicitările de generare a codului au fost preluate din HumanEval și LiveCodeBenchInterogările text-SQL au fost obținute din PăianjenApelurile API au fost construite folosind date din Clasamentul apelurilor de funcții Berkeley; problemele elementare de matematică au fost furnizate de GSM8K; sarcinile de subtitrare tabelară s-au bazat pe TotTo; și rezumatele mai multor documente au fost extrase din Rezumatul unui car cu fân set de date.

Performanța modelului a fost măsurată folosind trei indicatori principali: performanță medie, aptitudine și Nefiabilitate.

Performanță medie a surprins cât de bine s-a comportat un model în general pe parcursul mai multor încercări; aptitudine a reflectat cele mai bune rezultate pe care un model le putea obține, pe baza rezultatelor sale cu scoruri maxime; și Nefiabilitate a măsurat cât de mult au variat aceste rezultate, decalajele mai mari între cele mai bune și cele mai slabe rezultate indicând un comportament mai puțin stabil.

Toate scorurile au fost plasate pe o scală de la 0 la 100 pentru a asigura consecvența între sarcini, iar indicatorii au fost calculați pentru fiecare instrucțiune – apoi mediați pentru a oferi o imagine de ansamblu a performanței modelului.

În experimente au fost utilizate șase sarcini fragmentate, acoperind atât programarea, cât și generarea limbajului natural. Fiecare sarcină este prezentată cu o instrucțiune complet specificată și versiunea sa fragmentată. Între 90 și 120 de instrucțiuni au fost adaptate din reperele stabilite pentru fiecare sarcină.

Concurenți și teste

În simulările inițiale (cu un cost estimat de 5000 USD), 600 de instrucțiuni care acopereau șase sarcini au fost fragmentate și utilizate pentru a simula trei tipuri de conversație: Complet, concat și ascuțitPentru fiecare combinație de model, instrucțiune și tip de simulare, au fost rulate zece conversații, producând peste 200,000 de simulări în total – o schemă care a făcut posibilă surprinderea atât a performanței generale, cât și a unor măsuri mai detaliate ale aptitudinii și fiabilității.

Au fost testate cincisprezece modele, 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 aprilie 04) și modelul de gândire o3 (2025-04-16).

Modelele antropologice au fost Claude 3 Haiku (2024-03-07) și Claude 3.7 Sonetul (2025), accesat prin intermediul Amazon Bedrock.

Google a contribuit Gemini 2.5 Flash (previzualizare-04-17) și Gemini 2.5 Pro (previzualizare-03-25). Metamodelele au fost Llama 3.1-8B-Instruct și Llama 3.3-70B-Instruct, precum și Lamă 4 Cercetaș-17B-16E, prin intermediul Together AI.

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

Pentru cei doi 'gândire' modele (o3 și R1), limite de simbol au fost ridicate la 10,000 pentru a se adapta la lanțuri de raționament mai lungi:

Scorurile medii de performanță pentru fiecare model în șase sarcini: cod, bază de date, acțiuni, date-în-text, matematică și rezumat. Rezultatele sunt afișate pentru trei tipuri de simulări: completă, concatenată și fragmentată. Modelele sunt ordonate în funcție de scorul mediu pentru setarea completă. Umbrirea reflectă gradul de scădere a performanței față de setarea completă, ultimele două coloane raportând scăderi medii pentru concatenare și fragmentare în raport cu setarea completă.

Referitor la aceste rezultate, autorii afirmă^†:

„La un nivel înalt, fiecare model își observă degradarea performanței la fiecare sarcină atunci când se compară performanța COMPLETĂ cu cea FRACȚIONATĂ, cu o degradare medie de -39%. Numim acest fenomen Pierdut în conversațiemodele care ating performanțe stelare (90%+) în condiții de laborator, cu dificultăți în conversații pe o singură tură, complet specificate exact pe aceleași sarcini într-un cadru mai realist atunci când conversația este subspecificată și are mai multe rânduri de răspunsuri.

Concat scorurile au fost în medie de 95% din Complet, indicând faptul că scăderea performanței în configurația fragmentată nu poate fi explicată prin pierderea de informații. Modele mai mici, cum ar fi Llama3.1-8B-Instruct, OLMo-2-13B și Claude 3 Haiku, au prezentat o degradare mai pronunțată sub concat, ceea ce sugerează că modelele mai mici sunt, în general, mai puțin robuste la reformulare decât cele mai mari.

Autorii observă^†:

„În mod 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 degradări medii de 30-40%. Acest lucru se datorează parțial definițiilor metrice. Întrucât modelele mai mici obțin scoruri absolute mai mici în FULL, au un risc mai mic de degradare decât modelele mai bune.

„Pe scurt, indiferent cât de puternică este performanța unui LLM pe o singură tură, observăm degradări mari ale performanței în configurația multi-tură.”

Testul inițial indică faptul că unele modele s-au descurcat mai bine în anumite sarcini: Command-A pentru Acțiuni, Claude 3.7 Sonnet și GPT-4.1 pentru cod; și Gemini 2.5 Pro pentru Transformarea Datelor în Text, ceea ce indică faptul că abilitatea de raționament multi-tură variază în funcție de domeniu. Modelele de raționament precum o3 și Deepseek-R1 nu s-au descurcat mai bine în general, probabil pentru că răspunsurile lor mai lungi au introdus mai multe presupuneri, ceea ce a avut tendința de a deruta conversația.

Încredere

Relația dintre aptitudine și fiabilitate, evidentă în simulările cu o singură tură, părea să se destrame în condiții de tură multiplă. În timp ce aptitudinea a scăzut doar modest, nefiabilitatea sa dublat în medie. Modelele care erau stabile în prompturi în format complet, cum ar fi GPT-4.1 și Gemini 2.5 Pro, au devenit la fel de neregulate ca modelele mai slabe, precum Llama3.1-8B-Instruct sau OLMo-2-13B, odată ce instrucțiunea a fost fragmentată.

Prezentare generală a aptitudinii și a nefiabilității, așa cum se arată într-o diagramă tip box plot (a), urmată de rezultatele fiabilității din experimentele cu cincisprezece modele (b) și rezultatele testului de fragmentare graduală, în care instrucțiunile au fost împărțite în unu până la opt fragmente (c).

Răspunsurile modelului au variat adesea cu până la 50 de puncte în cadrul aceleiași sarcină, chiar și atunci când nu s-a adăugat nimic nou, ceea ce sugerează că scăderea performanței nu s-a datorat lipsei de abilități, ci faptului că modelul a devenit din ce în ce mai instabil de la o tură la alta.

Lucrarea afirmă^†:

„[Deși] modelele mai bune tind să aibă o aptitudine puțin mai mare pentru mai multe ture, toate modelele tind să aibă niveluri similare de nefiabilitate. Cu alte cuvinte, În setări subspecificate, cu mai multe ture, toate modelele pe care le testăm prezintă o nefiabilitate foarte ridicată, cu o degradare medie a performanței de 50% între cea mai bună și cea mai slabă simulare pentru o instrucțiune fixă.

Pentru a testa dacă degradarea performanței era legată de numărul de ture, autorii au efectuat un experiment de fragmentare graduală, împărțind fiecare instrucțiune în unu până la opt fragmente (vezi coloana din dreapta din imaginea de mai sus).

Pe măsură ce numărul de fragmente a crescut, nefiabilitatea a crescut constant, confirmând că chiar și creșteri minore ale numărului de ture au făcut modelele mai instabileAptitudinea a rămas în mare parte neschimbată, ceea ce întărește faptul că problema constă în consistenţă, nu capacitate.

Controlul temperaturii

Un set separat de experimente a testat dacă lipsa de fiabilitate era pur și simplu un produs secundar al aleatoriei. Pentru a face acest lucru, autorii au variat setarea temperaturii atât a asistentului, cât și a simulatorului de utilizator pe trei valori: 1.0, 0.5 și 0.0.

În formate cu o 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%; dar în ascuțit cadru, aceeași intervenție a avut un efect redus:

Scoruri de nefiabilitate pentru diferite combinații de temperatură a asistentului și a utilizatorului în setări complete, concatenate și fragmentate, valorile mai mici indicând o consecvență mai mare a răspunsului.

Chiar și atunci când atât asistentul, cât și utilizatorul au fost setați la temperatura zero, nefiabilitatea a rămas ridicată, GPT-4o prezentând o variație de aproximativ 30%, ceea ce sugerează că instabilitatea observată în conversațiile cu mai multe ture nu este doar... zgomot stochastic, ci o slăbiciune structurală în modul în care modelele gestionează datele de intrare fragmentate.

Implicații

Autorii scriu despre implicațiile descoperirilor lor într-un mod neobișnuit de detaliat în concluzia lucrării, argumentând că o performanță puternică pe o singură tură nu garantează fiabilitatea pe mai multe ture și avertizând împotriva dependenței excesive de repere complet specificate atunci când se evaluează pregătirea pentru lumea reală (deoarece astfel de repere maschează instabilitatea în interacțiuni mai naturale, fragmentate).

De asemenea, ei sugerează că nefiabilitatea nu este doar un artefact de eșantionare, ci un limitare fundamentală în modul în care modelele actuale procesează inputul în evoluție și sugerează că acest lucru ridică îngrijorări pentru cadrele de agenți, care depind de raționament susținut de-a lungul turelor.

În cele din urmă, ei susțin că abilitatea multi-ture ar trebui tratată ca o capacitate de bază a LLM-urilor, nu ca ceva descărcat către sisteme externe.

Autorii notează că rezultatele lor probabil subestima adevărata amploare a problemei și să atragă atenția asupra condițiilor ideale ale testului: simulatorul de utilizator din configurația lor a avut acces deplin la instrucțiuni și a putut dezvălui fragmente într-o ordine optimă, ceea ce i-a oferit asistentului un context nerealist de favorabil (în utilizarea în lumea reală, utilizatorii furnizează adesea solicitări fragmentate sau ambigue fără a ști ce trebuie să audă modelul în continuare).

În plus, asistentul a fost evaluat imediat după fiecare rundă, înainte de desfășurarea conversației complete, prevenind penalizarea confuziilor sau autocontradicțiilor ulterioare, care altfel ar înrăutăți performanța. Aceste alegeri, deși necesare pentru controlul experimental, înseamnă că lacunele de fiabilitate observate în practică sunt probabil chiar mai mari decât cele raportate.

Ei conchid:

„[Credem] că simulările efectuate reprezintă un teren de testare benign pentru capacitățile multi-tură LLM.” Din cauza condițiilor excesiv de simplificate ale simulării, credem că degradarea observată în experimente este, cel mai probabil, o subestimare a nefiabilității LLM și a frecvenței cu care LLM se pierd în conversații în contexte reale."

Concluzie

Oricine a petrecut o perioadă semnificativă de timp cu un master în drept va recunoaște probabil problemele formulate aici, din experiența practică; și majoritatea dintre noi, îmi imaginez, am abandonat intuitiv conversațiile „pierdute” din cadrul masteratului în drept pentru unele noi, în speranța că masteratul va „o lua de la capăt” și va înceta să se mai obsedeze de materialul apărut într-un schimb lung, sinuos și din ce în ce mai exasperant.

Este interesant de observat că oferirea unui context suplimentar problemei nu o rezolvă neapărat; și, într-adevăr, este de observat că lucrarea ridică mai multe întrebări decât oferă răspunsuri (cu excepția modalităților de a ocoli problema).

* În mod confuz, acest lucru nu are legătură cu sensul convențional al cuvântului „sharding” în IA.

† Sublinieri îndrăznețe ale autorilor.

Publicat pentru prima dată luni, 12 mai 2025