Læring fra virkelige erfaringer

Hvordan brukere samhandler med produktene våre i den virkelige verden, er en verdifull kilde for modelltrenig. Dataene er overflødige, reflekterer den faktiske distribusjonen av brukeroppgaver, og fanger opp brukerkorreksjoner og verktøyfeil som syntetiske miljøer kan gå glipp av.

En vanlig måte å lære fra data i den virkelige verden på er avvisningssamplingsfinjustering: vurder hver øktson utfall, beholde de vellykkede, og tren modellen til å imitere dem. Men et vellykket utfall betyr ikke at hvert trinn var korrekt, så å imitere hele banen risikerer å forsterke dårlige mellombaserte atferder i tillegg til gode. Å forkaste mislykkede økter mister også kritiske bevis på hvor modellen kommer til kort.

Vi kombinerer finjustering av avvisningssampling med hintstyrt selvinstillatelse for å lære av både vellykkede og mislykkede økter. Et hint er en kort korrigerende instruksjon basert på informasjon som modellen allerede hadde da den gjorde feilen. Nyttige trinn fra vellykkede økter forblir imitasjonsmål, mens begrunnede hint gjør unngåelige feil til korrigeringsmål.

Brukerkorreksjoner og verktøyfeil legger til veiledning om hva som gikk galt underveis, i tillegg til om oppgaven til slutt lyktes. Vi bruker dette trinnet etter forsterkende læring i syntetiske miljøer for å bidra til å tette gapet mellom disse miljøene og bruk i den virkelige verden.

Ved bruk i sanntid reduserte et senere ettertrenet GLM-5.2-sjekkpunkt feil i verktøykall med 21,2 % sammenlignet med et tidligere trenet sjekkpunkt. For GLM-5.3 reduserte ettertrening feil i verktøykall med 33,0 % og den gjennomsnittlige anslåtte sannsynligheten for middels eller høy brukermisnøye med 17,2 % sammenlignet med standardmodellen.

Syntetiske oppgaver lar oss opprette kontrollerte problemer med utfall som er enkle å verifisere, men de er vanligvis begrenset til én enkelt ledetekst og kan bare dekke scenarioene vi designer eksplisitt.

I kontrast bringer brukere i virkelige økter med seg mangfoldige instruksjoner, kontekst og verktøykombinasjoner inn i økter som utspiller seg over flere interaksjonsvendinger. Slik virkelige bruk gir naturlig to verdifulle signaler om feil: brukerkorreksjoner avslører hvor agenten ikke klarte å levere det de ville, og verktøyfeil viser hvor handlingene dens brøt sammen i virkelige miljøer. Samplingpipelinen vår respekterer brukernes personvern og treningsvalg ved å ekskludere økter med personlig identifiserbar informasjon (PII) og fra brukere som har reservert seg.

Data fra den virkelige verden gir oss derfor feiltilfeller som et syntetisk miljø kanskje ikke eksponerer, og kommer ofte med hvor feilen oppstod, allerede bakt inn.

Ved trening på data fra den virkelige verden velger standard avvisningssamplingsfinjustering (RFT) vellykkede økter basert på deres endelige utfall, uten eksplisitt å bruke bruker- og verktøytilbakemeldinger til å skille gode mellomliggende handlinger fra dårlige. En agent kan komme seg etter et dårlig verktøykall eller korrigere en feil etter brukertilbakemelding og fremdeles levere riktig utdata på slutten.

Å forkaste mislykkede økter begrenser også utvalgseffektiviteten. En økt som aldri når et godt resultat, kan likevel avsløre en tydelig, unngåelig feil som nyttige treningssignaler.

Vi løser disse begrensningene ved å separere to beslutninger: hvilke økter som inneholder atferd verdt å imitere, og hvilke vendinger som inneholder feil verdt å korrigere. Datapipelinen tar disse beslutningene separat, og tildeler deretter modellvendinger en av tre behandlinger:

Imiter: ikkefeilvendinger i vellykkede økter mottar vanlig kryssentropitap (CE-tap), som øker sannsynligheten for innspilte token.
Korrekt: i både vellykkede og mislykkede økter mottar feilvendinger med et gyldig hint et Kullback–Leibler (KL) divergenstap, som flytter modellen mot neste-token-forutsigelsene den gjør når den ser hintet.
Behold som kontekst: vendinger i mislykkede økter som mangler eit validert hint, og markerte dårlige vendinger uten eit validert hint i nokre av økttypene, fungerer som kontekst, men mottar ikkje nokre tap.

Som et resultat kan vellykkede økter levere både imitasjons- og korreksjonsmål, mens mislykkede økter bare leverer korreksjonsmål. Alle gjenværende vendinger, inkludert system-, bruker- og verktøyutdata, forblir som kontekst.

Øktruting-diagram: vellykkede økter gir CE-imitasjon og berettigede hintede korreksjoner; mislykkede økter gir bare berettigede korreksjoner. — Gjeldende øktruting og assistentinnhold-masker. Vellykkede økter bidrar med imitasjonsmål; behåldte tilbakemeldingsposter kan bidra med hintede korreksjoner selv når økten er mislykket. Annet innhold forblir som kontekst. Ufullstendige økter ekskluderes. CE-unntaket for ikke-endelig avkastning/stopp-token er ikke tegnet, og dette diagrammet etablerer ikke blandingen som brukes av et tidligere sjekkpunkt.

Imitasjonsdelen bruker standard RFT. Den korrigerende delen bruker On-Policy Self-Distillation (OPSD): den samme modellen fungerer som lærer og elev, der læreren får privilegert informasjon. Her er den privilegerte informasjonen et kort hint som forklarer en unngåelig feil. Vi trener eleven til å matche lærerens neste-token-forutsigelser uten å bli utlevert hintet.

Begge deler betyr noe. Bare-korreksjon-trening kan avsløre en snarvei: lærer og elev kan bli enige ved å ignorere kontekst i stedet for å lære korreksjonen. CE-leddet forankrer treningen til nyttig atferd, noe som bidrar til å motvirke enighet som kommer av å ignorere kontekst.

Den ettertrente eleven blir deretter et modellalternativ i Computer. Nye økter fra live-bruk går gjennom de samme kvalifiserings- og personvernfiltrene før de går inn i en ny runde med treningspipelinen.

Deretter går vi gjennom et konkret eksempel som inneholder både imitasjon og korreksjon.

Tenk på en til slutt vellykket økt der brukeren ber om en sammenligning av asyncio-endringer i Python 3.13 ved hjelp av offisiell dokumentasjon. Verktøydokumentasjonen vår slår fast at search.web returnerer en liste over treff, hver med et url-felt.

Modellen kjører først et gyldig søk etter én versjon som en del av samlingen av bevis for sammenligning, noe som er en god atferd å imitere.

Imidlertid behandler det neste kodeutførelseskallet feilaktig den listen som en ordbok. Kodeverktøyet returnerer TypeError: list indices must be integers or slices, not str. Fordi returtypen ble dokumentert før kallet, er det en feil modellen burde ha klart å unngå. Et hint med riktig kall kan genereres for å rette opp den handlingen.

Illustrativ kodesøkt: system- og brukerinndata og verktøyfeil forblir kontekst; nyttige innspilte søke- og gjenopprettingssøk mottar CE i en vellykket økt; en merket feilaktig listeforespørsel mottar KL mot en lærer gitt et begrunnet hint. — En illustrativ kodesøkt viser tre treningsroller: kun-kontekst-inndata og verktøyutdata (grå), CE-imitasjon av nyttige innspilte kall (mørke), og KL-korreksjon av en merket feil (turkis). Her behandler modellen feilaktig en liste over søketreff som en ordbok; et lærer-eneste-hint forankret i tidligere verktøydokumentasjon veileder korreksjonen. CE-mål gjelder bare når den fullførte økten vurderes som vellykket, mens en mislykket økt fremdeles kan levere et berettiget KL-korreksjonsmål.

Treningspipelinen har fire trinn: velg økter og vurder utfallene deres, identifiser feil og opprett hint fra brukerrespons og verktøyfeil, generer neste-token-sannsynligheter fra både læreren og eleven, og tren modellen med et kombinert CE- og KL-tap.

Utvalget i sampling-pipelinen henter fra et treningsberettiget delsett av virkelige Computer-økter som betjenes av GLM 5.2. Opt-outs for trening og pipeline-ens PII-relaterte eksklusjoner brukes før eksempler velges til denne arbeidsflyten.

Den første screeningsprosessen velger ut kandidater vurdert til 4 eller 5 på en fempunkts skala for oppgavevanskelighetsgrad av en LLM-dommer, og deler dem inn i 2 grupper:

Brukerresponsgruppen inneholder økter med en ekte brukeroppfølging eller et flagg for medium til høy misnøye. Vi finner disse oppfølgingene med høy intensjon spesielt nyttige for læring: brukere prøver aktivt å fullføre en oppgave, og korreksjonene deres peker nøyaktig på hva modellen gikk glipp av.
Verktøyfeilgruppen inneholder økter med mislykkede kall flagget av regelbaserte sjekker, og ekskluderer gjenkjente infrastrukturfeil og avslått autorisasjon.

To LLM-dommere vurderer deretter det endelige resultatet opp mot brukerens forespørsel; begge dommere må gi en positiv dom for at økten skal merkes som "vellykket". For tilfeller som leverer artefakter, kan utfallstrinne rekonstruere og inspisere leveransen, med tilbakefall til sine tekstbaserte vurderinger hvis det trinnet feiler. Økter som klassifiseres som ufullstendige, slik som arbeid som venter på brukeren, ekskluderes.

Dette trinnet identifiserer potensielle kilder til treningssignaler; imidlertid kan ikke alle feil tilskrives modellen, da noen oppstår fra tvetydige instruksjoner eller infrastrukturfeil. Senere annotering avgjør hvilke kandidatfeil som faktisk er unngåelige og egnet for trening.

Tenk deg en eksempeltur i brukerrespons-gruppen, der brukeren spør: "How do I find my w3 on paychex". Modellen behandler "w3" som en skrivefeil for W-2, søker etter W-2-instruksjoner og forklarer hvordan man finner det skjemaet. Brukerens oppfølging, "I meant the W-3 transmittal form," identifiserer feilen, selv om økten til slutt lykkes.

Klagen hjelper til med å lokalisere feilen, men den underliggende årsaken er den tidligere beslutningen om å omfortolke "w3" som W-2. Den opprinnelige forespørselen gjør feilen unngåelig: modellen kunne ha bevart W-3 eller bedt om avklaring. Det viser seg at den siste assistentvendingen før klagen bare er rotårsaken omtrent halvparten av tiden.

Animasjonspipelinen vår kartlegger årsak og virkning systematisk i hver brukerresponsøkt. Annotatoren sjekker først for et manglende krav eller en hensikt som støttes av tidligere kontekst. Tre LLM-dommere identifiserer deretter de ansvarlige vendingene, og krever at minst to er enige om en gitt vending. Noen ganger etablerer en tidligere uttalelse kravet eksplisitt. I andre tilfeller gjør ingen enkeltstående tidligere uttalelse det, men flere deler av den foregående samtalen gjør i fellesskap den tiltenkte atferden utledbar. Dette designet lar dem koble en klage til en tidligere rotfeil i stedet for å tilskrive den utelukkende det siste svaret.

Før pipelinen aksepterer et hint, sjekker den også at dets korrigerende påstander følger fra informasjon som var tilgjengelig før den merkede vendingen. Disse sjekkene har som mål å redusere etterpåklokskapskjevhet, der en ny preferanse som avdekkes i klagen, behandles som noe modellen burde ha visst fra før.

I dette eksemplet forteller hintet modellen å søke etter W-3-oversendelsesskjemaet på Paychex i stedet for W-2, eller spørre hvilket skjema brukeren mener hvis forespørselen er tvetydig. Korreksjonen retter seg mot den tidligere tolkningen og søkebeslutningen, ikke bare det endelige svaret. Den opprinnelige vendingen forblir uendret; annoteringen legger til is_bad_turn: true og et ikke-tomt hint.

En W-3-forespørsel mistolkes som W-2; en senere klage spores tilbake til den tidligere søkebeslutningen og sjekkes mot tidligere bevis. — En ekte økt som viser hvordan en klage spores tilbake til en tidligere feil, med anvisningsprosedyren lagt oppå. Brukeren spurde etter "w3" på Paychex, men modellen behandlet det som en skrivefeil for W-2 og søkte etter feil skjema. Forslagsstiller-konsensus lokaliserer rotårsaken, mens to forankringssjekker vurderer om beviset erdatert før feilen og hintets påstander følger fra informasjon som var tilgjengelig på det tidspunktet. Aksepterte annoteringer bevarer den opprinnelige teksten og legger til merker og hint, i stedet for omskrevne mål.

Tenk på en annen økt i verktøyfeilgruppen med et søkeoppkall der agenten søker med recency_filter: "year", men verktøyet avviser det fordi de tillatte verdiene er "day", "week" eller "month". Dette er et tydelig brudd på skjemaet.

Verktøyfeil-stien bruker deterministiske regler for kjente feil og modellskjønn for tvetydige tilfeller. En feilmelding alene er heller ikke nok til å skylde på modellen; en bedømt korreksjon må peke på noe modellen kunne ha visst fra verktøyskjemaet, systeminstruksjonene eller tidligere samtale.

Et søkeoppkall bruker den ugyldige recency_filter-verdien year; et begrunnet hint instruerer modellen til å bruke en oppført verdi eller utelate et valGFRitt felt. — Rapportens ugyldige søkeargument illustrerer den gjeldende verktøyfeilprosedyren. Skjemaet gjør denne feilen unngåelig; et strømbrudd alene ville ikke gjort det. Det opprinnelige kallet blir værende i posten og mottar et begrunnet hint. Hintet tillater en oppført verdi eller utelatelse hvis feltet er valGFRitt; det krever ikke "month" for hver forespørsel.

Her navngir hintet det mislykkede kallet, inkluderer valideringsfeilen, og instruerer modellen til å bruke en tillatt verdi eller utelate feltet hvis det er valGFRitt.

Når en tur er merket, kjører treneren det samme kontrollpunktet to ganger: én gang som læreren og én gang som eleven. Læreren ser hintet; eleven gjør det ikke.

Begge gjennomgangene bruker lærerpåtvinning, der vi mater modellen med den innspilte økten i stedet for å la den velge nye token. Framovergjennomgangen produserer fremdeles en full neste-token-distribusjon ved hvert trinn, men den er alltid betinget av det faste prefikset fra opptaket, ikke av utrullingstoken.

For søkeeksemplet tilordner den samme modellen mye høyere sannsynlighet til "month" og mindre til "year" når den får hintet. Trening bruker denne distribusjonsskiftet som et mykt mål.

Den samme modellen scorer en logget vending med og uten et hint; frakoblede lærersannsynligheter leverer KL-mål mens CE forankrer imitasjon. — To gjennomganger, ett sett med vekter. Begge gjennomgangene scorer den loggede fortsettelsen; bare læreren mottar hint. Dens frakoblede neste-token-sannsynligheter veileder eleven gjennom framover-KL. Separate CE-mål forankrer imitasjon. Begge tapene mater én vektoppdatering. Tidligere hint kan forbli i lærerens gjeldende segment; ingen av gjennomgangene genererer et erstatningssvar for trening.

Lærerens spådommer er frakoblet, eller stopp-gradient: de leverer et mål, men mottar ikke en oppdatering gjennom lærerpasset. Etter elevens pass oppdaterer ett optimaliseringstrinn den delte modellen.

CE-tap behandler de innspilte tokenene som er valgt for imitasjon, som fasitsmål og straffer modellen for å tilordne dem lave sannsynligheter. Dette skaper et hardt imitasjonsmål.

Ved tokenposisjon $i$ , la $p_i(v)$ være elevens sannsynlighet for token $v$ i det fulle vokabularet $V$ . Det innspilte neste tokenet i svaret eller verktøykallet er $y_i$ , den one-hot-måldistribusjonen er $r_i$ .

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

Kryssentropi måler hvor godt eleven forutsier det innspilte tokenet. Med et one-hot-mål reduseres det til den negative log-sannsynligheten tilordnet $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$ der tokenet skal imiteres og $0$ ellers. Summering over de valgte posisjonene gir imitasjonstapet.

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

KL-tap bruker i stedet lærerens fulle sannsynlighetsfordeling for neste token $q_i$ som et mykt korreksjonsmål. Lærerens kontekst inkluderer det gjeldende hintet og eventuelle tidligere hint som er beholdt i det treningssegmentet; elevens kontekst er alltid uten hint.

KL-masken $m_i^{\mathrm{KL}}$ er $1$ der tokenet skal korrigeres og $0$ ellers; CE- og KL-maskene overlapper ikke. Ved disse posisjonene straffer framover-KL uenighet mellom læreren og eleven på tvers av hele vokabularet:

\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 ledd deler én nevner i stedet for å bli normalisert separat. Denne nevneren teller de totale tokenene som er valgt for imitasjon på tvers av den globale treningsmiksen. Vekten $\lambda$ styrer bidraget fra korrigerende trening i forhold til imitasjon.

Denne delte normaliseringen passer til treningsinfrastrukturens grensesnitt med enkeltnevner og gjenoppretter standard SFT-tap når $\lambda=0$ , noe som forenkler sammenligninger med baselinjen. Fordi CE-tokene er mye mer tallrike enn KL-tokene, unngår man også ved bruk av en delt nevner å gi individuelle KL-tokene uforholdsmessig store vekter i mapper med få merkede token.

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

Anvendt på de tidligere eksemplene mottar vendingene som inneholder W-3/W-2-blandingen og det ugyldige søkeoppkall KL. Annet umerket assistentinnhold i en vellykket økt mottar fremdeles CE. Annet assistentinnhold i en mislykket økt beholde som kontekst, men mottar hverken CE eller KL.

Evalueringene våre besvarer to separate spørsmål. For det første: Hjelper et hint faktisk modellen med å rette opp en feil når hintet er til stede? For det andre: Hjelper trening modellen med å unngå den feilen senere, uten hintet? Det første tester om hint gir nyttige treningssignaler. Det andre tester om modellen lærer av dem.

Vi tester det første spørsmålet før treningskjøringene for å sikre at hint faktisk kan styre modellen bort fra feilene.

Vi regenererte merkede brukerrespons-vendinger med og uten et hint, ved bruk av den samme GLM-5.2-basismodellen ved temperatur null. En blind dommer ser den senere klagen, men hverken hintet eller hvilken tilstand som produserte svaret.

I W-3-eksemplet skifter hintet neste-token-sannsynligheten mot "3" og vekk fra "2" etter prefikset "W-".

Neste-token-sannsynligheter etter W- skifter mot 3 i stedet for 2 når den uendrede basismodellen mottar et hint. — Et hint bevarer den etterspurte W-3-formen. Stolper viser gjennomsnittlige neste-token-sannsynligheter på tvers av åtte framovergjennomganger; whiskers viser det observerte omfanget, ikke et konfidensintervall. Begge tilstandene bruker den uendrede basismodellen.

På et større hold-out-utvalg på 40 vendinger støttet av eksplisitt uttalte tidligere bevis, stiger andelen som vurderes som fiksede eller på sporet, fra 40,0 % uten hint til 75,0 % med et. På ytterligere 40 vendinger støttet av utledet hensikt stiger den fra 32,5 % til 80,0 %.

Hintvalidering: faste eller på-sporet-rater øker fra 40,0 % til 75,0 % for eksplisitt bevis og 32,5 % til 80,0 % for utledet hensikt. — Hintvalidering, ikke ettertreningsevaluering. De samme 40 merkede vendingene i hver bevisgruppe regenereres med og uten hint ved bruk av uendret GLM-5.2 ved temperatur null. Dommeren ser klagen, men ikke hintet eller tilstanden. Antall er utledet fra rapportens rater og utvalgsstørrelser; konfidensintervaller rapporteres ikke.

I eksemplet med verktøyfeil i søk flytter et hint faktisk sannsynlighetsmasse fra year-tokenet til month-tokenet.

Et hint skifter den uendrede basismodellens neste-token-sannsynligheter vekk fra year og mot den tillatte verdien month. — Et hint skifter sannsynligheten mot en tillatt verdi. Stolper viser gjennomsnittlige neste-token-sannsynligheter på tvers av åtte framovergjennomganger; whiskers viser det observerte omfanget, ikke et konfidensintervall. Begge tilstandene bruker den samme basismodellen; ingen trena sjekkpunkt sammenlignes.

På et større utvalg på 985 hold-out-vendinger regenererer vi hver vending fire ganger med og uten hint ved bruk av den samme basismodellen. En blind dommer evaluerer om hver regenerering unngår den opprinnelige feilen. Hint øker feilunngåelsen fra 75,1 % til 93,7 %, en parret økning på 18,6 prosentpoeng, og øker andelen som tar den korrigerte handlingen fra 60,6 % til 82,3 %. Gevinstene er størst på feil som gjentatt sampling alene sliter med å fikse.

På 985 hold-out-vendinger med merkede verktøyfeil øker hint feilunngåelse fra 75,1 % til 93,7 % og rater for korrigert handling fra 60,6 % til 82,3 %. — Validering av verktøyfeilhint på 985 hold-out-merkede vendinger, med fire regenereringer per tilstand. Stolper viser feilunngåelse og rater for korrigert handling for den uendrede basismodellen, med og uten hint. Å unngå den målrettede feilen etablerer ikke suksess for verktøykall eller oppgave.

Deretter tester vi om den trente modellen gjør færre feil uten å få hint. Vi evaluerer standardmodellen og ulike post-trente sjekkpunkter på offline benchmark-oppgaver og i live brukerøkter, og ser etter færre verktøyfeil og mindre brukerutilfredshet.

Den offlinen evalueringen bruker BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, eit representativt Computer-oppgavesett, og sjekker for ferdighetslasting, dokumentgjennomgang og innebygde siteringer. Vi måler andelen verktøykalv hvis resultater eksplisitt er flagget som feil på tvers av evalueringstrajektoriene.

I disse evalueringene var den innspilte verktøyfeilraten 2,79 % for standard GLM 5.2, 1,35 % for sjekkpunktet med bare RFT, og 0,87 % for et RFT-pluss-OPSD-sjekkpunkt. Disse sjekkpunktene ble trent på forskjellige data, så dette er ikke en matchet-dataablasjon av OPSD. Benchmarkresultater på oppgavenivå var blandede, så færre verktøyfeil alene betyr ikke nødvendigvis en bred forbedring i oppgavesuksess.

Innspilte offline-verktøyfeilrater: 2,79 % for standard GLM 5.2, 1,35 % for bare RFT, og 0,87 % for RFT pluss OPSD; treningsdata varierer. — Offline-verktøyfeilrater for standard GLM-5.2-, RFT-only- og RFT-plus-OPSD-sjekkpunkter. Treningsdataene varierer på tvers av sjekkpunkter; dette er ikke en kontrollert ablasjon.

For GLM-5.2 kjørte vi to separate A/B-tester med omtrent hundre tusen brukere i hver tilstand. I den første hadde et tidlig RFT-plus-OPSD-kontrollpunkt en litt lavere feilrate for verktøy enn standard GLM 5.2, 2,82 % mot 2,94 %, men forskjellen var ikke statistisk signifikant.

I den senere testen sammenlignede vi to RFT-pluss-OPSD-sjekkpunkter: et tidligere (sjekkpunkt én) og et senere (sjekkpunkt to). Verktøykallfeil falt fra 2,24 % til 1,77 % av kall med en innspilt status. Dette var en statistisk signifikant relativ reduksjon på 21,2 %. Vi sammenlignet ikke sjekkpunkt to direkte med standard GLM 5.2 online.

Resultatene for brukertilbakemeldinger var mindre konkluderende. I det andre GLM-5.2-eksperimentet var den gjennomsnittlige sannsynligheten for sterk misnøye (middels eller høy) på 2,58 % for kontrollpunkt én og 2,54 % for kontrollpunkt to, uten statistisk signifikant forskjell.

To separate online A/B-tester; bare den senere sjekkpunkt-sammenligningen har en betydelig reduksjon i verktøyfeil, uten signifikant endring i MID+-misnøye. — To separate GLM-5.2 live A/B-tester. Kontrollpunkt 1 sammenlignes med standard GLM-5.2; kontrollpunkt 2 sammenlignes med kontrollpunkt 1. I disse to testene er bare den senere reduksjonen i verktøyfeil statistisk signifikant. MID+-rater viser gjennomsnittlige estimerte sannsynligheter for middels eller høy misnøye, ikke antall klager.

For GLM-5.3 sammenlignet vi et ettertrenet sjekkpunkt direkte med standard GLM-5.3. Feil i verktøykall falt fra 3,56 % til 2,38 % av kall med registrert status, en relativ reduksjon på 33,04 %. MID+-raten, som er gjennomsnittlig anslått sannsynlighet for middels eller høy misnøye, falt fra 4,12 % til 3,41 %, en relativ reduksjon på 17,2 %. Begge reduksjonene var statistisk signifikante.

A/B-test for GLM-5.3: Feilraten for verktøy faller fra 3,56 % til 2,38 %, og MID+-raten (gjennomsnittlig anslått sannsynlighet for middels eller høy misnøye) faller fra 4,12 % til 3,41 %. CUPED-justerte relative reduksjoner er henholdsvis 33,04 % og 17,16 %. Begge sekvensielle 95 %-intervaller utelukker null; den primære engasjementsmetrikken er ikke signifikant. — Ettertrenet GLM-5.3 versus standard GLM-5.3 i en separat online A/B-test. Feilrate for verktøy og MID+-rater, relative endringer og sekvensielle 95 %-konfidensintervaller bruker CUPED-justering. Begge reduksjonene er statistisk signifikante. MID+-rater viser gjennomsnittlige anslåtte sannsynligheter for middels eller høy misnøye over kvalifiserte poengsatte oppfølgingstråder, ikke antall klager. Feilrater for verktøy utelukker kall uten registrert suksess- eller feilstatus.

Den sentrale ideen er å lære på nivå med beslutningen, ikke bare økten.

Et vellykket utfall kan skjule feil, og en mislykket økt kan fremdeles avsløre hvordan man kan forbedre seg. Vi beholder nyttig atferd fra vellykkede økter som et anker, bruker klager og verktøyfeil til å identifisere unngåelige feil, og trener modellen mot forutsigelsene den gjør når disse feilene og korreksjonene gjøres eksplisitte. Suksess gir atferd å bevare; feil gir retning for forbedring.

Bruk i den virkelige verden gjør denne tilnærmingen spesielt nyttig. Virkelige brukere bringer med seg mål, begrensninger og arbeidsflyter som er vanskelige å forutse i et syntetisk miljø. Korreksjonene deres avslører krav som modellen gikk glipp av, mens verktøyfeil avdekker gap mellom det modellen forsøkte, og det miljøet tillater. Disse signalene utfyller utfallsbasert trening: i stedet for å bare spørre om en oppgave lyktes, kan vi spørre hvor modellen gikk galt og hvilken informasjon som kunne ha hjulpet den til å ta en bedre beslutning.

Begrensningene er like viktige. Dommere kan ta feil, og å rette opp en tur garanterer ikke at hele oppgaven lykkes. Målet er ikke bare en agent som henter seg inn igjen etter en korrigering. Det er en agent som trenger korrigering sjeldnere.

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 trinnene, korriger de dårlige

Et eksempel: én økt kan lære bort begge lærdommene

Hvordan treningen fungerer

Velg økter, og vurder deretter utfallet

Finn feilene fra brukerrespons

Finn feilene fra verktøyfeil

To framovergjennomganger

Tapfunksjonen

CE-tapet

KL-tap

Kombinert tap

Hva evalueringene viser

Hint kan styre modellen bort fra feilene

Brukerrespons

Verktøyfeil

Verktøypålitelighet og brukertilbakemeldinger etter opplæring

Offline evaluering

Evaluering på nett: GLM-5.2

Online-evaluering: GLM-5.3

Konklusjon

Sitat