Læring af virkelige erfaringer

Hvordan brugere interagerer med vores produkter i den virkelige verden, er en værdifuld kilde til modeltræning. Dataene er rigelige, afspejler den faktiske fordeling af brugeropgaver og indfanger brugerkorrektioner og værktøjsfejl, som syntetiske miljøer kan overse.

En almindelig måde at lære af data fra den virkelige verden på er rejection sampling fine-tuning: bedøm hver sessions udfald, beholde de succesfulde og træn modellen til at imitere dem. Men et succesfuldt udfald betyder ikke, at hvert trin var korrekt, så at imitere hele trajektorien risikerer at forstærke dårlige mellemliggende adfærdsmønstre ud over de gode. At kassere mislykkede sessioner mister også kritisk evidens om, hvor modellen kommer til kort.

Vi kombinerer fintuning af afvisningssampling med tip-vejledt selv-distillation for at lære af både vellykkede og mislykkede sessioner. Et tip er en kort korrigerende instruktion baseret på information, som modellen allerede havde, da den begik fejlen. Nyttige trin fra vellykkede sessioner forbliver imitationmål, mens baserede tip gør undgåelige fejl til rettelsesmål.

Brugerkorrektioner og værktøjsfejl tilføjer overvågning om, hvad der gik galt undervejs, ud over om opgaven i sidste ende lykkedes. Vi anvender dette trin efter forstærkende læring i syntetiske miljøer for at hjælpe med at lukke kløften mellem disse miljøer og brug i den virkelige verden.

Ved live brug reducerede et senere post-trænet GLM-5.2-kontrolpunkt fejl i værktøjskalder med 21,2 % i forhold til et tidligere trænet kontrolpunkt. For GLM-5.3 reducerede post-træning fejl i værktøjskalder med 33,0 % og den gennemsnitlige estimerede sandsynlighed for middel til høj utilfredshed hos brugeren med 17,2 % i forhold til standardmodellen.

Syntetiske opgaver giver os mulighed for at skabe kontrollerede problemer med udfald, der er nemme at verificere, men de er typisk begrænset til en enkelt prompt og kan kun dække de scenarier, vi udtrykkeligt designer.

I kontrast bringer brugere i sessioner i den virkelige verden forskellige instruktioner, kontekst og værktøjskombinationer ind i sessioner, der udfolder sig over flere interaktionsomgange. Sådan brug i den virkelige verden giver naturligt to værdifulde signaler om fejl: brugerkorrektioner afslører, hvor agenten mislykkedes med at levere det, de ønskede, og værktøjsfejl viser, hvor dens handlinger brød sammen i virkelige miljøer. Vores samplingspipeline respekterer brugernes privatliv og træningsvalg ved at udelukke sessioner med personhenførbare oplysninger (PII) og fra brugere, der har fravagt.

Data fra den virkelige verden giver os derfor fejltilfælde, som et syntetisk miljø måske ikke afslører, og leveres ofte med fejlen allerede indlejret der, hvor den opstod.

Når man træner på data fra den virkelige verden, vælger standard rejection sampling fine-tuning (RFT) succesfulde sessioner baseret på deres endelige udfald uden udtrykkeligt at bruge bruger- og værktøjsfeedback til at skelne gode mellemliggende handlinger fra dårlige. En agent kan komme sig over et dårligt værktøjsopkald eller rette en fejl efter brugerfeedback og stadig levere det rigtige output til sidst.

At kassere mislykkede sessioner begrænser også sample-effektiviteten. En session, der aldrig når et godt resultat, kan stadig afsløre en tydelig, undgåelig fejl som nyttige træningssignaler.

Vi adresserer disse begrænsninger ved at adskille to beslutninger: hvilke sessioner der indeholder adfærd, der er værd at imitere, og hvilke omgange der indeholder fejl, der er værd at rette. Datapipelinen træffer disse beslutninger separat og tildeler derefter modelomgange en af tre behandlinger:

Imiter: ikke-fejl-omgange i succesfulde sessioner modtager almindeligt Cross-Entropy (CE) tab, hvilket øger sandsynligheden for registrerede tokens.
Korrekt: i både succesfulde og ufrugtbare sessioner modtager fejolomgange med et gyldigt tip et Kullback–Leibler (KL) divergenstab, hvilket flytter modellen mod de forudsigelser for næste token, den foretager, når den ser tippet.
Behold som kontekst: omgange i ufrugtbare sessioner, der mangler et valideret tip, og markerede dårlige omgange uden et valideret tip i en af sessionstypperne, fungerer som kontekst, men modtager ikke nogen af tabene.

Som et resultat kan succesfulde sessioner levere både imiterings- og korrektionsmål, mens ufrugtbare sessioner kun leverer korrektionsmål. Alle resterende omgange, herunder system-, bruger- og værktøjsoutput, forbliver som kontekst.

Session-routing-diagram: succesfulde sessioner giver CE-imitation og berettigede tip-baserede korrektioner; ufrugtbare sessioner giver kun berettigede korrektioner. — Nuværende session-routing og assistentindholdsmasker. Succesfulde sessioner bidrager med imiteringsmål; bevarede feedbackposter kan bidrage med tip-baserede korrektioner, selv når sessionen er ufrugtbar. Andet indhold forbliver som kontekst. Ufuldstændige sessioner udelukkes. CE-undtagelsen for ikke-final yield/stop-token er ikke tegnet, og dette diagram fastslår ikke den blanding, der blev brugt af et tidligere checkpoint.

Imiteringsdelen bruger standard RFT. Den korrigerende del bruger On-Policy Self-Distillation (OPSD): den samme model fungerer som lærer og elev, hvor læreren får privilegeret information. Her er den privilegerede information et kort tip, der forklarer en undgåelig fejl. Vi træner eleven til at matche lærerens forudsigelser for næste token uden at få tippet overrakt.

Begge dele betyder noget. Kun-korrektion-træning kan afsløre en genvej: lærer og elev kan blive enige ved at ignorere kontekst i stedet for at lære korrektionen. CE-leddet forankrer træningen til nyttig adfærd og hjælper med at modvirke enighed, der kommer fra at ignorere kontekst.

Den eftertrænede elev bliver derefter en modelmulighed i Computer. Nye sessioner fra live-brug passerer gennem de samme egnetheds- og privatlivsfiltre, før de går ind i endnu en runde af træningspipelinen.

Dernæst gennemgår vi et konkret eksempel, der indeholder både imitation og korrektion.

Overvej en eventuel succesfuld session, hvor brugeren beder om en sammenligning af asyncio-ændringer i Python 3.13 ved hjælp af officiel dokumentation. Vores værktøjsdokumentation angiver, at search.web returnerer en liste over træffere, hver med et url-felt.

Modellen kører først en gyldig søgning efter én version som en del af indsamling af evidens til sammenligning, hvilket er en god adfærd at imitere.

Dog behandler det næste kodeeksekveringsopkald forkert denne liste som en ordbog. Kodetøjet returnerer TypeError: list indices must be integers or slices, not str. Da returtypen blev dokumenteret før opkaldet, er det en fejl, modellen burde have kunnet undgå. Et tip med det rigtige opkald kan genereres for at rette denne handling.

Illustrativ kodningssession: system- og brugerinput samt værktøjsfejl forbliver kontekst; nyttige registrerede søge- og gendannelsesopkald modtager CE i en succesfuld session; en markeret fejlagtig listesøgning modtager KL mod en lærer givet et funderet tip. — En illustrativ kodningssession viser tre træningsroller: kun-kontekst-input og værktøjsoutput (grå), CE-imitation af nyttige registrerede opkald (mørk) og KL-korrektion af en markeret fejl (blågrøn). Her behandler modellen fejlagtigt en liste over søgetræffere som en ordbog; et lærer-eneste-tip funderet i tidligere værktøjsdokumentation vejleder korrektionen. CE-mål gælder kun, når den fuldførte session bedømmes som succesfuld, mens en ufrugtbar session stadig kan levere et berettiget KL-korrektionsmål.

Træningspipelinen har fire trin: vælg sessioner og bedøm deres udfald, identificer fejl og opret tip ud fra brugerfeedback og værktøjsfejl, generer forudsigelser for næste token fra både læreren og eleven, og træn modellen med et kombineret CE- og KL-tab.

Prøveudtagnings-pipelinen trækker fra en træningsberettiget delmængde af virkelige Computer-sessioner, der serviceres af GLM 5.2. Fravalg af træning og pipelinens PII-relaterede udelukkelser anvendes, før eksempler til denne arbejdsproces vælges.

Den indledende screeningsproces vælger kandidater vurderet til 4 eller 5 på en fem-punkts skala for opgavesværhedsgrad af en LLM-dommer og opdeler dem i 2 grupper:

Brugerfeedback-gruppen indeholder sessioner med en ægte brugeropfølgning eller et flag for medium-til-høj utilfredshed. Vi finder disse opfølgninger med høj hensigt særligt nyttige til læring: brugere prøver aktivt at fuldføre en opgave, og deres korrektioner fastslår nøjagtigt, hvad modellen overså.
Gruppen med værktøjsfejl indeholder sessioner med mislykkede opkald markeret af regelbaserede kontroller, eksklusive genkendte infrastrukturfejl og afvist godkendelse.

To LLM-dommere vurderer derefter det endelige resultat i forhold til brugerens anmodning; begge dommere skal vende tilbage med en positiv dom for at mærke sessionen som "succesfuld". For tilfælde, der leverer artefakter, kan udfaldstrinnet rekonstruere og inspistere leveringen og falde tilbage på sine tekstbaserede bedømmelser, hvis det trin mislykkes. Sessioner, der klassificeres som ufuldstændige, såsom arbejde, der venter på brugeren, udelukkes.

Dette trin identificerer mulige kilder til læringssignaler; dog kan ikke enhver fejl tilskrives modellen, da nogle opstår som følge af tvetydige instruktioner eller infrastrukturfejl. Senere annotering bestemmer, hvilke kandidatfejl der faktisk er undgåelige og egnede til træning.

Overvej en eksempelsession i brugerfeedback-gruppen, hvor brugeren spørger: "How do I find my w3 on paychex". Modellen behandler "w3" som en skrivefejl for W-2, søger efter W-2-instruktioner og forklarer, hvordan man finder den formular. Brugerens opfølgning, "I meant the W-3 transmittal form," identificerer fejlen, selvom sessionen i sidste ende lykkes.

Klagen hjælper med at finde fejlen, men rodårsagen er den tidligere beslutning om at fortolke "w3" som W-2. Den oprindelige forespørgsel gør fejlen undgåelig: modellen kunne have bevaret W-3 eller bedt om afklaring. Det viser sig, at den sidste assistentrumgang før klagen kun er rodårsagen i omkring halvdelen af tilfældene.

Vores annoteringspipeline karterer årsag og virkning systematisk inden for hver brugerfeedback-session. Annotatoren screener først for et overset krav eller en hensigt understøttet af tidligere kontekst. Tre LLM-dommere identificerer derefter de ansvarlige omgange og kræver, at mindst to er enige om en given omgang. Nogle ganger etablerer en tidligere udtalelse udtrykkeligt kravet. I andre tilfælde gør ingen enkelt prioriteret udtalelse det, men flere dele af den foregående samtale gør i fællesskab den tilsigtede adfærd udledningsbar. Dette design lader dem forbinde en klage med en tidligere rodfejl i stedet for udelukkende at tilskrive den det sidste svar.

Før pipelinen accepterer et tip, kontrollerer den også, at dens korrigerende påstande følger af oplysninger, der var tilgængelige før den markerede omgang. Disse kontroller har til formål at reducere efterklogskabsbias, hvor en ny præference afsløret i klagen behandles som noget, modellen allerede burde have vidst.

I dette eksempel forteller tippet modellen, at den skal søge efter W-3-indberetningsformularen på Paychex i stedet for W-2, eller spørge, hvilken formular brugeren mener, hvis anmodningen er tvetydig. Korrektionen er rettet mod den tidligere fortolkning og søgebeslutning, ikke kun det endelige svar. Den oprindelige omgang forbliver uændret; annoteringen tilføjer is_bad_turn: true og et ikke-tomt tip.

En W-3-forespørgsel mistolkes som W-2; en senere klage spores til den tidligere søgebeslutning og tjekkes mod tidligere evidens. — En reel session, der viser, hvordan en klage spores tilbage til en tidligere fejl, med annoteringsproceduren lagt henover. Brugeren bad om "w3" på Paychex, men modellen behandlede det som en skrivefejl for W-2 og søgte efter den forkerte formular. Forslagsstiller-konsensus lokaliserer rodårsagen, mens to afstemningskontroller vurderer, om evidensen er ældre end fejlen, og tippets påstande følger af oplysninger, der var tilgængelige på det tidspunkt. Accepterede annoteringer bevarer den oprindelige tekst og tilføjer mærker og tip i stedet for omskrevne mål.

Overvej endnu en session i værktøjsfejl-gruppen med et søgeopkald, hvor agenten søger med recency_filter: "year", men værktøjet afviser det, fordi de tilladte værdier er "day", "week" eller "month". Dette er en tydelig skemakrænkelser.

Værktøjsfejl-stien bruger deterministiske regler for kendte fejl og modelbedømmelse for tvetydige tilfælde. En fejlmeddelelse alene er heller ikke nok til at give modellen skylden; en bedømt korrektion skal pege på noget, modellen kunne have vidst fra værktøjsskemaet, systeminstruktionerne eller den tidligere samtale.

Et søgeopkald bruger den ugyldige recency_filter-værdi year; et funderet tip instruerer modellen i at bruge en opført værdi eller udelade et valgfrit felt. — Rapportens ugyldige søgeargument illustrerer den nuværende procedure for værktøjsfejl. Skemaet gør denne fejl undgåelig; et udfald alene ville ikke gøre det. Det oprindelige opkald forbliver i posten og modtager et funderet tip. Tippet tillader en opført værdi eller udeladelse, hvis feltet er valgfrit; det kræver ikke "month" for hver forespørgsel.

Her navngiver tippet det mislykkede opkald, inkluderer valideringsfejlen og instruerer modellen i at bruge en tilladt værdi eller udelade feltet, hvis det er valgfrit.

Når en tur er markeret, kører træneren det samme checkpoint to gange: én gang som lærer og én gang som elev. Læreren ser tippet; eleven gør det ikke.

Begge gennemgange bruger lærerstyring (teacher forcing), hvor vi fodrer modellen med den registrerede session i stedet for at lade den vælge nye tokens. Den fremadrettede gennemgang producerer stadig en fuld fordeling af næste token ved hvert trin, men den betinges altid af det faste præfiks fra optagelsen og ikke af udrulningstokens.

For søge-eksemplet tildeler den samme model en meget højere sandsynlighed til "month" og mindre til "year", når den får tippet. Træning bruger dette fordelingsskift som et blødt mål.

Den samme model scorer en logget omgang med og uden et tip; afkoblede lærersandsynligheder leverer KL-mål, mens CE forankrer imitation. — To gennemgange, ét sæt vægte. Begge gennemgange scorer den loggede fortsættelse; kun læreren modtager tip. Dens afkoblede næste-token-sandsynligheder vejleder eleven gennem fremadrettet KL. Separate CE-mål forankrer imitation. Begge tab føder én vægtopdatering. Tidligere tip kan forblive i lærerens nuværende segment; ingen af gennemgangene genererer et erstatnings-træningssvar.

Lærerens forudsigelser er afkoblede eller stop-gradient: de leverer et mål, men modtager ikke en opdatering gennem lærergennemgangen. Efter elevens gennemgang opdaterer ét optimeringstrin den delte model.

CE-tab behandler de registrerede tokens, der er valgt til imitation, som ground-truth-mål og straffer modellen for at tildele dem lave sandsynligheder. Dette skaber et hårdt imiteringsmål.

Ved tokenposition $i$ , lad $p_i(v)$ være elevens sandsynlighed for token $v$ i det fulde vokabularium $V$ . Det registrerede næste token i svaret eller værktøjsopkaldet er $y_i$ , den one-hot-målfordeling er $r_i$ .

r_i(v)=\mathbf{1}[v=y_i]

Krydsentropi (Cross-entropy) måler, hvor godt eleven forudsiger det registrerede token. Med et one-hot-mål reduceres det til den negative log-sandsynlighed tildelt $y_i$ .

H(r_i,p_i)=-\sum_{v\in V}r_i(v)\log p_i(v)=-\log p_i(y_i)

CE-masken $m_i^{\mathrm{CE}}$ er $1$ , hvor tokenet skal imiteres, og $0$ ellers. Summering over de valgte positioner giver imiterings-tabet.

\mathcal{L}_{\mathrm{CE}}=\sum_i m_i^{\mathrm{CE}}H(r_i,p_i)

KL-tab (KL loss) bruger i stedet lærerens fulde sandsynlighedsfordeling for næste token $q_i$ som et blødt korrektionsmål. Lærerens kontekst inkluderer det aktuelle tip og eventuelle tidligere tip, der er bevaret i det pågældende træningssegment; elevens kontekst er altid tip-fri.

KL-masken $m_i^{\mathrm{KL}}$ er $1$ , hvor tokenet skal korrigeres, og $0$ ellers; CE- og KL-maskerne overlapper ikke. På disse positioner straffer fremadrettet KL uenighed mellem lærer og elev på tværs af hele vokabulariet:

\mathcal{L}_{\mathrm{KL}}=\sum_i m_i^{\mathrm{KL}}D_{\mathrm{KL}}(q_i\Vert p_i)=\sum_i m_i^{\mathrm{KL}}\sum_{v\in V}q_i(v)\log\frac{q_i(v)}{p_i(v)}

Begge led deler én nævner i stedet for at blive normaliseret separat. Denne nævner tæller det samlede antal tokens, der er valgt til imitation på tværs af den globale træningsbatch. Vægten $\lambda$ styrer bidraget fra korrigerende træning i forhold til imitation.

Denne delte normalisering passer til vores træningsinfrastrukturs grænseflade med én nævner og gendanner standard SFT-tabet, når $\lambda=0$ , hvilket forenkler baseline-sammenligninger. Fordi CE-tokens er meget mere udbredte end KL-tokens, undgår brugen af en delt nævner også at give individuelle KL-tokens uforholdsmæssigt store vægte i batches med få markerede tokens.

\mathcal{L}=\frac{\mathcal{L}_{\mathrm{CE}}+\lambda\mathcal{L}_{\mathrm{KL}}}{\sum_i m_i^{\mathrm{CE}}}

Anvendt på de tidligere eksempler modtager de omgange, der indeholder W-3/W-2-sammenblandingen og det ugyldige søgeopkald, KL. Andet umarkeret assistentindhold i en succesfuld session modtager stadig CE. Andet assistentindhold i en ufrugtbar session bevares som kontekst, men modtager hverken CE eller KL.

Vores evalueringer besvarer to separate spørgsmål. For det første: Hjælper et tip faktisk modellen med at rette en fejl, når tippet er til stede? For det andet: Hjælper træning modellen med at undgå den fejl senere, uden tippet? Den første tester, om tip giver nyttige træningssignaler. Den anden tester, om modellen lærer af dem.

Vi tester det første spørgsmål, før træningen kører, for at sikre, at tip faktisk kan styre modellen væk fra fejlene.

Vi genskabte markerede brugerfeedback-omgange med og uden et tip ved hjælp af den samme GLM-5.2-basismodel ved temperatur nul. En blind dommer ser den senere klage, men hverken tippet eller hvilken tilstand der producerede svaret.

I W-3-eksemplet flytter tippet sandsynligheden for næste token mod "3" og væk fra "2" efter præfikset "W-".

Sandsynligheder for næste token efter W- skifter mod 3 i stedet for 2, når den uændrede basismodel modtager et tip. — Et tip bevarer den anmodede W-3-formular. Søjler viser gennemsnitlige sandsynligheder for næste token på tværs af otte fremadrettede gennemgange; forhøjninger viser det observerede interval, ikke et konfidensinterval. Begge tilstande bruger den uændrede basismodel.

På et større hold-out-sample på 40 omgange understøttet af udtrykkeligt angivet tidligere evidens stiger andelen, der bedømmes som rettet eller på sporet, fra 40,0 % uden et tip til 75,0 % med et. På yderligere 40 omgange understøttet af udledt hensigt stiger den fra 32,5 % til 80,0 %.

Tip-validering: faste eller på sporet-rater stiger fra 40,0 % til 75,0 % for eksplicit bevismateriale og 32,5 % til 80,0 % for udledt hensigt. — Tip-validering, ikke eftertræningsevaluering. De samme 40 markerede omgange i hver evidensgruppe genskabes med og uden et tip ved hjælp af uændret GLM-5.2 ved temperatur nul. Dommeren ser klagen, men ikke tippet eller tilstanden. Antal er udledt af rapportens rater og stikprøvestørrelser; konfidensintervaller rapporteres ikke.

I eksemplet med søgeværktøjsfejl flytter et tip faktisk sandsynlighedsmasse fra year-tokenet til month-tokenet.

Et tip flytter den uændrede basismodels sandsynligheder for næste token væk fra year og mod den tilladte værdi month. — Et tip flytter sandsynlighed mod en tilladt værdi. Søjler viser gennemsnitlige sandsynligheder for næste token på tværs af otte fremadrettede gennemgange; forhøjninger viser det observerede interval, ikke et konfidensinterval. Begge tilstande bruger den samme basismodel; intet trænede checkpoint sammenlignes.

På et større hold-out-sample på 985 omgange genskaber vi hver omgang fire gange med og uden et tip ved hjælp af den samme basismodel. En blind dommer evaluerer, om hver genskabelse undgår den oprindelige fejl. Tip øger undgåelse af fejl fra 75,1 % til 93,7 %, en parret stigning på 18,6 procentpoint, og øger andelen, der foretager den korrigerede handling, fra 60,6 % til 82.3 %. Gevinster er størst ved fejl, som gentagen sampling alene har svært ved at rette.

På 985 hold-out markerede værktøjsfejl-omgange øger tip fejlundgåelse fra 75,1 % til 93,7 % og rater for korrigerede handlinger fra 60,6 % til 82,3 %. — Validering af værktøjsfejl-tip på 985 hold-out markerede omgange, med fire genskabelser pr. tilstand. Søjler viser fejlundgåelse og rater for korrigerede handlinger for den uændrede basismodel, med og uden tip. At undgå den målrettede fejl etablerer ikke succes med værktøjsopkald eller opgaver.

Vi tester derefter, om den trænede model laver færre fejl uden at modtage hints. Vi evaluerer standardmodellen og forskellige post-trænede checkpoints på offline benchmark-opgaver og i live usersessioner og ser efter færre værktøjsfejl og mindre brugermisnøje.

Den offline evaluering bruger BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, et repræsentativt Computer-opgavesæt og kontrollerer for færdighedsindlæsning, dokumentgennemgang og indbyggede kilder. Vi måler andelen af værktøjsopkald, hvis resultater udtrykkeligt er markeret som fejl på tværs af evalueringstrajektorierne.

I disse evalueringer var den registrerede værktøjsfejlrate 2,79 % for standard GLM 5.2, 1,35 % for kun-RFT-checkpointet og 0,87 % for et RFT-plus-OPSD-checkpoint. Disse checkpoints blev trænet på forskellige data, så dette er ikke en matchet-data-ablering af OPSD. Opgaveniveauets benchmarkresultater var blandede, så færre værktøjsfejl alene oversættes ikke nødvendigvis til en bred forbedring af opgavesucces.

Offline registrerede rater for værktøjsfejl: 2,79 % for standard GLM 5.2, 1,35 % for kun-RFT og 0,87 % for RFT plus OPSD; træningsdata varierer. — Offline rater for værktøjsfejl for standard GLM-5.2, kun-RFT og RFT-plus-OPSD-checkpoints. Træningsdataene varierer på tværs af checkpoints; dette er ikke en kontrolleret ablering.

For GLM-5.2 kørte vi to separate A/B-tests med omkring 100.000 brugere i hver betingelse. I den første havde et tidligt RFT-plus-OPSD-checkpoint en lidt lavere rater for værktøjsfejl end standard GLM-5.2, 2,82 % mod 2,94 %, men forskellen var ikke statistisk signifikant.

I den senere test sammenlignede vi to RFT-plus-OPSD-checkpoints: et tidligere (checkpoint et) og et senere (checkpoint to). Værktøjsopkaldsfejl faldt fra 2,24 % til 1,77 % af opkald med en registreret status. Dette var en statistisk signifikant 21,2 % relativ reduktion. Vi sammenlignede ikke direkte checkpoint to med standard GLM 5.2 online.

Brugertilbagemeldingernes resultater var mindre entydige. I det andet GLM-5.2-eksperiment var den gennemsnitlige sandsynlighed for stærk utilfredshed (middel eller høj) 2,58 % for checkpoint et og 2,54 % for checkpoint to, uden statistisk signifikant forskel.

To separate online A/B-tester; kun den senere checkpoint-sammenligning har en signifikant reduktion af værktøjsfejl uden nogen signifikant ændring i MID+-utilfredshed. — To separate GLM-5.2 live-A/B-tests. Checkpoint 1 sammenlignes med standard GLM-5.2; checkpoint 2 sammenlignes med checkpoint 1. Inden for disse to tests er det kun den senere reduktion af værktøjsfejl, der er statistisk signifikant. MID+-rater angiver gennemsnitlige estimerede sandsynligheder for middel til høj utilfredshed, ikke antallet af klager.

For GLM-5.3 sammenlignede vi et post-trænet kontrolpunkt direkte med standard-GLM-5.3. Fejl i værktøjskalder faldt fra 3,56 % til 2,38 % af kald med en registreret status, hvilket er en relativ reduktion på 33,04 %. MID+-raten, som er den gennemsnitlige estimerede sandsynlighed for middel eller høj utilfredshed, faldt fra 4,12 % til 3,41 %, hvilket er en relativ reduktion på 17,2 %. Begge reduktioner var statistisk signifikante.

GLM-5.3 A/B-test: Fejlraten for værktøjer falder fra 3,56 % til 2,38 %, og MID+-raten, som er den gennemsnitlige estimerede sandsynlighed for middel eller høj utilfredshed, falder fra 4,12 % til 3,41 %. CUPED-justerede relative reduktioner er henholdsvis 33,04 % og 17,16 %. Begge 95 % sekventielle intervaller udelukker nul; det primære engagementstal er ikke signifikant. — Post-trænet GLM-5.3 sammenlignet med standard-GLM-5.3 i en separat online A/B-test. Fejl- og MID+-rater for værktøjer, relative ændringer og 95 % sekventielle konfidensintervaller bruger CUPED-justering. Begge reduktioner er statistisk signifikante. MID+-rater viser gennemsnitlige estimerede sandsynligheder for middel eller høj utilfredshed over berettigede scorede opfølgende tråde, ikke antal klager. Værktøjsfejlraten udelukker kald uden en registreret succes- eller fejlstatus.

Den centrale idé er at lære på beslutningsniveauet, ikke bare sessionen.

Et succesfuldt udfald kan skjule fejl, og en ufrugtbar session kan stadig afsløre, hvordan man kan forbedre sig. Vi bevarer nyttig adfærd fra succesfulde sessioner som et anker, bruger klager og værktøjsfejl til at identificere undgåelige fejl og træner modellen mod de forudsigelser, den foretager, når disse fejl og korrektioner gøres eksplicitte. Succes giver adfærd at bevare; fejl giver retning for forbedring.

Brug i den virkelige verden gør denne tilgang særligt nyttig. Virkelige brugere bringer mål, begrænsninger og arbejdsgange, der er svære at forudse i et syntetisk miljø. Deres korrektioner afslører krav, som modellen overså, mens værktøjsfejl blotlægger huller mellem det, modellen forsøgte, og det, miljøet tillader. Disse signaler supplerer udfaldsbaseret træning: i stedet for kun at spørge, om en opgave lykkedes, kan vi spørge, hvor modellen gik galt, og hvilke oplysninger der kunne have hjulpet den til at træffe en bedre beslutning.

Grænserne er lige så vigtige. Dommere kan tage fejl, og det at rette en tur garanterer ikke, at hele opgaven lykkes. Målet er ikke blot en agent, der kommer sig efter en rettelse. Det er en agent, der har brug for rettelser sjældnere.

BibTeX

@online{perplexity2026LearningFromRealWorldExperience,
  author = {{Perplexity} and Senzeyu Zhang and Chuan Wang and Hang Wu and Hao Zhang and Yuan Liang and Yunfan Zhong and Phi Hoang and Claire Beamer and Jeremy Yang and Andrew Wilson and Denis Yarats},
  title = {{Learning from real-world experience}},
  date = {2026-09-21},
  url = {https://www.perplexity.ai/hub/blog/learning-from-real-world-experience}
}

Fra syntetiske til virkelige data

Imiter de gode trin, ret de dårlige

Et eksempel: én session kan lære begge lektier

Hvordan træningen virker

Vælg sessioner, og bedøm derefter udfaldet

Find fejlene fra brugerfeedback

Find fejlene fra værktøjsfejl

To fremadrettede gennemgange (Two forward passes)

Tabmålet (The loss function)

CE-tabet (The CE loss)

KL-tab (KL loss)

Kombineret tab (Combined loss)

Hvad evalueringerne viser

Tip kan styre modellen væk fra fejlene

Brugerfeedback

Værktøjsfejl

Værktøjspålidelighed og brugertilbagemeldinger efter træning

Offline evaluering

Onelinevaluering: GLM-5.2

Onlinetest: GLM-5.3

Konklusion

Citering