Leren van praktijkervaring

Een Perplexity Computer-model post-trainen om succesvol gedrag te imiteren, de behoefte aan gebruikerscorrecties te verminderen en tool-fouten te voorkomen.

AuteursPerplexity Research

Hoe gebruikers in de echte wereld met onze producten omgaan is een waardevolle bron voor modeltraining. De data is overvloedig, weerspiegelt de daadwerkelijke distributie van gebruikerstaken en legt correcties van gebruikers en tool-fouten vast die synthetische omgevingen mogelijk missen.

Een veelvoorkomende manier om te leren van real-world data is rejection sampling fine-tuning: beoordeel de uitkomst van elke sessie, behoud de succesvolle sessies en train het model om deze na te volgen. Maar een succesvolle uitkomst betekent niet dat elke stap correct was, dus het nabootsen van het hele traject brengt het risico met zich mee dat slechte tussenliggende gedragingen worden versterkt naast de goede. Het weggooien van onsuccesvolle sessies zorgt er bovendien voor dat cruciaal bewijs verloren gaat over waar het model tekortschiet.

We combineren fine-tuning op basis van rejection sampling met hint-geleide self-distillation om te leren van zowel succesvolle als niet-succesvolle sessies. Een hint is een korte correctieve instructie gebaseerd op informatie waarover het model al beschikte toen het de fout maakte. Nuttige stappen uit succesvolle sessies blijven imitatiekdoelen, terwijl gefundeerde hints vermijdbare fouten omzetten in correctiedoelen.

Gebruikerscorrecties en tool-fouten voegen supervisie toe over wat er onderweg misging, bovenop de vraag of de taak uiteindelijk is geslaagd. We passen deze fase toe na versterkend leren (reinforcement learning) in synthetische omgevingen om de kloof tussen die omgevingen en real-world gebruik te helpen overbruggen.

Bij live gebruik verminderde een later getraind GLM-5.2-controlepunt het aantal mislukte tool-aanroepen met 21,2% ten opzichte van een eerder getraind controlepunt. Voor GLM-5.3 verminderde post-training het aantal mislukte tool-aanroepen met 33,0% en de gemiddelde geschatte kans op middelmatige tot hoge ontevredenheid bij gebruikers met 17,2% ten opzichte van het standaardmodel.

Van synthetische naar real-world data

Synthetische taken stellen ons in staat gecontroleerde problemen te creëren met uitkomsten die eenvoudig te verifiëren zijn, maar ze zijn meestal beperkt tot één enkele prompt en kunnen alleen de scenario's dekken die we expliciet ontwerpen.

Daarentegen brengen gebruikers in real-world sessies uiteenlopende instructies, context en tool-combinaties in sessies die zich ontvouwen over meerdere interactiebeurten. Dergelijk real-world gebruik levert op natuurlijke wijze twee waardevolle signalen van fouten op: gebruikerscorrecties onthullen waar de agent niet leverde wat ze wilden, en tool-fouten tonen waar de acties in de soep liepen in echte omgevingen. Onze steekproefpipeline respecteert de privacy en trainingskeuzes van gebruikers door sessies met persoonlijk identificeerbare informatie (PII) uit te sluiten, evenals sessies van gebruikers die zich hebben afgemeld.

Real-world data levert ons daarom gevallen van fouten op die een synthetische omgeving mogelijk niet blootlegt, en bevat vaak al ingebakken waar de fout zich heeft voorgedaan.

Nakoers de goede stappen na, corrigeer de slechte

Bij training op real-world data selecteert standaard rejection sampling fine-tuning (RFT) succesvolle sessies op basis van hun uiteindelijke uitkomsten, zonder expliciet gebruik te maken van gebruikers- en toolfeedback om goede tussenliggende acties te onderscheiden van slechte. Een agent kan herstellen van een slechte tool-aanroep of een fout corrigeren na gebruikersfeedback en aan het einde alsnog het juiste uitvoerproduct afleveren.

Het weggooien van mislukte sessies beperkt bovendien de sample-efficiëntie. Een sessie die nooit een goed resultaat bereikt, kan toch een duidelijke, vermijdbare fout aan het licht brengen als nuttig trainingssignaal.

We pakken deze beperkingen aan door twee beslissingen te scheiden: welke sessies gedrag bevatten dat het navolgen waard is, en welke beurten fouten bevatten die gecorrigeerd moeten worden. De datapipeline neemt deze beslissingen afzonderlijk en kent modelbeurten vervolgens een van de drie behandelingen toe:

  • Imiteer: niet-foutbeurten in succesvolle sessies ontvangen gewone Cross-Entropy (CE) loss, waardoor de waarschijnlijkheid van opgenomen tokens wordt verhoogd.
  • Correct: in zowel succesvolle als onsuccesvolle sessies ontvangen foutbeurten met een geldige hint een Kullback-Leibler (KL) divergence loss, waardoor het model wordt bewogen in de richting van de voorspellingen voor het volgende token die het doet wanneer het de hint ziet.
  • Behouden als context: beurten in onsuccesvolle sessies die een gevalideerde hint missen, en gemarkeerde slechte beurten zonder een gevalideerde hint in beide sessietypes, dienen als context maar ontvangen geen van beide loss.

Als gevolg hiervan kunnen succesvolle sessies zowel imitatie- als correctiedoelwitten leveren, terwijl onsuccesvolle sessies alleen correctiedoelwitten leveren. Alle resterende beurten, inclusief systeem-, gebruiker- en tool-output, blijven behouden als context.

Huidige sessierouting en masker voor assistentinhoud. Succesvolle sessies dragen imitatiedoelwitten bij; bewaarde feedbackrecords kunnen bijdragen aan gehintte correcties, zelfs wanneer de sessie onsuccesvol is. Overige inhoud blijft behouden als context. Onvolledige sessies worden uitgesloten. De niet-finale yield/stop-token CE-uitzondering is niet getekend, en dit diagram toont niet de mix die door een eerdere controlepunt werd gebruikt.

Het imitatiedeel maakt gebruik van de standaard RFT. Het correctieve deel maakt gebruik van On-Policy Self-Distillation (OPSD): hetzelfde model treedt op als leraar en leerling, waarbij de leraar bevoorrechte informatie krijgt. Hier is die bevoorrechte informatie een korte hint die een vermijdbare fout uitlegt. We trainen de leerling om overeen te komen met de voorspellingen voor het volgende token van de leraar zonder de hint te krijgen.

Beide onderdelen zijn belangrijk. Training met alleen correctie kan een kortere route blootleggen: leraar en leerling kunnen het met elkaar eens worden door de context te negeren in plaats van de correctie te leren. De CE-term verankert de training aan nuttig gedrag, wat helpt om overeenstemming die voortkomt uit het negeren van context te ontmoedigen.

De getrainde leerling wordt vervolgens een modeloptie in Computer. Verse sessies uit live gebruik passeren dezelfde geschiktheids- en privacyfilters voordat ze aan een volgende ronde van de trainingspipeline beginnen.

Een voorbeeld: één sessie kan beide lessen leren

Vervolgens doorlopen we een concreet voorbeeld dat zowel imitatie als correctie bevat.

Beschouw een uiteindelijke succesvolle sessie waarin de gebruiker vraagt om een vergelijking van asyncio-wijzigingen in Python 3.13 met behulp van de officiële documentatie. Onze tooldocumentatie vermeldt dat search.web een lijst met treffers retourneert, elk met een url-veld.

Het model voert eerst een geldige zoekopdracht uit voor één versie als onderdeel van het verzamelen van bewijs voor de vergelijking, wat goed gedrag is om na te volgen.

De daaropvolgende aanroep voor code-uitvoering behandelt die lijst echter ten onrechte als een woordenboek. De codetool retourneert TypeError: list indices must be integers or slices, not str. Omdat het returntype vóór de aanroep was gedocumenteerd, is dit een fout die het model had moeten kunnen vermijden. Er kan een hint met de juiste aanroep worden gegenereerd om die actie te corrigeren.

Een illustratieve codeersessie toont drie trainingsrollen: invoer die alleen uit context bestaat en tool-outputs (grijs), CE-imitatie van nuttige opgenomen aanroepen (donker), en KL-correctie van een gemarkeerde fout (teal). Hier behandelt het model een lijst met zoektreffers ten onrechte als een woordenboek; een hint die alleen afkomstig is van de leraar en die is gebaseerd op eerdere tooldocumentatie, begeleidt de correctie. CE-doelwitten zijn alleen van toepassing wanneer de voltooiing van de sessie als succesvol wordt beoordeeld, terwijl een onsuccesvolle sessie nog steeds een in aanmerking komend KL-correctiedoelwit kan leveren.

Hoe de training werkt

De trainingspipeline kent vier fasen: selecteer sessies en beoordeel hun uitkomsten, identificeer fouten en creëer hints op basis van gebruikersfeedback en tool-fouten, genereer waarschijnlijkheden voor het volgende token van zowel de leraar als de leerling, en train het model met een gecombineerde CE- en KL-loss.

Selecteer sessies en beoordeel vervolgens de uitkomst

Het sampling-pijplijn haalt uit een trainingsgeschikte subset van echte Computer-sessies die worden bediend door GLM 5.2. Afmeldingen voor training en de op PII gebaseerde uitsluitingen van de pijplijn worden toegepast voordat voorbeelden voor deze workflow worden geselecteerd.

Het initiële screeningsproces selecteert kandidaten die door een LLM-jury zijn beoordeeld met een 4 of 5 op een taakmoeilijkheidsschaal van vijf punten en deelt deze op in 2 groepen:

  • De gebruikersfeedbackgroep bevat sessies met een echt vervolg van de gebruiker of een markering voor middelmatige tot hoge ontevredenheid. We vinden deze vervolgacties met een hoge intentie bijzonder nuttig om van te leren: gebruikers proberen actief een taak te voltooien, en hun correcties wijzen precies aan wat het model heeft gemist.
  • De tool-foutengroep bevat sessies met mislukte aanroepen die zijn gemarkeerd door op regels gebaseerde controles, met uitzondering van erkende infrastructurele storingen en geweigerde autorisatie.

Twee LLM-juryleden beoordelen vervolgens de uiteindelijke oplevering aan de hand van het verzoek van de gebruiker; beide juryleden moeten een positief oordeel geven om de sessie als "succesvol" te bestempelen. Voor gevallen waarin artefacten worden opgeleverd, kan de uitkomstfase de oplevering reconstrueren en inspecteren, waarbij wordt teruggevallen op op tekst gebaseerde oordelen als die fase mislukt. Sessies die als onvolledig worden geclassificeerd, zoals werk dat wacht op de gebruiker, worden uitgesloten.

Deze stap identificeert mogelijke bronnen van leerinformatie; niet elke fout is echter toe te schrijven aan het model, aangezien sommige voortkomen uit ambigue instructies of infrastructurele storingen. Latere annotatie bepaalt welke kandidaat-fouten daadwerkelijk vermijdbaar en geschikt zijn om op te trainen.

Vind de fouten uit gebruikersfeedback

Beschouw een voorbeeldsessie in de gebruikersfeedbackgroep, waarin de gebruiker vraagt: "How do I find my w3 on paychex". Het model behandelt "w3" als een typo voor W-2, zoekt naar instructies voor W-2 en legt uit hoe dat formulier te vinden is. Het vervolg van de gebruiker, "I meant the W-3 transmittal form," wijst de fout aan, zelfs als de sessie uiteindelijk slaagt.

De klacht helpt de fout te lokaliseren, maar de hoofdoorzaak is de eerdere beslissing om "w3" te herinterpreteren als W-2. Het oorspronkelijke verzoek maakt de fout vermijdbaar: het model had W-3 kunnen behouden of om verduidelijking kunnen vragen. Het blijkt dat de laatste assistentbeurt vóór de klacht slechts ongeveer de helft van de keren de hoofdoorzaak is.

Onze annotatiepipeline brengt oorzaak en gevolg systematisch in kaart binnen elke gebruikersfeedbacksessie. De annotator screent eerst op een gemist vereiste of een intentie die wordt ondersteund door eerdere context. Drie LLM-juryleden identificeren vervolgens de verantwoordelijke beurten, waarbij ten minste twee het over een bepaalde beurt eens moeten zijn. Soms stelt een eerdere uitspraak het vereiste expliciet vast. In andere gevallen doet geen enkel eerdere uitspraak dit afzonderlijk, maar zorgen meerdere delen van het voorafgaande gesprek er gezamenlijk voor dat het beoogde gedrag kan worden afgeleid. Dankzij dit ontwerp kunnen ze een klacht koppelen aan een eerdere hoofdfout in plaats de klacht uitsluitend toe te schrijven aan het laatste antwoord.

Voordat de pipeline een hint accepteert, controleert deze ook of de correctieve beweringen voortvloeien uit informatie die beschikbaar was vóór de gemarkeerde beurt. Deze controles zijn bedoeld om achteraf-vooroordelen (hindsight bias) te verminderen, waarbij een nieuwe voorkeur die in de klacht wordt onthuld, wordt behandeld als iets dat het model al had moeten weten.

In dit voorbeeld vertelt de hint het model om te zoeken naar het W-3-transmissieformulier op Paychex in plaats van W-2, of te vragen welk formulier de gebruiker bedoelt als het verzoek ambigue is. De correctie richt zich op de eerdere interpretatie en zoekbeslissing, niet alleen op het uiteindelijke antwoord. De oorspronkelijke beurt blijft ongewijzigd; de annotatie voegt is_bad_turn: true en een niet-lege hint toe.

Een echte sessie die laat zien hoe een klacht wordt herleid tot een eerdere fout, waarbij de annotatieprocedure is aangebracht. De gebruiker vroeg om "w3" op Paychex, maar het model behandelde dit als een typefout voor W-2 en zocht naar het verkeerde formulier. Consensus van de voorsteller lokaliseert de hoofdoorzaak, terwijl twee grondingstoetsen beoordelen of het bewijs van vóór de fout dateert en of de claims van de hint voortvloeien uit informatie die op dat moment beschikbaar was. Geaccepteerde annotaties behouden de oorspronkelijke tekst en voegen markeringen en hints toe, in plaats van herschreven doelwitten.

Vind de fouten uit tool-fouten

Beschouw een andere sessie in de tool-foutengroep met een zoekaanroep waarbij de agent zoekt met recency_filter: "year", maar de tool dit afwijst omdat de toegestane waarden “day”, “week” of “month” zijn. Dit is een duidelijke schending van het schema.

Het pad voor tool-fouten gebruikt deterministische regels voor bekende fouten en modeloordeel voor ambigue gevallen. Alleen een foutmelding is bovendien niet genoeg om het model de schuld te geven; een beoordeelde correctie moet wijzen op iets dat het model had kunnen weten uit het toolschema, de systeeminstructies of een eerdere conversatie.

Het ongeldige zoekargument in het rapport illustreert de huidige procedure voor tool-fouten. Het schema maakt deze fout vermijdbaar; een storing op zich zou dat niet doen. De oorspronkelijke aanroep blijft in het record staan en krijgt een onderbouwde hint. De hint staat een vermelde waarde of omissie toe als het veld optioneel is; het vereist niet voor elk verzoek "month".

Hier benoemt de hint de mislukte aanroep, bevat deze de validatiefout en instrueert deze het model om een toegestane waarde te gebruiken of het veld weg te laten als dit optioneel is.

Twee voorwaartse passes

Zodra een beurt is gemarkeerd, voert de trainer hetzelfde checkpoint twee keer uit: een keer als de leraar en een keer als de student. De leraar ziet de hint; de student niet.

Beide passes maken gebruik van teacher forcing, waarbij we het model voeden met de opgenomen sessie in plaats van het zelf nieuwe tokens te laten kiezen. De voorwaartse pass produceert nog steeds een volledige verdeling van het volgende token bij elke stap, maar deze is altijd geconditioneerd op het vaste voorvoegsel uit de opname, niet op rollout-tokens.

Voor het zoekvoorbeeld kent hetzelfde model een veel hogere waarschijnlijkheid toe aan "month" en minder aan "year" wanneer de hint wordt meegegeven. De training gebruikt deze distributionele verschuiving als een zacht doelwit.

Twee passes, één set gewichten. Beide passes scoren de gelogde voortzetting; alleen de leraar ontvangt hints. De losgekoppelde waarschijnlijkheden voor het volgende token van de leraar begeleiden de leerling via forward KL. Afzonderlijke CE-doelwitten verankeren de imitatie. Beide losses voeden één gewichtsupdate. Eerdere hints kunnen in het huidige segment van de leraar achterblijven; geen van beide passes genereert een vervangend trainingsantwoord.

De voorspellingen van de leraar zijn losgekoppeld, ofwel stop-gradient: ze leveren een doel op, maar ontvangen geen update via de lerarenpass. Na de pass van de leerling werkt één optimizerstap het gedeelde model bij.

De loss-functie

De CE-loss

CE loss behandelt de opgenomen tokens die zijn geselecteerd voor imitatie als grondwaarheid-doelwitten (ground-truth targets) en bestraft het model voor het toekennen van lage waarschijnlijkheden aan deze tokens. Dit creëert een hard imitatiedoelwit.

Laat op tokenpositie ii, pi(v)p_i(v) de waarschijnlijkheid van de leerling zijn voor token vv in de volledige woordenschat VV. Het opgenomen volgende token in het antwoord of de tool-aanroep is yiy_i, de one-hot doelverdeling is rir_i.

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

Cross-entropie meet hoe goed de leerling dat opgenomen token voorspelt. Met een one-hot doelwit reduceert dit tot de negatieve log-waarschijnlijkheid die is toegekend aan 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)

Het CE-masker miCEm_i^{\mathrm{CE}} is 11 waar het token moet worden nagevolgd en 00 in alle andere gevallen. Optellen over de geselecteerde posities levert de imitatie-loss op.

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

KL loss

KL loss gebruikt in plaats daarvan de volledige waarschijnlijkheidsverdeling van de leraar voor het volgende token qiq_i als zacht correctiedoelwit. De context van de leraar omvat de huidige hint en eventuele eerdere hints die in dat trainingssegment zijn bewaard; de context van de leerling is altijd hintvrij.

Het KL-masker miKLm_i^{\mathrm{KL}} is 11 waar het token moet worden gecorrigeerd en 00 in alle andere gevallen; de CE- en KL-maskers overlappen elkaar niet. Op deze posities bestraft forward KL onenigheid tussen de leraar en leerling over de volledige woordenschat:

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

Gecombineerde loss

Beide termen delen één noemer in plaats van afzonderlijk te worden genormaliseerd. Deze noemer telt het totale aantal tokens dat is geselecteerd voor imitatie in de globale trainingsbatch. Het gewicht λ\lambda beheerst de bijdrage van correctieve training ten opzichte van imitatie.

Deze gedeelde normalisatie past bij de interface met één noemer van onze trainingsinfrastructuur en herstelt de standaard SFT-loss wanneer λ=0\lambda=0, wat baselinevergelijkingen vereenvoudigt. Omdat CE-tokens veel overvloediger zijn dan KL-tokens, voorkomt het gebruik van een gedeelde noemer ook dat individuele KL-tokens onevenredig grote gewichten krijgen in batches met weinig gemarkeerde tokens.

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

Toegepast op de eerdere voorbeelden ontvangen de beurten met de W-3/W-2-verwarring en de ongeldige zoekaanroep KL. Andere ongemarkeerde assistentinhoud in een succesvolle sessie ontvangt nog steeds CE. Andere assistentinhoud in een onsuccesvolle sessie wordt bewaard als context, maar ontvangt noch CE noch KL.

Wat de evaluaties laten zien

Onze evaluaties beantwoorden twee afzonderlijke vragen. Ten eerste: helpt een hint het model daadwerkelijk om een fout te corrigeren wanneer de hint aanwezig is? Ten tweede: helpt training het model om die fout later te vermijden, zonder de hint? De eerste test of hints nuttige trainingssignalen opleveren. De tweede test of het model ervan leert.

Hints kunnen het model wegleiden van de fouten

We testen de eerste vraag voorafgaand aan de training om te controleren of hints het model inderdaad kunnen wegleiden van de fouten.

Gebruikersfeedback

We hebben gemarkeerde beurten met gebruikersfeedback opnieuw gegenereerd met en zonder hint, met behulp van hetzelfde GLM-5.2-basismodel bij temperatuur nul. Een blinde jury ziet de latere klacht, maar noch de hint noch de conditie die het antwoord heeft geproduceerd.

In het W-3-voorbeeld verschuift de hint de waarschijnlijkheid van het volgende token naar "3" en weg van "2" na het voorvoegsel "W-".

Een hint behoudt het gevraagde W-3-formulier. Staven tonen de gemiddelde waarschijnlijkheden voor het volgende token over acht voorwaartse passes; snorharen tonen het waargenomen bereik, geen betrouwbaarheidsinterval. Beide condities gebruiken het ongewijzigde basismodel.

Op een grotere afgezonderde steekproef van 40 beurten ondersteund door expliciet vermeld eerder bewijs, stijgt het aandeel dat als opgelost of op koers wordt beoordeeld van 40,0% zonder hint naar 75,0% met een hint. Op nog eens 40 beurten ondersteund door afgeleide intentie stijgt dit van 32,5% naar 80,0%.

Hint-validatie, geen evaluatie na de training. Dezelfde 40 gemarkeerde beurten in elke bewijsgroep worden opnieuw gegenereerd met en zonder hint met behulp van ongewijzigde GLM-5.2 bij temperatuur nul. De jury ziet de klacht, maar niet de hint of conditie. Aantallen zijn afgeleid van de percentages en steekproefgroottes in het rapport; betrouwbaarheidsintervallen worden niet gerapporteerd.

Tool-fouten

In het voorbeeld van de tool-fout verschuift een hint inderdaad de waarschijnlijkheidsmassa van het token year naar het token month.

Een hint verschuift de waarschijnlijkheid richting een toegestane waarde. Staven tonen de gemiddelde waarschijnlijkheden voor het volgende token over acht voorwaartse passes; snorharen (whiskers) tonen het waargenomen bereik, geen betrouwbaarheidsinterval. Beide condities gebruiken hetzelfde basismodel; er wordt geen getraind controlepunt vergeleken.

Op een grotere afgezonderde steekproef van 985 beurten regenereren we elke beurt vier keer met en zonder hint met behulp van hetzelfde basismodel. Een blinde jury beoordeelt of elke regeneratie de oorspronkelijke fout vermijdt. Hints verhogen het vermijden van fouten van 75,1% naar 93,7%, een gepaarde winst van 18,6 procentpunten, en vergroten het aandeel dat de gecorrigeerde actie onderneemt van 60,6% naar 82,3%. De winst is het grootst bij fouten die alleen door herhaaldelijk samplen moeilijk te verhelpen zijn.

Validatie van tool-fijntheorie/hints op 985 afgezonderde gemarkeerde beurten, met vier regeneraties per conditie. Staven tonen het vermijden van fouten en de percentages gecorrigeerde acties voor het ongewijzigde basismodel, met en zonder hints. Het vermijden van de gerichte fout betekent niet dat de tool-aanroep of taak succesvol was.

Betrouwbaarheid van tools en gebruikersfeedback na training

We testen vervolgens of het getrainde model minder fouten maakt zonder hints te ontvangen. We evalueren het stockmodel en verschillende post-trained checkpoints op offline benchmarktaken en in live gebruikerssessies, waarbij we controleren op minder toolstoringen en minder ontevredenheid bij gebruikers.

Offline evaluatie

De offline evaluatie maakt gebruik van BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, een representatieve set Computer-taken, en controleert op skill-loading, documentbeoordeling en inline citaten. We meten het aandeel tool-aanroepen waarvan de resultaten expliciet als fouten worden gemarkeerd in de evaluatietrajecten.

In deze evaluaties was het opgenomen percentage tool-fouten 2,79% voor standaard GLM 5.2, 1,35% voor het alleen-RFT-controlepunt en 0,87% voor een RFT-plus-OPSD-controlepunt. Deze controlepunten zijn getraind op verschillende data, dus dit is geen ablatie van OPSD op gematchte data. De benchmarkresultaten op taakniveau waren wemeling van verschillen, dus minder tool-fouten op zich vertaalt zich niet noodzakelijkerwijs in brede verbetering van taaksucces.

Offline percentages tool-fouten voor standaard GLM-5.2, alleen-RFT en RFT-plus-OPSD-controlepunten. De trainingsdata verschilt per controlepunt; dit is geen gecontroleerde ablatie.

Online evaluatie: GLM-5.2

Voor GLM-5.2 voerden we twee afzonderlijke A/B-tests uit met ongeveer honderdduizend gebruikers in elke conditie. In de eerste had een vroeg RFT-plus-OPSD-checkpoint een iets lager percentage tool-fouten dan standaard GLM 5.2 (2,82% tegenover 2,94%), maar het verschil was niet statistisch significant.

In de latere test vergeleken we twee RFT-plus-OPSD-controlepunten: een eerdere (controlepunt één) en een latere (controlepunt twee). Fouten in tool-aanroepen daalden van 2,24% naar 1,77% van de aanroepen met een opgenomen status. Dit was een statistisch significante relatieve afname van 21,2%. We hebben controlepunt twee online niet direct vergeleken met de standaard GLM 5.2.

De resultaten van de gebruikersfeedback waren minder overtuigend. In het tweede GLM-5.2-experiment was de gemiddelde kans op sterke ontevredenheid (matig of hoog) 2,58% voor checkpoint één en 2,54% voor checkpoint twee, zonder statistisch significant verschil.

Twee afzonderlijke live GLM-5.2 A/B-tests. Checkpoint 1 wordt vergeleken met standaard GLM-5.2; checkpoint 2 wordt vergeleken met checkpoint 1. Binnen deze twee tests is alleen de latere reductie van tool-fouten statistisch significant. MID+-percentages zijn gemiddelde geschatte kansen op middelmatige of hoge ontevredenheid, geen aantallen klachten.

Online evaluatie: GLM-5.3

Voor GLM-5.3 vergeleken we een nagegetraind controlepunt direct met de standaard GLM-5.3. Het aantal mislukte tool-aanroepen daalde van 3,56% naar 2,38% van de aanroepen met een geregistreerde status, een relatieve daling van 33,04%. Het MID+-percentage, de gemiddelde geschatte kans op middelmatige of hoge ontevredenheid, daalde van 4,12% naar 3,41%, een relatieve daling van 17,2%. Beide dalingen waren statistisch significant.

Nagegetrainde GLM-5.3 versus standaard GLM-5.3 in een aparte online A/B-test. percentages mislukte tools en MID+, relatieve veranderingen en sequentiële betrouwbaarheidsintervallen van 95% maken gebruik van CUPED-correctie. Beide dalingen zijn statistisch significant. MID+-percentages zijn gemiddelde geschatte kansen op middelmatige of hoge ontevredenheid over in aanmerking komende gescoorde vervolgdraden, geen aantallen klachten. percentages mislukte tools sluiten aanroepen zonder geregistreerde geslaagde of mislukte status uit.

Conclusie

Het centrale idee is om te leren op het niveau van de beslissing, niet alleen van de sessie.

Een succesvolle uitkomst kan fouten verbergen, en een onsuccesvolle sessie kan alsnog onthullen hoe te verbeteren. We behouden nuttig gedrag uit succesvolle sessies als anker, gebruiken klachten en tool-fouten om vermijdbare mislukkingen te identificeren, en trainen het model in de richting van de voorspellingen die het doet wanneer die fouten en correcties expliciet worden gemaakt. Succes biedt gedrag om te behouden; mislukking biedt richting voor verbetering.

Real-world gebruik maakt deze benadering bijzonder nuttig. Echte gebruikers brengen doelen, beperkingen en workflows met zich mee die moeilijk te anticiperen zijn in een synthetische omgeving. Hun correcties onthullen vereisten die het model heeft gemist, terwijl tool-fouten hiaten blootleggen tussen wat het model probeerde en wat de omgeving toestaat. Deze signalen vormen een aanvulling op uitkomstgebaseerde training: in plaats van alleen te vragen of een taak is geslaagd, kunnen we vragen waar het model de mist in ging en welke informatie het had kunnen helpen een betere beslissing te nemen.

De limieten zijn even belangrijk. Beoordelaars kunnen zich vergissen en het corrigeren van één beurt garandeert niet dat de volledige taak slaagt. Het doel is niet enkel een agent die herstelt na een correctie. Het is een agent die minder vaak correcties nodig heeft.

Citaat

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