Att lära sig av verklig erfarenhet
Efterträning av en Perplexity Computer-modell för att imitera framgångsrika beteenden, minska behovet av användarkorrigeringar och undvika verktygsfel.
Hur användare interagerar med våra produkter i den verkliga världen är en värdefull källa för modellträning. Data är rikliga, återspeglar den faktiska fördelningen av användaruppgifter och fångar upp användarkorrigeringar och verktygsfel som syntetiska miljöer kan missa.
Ett vanligt sätt att lära sig från verklig data är finjustering med avvisningssampeltagning: bedöm varje sessions resultat, behåll de framgångsrika och träna modellen att imitera dem. Men ett framgångsrikt resultat innebär inte att varje steg var korrekt, så att imitera hela banan riskerar att förstärka dåliga mellanliggande beteenden utöver de bra. Att kassera misslyckade sessioner förlorar också kritiska bevis för var modellen faller kort.
Vi kombinerar finjustering med avvisningssampeltagning (rejection sampling fine-tuning) och vinkonstyrd självdestillering för att lära oss av både lyckade och misslyckade sessioner. Ett vinkonslag är en kort korrigerande instruktion baserad på information som modellen redan hade när den gjorde misstaget. Användbara steg från lyckade sessioner förblir imitationsmål, medan grundade vinkonslag förvandlar undvikbara misstag till korrigeringsmål.
Användarkorrigeringar och verktygsfel lägger till handledning om vad som gick fel på vägen, ovanpå huruvida uppgiften i slutändan lyckades. Vi tillämpar detta steg efter förstärkningsinlärning i syntetiska miljöer för att hjälpa till att överbrygga klyftan mellan dessa miljöer och verklig användning.
Vid användning i realtid minskade en senare eftertränad GLM-5.2-kontrollpunkt verktygsanropsfelen med 21,2 % jämfört med en tidigare tränad kontrollpunkt. För GLM-5.3 minskade efterträningen verktygsanropsfelen med 33,0 % och den genomsnittliga uppskattade sannolikheten för medelhög eller hög användarmissnöjdhet med 17,2 % jämfört med standardmodellen.
Från syntetisk till verklig data
Syntetiska uppgifter låter oss skapa kontrollerade problem med resultat som är lätta att verifiera, men de är vanligen begränsade till en enda prompt och kan enbart täcka de scenarier som vi uttryckligen designar.
Däremot tar användare i verkliga sessioner med sig varierande instruktioner, kontext och verktygskombinationer till sessioner som utvecklas över flera interaktionsturer. Sådan verklig användning ger på naturlig väg två värdefulla felaktighetssignaler: användarkorrigeringar avslöjar var agenten misslyckades med att leverera det de ville ha, och verktygsfel visar var dess åtgärder bröt samman i verkliga miljöer. Vår samplingspipeline respekterar användarnas integritets- och träningsval genom att utesluta sessioner med personligt identifierbar information (PII) och från användare som har valt bort detta.
Verklig data ger oss därför felfall som en syntetisk miljö kanske inte exponerar, och levereras ofta med var felet inträffade redan inbyggt.
Imitera de bra stegen, korrigera de dåliga
Vid träning på verklig data väljer standardiserad rejection sampling fine-tuning (RFT) ut framgångsrika sessioner baserat på deras slutliga resultat, utan att uttryckligen använda användar- och verktygsfeedback för att skilja bra mellanliggande åtgärder från dåliga. En agent kan återhämta sig från ett dåligt verktygsanrop eller korrigera ett misstag efter användarfeedback och ändå leverera rätt utdata i slutet.
Att kassera misslyckade sessioner begränsar också proveffektiviteten. En session som aldrig når ett bra resultat kan ändå avslöja ett tydligt, undvikbart misstag som användbara träningssignaler.
Vi adresserar dessa begränsningar genom att separera två beslut: vilka sessioner som innehåller ett beteende som är värt att imitera, och vilka turer som innehåller misstag som är värda att korrigera. Datapipelinen fattar dessa beslut separat och tilldelar sedan modellturer en av tre behandlingar:
- Imitera: icke-felturer i framgångsrika sessioner erhåller vanlig Cross-Entropy (CE) loss (korsentropiförlust), vilket höjer sannolikheten för inspelade token.
- Korrigerande: i både framgångsrika och misslyckade sessioner får felturer med en giltig ledtråd en Kullback–Leibler (KL) divergence loss, vilket flyttar modellen mot de förutsägelser för nästa token som den gör när den ser ledtråden.
- Behåll som kontext: turer i misslyckade sessioner som saknar en validerad ledtråd, samt markerade dåliga turer utan en validerad ledtråd i vardera sessionstyp, fungerar som kontext men erhåller ingen av förlusterna.
Som ett resultat kan framgångsrika sessioner tillhandahålla både imitations- och korrigeringsmål, medan misslyckade sessioner enbart tillhandahåller korrigeringsmål. Alla återstående turer, inklusive system-, användar- och verktygsutdata, förblir som kontext.
Imitationsdelen använder standard-RFT. Den korrigerande delen använder On-Policy Self-Distillation (OPSD): samma modell fungerar som lärare och elev, där läraren förses med privilegierad information. Här är denna privilegierade information en kort ledtråd som förklarar ett undvikbart misstag. Vi tränar eleven att matcha lärarens förutsägelser för nästa token utan att få ledtråden i hand.
Båda delarna spelar roll. Endast korrigering-träning kan blottlägga en genväg: lärare och elev kan komma överens genom att ignorera kontext i stället för att lära sig korrigeringen. CE-termen förankrar träningen vid ett användbart beteende och hjälper till att motverka överenskommelser som kommer från att kontext ignoreras.
Den eftertränade eleven blir sedan ett modellalternativ i Computer. Färsk sessioner från live-användning passerar genom samma behörighets- och integritetsfilter innan de går in i en ny runda av träningspipeline.
Ett exempel: en session kan lära ut båda lektionerna
Därefter går vi igenom ett konkret exempel som innehåller både imitation och korrigering.
Betrakta en eventuell framgångsrik session där användaren ber om en jämförelse av asyncio-ändringar i Python 3.13 med hjälp av officiell dokumentation. Vår verktygsdokumentation anger att search.web returnerar en lista med träffar, var och en med ett url-fält.
Modellen kör först en giltig sökning efter en version som en del av att samla in bevis för jämförelsen, vilket är ett bra beteende att imitera.
Nästa anrop för kodexekvering behandlar dock felaktigt den listan som en ordbok. Kodverktyget returnerar TypeError: list indices must be integers or slices, not str. Eftersom returtypen dokumenterades före anropet är det ett misstag som modellen borde ha kunnat undvika. En ledtråd med rätt anrop kan genereras för att korrigera den åtgärden.
Hur träningen fungerar
Träningspipelinen har fyra steg: välj ut sessioner och bedöm deras resultat, identifiera misstag och skapa ledtrådar från användarfeedback och verktygsfel, generera sannolikheter för nästa token från både läraren och eleven, och träna modellen med en kombinerad CE- och KL-förlust.
Välj sessioner och bedöm sedan resultatet
Urvalsprocessen hämtar från en träningsberättigad delmängd av verkliga Computer-sessioner som levereras av GLM 5.2. Avhopp från träning och pipelinens PII-relaterade exkluderingar tillämpas innan exempel väljs för detta arbetsflöde.
Den inledande sållningsprocessen väljer ut kandidater som bedöms till 4 eller 5 på en femgradig svårighetsskala för uppgifter av en LLM-domare och delar in dem i 2 grupper:
- Gruppen för användarfeedback innehåller sessioner med en äkta användaruppföljning eller en flagga för medelhögt till högt missnöje. Vi finner dessa uppföljningar med hög avsikt särskilt användbara för inlärning: användare försöker aktivt slutföra en uppgift, och deras korrigeringar pekar exakt ut vad modellen missade.
- Gruppen för verktygsfel innehåller sessioner med misslyckade anrop som flaggats av regelbaserade kontroller, exklusive kända infrastrukturfel och nekad behörighet.
Två LLM-domare bedömer sedan det slutliga resultatet i förhållande till användarens begäran; båda domarna måste ge ett positivt utlåtande för att sessionen ska betecknas som ”framgångsrik”. För fall som levererar artefakter kan utfallsfasen rekonstruera och inspektera leveransen, och falla tillbaka på sina textbaserade bedömningar om den fasen misslyckas. Sessioner som klassificeras som ofullständiga, till exempel arbete som väntar på användaren, utesluts.
Detna steg identifierar potentiella källor till träningssignaler; alla fel kan dock inte tillskrivas modellen, eftersom vissa beror på tvetydiga instruktioner eller infrastrukturfel. Senare annotering avgör vilka kandidatmisstag som faktiskt är undvikbara och lämpliga för träning.
Hitta misstagen från användarfeedback
Betrakta ett exempel på en session i gruppen för användarfeedback, där användaren frågar: ”How do I find my w3 on paychex”. Modellen behandlar ”w3” som ett skrivfel för W-2, söker efter W-2-instruktioner och förklarar hur man hittar det formuläret. Användarens uppföljning, ”I meant the W-3 transmittal form,” identifierar misstaget, även om sessionen slutligen lyckas.
Klagomålet hjälper till att lokalisera misstaget, men rotorsaken är det tidigare beslutet att tolka om ”w3” som W-2. Den ursprungliga begäran gör misstaget undvikbart: modellen kunde ha bevarat W-3 eller bett om klargörande. Det visar sig att den sista assistentturen före klagomålet är rotorsaken endast ungefär hälften av gångerna.
Vår annoteringspipeline mappar orsak och verkan systematiskt inom varje session med användarfeedback. Annoteraren söker först igenom efter ett missat krav eller en avsikt som stöds av tidigare kontext. Tre LLM-domare identifierar sedan de ansvariga turerna, vilket kräver att minst två är överens om en givet tur. Ibland etablerar ett tidigare uttalande uttryckligen kravet. I andra fall gör inget enskilt tidigare uttalande det, men flera delar av den föregående konversationen gör gemensamt det avsedda beteendet härledbart. Denna design låter dem koppla ett klagomål till ett tidigare rotmisstag i stället för att enbart tillskriva det det sista svaret.
Innan en ledtråd accepteras kontrollerar pipelinen också att dess korrigerande anspråk följer av information som var tillgänglig före den markerade turen. Dessa kontroller är avsedda att minska efterklokhetsbias, där en ny preferens som avslöjas i klagomålet behandlas som något som modellen redan borde ha känt till.
I det här exemplet instruerar ledtråden modellen att söka efter W-3-överföringsformuläret på Paychex i stället för W-2, eller fråga vilket formulär användaren menar om begäran är tvetydig. Korrigeringen riktar in sig på den tidigare tolkningen och sökbeslutet, inte bara det slutliga svaret. Den ursprungliga turen förblir oförändrad; annoteringen lägger till is_bad_turn: true och en icke-tom hint.
Hitta misstagen från verktygsfel
Betrakta en annan session i verktygsfelsgruppen med ett sökanrop där agenten söker med recency_filter: "year", men verktyget avvisar det eftersom de tillåtna värdena är ”day”, ”week” eller ”month”. Detta är ett tydligt schemabrott.
Sökvägen för verktygsfel använder deterministiska regler för kända misstag och modellbedömning för tvetydiga fall. Ett felmeddelande ensamt räcker inte heller för att beskylla modellen; en bedömd korrigering måste peka på något som modellen kunde ha känt till från verktygsschemat, systeminstruktionerna eller den tidigare konversationen.
Här namnger ledtråden det misslyckade anropet, inkluderar valideringsfelet och instruerar modellen att använda ett tillåtet värde eller utelämna fältet om det är valfritt.
Två framåtgående passeringar
När en tur har markerats kör tränaren samma checkpoint två gånger: en gång som lärare och en gång som student. Läraren ser vinkonslaget; studenten gör det inte.
Båda passen använder teacher forcing, där vi matas modellen med den inspelade sessionen i stället för att låta den välja nya token. Den framåtgående passeringen producerar fortfarande en fullständig fördelning av nästa token vid varje steg, men den är alltid villkorad av det fasta prefixet från inspelningen, inte av rollout-token.
För sökexemplet tilldelar samma modell mycket högre sannolikhet till ”month” och mindre till ”year” när den får ledtråden. Träningen använder denna fördelningsförskjutning som ett mjukt mål.
Lärarens förutsägelser är fristående eller stop-gradient: de tillhandahåller ett mål men får ingen uppdatering via lärarpasset. Efter elevens pass uppdaterar ett optimeringssteg den delade modellen.
Förlustfunktionen
CE-förlusten
CE-förlust behandlar de inspelade token som valts för imitation som ”ground-truth”-mål och straffar modellen för att den tilldelar dem låga sannolikheter. Detta skapar ett hårt imitationsmål.
Vid tokenposition , låt vara elevens sannolikhet för token i hela vokabulären . Den inspelade nästa token i svaret eller verktygsanropet är , och one-hot-målfördelningen är .
Korsentropi mäter hur väl eleven förutsäger den inspelade token. Med ett one-hot-mål reduceras det till den negativa logaritmiska sannolikheten som tilldelats .
CE-masken är där token ska imiteras och annars. Summering över de valda positionerna ger imitationsförlusten.
KL-förlust
KL-förlust (loss) använder i stället lärarens fullständiga sannolikhetsfördelning för nästa token som ett mjukt korrigeringsmål. Lärarens kontext inkluderar den aktuella ledtråden och eventuella tidigare ledtrådar som behållits i det träningssegmentet; elevens kontext är alltid ledtrådsfri.
KL-masken är där token ska korrigeras och annars; CE- och KL-maskerna överlappar inte. Vid dessa positioner straffar framåtriktad KL oenighet mellan läraren och eleven över hela vokabulären:
Kombinerad förlust
Båda termerna delar en nämnare i stället för att normaliseras separat. Denna nämnare räknar det totala antalet token som valts ut för imitation över den globala träningsbatchen. Vikten styr bidraget från korrigerande träning i förhållande till imitation.
Denna delade normalisering passar vår träningsinfrastrukturs gränssnitt med en nämnare och återskapar standard-SFT-förlusten när , vilket förenklar baslinjejämförelser. Eftersom CE-token är mycket vanligare än KL-token undviker man dessutom genom att använda en delad nämnare att enskilda KL-token får oproportionerligt stora vikter i batcher med få markerade token.
Tillämpat på de tidigare exemplen får turerna som innehåller W-3/W-2-blandningen och det ogiltiga sökanropet KL. Annat omarkerat assistentinnehåll i en framgångsrik session får fortfarande CE. Annat assistentinnehåll i en misslyckad session behålls som kontext men erhåller varken CE eller KL.
Vad utvärderingarna visar
Våra utvärderingar besvarar två skilda frågor. För det första, hjälper en ledtråd faktiskt modellen att korrigera ett fel när ledtråden finns där? För det andra, hjälper träningen modellen att undvika det felet senare, utan ledtråden? Det första testar om ledtrådar tillhandahåller användbara träningssignaler. Det andra testar om modellen lärar sig av dem.
Ledtrådar kan styra bort modellen från misstagen
Vi testar den första frågan innan träningen körs för att säkerställa att ledtrådar faktiskt kan styra bort modellen från misstagen.
Användarfeedback
Vi genererade om markerade turer för användarfeedback med och utan ledtråd, med samma basmodell GLM-5.2 vid temperatur noll. En blind domare ser det senare klagomålet, men varken ledtråden eller vilket tillstånd som genererade svaret.
I W-3-exemplet flyttar ledtråden sannolikheten för nästa token mot ”3” och bort från ”2” efter prefixet ”W-”.
På ett större undanhållet urval om 40 turer som stöds av explicit uttryckta tidigare bevis, stiger andelen som bedöms som fixade eller på spåret från 40,0 % utan ledtråd till 75,0 % med en. På ytterligare 40 turer som stöds av härledd avsikt stiger den från 32,5 % till 80,0 %.
Verktygsfel
I exemplet med verktygsfel för sökning flyttar en ledtråd faktiskt sannolikhetsmassa från token year till token month.
På ett större undanhållet urval om 985 turer regenererar vi varje tur fyra gånger med och utan ledtråd med hjälp av samma basmodell vid temperatur noll. En blind domare utvärderar om varje regenerering undviker det ursprungliga felet. Ledtrådar höjer felundandragandet från 75,1 % till 93,7 %, en parad ökning med 18,6 procentenheter, och ökar andelen som utför den korrigerade åtgärden från 60,6 % till 82,3 %. Vinsterna är störst för fel som enbart upprepad sampling har svårt att åtgärda.
Verktygets tillförlitlighet och användarfeedback efter träning
Därefter testar vi om den tränade modellen gör färre misstag utan att få ledtrådar. Vi utvärderar standardmodellen och olika eftertränade checkpoints på offline-benchmarkuppgifter och i liveanvändarsessioner, med fokus på färre verktygsfel och mindre användarmissnöje.
Offlineutvärdering
Offlinedusvärderingen använder BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, en representativ Computer-uppgiftsuppsättning samt kontrollerar färdighetsladdning, dokumentgranskning och inline-citat. Vi mäter andelen verktygsanrop vars resultat uttryckligen flaggas som fel över utvärderingstjoar.
I dessa utvärderingar var den inspelade frekvensen för verktygsfel 2,79 % för lager-GLM-5.2, 1,35 % för kontrollpunkten med enbart RFT, och 0,87 % för en RFT-plus-OPSD-kontrollpunkt. Dessa kontrollpunkter tränades på olika data, så detta är inte en matchad datablering av OPSD. Uppgiftsnivåns riktmärkesresultat var blandade, så färre verktygsfel enbart leder inte nödvändigtvis till en bred förbättring av uppgiftsframgång.
Utvärdering online: GLM-5.2
För GLM-5.2 körde vi två separata A/B-tester med ungefär hundratusen användare i varje tillstånd. I det första hade en tidig RFT-plus-OPSD-checkpoint en något lägre frekvens av verktygsfel än standard-GLM 5.2, 2,82 % jämfört med 2,94 %, men skillnaden var inte statistiskt säkerställd.
I det senare testet jämförde vi två RFT-plus-OPSD-kontrollpunkter: en tidigare (kontrollpunkt ett) och en senare (kontrollpunkt två). Fel i verktygsanrop sjönk från 2,24 % till 1,77 % av anropen med en inspelad status. Detta var en statistiskt signifikant relativ minskning på 21,2 %. Vi jämförde inte kontrollpunkt två direkt med lager-GLM-5.2 online.
Resultaten för användarfeedback var mindre entydiga. I det andra GLM-5.2-experimentet var den genomsnittliga sannolikheten för stark missnöjdhet (medelhög eller hög) 2,58 % för checkpoint ett och 2,54 % för checkpoint två, utan någon statistiskt säkerställd skillnad.
Onlineutvärdering: GLM-5.3
För GLM-5.3 jämförde vi en eftertränad kontrollpunkt direkt med standard-GLM-5.3. Verktygsanropsfelen sjönk från 3,56 % till 2,38 % av anropen med en registrerad status, vilket är en relativ minskning med 33,04 %. MID+-frekvensen, den genomsnittliga uppskattade sannolikheten för medelhög eller hög missnöjdhet, sjönk från 4,12 % till 3,41 %, vilket är en relativ minskning med 17,2 %. Båda minskningarna var statistiskt signifikanta.
Slutsats
Den centrala tanken är att lära sig på beslutsnivå, inte bara på sessionsnivå.
Ett framgångsrikt resultat kan dölja misstag, och en misslyckad session kan ändå avslöja hur man förbättrar sig. Vi behåller ett användbart beteende från framgångsrika sessioner som ett ankare, använder klagomål och verktygsfel för att identifiera undvikbara fel och tränar modellen mot de förutsägelser den gör när dessa misstag och korrigeringar görs explicita. Framgång tillhandahåller beteende att bevara; misslyckande tillhandahåller riktning för förbättring.
Verklig användning gör detta tillvägagångssätt särskilt användbart. Verkliga användare har mål, begränsningar och arbetsflöden som är svåra att förutse i en syntetisk miljö. Deras korrigeringar avslöjar krav som modellen missade, medan verktygsfel blottlägger klyftor mellan vad modellen försökte göra och vad miljön tillåter. Dessa signifikanser kompletterar utfallsbaserad träning: i stället för att bara fråga om en uppgift lyckades kan vi fråga var modellen gick fel och vilken information som kunde ha hjälpt den att fatta ett bättre beslut.
Gränserna är lika viktiga. Domare kan ha fel, och att korrigera en tur garanterar inte att hela uppgiften lyckas. Målet är inte enbart en agent som återhämtar sig efter en korrigering. Det är en agent som behöver korrigering mer sällan.
Citering
@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}
}