Hvorfor språkmodeller går «tapt» i samtaler

En ny artikkel fra Microsoft Research og Salesforce viser at selv de dyktigste Store språkmodeller (LLM-er) faller fra hverandre når instruksjoner gis i etapper heller enn alt på én gang. Forfatterne fant at ytelsen synker med gjennomsnittlig 39 prosent på tvers av seks oppgaver når en ledetekst er fordelt over flere runder:

En samtale med én runde (venstre) gir de beste resultatene, men er unaturlig for sluttbrukeren. En samtale med flere runder (høyre) fører til at selv de høyest rangerte og mest effektive LLM-ene mister den effektive drivkraften i en samtale. Kilde: https://arxiv.org/pdf/2505.06120

Mer påfallende er det at pålitelighet av svarene tar et stup, med prestisjefylte modeller som CatGPT-4.1 og Gemini 2.5 Pro svingende mellom nesten perfekte svar og åpenbare feil, avhengig av hvordan den samme oppgaven er formulert; dessuten kan konsistensen i produksjonen synke med mer enn halvparten i prosessen.

For å utforske denne oppførselen introduserer artikkelen en metode som kalles skjæring*, som deler opp fullstendig spesifiserte spørsmål i mindre fragmenter og frigjør dem én om gangen i en samtale.

Enkelt sagt tilsvarer dette å gi en helhetlig og omfattende enkeltbestilling på en restaurant, slik at servitøren ikke har noe annet å gjøre enn å bekrefte forespørselen; eller bestemme seg for å angripe saken i fellesskap:

To ekstreme versjoner av en restaurantsamtale (ikke fra den nye avisen, kun for illustrasjonsformål).

For å understreke dette, setter eksemplet ovenfor kanskje kunden i et negativt lys. Men kjerneideen som er skildret i den andre kolonnen er en transaksjonsutveksling som avklarer et problemsett før problemene tas opp – tilsynelatende en rasjonell og rimelig måte å tilnærme seg en oppgave på.

Dette oppsettet gjenspeiles i det nye verkets dryppmatede, knust tilnærming til LLM-interaksjon. Forfatterne bemerker at LLM-er ofte genererer altfor lange svar og deretter fortsetter å stole på sin egen innsikt selv etter at disse innsiktene har vist seg å være feil eller irrelevanteDenne tendensen, kombinert med andre faktorer, kan føre til at systemet mister oversikten over utvekslingen fullstendig.

Faktisk legger forskerne merke til hva mange av oss har funnet anekdotisk – at den beste måten å få samtalen tilbake på sporet er å starte en ny samtale med juristspesialisten.

«Hvis en samtale med en LLM ikke førte til forventede resultater, kan det å starte en ny samtale som gjentar den samme informasjonen gi betydelig bedre resultater enn å fortsette en pågående samtale.»

«Dette er fordi nåværende LLM-er kan gå seg vill i samtalen, og våre eksperimenter viser at det er ineffektivt å fortsette i en samtale med modellen. I tillegg, siden LLM-er genererer tekst med tilfeldighet, kan en ny samtale føre til forbedrede resultater.»

Forfatterne erkjenner at agentsystemer som autogent or Langkjede kan potensielt forbedre resultatene ved å fungere som tolkende lag mellom sluttbrukeren og LLM-en, og bare kommunisere med LLM-en når de har samlet nok «shardede» svar til å koagulere til én enkelt sammenhengende spørring (som sluttbrukeren ikke vil bli eksponert for).

Forfatterne hevder imidlertid at et separat abstraksjonslag ikke burde være nødvendig, eller at det ellers burde bygges direkte inn i kilde-LLM-en:

«Man kan argumentere for at flerturnfunksjoner ikke er en nødvendig funksjon i LLM-er, ettersom de kan overføres til agentrammeverket. Med andre ord, trenger vi innebygd flerturnstøtte i LLM-er når et agentrammeverk kan orkestrere interaksjoner med brukere og kun utnytte LLM-er som enkeltturnoperatorer? ...»

Men etter å ha testet påstanden på tvers av sine eksempler, konkluderer de:

«[Å stole på] et agentlignende rammeverk for å behandle informasjon kan være begrensende, og vi argumenterer for at LLM-er bør ha innebygd støtte for interaksjon mellom flere omganger.»

Dette interessant nytt papir har tittelen LLM-er går seg vill i flertrinnssamtaler, og kommer fra fire forskere på tvers av MS Research og Salesforce,

Fragmenterte samtaler

Den nye metoden bryter først ned konvensjonelle enkeltrunde-instruksjoner i mindre shards, designet for å bli introdusert i viktige øyeblikk under en LLM-interaksjon, en struktur som gjenspeiler den utforskende, frem-og-tilbake-stilen for engasjement som sees i systemer som ChatGPT eller Google Gemini.

Hver originale instruksjon er en enkelt, selvstendig ledetekst som leverer hele oppgaven på én gang, og kombinerer et spørsmål på høyt nivå, støttende kontekst og eventuelle relevante betingelser. Den shard-baserte versjonen deler dette opp i flere mindre deler, der hver shard bare legger til én informasjonsbit:

Parvise instruksjoner som viser (a) en komplett prompt levert i én runde og (b) dens sharded-versjon brukt til å simulere en underspesifisert interaksjon med flere runder. Semantisk leverer hver versjon den samme informative nyttelasten.

Den første sharden introduserer alltid hovedmålet med oppgaven, mens resten gir avklarende detaljer. Sammen leverer de det samme innholdet som den opprinnelige prompten, men sprer seg naturlig over flere runder i samtalen.

Hver simulerte samtale utfolder seg mellom tre komponenter: assistent, modellen som evalueres; bruker, en simulert agent med tilgang til hele instruksjonen i sharded-format; og system, som overvåker og gir poeng i utvekslingen.

Samtalen starter med at brukeren avslører den første sharden, og assistenten svarer fritt. Systemet klassifiserer deretter svaret i en av flere kategorier, for eksempel en forespørsel om avklaring eller forsøk på fullstendig svar.

Hvis modellen gjør forsøke et svar, trekker en separat komponent ut kun det relevante spennet for evaluering, og ignorerer all omkringliggende tekst. På hver ny tur avslører brukeren én ekstra shard, noe som fører til et nytt svar. Utvekslingen fortsetter til enten modellen får riktig svar eller det ikke er noen shards igjen å avsløre:

Diagram av en sharded samtalesimulering, med den evaluerte modellen uthevet i rødt.

Tidlige tester viste at modeller ofte spurte om informasjon som ikke hadde blitt delt ennå, så forfatterne droppet ideen om å avsløre shards i en fast rekkefølge. I stedet ble en simulator brukt til å bestemme hvilken shard som skulle avsløres neste gang, basert på hvordan samtalen forløp.

Brukersimulatoren, implementert med GPT-4o-mini, fikk derfor full tilgang til både hele instruksjonen og samtalehistorikken, med oppgaven å bestemme, for hver runde, hvilken shard som skulle avsløres neste gang, basert på hvordan utvekslingen utfoldet seg.

Brukersimulatoren også omformulert hver shard for å opprettholde samtaleflyten uten å endre meningen. Dette tillot simuleringen å gjenspeile «gi og ta» i ekte dialog, samtidig som kontrollen over oppgavestrukturen ble bevart.

Før samtalen starter, får assistenten bare den grunnleggende informasjonen som er nødvendig for å fullføre oppgaven, for eksempel et databaseskjema eller en API-referanse. Den får ikke vite at instruksjonene vil bli delt opp, og den blir ikke veiledet mot noen spesifikk måte å håndtere samtalen på. Dette gjøres med vilje: i bruk i den virkelige verden får modeller nesten aldri vite at en ledetekst vil være ufullstendig eller oppdatert over tid, og å utelate denne konteksten hjelper simuleringen med å gjenspeile hvordan modellen oppfører seg i en mer realistisk kontekst.

GPT-4o-mini ble også brukt til å bestemme hvordan modellens svar skulle klassifiseres, og til å trekke ut eventuelle endelige svar fra disse svarene. Dette hjalp simuleringen med å holde seg fleksibel, men introduserte sporadiske feil: etter å ha sjekket flere hundre samtaler for hånd fant forfatterne imidlertid at færre enn fem prosent hadde noen problemer, og færre enn to prosent viste endring i utfallet på grunn av dem, og de anså dette som en lav nok feilrate innenfor prosjektets rammer.

Simuleringsscenarier

Forfatterne brukte fem typer simuleringer for å teste modellatferd under forskjellige forhold, hver en variant av hvordan og når deler av instruksjonen avsløres.

på Full innstillingen, mottar modellen hele instruksjonen i én runde. Dette representerer standard referanseformat og fungerer som ytelsesgrunnlinjen.

Ocuco Skjært Innstillingen deler opp instruksjonen i flere deler og leverer dem én om gangen, noe som simulerer en mer realistisk, underspesifisert samtale. Dette er hovedinnstillingen som brukes til å teste hvor godt modeller håndterer flerturn-input.

på Concat I denne innstillingen settes fragmentene sammen igjen til én liste, og ordlyden bevares, men den trinnvise strukturen fjernes. Dette bidrar til å isolere effektene av samtalefragmentering fra omformulering eller tap av innhold.

Ocuco Oppsummering innstillingen går som Skjært, men legger til en siste runde der alle tidligere shards blir omformulert før modellen gir et endelig svar. Dette tester om en sammendragsoppgave kan bidra til å gjenopprette tapt kontekst.

Endelig, Snowball går videre ved å gjenta alle tidligere skår på hver tur, slik at hele instruksjonen er synlig mens samtalen utfolder seg – og det gir en mer tilgivende test av evnen til å kjøre flere runder.

Simuleringstyper basert på sharded-instruksjoner. En fullstendig spesifisert ledetekst deles inn i mindre deler, som deretter kan brukes til å simulere enten enkeltrunde- (Full, Concat) eller flerrunde- (Sharded, Recap, Snowball) samtaler, avhengig av hvor raskt informasjonen avsløres.

Oppgaver og målinger

Seks generasjonsoppgaver ble valgt for å dekke både programmerings- og naturlige språkdomener: kodegenereringsoppgaver ble hentet fra HumanEval og LiveCodeBenchTekst-til-SQL-spørringer ble hentet fra SpiderAPI-kall ble konstruert ved hjelp av data fra Toppliste for Berkeley-funksjonskall; elementære matematikkoppgaver ble levert av GSM8K; tabellformede tekstingsoppgaver var basert på ToTo; og sammendrag av flere dokumenter ble hentet fra Sammendrag av en høystakk datasett.

Modellytelsen ble målt ved hjelp av tre kjerneparametre: gjennomsnittlig ytelse, aptitudeog upålitelighet.

Gjennomsnittlig ytelse fanget opp hvor bra en modell gjorde det totalt sett på tvers av flere forsøk; aptitude reflekterte de beste resultatene en modell kunne oppnå, basert på dens toppscorende utganger; og upålitelighet målte hvor mye disse resultatene varierte, med større gap mellom beste og verste utfall som indikerer mindre stabil atferd.

Alle poengsummer ble plassert på en skala fra 0–100 for å sikre konsistens på tvers av oppgaver, og målinger ble beregnet for hver instruksjon – og deretter gjennomsnittet beregnet for å gi et helhetsbilde av modellens ytelse.

Seks shardede oppgaver brukt i eksperimentene, som dekker både programmering og generering av naturlig språk. Hver oppgave vises med en fullstendig spesifisert instruksjon og dens shardede versjon. Mellom 90 og 120 instruksjoner ble tilpasset fra etablerte referansepunkter for hver oppgave.

Konkurrenter og tester

I de første simuleringene (med en estimert kostnad på $5000) ble 600 instruksjoner som spenner over seks oppgaver shardet og brukt til å simulere tre samtaletyper: fullt, konkatog knustFor hver kombinasjon av modell, instruksjon og simuleringstype ble det kjørt ti samtaler, noe som produserte over 200,000 XNUMX simuleringer totalt – et skjema som gjorde det mulig å fange opp både total ytelse og dypere mål på egnethet og pålitelighet.

Femten modeller ble testet, som spenner over et bredt spekter av leverandører og arkitekturer: OpenAI-modellene GPT-4o (versjon 2024-11-20), GPT-4o-mini (2024-07-18), GPT-4.1 (2025-04-14), og tankemodellen o3 (2025-04-16).

Antropiske modeller var Claude 3 Haiku (2024-03-07) og Claude 3.7 sonett (2025-02-19), tilgjengelig via Amazon Bedrock.

Google bidro Gemini 2.5 Flash (forhåndsvisning-04-17) og Gemini 2.5 Pro (forhåndsvisning-03-25). Metamodeller var Llama 3.1-8B-Instruksjon og Llama 3.3-70B-Instruksjon, i tillegg til Llama 4 Scout-17B-16E, via Sammen AI.

De andre bidragene var OLMo 2 13B, Phi-4og Kommando-A, alt tilgjengelig lokalt via Ollama eller Cohere API; og Deepseek-R1, tilgjengelig via Amazon Bedrock.

For de to 'tenker' modeller (o3 og R1), symbolske grenser ble hevet til 10,000 XNUMX for å imøtekomme lengre resonneringskjeder:

Gjennomsnittlige ytelsespoeng for hver modell på tvers av seks oppgaver: kode, database, handlinger, data-til-tekst, matematikk og sammendrag. Resultatene vises for tre simuleringstyper: full, concat og sharded. Modeller er sortert etter gjennomsnittlig poengsum for full innstilling. Skyggelegging gjenspeiler graden av ytelsesfall fra full innstilling, der de to siste kolonnene rapporterer gjennomsnittlig nedgang for concat og sharded i forhold til full.

Angående disse resultatene, sier forfatterne^†:

«På et høyt nivå, hver modell ser ytelsen sin forringes på hver oppgave når man sammenligner FULL og SHARDED ytelse, med en gjennomsnittlig degradering på -39 %. Vi kaller dette fenomenet Tapt i samtalenmodeller som oppnår fantastisk ytelse (90 %+) i laboratorielignende omgivelser med fullt spesifisert samtalekamp med én tur på akkurat de samme oppgavene i en mer realistisk setting når samtalen er underspesifisert og går over flere vendinger.

Concat gjennomsnittspoengsummene var 95 prosent av fullt, noe som indikerer at ytelsesfallet i den shardede innstillingen ikke kan forklares med informasjonstap. Mindre modeller som Llama3.1-8B-Instruct, OLMo-2-13B og Claude 3 Haiku viste mer uttalt forringelse under konkat, noe som tyder på at mindre modeller generelt er mindre robuste mot omformulering enn større.

Forfatterne observerer^†:

Overraskende nok, Mer effektive modeller (Claude 3.7 Sonnet, Gemini 2.5, GPT-4.1) går like mye tapt i samtalen som mindre modeller (Llama 3.1-8B-Instruct, Phi-4)), med gjennomsnittlige degraderinger på 30–40 %. Dette skyldes delvis metriske definisjoner. Siden mindre modeller oppnår lavere absolutte poengsummer i FULL, de har mindre potensial for degradering enn de bedre modellene.

«Kort sagt, uansett hvor sterk en LLMs ytelse i én turn er, observerer vi store ytelsesforringelser i flerturn-settingen.»

Den første testen indikerer at noen modeller holdt seg bedre i spesifikke oppgaver: Command-A på handlinger, Claude 3.7 Sonnet og GPT-4.1 på kode; og Gemini 2.5 Pro på data-til-tekst, noe som indikerer at evnen til å omdanne flere vendinger varierer etter domene. Resonneringsmodeller som o3 og Deepseek-R1 gjorde det ikke bedre totalt sett, kanskje fordi de lengre svarene deres introduserte flere antagelser, noe som pleide å forvirre samtalen.

Pålitelighet

Forholdet mellom evne og pålitelighet, tydelig i simuleringer med én tur, så ut til å falle fra hverandre under forhold med flere turner. Mens evnen bare avtok beskjedent, var upåliteligheten doblet i gjennomsnitt. Modeller som var stabile i fullformat-ledetekster, som GPT-4.1 og Gemini 2.5 Pro, ble like uberegnelige som svakere modeller som Llama3.1-8B-Instruct eller OLMo-2-13B når instruksjonen ble fragmentert.

Oversikt over egnethet og upålitelighet vist i et boksplott (a), etterfulgt av pålitelighetsutfall fra eksperimenter med femten modeller (b), og resultater fra den gradvise sharding-testen der instruksjoner ble delt inn i én til åtte shards (c).

Modellresponsene varierte ofte med så mye som 50 poeng på samme oppgave, selv når ingenting nytt ble lagt til, noe som tyder på at nedgangen i ytelse ikke skyldtes mangel på ferdigheter, men at modellen ble stadig mer ustabil på tvers av runder.

Avisen sier^†:

«[Selv om] bedre modeller har en tendens til å ha litt høyere flerturnevner, har alle modeller en tendens til å ha lignende nivåer av upålitelighet. Med andre ord, I flerturns, underspesifiserte innstillinger viser alle modellene vi tester svært høy upålitelighet, med en ytelsesforringelse på 50 prosentpoeng i gjennomsnitt mellom den beste og verste simulerte kjøringen for en fast instruksjon.».

For å teste om ytelsesforringelse var knyttet til antall runder, kjørte forfatterne et gradvis sharding-eksperiment, der de delte hver instruksjon inn i én til åtte shards (se høyre kolonne i bildet ovenfor).

Etter hvert som antallet shards økte, økte upåliteligheten jevnt og trutt, noe som bekreftet at Selv små økninger i antall turn gjorde modellene mer ustabileEvneverdien forble stort sett uendret, noe som forsterker at problemet ligger i konsistens, ikke evne.

Temperaturkontroll

Et separat sett med eksperimenter testet om upålitelighet rett og slett var et biprodukt av tilfeldighet. For å gjøre dette varierte forfatterne temperaturinnstillingen til både assistenten og brukersimulatoren på tvers av tre verdier: 1.0, 0.5 og 0.0.

I enkeltsvingningsformater som fullt og konkat, ved å redusere assistentens temperatur forbedret påliteligheten betydelig, og variasjonen ble redusert med så mye som 80 prosent; men i knust innstillingen, hadde den samme intervensjonen liten effekt:

Upålitelighetspoeng for ulike kombinasjoner av assistent- og brukertemperatur på tvers av fulle, sammenslåtte og shardede innstillinger, der lavere verdier indikerer større responskonsistens.

Selv når både assistenten og brukeren var satt til nulltemperatur, forble upåliteligheten høy, med GPT-4o som viste variasjon rundt 30 prosent, noe som tyder på at ustabiliteten som sees i samtaler med flere runder ikke bare er stokastisk støy, men en strukturell svakhet i hvordan modeller håndterer fragmentert input.

Implikasjoner

Forfatterne skriver uvanlig langt om implikasjonene av funnene sine i konklusjonen av artikkelen, og argumenterer for at sterk ytelse på én tur ikke garanterer pålitelighet på flere turner, og advarer mot å stole for mye på fullt spesifiserte referansepunkter når man evaluerer beredskap i den virkelige verden (siden slike referansepunkter maskerer ustabilitet i mer naturlige, fragmenterte interaksjoner).

De antyder også at upålitelighet ikke bare er et utvalgsartefakt, men en grunnleggende begrensning i hvordan nåværende modeller behandler utviklende input, og de antyder at dette reiser bekymringer for agentrammeverk, som er avhengige av vedvarende resonnement på tvers av turneer.

Til slutt argumenterer de for at flerturnsevne bør behandles som en kjernefunksjon hos LLM-er, ikke noe som overføres til eksterne systemer.

Forfatterne bemerker at resultatene deres sannsynligvis undervurder problemets sanne omfang, og rette oppmerksomheten mot de ideelle forholdene for testen: brukersimulatoren i oppsettet deres hadde full tilgang til instruksjonen og kunne avsløre skjær i en optimal rekkefølge, noe som ga assistenten en urealistisk gunstig kontekst (i bruk i den virkelige verden gir brukere ofte fragmenterte eller tvetydige ledetekster uten å vite hva modellen trenger å høre videre).

I tillegg ble assistenten evaluert umiddelbart etter hver runde, før hele samtalen utfoldet seg, noe som forhindrer at senere forvirring eller selvmotsigelser blir straffet, noe som ellers ville forverret ytelsen. Disse valgene, selv om de er nødvendige for eksperimentell kontroll, betyr at pålitelighetsgapene som observeres i praksis sannsynligvis vil være enda større enn de som er rapportert.

De konkluderer med:

«[Vi] mener at gjennomførte simuleringer representerer et gunstig testområde for LLM-multi-turn-kapasiteter. På grunn av de altfor forenklede simuleringsbetingelsene, tror vi at degraderingen observert i eksperimentene mest sannsynlig er en undervurdering av LLM-ens upålitelighet, og hvor ofte LLM-er går tapt i samtaler i virkelige omgivelser.'

Konklusjon

Alle som har brukt mye tid på en LLM vil sannsynligvis gjenkjenne problemstillingene som er formulert her, fra praktisk erfaring; og jeg antar at de fleste av oss intuitivt har forlatt «tapte» LLM-samtaler til fordel for nye, i håp om at LLM-en kan «starte på nytt» og slutte å være besatt av materiale som dukket opp i en lang, kronglete og stadig mer irriterende utveksling.

Det er interessant å merke seg at det å sette mer kontekst på problemet ikke nødvendigvis løser det; og faktisk å observere at artikkelen reiser flere spørsmål enn den gir svar (bortsett fra når det gjelder måter å hoppe over problemet på).

* Forvirrende nok er dette ikke relatert til den konvensjonelle betydningen av «sharding» i AI.

† Forfatternes egne dristige vektlegginger.

Først publisert mandag 12. mai 2025