Učení se ze zkušeností reálného světa

Způsob, jakým uživatelé interagují s našimi produkty v reálném světě, je cenným zdrojem pro trénink modelů. Data jsou hojná, odrážejí skutečné rozdělení uživatelských úkolů a zachycují uživatelské korekce a selhání nástrojů, které mohou syntetická prostředí minout.

Běžným způsobem, jak se učit z dat reálného světa, je doladění vzorkováním s odmítáním: posoudit výsledek každé relace, ponechat si úspěšné a trénovat model tak, aby je napodobil. Úspěšný výsledek však neznamená, že každý krok byl správný, takže napodobování celé trajektorie riskuje posílení špatných mezistupňů kromě těch dobrých. Zahození neúspěšných relací také ztrácí kritické důkazy o tom, kde model selhává.

Kombinujeme doladění vzorkováním odmítnutím se sebe-destilací řízenou nápovědou, abychom se učili z úspěšných i neúspěšných relací. Nápověda je krátká nápravná instrukce vycházející z informací, které model měl již v okamžiku, kdy udělal chybu. Užitečné kroky z úspěšných relací zůstávají cíli napodobování, zatímco podložené nápovědy mění odvrátitelné chyby v cíle nápravy.

Uživatelské korekce a chyby nástrojů přidávají dohled nad tím, co se během procesu pokazilo, nad rámec toho, zda úkol nakonec uspěl. Tuto fázi aplikujeme po posilovaném učení v syntetických prostředích, abychom pomohli uzavřít propast mezi těmito prostředími a použitím v reálném světě.

Při ostrém nasazení snížil pozdější dodatečně trénovaný kontrolní bod GLM-5.2 selhání volání nástrojů o 21,2 % oproti dřívějšímu trénovanému kontrolnímu bodu. U modelu GLM-5.3 snížilo dodatečné trénování selhání volání nástrojů o 33,0 % a průměrnou odhadovanou pravděpodobnost střední až vysoké nespokojenosti uživatelů o 17,2 % v porovnání s výchozím modelem.

Syntetické úkoly nám umožňují vytvořit kontrolované problémy s výsledky, které lze snadno ověřit, ale obvykle jsou omezeny na jeden prompt a mohou pokrýt pouze scénáře, které explicitně navrhneme.

Naproti tomu uživatelé v relacích v reálném světě přinášejí různorodé pokyny, kontext a kombinace nástrojů do relací, které se odvíjejí v průběhu mnoha interakčních kroků. Takové použití v reálném světě přirozeně přináší dva cenné signály chyb: uživatelské korekce odhalují, kde agent nedodal to, co chtěli, a chyby nástrojů ukazují, kde se jeho akce v reálném prostředí zhroutily. Naše vzorkovací pipeline respektuje soukromí uživatelů a jejich volby ohledně tréninku tím, že vylučuje relace s osobně identifikovatelnými informacemi (PII) a od uživatelů, kteří se odhlásili.

Data z reálného světa nám proto poskytují případy selhání, které syntetické prostředí nemusí odhalit, a často přicházejí s již zakomponovaným místem, kde k selhání došlo.

Při tréninku na datech z reálného světa vybírá standardní doladění vzorkováním s odmítáním (rejection sampling fine-tuning - RFT) úspěšné relace na základě jejich konečných výsledků, aniž by explicitně používalo zpětnou vazbu uživatelů a nástrojů k odlišení dobrých mezilehlých akcí od špatných. Agent se může zotavit z chybného volání nástroje nebo opravit chybu po uživatelské zpětné vazbě a přesto nakonec dodat správný výstup.

Zahození neúspěšných relací také omezuje efektivitu vzorků. Relace, která nikdy nedosáhne dobrého výsledku, může přesto odhalit jasnou a odstranitelnou chybu jako užitečný tréninkový signál.

Tato omezení řešíme oddělením dvou rozhodnutí: které relace obsahují chování, které stojí za to napodobit, a které kroky obsahují chyby, které stojí za to opravit. Datová pipeline tato rozhodnutí činí odděleně a poté modelovým krokům přiřazuje jedno ze tří ošetření:

Napodobit: kroky bez chyb v úspěšných relacích obdrží běžnou ztrátu křížové entropie (CE loss), čímž se zvýší pravděpodobnost zaznamenaných tokenů.
Správně: v úspěšných i neúspěšných relacích obdrží chybové kroky s platnou nápovědou ztrátu Kullbackovy–Leiblerovy (KL) divergence, což posouvá model směrem k předpovědím následujícího tokenu, které dělá, když nápovědu vidí.
Zachovat jako kontext: konverzační kroky v neúspěšných relacích, kterým chybí ověřená nápověda, a označené chybné kroky bez ověřené nápovědy v obou typech relací slouží jako kontext, ale nepřijímají žádnou ztrátu.

V důsledku toho mohou úspěšné relace poskytovat jak cíle napodobování, tak korekce, zatímco neúspěšné relace poskytují pouze cíle korekce. Všechny zbývající kroky, včetně systémového výstupu, výstupu uživatele a nástroje, zůstávají jako kontext.

Diagram směrování relací: úspěšné relace poskytují napodobování CE a způsobilé nápovědou opravené položky; neúspěšné relace poskytují pouze způsobilé korekce. — Aktuální směrování relací a masky obsahu asistenta. Úspěšné relace přispívají cíli napodobování; zachované záznamy zpětné vazby mohou přispívat nápovědou opravenými korekcemi, i když je relace neúspěšná. Ostatní obsah zůstává jako kontext. Neúplné relace jsou vyloučeny. Výjimka CE pro konečný výnos/zastavovací token není vykreslena a tento diagram nestanovuje směs použitou dřívějším kontrolním bodem.

Část napodobování používá standardní RFT. Korekční část používá On-Policy Self-Distillation (OPSD): stejný model funguje jako učitel i student, přičemž učitel má k dispozici privilegované informace. Zde jsou těmito privilegovanými informacemi krátká nápověda vysvětlující odstranitelnou chybu. Trénujeme studenta tak, aby odpovídal předpovědím učitele pro další token, aniž by mu byla předána nápověda.

Obě části jsou důležité. Trénink zaměřený pouze na korekci může odhalit zkratku: učitel a student se mohou shodnout na ignorování kontextu namísto naučení se korekci. Člen CE kotví trénink k užitečnému chování a pomáhá odrazovat od shody, která vyplývá z ignorování kontextu.

Trénovaný student se pak stane možností modelu v aplikaci Computer. Nové relace z živého provozu procházejí stejnými filtry způsobilosti a ochrany soukromí před vstupem do dalšího kola tréninkové pipeline.

Dále si projdeme konkrétní příklad, který obsahuje jak napodobování, tak korekci.

Zvažte případnou úspěšnou relaci, kde uživatel požaduje porovnání změn asyncio v Pythonu 3.13 pomocí oficiální dokumentace. Naše dokumentace nástrojů uvádí, že search.web vrací seznam výsledků (hits), z nichž každý má pole url.

Model nejprve spustí platné vyhledávání jedné verze jako součást shromažďování důkazů pro srovnání, což je dobré chování k napodobení.

Následné volání pro spuštění kódu však tento seznam nesprávně považuje za slovník. Nástroj kódu vrací TypeError: list indices must be integers or slices, not str. Jelikož byl návratový typ zdokumentován před voláním, jde o chybu, které měl být model schopen se vyhnout. K nápravě této akce lze vygenerovat nápovědu se správným voláním.

Ilustrativní relace kódování: vstup systému a uživatele a chyby nástrojů zůstávají kontextem; užitečná zaznamenaná volání vyhledávání a zotavení obdrží CE v úspěšné relaci; označené chybné vyhledávání v seznamu obdrží KL směrem k učiteli, kterému byla poskytnuta podložená nápověda. — Ilustrativní relace kódování ukazuje tři tréninkové role: vstupy a výstupy nástrojů pouze jako kontext (šedě), napodobování CE u užitečných zaznamenaných volání (tmavě) a korekce KL u označené chyby (tykysově). Zde model nesprávně považuje seznam výsledků vyhledávání za slovník; korekci vede nápověda pouze pro učitele, podložená dřívější dokumentací nástrojů. Cíle CE platí pouze tehdy, když je dokončená relace posouzena jako úspěšná, zatímco neúspěšná relace může stále poskytnout způsobilý cíl korekce KL.

Tréninková pipeline má čtyři fáze: výběr relací a posouzení jejich výsledků, identifikace chyb a vytváření nápověd ze zpětné vazby uživatelů a chyb nástrojů, generování pravděpodobností následujícího tokenu od učitele i studenta a trénink modelu s kombinovanou ztrátou CE a KL.

Vzorek do pipeline čerpá z podmnožiny relací Computer z reálného světa, které jsou způsobilé pro trénování a jsou obsluhovány modelem GLM 5.2. Odhlášení z trénování a vyloučení související s PII v rámci pipeline se uplatňují před výběrem příkladů pro tento pracovní postup.

Počáteční proces prověřování vybírá kandidáty ohodnocené známkou 4 nebo 5 na pětibodové stupnici obtížnosti úloh rozhodčím LLM a rozdělí je do 2 skupin:

Skupina uživatelské zpětné vazby obsahuje relace s opravdovou následnou akcí uživatele nebo příznakem střední až vysoké nespokojenosti. Tyto následné akce s vysokým záměrem shledáváme obzvláště užitečnými pro učení: uživatelé se aktivně snaží dokončit úkol a jejich korekce přesně ukazují, co model minul.
Skupina chyb nástrojů obsahuje relace s neúspěšnými voláními označenými kontrolami založenými na pravidlech, přičemž jsou vyloučena rozpoznaná selhání infrastruktury a zamítnutá autorizace.

Dva rozhodčí LLM poté vyhodnotí finální výsledek vzhledem k požadavku uživatele; oba rozhodčí musejí vrátit kladný verdikt, aby byla relace označena jako „úspěšná“. V případech, které přinášejí artefakty, může fáze výsledku rekonstruovat a zkontrolovat doručení a v případě selhání této fáze se vrátit k textovým hodnocením. Relace klasifikované jako neúplné, například práce čekající na uživatele, jsou vyloučeny.

Tento krok identifikuje potenciální zdroje tréninkových signálů; ne každá chyba je však připisitelná modelu, protože některé vyplývají z nejednoznačných pokynů nebo selhání infrastruktury. Pozdější anotace určuje, které kandidátské chyby jsou skutečně odstranitelné a vhodné pro trénink.

Zvažte ukázkovou relaci ve skupině uživatelské zpětné vazby, kde se uživatel ptá: „How do I find my w3 on paychex“. Model považuje „w3“ za překlep pro W-2, vyhledá pokyny pro W-2 a vysvětlí, jak tento formulář najít. Následná otázka uživatele „I meant the W-3 transmittal form,“ identifikuje chybu, i když relace nakonec uspěje.

Stížnost pomáhá lokalizovat chybu, ale hlavní příčinou je dřívější rozhodnutí reinterpretovat „w3“ jako W-2. Původní požadavek činí chybu odstranitelnou: model mohl zachovat W-3 nebo požádat o objasnění. Ukazuje se, že poslední krok asistenta před stížností je hlavní příčinou pouze zhruba v polovině případů.

Naše anotační pipeline mapuje příčinu a následek systematicky v rámci každé relace uživatelské zpětné vazby. Anotátor nejprve prověří zmeškaný požadavek nebo záměr podpořený dřívějším kontextem. Tři rozhodčí LLM poté identifikují odpovědné kroky, přičemž vyžadují, aby se na daném kroku shodli alespoň dva. Někdy dřívější prohlášení požadavek explicitně stanoví. V jiných případech tak neučiní žádné jedno předchozí prohlášení, ale více částí předcházející konverzace společně umožňuje odvodit zamýšlené chování. Tento návrh jim umožňuje spojit stížnost s dřívější hlavní chybou namísto jejího připisování výhradně poslední odpovědi.

Před přijetím nápovědy pipeline rovněž ověřuje, zda její korekční tvrzení vyplývají z informací dostupných před označeným krokem. Tyto kontroly mají za cíl omezit zkreslení zpětného pohledu (hindsight bias), kdy je nová preference odhalená ve stížnosti považována za něco, co měl model již znát.

V tomto příkladu nápověda říká modelu, aby vyhledal transakční formulář W-3 na Paychex namísto W-2, nebo aby se zeptal, který formulář má uživatel na mysli, pokud je požadavek nejednoznačný. Korekce cílí na dřívější interpretaci a rozhodnutí o vyhledávání, nejen na konečnou odpověď. Původní krok zůstává beze změny; anotace přidává is_bad_turn: true a neprázdný hint.

Požadavek na W-3 je nesprávně interpretován jako W-2; pozdější stížnost je vysledována k dřívějšímu rozhodnutí o vyhledávání a zkontrolována oproti dřívějším důkazům. — Reálná relace ukazuje, jak je stížnost vysledována zpět k dřívější chybě, s překrytým postupem anotace. Uživatel požádal o „w3“ na Paychex, ale model to považoval za překlep pro W-2 a vyhledal nesprávný formulář. Konsensus navrhovatelů lokalizuje hlavní příčinu, zatímco dvě kontroly podložení posuzují, zda důkazy předcházejí chybě a zda tvrzení nápovědy vyplývají z informací dostupných v daném okamžiku. Přijaté anotace zachovávají původní text a přidávají značky a nápovědy namísto přepsaných cílů.

Zvažte další relaci ve skupině chyb nástrojů s voláním vyhledávání, kde agent vyhledává s recency_filter: "year", ale nástroj to odmítne, protože povolené hodnoty jsou „day“, „week“ nebo „month“. Jde o jasné porušení schématu.

Cesta chyb nástrojů používá deterministická pravidla pro známé chyby a úsudek modelu pro nejednoznačné případy. Samotná chybová zpráva také nestačí k obvinění modelu; posouzená korekce musí poukazovat na něco, co mohl model vědět ze schématu nástroje, pokynů systému nebo dřívější konverzace.

Volání vyhledávání používá neplatnou hodnotu recency_filter year; podložená nápověda instruuje model, aby použil uvedenou hodnotu nebo vynechal volitelné pole. — Neplatný argument vyhledávání v zprávě ilustruje současný postup pro chyby nástrojů. Schéma činí tuto chybu odstranitelnou; samotný výpadek by to neudělal. Původní volání zůstává v záznamu a obdrží podloženou nápovědu. Nápověda umožňuje uvedenou hodnotu nebo vynechání, pokud je pole volitelné; nevyžaduje „month“ pro každý požadavek.

Zde nápověda pojmenovává neúspěšné volání, obsahuje validační chybu a instruuje model, aby použil povolenou hodnotu nebo vynechal pole, pokud je volitelné.

Jakmile je krok označen, trenér spustí stejný kontrolní bod dvakrát: jednou jako učitel a jednou jako student. Učitel vidí nápovědu; student ji nevidí.

Oba průchody používají vynucení učitelem (teacher forcing), kdy modelu namísto výběru nových tokenů předkládáme zaznamenanou relaci. Dopředný průchod stále vytváří úplné rozdělení následujícího tokenu v každém kroku, ale je vždy podmíněn pevnou předponou ze záznamu, nikoliv tokeny z průběhu generování.

V příkladu s vyhledáváním přiřadí stejný model při poskytnutí nápovědy mnohem vyšší pravděpodobnost slovu „month“ a menší slovu „year“. Trénink využívá tento distribuční posun jako měkký cíl.

Stejný model ohodnotí zaznamenaný krok s nápovědou a bez ní; pravděpodobnosti odděleného učitele poskytují cíle KL, zatímco CE kotví napodobování. — Dva průchody, jedna sada vah. Oba průchody hodnotí zaznamenané pokračování; nápovědy dostává pouze učitel. Jeho pravděpodobnosti následujícího tokenu v odděleném režimu vedou studenta prostřednictvím dopředné divergenci KL. Samostatné cíle CE kotví napodobování. Obě ztráty napájejí jednu aktualizaci vah. Dřívější nápovědy mohou zůstat v aktuálním segmentu učitele; žádný průchod nevytváří náhradní tréninkovou odpověď.

Předpovědi učitele jsou oddělené neboli stop-gradient: poskytují cíl, ale nepřijímají aktualizaci prostřednictvím průchodu učitele. Po průchodu studenta aktualizuje sdílený model jeden krok optimalizátoru.

Ztráta CE považuje zaznamenané tokeny vybrané pro napodobování za pravdivé cíle (ground-truth) a penalizuje model za přiřazení nízkých pravděpodobností. To vytváří pevný cíl napodobování.

Na pozici tokenu $i$ nechte $p_i(v)$ představovat pravděpodobnost studenta pro token $v$ v plné slovní zásobě $V$ . Zaznamenaný další token v odpovědi nebo volání nástroje je $y_i$ a jednohorková (one-hot) cílová distribuce je $r_i$ .

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

Křížová entropie měří, jak dobře student předpovídá daný zaznamenaný token. S jednohorkovým cílem se redukuje na zápornou logaritmickou pravděpodobnost přiřazenou k $y_i$ .

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

Maska CE $m_i^{\mathrm{CE}}$ je $1$ tam, kde by měl být token napodoben, a $0$ v opačném případě. Sečtením přes vybrané pozice získáme ztrátu napodobování.

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

Ztráta KL namísto toho používá úplné rozdělení pravděpodobnosti dalšího tokenu učitele $q_i$ jako měkký cíl pro korekci. Kontext učitele zahrnuje aktuální nápovědu a všechny dřívější nápovědy uchované v tomto tréninkovém segmentu; kontext studenta je vždy bez nápovědy.

Maska KL $m_i^{\mathrm{KL}}$ je $1$ tam, kde by měl být token opraven, a $0$ v opačném případě; masky CE a KL se nepřekrývají. Na těchto pozicích penalizuje dopředná divergence KL neshodu mezi učitelem a studentem napříč celou slovní zásobou:

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

Oba členy sdílejí jednoho jmenovatele namísto samostatné normalizace. Tento jmenovatel počítá celkový počet tokenů vybraných pro napodobování napříč globální tréninkovou dávkou. Váha $\lambda$ řídí příspěvek korekčního tréninku vzhledem k napodobování.

Tato sdílená normalizace odpovídá rozhraní s jedním jmenovatelem naší tréninkové infrastruktury a obnovuje standardní ztrátu SFT, když $\lambda=0$ , což zjednodušuje porovnání se základní linií. Protože tokeny CE jsou mnohem hojnější než tokeny KL, použití sdíleného jmenovatele také zabraňuje tomu, aby jednotlivé tokeny KL měly nepřiměřeně velkou váhu v dávkách s málo označenými tokeny.

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

Aplikováno na dřívější příklady, kroky obsahující záměnu W-3/W-2 a neplatné volání vyhledávání obdrží KL. Jiný neoznačený obsah asistenta v úspěšné relaci stále obdrží CE. Ostatní obsah asistenta v neúspěšné relaci je zachován jako kontext, ale neobdrží ani CE, ani KL.

Naše vyhodnocení odpovídají na dvě samostatné otázky. Za prvé, pomáhá nápověda modelu skutečně opravit chybu, když je nápověda přítomna? Za druhé, pomáhá trénink modelu vyhnout se této chybě později, a to i bez nápovědy? První testuje, zda nápovědy poskytují užitečné tréninkové signály. Druhá testuje, zda se z nich model učí.

Před spuštěním tréninku otestujeme první otázku, abychom se ujistili, že nápovědy dokážou model skutečně odklonit od chyb.

Regenerovali jsme označené kroky zpětné vazby uživatele s nápovědou i bez ní za použití stejného základního modelu GLM-5.2 při nulové teplotě. Zaslepený rozhodčí vidí pozdější stížnost, ale nikoliv nápovědu ani to, která podmínka odpověď vyprodukovala.

V příkladu W-3 posouvá nápověda pravděpodobnost dalšího tokenu směrem k „3“ a pryč od „2“ za předponou „W-“.

Pravděpodobnosti dalšího tokenu po W- se posouvají směrem k 3 namísto 2, když nezměněný základní model obdrží nápovědu. — Nápověda zachovává požadovaný formulář W-3. Sloupce ukazují průměrné pravděpodobnosti následujícího tokenu napříč osmi dopřednými průchody; vousy ukazují pozorovaný rozsah, nikoliv interval spolehlivosti. Obě podmínky používají nezměněný základní model.

Na větším vyhrazeném vzorku 40 kroků podloženém explicitně uvedenými dřívějšími důkazy stoupá podíl posouzený jako opravený nebo na správné cestě ze 40,0 % bez nápovědy na 75,0 % s ní. Na dalších 40 krocích podložených odvozeným záměrem stoupá z 32,5 % na 80,0 %.

Ověření nápovědy: míra opravených nebo správně směřujících případů se zvyšuje ze 40,0 % na 75,0 % u explicitních důkazů a z 32,5 % na 80,0 % u odvozeného záměru. — Ověření nápovědy, nikoliv vyhodnocení po tréninku. Těch istých 40 označených kroků v každé skupině důkazů je zregenerováno s nápovědou i bez ní pomocí nezměněného GLM-5.2 při nulové teplotě. Rozhodčí vidí stížnost, ale ne nápovědu nebo podmínku. Počty jsou odvozeny z měr zprávy a velikostí vzorků; intervaly spolehlivosti nejsou hlášeny.

V příkladu chyby vyhledávacího nástroje nápověda skutečně posouvá hmotnost pravděpodobnosti od tokenu year k tokenu month.

Nápověda posouvá pravděpodobnosti dalšího tokenu nezměněného základního modelu pryč od roku (year) a směrem k povolené hodnotě měsíce (month). — Nápověda posouvá pravděpodobnost směrem k povolené hodnotě. Sloupce ukazují průměrné pravděpodobnosti následujícího tokenu napříč osmi dopřednými průchody; vousy (whiskers) ukazují pozorovaný rozsah, nikoliv interval spolehlivosti. Obě podmínky používají stejný základní model; neporovnává se žádný trénovaný kontrolní bod.

Na větším vyhrazeném vzorku 985 kroků jsme každý krok čtyřikrát zregenerovali s nápovědou i bez ní za použití stejného základního modelu. Zaslepený rozhodčí vyhodnotí, zda každá regenerace odvrátila původní selhání. Nápovědy zvyšují odvrácení selhání ze 75,1 % na 93,7 %, což je párový nárůst o 18,6 procentního bodu, a zvyšují podíl provedení opravené akce z 60,6 % na 82,3 %. Zisky jsou největší u chyb, které samotné opakované vzorkování obtížně nápraví.

U 985 vyhrazených označených kroků chyb nástrojů zvyšují nápovědy odvrácení selhání ze 75,1 % na 93,7 % a míru opravených akcí z 60,6 % na 82,3 %. — Ověření nápovědy pro chyby nástrojů na 985 vyhrazených označených krocích se čtyřmi regeneracemi na podmínku. Sloupce ukazují míru odvrácení selhání a opravených akcí pro nezměněný základní model, s nápovědami a bez nich. Odvrácení cílené chyby nezaručuje úspěch volání nástroje ani úlohy.

Dále testujeme, zda trénovaný model dělá méně chyb bez přijímání nápověd. Vyhodnocujeme standardní model a různé kontrolní body po tréninku na offline benchmarkových úlohách a v živých uživatelských relacích a kontrolujeme menší počet selhání nástrojů a nižší nespokojenost uživatelů.

Offline vyhodnocení využívá BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, reprezentativní sadu úloh Computer a kontroluje načítání dovedností, kontrolu dokumentů a vložené citace. Měříme podíl volání nástrojů, jejichž výsledky jsou v evaluačních trajektoriích explicitně označeny jako chyby.

V těchto vyhodnoceních byla zaznamenaná chybovost nástrojů 2,79 % pro standardní GLM 5.2, 1,35 % pro kontrolní bod pouze s RFT a 0,87 % pro kontrolní bod RFT-plus-OPSD. Tyto kontrolní body byly trénovány na různých datech, takže se nejedná o ablační test OPSD s párovanými daty. Výsledky benchmarků na úrovni úloh byly smíšené, takže méně chyb nástrojů samo o sobě nutně nevede k širšímu zlepšení úspěšnosti úloh.

Míry offline zaznamenaných chyb nástrojů: 2,79 % pro standardní GLM 5.2, 1,35 % pro samotné RFT a 0,87 % pro RFT plus OPSD; tréninková data se liší. — Míry offline chyb nástrojů pro kontrolní body standardního GLM-5.2, pouze RFT a RFT-plus-OPSD. Tréninková data se napříč kontrolními body liší; nejedná se o ablační test s párovanými daty.

Pro GLM-5.2 jsme provedli dva samostatné A/B testy s přibližně sto tisíci uživateli v každé podmínce. V prvním měl raný kontrolní bod RFT-plus-OPSD o něco nižší chybovost nástrojů než standardní GLM-5.2 (2,82 % oproti 2,94 %), ale rozdíl nebyl statisticky významný.

V pozdějším testu jsme porovnali dva kontrolní body RFT-plus-OPSD: dřívější (kontrolní bod jedna) a pozdější (kontrolní bod dva). Selhání volání nástrojů klesla z 2,24 % na 1,77 % volání se zaznamenaným stavem. Jednalo se o statisticky významné relativní snížení o 21,2 %. Kontrolní bod dva jsme online přímo neporovnávali se standardním GLM 5.2.

Výsledky uživatelské zpětné vazby byly méně jednoznačné. Ve druhém experimentu s GLM-5.2 byla průměrná pravděpodobnost silné nespokojenosti (střední nebo vysoké) 2,58 % u prvního kontrolního bodu a 2,54 % u druhého kontrolního bodu, přičemž rozdíl nebyl statisticky významný.

Dva samostatné online A/B testy; pouze pozdější porovnání kontrolních bodů vykazuje významné snížení selhání nástrojů, přičemž nedošlo k žádné významné změně nespokojenosti MID+. — Dva samostatné živé A/B testy modelu GLM-5.2. Kontrolní bod 1 je porovnán se standardním GLM-5.2; kontrolní bod 2 je porovnán s kontrolním bodem 1. V rámci těchto dvou testů je statisticky významné pouze pozdější snížení selhání nástrojů. Míry MID+ představují průměrné odhadované pravděpodobnosti střední nebo vysoké nespokojenosti, nikoli počty stížností.

U modelu GLM-5.3 jsme porovnali dodatečně trénovaný kontrolní bod přímo s výchozím modelem GLM-5.3. Selhání volání nástrojů klesla z 3,56 % na 2,38 % volání se zaznamenaným stavem, což představuje relativní snížení o 33,04 %. Míra MID+, tedy průměrná odhadovaná pravděpodobnost střední či vysoké nespokojenosti, klesla ze 4,12 % na 3,41 %, což představuje relativní snížení o 17,2 %. Obě snížení byla statisticky významná.

A/B test GLM-5.3: míra selhání nástrojů klesá z 3,56 % na 2,38 % a míra MID+, průměrná odhadovaná pravděpodobnost střední či vysoké nespokojenosti, klesá ze 4,12 % na 3,41 %. Relativní snížení upravená metodou CUPED činí 33,04 %, resp. 17,16 %. Oba 95% sekvenční intervaly vylučují nulu; primární metrika zapojení není významná. — Dodatečně trénovaný GLM-5.3 oproti výchozímu GLM-5.3 v samostatném online A/B testu. Míry selhání nástrojů a MID+, relativní změny a 95% sekvenční intervaly spolehlivosti využívají úpravu CUPED. Obě snížení jsou statisticky významná. Míry MID+ představují průměrné odhadované pravděpodobnosti střední či vysoké nespokojenosti v rámci oprávněných hodnocených navazujících vláken, nikoliv počty stížností. Míry selhání nástrojů nezahrnují volání bez zaznamenaného stavu úspěchu či neúspěchu.

Centrální myšlenkou je učit se na úrovni rozhodnutí, nejen relace.

Úspěšný výsledek může skrývat chyby a neúspěšná relace může stále odhalit, jak se zlepšit. Užitečné chování z úspěšných relací uchováváme jako kotvu, stížnosti a chyby nástrojů používáme k identifikaci odstranitelných selhání a trénujeme model směrem k předpovědím, které činí, když jsou tyto chyby a korekce učiněny explicitními. Úspěch poskytuje chování, které je třeba zachovat; selhání poskytuje směr pro zlepšení.

Použití v reálném světě činí tento přístup obzvláště užitečným. Skuteční uživatelé přinášejí cíle, omezení a pracovní postupy, které je v syntetickém prostředí obtížné předvídat. Jejich korekce odhalují požadavky, které model minul, zatímco chyby nástrojů odhalují mezery mezi tím, o co se model pokusil, a tím, co prostředí umožňuje. Tyto signály doplňují trénink založený na výsledcích: namísto pouhé otázky, zda úkol uspěl, se můžeme zeptat, kde model udělal chybu a jaké informace mu mohly pomoci učinit lepší rozhodnutí.

Omezení jsou stejně důležitá. Hodnotitelé se mohou mýlit a oprava jednoho kroku nezaručuje úspěch celého úkolu. Cílem není pouze agent, který se po opravě zotaví. Cílem je agent, který potřebuje opravy méně často.

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

Od syntetických dat k datům z reálného světa

Napodobujte dobré kroky, opravte ty špatné

Příklad: jedna relace může naučit obě lekce

Jak trénink funguje

Vyberte relace a poté posuďte výsledek

Nalezení chyb z uživatelské zpětné vazby

Nalezení chyb z chyb nástrojů

Dva dopředné průchody

Ztrátová funkce

Ztráta CE

Ztráta KL

Kombinovaná ztráta

Co ukazují vyhodnocení

Nápovědy mohou model odklonit od chyb

Zpětná vazba od uživatele

Chyby nástrojů

Spolehlivost nástrojů a zpětná vazba od uživatelů po tréninku

Offline vyhodnocení

Online vyhodnocení: GLM-5.2

Online vyhodnocení: GLM-5.3

Závěr

Citace