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.

FörfattarePerplexity Research

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.

Aktuell sessionsdirigering och masker för assistentinnehåll. Framgångsrika sessioner bidrar med imitationsmål; behållna feedbackposter kan bidra med ledtrådsförsedda korrigeringar även när sessionen misslyckas. Annat innehåll förblir som kontext. Ofullständiga sessioner utesluts. Det icke-slutliga CE-undantaget för yield/stop-token ritas inte ut, och detta diagram fastställer inte den blandning som användes av en tidigare kontrollpunkt.

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.

En illustrativ kodningssession visar tre träningsroller: enbart kontextinmatningar och verktygsutdata (grå), CE-imitation av användbara inspelade anrop (mörka), och KL-korrigering av ett markerat misstag (blågrön). Här behandlar modellen felaktigt en lista med sökträffar som en ordbok; en enbart-lärarledtråd grundad i tidigare verktygsdokumentation vägleder korrigeringen. CE-mål tillämpas enbart när den slutförda sessionen bedöms som framgångsrik, medan en misslyckad session fortfarande kan tillhandahålla ett berättigat KL-korrigeringsmål.

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.

En riktig session som visar hur ett klagomål spåras tillbaka till ett tidigare misstag, med annoteringsproceduren inlagd ovanpå. Användaren bad om ”w3” på Paychex, men modellen behandlade det som ett skrivfel för W-2 och sökte efter fel formulär. Förslagskonsensus lokaliserar rotorsaken, medan två grundningskontroller bedömer om bevisen föregår misstaget och om ledtrådens anspråk följer av information som var tillgänglig vid den tidpunkten. Accepterade annoteringar bevarar den ursprungliga texten och lägger till markeringar och ledtrådar i stället för omskrivna mål.

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.

Rapportens ogiltiga sökargument illustrerar den aktuella proceduren för verktygsfel. Schemat gör detta misstag undvikbart; en enskild nedcirkulation skulle inte göra det. Det ursprungliga anropet ligger kvar i posten och tilldelas en grundad ledtråd. Ledtråden tillåter ett listat värde eller utelämnande om fältet är valfritt; den kräver inte ”month” för varje begäran.

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.

Två pass, en uppsättning vikter. Båda passen poängsätter den loggade fortsättningen; endast läraren tar emot ledtrådar. Dess fristående sannolikheter för nästa token vägleder eleven genom framåtriktad KL. Separata CE-mål förankrar imitation. Båda förlusterna matar en viktuppdatering. Tidigare ledtrådar kan finnas kvar i lärarens aktuella segment; inget pass genererar ett ersättningsträningssvar.

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 ii, låt pi(v)p_i(v) vara elevens sannolikhet för token vv i hela vokabulären VV. Den inspelade nästa token i svaret eller verktygsanropet är yiy_i, och one-hot-målfördelningen är rir_i.

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

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 yiy_i.

H(ri,pi)=−∑v∈Vri(v)log⁡pi(v)=−log⁡pi(yi)H(r_i,p_i)=-\sum_{v\in V}r_i(v)\log p_i(v)=-\log p_i(y_i)

CE-masken miCEm_i^{\mathrm{CE}} är 11 där token ska imiteras och 00 annars. Summering över de valda positionerna ger imitationsförlusten.

LCE=∑imiCEH(ri,pi)\mathcal{L}_{\mathrm{CE}}=\sum_i m_i^{\mathrm{CE}}H(r_i,p_i)

KL-förlust

KL-förlust (loss) använder i stället lärarens fullständiga sannolikhetsfördelning för nästa token qiq_i 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 miKLm_i^{\mathrm{KL}} är 11 där token ska korrigeras och 00 annars; CE- och KL-maskerna överlappar inte. Vid dessa positioner straffar framåtriktad KL oenighet mellan läraren och eleven över hela vokabulären:

LKL=∑imiKLDKL(qi∥pi)=∑imiKL∑v∈Vqi(v)log⁡qi(v)pi(v)\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)}

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 λ\lambda 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 λ=0\lambda=0, 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.

L=LCE+λLKL∑imiCE\mathcal{L}=\frac{\mathcal{L}_{\mathrm{CE}}+\lambda\mathcal{L}_{\mathrm{KL}}}{\sum_i m_i^{\mathrm{CE}}}

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-”.

En ledtråd bevarar det begärda W-3-formuläret. Staplarna visar genomsnittliga sannolikheter för nästa token över åtta framåtgående passeringar; morrhåren visar det observerade intervallet, inte ett konfidensintervall. Båda tillstånden använder den oförändrade basmodellen.

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 %.

Ledtrådsvalidering, inte efterträningsutvärdering. Samma 40 markerade turer i varje bevisgrupp regenereras med och utan ledtråd med oförändrad GLM-5.2 vid temperatur noll. Domaren ser klagomålet men inte ledtråden eller tillståndet. Antalen härleds från rapportens frekvenser och urvalsstorlekar; konfidensintervall rapporteras inte.

Verktygsfel

I exemplet med verktygsfel för sökning flyttar en ledtråd faktiskt sannolikhetsmassa från token year till token month.

En ledtråd flyttar sannolikheten mot ett tillåtet värde. Staplarna visar genomsnittliga sannolikheter för nästa token över åtta framåtgående passeringar; morrhåren visar det observerade intervallet, inte ett konfidensintervall. Båda tillstånden använder samma basmodell; ingen tränad kontrollpunkt jämförs.

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.

Validering av verktygsfelledtrådar på 985 undanhållna markerade turer, med fyra regenereringar per tillstånd. Staplarna visar felundandragande och andelar korrigerade åtgärder för den oförändrade basmodellen, med och utan ledtrådar. Att undvika det avsedda misstaget innebär inte att verktygsanropet eller uppgiften lyckas.

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.

Verktygsfelfrekvenser offline för kontrollpunkter med lager-GLM-5.2, enbart RFT och RFT-plus-OPSD. Träningsdata skiljer sig åt mellan kontrollpunkterna; detta är inte en kontrollerad ablering.

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.

Två separata A/B-live-tester med GLM-5.2. Checkpoint 1 jämförs med standard-GLM-5.2; checkpoint 2 jämförs med checkpoint 1. Av dessa två tester är det endast den senare minskningen av verktygsfel som är statistiskt säkerställd. MID+-frekvenser är genomsnittliga uppskattade sannolikheter för medelhög eller hög missnöjdhet, inte antalet klagomål.

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.

Eftertränad GLM-5.3 jämfört med standard-GLM-5.3 i ett separat online-A/B-test. Verktygsfel- och MID+-frekvenser, relativa förändringar och 95-procentiga sekventiella konfidensintervall använder CUPED-justering. Båda minskningarna är statistiskt signifikanta. MID+-frekvenser är genomsnittliga uppskattade sannolikheter för medelhög eller hög missnöjdhet över berättigade poängsatta uppföljningstrådar, inte antal klagomål. Frekvenser för verktygsfel exkluderar anrop utan en registrerad framgångs- eller felstatus.

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

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}
}