GenPage: A Netflix célja az end-to-end generatív főoldal építése

Szerzők: Lequn Wang, Jiangwei Pan és Linas Baltrunas. 1. ábra. Autoregresszív kezdőlap-generálás. A GenPage egy Netflix kezdőlapot épít fel, egy sort vagy entitást egyszerre, mindegyik a már az oldalon lévő tartalmakra és a felhasználó kontextusára alapozva. Bevezetés A Netflix kezdőlapja az első dolog, amit a felhasználók látnak, amikor megnyitják az alkalmazást, és a fő mód, ahogyan felfedeznek tartalmat, amit élvezhetnek. Szinte minden részlet személyre szabott, ideértve, hogy mely sorok jelennek meg, mely entitások szerepelnek ezeken a sorokon, és hogyan van elrendezve minden az oldalon. A kezdőlap összerakása valóban nehéz feladat. Ez nem csupán egy rangsorolt lista előállítását jelenti. A kezdőlap egy strukturált, kétdimenziós elrendezés, amely ajánlósorokból és az azokban lévő entitásokból áll. Itt egy entitás lehet film, műsor, játék, élő esemény vagy más ajánlható elem. Minden választás hatással lehet a többi értékére. Hagyományosan, ezt egy összetett, többlépcsős folyamat révén építik fel, különféle komponensekkel a jelöltek generálására és rangsorolására, mind a sor, mind az entitás szintjén. Lehetőséget láttunk ennek a tervezésnek a átértékelésére. A nagy nyelvi modellek megmutatták, hogy egyetlen generatív modell különböző feladatokat tud végrehajtani azáltal, hogy egyszerűen válaszol egy bemenetre. Ebből a bemenet-válasz paradigmából inspirálódva egyetlen generatív modellt képeztünk ki, hogy közvetlenül válaszolva egy kérdésre felépítse a kezdőlapot: Mivel mindent tudunk erről a felhasználóról és erről a kérésekről, milyen kezdőlapot kell generálnunk a felhasználói elégedettség maximalizálása érdekében? Ezt a megközelítést GenPage-nek nevezzük. Ez a felhasználói előzményeket és a kérések kontextusát méretként kezeli, és autoregresszíven generálja az egész kezdőlapot válaszként (1. ábra). A legtöbb generatív ajánlóval, mint például a TIGER, HSTU és OneRec, amelyek lapos rangsorolt listákat generálnak, szemben, a GenPage együtt generálja a sorokat, entitásokat és elrendezést. Ez a váltás több célt szolgál: Végpontok közötti modellezés. Egyetlen transformer modell, amely a nyers bemeneti jelekből építi fel az oldalt, helyettesítheti a komplex, többlépcsős ajánló rendszert. Ez csökkenti a karbantartandó ML modellek számát, elkerüli a különböző célkitűzésekkel kapcsolatos összefonódásokat a lépések között, és sok hagyományos funkciómérnökséget eltávolít. Teljes oldali optimalizálás megerősítés révén (RL). Az autoregresszív oldalgenerálás lehetővé teszi az oldal szintű jutalmak optimalizálását RL segítségével. Ez képes rögzíteni az interakciókat a sorok és entitások között, például a sokféleséget vagy a különböző megállási erősségű sorok közötti egyensúlyt. Például egy "Folytatás nézése" sor a lap tetején erősen kielégítheti a felhasználó azonnali szándékát, de csökkentheti azt is, hogy mennyit böngésznek az oldalon. Ezeknek az interakcióknak az oldalszinten való modellezése lehetővé teszi a rendszer közvetlenebb összhangját a felhasználói elégedettséggel, mint pusztán az entitás szintű célok. Jobb skálázási viselkedés. A generatív transformer modell világosabb utat ad a minőség javítására több adaton, számításon és modell kapacitáson keresztül, anélkül, hogy folyamatosan újra kellene terveznünk a rendszert. Rugalmasság és bővíthetőség. A bemenet-válasz paradigma tervezési szempontból rugalmas. A funkciómérnökség egyszerűsítésével és a teljes oldali optimalizálás lehetővé tételével a GenPage megkönnyíti új termékélmények támogatását, mint például további tartalomtípusok, például élő események, játékok és podcastok; a jelenlegi kétdimenziós struktúrán túlmutató elrendezések; személyre szabott UI elemek; és entitásonkénti művészeti személyre szabás, mindezt kevesebb architekturális változtatással. A GenPage termelésbe állítása a Netflixnél azt is igényelte, hogy megoldjunk az ipari léptékű ajánló rendszerekhez kapcsolódó kihívásokat. Mivel a kezdőlap valós időben generálódik, a szolgáltatási késleltetés elsődleges mérnöki korlátozás. Kezelni kell az entitás hideg indulását is egy folyamatosan fejlődő katalógusban, frissen kell tartani a modellt a felhasználói érdekek és kulturális trendek változásával, és részletes termék- és üzleti szabályokat kell alkalmazni a generált kimenetre. E kihívások ellenére a GenPage már jelentős hatással volt a termelésre. Egy online A/B teszt során, amely egy érett, rendkívül optimalizált többlépcsős termelési ajánlóval szemben készült, a GenPage statisztikailag szignifikáns javulást mutatott a mag felhasználói elkötelezettségi mutatószámmal, amelyet a bevezetési döntésekhez használunk, miközben 20%-kal csökkentette a végpontok közötti szolgáltatási késleltetést. Offline két megállapítás kiemelkedett. Először is, a bemenet gazdagítása jobban segített, mint a modell kapacitásának skálázása a jelenlegi rendszerünkben. Másodszor, az RL utáni képzés növelte a kezdőlap sokszínűségét, bár a sokszínűség nem része a célkitűzésnek. Úgy várjuk, hogy ez a megközelítés általánosítsa a személyre szabási beállításokra. Ebben a bejegyzésben a Netflix kezdőlapjára összpontosítunk, mint konkrét esettanulmányra, megosztva a tervezésünket, az ütközéseinket és a tanulságokat. Adatok Hagyományos ajánlóról generatív transformerre való átállásunk a torzítás gondolkodását igényli. Hasonlóan ahhoz, ahogyan egy LLM átkonvertálja a szöveget tokenekre, a GenPage mind a felhasználói kontextust, mind a generált kezdőlapot egy diszkrét tokenekből álló szekvenciaként képviseli. Ez a szekvencia tartalmazza a teljes struktúrált kezdőlap elrendezést, több sorral és az azokban található entitásokkal, így a modell holisztikusan képes generálni az oldalt, ahelyett, hogy minden sort vagy entitást külön-külön értékelne. 2. ábra. A Netflix kezdőlap építési adatának tokenizálása. A kontextus tokenek a bemeneti hívások, amelyek különböző adatforrásokból származnak, beleértve a felhasználói előzményeket, a profil attribútumokat és a kérések kontextusát, példás tokenek jelennek meg minden forráshoz. Az oldal tokenjei a generált választ képviselik, kódolva a sorok és entitások struktúrált elrendezését. Minden képzés példány egy kezdőlap impressziót képvisel, és három összetevőből áll: Kontextus: felhasználói elkötelezettségi előzmények, profil attribútumok, és kérések kontextusa. Oldal: a kezdőlapon megjeleníthető ajánlott sorok és entitások elrendezési sorrendje. Visszajelzés: a felhasználói interakciók az oldalon, például lejátszás, tetszik, vagy elhagyás az oldalon lévő entitásokkal. Csak a kontextust és az oldalt tokenizálják, mint a modell bemenetét és kimeneté. A visszajelzést belső jutalmi rendszerünk segítségével felügyeleti jelekké alakítjuk (lásd a Jutalmi rendszer szekciót). Nem off-the-shelf szöveg tokenizálót használunk, hanem egy terület-specifikus tokenizálót építünk a kezdőlap építési adataihoz. Ez egy bizonyított megközelítés ajánlórendszerekben és más specializált területeken, beleértve a számítógépes látást, biológiát és kémiát, ahol a nyers adatok nem természetesen szövegként vannak képviselve. Az általános szöveg tokenizálással összehasonlítva ennek két kulcselőnyét adja: Számítási hatékonyság. A testreszabott tokenizálás jelentősen csökkenti a szekvencia hosszúságát, alacsonyabbra csökkentve a következtetési költségeket és késleltetést. Például az "A felhasználó 30 napja 50 percig nézte az 'Orange Is the New Black'-et." esemény képviseléséhez a GPT-5 tokenizálóval 16 tokenre van szükség, míg a mi sémánk 4 tokenre tömöríti: [Entity_ID], [Action_Type], [Action_Time_Bucket] és [Action_Duration_Bucket]. Termékkontroll. A tokenek és a termékfogalmak, például sorok és entitások közötti közvetlen megfeleltetés megkönnyíti a modell generálásának ellenőrzését. Ez kulcsfontosságú a végső kezdőlapra vonatkozó üzleti szabályok végrehajtásához. Kontextus tokenek A kontextus tokenek a felhasználói elkötelezettségi előzményeket, a felhasználói profilt és a kérések kontextusát kódolják. A felhasználói előzményeket a felhasználói cselekvések sorozataként ábrázoljuk. Minden cselekvéshez kulcsfontosságú metaadatokat vonunk ki, beleértve a cselekvés típusát, az entitás azonosítóját, az időbélyeget és a tartamot. Ezek a cselekvések közé tartoznak a kifejezett jelek, mint például a lejátszás, a "Hozzáadás a listához" és a tetszésnyilvánítás, valamint az implicit jelek, mint például a trailer megtekintése vagy a részletező oldalra való látogatás. A felhasználói profil tokenek rögzítik az olyan attribútumokat, mint a nyelv és a profil típusa. Kérés kontextus tokenek a nap időpontjára, a hét napjára és az eszközre vonatkozó jeleket kódolják. Néhány adatforrás túl hosszú ahhoz, hogy közvetlenül nyers token szekvenciákként szerepeljen. Például egy felhasználó teljes impressziótörténete megszokottan költségérzékeny lenne teljességében való ábrázolás során. Ezekben az esetekben összegzett verziót használunk. Ez egy pragmatikus ütközés: miközben a GenPage arra törekszik, hogy lehetőleg nyers bemeneti adatokkal működjön, a kézzel elkészített összegzések még mindig bevezetik a prompt mérnökség egy formáját a folyamatba. A hosszú adatforrások összenyomásának elsajátítása fontos irány a jövőbeli munkához. A modell számára könnyen megkülönböztethető adatforrások között, különleges tokeneket helyezünk el, amelyek megjelölik az egyes szegmensek kezdetét. A folyamatos jeleket, például az időbélyegeket és a tartamokat, diszkrét tartományokba rendezik, hogy a szókészlet véges maradjon. Oldaltokenek Minden entitás, például egy műsor, film vagy játék, valamint minden sor, például koreai TV műsorok, egyetlen tokenként van megjelenítve. A kezdőlap elrendezési sorrendben van sorozatosítva: balról jobbra, majd felülről lefelé. Naponta frissítjük az entitás- és sor szókincset, hogy a frissen hozzáadott entitásokat és sorokat is belefoglaljuk. Azokat az entitásokat, amelyek még ki vannak a szókincsből a szolgáltatáskor, szemantikus embedding fúzióval és visszaeső tokenekkel kezeljük, amelyeket később írunk le. Elvileg a ugyanaz a paradigma kiterjeszthető bármilyen kimenetre, amely lineáris token szekvenciaként kifejezhető. Ez magában foglalja a jelenlegi kétdimenziós struktúrán túlmutató elrendezéseket, mint például egy dimenziós hírcsatornák vagy kevert elrendezések, valamint személyre szabott UI komponensek és entitásonkénti kimenetek, például személyre szabott művészet. Ezeknek a bővítéseknek a kidolgozása a jövőbeli munkánk része. Lapozott ajánlás Ahhoz, hogy az ajánlások reagáljanak az ülés során felmerülő felhasználói preferenciákra, a kezdőlapot gyakran fokozatosan, néhány sorban generálják. Minden lapozási kérés előtt a korábban generált sorokból származó oldal tokenjeit hozzáadjuk a bemeneti híváshoz, a felhasználó legutóbbi elkötelezettségeivel e sorokkal kapcsolatban a Netflix valós idejű eseménynaplózó infrastruktúráján. Ez lehetővé teszi, hogy a modell a felhasználó hosszú távú preferenciáival és legutóbbi ülésen belüli viselkedésével együtt generálja a következő ajánlások sorozatát. Jutalmi rendszer A javaslat hosszú távú értékének kvantálásához egy belső jutalmi rendszerre támaszkodunk, amelyet korábbi munkákban tárgyaltunk. A jutalmi rendszert online A/B tesztelés során hangolják össze a hosszú távú felhasználói elégedettséggel, és ez szolgál a primer felügyeleti jelként a felügyelt és erősítő tanulás során. A jutalmi rendszer feldolgozza a felhasználói visszajelzéseket, és minden impressziózott entitásra egy skaláris jutalmat rendel. Például egy TV műsor, amelyet egy éjszaka alatt néztek végig, erősebb felhasználói elégedettséget tükröz, és magasabb jutalmat kap, mint egy film, amelyet csupán 10 percig néztek. Egy impressziózott entitás, amelyet a felhasználó elhagy, negatív jutalmat kap. Az oldal szintű jutalmat az összes impressziózott entitás jutalmának összegeként definiáljuk a kezdőlapon. Modellarchitektúra A GenPage egy standard dekóder- csak transformer architektúrát használ, ugyanazzal az általános architektúrával, amely mögött sok modern LLM van. Ez a választás egyszerűvé és rugalmasabbá teszi a modellt, miközben lehetővé teszi számunkra, hogy a transformer képzés és szolgáltatás körüli széles ökoszisztéma előnyeit is kihasználjuk. Az építési részletek közé tartozik a bemeneti beágyazás és a kimeneti projekciós súlyok leválasztása. Ez hasznos, mivel a pre-training és a post-training különböző igényeket támaszt a logit-okon. A következő token előrejelzés pre-training optimalizálja a softmax-ot a szókincsen, míg a súlyozott bináris klasszifikáció (WBC) utáni képzés a per-token sigmoid pontszámokat optimalizálja, ahogy alább leírjuk. A súlyok leválasztása további rugalmasságot ad a modellnek, hogy alkalmazkodhasson mindkét célhoz. Képzési recept A képzési csővezetékünk lemásolja az LLM receptjét: először tanítjuk meg a modellt a Netflix kezdőlap "nyelvét“ a pre-training révén, majd összehangoljuk kimeneteit a felhasználói elégedettséggel a post-training révén. A post-training során két alternatív megközelítést vizsgálunk: súlyozott bináris klasszifikáció (WBC) és megerősítő tanulás (RL). A WBC egyszerűbb az optimalizálásra és közvetlenül összhangban áll a termelési rangsoroló modellek entitás szintű céljaival. Az RL nehezebben értékelhető és optimalizálható, de ez a kulcs a GenPage teljes víziójához az oldal szintű optimalizációhoz, a tesztidőbeli gondolkodás és a több-token entitás ábrázolás rugalmas incorporateálásával. Pre-training következő token előrejelzés révén A modellt standard következő token előrejelzési céllal képezzük: a kontextus tokenek és egy oldal tokenek előtagja alapján a modell megtanulja előre jelezni a következő oldal tokenet. Ez a szakasz a reprezentáció tanulására összpontosítva tanítja meg a modellt a felhasználói kontextusok és a sikeres kezdőlapok közötti kapcsolatot. Érdemes megjegyezni, hogy a kontextus-oldal képzési példák hasonlítanak az LLM felügyelt finomhangolás (SFT) során használt bemenet-válasz párokhoz, mintsem a nyers szövegre, amelyet az LLM pre-training során használnak. Mégis, ezt a szakaszt pre-trainingnek nevezzük, mivel a modellt a semmiből képezzük, nem egy meglévő ellenőrzőpontról finomhangolva. Az LLM-ekkel ellentétben, amelyek gyakran szembesülnek a magas minőségű címkézett adatok hiányával, az ajánlórendszerek bővelkednek felhasználói visszajelzésekben. A pre-training során azokat a kezdőlap impressziókat használjuk, amelyek pozitív visszajelzést kaptak, amikor a termelés során bemutatták őket, ezzel indítva el a modellt, hogy olyan oldalakat generáljon, amelyek hasonlóak ahhoz, amelyeket a meglévő termelési rendszer produkál. A pre-training azonban főleg arra tanítja meg a GenPage-et, hogy utánozza a termelési rendszert. Ez nem optimalizálja közvetlenül a jutalom mértékét, és ahogy a GenPage a termelés részévé válik, a korábbi modellek által generált oldalakon végzett folyamatos képzés a modell leromlásának kockázatát hordozza. E korlátok kezelésére két megközelítést vizsgálunk post-training során. Post-training súlyozott bináris klasszifikációval Az egyik hatékony módja a generatív modell összhangja a felhasználói elégedettséggel a súlyozott bináris klasszifikáció (WBC). Magas szinten a WBC a generálást token-szintű érték előrejelzésévé alakítja: a felhasználói kontextus és az eddig generált tokenek alapján a modell megtanulja megbecsülni a következő sor vagy entitás token generálásának értékét. Ez az célkitűzés könnyebben optimalizálható, mint az oldal szintű RL. A kezdőlap felbontásával per-token célokra a WBC a konstrukción alapuló token-szintű kreditet biztosít, ahelyett, hogy RL-re támaszkodna, hogy megközelítse, hogyan járult hozzá a generált döntés a végső oldal szintű jutalomhoz. Ez a képzési beállítás lehetővé válik az egyedi tokenizálás által. Minden oldal token közvetlenül egy specifikus entitáshoz vagy sorhoz kapcsolódik, megkönnyítve a jutalom hozzárendelését. Minden impressziózott entitásra a jutalmi rendszerünk skaláris jutalmat biztosít a felhasználói visszajelzés alapján. Minden impressziózott sorhoz sor szintű jutalmat képezünk az adott sorban lévő entitások jutalmának aggregálásával. Minden jutalomból deriválunk egy bináris címkét a jele alapján, például pozitív elköteleződést a kockázatra, és egy súlyt a mértéke alapján, például a binge-watching nagyobb súlyt kap, mint egy rövid lejátszás. Ezután optimalizálunk egy súlyozott bináris keresztentropia veszteséget a megfelelő token logit-ján. E beállítás alatt a betekintés a tokent a modellen keresztül a mai helyzetére és a figyelembe vett kozmoszba is lehet értelmezni. Bár a modell érték előrejelzőként van edzve, még mindig autoregresszíven generálhat oldalakat. Minden lépésben a modell pontozza a következő kandidat tokeneket, körömszagú módon kiválasztja a legmagasabb értékű tokent, és hozzáfűzi azt a prefixhez. Ez a folyamat tokenről tokenre ismétlődik, amíg a teljes kezdőlap generálódik. Post-training megerősítő tanulással A második post-training megközelítésünk a megerősítő tanulás (RL). A WBC hatékony az entitás szintű metrikák optimalizálására, de nem optimalizálja közvetlenül a kezdőlapot mint egészet. Az RL az oldal generálást sorozatos döntéshozatali problémaként kezeli, lehetővé téve a modell számára, hogy optimalizáljon egy oldal szintű jutalmat, miközben megőrzi az autoregresszív generálás rugalmasságát. Ez megnyitja az utat néhány fontos képesség előtt: Teljes oldali optimalizálás. Az RL közvetlenül optimalizálja az aggregált oldal szintű jutalmat, lehetővé téve a modell számára, hogy figyelembe vegye az interakciókat a sorok és entitások között, mint például a sokszínűséget, a megállási erőt és az üzleti korlátozásokat. Tesztidőbeli gondolkodás. Az LLM-ek használatával analógiás, az RL optimalizálja a gondolkodási képességeket a generatív ajánláson. A gondolkodási kimeneteket is tekinthetjük automatizált funkciómérnökség formájának. Több-token entitás támogatás. Jelenlegi tokenizálásában minden entitás és sor egyetlen tokenként van képviselve, így a jutalmak tisztán térképezhetők a különböző tokenekhez. Azonban bonyolultabb környezetekben egy entitásnak több tokenre is szüksége lehet, például [Show_ID] és [Episode_#] egy epizódhoz, vagy egy szemantikai azonosító tokenek.

Ebben az esetben a WBC per-token címkézése homályos, mivel egyetlen entitás szintű jutalmat kell elosztani több tokenre. Az RL elkerüli ezt a problémát, optimalizálva a szekvencia szintű megtérülést, így természetesebb illeszkedést biztosít a változó hosszúságú, több-token entitásokhoz. Az RLHF recept alapján, amelyet a nagy nyelvi modellek összhangjára használnak, egy kétlépcsős megközelítést alkalmazunk. Először egy jutalmintázat modellt tanítunk, amely megjósolja a generált oldal szintű jutalmát. Ez a jutalminta modell eltér a korábban említett jutalmi rendszertől. A jutalmi rendszer az észlelt felhasználói visszajelzést egy skaláris jutalommá alakítja a már valóban megmutatott oldalra, míg a jutalminta modell megjósolja a generált oldal szintű jutalmát anélkül, hogy azt a felhasználónak meg kellene mutatni. Ez a predikció lehetővé teszi az RL számára, hogy a képzés során tetszőleges jelölt oldalak ellen optimalizáljon. A jutalminta ellenében a képzés során elkerüljük a policy prefektiválás magas variabilitását, de ez a jutalmak manipulálásának kockázatát is bevezet. Mivel a jutalminta a termelési politikából generált adatokon edzve a lehető legmegbízhatóbb a termelési politikából generált oldalakkal hasonló oldalain, ezért KL büntetést alkalmazunk, hogy a politikát a pre-képzett ellenőrzőpontra közel tartsuk, amely maga is a termelési politikát utánozva lett képezve. Ez biztosítja, hogy az oldalak a jutalminta modellezési területén belül maradjanak, és korlátozzák a jutalmak manipulálásának lehetőségeit. Az RL algoritmushoz a Dr. GRPO-t választjuk, amely a GRPO egy olyan változata, amely csökkenti a tréning célkitűzésének elfogultságait. A modell tréningjéhez az alábbi komponensekre van szükség: Bemenetek: gyártási felhasználói kérések, amelyek kontextus tokenekként vannak ábrázolva. Politikai és referencia modellek: mindkettőt az előzetes ellenőrzőpontból inicializálják; a referencia modell képezi a KL büntetést, amelyről az előbbiekben szó volt. Jutalminta modell: egy dedikált transformer-alapú jutalminta modell, szintén az előzetes ellenőrzőpontról inicializálva, előre jelzi az oldal szintű kimeneti jumalat, felhasználva a belső jutalmik rendszerünkből származó entitás szintű jutalmak összegét mint a felügyeleti célkítűzést. Szabályalapú formátum jutalmakat is beépítünk az RL politika irányítására. Például az oldalnak úgy kell kinéznie, mint egy sorok listájának, és a termék szempontjából kritikus soroknak vagy entitásoknak nem szabad túl alacsonyan megjelenniük az oldalon. A termelési kihívások kezelése Hideg kezdet Az új entitások hiányolják a gazdag interakciós adatokat, amelyek szükségesek a robosztus token beágyazás tanulmányozásához. Ezt két kiegészítő stratégiával kezeljük: Kontex-kinjekció. Az új vagy időérzékeny entitásokról (például élő események) szóló metaadatokat közvetlenül a kontextus tokenekbe injektáljuk, biztosítva a modell számára a szemantikus és időérzékeny információkat. Szemantikus beágyazási fúzió. Ahelyett, hogy csupán a felhasználói interakciós adatokból tanult entitásazonosító beágyazásokra támaszkodnánk, minden entitást az azonosító beágyazása és egy tartalom alapú beágyazás fúziójaként képviselünk, amely származik szemantikai információkból, mint például a szinopszisok, szereplők, átírások, műfajok és videótartalmak. Ez a fúziós beágyazás szolgál az entitás token bemeneti beágyazásaként a transformeren. Képzés során kis valószínűséggel véletlenszerűen egy entitásazonosító tokent cserélünk ki a generic fallback tokennel (az alább említett), így a modell megtanulja, hogy csak a tartalom-alapú beágyazást használva adjon ajánlást. Ez biztosítja, hogy egy új entitás jelentős reprezentációval bírjon ugyanabban a rejtett térben, mint a már létező entitások, amint a tartalom metaadatai elérhetővé válik — még mielőtt bármilyen interakciós adat állna rendelkezésre. Többciklusos fokozatos képzés Netflix léptékben a nagy transformer naponta való újratanítása rendkívül költséges, ugyanakkor az ajánlórendszereknek naprakészen kellene tartaniuk, hogy megragadják az elmozduló trendeket és az új katalógus elemeit. Ezt egy többfokozatú fokozatos tanulási stratégiával kezeljük. A folyamat struktúrája biztosítja, hogy jól frissítjük az azonnal elérendő bájtot. Periódikusan nagy léptékű pre-traininget és post-trainingot hajtunk végre egy széles történelmi ablak adatai alapján. Ezek között naponta kis fokozatú frissítést hajtunk végre, amely ötvözi a legutóbbi nap adatait a korábbi adatok mintavételezett alszámaival, hogy a modellt naprakészen tartsuk, miközben elkerüljük a katasztrofális elfelejtést. Képzési csővezetékünk ciklikus tervezés szerint működik, két eltérő ritmusú időszakban. Állítható ritmusban a korábbi történeti ablak adatain végzünk nagyméretű pre-traininget és post-trainingot. Ezen passzusok között minden nap egy fokozatos frissítést végzünk, hogy folytassuk a korábbi napi ellenőrzési ponttól az utólagos edzést, a legfrissebb napi adatok keverékével és a múltbeli adatok mintavételezett alszámaival. Ez segít a modellnek abban, hogy naprakész maradjon az új trendekkel és katalógusváltozásokkal, miközben megakadályozza a túlépítést és a katasztrofális elfelejtést. Az új tokenek napi beáramlásának irányításához (pl. új entitások, sorok), visszaeső tokeneket alkalmazunk. Az új tokent a saját típusának visszaváltható tokenjeivel inicializáljuk (pl. [Row_Fallback_Token] új sorokhoz, [Entity_Fallback_Token] új entitásokhoz). A képzés során a véletlenszerűen ismert tokenek egy kis százalékát kicseréljük visszaeső tokenekre, ezáltal a modellt arra tanítjuk, hogy szépen kezelje az ismeretlen tokeneket. A termék szabályok érvényesítése A Netflix kezdőlapjának szerkezeti korlátozásoknak (pl. a sorok listájaként rendezett) és a termék logikájának, például a duplikáció elkerülésének, a sorok rögzítésének és a kategória konzisztenciájának is eleget kell tennie (pl. egy vígjáték sorban lévő entitásoknak vígjátékoknak kell lenniük). Míg a képzési jelek ösztönözhetik a szabálykövetést, nem garantálhatják a szigorú összhangot. Ezeket a szabályokat a tesztidőben kényszerített dekódolással érvényesítjük. Minden autoregresszív generálási lépésnél egy maszkot számolunk az arra jogosult tokenekből, az alkalmazásban lévő üzleti szabályoknak megfelelően, és alkalmazzuk az output logitjainkra, lehetővé téve csak a feltételezett tokenek generálását. Ez a konkrét tokenizáló rendszerünk nagy mértékben leegyszerűsíti: mivel minden entitás és sor egyetlen token, a termék szabályai közvetlenül térképezkednek a token szintű maszkokra, elkerülve a több tokenes könyvelést, amit tengeri dekódolás igényel egy szöveg szókészleten. Például egy specifikus sor (pl. népszerű játékok) rögzítése egy fix pozícióban (pl. 2. sor pozíció) következik: egyszerűen maszkáljuk a többi token az adott pozícióban. Hibrid sor dekódolás Az autoregresszív generálás biztosítja, hogy minden újonnan generált token a teljes megelőző kontextust figyelembe vegye, de minden entitás token generálása egyedül drága lehet. Kihasználjuk a kezdőlap struktúráját, hogy egyensúlyt teremtsünk a következtetési hatékonyság és a generált tokenek elérhető kontextuális információja között. Minden soron belül az első néhány entitás különösen fontos: azok kapják a legtöbb felhasználói figyelmet, és erősen formálják meg a sor észlelhető minőségét és témáját. A következtetési késleltetés minimalizálása érdekében egy hibrid sor dekódolási stratégiát alkalmazunk. A modell autoregresszíven generál az első néhány entitás minden sorban. Az ezen generált prefix alapján, egyetlen előre futás során bezérdeljük az összes jogosult entitás logits-ait, és kiválasztjuk a legjobban teljesítő fennmaradó entitásokat, a fentiekben leírt üzleti szabály korlátozások függvényében. Ez a megközelítés megőrzi az autoregresszív kondicionálást, ahol a legfontosabb, miközben elkerüli a hosszú sorok token by token dekódolásának késleltetését és költségét. Offline kísérletek A Netflix belső adataival végzett sorozatos ablatív vizsgálatok révén azt próbáltuk megérteni, hogy a GenPage különböző összetevői hogyan befolyásolják a modell minőségét. Mivel a rendszert iteratívan fejlesztették, az egyes ablatív tesztek különböző képzési konfigurációkat és adatszetteket ölelnek fel, így csak relatív összehasonlításokat jelentünk be minden tanulmány keretein belül. Különben a kísérletek ~200M paraméteres modelleket használnak, és az eredményeket egy háttérbe helyezett kiértékelési halmazon jelentik. Segít-e a pre-training? A WBC post-training-et hasonlítjuk össze egy előző következő token predikciós pre-training fázis nélkül és annak jelenlétében. Az ábra azt mutatja, hogy a pre-training jelentős javulást eredményezett az összes mutatóban. Az előnyök talán kicsinek tűnnek abszolút értelemben, de nagynak számítanak a termelési rendszerünkben: egy impressziózott entitások véletlenszerűen kiválasztott párjának rangsorának hibája 9%-ról 8%-ra csökken, ahogy az Entitás AUC 0.91-ről 0.92-re emelkedik — ilyen mértékű előrelépést ritkán látunk egy érett termelési rendszeren belüli egyetlen változással. A modell "nyelvének" előképzése biztos alapot ad a post-traininghez, tükrözve a modern LLM-ek mögött álló pretrain-then-post-train receptet. Hogyan skálázódik a teljesítmény a modell méretével? Az ~120M-től ~900M paraméterekig besöppert modellszélességgel (ábra) és riportáljuk a következő token predikciós veszteséget a pre-training és a WBC veszteséget a post-training során. Mindkét veszteség csökken egy hatványtörélyszámú módon, visszatükrözve LLM-ekben észlelteket. Ez megerősíti, hogy a generatív megközelítés kedvezően skálázódik a mdl méretével, sugallva hogy az ajánlási minőség tovább javítható a kapacitás növelésével. Hogyan skálázódik a teljesítmény a felhasználói kontextus információjával? A fejlesztés során folyamatosan mélyítettük a bemeneti információt, új datforrásokat adva a kontextushoz, és finomítva, hogy az egyes forrásokat hogyan tokenizálják. A modellszélesség rögzítése mellett a WBC post-training veszteség jelentősen csökkent, ahogy a kontextus bővült. A modellszélesség átütemezés és a kontextus gazdagítása az eltérő tengelyeken helyezkedik el, és nem szigorúan kompatibilis: a modellszélesség tanulmány körülbelül egy nagyságrendnyi paramétert ölel fel, míg a kontextus tanulmány a bemeneti design teljes pályáját fedi. Mégis, a két közötti különbség figyelemre méltó. A modellt a 120M-tól 900M-ig terjedő paraméterekkel való bővítése a WBC veszteséget körülbelül 1.3%-kal csökkenti, míg a kontextus gazdagítás kumulatív hatása körülbelül 6.9%. Több esetben egyetlen jól megtervezett kontextus bővítés nagyobb javulást érzékel, mint az egész ~7.5×-os model kapacitás növelése. Ez azt sugallja, hogy a mi rendszerünkben a bemeneti gazdagítás — mind az, amit a kontextusba teszünk, mind pedig ahogy tokenizáljuk - lényegében sokkal nagyobb javulást jelent, mint a modelhez való kapacitás növelése. A személyre szabás minősége úgy tűnik, elsődlegesen a modell rendelkezésére álló információ és reprezentálás blokkolva van, és csak ezt követi a kapacitás. Várható, hogy a kontextus gazdagítás dominál, amíg a kontextus telítve nem lesz, mikor is a modellkapacitás a legfontosabb mozgatórugó lesz. Az RL post-training optimalizálja-e az oldal szintjén? Offline értékelések során az RL utáni képzés folyamatosan javítja az oldal szintű jutalmat a pre-képzett ellenőrzőponthoz képest, de ez nagyrészt megerősítő jellegű: a jutalmat ugyanazzal a modellel számolják ki, amely ellen a politika optimalizál. Érdekesebben tapasztalható, hogy bár a sokszínűség nem a RL célja, a kezdőlap sokszínűsége — az oldalon lévő entitások párba állított beágyazási távolságának mértéken keresztül — szintén növekszik a képzés során. Ez arra utal, hogy az RL által képzett politikák az oldalt mint egészt optimalizálják, nem csak a tokenek izolált optimalizálására fókuszálnak. Online értékelés Az GenPage-el folytatott online A/B tesztet a jelenlegi termelési kezdőlap ajánlóval végeztük. Ebben a tesztben a GenPage a meglévő termelési sor és entitás jelöltkészletek felett dekódolt, ami segít kezelni sok üzleti szabályt (például jogosultságok). Az eredmény ezt mutatja: minden variáció statisztikailag szignifikáns javulásokat nyújtott a mag felhasználói elkötelezettségi mutatóján, amelyet a bevezetési döntésekhez használunk (p < 0.001), egy érett, rendkívül optimalizált többlépcsős termelési alaphoz képest. A variációk eltértek a képzési adat konfigurációikban; hogy mindegyik hasonló emeléseket nyújt, azt jelzi, hogy a nyeremény robusztus ezeknek a designválasztásoknak a felfogásával, nem pedig alapján egy adott konfiguráción. Az elköteleződési nyeremények mellett észleltünk szándéktalan elmozdulásokat az impressziózott entitás kategóriák eloszlásában (pl. új vs. meglévő címek, TV műsorok vs. filmek). Ezek az elmozdulások nem feltétlenül negatívak, de nem olyanok, amelyeket kifejezetten optimalizáltunk, és mélyebb kivizsgálást érdemelnek. Gyanítjuk, hogy ezek az elmozdulások azt a tágabb egyéni élménnyel való generálást tükrözik, amit a termelési áthidaló rendszerek nem tudtak lekezelni — összhangban azzal, hogy a kezdőlap impresszióhatékonysága megnövekedett, ti. a felhasználók azokkal érintkezve, amiket láttak, kevesebb impresszióval. Ez élesebb személyre szabásnak tűnik, amely a termelési öröklési elemeket (mint például a jutalmi rendszert) hozza felszínre, amelyek még nem állnak összhangban az új generatív paradigmával. Azt tervezzük, hogy jellemezzük e elmozdulások hajtóerejét, és ha megfelelő, finomhangoljuk ezeket az összetevőket, hogy a jövőbeli eloszlások jobban összehangoltak legyenek a kívánt terméki viselkedéssel. Erőteljes reagálást tapasztaltunk az ülés során jelentkező jelekre is: a legújabb cselekvések gyorsan befolyásolták a következő ajánlásokat és egy-két nap alatt visszatértek a hosszú távú preferenciákra, megerősítve, hogy a modell hatékonyan figyel a cselekvések időbélyegére. Ez a reagálás a generatív formulációból származik, anélkül, hogy a termelési rendszereinknél használt részletes manuális funkciómérnökség lenne szükséges. A közismert feltételezéssel ellentétben, hogy a generatív modellek lassabbak, a GenPage a végpontok közötti szolgáltatási késleltetést 20%-kal csökkentette a bázishoz képest. A több rangsorolási lépést és a nehéz funkciómenedzselést egyetlen transformerre helyből, nyers tokenizált bemenetekre cseréltük, ezzel jelentős kiszolgálási bonyolultságot és számítási költséget távolítva el. A testreszabott tokenizálás és a hibrid sor dekódolás tovább csökkentette a dekódolási lépések számát, ezzel csökkentve a késleltetést is. A 20%-os csökkentés fenntartása nem kimerítette a rendelkezésre álló optimalizációkat; további csökkentések is lehetségesek, és ez a tartalék vissza lehet fektetni a kapacitásba vagy gazdagabb bemenetekbe. Következtetés Bemutattuk a GenPage-t, amely egy korai lépés a Netflix teljes generatív kezdőlap építési folyamatába: a felhasználói kontextust tokenizálva jelenítjük meg, és az egész kezdőlapot autoregresszíven generáljuk valós időben. Ez összeomlasztja a hagyományos többlépcsős ajánló rendszert egyetlen transformerbe, amely optimalizálható teljes körűen. Online A/B tesztek során, amelyek során egy érett, rendkívül optimalizált többlépcsős termelési rendszert hasonlítottunk meg, a GenPage statisztikailag szignifikáns nyereséget ért el a mag felhasználói elkötelezettségi mutatóján, miközben 20%-kal csökkentette a végpontok közötti szolgáltatási késleltetést. Ehhez az LLM képzés előírásának - pre-training után WBC vagy RL utáni képzés - alkalmazkodása volt szükséges, valamint egy sor terület specifikus technikák: testreszabott tokenizálás a kiszolgálási hatékonysághoz és termékkontroll, kontextus injekció és szemantikus beágyazás fúzió az entitás hideg indításához, többfokozatú fokozatos tanulás a modell frissességéhez, kényszerített dekódolás az üzleti szabályok érvényesítéséhez, és a dekódolt hatékonyság fenntartásának érdekében. Két offline megállapítás kiemelkedik. Először is, a jelenlegi rendszerünkben a bemenet gazdagítása lényegesen nagyobb előrelépést hoz, mint a model kapacitás skálázása — egy következtetés, amelyet más ipari méretű személyreszabási beállításokra is általánosan várunk, legalább amíg a rendelkezésre álló kontextust teljesen nem hasznosítik. Másodszor, az RL utáni képzés növeli a kezdőlap sokszínűségét, még akkor is, ha a sokszínűség nem része a célkitűzésnek — ami arra utal, hogy az oldal szintű optimalizálás rögzíti az interakciókat a sorok és entitások között. A teljes vízió számos eleme még mindig fejlesztés alatt áll: a hosszú kontextus még mindig kézzel készült összegzésen alapul, és a szélesebb LLM-stílusú képességek — nyelv, multimodalitás és érvelés — még nem lettek beillesztve. Egy ígéretes irány itt egy hibrid tokenizálás, amely egyesíti a terület-specifikus tokeneket a generikus szöveges tokenekkel, miközben megtartja a strukturális kontrollt, örökölve a általános célú LLM-ek erősségeit; elméletileg ez további ajánlási modality-t vezet egy LLM-be. Szélesebb értelemben azt várjuk, hogy az LLM ökoszisztéma számos fejlesztése természetesen átkonvertálva kerüljön erre a beállításra, és a határvonal egy LLM és egy ajánló rendszer között egyre inkább elmosódhat. Eredményeink azt sugallják, hogy ez egy lehetséges út a felhasználói elégedettséggel közvetlenebbül összehangolt egyszerűbb ajánlórendszerek felé. Köszönetnyilvánítás A munkához hozzájárulók (abc-rendben): Abhishek Agrawal, Baolin Li, Casey Stella, Daneo Zhang, Dan Zheng, Donnie DeBoer, Fengdi Che, Fernando Amat Gil, Grace Huang, Inbar Naor, Ishita Verma, Jason Uh, Jimmy Patel, Justin Basilico, Lanxi Huang, Lingyi Liu, Liping Peng, Louis Wang, Michelle Kislak, Nathan Kallus, Nicolas Hortiguera, Paran Jain, Qusai Al-Rabadi, Rein Houthooft, Ryan Lee, Santino Ramos, Scarlet Chen, Shaojing Li, Sheallika Singh, Si Cheng, Wei Wang és ZQ Zhang. A GenPage: A teljes generatív kezdőlap építés felé a Netflixnél eredetileg a Netflix TechBlog-on jelent meg a Medium-on, ahol az emberek továbbra is folytathatják a beszélgetést, kiemelve és válaszolva a történetre.