Dins de ByteDance's Monolith: El motor que impulsa feeds de contingut més intel·ligents i ràpids

Autors: Zhuoran Liu, Bytedance Inc. Leqi Zou, Bytedance Inc. Xuan Zou, Bytedance Inc. Caihua Wang, Bytedance Inc. Biao Zhang, Bytedance Inc. Da Tang, Bytedance Inc. Bolin Zhu∗, Universitat de Fudan Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) RESUM Construir un sistema de recomanació escalable i en temps real és vital per a moltes empreses impulsades per retroalimentació del client sensible al temps, com ara la classificació de vídeos curts o els anuncis en línia. Malgrat l'adopció omnipresent de frameworks d'aprenentatge profund a escala de producció com Ten-sorFlow o PyTorch, aquests frameworks d'ús general no compleixen les demandes empresarials en escenaris de recomanació per diverses raons: per una banda, modificar sistemes basats en paràmetres estàtics i càlculs densos per a la recomanació amb característiques dinàmiques i disperses és perjudicial per a la qualitat del model; per altra banda, aquests frameworks estan dissenyats amb l'etapa d'entrenament per lots i l'etapa de servei completament separades, impedint que el model interactuï amb la retroalimentació del client en temps real. Aquests problemes ens van portar a reexaminar els enfocaments tradicionals i explorar opcions de disseny radicalment diferents. En aquest article, presentem 1, un sistema adaptat per a l'entrenament en línia. El nostre disseny ha estat impulsat per observacions dels nostres càrregues de treball d'aplicació i entorn de producció que reflecteixen una marcada desviació d'altres sistemes de recomanació. Les nostres contribucions són múltiples: primer, hem creat una taula d'incrustació sense col·lisions amb optimitzacions com ara incrustacions expirables i filtratge de freqüència per reduir la seva empremta de memòria; segon, proporcionem una arquitectura d'entrenament en línia llesta per a producció amb alta tolerància a fallades; finalment, hem demostrat que la fiabilitat del sistema es pot bescanviar per a l'aprenentatge en temps real. Monolith s'ha implementat amb èxit al producte BytePlus Recommend2. Monolith 1 INTRODUCCIÓ La dècada passada va ser testimoni d'un auge d'empreses impulsades per tècniques de recomanació. En la recerca d'una millor experiència del client, oferir contingut personalitzat per a cada usuari individual com a resposta en temps real és un objectiu comú d'aquestes aplicacions empresarials. Per a aquest fi, la informació de la interacció més recent d'un usuari s'utilitza sovint com a entrada principal per entrenar un model, ja que representaria millor el retrat d'un usuari i faria prediccions de l'interès i els comportaments futurs de l'usuari. L'aprenentatge profund ha estat dominant els models de recomanació [ , , , , , ] ja que la gigantitat quantitat de dades d'usuari s'adapta naturalment als models neuronals massivament impulsats per dades. No obstant això, els esforços per aprofitar el poder de l'aprenentatge profund en sistemes de recomanació a nivell industrial es troben constantment amb problemes derivats de les característiques úniques de les dades derivades del comportament real de l'usuari. Aquestes dades són dràsticament diferents de les utilitzades en problemes d'aprenentatge profund convencionals com el modelatge del llenguatge o la visió per ordinador en dos aspectes: 5 6 10 12 20 21 (1) Les característiques són majoritàriament disperses, categòriques i canvien dinàmicament; (2) La distribució subjaent de les dades d'entrenament no és estacionària, també coneguda com a "Concept Drift" . Aquestes diferències han plantejat reptes únics als investigadors i enginyers que treballen en sistemes de recomanació. 1.1 Dispersió i Dinamisme Les dades per a la recomanació contenen principalment característiques categòriques disperses, algunes de les quals apareixen amb poca freqüència. La pràctica comuna de mapejar-les a un espai d'incrustació d'alta dimensionalitat donaria lloc a una sèrie de problemes: • A diferència dels models de llenguatge on el nombre de peces de paraules és limitat, la quantitat d'usuaris i elements de classificació és ordres de magnitud superior. Una taula d'incrustació tan enorme difícilment cabria en la memòria d'un sol hoste; • Pitjor encara, s'espera que la mida de la taula d'incrustació creixi amb el temps a mesura que s'admetin més usuaris i elements, mentre que frameworks com [ , ] utilitzen variables denses de mida fixa per representar la taula d'incrustació. 1 17 A la pràctica, molts sistemes adopten hashings de baixa col·lisió [ , ] com a manera de reduir la memòria i permetre el creixement d'identificadors. Això depèn d'una suposició massa idealista que els identificadors de la taula d'incrustació es distribueixen uniformement en freqüència, i les col·lisions són inofensives per a la qualitat del model. Malauradament, això poques vegades és cert per a un sistema de recomanació del món real, on un petit grup d'usuaris o elements tenen ocurrències significativament més grans. Amb el creixement orgànic de la mida de la taula d'incrustació, les possibilitats de col·lisió de claus hash augmenten i condueixen a la deterioració de la qualitat del model 3 6 . Per tant, és una demanda natural per als sistemes de recomanació a escala de producció tenir la capacitat de capturar tantes característiques com sigui possible en els seus paràmetres, i també tenir la capacitat d'ajustar elàsticament el nombre d'usuaris i elements que intenten mantenir registrat. 1.2 Distribució no estacionària Els patrons visuals i lingüístics amb prou feines es desenvolupen en una escala de temps de segles, mentre que el mateix usuari interessat en un tema pot canviar el seu zel cada minut següent. Com a resultat, la distribució subjaent de les dades d'usuari no és estacionària, un fenomen comunament referit com a "Concept Drift" . Intuitivament, la informació d'un historial més recent pot contribuir més eficaçment a predir el canvi en el comportament d'un usuari. Per mitigar l'efecte del "Concept Drift", els models de servei necessiten ser actualitzats a partir de la retroalimentació de nous usuaris el més a prop possible del temps real per reflectir l'últim interès d'un usuari. A la llum d'aquestes distincions i en observació dels problemes que sorgeixen de la nostra producció, hem dissenyat , un sistema de recomanació a gran escala per abordar aquests punts febles. Hem realitzat experiments extensos per verificar i iterar el nostre disseny a l'entorn de producció. Monolith és capaç de: Monolith (1) Proporcionar poder expressiu complet per a característiques disperses mitjançant el disseny d'una taula hash sense col·lisions i un mecanisme dinàmic d'evicció de característiques; (2) Retornar el feedback del servei a l'entrenament en temps real amb entrenament en línia. Potenciat per aquestes capacitats arquitectòniques, Monolith supera constantment els sistemes que adopten trucs hash amb col·lisions amb un ús de memòria aproximadament similar, i aconsegueix un AUC de servei en línia d'avantguarda sense sobrecarregar la potència computacional dels nostres servidors. La resta del document s'organitza de la següent manera. Primer, detallem els detalls del disseny de com Monolith aborda els reptes existents amb una taula hash sense col·lisions i entrenament en temps real a la Secció 2. Els experiments i resultats es presentaran a la Secció 3, juntament amb conclusions provades en producció i algunes discussions sobre els compromisos entre la sensibilitat al temps, la fiabilitat i la qualitat del model. La Secció 4 resumeix el treball relacionat i el compara amb Monolith. La Secció 5 conclou aquest treball. 2 DISSENY L'arquitectura general de Monolith segueix generalment l'entorn distribuït Worker- arameter erver de TensorFlow (Figura En una arquitectura Worker-PS, les màquines s'assignen diferents rols; les màquines Worker són responsables de realitzar càlculs tal com defineix el gràfic, i les màquines PS emmagatzemen paràmetres i els actualitzen d'acord amb els gradients calculats pels Workers. P S 2). En els models de recomanació, els paràmetres es classifiquen en dos conjunts: densos i dispersos. Els paràmetres densos són pesos/variables en una xarxa neuronal profunda, i els paràmetres dispersos es refereixen a taules d'incrustació que corresponen a característiques disperses. En el nostre disseny, tant els paràmetres densos com els dispersos formen part del Gràfic de TensorFlow i s'emmagatzemen als servidors de paràmetres. Similar a la Variable de TensorFlow per a paràmetres densos, hem dissenyat un conjunt d'operacions HashTable eficients, sense col·lisions i flexibles per a paràmetres dispersos. Com a complement a la limitació de TensorFlow que sorgeix de la separació entre entrenament i inferència, l'entrenament en línia escalable elàsticament de Monolith està dissenyat per sincronitzar eficaçment els paràmetres del PS d'entrenament al PS de servei en línia dins d'intervals curts, amb una garantia de robustesa del model proporcionada pel mecanisme de tolerància a fallades. 2.1 Taula Hash Un primer principi en el nostre disseny de representació de paràmetres dispersos és evitar amuntegar informació de diferents identificadors en la mateixa incrustació de mida fixa. Simular una taula d'incrustació de mida dinàmica amb una Variable de TensorFlow fora de la caixa inevitablement condueix a col·lisions d'identificadors, que s'exagera a mesura que arriben nous identificadors i la taula creix. Per tant, en lloc de basar-nos en Variable, hem desenvolupat una nova taula HashTable clau-valor per als nostres paràmetres dispersos. La nostra HashTable utilitza Cuckoo Hashmap [ ] sota el cap, que admet la inserció de noves claus sense col·lidir amb les existents. Cuckoo Hashing aconsegueix una complexitat de temps 𝑂 (1) en el pitjor dels casos per a cerques i eliminacions, i un 𝑂 (1) amortitzat esperat per a insercions. Com s'il·lustra a la Figura manté dues taules 𝑇0, 𝑇1 amb diferents funcions hash ℎ0 (𝑥), ℎ1 (𝑥), i un element s'emmagatzemaria en una d'elles. Quan s'intenta inserir un element 16 3, 𝐴 a 𝑇0, primer intenta col·locar 𝐴 a ℎ0 (𝐴); si ℎ0 (𝐴) està ocupat per un altre element 𝐵, expulsaria 𝐵 de 𝑇0 i intentaria inserir 𝐵 a 𝑇1 amb la mateixa lògica. Aquest procés es repetirà fins que tots els elements s'estabilitzin, o es produeixi un rehashing quan la inserció trobi un cicle. La reducció de l'empremta de memòria també és una consideració important en el nostre disseny. Un enfocament ingenu d'inserir cada nou identificador a la HashTable esgotaria ràpidament la memòria. L'observació de models de producció reals condueix a dues conclusions: (1) Els identificadors que apareixen només unes poques vegades tenen una contribució limitada a millorar la qualitat del model. Una observació important és que els identificadors es distribueixen en la cua llarga, on els identificadors populars poden aparèixer milions de vegades mentre que els impopulars apareixen no més de deu vegades. Les incrustacions corresponents a aquests identificadors infreqüents estan subajustades a causa de la manca de dades d'entrenament i el model no podrà fer una bona estimació basada en elles. Al final, és poc probable que aquests identificadors afectin el resultat, de manera que la qualitat del model no patirà per l'eliminació d'aquests identificadors amb baixes ocurrències; (2) Els identificadors obsolets d'un historial distant poques vegades contribueixen al model actual, ja que molts d'ells mai no es visiten. Això podria ser degut a un usuari que ja no està actiu, o a un vídeo curt que està fora de data. Emmagatzemar incrustacions per a aquests identificadors no pot ajudar al model de cap manera sinó a esgotar la nostra memòria del PS en va. Basant-nos en aquestes observacions, hem dissenyat diverses heurístiques de filtratge d'identificadors de característiques per a una implementació més eficient en memòria de HashTable: (1) Els identificadors es filtren abans d'admetre'ls a les taules d'incrustació. Tenim dos mètodes de filtratge: Primer filtrem per les seves ocurrències abans que s'insereixin com a claus, on el llindar d'ocurrències és un hiperparàmetre configurable que varia per a cada model; A més, utilitzem un filtre probabilístic que ajuda a reduir encara més l'ús de memòria; ![#Figura 4: Motor de Streaming. El bucle de retroalimentació d'informació de [Usuari → Servidor de Models → Treballador d'Entrenament → Servidor de Models → Usuari] trigaria molt de temps si seguís la ruta d'Entrenament per Lots, mentre que l'Entrenament en Línia tancaria el bucle de manera més instantània.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Els identificadors es cronometren i s'estableixen per a expirar després de no haver estat inactius durant un període de temps predefinit. El temps d'expiració també és configurable per a cada taula d'incrustació per permetre distingir característiques amb diferent sensibilitat a la informació històrica. En la nostra implementació, HashTable s'implementa com una operació de recurs de Tensor-Flow. De manera similar a Variable, les cerques i les actualitzacions també s'implementen com a operacions natives de TensorFlow per facilitar la integració i millorar la compatibilitat. 2.2 Entrenament en Línia A Monolith, l'entrenament es divideix en dues etapes (Figura 1): (1) Etapa d'entrenament per lots. Aquesta etapa funciona com un bucle d'entrenament de Tensor-Flow ordinari: En cada pas d'entrenament, un treballador d'entrenament llegeix un mini-batch d'exemples d'entrenament de l'emmagatzematge, sol·licita paràmetres del PS, realitza un pas endavant i un pas enrere, i finalment envia els paràmetres actualitzats al PS d'entrenament. Una mica diferent d'altres tasques comunes d'aprenentatge profund, només entrenem el nostre conjunt de dades per a un pas. L'entrenament per lots és útil per entrenar dades històriques quan modifiquem la nostra arquitectura de model i reentrenem el model; (2) Etapa d'entrenament en línia. Després que un model es desplega al servei en línia, l'entrenament no s'atura sinó que entra a l'etapa d'entrenament en línia. En lloc de llegir exemples en mini-batches de l'emmagatzematge, un treballador d'entrenament consumeix dades en temps real sobre la marxa i actualitza el PS d'entrenament. El PS d'entrenament sincronitza periòdicament els seus paràmetres amb el PS de servei, que tindran efecte immediat al costat de l'usuari. Això permet que el nostre model s'adapti interactiva-ment segons la retroalimentació d'un usuari en temps real. Monolith està construït amb la capacitat de canviar sense problemes entre entrenament per lots i entrenament en línia. Això és possible gràcies al nostre disseny de motor de streaming il·lustrat per la Figura 2.2.1 Motor de Streaming. 4. En el nostre disseny, utilitzem una cua de Kafka [ ] per registrar les accions dels usuaris (p. ex., Clic en un element o m'agrada un element, etc.) i una altra cua de Kafka per a les característiques. Al nucli del motor hi ha un treball de streaming de Flink [ ] per a la Unió de característiques en línia. El joiner en línia concatena les característiques amb les etiquetes de les accions de l'usuari i produeix exemples d'entrenament, que després s'escriuen en una cua de Kafka. La cua per als exemples d'entrenament és consumida tant per l'entrenament en línia com per l'entrenament per lots: 13 4 Per a l'entrenament en línia, el treballador d'entrenament llegeix directament les dades de la cua de Kafka; Per a l'entrenament per lots, un treball de bolcat de dades primer bolcarà les dades a HDFS [ ]; Després que les dades a HDFS s'acumulin fins a una certa quantitat, el treballador d'entrenament recuperarà les dades de HDFS i realitzarà l'entrenament per lots. 18 Els paràmetres actualitzats al PS d'entrenament es lliuraran al PS de servei segons el calendari de sincronització de paràmetres. En aplicacions del món real, el registre d'accions d'usuari i les característiques s'emeten al joiner en línia (Figura sense garantia d'ordre temporal. Per tant, utilitzem una clau única per a cada sol·licitud perquè l'acció de l'usuari i les característiques es puguin emparellar correctament. 2.2.2 Unió en Línia. 5) El retard de l'acció de l'usuari també pot ser un problema. Per exemple, un usuari pot trigar uns quants dies abans de decidir comprar un article que se li va presentar fa dies. Això és un repte per al joiner perquè si totes les característiques es mantinguessin a la memòria cau, simplement no cabria a la memòria. Al nostre sistema, s'utilitza un emmagatzematge clau-valor en disc per emmagatzemar característiques que esperen durant un cert període de temps. Quan arriba un registre d'acció d'usuari, primer busca a la memòria cau en memòria, i després busca a l'emmagatzematge clau-valor en cas de falta de memòria cau. Un altre problema que sorgeix en l'aplicació del món real és que la distribució d'exemples negatius i positius és molt desigual, on el nombre del primer pot ser magnituds superior al del segon. Per evitar que els exemples positius siguin aclaparats pels negatius, una estratègia comuna és fer mostreig negatiu. Això canviaria sens dubte la distribució subjaent del model entrenat, ajustant-lo cap a una major probabilitat de fer prediccions positives. Com a remei, apliquem la correcció de log-odds [ ] durant el servei, assegurant que el model en línia sigui un estimador imparcial de la distribució original. 19 Durant l'entrenament en línia, el clúster d'entrenament de Mono-lith continua rebent dades del mòdul de servei en línia i actualitza els paràmetres al PS d'entrenament. Un pas crucial per permetre que el PS de servei en línia es beneficiï d'aquests paràmetres recentment entrenats és la sincronització dels paràmetres del model actualitzats. En l'entorn de producció, ens trobem amb diversos reptes: 2.2.3 Sincronització de Paràmetres. Els models al PS de servei en línia no han d'aturar el servei quan s'actualitzen. Els nostres models en producció solen tenir diversos terabytes de mida, i com a resultat, reemplaçar tots els paràmetres triga un temps. Seria intolerable aturar un PS en línia de servir el model durant el procés de reemplaçament, i les actualitzacions s'han de fer sobre la marxa; Transferir un model de diversos terabytes en la seva totalitat des del PS d'entrenament al PS de servei en línia suposaria una gran pressió tant per a l'amplada de banda de la xarxa com per a la memòria al PS, ja que requereix una mida de memòria duplicada del model per acceptar el model entrant. Perquè l'entrenament en línia s'escali a la mida del nostre escenari empresarial, hem dissenyat un mecanisme de sincronització de paràmetres periòdic incremental sobre la marxa a Monolith basat en diverses característiques notables dels nostres models: (1) Els paràmetres dispersos dominen la mida dels models de recomanació; (2) Donat un interval de temps curt, només un petit subconjunt d'identificadors s'entrena i les seves incrustacions s'actualitzen; (3) Les variables denses es mouen molt més lentament que les incrustacions disperses. Això és degut a que en optimitzadors basats en el momentum, l'acumulació de momentum per a variables denses s'amplifica per la gigantitat mida de les dades d'entrenament de recomanació, mentre que només unes poques incrustacions disperses reben actualitzacions en un sol batch de dades. (1) i (2) ens permeten explotar les actualitzacions disperses a través de tots els identificadors de característiques. A Monolith, mantenim un conjunt hash de claus tocades, que representen identificadors les incrustacions dels quals s'han entrenat des de la darrera sincronització de paràmetres. Enviem el subconjunt de paràmetres dispersos les claus dels quals estan al conjunt de claus tocades amb un interval de temps de nivell de minut des del PS d'entrenament al PS de servei en línia. Aquest paquet relativament petit d'actualització incremental de paràmetres és lleuger per a la transmissió de xarxa i no causarà un pic de memòria brusc durant la sincronització. També explotem (3) per reduir encara més les E/S de xarxa i l'ús de memòria establint un calendari de sincronització més agressiu per als paràmetres dispersos, mentre que actualitzem els paràmetres densos amb menys freqüència. Això ens podria donar una situació on els paràmetres densos que servim són una versió relativament antiga en comparació amb la part dispersa. No obstant això, aquesta inconsistència pot ser tolerada per la raó esmentada a (3), ja que no s'ha observat cap pèrdua conspicuous. 2.3 Tolerància a Fallades Com a sistema en producció, Monolith està dissenyat amb la capacitat de recuperar un PS en cas que falli. Una elecció comuna per a la tolerància a fallades és fer una instantània de l'estat d'un model periòdicament, i recuperar-se de la darrera instantània quan es detecta una fallada del PS. L'elecció de la freqüència d'instantànies té dos impactes principals: (1) Qualitat del model. Intuitivament, la qualitat del model pateix menys la pèrdua de l'historial recent amb l'augment de la freqüència d'instantànies. (2) Sobrecàrrega computacional. Fer una instantània d'un model de diversos terabytes no és gratuït. Incorre en grans quantitats de còpies de memòria i E/S de disc. Com a compromís entre la qualitat del model i la sobrecàrrega computacional, Monolith fa una instantània de tots els PS d'entrenament cada dia. Tot i que un PS perdrà un dia d'actualització en cas de fallada, descobrim que la degradació del rendiment és tolerable a través dels nostres experiments. Analitzarem l'efecte de la fiabilitat del PS a la propera secció. 3 AVALUACIÓ Per a una millor comprensió dels beneficis i compromisos aportats pel nostre disseny proposat, hem realitzat diversos experiments a escala de producció i proves A/B amb trànsit de servei en directe per avaluar i verificar Monolith des de diferents aspectes. El nostre objectiu és respondre les següents preguntes amb els nostres experiments: (1) Quant podem beneficiar-nos d'una HashTable sense col·lisions? (2) Quina importància té l'entrenament en línia en temps real? (3) És el disseny de sincronització de paràmetres de Monolith prou robust en un escenari de producció a gran escala? En aquesta secció, presentem primer la nostra configuració experimental i després discutim els resultats i les nostres conclusions en detall. 3.1 Configuració Experimental Com es descriu a la Secció les taules d'incrustació a Monolith s'implementen com a HashTables sense col·lisions. Per provar la necessitat d'evitar col·lisions a les taules d'incrustació i quantificar els guanys de la nostra implementació sense col·lisions, hem realitzat dos grups d'experiments al conjunt de dades Movielens i al nostre conjunt de dades de producció interna respectivament: 3.1.1 Taula d'Incrustació. 2.1, (1) Conjunt de dades ml-25m [ ]. Aquest és un conjunt de dades públic estàndard per a valoracions de pel·lícules, que conté 25 milions de valoracions que involucren aproximadament 162.000 usuaris i 62.000 pel·lícules. MovieLens 11 • . Les etiquetes originals són valoracions de Preprocessament d'etiquetes 0.5 a 5.0, mentre que en producció les nostres tasques solen rebre senyals binaris dels usuaris. Per simular millor els nostres models de producció, convertim les etiquetes d'escala a etiquetes binàries tractant les puntuacions ≥ 3.5 com a mostres positives i la resta com a mostres negatives. • Model i mètriques. Hem implementat un model DeepFM estàndard, un model arquitectònic d'ús comú per a problemes de recomanació. Consisteix en un component FM i un component dens (Figura 6). Les prediccions s'avaluen mitjançant AUC, ja que aquesta és la mesura principal per als models reals. • Col·lisions d'incrustació. Aquest conjunt de dades conté aproximadament 160K identificadors d'usuari i 60K identificadors de pel·lícula. Per comparar amb la versió sense col·lisions de la implementació de la taula d'incrustació, hem realitzat un altre grup d'experiments on els identificadors es preprocessen amb hashing MD5 i després es mapegen a un espai d'identificadors més petit. Com a resultat, alguns