Andersons vinkel

Hvorfor sprÃĨkmodeller blir “tapt” i samtale

mm
Legg til Unite.AI blant dine foretrukne kilder pÃĨ Google
ChatGPT-4o and Adobe Firefly.

En ny rapport fra Microsoft Research og Salesforce viser at selv de mest kapable Large Language Models (LLM) bryter sammen nÃĨr instruksjoner blir gitt i stadier fremfor alle pÃĨ en gang. Forfatterne fant ut at ytelsen sank med gjennomsnittlig 39 prosent over seks oppgaver nÃĨr en prompt ble splittert over flere omganger:

En enkelt omgangssamtale (venstre) gir de beste resultater. En fleromgangssamtale (hÃļyre) viser at selv de hÃļyest rangerte og mest performante LLM-ene mister den effektive impulsen i en samtale. Kilde: https://arxiv.org/pdf/2505.06120

En enkelt omgangssamtale (venstre) gir de beste resultater, men er unaturlig for sluttbrukeren. En fleromgangssamtale (hÃļyre) viser at selv de hÃļyest rangerte og mest performante LLM-ene mister den effektive impulsen i en samtale. Kilde: https://arxiv.org/pdf/2505.06120

Enda mer slÃĨende er det at tilfeldigheten av svarene tar en nedtur, med prestisje modeller som ChatGPT-4.1 og Gemini 2.5 Pro som svinger mellom nesten perfekte svar og manifeste feil, avhengig av hvordan den samme oppgaven blir formulert; videre kan utgangskonsistensen synke med mer enn halvparten i prosessen.

For ÃĨ utforske dette beteendet, innfÃļrer rapporten en metode kalt sharding*, som splitter fullestendig angitte prompter inn i mindre fragmenter og slipper dem lÃļs en om gangen i en samtale.

I de enkleste termer er dette ekvivalent med ÃĨ gi en sammenhengende og omfattende enkelt ordre pÃĨ en restaurant, og la kelneren bare bekrefte forespÃļrselen; eller ogsÃĨ ÃĨ angripe saken samarbeidende:

To ekstreme versjoner av en restaurantssamtale (ikke fra den nye rapporten, kun for illustrasjonsformÃĨl).

To ekstreme versjoner av en restaurantssamtale (ikke fra den nye rapporten, kun for illustrasjonsformÃĨl).

For ÃĨ understreke, eksemplet ovenfor plasserer kanskje kunden i et negativt lys. Men kjernen i ideen som er avbildet i den andre kolonnen er en transaksjonell utveksling som klarer et problemsett fÃļr det blir angrepet – ÃĨpenbart en rasjonell og rimelig mÃĨte ÃĨ nÃĶrme seg en oppgave pÃĨ.

Dette oppsettet reflekteres i den nye arbeidets drip-fed, sharded tilnÃĶrming til LLM-interaksjon. Forfatterne merker at LLM-er ofte genererer over langt svar og deretter fortsetter ÃĨ stole pÃĨ deres egne innsikter selv etter at disse innsiktene har vist seg ÃĨ vÃĶre feil eller irrelevante. Denne tendensen, kombinert med andre faktorer, kan fÃļre til at systemet mister spor av utvekslingen helt.

I virkeligheten merker forskerne hva mange av oss har funnet anekdotisk – at den beste mÃĨten ÃĨ fÃĨ samtalen tilbake pÃĨ sporet er ÃĨ starte en ny samtale med LLM-en.

‘Hvis en samtale med en LLM ikke ledet til forventede resultater, kan starten av en ny samtale som gjentar den samme informasjonen muligens gi betydelig bedre resultater enn ÃĨ fortsette en pÃĨgÃĨende samtale.

‘Dette er fordi nÃĨvÃĶrende LLM-er kan bli tapt i samtalen, og vÃĨre eksperimenter viser at ÃĨ holde fast i en samtale med modellen er ineffektivt. I tillegg, siden LLM-er genererer tekst med tilfeldighet, kan en ny samtale muligens lede til forbedrede resultater.’

Forfatterne anerkjenner at agente systemer som Autogen eller LangChain potensielt kan forbedre resultater ved ÃĨ fungere som tolkende lag mellom sluttbrukeren og LLM-en, kun kommuniserer med LLM-en nÃĨr de har samlet inn nok ‘sharded’ svar til ÃĨ koagulere til en enkelt sammenhengende forespÃļrsel (som sluttbrukeren ikke blir eksponert for).

Men forfatterne hevder at et eget abstraksjonslag ikke burde vÃĶre nÃļdvendig, eller ellers bygges direkte inn i kilde-LLM-en:

‘Et argument kan bli fremfÃļrt om at multi-omgangsevner ikke er en nÃļdvendig funksjon i LLM-er, da det kan avlastes til agentrammeverket. Med andre ord, trenger vi nativ multi-omgangsstÃļtte i LLM-er nÃĨr et agentrammeverk kan orkestrere interaksjoner med brukere og utnytte LLM-er bare som enkelt-omgangsoperatÃļrer?â€Ķ’

Men etter ÃĨ ha testet pÃĨstandet over hele deres rekke med eksempler, konkluderer de:

‘[Å stole pÃĨ] et agent-lignende rammeverk for ÃĨ prosessere informasjon kan vÃĶre begrensende, og vi argumenterer for at LLM-er bÃļr stÃļtte nativ multi-omgangssamtale’

Denne interessante nye rapporten har tittelen LLM-er blir tapt i multi-omgangssamtale, og kommer fra fire forskere over MS Research og Salesforce,

Fragmenterte samtaler

Den nye metoden splitter fÃļrst konvensjonelle enkelt-omgangsinstruksjoner inn i mindre shards, designet for ÃĨ bli introdusert pÃĨ nÃļkkelÃļyeblikk under en LLM-interaksjon, en struktur som reflekterer den utforskende, frem-og-tilbake-stilen av engasjement sett i systemer som ChatGPT eller Google Gemini.

Hver opprinnelig instruksjon er en enkelt, selvstendig prompt som leverer hele oppgaven pÃĨ en gang, kombinert med en hÃļy-nivÃĨ-spÃļrsmÃĨl, stÃļttende kontekst og relevante betingelser. Den sharded versjonen splitter dette inn i flere mindre deler, med hver shard som bare legger til ett stykke informasjon:

Parrede instruksjoner som viser (a) en fullstendig prompt levert i en enkelt omgang og (b) dens sharded versjon brukt til ÃĨ simulere en underspesifisert, multi-omgangssamtale. Semantisk sett leverer hver versjon den samme informative lasten.

Parrede instruksjoner som viser (a) en fullstendig prompt levert i en enkelt omgang og (b) dens sharded versjon brukt til ÃĨ simulere en underspesifisert, multi-omgangssamtale. Semantisk sett leverer hver versjon den samme informative lasten.

Den fÃļrste shard introduserer alltid hovedmÃĨlet med oppgaven, mens resten gir klargjÃļrende detaljer. Sammen leverer de den samme innholdet som den opprinnelige prompten, men fordelt naturlig over flere omganger i samtalen.

Hver simuleringsamtale utvikler seg mellom tre komponenter: assistenten, modellen under evaluering; brukeren, en simuleringsagent med tilgang til den fullstendige instruksjonen i sharded form; og systemet, som invigilerer og scorer utvekslingen.

Samtalen begynner med at brukeren avslÃļrer den fÃļrste shard og assistenten svarer fritt. Systemet klassifiserer deretter svaret til en av flere kategorier, som en klargjÃļringforespÃļrsel eller en fullt svarforsÃļk.

Hvis modellen gjÃļr et svarforsÃļk, trekker en separat komponent ut bare den relevante spannen for evaluering, og ignorerer all omgivende tekst. PÃĨ hver ny omgang avslÃļrer brukeren en ekstra shard, og utlÃļser et nytt svar. Utvekslingen fortsetter til modellen fÃĨr svaret riktig eller det ikke er noen shards igjen ÃĨ avslÃļre:

Diagram over en sharded samtale-simulering, med den evaluerte modellen merket i rÃļdt.

Diagram over en sharded samtale-simulering, med den evaluerte modellen merket 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, basert pÃĨ hvordan samtalen gikk.

Bruker-simulatorn, implementert ved hjelp av GPT-4o-mini, fikk derfor full tilgang til bÃĨde den fullstendige instruksjonen og samtale-historien, og ble bedt om ÃĨ bestemme, pÃĨ hver omgang, hvilken shard som skulle avslÃļres neste, basert pÃĨ hvordan utvekslingen utviklet seg.

Bruker-simulatorn omformulerte ogsÃĨ hver shard for ÃĨ opprettholde samtale-flyten, uten ÃĨ endre meningen. Dette tillot simuleringen ÃĨ reflektere ‘gi-og-ta’-stilen av ekte dialog, samtidig som kontrollen over oppgavestrukturen ble opprettholdt.

FÃļr samtalen begynner, fÃĨr assistenten bare den grunnleggende informasjonen som trengs for ÃĨ fullfÃļre oppgaven, som en database-skjema eller en API-referanse. Den blir ikke fortalt at instruksjonene vil bli brutt opp, og den blir ikke veiledet mot en bestemt mÃĨte ÃĨ hÃĨndtere samtalen pÃĨ. Dette gjÃļres med vilje: i virkelige anvendelser er modeller nesten aldri fortalt at en prompt vil bli ufullstendig eller oppdatert over tid, og ÃĨ utelate denne konteksten hjelper simuleringen ÃĨ reflektere 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 sluttsvar fra disse svarene. Dette hjalp simuleringen ÃĨ forbli fleksibel, men innfÃļrte ogsÃĨ noen feil: men etter ÃĨ ha sjekket flere hundre samtaler for hÃĨnd, fant forfatterne ut at fÃĶrre enn fem prosent hadde noen problemer, og fÃĶrre enn to prosent viste en endring i resultatet pÃĨ grunn av dem, og de betraktet dette som en lav nok feilrate innenfor prosjektets rammer.

Simuleringsscenarier

Forfatterne brukte fem typer simulering for ÃĨ teste modellens atferd under forskjellige forhold, hver en variasjon over hvordan og nÃĨr deler av instruksjonen blir avslÃļrt.

I Full-innstillingen mottar modellen hele instruksjonen i en enkelt omgang. Dette representerer den standard benchmark-formatet og tjener som ytelses-basen.

Sharded-innstillingen bryter instruksjonen opp i flere deler og leverer dem en om gangen, simulering en mer realistisk, underspesifisert samtale. Dette er hovedinnstillingen brukt til ÃĨ teste hvordan modeller hÃĨndterer multi-omgangsinput.

I Concat-innstillingen syes shardene sammen igjen som en enkelt liste, og beholder deres formulering, men fjerner omgangsstrukturen. Dette hjelper med ÃĨ isolere effektene av samtale-fragmentering fra omformulering eller innholdstap.

I Recap-innstillingen kjÃļres som Sharded, men legger til en siste omgang hvor alle tidligere shards blir gjentatt fÃļr modellen gir et sluttsvar. Dette tester om en oppsummeringsprompt kan hjelpe med ÃĨ gjenopprette tapt kontekst.

Til slutt gÃĨr Snowball videre, ved ÃĨ gjenta alle tidligere shards pÃĨ hver omgang, og holder hele instruksjonen synlig mens samtalen utvikler seg – og tilbyr en mer tilgjengelig test av multi-omgangsevne.

Simuleringstyper basert pÃĨ sharded instruksjoner. En fullstendig prompt blir splittet opp i mindre deler, som kan brukes til ÃĨ simulere enten enkelt-omgang (Full, Concat) eller multi-omgang (Sharded, Recap, Snowball) samtaler, avhengig av hvor raskt informasjonen blir avslÃļrt.

Simuleringstyper basert pÃĨ sharded instruksjoner. En fullstendig prompt blir splittet opp i mindre deler, som kan brukes til ÃĨ simulere enten enkelt-omgang (Full, Concat) eller multi-omgang (Sharded, Recap, Snowball) samtaler, avhengig av hvor raskt informasjonen blir avslÃļrt.

Oppgaver og metrikker

Seks genereringsoppgaver ble valgt for ÃĨ dekke bÃĨde programmering og naturlig sprÃĨk-domener: kodegenereringsprompter ble tatt fra HumanEval og LiveCodeBench; Text-to-SQL-spÃļrsmÃĨl ble hentet fra Spider; API-kall ble konstruert ved hjelp av data fra Berkeley Function Calling Leaderboard; elementÃĶre matematikkproblemer ble levert av GSM8K; tabell-kapitlingsoppgaver var basert pÃĨ ToTTo; og multi-dokument-sammendrag ble hentet fra Summary of a Haystack-dataset.

Modellens ytelse ble mÃĨlt ved hjelp av tre kjerne-metrikker: gjennomsnittlig ytelse, evne, og utilbÃļyelighet.

Gjennomsnittlig ytelse fanget hvordan godt en modell gjorde det over flere forsÃļk; evne reflekterte de beste resultater en modell kunne nÃĨ, basert pÃĨ dens beste utgangspunkter; og utilbÃļyelighet mÃĨlte hvor mye disse resultater varierte, med stÃļrre gap mellom beste og dÃĨrligste resultater som indikerte mindre stabil atferd.

Alle poeng ble plassert pÃĨ en 0-100 skala for ÃĨ sikre konsistens over oppgaver, og metrikker ble beregnet for hver instruksjon – og deretter gjennomsnittlig for ÃĨ gi en helhetlig bildet av modellens ytelse.

Seks sharded oppgaver brukt i eksperimentene, som dekker bÃĨde programmering og naturlig sprÃĨk-generering. Hver oppgave vises med en fullstendig instruksjon og dens sharded versjon. Mellom 90 og 120 instruksjoner ble tilpasset fra etablerte benchmark-oppgaver for hver oppgave.

Seks sharded oppgaver brukt i eksperimentene, som dekker bÃĨde programmering og naturlig sprÃĨk-generering. Hver oppgave vises med en fullstendig instruksjon og dens sharded versjon. Mellom 90 og 120 instruksjoner ble tilpasset fra etablerte benchmark-oppgaver for hver oppgave.

Konkurrenter og tester

I de initielle simuleringene (med en estimert kostnad pÃĨ 5000 dollar), ble 600 instruksjoner som spente over seks oppgaver sharded og brukt til ÃĨ simulere tre samtale-typer: full, concat, og sharded. For hver kombinasjon av modell, instruksjon og simuleringstype, ble ti samtaler kjÃļrt, og produserte over 200 000 simuleringer i alt – et skjema som gjorde det mulig ÃĨ fange bÃĨde helhetlig ytelse og dypere mÃĨl pÃĨ evne og pÃĨlitelighet.

Femten modeller ble testet, som spente over en rekke 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 tenkingsmodellen o3 (2025-04-16).

Anthropic-modellene var Claude 3 Haiku (2024-03-07) og Claude 3.7 Sonnet (2025-02-19), som ble aksessert via Amazon Bedrock.

Google bidro med Gemini 2.5 Flash (preview-04-17) og Gemini 2.5 Pro (preview-03-25). Meta-modellene var Llama 3.1-8B-Instruct og Llama 3.3-70B-Instruct, samt Llama 4 Scout-17B-16E, via Together AI.

De andre inngangene var OLMo 2 13B, Phi-4, og Command-A, som alle ble aksessert lokalt via Ollama eller Cohere API; og Deepseek-R1, som ble aksessert via Amazon Bedrock.

For de to ‘tenkende’ modellene (o3 og R1), ble token-grensene Ãļkt til 10 000 for ÃĨ akkommodere lengre resonemangs-kjeder:

Gjennomsnittlig ytelsespoeng for hver modell over seks oppgaver: kode, database, handlinger, data-til-tekst, matematikk og sammendrag. Resultater vises for tre simuleringstyper: full, concat og sharded. Modellene er sortert etter deres gjennomsnittlige full-innstillingsscore. Skygging reflekterer graden av ytelsesnedgang fra full-innstillingen, med de to siste kolonnene som rapporterer gjennomsnittlig nedgang for concat og sharded i forhold til full.

Gjennomsnittlig ytelsespoeng for hver modell over seks oppgaver: kode, database, handlinger, data-til-tekst, matematikk og sammendrag. Resultater vises for tre simuleringstyper: full, concat og sharded. Modellene er sortert etter deres gjennomsnittlige full-innstillingsscore. Skygging reflekterer graden av ytelsesnedgang fra full-innstillingen, med de to siste kolonnene som rapporterer gjennomsnittlig nedgang for concat og sharded i forhold til full.

Med hensyn til disse resultater, uttaler forfatterne†:

‘PÃĨ et hÃļyt nivÃĨ ser hver modell sin ytelse forringes pÃĨ hver oppgave nÃĨr FULL og SHARDED-ytelse sammenlignes, med en gjennomsnittlig forringelse pÃĨ -39%. Vi kaller dette fenomenet Lost in Conversation: modeller som oppnÃĨr strÃĨlende (90%+) ytelse i laboratorie-lignende settinger med fullstendig angitte, enkelt-omgangssamtaler, strever pÃĨ de samme oppgavene i en mer realistisk setting nÃĨr samtalen er underspesifisert og multi-omgang.’

Concat-poeng hadde gjennomsnittlig 95 prosent av full, og indikerte at ytelsesnedgangen i den sharded-innstillingen ikke kunne forklares av informasjonstap. Mindre modeller som Llama3.1-8B-Instruct, OLMo-2-13B og Claude 3 Haiku viste mer markant forringelse under concat, og antydet at mindre modeller generelt er mindre robuste til omformulering enn stÃļrre modeller.

Forfatterne observerer†:

‘Overraskende, mer performante modeller (Claude 3.7 Sonnet, Gemini 2.5, GPT-4.1) blir like mye tapt i samtalen sammenlignet med mindre modeller (Llama3.1-8B-Instruct, Phi-4), med gjennomsnittlig forringelse pÃĨ 30-40%. Dette skyldes i del metrikkdefinisjoner. Siden mindre modeller oppnÃĨr lavere absolutt poeng i FULL, har de mindre rom for forringelse enn de bedre modellene.

‘Kort sagt, uansett hvor sterk en LLMs enkelt-omgangsytelse er, observerer vi store ytelsesnedganger i multi-omgangssettingen.’

Den initielle testen indikerer at noen modeller holdt seg bedre i bestemte oppgaver: Command-A pÃĨ handlinger, Claude 3.7 Sonnet og GPT-4.1 pÃĨ kode; og Gemini 2.5 Pro pÃĨ data-til-tekst, og indikerer at multi-omgangsevne varierer med domene. Tenkingsmodeller som o3 og Deepseek-R1 gjorde det ikke bedre generelt, kanskje fordi deres lengre svar innfÃļrte flere antakelser, som tenderte til ÃĨ forvirre samtalen.

PÃĨlitelighet

Forholdet mellom evne og pÃĨlitelighet, tydelig i enkelt-omgangssimuleringer, syntes ÃĨ bryte sammen under multi-omgangsforhold. Mens evnen sank bare moderat, doblet utilbÃļyeligheten seg i gjennomsnitt. Modeller som var stabile i full-formatprompter, som GPT-4.1 og Gemini 2.5 Pro, ble like ustabile som svakere modeller som Llama3.1-8B-Instruct eller OLMo-2-13B, sÃĨ snart instruksjonen ble fragmentert.

Oversikt over evne og utilbÃļyelighet, vist i en boksplot (a), etterfulgt av pÃĨlitelighetsresultater fra eksperimenter med 15 modeller (b), og resultater fra den gradvise sharding-testen hvor instruksjoner ble delt inn i ett til ÃĨtte shards (c).

Oversikt over evne og utilbÃļyelighet, vist i en boksplot (a), etterfulgt av pÃĨlitelighetsresultater fra eksperimenter med 15 modeller (b), og resultater fra den gradvise sharding-testen hvor instruksjoner ble delt inn i ett til ÃĨtte shards (c).

Modellens svar varierte ofte sÃĨ mye som 50 poeng pÃĨ samme oppgave, selv nÃĨr ingenting nytt ble lagt til, og antydet at nedgangen i ytelse ikke skyldtes mangel pÃĨ ferdighet, men at modellen ble stadig mer ustabil over omgangene.

Rapporten slÃĨr fast†:

‘[Selv om] bedre modeller tenderer til ÃĨ ha en litt hÃļyere multi-omgangsevne, tenderer alle modeller til ÃĨ ha lignende nivÃĨer av utilbÃļyelighet. Med andre ord, i multi-omgangs-, underspesifiserte settinger, viser alle modeller vi tester svÃĶrt hÃļy utilbÃļyelighet, med ytelse som forringes 50 poeng pÃĨ gjennomsnitt mellom beste og dÃĨrligste simuleringskjÃļringer for en fast instruksjon.’

For ÃĨ teste om ytelsesnedgangen var knyttet til antall omganger, kjÃļrte forfatterne en gradvis sharding-eksperiment, og delte hver instruksjon inn i ett til ÃĨtte shards (se hÃļyre kolonne i bildet ovenfor).

Etterhvert som antall shards Ãļkte, steg utilbÃļyeligheten jevnt, og bekreftet at selv smÃĨ Ãļkninger i omgangstelling gjorde modellene mer ustabile. Evnen forble stort sett uendret, og understreket at problemet ligger i konsekvens, ikke evne.

Temperaturkontroll

En separat sett med eksperimenter testet om utilbÃļyelighet bare var et biprodukt av tilfeldighet. For ÃĨ gjÃļre dette, varierte forfatterne temperaturinnstillingen for bÃĨde assistenten og bruker-simulator over tre verdier: 1,0, 0,5 og 0,0.

I enkelt-omgangsformater som full og concat forbedret reduksjon av assistentens temperatur pÃĨliteligheten betydelig, og kutte variasjonen med opptil 80 prosent; men i den sharded-innstillingen hadde samme inngripen liten effekt:

UtilbÃļyelighetsscore for ulike kombinasjoner av assistent- og bruker-temperatur over full, concat og sharded-innstilling. Lavere verdier indikerer stÃļrre svar-konsistens.

UtilbÃļyelighetsscore for ulike kombinasjoner av assistent- og bruker-temperatur over full, concat og sharded-innstilling. Lavere verdier indikerer stÃļrre svar-konsistens.

Selv nÃĨr bÃĨde assistenten og brukeren var satt til null temperatur, forble utilbÃļyeligheten hÃļy, med GPT-4o som viste variasjon rundt 30 prosent, og antydet at ustabiliteten sett i multi-omgangssamtaler ikke bare skyldes stokastisk stÃļy, men en strukturell svakhet i hvordan modeller hÃĨndterer fragmentert input.

Konsekvenser

Forfatterne skriver om konsekvensene av funnene pÃĨ en usedvanlig lengde i rapportens konklusjon, og argumenterer for at sterk enkelt-omgangsytelse ikke garanterer multi-omgangspÃĨlitelighet, og advarer mot ÃĨ over-gjÃļre pÃĨ fullstendig angitte benchmark-tester nÃĨr man vurderer virkelige anvendelser (siden slike tester maskerer ustabilitet i mer naturlige, fragmenterte interaksjoner).

De foreslÃĨr ogsÃĨ at utilbÃļyelighet ikke bare er et stikprÃļve-arterefakt, men en grunnleggende begrensning i hvordan nÃĨvÃĶrende modeller prosesserer utviklende input, og de antyder at dette Ãļker bekymringer for agent-rammeverk, som avhenger av vedvarende resonemang over omganger.

Til slutt argumenterer de for at multi-omgangsevne bÃļr behandles som en kjerne-egenskap i LLM-er, og ikke noe som kan lastes over pÃĨ eksterne systemer.

Forfatterne merker at deres resultater sannsynligvis underskattet den sanne skalaen av problemet, og trekker oppmerksomheten til de ideelle forholdene i testen: bruker-simulatorn i deres oppsett hadde full tilgang til instruksjonen og kunne avslÃļre shards i en optimal rekkefÃļlge, noe som ga assistenten en urealistisk gunstig kontekst (i virkelige anvendelser gir brukere ofte fragmenterte eller tvetydige prompter uten ÃĨ vite hva modellen trenger ÃĨ hÃļre neste).

I tillegg ble assistenten evaluert umiddelbart etter hver omgang, fÃļr hele samtalen utviklet seg, og hindret senere forvirring eller selv-motstridende fra ÃĨ bli straffet, noe som ellers ville forverret ytelsen. Disse valgene, selv om de var nÃļdvendige for eksperimentell kontroll, betyr at pÃĨlitelighetsgapene observert i praksis sannsynligvis vil vÃĶre enda stÃļrre enn de rapporterte.

De konkluderer:

‘[Vi] tror at gjennomfÃļrte simuleringer representerer en harmlÃļs testarena for LLM-ers multi-omgangsevner. Fordi de overforente testforholdene er for enkle, tror vi at forringelsen observert i eksperimentene sannsynligvis er en underskattelse av LLM-ers utilbÃļyelighet, og hvor ofte LLM-er blir tapt i samtalen i virkelige settinger.‘

Konklusjon

Hver person som har tilbragt en betydelig mengde tid med en LLM, vil sannsynligvis gjenkjenne problemene formulert her, fra praktisk erfaring; og de fleste av oss, tenker jeg, har intuitivt forlatt ‘tapt’ LLM-samtaler for nye, i hÃĨp om at LLM-en kan ‘starte pÃĨ nytt’ og slutte ÃĨ besette seg med materiale som kom opp i en lang, vindende og stadig mer irriterende utveksling.

Det er interessant ÃĨ merke at ÃĨ kaste mer kontekst pÃĨ problemet kanskje ikke nÃļdvendigvis lÃļser det; og faktisk ÃĨ observere at rapporten reiser flere spÃļrsmÃĨl enn den gir svar pÃĨ (bortsett fra mÃĨter ÃĨ hoppe over problemet).

 

* Forvirrende, dette er ikke relatert til den konvensjonelle betydningen av ‘sharding’ i AI.

† Forfatterens egne fet skrifttyper.

FÃļrst publisert mandag, 12. mai 2025

Forfatter innen maskinlÃĶring, domenespesialist i menneskeskapesynthese. Tidligere sjef for forskningsinnhold i Metaphysic.ai, til det ble opplÃļst i DNEG's Brahma.ai.
Portfolio nettsted: martinanderson.ai
Kontakt: [email protected]