Dentro do Monolith da ByteDance: O Motor que Impulsiona Feeds de Conteúdo Mais Inteligentes e Rápidos

```html Autores: 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∗, Universidade de Fudan Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) RESUMO Construír un sistema de recomendación escalable e en tempo real é vital para moitas empresas que se basean en comentarios de clientes sensibles ao tempo, como a clasificación de vídeos curtos ou anuncios en liña. A pesar da adopción xeneralizada de marcos de aprendizaxe profunda a escala de produción como Ten-sorFlow ou PyTorch, estes marcos de propósito xeral non cumpren as demandas empresariais nos escenarios de recomendación por varias razóns: por unha banda, axustar os sistemas en función de parámetros estáticos e computacións densas para a recomendación con características dinámicas e esparsas prexudica a calidade do modelo; por outra banda, tales marcos están deseñados coas etapas de adestramento por lotes e servizo completamente separadas, impedindo que o modelo interactúe cos comentarios dos clientes en tempo real. Estes problemas leváronnos a reexaminar os enfoques tradicionais e a explorar opcións de deseño radicalmente diferentes. Neste artigo, presentamos 1, un sistema adaptado para o adestramento en liña. O noso deseño foi impulsado por observacións das nosas cargas de traballo de aplicacións e do noso entorno de produción, que reflicten unha marcada diferenza con outros sistemas de recomendación. As nosas contribucións son múltiples: primeiro, elaboramos unha táboa de incrustación sen colisións con optimizacións como incrustacións expirables e filtrado de frecuencia para reducir a súa pegada de memoria; segundo, proporcionamos unha arquitectura de adestramento en liña lista para produción con alta tolerancia a fallos; finalmente, probamos que a fiabilidade do sistema pode ser sacrificada pola aprendizaxe en tempo real. Monolith implantouse con éxito no produto BytePlus Recommend2. Monolith 1 INTRODUCIÓN A última década foi testemuña dun auxe de empresas impulsadas por técnicas de recomendación. Na procura dunha mellor experiencia do cliente, ofrecer contido personalizado para cada usuario individual como resposta en tempo real é un obxectivo común destas aplicacións empresariais. Para iso, a información da última interacción dun usuario úsase a miúdo como entrada principal para adestrar un modelo, xa que representaría mellor o retrato dun usuario e faría predicións sobre o interese e os comportamentos futuros do usuario. A aprendizaxe profunda dominou os modelos de recomendación [ , , , , , ] xa que a xigantesca cantidade de datos de usuario é un axuste natural para os modelos neurais masivamente impulsados por datos. Non obstante, os esforzos por aproveitar o poder da aprendizaxe profunda nos sistemas de recomendación a nivel industrial atópanse constantemente con problemas derivados das características únicas dos datos derivados do comportamento do usuario no mundo real. Estes datos difiren drasticamente dos utilizados nos problemas convencionais de aprendizaxe profunda, como a modelaxe de linguaxe ou a visión por ordenador, en dous aspectos: 5 6 10 12 20 21 (1) As características son na súa maioría esparsas, categóricas e cambian dinámicamente; (2) A distribución subxacente dos datos de adestramento non é estacionaria, tamén coñecida como Concept Drift [8]. Estas diferenzas plantexaron desafíos únicos para os investigadores e enxeñeiros que traballan en sistemas de recomendación. 1.1 Esparsidade e Dinamismo Os datos de recomendación conteñen principalmente características categóricas esparsas, algunhas das cales aparecen con baixa frecuencia. A práctica común de mapealas a un espazo de incrustación de alta dimensión daría lugar a unha serie de problemas: • A diferenza dos modelos de linguaxe onde o número de pezas de palabras é limitado, a cantidade de usuarios e elementos de clasificación é varias ordes de magnitude maior. Unha táboa de incrustación tan enorme apenas cabería na memoria dun único host; • Peor aínda, espérase que o tamaño da táboa de incrustación creza co tempo a medida que se admiten máis usuarios e elementos, mentres que os marcos como [ , ] usan variables densas de tamaño fixo para representar a táboa de incrustación. 1 17 Na práctica, moitos sistemas adoptan hash de baixa colisión [ , ] como forma de reducir a pegada de memoria e permitir o crecemento dos ID. Isto baséase nunha suposición demasiado idealista de que os ID na táboa de incrustación están distribuídos uniformemente en frecuencia e que as colisións son inofensivas para a calidade do modelo. Desafortunadamente, isto rara vez é certo para un sistema de recomendación do mundo real, onde un pequeno grupo de usuarios ou elementos teñen ocorrencias significativamente maiores. Co crecemento orgánico do tamaño da táboa de incrustación, as posibilidades de colisión de claves hash aumentan e levan á deterioración da calidade do modelo 3 6 [3]. Polo tanto, é unha demanda natural para os sistemas de recomendación a escala de produción ter a capacidade de capturar tantas características nos seus parámetros, e tamén ter a capacidade de axustar elásticamente o número de usuarios e elementos que intentan manter rexistrados. 1.2 Distribución Non Estacionaria Os patróns visuais e lingüísticos apenas se desenvolven nunha escala de tempo de séculos, mentres que o mesmo usuario interesado nun tema pode cambiar o seu entusiasmo ao minuto seguinte. Como resultado, a distribución subxacente dos datos do usuario non é estacionaria, un fenómeno comúnmente coñecido como Concept Drift [8]. Intuitivamente, a información dun historial máis recente pode contribuír máis eficazmente a predicir o cambio no comportamento dun usuario. Para mitigar o efecto do Concept Drift, os modelos de servizo necesitan ser actualizados a partir de novos comentarios dos usuarios o máis preto posible do tempo real para reflectir o último interese dun usuario. Á vista destas distincións e da observación dos problemas que xorden da nosa produción, deseñamos , un sistema de recomendación a gran escala para abordar estes puntos débiles. Levamos a cabo extensos experimentos para verificar e iterar o noso deseño no entorno de produción. Monolith é capaz de Monolith (1) Proporcionar poder expresivo completo para características esparsas mediante o deseño dunha táboa hash sen colisións e un mecanismo dinámico de saída de características; (2) Devolver o feedback do servizo ao adestramento en tempo real co adestramento en liña. Impulsado por estas capacidades arquitectónicas, Monolith supera consistentemente aos sistemas que adoptan hash-tricks con colisións cun uso de memoria aproximadamente similar, e consegue un AUC de servizo en liña de vangarda sen sobrecargar a potencia computacional dos nosos servidores. O resto do artigo organízase da seguinte forma. Primeiro detallaremos os deseños de como Monolith aborda os desafíos existentes coa táboa hash sen colisións e o adestramento en tempo real na Sección 2. Os experimentos e os resultados presentaranse na Sección 3, xunto con conclusións probadas en produción e algunhas discusións sobre compromisos entre a sensibilidade ao tempo, a fiabilidade e a calidade do modelo. A Sección 4 resume o traballo relacionado e compárao con Monolith. A Sección 5 conclúe este traballo. 2 DESEÑO A arquitectura xeral de Monolith segue en xeral a configuración Worker- arameter erver de TensorFlow (Figura Nunha arquitectura Worker-PS, as máquinas son asignadas a diferentes roles; as máquinas Worker son responsables de realizar os cálculos definidos polo gráfico, e as máquinas PS almacenan os parámetros e actualízaos segundo os gradientes calculados polos Workers. P S 2). Nos modelos de recomendación, os parámetros clasifícanse en dous conxuntos: densos e esparsos. Os parámetros densos son pesos/variables nunha rede neural profunda, e os parámetros esparsos refírense ás táboas de incrustación que corresponden a características esparsas. No noso deseño, tanto os parámetros densos como os esparsos forman parte do Gráfico de TensorFlow e almacénanse nos servidores de parámetros. Similar á Variable de TensorFlow para parámetros densos, deseñamos un conxunto de operacións HashTable eficientes, sen colisións e flexibles para parámetros esparsos. Como complemento á limitación de Tensor-Flow que xorde da separación do adestramento e a inferencia, o adestramento en liña escalable de forma elástica de Monolith está deseñado para sincronizar eficientemente os parámetros do PS de adestramento ao PS de servizo en liña dentro de intervalos curtos, coa garantía de robustez do modelo proporcionada polo mecanismo de tolerancia a fallos. 2.1 Táboa Hash Un principio fundamental no noso deseño de representación de parámetros esparsos é evitar amontoar información de diferentes ID nunha incrustación de tamaño fixo. Simular unha táboa de incrustación de tamaño dinámico cunha Variable de TensorFlow lista para usar inevitablemente leva a colisións de ID, que se agravan a medida que chegan novos ID e a táboa medra. Polo tanto, en lugar de construír sobre Variable, desenvolvemos unha nova HashTable clave-valor para os nosos parámetros esparsos. A nosa HashTable utiliza Cuckoo Hashmap [ ] internamente, que admite a inserción de novas claves sen colidir coas existentes. Cuckoo Hashing consegue unha complexidade de tempo 𝑂(1) no peor caso para buscas e eliminacións, e un tempo amortizado esperado de 𝑂(1) para insercións. Como se ilustra na Figura mantén dúas táboas 𝑇0, 𝑇1 con diferentes funcións hash ℎ0(𝑥), ℎ1(𝑥), e un elemento almacenaríase nunha ou outra delas. Ao tentar inserir un elemento 16 3, 𝐴 en 𝑇0, primeiro intenta colocar 𝐴 en ℎ0(𝐴); Se ℎ0(𝐴) está ocupado por outro elemento 𝐵, este sería desaloxado de 𝑇0 e tentaríase inserir 𝐵 en 𝑇1 coa mesma lóxica. Este proceso repetirase ata que todos os elementos se estabilicen, ou ocorra un rehash cando a inserción incorra nun ciclo. A redución da pegada de memoria tamén é unha consideración importante no noso deseño. Un enfoque inxenuo de inserir cada novo ID na HashTable esgotará a memoria rapidamente. A observación de modelos de produción reais leva a dúas conclusións: (1) Os ID que aparecen só unhas poucas veces teñen unha contribución limitada á mellora da calidade do modelo. Unha observación importante é que os ID teñen unha distribución de cola longa, onde os ID populares poden ocorrer millóns de veces mentres que os impopulares aparecen non máis de dez veces. As incrustacións correspondentes a estes ID infrecuentes están infraaxustadas debido á falta de datos de adestramento e o modelo non poderá facer unha boa estimación baseándose nelas. Ao final, é probable que estes ID non afecten o resultado, polo que a calidade do modelo non sufrirá pola eliminación destes ID con baixas ocorrencias; (2) Os ID obsoletos dun historial distante raramente contribúen ao modelo actual xa que moitos deles nunca son visitados. Isto pode deberse a un usuario que xa non está activo, ou a un vídeo curto que xa está fóra de data. Almacenar incrustacións para estes ID non axuda ao modelo de ningunha maneira, excepto por baleirar a nosa memoria de PS en balde. Baseándonos nestas observacións, deseñamos varias heurísticas de filtrado de ID de características para unha implementación máis eficiente en memoria da HashTable: (1) Os ID fíltranse antes de que sexan admitidos nas táboas de incrustación. Temos dous métodos de filtrado: primeiro, filtramos polas súas ocorrencias antes de que se insiran como claves, onde o limiar de ocorrencias é un hiperparámetro axustable que varía para cada modelo; Ademais, utilizamos un filtro probabilístico que axuda a reducir aínda máis o uso de memoria; ![#Figura 4: Motor de Streaming. O ciclo de retroalimentación de información de [Usuario → Servidor de Modelo → Traballador de Adestramento → Servidor de Modelo → Usuario] levaría moito tempo se tomase a ruta de Adestramento por Lotes, mentres que o Adestramento en Liña pecharía o ciclo de forma máis instantánea.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Os ID son temporizados e configúranse para caducar despois de estar inactivos durante un período de tempo predefinido. O tempo de caducidade tamén é axustable para cada táboa de incrustación para permitir a distinción de características con diferente sensibilidade á información histórica. Na nosa implementación, a HashTable impléntase como unha operación de recurso de TensorFlow. Similar a Variable, as buscas e actualizacións tamén se implementan como operacións nativas de TensorFlow para unha integración máis sinxela e unha mellor compatibilidade. 2.2 Adestramento en Liña En Monolith, o adestramento divídese en dúas etapas (Figura 1): (1) Etapa de adestramento por lotes. Esta etapa funciona como un bucle de adestramento ordinario de Tensor-Flow: en cada paso de adestramento, un traballador de adestramento le un mini-lote de exemplos de adestramento do almacenamento, solicita parámetros ao PS, calcula un pase cara adiante e outro cara atrás, e finalmente envíe os parámetros actualizados ao PS de adestramento. Lixeiramente diferente doutras tarefas comúns de aprendizaxe profunda, só adestramos o noso conxunto de datos para un pase. O adestramento por lotes é útil para adestrar datos históricos cando modificamos a nosa arquitectura de modelo e re-adestramos o modelo; (2) Etapa de adestramento en liña. Despois de que un modelo se implante para o servizo en liña, o adestramento non se detén, senón que entra na etapa de adestramento en liña. En lugar de ler exemplos de mini-lotes do almacenamento, un traballador de adestramento consome datos en tempo real sobre a marcha e actualiza o PS de adestramento. O PS de adestramento sincroniza periodicamente os seus parámetros co PS de servizo, que terán efecto no lado do usuario inmediatamente. Isto permite que o noso modelo se adapte interactivamente segundo os comentarios dun usuario en tempo real. Monolith está construído coa capacidade de cambiar sen problemas entre o adestramento por lotes e o adestramento en liña. Isto é posible grazas ao noso deseño de motor de streaming ilustrado na Figura 2.2.1 Motor de Streaming. 4. No noso deseño, usamos unha cola Kafka [ ] para rexistrar as accións dos usuarios (por exemplo, facer clic nun elemento ou gústalle un elemento, etc.) e outra cola Kafka para as características. No núcleo do motor hai un traballo de streaming Flink [ ] para o Union de características en liña. O union en liña concatena as características con etiquetas das accións do usuario e produce exemplos de adestramento, que despois se escriben nunha cola Kafka. A cola para os exemplos de adestramento é consumida tanto polo adestramento en liña como polo adestramento por lotes: 13 4 Para o adestramento en liña, o traballador de adestramento le directamente os datos da cola Kafka; Para o adestramento por lotes, un traballo de volcado de datos primeiro volcará os datos a HDFS [ ]; Despois de que os datos en HDFS se acumulen nunha certa cantidade, o traballador de adestramento recuperará os datos de HDFS e realizará o adestramento por lotes. 18 Os parámetros actualizados no PS de adestramento enviaranse ao PS de servizo segundo o programa de sincronización de parámetros. En aplicacións do mundo real, o rexistro de accións do usuario e as características transmítense ao union en liña (Figura sen garantía de orde temporal. Polo tanto, usamos unha clave única para cada solicitude para que a acción do usuario e as características poidan emparellarse correctamente. 2.2.2 Union en Liña. 5) O atraso da acción do usuario tamén pode ser un problema. Por exemplo, un usuario pode tardar uns días antes de decidir comprar un artigo que lle presentaron hai días. Isto é un desafío para o union, xa que se se gardan todas as características na caché, simplemente non cabería na memoria. No noso sistema, utilízase un almacenamento clave-valor no disco para gardar as características que agardan máis dun certo período de tempo. Cando chega un rexistro de acción do usuario, primeiro busca na caché en memoria e, despois, busca no almacenamento clave-valor en caso de que falte a caché. Outro problema que xorde na aplicación do mundo real é que a distribución de exemplos negativos e positivos é moi desigual, onde o número dos primeiros pode ser magnitudes de orde maior que os segundos. Para evitar que os exemplos positivos sexan abrumados polos negativos, unha estratexia común é facer mostraxe negativa. Isto certamente cambiaría a distribución subxacente do modelo adestrado, axustándoo cara a unha maior probabilidade de facer predicións positivas. Como remedio, aplicamos corrección de log-odds [ ] durante o servizo, asegurando que o modelo en liña sexa un estimador non sesgado da distribución orixinal. 19 Durante o adestramento en liña, o clúster de adestramento de Mono-lith segue recibindo datos do módulo de servizo en liña e actualiza os parámetros no PS de adestramento. Un paso crucial para que o PS de servizo en liña benefíciese destes parámetros recén adestrados é a sincronización dos parámetros do modelo actualizados. No entorno de produción, atopámonos con varios desafíos: 2.2.3 Sincronización de Parámetros. Os modelos no PS de servizo en liña non deben deixar de servir durante a actualización. Os nosos modelos en produción adoitan ter varios terabytes de tamaño e, como resultado, substituír todos os parámetros leva tempo. Sería intolerable deter un PS en liña de servir o modelo durante o proceso de substitución, e as actualizacións deben facerse sobre a marcha; Transferir un modelo de varios terabytes na súa totalidade do PS de adestramento ao PS de servizo en liña suporía unha gran presión tanto para o ancho de banda da rede como para a memoria no PS, xa que require o dobre tamaño de memoria do modelo para aceptar o modelo recén chegado. Para que o adestramento en liña escale ao tamaño do noso escenario empresarial, deseñamos un mecanismo incremental de sincronización de parámetros por lotes en tempo real en Monolith baseado en varias características notables dos nosos modelos: (1) Os parámetros esparsos dominan o tamaño dos modelos de recomendación; (2) Dado un curto período de tempo, só un pequeno subconxunto de ID se adestra e as súas incrustacións actualízanse; (3) As variables densas móvense moito máis lentamente que as incrustacións esparsas. Isto débese a que nos optimizadores baseados en momentum, a acumulación de momentum para variables densas magnifícase polo xigantesco tamaño dos datos de adestramento de recomendación, mentres que só unhas poucas incrustacións esparsas reciben actualizacións nun único lote de datos. (1) e (2) permítennos aproveitar as actualizacións esparsas en todos os ID de características. En Monolith, mantemos un conxunto hash de claves tocadas, que representan os ID cuxas incrustacións foron adestradas desde a última sincronización de parámetros. Enviamos o subconxunto de parámetros esparsos cuxas claves están no conxunto de claves tocadas cun intervalo de tempo de nivel de minuto desde o PS de adestramento ao PS de servizo en liña. Este paquete relativamente pequeno de actualización de parámetros incremental é lixeiro para a transmisión de rede e non causará un pico agudo de memoria durante a sincronización. Tamén aproveitamos (3) para reducir aínda máis a E/S de rede e o uso de memoria establecendo un programa de sincronización máis agresivo para parámetros esparsos, mentres que actualizamos parámetros densos con menos frecuencia. Isto podería ofrecer unha situación na que os parámetros densos que servimos sexan unha versión relativamente desactualizada en comparación coa parte esparsa. Non obstante, tal inconsistencia podería ser tolerable debido á razón mencionada en (3), xa que non se observou ningunha perda conspicua. 2.3 Tolerancia a Fallos Como sistema en produción, Monolith está deseñado coa capacidade de recuperar un PS en caso de fallo. Unha opción común para a tolerancia a fallos é facer instantáneas do estado dun modelo periodicamente e recuperarse da última instantánea cando se detecta un fallo do PS. A elección da frecuencia de instantáneas ten dous impactos importantes: (1) Calidade do modelo. Intuitivamente, a calidade do modelo sofre menos pola perda do historial recente cunha maior frecuencia de instantáneas. (2) Sobrecarga computacional. Facer unha instantánea dun modelo de varios terabytes non é gratuíto. Incorre en grandes fragmentos de copia de memoria e E/S de disco. Como compromiso entre a calidade do modelo e a sobrecarga computacional, Monolith fai instantáneas de todos os PS de adestramento todos os días. Aínda que un PS perderá un día de actualización en caso de fallo, descubrimos que a degradación do rendemento é tolerable a través dos nosos experimentos. Analizaremos o efecto da fiabilidade do PS na seguinte sección. 3 AVALIACIÓN Para comprender mellor os beneficios e os compromisos que achega o noso deseño proposto, realizamos varios experimentos a escala de produción e probas A/B con tráfico de servizo en directo para avaliar e verificar Monolith desde diferentes aspectos. Pretendemos responder ás seguintes preguntas cos nosos experimentos: (1) Canto podemos beneficiarnos dunha táboa hash sen colisións? (2) Que importancia ten o adestramento en liña en tempo real? (3) O deseño de sincronización de parámetros de Monolith é suficientemente robusto nun escenario de produción a gran escala? Nesta sección, primeiro presentamos a nosa configuración experimental e despois discutimos os resultados e as nosas conclusións en detalle. 3.1 Configuración Experimental Como se describe na Sección as táboas de incrustación en Monolith impĺementanse como HashTables sen colisións. Para probar a necesidade de evitar colisións nas táboas de incrustación e cuantificar os beneficios da nosa implementación sen colisións, realizamos dous grupos de experimentos no conxunto de datos Movielens e no noso conxunto de datos de produción interno respectivamente: 3.1.1 Táboa de Incrustación. 2.1, (1) ml-25m dataset [ ]. Este é un conxunto de datos público estándar para valoracións de películas, que contén 25 millóns de valoracións que involucran aproximadamente 162.000 usuarios e 62.000 películas. MovieLens 11 • . As etiquetas orixinais son valoracións de Preprocesamento de etiquetas 0.5 a 5.0, mentres que en produción as nosas tarefas son principalmente recibir sinais binarios dos usuarios. Para simular mellor os nosos modelos de produción, convertemos as etiquetas de escala a etiquetas binarias tratando as puntuacións ≥ 3.5 como mostras positivas e o resto como negativas. • Modelo e métricas. Implementamos un modelo DeepFM [9] estándar, unha arquitectura de modelo de uso común para problemas de recomendación. Consiste nun compoñente FM e un compoñente denso (Figura 6). As predicións avalíanse por AUC [2], xa que esta é a principal medida para os modelos reais. • Colisións de incrustación. Este conxunto de datos contén aproximadamente 160K ID de usuario e 60K ID de película. Para comparar coa versión sen colisións da implementación da táboa de incrustación, realizamos outro grupo de experimentos onde os ID se preprocesan con hash MD5 e despois se mapean a un espazo de ID máis pequeno. Como resultado, algúns ID compartirán a súa incrustación con outros. A táboa 1 mostra estatísticas detalladas dos ID de usuario e película antes e despois do hash. (2) . Conxunto de datos de recomendación interno Tamén realizamos experimentos cun modelo de recomendación no entorno de produción. Este modelo segue xeralmente unha arquitectura de multi-torre, con cada torre responsable de aprender a predicir un tipo especializado de comportamento do usuario. Cada modelo ten ao redor de 1000 táboas de incrustación, e a distribución do tamaño das táboas de incrustación é moi desigual; O espazo de ID orixinal da táboa de incrustación era 248. Na nosa liña base, aplicamos un truco de hash descompoñéndoo para frear o tamaño da táboa de incrustación. Para ser máis específicos, usamos dúas táboas de incrustación máis pequenas en lugar dunha xigantesca para xerar unha incrustación única para cada ID mediante a combinación vectorial: onde 𝐸𝑟 , 𝐸𝑞 son incrustacións correspondentes a 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Isto reduce efectivamente os tamaños das táboas de incrustación de 248 a 225; • Este modelo está a servir en produción real, e o rendemento deste experimento mídase polo AUC en liña co tráfico de servizo real. Durante o adestramento en liña, actualizamos o noso PS de servizo en liña co último conxunto de parámetros con intervalos de nivel de minuto. Deseñamos dous grupos de experimentos para verificar a calidade do modelo e a robustez do sistema. 3.1.2 Adestramento en Liña. (1) . Para investigar a necesidade dunha frecuencia de actualización de nivel de minuto, realizamos experimentos que sincronizan parámetros do modelo de adestramento ao modelo de predición con diferentes intervalos. Frecuencia de actualización O conxunto de datos que usamos é o Criteo Display Ads Challenge dataset3, un conxunto de datos a gran escala para comparar modelos CTR. Contén 7 días de datos ordenados cronoloxicamente que rexistran características e accións de clics. Para este experimento, usamos un modelo DeepFM [9] estándar como se describe en 6. Para simular o adestramento en liña, fixemos o seguinte preprocesamento para o conxunto de datos. Tomamos 7 días de datos do conxunto de datos e dividímolo en dúas partes: 5 días de datos para adestramento por lotes e 2 días para adestramento en liña. Ademais, dividimos os 2 días de datos en 𝑁 fragmentos cronoloxicamente. O adestramento en liña simúlase mediante o algoritmo 1. Como tal, simulamos a sincronización de parámetros adestrados co PS de servizo en liña cun intervalo determinado polo número de fragmentos de datos. Experimentamos con 𝑁 = 10, 50, 100, que corresponden aproximadamente a intervalos de actualización de 5h, 1h e 30min. (2) . Ademais, tamén realizamos un experimento en directo con tráfico de servizo real para demostrar aínda máis a importancia do adestramento en liña na aplicación do mundo real. Este experimento A/B compara o adestramento en liña co adestramento por lotes nun dos nosos modelos de anuncios en produción. Experimento en directo 3.2 Resultados e Análise 3.2.1