Az MLCommons új ajánlási benchmarkot mutatott be, 560 GB-os embeddingtáblával

A DLRMv4 a szekvenciaalapú ajánlásra fókuszál

Az MLPerf Training korábbi DLRM benchmarkjai azt mérik, mennyi idő alatt tanít be egy rendszer egy személyre szabott ajánlási modellt egy meghatározott minőségi cél eléréséig. A DLRMv2 olyan rendszereket modellez, amelyek a felhasználói viselkedésből és az elemek jellemzőiből készítenek ajánlásokat, majd mélytanulással vizsgálják a közöttük lévő kapcsolatokat.

Az MLCommons szerint a nagy léptékű, éles ajánlórendszerek közben egyre inkább a felhasználók legutóbbi interakcióinak eseménysorozataként kezelik az előzményeket. A korábbi megoldások ezeket gyakran összesített, sűrű jellemzőkké alakították. A DLRMv4 ezt a változást követi, és a korábbi jellemző-interakciós felépítést a HSTU-val váltja fel.

A HSTU a felhasználó interakciós előzményeit közvetlenül sorozatként dolgozza fel. Az MLCommons ezzel egy olyan tanítási benchmark hiányát pótolja, amely az MLPerf Inference HSTU-alapú méréséhez hasonló, termelési környezetben használt modellosztályt képvisel.

Egy modellben jelenik meg az előzmény és a jelölt elem

A korábbi DLRM-architektúrában a numerikus jellemzőket alsó MLP-k, a kategóriaazonosítókat embedding-keresések dolgozzák fel. Ezek eredményeit egy külön interakciós modul, például kereszt- vagy faktorizációs hálózat kezeli. Ez a felépítés előre összesített jellemzőkre támaszkodik, ezért nem látja közvetlenül a felhasználói viselkedés teljes időbeli folyamatát.

HSTU esetében a kategória- és a lassan változó jellemzők egységes idősort alkotnak. Az események tokenként kerülnek a sorozatba, és tartalmazzák az érintett elemet, a felhasználó műveletét és az esemény időpontját. Így például egy kihagyás önálló negatív jelzésként marad meg, ahelyett hogy egy összesített számlálóba olvadna.

A sorozat elején néhány prefix token tartalmazza a felhasználó azonosítóját és az előre kiszámított keresztezett jellemzőket. A vizsgált jelölt elem a sorozat végére kerül. A modell ezután egyetlen oksági blokkon keresztül dolgozza fel az előzményt, a kontextust és a jelöltet, majd a jelölt pozícióján létrejövő reprezentációból készül az elköteleződési előrejelzés.

A Yambda-5B több mint 4,79 milliárd interakciót tartalmaz

A DLRMv4 tanítása a Yandex Music által nyilvánosan kiadott Yambda-5B adatkészlet teljes, 5 milliárd eseményes változatán történik. Az adatkészlet körülbelül 4,79 milliárd interakciót, 1 millió felhasználót és 9,39 millió elemet tartalmaz. Öt viselkedéstípust különböztet meg: hallgatást, kedvelést, nem kedvelést, a kedvelés visszavonását és a nem kedvelés visszavonását. A nyers adatok mérete körülbelül 38 GB, az eseményenkénti adatmennyiség nagyjából 20 bájt.

A Criteo 1TB adatkészletéhez képest a Yambda-5B olyan felhasználói idővonalat biztosít, amely alkalmas a szekvenciaalapú HSTU-modell tanítására. Az MLCommons a négy natív ritka jellemzőt, az elemet, az előadót, az albumot és a felhasználói azonosítót, keresztszorzatos, hash-elt táblákkal egészítette ki.

A bővítés után az embeddingtáblák mérete körülbelül 560 GiB, 512-es embeddingdimenzió és fp32 pontosság mellett. A táblák között szerepelnek például a felhasználó és az előadó, a felhasználó és az album, az elem és a napszak, valamint a felhasználó, az előadó és az óra keresztezései.

A benchmark a hosszú előzményeket és az embeddingek szétosztását is méri

Az MLCommons elemzése szerint a Yambda-5B adatai a valós ajánlási forgalomhoz hasonlóan erősen torzítottak. Az interakciók jelentős részét az elemek kis része adja. Egy körülbelül 205 ezer valós interakcióból álló mintában az elem-, előadó- és albumtáblák mindegyike követte a klasszikus Zipf-eloszlást.

A leggyakrabban elért sorok a felhasználói előzmények átfedései miatt még nagyobb terhelést kapnak. A legfelső 1 százalék a lekérdezések 52 és 68 százaléka közötti részét, a legfelső 10 százalék pedig több mint 90 százalékát adta. Ez az eloszlás az embeddingek több gyorsítóra történő szétosztását, vagyis a shardingot is a benchmark fontos részévé teszi.

A DLRMv4 így a forrás szerint a modern ajánlási rendszerek két meghatározó terhelését együtt képviseli: a hosszú felhasználói előzmények feletti figyelmi számításokat és a nagy méretű embeddingtáblák kezelését.