DLRMv4: új MLPerf Training benchmark a sorozatalapú ajánlórendszerekhez

A DLRMv4 a modern ajánlórendszerekhez igazodik

Az MLPerf Training korábbi ajánlórendszeres benchmarkja, a DLRMv2, azt méri, mennyi idő alatt képes egy rendszer egy személyre szabott ajánlási modellt egy meghatározott minőségi célértékig betanítani. A modell a felhasználói viselkedést és az elemek jellemzőit kapcsolja össze, hogy relevánsabb ajánlásokat készítsen például e-kereskedelmi oldalakon és streamingplatformokon.

Az MLCommons szerint a nagy léptékű gyártási rendszerek közben egyre inkább a felhasználók legutóbbi interakcióinak eseménysorozatait használják. A korábbi megközelítések ezeket az előzményeket összesített, sűrű jellemzőkké tömörítették. A DLRMv4 ezt a változást követi, így a benchmark a hosszú felhasználói előzmények feldolgozását és a nagy embeddingtáblák kezelését is méri.

Az MLCommons október 1-jén közzétett bemutatója szerint a DLRMv4 a DLRMv3 inference benchmarkban már használt HSTU-alapú megközelítéshez igazodik. A cél az, hogy a betanítási mérés is lefedje ezt a gyorsan bővülő, gyártási környezetben használt modellkategóriát.

A HSTU közvetlenül a felhasználói előzményeket dolgozza fel

A HSTU felváltja a DLRMv2-re jellemző, előbb kódoló, majd jellemzőket kölcsönhatásba hozó felépítést. A kategória- és lassan változó jellemzők egy közös idősorrá állnak össze, amelyben a felhasználó korábbi elemei és az azokon végrehajtott műveletek időrendben szerepelnek.

Az eseménysorozat egyes elemei tokenként jelennek meg. Egy token tartalmazhatja, hogy melyik elemhez kapcsolódott az interakció, mit tett a felhasználó, és mikor történt az esemény. Így egy negatív jelzés, például egy kihagyás, önálló eseményként marad meg, ahelyett hogy egy összesített számlálóban tűnne el.

A modell a vizsgált ajánlási jelöltet a sorozat végére illeszti, majd egyetlen oksági blokkban dolgozza fel a felhasználói előzményeket, a környezetet és a jelöltet. Az MLCommons leírása alapján a HSTU rétegei vetítést, a pozíció és az időbeli távolság alapján módosított figyelmet, valamint kapuzott transzformációt egyesítenek. A modell fő skálázási tengelyei a mélység, a szélesség és a sorozathossz.

A Yambda-5B csaknem 4,79 milliárd interakciót tartalmaz

A DLRMv4 a Yandex Music által nyilvánosan kiadott Yambda-5B adatkészlet teljes, 5 milliárd eseményes változatát használja. Az adathalmaz körülbelül 4,79 milliárd interakciót tartalmaz 1 millió felhasználótól és 9,39 millió elemtől. Ötféle viselkedést rögzít: hallgatást, kedvelést, nemtetszést, a kedvelés visszavonását és a nemtetszés visszavonását.

A nyers adatok mérete körülbelül 38 GB, egy esemény pedig hozzávetőleg 20 bájtot foglal. A korábbi, Criteo 1TB adatkészletre épülő DLRMv2-höz képest a Yambda-5B per felhasználó rekonstruálható idővonalakat biztosít, ezért alkalmasabb a sorozatalapú HSTU-modell mérésére.

Az MLCommons a négy eredeti ritka jellemzőt, az elemet, az előadót, az albumot és a felhasználói azonosítót kereszttermékes, hash-elt táblákkal egészítette ki. Ilyen például a felhasználó és az előadó, illetve az elem és a napszak kombinációja. A bővítés után az embeddingtáblák mérete hozzávetőleg 560 GB, 512-es embeddingdimenzió és fp32 pontosság mellett.

A benchmark a nagy embeddingtáblák elosztását is próbára teszi

A DLRMv4 adatai a valós ajánlási forgalom egy fontos tulajdonságát is megőrzik. Az interakciók erősen koncentrálódnak, vagyis kevés elemhez kapcsolódik az események jelentős része. Az MLCommons egy körülbelül 205 ezer valós interakcióból álló mintán vizsgálta, milyen gyakran olvassák az elem-, előadó- és albumtáblák egyes sorait.

A három tábla mindegyike közel Zipf-eloszlást követett. A leggyakrabban elért sorok felső 1 százaléka az embedding-lekérdezések 52 és 68 százaléka közötti részét adta, míg a felső 10 százalék több mint 90 százalékot fedett le. Ez a terhelési minta a több modern gyorsítóra szétosztott embeddingtáblák kezelését a benchmark egyik központi feladatává teszi.

A felhasználók és a fejlesztők számára a változás azt jelenti, hogy az MLPerf Training új mérése a korábbinál közelebb kerül azokhoz az ajánlórendszerekhez, amelyek hosszú interakciós előzményeket és nagyméretű embeddingtáblákat használnak. A piac számára a DLRMv4 egységesebb összehasonlítást adhat az ilyen rendszerek betanításához szükséges hardveres teljesítményről, a benchmark által lefedett munkaterhelés keretein belül.