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.
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.
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.
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.
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.
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.
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 tokenpozícióban legyen a token valószínűsége a teljes szókincsben a diák számára. A rögzített következő token a válaszban vagy az eszközhívásban , az egyhot céleloszlás .
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 -hez rendelt negatív logaritmikus valószínűségre egyszerűsödik.
A CE-maszk értéke , ahol a tokent imitálni kell, és egyébként. A kiválasztott pozíciók összeadása adja az imitációs veszteséget.
KL-veszteség
A KL-veszteség helyette a tanár teljes következő token valószínűségi eloszlását 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 értéke , ahol a tokent ki kell javítani, és 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:
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 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 , 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.
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 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.
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 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ö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.
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.
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.
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
@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}
}