Tanulás a valós világ tapasztalataiból

Egy Perplexity Computer modell utólagos betanítása a sikeres viselkedés imitálására, a felhasználói javítások szükségességének csökkentésére és az eszközhibák elkerülésére.

SzerzőkPerplexity Research

Az, hogy a felhasználók hogyan lépnek kapcsolatba termékeinkkel a valós világban, értékes forrás a modell tanításához. Az adatok bőségesek, tükrözik a felhasználói feladatok tényleges eloszlását, és rögzítik a felhasználói korrekciókat és eszközhibákat, amelyeket a szintetikus környezetek kihagyhatnak.

A valós adatokból való tanulás gyakori módja az elutasításos mintavételes finomhangolás: az egyes munkamenetek kimenetének elbírálása, a sikeresek megtartása, és a modell tanítása ezek imitálására. De a sikeres eredmény nem jelenti azt, hogy minden lépés helyes volt, így a teljes pálya imitálása kockáztatja a rossz közbenső viselkedések megerősítését a jók mellett. A sikertelen munkamenetek eldobása szintén elveszíti a kritikus bizonyítékokat arról, hogy hol vall kudarcot a modell.

A visszautasítási mintavételen alapuló finomhangolást tippalapú ön-desztillációval kombináljuk, hogy a sikeres és sikertelen munkamenetekből egyaránt tanulhassunk. A tipp egy rövid korrekciós utasítás, amely olyan információkon alapul, amelyekkel a modell már a hiba elkövetésekor is rendelkezett. A sikeres munkamenetek hasznos lépései továbbra is imitációs célok maradnak, míg a megalapozott tippek a elkerülhető hibákat korrekciós célokká alakítják.

A felhasználói korrekciók és az eszközhibák további felügyeletet biztosítanak arról, hogy mi romlott el menet közben, a feladat végső sikerességén túl. Ezt a szakaszt a szintetikus környezetben végzett megerősítéses tanulás után alkalmazzuk, hogy segítsünk áthidalni a szakadékot ezen környezetek és a valós használat között.

Éles használatban egy későbbi, utótanított GLM-5.2 ellenőrzőpont 21,2%-kal csökkentette az eszközhívási hibák számát egy korábban betanított ellenőrzőponthoz képest. A GLM-5.3 esetében az utótanítás 33,0%-kal csökkentette az eszközhívási hibákat, és 17,2%-kal az alaptípushoz képest a közepes vagy magas szintű felhasználói elégedetlenség átlagos becsült valószínűségét.

A szintetikus adatoktól a valós adatokig

A szintetikus feladatok lehetővé teszik számunkra, hogy ellenőrzött problémákat hozzunk létre könnyen ellenőrizhető eredményekkel, de ezek általában egyetlen promptra korlátozódnak, és csak az általunk kifejezetten megtervezett forgatókönyveket fedhetik le.

Ezzel szemben a valós munkamenetekben a felhasználók változatos utasításokat, kontextust és eszköz-kombinációkat hoznak olyan munkamenetekbe, amelyek a interakció több fordulóján keresztül bontakoznak ki. Az ilyen valós használat természetesen a hibák két értékes jelét eredményezi: a felhasználói korrekciók feltárják, hol nem sikerült az ügynöknek azt nyújtania, amit akartak, az eszközhibák pedig azt mutatják, hol omlottak össze a műveletei valós környezetben. Mintavételi folyamatunk tiszteletben tartja a felhasználók adatvédelmét és tanítási választásait azáltal, hogy kizárja a személyes azonosításra alkalmas adatokat (PII) tartalmazó munkameneteket, valamint a leiratkozott felhasználók munkameneteit.

A valós adatok ezért olyan hibaeseteket adnak, amelyeket a szintetikus környezet talán nem fed fel, és gyakran már eleve tartalmazzák a hiba helyét.

Imitáljuk a jó lépéseket, javítsuk ki a rosszakat

Valós adatokon való tanításkor a szabványos elutasításos mintavételes finomhangolás (RFT) a végső kimenetük alapján választja ki a sikeres munkameneteket anélkül, hogy kifejezetten a felhasználói és eszközvisszajelzéseket használná a jó közbenső műveletek rosszak megkülönböztetésére. Előfordulhat, hogy egy ügynök helyreáll egy rossz eszközhívásból, vagy kijavít egy hibát a felhasználói visszajelzés után, és a végén mégis a megfelelő kimenetet szolgáltatja.

A sikertelen munkamenetek eldobása a mintahatékonyságot is korlátozza. Egy olyan munkamenet, amely soha nem ér el jó eredményt, még felfedhet egyértelmű, elkerülhető hibát hasznos tanítási jelzésként.

Ezeket a korlátokat úgy hidaljuk át, hogy szétválasztunk két döntést: mely munkamenetek tartalmaznak utánzásra érdemes viselkedést, és mely fordulók tartalmaznak kijavításra érdemes hibákat. Az adatsorozat külön-külön hozza meg ezeket a döntéseket, majd a modellfordulókhoz a három kezelés egyikét rendeli hozzá:

  • Imitálás: a sikeres munkamenetek nem hibás fordulói a szokásos keresztentrópia-veszteséget (CE) kapják, növelve a rögzített tokenek valószínűségét.
  • Helyes: a sikeres és sikertelen munkamenetekben egyaránt az érvényes tippel rendelkező hibafordulók Kullback–Leibler-divergencia-veszteséget (KL) kapnak, elmozdítva a modellt a következő token előrejelzések felé, amelyeket akkor tesz, amikor meglátja a tippet.
  • Megőrzés kontextusként: a sikertelen munkamenetek érvényesített tipp nélküli fordulói, valamint a megjelölt rossz fordulók érvényesített tipp nélkül bármilyen munkamenettípusban kontextusként szolgálnak, de egyik veszteséget sem kapják meg.

Ennek eredményeként a sikeres munkamenetek imitációs és korrekciós célokat is biztosíthatnak, míg a sikertelen munkamenetek csak korrekciós célokat. Az összes többi forduló, beleértve a rendszer-, a felhasználói és az eszközkimenetet is, kontextusként marad.

Aktuális munkamenet-útválasztás és asszisztens-tartalom maszkok. A sikeres munkamenetek imitációs célokkal járulnak hozzá; a megőrzött visszajelzési rekordok tippelt korrekciókkal járulhatnak hozzá még akkor is, ha a munkamenet sikertelen. A többi tartalom kontextusként marad. A nem teljes munkamenetek ki vannak zárva. A nem végső hozam-/stop-token CE kivétel nincs rajzolva, és ez a diagram nem állapítja meg a korábbi ellenőrzőpont által használt keveréket.

Az imitációs rész a szabványos RFT-t használja. A korrekciós rész On-Policy Self-Distillation (OPSD) módszert alkalmaz: ugyanaz a modell működik tanárként és diákként, a tanár pedig kiemelt információkat kap. Ebben az esetben ez a kiemelt információ egy rövid tipp, amely egy elkerülhető hibát magyaráz el. Megtanítjuk a diákot, hogy illeszkedjen a tanár következő token előrejelzéseihez anélkül, hogy a kezébe adnánk a tippet.

Mindkét rész számít. A kizárólag korrekciós tanítás felfedhet egy rövidebb utat: a tanár és a diák megállapodhat a kontextus figyelmen kívül hagyásával ahelyett, hogy megtanulná a korrekciót. A CE-tag a hasznos viselkedéshez köti a tanítást, és segít visszatartani a kontextus figyelmen kívül hagyásából eredő egyetértést.

A tanított diák ezután modellopcióvá válik a Computerben. Az élő használatból származó friss munkamenetek áthaladnak ugyanolyan jogosultsági és adatvédelmi szűrőkön, mielőtt belépnének a tanítási folyamat újabb körébe.

Példa: egyetlen munkamenet mindkét leckét megtaníthatja

Ezután végigmegyünk egy konkrét példán, amely imitációt és korrekciót is tartalmaz.

Vegyünk egy végül sikeres munkamenetet, ahol a felhasználó a Python 3.13-as verziójának asyncio változtatásairól kér összehasonlítást a hivatalos dokumentáció felhasználásával. Eszközdokumentációnk kijelenti, hogy a search.web találatok listáját adja vissza, amelyek mindegyike rendelkezik url mezővel.

A modell először érvényes keresést futtat az egyik verzióra az összehasonlításhoz szükséges bizonyítékok gyűjtésének részeként, ami egy imitálásra érdemes jó viselkedés.

A következő kódvégrehajtási hívás azonban helytelenül szótárként kezeli ezt a listát. A kódeszköz a következőt adja vissza: TypeError: list indices must be integers or slices, not str. Mivel a visszatérési típus a hívás előtt dokumentálva lett, ez olyan hiba, amelyet a modellnek el kellett volna tudnia kerülni. Generálható egy helyes hívást tartalmazó tipp ezen művelet kijavításához.

Egy szemléltető kódolási munkamenet három tanítási szerepet mutat be: csak kontextust tartalmazó bemenetek és eszközbemenetek (szürke), a hasznos rögzített hívások CE-imitációja (sötét) és egy megjelölt hiba KL-korrekciója (kékeszöld). Itt a modell helytelenül szótárként kezeli a keresési találatok listáját; a korábbi eszközdokumentáción alapuló, kizárólag tanári tipp vezérli a korrekciót. A CE-célok csak akkor érvényesülnek, ha a befejezett munkamenet sikeresnek minősül, míg egy sikertelen munkamenet továbbra is biztosíthat jogosult KL-korrekciós célt.

Hogyan működik a tanítás

A tanítási folyamat négy szakaszból áll: munkamenetek kiválasztása és kimenetük elbírálása, hibák azonosítása és tippek készítése a felhasználói visszajelzésekből és eszközhibákból, következő token valószínűségek generálása a tanártól és a diáktól egyaránt, valamint a modell tanítása kombinált CE- és KL-veszteséggel.

Válasszon munkamenetet, majd bírálja el az eredményt

A mintavételi pipeline a GLM 5.2 által kiszolgált valós Computer munkamenetek tanításra alkalmas részhalmazából dolgozik. A tanításból való kizárások és a pipeline PII-hez kapcsolódó kizárásai az általunk kiválasztott példák előtt érvényesülnek ennél a munkafolyamatnál.

A kezdeti szűrési folyamat az LLM bíráló által egy ötpontos feladatnehézségi skálán 4-es vagy 5-ös értékelésű jelölteket választja ki, és 2 csoportra osztja őket:

  • A felhasználói visszajelzési csoport olyan munkameneteket tartalmaz, amelyekben valódi felhasználói utókövetés vagy közepes vagy magas elégedetlenség jelző szerepel. Ezeket a magas szándékú utókövetéseket különösen hasznosnak találjuk a tanuláshoz: a felhasználók aktívan próbálnak befejezni egy feladatot, és a korrekcióik pontosan megjelölik, amit a modell kihagyott.
  • Az eszközhiba-csoport olyan munkameneteket tartalmaz, amelyekben a szabályalapú ellenőrzések által megjelölt sikertelen hívások szerepelnek, kizárva az elismert infrastrukturális hibákat és a visszautasított engedélyeket.

Két LLM bíráló ezután értékeli a végső eredményt a felhasználó kérése alapján; mindkét bírálónak pozitív ítéletet kell hoznia ahhoz, hogy a munkamenet „sikeresnek” legyen minősítve. Műtermékeket szolgáltató esetekben az eredményszakasz képes rekonstruálni és ellenőrizni a teljesítést, és hiba esetén visszatér a szöveges alapú értékelésekhez. A nem teljesként besorolt ​​munkamenetek, például a felhasználóra váró munkamenetek ki vannak zárva.

Ez a lépés azonosítja a tanítási jelek lehetséges forrásait; azonban nem minden hiba tulajdonítható a modellnek, mivel néhány kétértelmű utasításokból vagy infrastrukturális hibákból adódik. A későbbi annotáció határozza meg, hogy mely lehetséges hibák valóban elkerülhetők és alkalmasak a tanításra.

Keressük meg a hibákat a felhasználói visszajelzésekből

Vegyünk egy mintamunkamenetet a felhasználói visszajelzések csoportjából, ahol a felhasználó így kérdez: „Hogyan találom meg a w3-at a paychexben”. A „w3”-at a W-2 elírásának tekinti, W-2 utasításokra keres, és elmagyarázza, hogyan találja meg azt az űrlapot. A felhasználó utókövetése: „A W-3 átviteli űrlapra gondoltam,” azonosítja a hibát, még akkor is, ha a munkamenet végül sikeres lesz.

A panasz segít meghatározni a hiba helyét, de a kiváltó ok a „w3” W-2-ként való újraértelmezésének korábbi döntése. Az eredeti kérés elkerülhetővé teszi a hibát: a modell megőrizhette volna a W-3-at, vagy tisztázást kérhetett volna. Kiderült, hogy a panasz előtti utolsó asszisztens-forduló csak az esetek körülbelül felében a gyökérok.

Annotációs folyamatunk szisztematikusan feltérképezi az okot és az okozatot az egyes felhasználói visszajelzési munkameneteken belül. Az annotátor először kiszűri a kihagyott követelményt vagy a korábbi kontextus által támogatott szándékot. Három LLM bíráló ezután azonosítja a felelős fordulókat, és legalább kettő egyetértését kéri egy adott fordulóban. Néha egy korábbi kijelentés kifejezetten megállapítja a követelményt. Más esetekben egyetlen korábbi kijelentés sem teszi ezt meg, de az előző beszélgetés több része együttesen teszi következtethetővé a szándékolt viselkedést. Ez a kialakítás lehetővé teszi számukra, hogy a panaszt egy korábbi gyökérhibához kössék ahelyett, hogy azt kizárólag az utolsó válasznak tulajdonítanák.

A tipp elfogadása előtt a folyamat azt is ellenőrzi, hogy a korrekciós állításai a megjelölt forduló előtt elérhető információkból következnek-e. Ezek az ellenőrzések a hátratekintési torzítás csökkentését szolgálják, amikor a panaszban feltárt új preferenciát olyan dologként kezelik, amelyet a modellnek már ismernie kellett volna.

Ebben a példában a tipp azt mondja a modellnek, hogy a Paychexen keresse a W-3 átviteli űrlapot a W-2 helyett, vagy kérdezze meg, hogy a felhasználó melyik űrlapra gondol, ha a kérés kétértelmű. A korrekció a korábbi értelmezést és keresési döntést célozza meg, nem csupán a végső választ. Az eredeti forduló változatlan marad; az annotáció hozzáadja az is_bad_turn: true értéket és egy nem üres tippet.

Egy valós munkamenet, amely bemutatja, hogyan vezethető vissza egy panasz egy korábbi hibára, a ráhelyezett annotációs eljárással. A felhasználó „w3”-at kért a Paychexen, de a modell a W-2 elírásának tekintette, és a rossz űrlapot kereste meg. A javaslattevők konszenzusa meghatározza a gyökérokot, míg két megalapozottsági ellenőrzés azt értékeli, hogy a bizonyíték megelőzi-e a hibát, és a tipp állításai következnek-e az adott ponton elérhető információkból. Az elfogadott annotációk megőrzik az eredeti szöveget, és jelöléseket, valamint tippeket adnak hozzá az átírt célok helyett.

Keressük meg a hibákat az eszközhibákból

Vegyünk egy másik munkamenetet az eszközhiba-csoportból egy olyan keresési hívással, ahol az ügynök a recency_filter: "year" paraméterrel keres, de az eszköz elutasítja azt, mivel az engedélyezett értékek a „day”, „week” vagy „month”. Ez egyértelmű semsértés.

Az eszközhiba-útvonal determinisztikus szabályokat használ az ismert hibákra és modellbírálatot a kétértelmű esetekre. Egy hibaüzenet önmagában szintén nem elég a modell hibáztatásához; egy bírált korrekciónak olyan valamire kell mutatnia, amit a modell tudhatott volna az eszközséma, a rendszerutasítások vagy a korábbi beszélgetés alapján.

A jelentés érvénytelen keresési argumentuma szemlélteti az aktuális eszközhiba-eljárást. A séma miatt ez a hiba elkerülhető; egy leállás önmagában nem tenné azzá. Az eredeti hívás a rekordban marad, és kap egy megalapozott tippet. A tipp engedélyez egy felsorolt értéket vagy kihagyást, ha a mező opcionális; nem követeli meg a „hónap” használatát minden kérésnél.

Itt a tipp megnevezett a sikertelen hívást, tartalmazza az érvényesítési hibát, és arra utasítja a modellt, hogy használjon egy engedélyezett értéket, vagy hagyja ki a mezőt, ha az opcionális.

Két előrehaladó menet

Miután egy kört megjelöltek, a betanító kétszer futtatja ugyanazt az ellenőrzési pontot: egyszer tanárként, egyszer pedig diákként. A tanár látja a tippet; a diák nem.

Mindkét menet tanárkényszerítést (teacher forcing) használ, ahol a rögzített munkamenetet adjuk át a modellnek ahelyett, hogy hagynánk új tokeneket választani. Az előrehaladó menet továbbra is teljes következő token eloszlást hoz létre minden lépésnél, de ez mindig a felvételből származó rögzített előtagra van feltételezve, nem pedig a rollout tokenekre.

A keresési példa esetében ugyanez a modell sokkal nagyobb valószínűséget rendel a „hónap” és kevesebbet az „év” szóhoz, amikor megkapja a tippet. A tanítás ezt a eloszlásbeli eltolódást lágy célként használja.

Két menet, egy súlykészlet. Mindkét menet pontozza a rögzített folytatást; csak a tanár kap tippeket. A leválasztott következő token valószínűségei az előrehaladó KL-en keresztül vezetik a diákot. Külön CE-célok rögzítik az imitációt. Mindkét veszteség egy súlyfrissítést táplál. A korábbi tippek a tanár aktuális szegmensében maradhatnak; egyik menet sem generál csere tanítási választ.

A tanár előrejelzései leválasztottak vagy leállított gradiensűek: célt biztosítanak, de nem kapnak frissítést a tanári meneten keresztül. A diák menete után egy optimalizálási lépés frissíti a megosztott modellt.

A veszteségfüggvény

A CE-veszteség

A CE-veszteség az imitációra kijelölt rögzített tokeneket igazságforrás-célként kezeli, és bünteti a modellt, ha alacsony valószínűséget rendel hozzájuk. Ez egy nehéz imitációs célt hoz létre.

Az ii tokenpozícióban legyen pi(v)p_i(v) a vv token valószínűsége a teljes VV szókincsben a diák számára. A rögzített következő token a válaszban vagy az eszközhívásban yiy_i, az egyhot céleloszlás rir_i.

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

A keresztentrópia azt méri, hogy a diák mennyire jól jósolja meg ezt a rögzített tokent. Egyhot céllal ez az yiy_i-hez rendelt negatív logaritmikus valószínűségre egyszerűsödik.

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)

A CE-maszk miCEm_i^{\mathrm{CE}} értéke 11, ahol a tokent imitálni kell, és 00 egyébként. A kiválasztott pozíciók összeadása adja az imitációs veszteséget.

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

KL-veszteség

A KL-veszteség helyette a tanár teljes következő token valószínűségi eloszlását qiq_i használja lágy korrekciós célként. A tanár kontextusa tartalmazza az aktuális tippet és az adott tanítási szegmensben megtartott korábbi tippeket; a diák kontextusa mindig tippmentes.

A KL-maszk miKLm_i^{\mathrm{KL}} értéke 11, ahol a tokent ki kell javítani, és 00 egyébként; a CE- és a KL-maszkok nem fedik át egymást. Ezen pozícióknál az előrehaladó KL bünteti a tanár és a diák közötti egyetértés hiányát a teljes szókincsben:

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

Kombinált veszteség

Mindkét tag egy közös nevezőt oszt meg ahelyett, hogy külön lennének normalizálva. Ez a nevező számolja meg az imitációra kiválasztott összes tokent a globális tanítási kötegen belül. Az λ\lambda súly szabályozza a korrekciós tanítás hozzájárulását az imitációhoz képest.

Ez a megosztott normalizálás illeszkedik tanítási infrastruktúránk egynevezős felületéhez, és visszaállítja a szabványos SFT-veszteséget, amikor λ=0\lambda=0, egyszerűsítve az alapszintű összehasonlításokat. Mivel a CE-tokenek sokkal bőségesebben állnak rendelkezésre, mint a KL-tokenek, a megosztott nevező használata azt is elkerüli, hogy az egyes KL-tokenek aránytalanul nagy súlyt kapjanak a kevés megjelölt tokent tartalmazó kötegekben.

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

A korábbi példákra alkalmazva a W-3/W-2 keverést és az érvénytelen keresési hívást tartalmazó fordulók KL-t kapnak. A sikeres munkamenet egyéb megjelöletlen asszisztens-tartalma továbbra is CE-t kap. A sikertelen munkamenet egyéb asszisztens-tartalma kontextusként megmarad, de sem CE-t, sem KL-t nem kap.

Mit mutatnak az értékelések

Értékeléseink két külön kérdésre válaszolnak. Először is, segít-e a tipp a modellnek a hiba kijavításában, amikor a tipp jelen van? Másodszor, segít-e a tanítás a modellnek későbbi elkerülni ezt a hibát a tipp nélkül? Az első azt teszi próbára, hogy a tippek hasznos tanítási jeleket adnak-e. A második azt vizsgálja, hogy a modell tanul-e belőlük.

A tippek el tudják téríteni a modellt a hibáktól

A tanítási folyamat indulása előtt teszteljük az első kérdést, hogy meggyőződjünk arról, hogy a tippek valóban el tudják téríteni a modellt a hibáktól.

Felhasználói visszajelzés

Újrageneráltuk a megjelölt felhasználói visszajelzési fordulókat tippel és tipp nélkül, ugyanazt a GLM-5.2 alapmodellt használva nullás hőmérsékleten. Egy vak bíráló látja a későbbi panaszt, de sem a tippet, sem azt, hogy melyik feltétel hozta létre a választ.

A W-3 példában a tipp a „3” felé és a „2” elől mozdítja el a következő token valószínűségét a „W-” előtag után.

Egy tipp megőrzi a kért W-3 űrlapot. Az oszlopok a nyolc előrehaladó meneten átívelő átlagos következő token valószínűségeket mutatják; a bajuszok a megfigyelt tartományt mutatják, nem konfidencia-intervallumot. Mindkét feltétel a változatlan alapmodellt használja.

Egy nagyobb, 40 fordulós kiszűrt mintán, amelyet kifejezetten kifejtett korábbi bizonyítékok támogatnak, a rögzítettnek vagy helyes úton lévőnek ítéltek aránya 40,0%-ról (tipp nélkül) 75,0%-ra emelkedik tippel. Egy másik, 40, következtetett szándékon alapuló fordulón 32,5%-ról 80,0%-ra emelkedik.

Tipp érvényesítése, nem tanítás utáni értékelés. Az egyes bizonyítékcsoportokban szereplő ugyanezt a 40 megjelölt fordulót tippel és tipp nélkül újragenerálják a változatlan GLM-5.2 modell használatával nullás hőmérsékleten. A bíráló látja a panaszt, de a tippet vagy a feltételt nem. A darabszámok a jelentés arányaiból és mintaméreteiből származnak; a konfidencia-intervallumok nincsenek jelentve.

Eszközhibák

A keresési eszköz hibájára hozott példában a tipp valóban áthelyezi a valószínűségi tömeget az év tokenről a hónap tokenre.

Egy tipp elmozdítja a valószínűséget egy engedélyezett érték felé. Az oszlopok a nyolc előrehaladó meneten átívelő átlagos következő token valószínűségeket mutatják; a bajuszok a megfigyelt tartományt mutatják, nem konfidencia-intervallumot. Mindkét feltétel ugyanazt az alapmodellt használja; nincs összehasonlítás tanított ellenőrzőponttal.

Egy nagyobb, 985 fordulós kiszűrt mintán négyszer újrageneráljuk az egyes fordulókat tippel és tipp nélkül, ugyanazt az almodellt használva nullás hőmérsékleten. Egy vak bíráló értékeli, hogy minden újragenerálás elkerüli-e az eredeti hibát. A tippek 75,1%-ról 93,7%-ra növelik a hiba elkerülését – ez 18,6 százalékpontos páros nyereség –, és 60,6%-ról 82,3%-ra növelik a kijavított műveletet választók arányát. A nyereség azon hibák esetén a legnagyobb, amelyek javításával a csak ismételt mintavétel nehezen birkózik meg.

Eszközhiba-tipp érvényesítése 985 kiszűrt megjelölt fordulón, állapotonként négy újragenerálással. Az oszlopok a hiba elkerülését és a kijavított művelet arányát mutatják a változatlan alapmodell esetében, tippel és tipp nélkül. A célzott hiba elkerülése nem jelenti az eszközhívás vagy a feladat sikerét.

Eszközök megbízhatósága és a felhasználói visszajelzések a betanítás után

Ezután azt teszteljük, hogy a betanított modell kevesebb hibát követ-e el, ha nem kap tippeket. Az alapmodellt és különféle utólag betanított checkpointokat offline benchmarkfeladatokon és élő felhasználói munkamenetekben értékeljük, azt vizsgálva, hogy kevesebb-e az eszközhibák száma és a felhasználói elégedetlenség.

Offline értékelés

Az offline értékelés a BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE rendszereket, valamint egy reprezentatív Computer feladatkészletet használ, és ellenőrzi a készletbetöltést, a dokumentumfelülvizsgálatot és a beágyazott hivatkozásokat. Mmérjük azon eszközhívások arányát, amelyeknek az eredményei kifejezetten hibaként vannak megjelölve az értékelési pályák mentén.

Ezekben az értékelésekben a rögzített eszközhiba-arány 2.79% volt az alap GLM 5.2, 1,35% a csak RFT ellenőrzőpont és 0,87% az RFT-plus-OPSD ellenőrzőpont esetében. Ezeket az ellenőrzőpontokat különböző adatokon tanították, így ez nem egy egyező adatos OPSD-absláció. A feladatszintű benchmark eredmények vegyesek voltak, így a kevesebb eszközhiba önmagában nem feltétlenül jelent széles körű javulást a feladat sikerében.

Offline eszközhiba-arányok az alap GLM-5.2, a csak RFT és az RFT-plus-OPSD ellenőrzőpontok esetében. A tanítási adatok eltérőek az ellenőrzőpontok között; ez nem ellenőrzött absláció.

Online értékelés: GLM-5.2

A GLM-5.2 esetében két különálló A/B-tesztet futtattunk körülbelül százezer felhasználóval mindkét feltétel mellett. Az elsőben a korai RFT-plus-OPSD ellenőrzési pont eszközhibájának aránya kissé alacsonyabb volt, mint az alaptípusú GLM 5.2-é (2,82% a 2,94%-kal szemben), de a különbség nem volt statisztikailag szignifikáns.

A későbbi tesztben két RFT-plus-OPSD ellenőrzőpontot hasonlítottunk össze: egy korábbit (1. ellenőrzőpont) és egy későbbit (2. ellenőrzőpont). Az eszközhívási hibák a rögzített státuszú hívások 2,24%-áról 1,77%-ára estek vissza. Ez statisztikailag jelentős, 21,2%-os relatív csökkenés volt. Nem hasonlítottuk össze közvetlenül online a 2. ellenőrzőpontot az alap GLM 5.2-vel.

A felhasználói visszajelzések eredményei kevésbé voltak meggyőzőek. A második GLM-5.2 kísérletben az erős elégedetlenség (közepes vagy magas) átlagos valószínűsége 2,58% volt az első és 2,54% a második ellenőrzési pont esetében, statisztikailag szignifikáns különbség nélkül.

Két különálló GLM-5.2 élő A/B-teszt. Az 1. ellenőrzési pontot az alaptípusú GLM-5.2-vel, a 2. ellenőrzési pontot pedig az 1. ellenőrzési ponttal hasonlítjuk össze. E két teszten belül csak a későbbi eszközhibák csökkenése statisztikailag szignifikáns. A MID+ arányok a közepes vagy magas elégedetlenség átlagos becsült valószínűségét jelzik, nem pedig a panaszok számát.

Online értékelés: GLM-5.3

A GLM-5.3 esetében közvetlenül összehasonlítottunk egy utótanított ellenőrzőpontot az alap GLM-5.3-mal. Az eszközhívási hibák aránya a rögzített státuszú hívások 3,56%-áról 2,38%-ára esett vissza, ami 33,04%-os relatív csökkenést jelent. A MID+ arány, azaz a közepes vagy magas elégedetlenség átlagos becsült valószínűsége 4,12%-ról 3,41%-ra csökkent, ami 17,2%-os relatív csökkenés. Mindkét csökkenés statisztikailag szignifikáns volt.

Utótanított GLM-5.3 az alap GLM-5.3 ellen egy külön online A/B tesztben. Az eszközhiba- és MID+ arányok, a relatív változások és a 95%-os szekvenciális konfidenciaintervallumok CUPED-igazítást használnak. Mindkét csökkenés statisztikailag szignifikáns. A MID+ arányok a közepes vagy magas elégedetlenség átlagos becsült valószínűségét jelzik a jogosult, pontozott utókövetési szálak vonatkozásában, nem pedig a panaszok számát. Az eszközhibák aránya nem tartalmazza a rögzített siker- vagy hibastátusz nélküli hívásokat.

Következtetés

Központi gondolat a döntés szintjén tanulni, nem csupán a munkamenetében.

A sikeres eredmény elrejtheti a hibákat, és egy sikertelen munkamenet is feltárhatja a javítás módját. A sikeres munkamenetekből származó hasznos viselkedést horgonyként tartjuk meg, a panaszokat és az eszközhibákat az elkerülhető hibák azonosítására használjuk, és a modellt azon előrejelzések felé tanítjuk, amelyeket akkor tesz, amikor ezeket a hibákat és korrekciókat kifejezetten megadjuk. A siker megőrzendő viselkedést biztosít; a hiba irányt ad a fejlesztéshez.

A valós használat teszi ezt a megközelítést különösen hasznossá. A valós felhasználók olyan célokat, korlátokat és munkafolyamatokat hoznak, amelyeket nehéz előre látni egy szintetikus környezetben. Korrekcióik feltárják a modell által kihagyott követelményeket, míg az eszközhibák kiemelik a szakadékot a modell által megkísérelt és a környezet által megengedett műveletek között. Ezek a jelek kiegészítik az eredménsalapú tanítást: ahelyett, hogy csak azt kérdeznénk, hogy a feladat sikerült-e, megkérdezhetjük, hogy hol tévedett a modell, és milyen információ segíthette volna jobb döntés meghozatalában.

A korlátok ugyanolyan fontosak. A bírálók tévedhetnek, és egy kör kijavítása nem garantálja a teljes feladat sikerét. A cél nem csupán egy olyan ügynök, amely egy javítás után magához tér. Olyan ügynökre van szükség, amelynek ritkábban van szüksége javításra.

Idézet

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