Всередині моноліту ByteDance: двигун, що живить розумніші, швидші стрічки контенту

```html Автори: Чжуоран Лю, Bytedance Inc. Леці Цзоу, Bytedance Inc. Сюань Цзоу, Bytedance Inc. Цайхуа Ван, Bytedance Inc. Біао Чжан, Bytedance Inc. Да Тан, Bytedance Inc. Болін Чжу∗, Фуданський університет Їцзі Чжу, Bytedance Inc. Пен Ву, Bytedance Inc. Ке Ван, Bytedance Inc. Юлонг Ченґ†, Bytedance Inc. (youlong.cheng@bytedance.com) АНОТАЦІЯ Побудова масштабованої системи рекомендацій у реальному часі є життєво важливою для багатьох бізнесів, керованих чутливим до часу відгуком клієнтів, таких як ранжування коротких відео або онлайн-реклама. Незважаючи на повсюдне впровадження великомасштабних фреймворків глибокого навчання, таких як Ten-sorFlow або PyTorch, ці загального призначення фреймворки не відповідають бізнес-вимогам у сценаріях рекомендацій з різних причин: з одного боку, налаштування систем на основі статичних параметрів та щільних обчислень для рекомендацій з динамічними та розрідженими ознаками шкодить якості моделі; з іншого боку, такі фреймворки розроблені з повним розділенням етапів пакетного навчання та обслуговування, що заважає моделі взаємодіяти з відгуками клієнтів у реальному часі. Ці проблеми змусили нас переглянути традиційні підходи та дослідити радикально різні дизайнерські рішення. У цій статті ми представляємо 1, систему, адаптовану для онлайн-навчання. Наш дизайн базується на спостереженнях за нашими робочими навантаженнями додатків та виробничим середовищем, що відображає помітний відхід від інших систем рекомендацій. Наш внесок багатогранний: по-перше, ми створили таблицю вкладень без колізій з оптимізаціями, такими як тимчасові вкладення та фільтрація за частотою, щоб зменшити її обсяг пам'яті; по-друге, ми надаємо готову до використання архітектуру онлайн-навчання з високою відмовостійкістю; нарешті, ми довели, що надійність системи може бути використана для навчання в реальному часі. Monolith успішно інтегровано в продукт BytePlus Recommend2. Monolith 1 ВСТУП Минуле десятиліття стало свідком буму бізнесів, що базуються на рекомендаційних техніках. Прагнучи до кращого клієнтського досвіду, персоналізований контент для кожного окремого користувача як реакція в реальному часі є спільною метою цих бізнес-додатків. Для цього інформація з останньої взаємодії користувача часто використовується як основний вхідний сигнал для навчання моделі, оскільки вона найкраще відображає профіль користувача та прогнозує інтереси та майбутню поведінку користувача. Глибоке навчання домінує в рекомендаційних моделях [ , , , , , ], оскільки величезна кількість даних користувачів природно підходить для масивно керованих нейронних моделей. Однак зусилля з використання потужності глибокого навчання в промислових рекомендаційних системах постійно стикаються з проблемами, що виникають через унікальні характеристики даних, отриманих з реальної поведінки користувачів. Ці дані кардинально відрізняються від даних, що використовуються у звичайних завданнях глибокого навчання, таких як моделювання мови або комп'ютерний зір, у двох аспектах: 5 6 10 12 20 21 (1) Ознаки переважно розріджені, категоріальні та динамічно змінюються; (2) Базовий розподіл навчальних даних є нестаціонарним, також відомий як дрейф концепції [8]. Такі відмінності створили унікальні виклики для дослідників та інженерів, що працюють над системами рекомендацій. 1.1 Розрідженість та динамічність Дані для рекомендацій переважно містять розріджені категоріальні ознаки, деякі з яких з'являються з низькою частотою. Стандартна практика відображення їх у високорозмірний простір вкладень призводить до низки проблем: • На відміну від мовних моделей, де кількість частин слів обмежена, кількість користувачів та елементів для ранжування на порядки більша. Така величезна таблиця вкладень навряд чи вміститься в пам'ять одного хоста; • Що ще гірше, розмір таблиці вкладень очікується зростати з часом, оскільки додається більше користувачів та елементів, тоді як фреймворки, як-от [ , ], використовують щільні змінні фіксованого розміру для представлення таблиці вкладень. 1 17 На практиці багато систем використовують хешування з низьким рівнем колізій [ , ] як спосіб зменшити обсяг пам'яті та дозволити зростання ідентифікаторів. Це базується на надмірно ідеалістичному припущенні, що ідентифікатори в таблиці вкладень розподілені рівномірно за частотою, і колізії не шкодять якості моделі. На жаль, це рідко буває правдою для реальних систем рекомендацій, де невелика група користувачів або елементів має значно більше випадків появи. З органічним зростанням розміру таблиці вкладень шанси колізії хеш-ключів зростають і призводять до погіршення якості моделі 3 6 [3]. Тому природною вимогою для великомасштабних систем рекомендацій є здатність захоплювати якомога більше ознак у своїх параметрах, а також можливість еластично регулювати кількість користувачів та елементів, які вони намагаються відстежувати. 1.2 Нестаціонарний розподіл Візуальні та мовні патерни ледь розвиваються за масштабом століть, тоді як той самий користувач, зацікавлений в одній темі, може змінити свої уподобання щохвилини. В результаті базовий розподіл даних користувачів є нестаціонарним, явище, яке часто називають дрейфом концепції [8]. Інтуїтивно, інформація з більш недавньої історії може ефективніше сприяти прогнозуванню змін у поведінці користувача. Щоб зменшити вплив дрейфу концепції, моделі обслуговування повинні оновлюватися на основі нових відгуків користувачів якомога ближче до реального часу, щоб відображати останні інтереси користувача. З огляду на ці відмінності та спостереження за проблемами, що виникають у нашій виробничій діяльності, ми розробили , великомасштабну систему рекомендацій для вирішення цих проблем. Ми провели масштабні експерименти для перевірки та ітерації нашого дизайну в виробничому середовищі. Monolith здатний Monolith (1) Забезпечити повну виразну потужність для розріджених ознак шляхом розробки хеш-таблиці без колізій та механізму динамічного виключення ознак; (2) Повертати відгуки обслуговування до навчання в реальному часі за допомогою онлайн-навчання. Завдяки цим архітектурним можливостям Monolith стабільно перевершує системи, що використовують хеш-трики з колізіями, з приблизно подібним використанням пам'яті, і досягає найсучаснішого онлайн-обслуговування AUC без надмірного навантаження на обчислювальну потужність наших серверів. Решта статті організована наступним чином. Спочатку ми детально описуємо дизайн того, як Monolith вирішує існуючі проблеми за допомогою хеш-таблиці без колізій та навчання в реальному часі в Розділі 2. Експерименти та результати будуть представлені в Розділі 3, разом з висновками, перевіреними на практиці, та деякими обговореннями компромісів між чутливістю до часу, надійністю та якістю моделі. Розділ 4 узагальнює пов'язані роботи та порівнює їх з Monolith. Розділ 5 підсумовує цю роботу. 2 ДИЗАЙН Загальна архітектура Monolith загалом відповідає розподіленій моделі Worker- arameter erver TensorFlow (Малюнок У архітектурі Worker-PS машини мають різні ролі; машини Worker відповідають за виконання обчислень, визначених графом, а машини PS зберігають параметри та оновлюють їх відповідно до градієнтів, обчислених Workers. P S 2). У рекомендаційних моделях параметри класифікуються на дві групи: щільні та розріджені. Щільні параметри — це ваги/змінні в глибокій нейронній мережі, а розріджені параметри відносяться до таблиць вкладень, які відповідають розрідженим ознакам. У нашому дизайні як щільні, так і розріджені параметри є частиною графа TensorFlow і зберігаються на серверах параметрів. Подібно до змінної TensorFlow для щільних параметрів, ми розробили набір високоефективних, без колізій та гнучких операцій HashTable для розріджених параметрів. Як доповнення до обмежень TensorFlow, що виникають через розділення навчання та висновку, еластично масштабоване онлайн-навчання Monolith розроблено для ефективної синхронізації параметрів з навчального PS до онлайн-сервісного PS протягом коротких інтервалів, з гарантією надійності моделі, що забезпечується механізмом відмовостійкості. 2.1 Хеш-таблиця Першим принципом нашого дизайну представлення розріджених параметрів є уникнення змішування інформації з різних ідентифікаторів в одне вкладення фіксованого розміру. Імітація таблиці вкладень динамічного розміру за допомогою стандартної змінної TensorFlow неминуче призводить до колізії ідентифікаторів, яка посилюється з появою нових ідентифікаторів та зростанням таблиці. Тому, замість того, щоб будувати на змінній, ми розробили нову хеш-таблицю ключ-значення для наших розріджених параметрів. Наша HashTable використовує Cuckoo Hashmap [ ] в основі, яка підтримує вставку нових ключів без колізій з існуючими. Cuckoo Hashing досягає найгіршого випадку 𝑂 (1) часу для пошуку та видалення, та очікуваного амортизованого 𝑂 (1) часу для вставки. Як проілюстровано на Малюнку , вона підтримує дві таблиці 𝑇0, 𝑇1 з різними хеш-функціями ℎ0 (𝑥), ℎ1 (𝑥), і елемент буде зберігатися в одній з них. При спробі вставити елемент 16 3 𝐴 в 𝑇0, вона спочатку намагається розмістити 𝐴 в ℎ0 (𝐴); якщо ℎ0 (𝐴) зайнято іншим елементом 𝐵, вона витісняє 𝐵 з 𝑇0 і намагається вставити 𝐵 в 𝑇1 за тим же логікою. Цей процес повторюватиметься до тих пір, поки всі елементи не стабілізуються, або не відбудеться повторне хешування, коли вставка потрапить у цикл. Зменшення обсягу пам'яті також є важливим фактором у нашому дизайні. Простий підхід вставки кожного нового ідентифікатора в HashTable швидко вичерпає пам'ять. Спостереження за реальними моделями виробництва призвели до двох висновків: (1) Ідентифікатори, що з'являються лише кілька разів, мають обмежений внесок у покращення якості моделі. Важливим спостереженням є те, що ідентифікатори розподілені за довгим хвостом, де популярні ідентифікатори можуть зустрічатися мільйони разів, тоді як непопулярні з'являються не більше десяти разів. Вкладення, що відповідають цим рідкісним ідентифікаторам, недонавчаються через брак навчальних даних, і модель не зможе зробити хорошу оцінку на їх основі. В кінцевому підсумку ці ідентифікатори навряд чи вплинуть на результат, тому якість моделі не постраждає від видалення цих ідентифікаторів з низькою частотою появи; (2) Застарілі ідентифікатори з далекого минулого рідко сприяють поточній моделі, оскільки багато з них ніколи не відвідуються. Це може бути пов'язано з тим, що користувач більше не активний, або короткий відеоролик застарів. Зберігання вкладень для цих ідентифікаторів ніяк не допоможе моделі, крім марної витрати пам'яті на нашому PS. На основі цих спостережень ми розробили кілька евристик фільтрації ідентифікаторів ознак для більш ефективної з точки зору пам'яті реалізації HashTable: (1) Ідентифікатори фільтруються перед тим, як вони будуть прийняті до таблиць вкладень. У нас є два методи фільтрації: спочатку ми фільтруємо за їхньою частотою появи перед їх вставкою як ключі, де порогове значення частоти появи є налаштовуваним гіперпараметром, що варіюється для кожної моделі; Крім того, ми використовуємо ймовірнісний фільтр, який допомагає додатково зменшити використання пам'яті; ![#Figure 4: Streaming Engine. Петля зворотного зв'язку інформації від [Користувач → Сервер моделі → Навчальний Worker → Сервер моделі → Користувач] витрачає багато часу при використанні шляху пакетного навчання, тоді як онлайн-навчання закриває петлю більш миттєво.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Ідентифікатори мають часові позначки і встановлюються на видалення після певного періоду неактивності. Час видалення також налаштовується для кожної таблиці вкладень, щоб дозволити розрізняти ознаки з різною чутливістю до історичної інформації. У нашій реалізації HashTable реалізована як операція ресурсу TensorFlow. Подібно до змінної, пошук та оновлення також реалізовані як нативні операції TensorFlow для легшої інтеграції та кращої сумісності. 2.2 Онлайн-навчання У Monolith навчання розділено на два етапи (Малюнок 1): (1) Етап пакетного навчання. Цей етап працює як звичайний цикл навчання TensorFlow: на кожному кроці навчання worker читає міні-пакет навчальних прикладів зі сховища, запитує параметри у PS, обчислює прямий та зворотний проходи, і нарешті передає оновлені параметри до навчального PS. Трохи відрізняючись від інших звичайних завдань глибокого навчання, ми тренуємо наш набір даних лише один раз. Пакетне навчання корисне для навчання історичних даних, коли ми модифікуємо архітектуру нашої моделі та перенавчаємо модель; (2) Етап онлайн-навчання. Після розгортання моделі для онлайн-обслуговування, навчання не припиняється, а переходить на етап онлайн-навчання. Замість читання міні-пакетів прикладів зі сховища, worker споживає дані в реальному часі на льоту та оновлює навчальний PS. Навчальний PS періодично синхронізує свої параметри з сервісним PS, що негайно набуває чинності для користувача. Це дозволяє нашій моделі інтерактивно адаптуватися відповідно до відгуків користувача в реальному часі. Monolith побудований з можливістю безперебійного перемикання між пакетним та онлайн-навчанням. Це забезпечується нашим дизайном потокового рушія, як проілюстровано на Малюнку 2.2.1 Потоковий рушій. 4. У нашому дизайні ми використовуємо одну чергу Kafka [ ] для логування дій користувачів (наприклад, клік на елемент або лайк елемента тощо) та іншу чергу Kafka для ознак. В основі рушія лежить потокове завдання Flink [ ] для онлайн-об'єднувача ознак. Онлайн-об'єднувач об'єднує ознаки з мітками з дій користувачів та генерує навчальні приклади, які потім записуються в чергу Kafka. Черга для навчальних прикладів споживається як онлайн-навчанням, так і пакетним навчанням: 13 4 Для онлайн-навчання worker безпосередньо читає дані з черги Kafka; Для пакетного навчання завдання скидання даних спочатку скидає дані в HDFS [ ]; Після накопичення певної кількості даних в HDFS, worker отримує дані з HDFS і виконує пакетне навчання. 18 Оновлені параметри в навчальному PS передаються до сервісного PS відповідно до розкладу синхронізації параметрів. У реальних додатках журнали дій користувачів та ознаки передаються в онлайн-об'єднувач (Малюнок без гарантії хронологічного порядку. Тому ми використовуємо унікальний ключ для кожного запиту, щоб дії користувача та ознаки могли правильно поєднуватися. 2.2.2 Онлайн-об'єднувач. 5) Затримка дій користувача також може бути проблемою. Наприклад, користувач може витратити кілька днів, перш ніж вирішить купити товар, представлений йому кілька днів тому. Це виклик для об'єднувача, оскільки якщо всі ознаки зберігаються в кеші, він просто не вміститься в пам'ять. У нашій системі використовується позадискове сховище ключ-значення для зберігання ознак, які чекають довше певного періоду часу. Коли надходить журнал дій користувача, він спочатку шукає в кеші пам'яті, а потім шукає в сховищі ключ-значення у разі відсутності в кеші. Ще одна проблема, яка виникає в реальних додатках, полягає в тому, що розподіл негативних та позитивних прикладів є дуже нерівномірним, причому кількість перших може бути на порядок вищою, ніж останніх. Щоб запобігти перевантаженню позитивних прикладів негативними, загальною стратегією є негативне вибіркове взяття. Це, безумовно, змінить базовий розподіл навченого моделі, налаштувавши його на вищу ймовірність позитивних прогнозів. Як засіб виправлення, ми застосовуємо корекцію лог-одів [ ] під час обслуговування, забезпечуючи, що онлайн-модель є неупередженою оцінкою початкового розподілу. 19 Під час онлайн-навчання кластер Monolith продовжує отримувати дані з модуля онлайн-обслуговування та оновлювати параметри на навчальному PS. Критично важливим кроком для того, щоб навчальний PS міг отримати переваги від цих новонавчених параметрів, є синхронізація оновлених параметрів моделі. У виробничому середовищі ми стикаємося з кількома проблемами: 2.2.3 Синхронізація параметрів. Моделі на онлайн-сервісному PS не повинні припиняти обслуговування під час оновлення. Наші моделі у виробництві зазвичай мають розмір у кілька терабайтів, і в результаті заміна всіх параметрів займає деякий час. Було б неприпустимо зупиняти онлайн-PS від обслуговування моделі під час процесу заміни, і оновлення повинні відбуватися на льоту; Передача моделі розміром у кілька терабайтів від навчального PS до онлайн-сервісного PS створить величезний тиск як на пропускну здатність мережі, так і на пам'ять на PS, оскільки це вимагає подвійного розміру пам'яті моделі для прийому нової моделі. Для масштабування онлайн-навчання до розміру нашого бізнес-сценарію ми розробили механізм інкрементальної періодичної синхронізації параметрів на льоту в Monolith на основі кількох помітних характеристик наших моделей: (1) Розріджені параметри домінують у розмірі рекомендаційних моделей; (2) При заданому короткому часовому вікні лише невелика підмножина ідентифікаторів тренується, і їх вкладення оновлюються; (3) Щільні змінні рухаються набагато повільніше, ніж розріджені вкладення. Це пояснюється тим, що в оптимізаторах на основі імпульсу накопичення імпульсу для щільних змінних збільшується гігантським розміром даних для рекомендаційного навчання, тоді як лише кілька розріджених вкладень отримують оновлення в одному пакеті даних. (1) та (2) дозволяють нам використовувати розріджені оновлення для всіх ідентифікаторів ознак. У Monolith ми підтримуємо хеш-множину торкнутих ключів, що представляють ідентифікатори, вкладення яких тренувалися з моменту останньої синхронізації параметрів. Ми передаємо підмножину розріджених параметрів, ключі яких знаходяться в множині торкнутих ключів, з інтервалом часу в хвилину з навчального PS до онлайн-сервісного PS. Цей відносно невеликий пакет інкрементального оновлення параметрів є легким для передачі по мережі і не викличе різкого сплеску пам'яті під час синхронізації. Ми також використовуємо (3) для подальшого зменшення мережевого трафіку та використання пам'яті, встановлюючи більш агресивний розклад синхронізації для розріджених параметрів, тоді як щільні параметри оновлюються рідше. Це може призвести до ситуації, коли щільні параметри, які ми обслуговуємо, є відносно застарілою версією порівняно з розрідженою частиною. Однак така неузгодженість може бути терпимою через причину, зазначену в (3), оскільки помітних втрат не спостерігалося. 2.3 Відмовостійкість Як система в експлуатації, Monolith розроблений з можливістю відновлення PS у разі його збою. Поширеним вибором для відмовостійкості є періодичне створення знімків стану моделі та відновлення з останнього знімка при виявленні збою PS. Вибір частоти знімків має два основні наслідки: (1) Якість моделі. Інтуїтивно, якість моделі менше страждає від втрати недавньої історії зі збільшенням частоти знімків. (2) Обчислювальні накладні витрати. Створення знімка моделі розміром у кілька терабайтів не є безкоштовним. Це призводить до великих обсягів копіювання пам'яті та операцій вводу-виводу диска. Як компроміс між якістю моделі та обчислювальними накладними витратами, Monolith робить знімки всіх навчальних PS щодня. Хоча PS втратить один день оновлень у разі збою, ми виявили, що деградація продуктивності є прийнятною згідно з нашими експериментами. Ми проаналізуємо ефект надійності PS у наступному розділі. 3 ОЦІНКА Для кращого розуміння переваг та компромісів, що виникають внаслідок нашого запропонованого дизайну, ми провели кілька експериментів у промислових масштабах та A/B-тестування з живим трафіком для оцінки та перевірки Monolith з різних аспектів. Ми прагнемо відповісти на наступні питання за допомогою наших експериментів: (1) Наскільки ми можемо отримати вигоду від хеш-таблиці без колізій? (2) Наскільки важливе онлайн-навчання в реальному часі? (3) Чи є дизайн синхронізації параметрів Monolith достатньо надійним у великомасштабному виробничому сценарії? У цьому розділі ми спочатку представимо наші експериментальні налаштування, а потім детально обговоримо результати та наші висновки. 3.1 Експериментальна установка Як описано в Розділі таблиці вкладень у Monolith реалізовані як хеш-таблиці без колізій. Щоб довести необхідність уникнення колізій у таблицях вкладень та кількісно оцінити переваги від нашої реалізації без колізій, ми провели дві групи експериментів на наборі даних Movielens та на нашому внутрішньому виробничому наборі даних відповідно: 3.1.1 Таблиця вкладень. 2.1, (1) ml-25m dataset [ ]. Це стандартний загальнодоступний набір даних для рейтингів фільмів, що містить 25 мільйонів рейтингів, які включають приблизно 162000 користувачів та 62000 фільмів. MovieLens 11 • . Початкові мітки — це рейтинги від Попередня обробка міток 0.5 до 5.0, тоді як у виробничій діяльності наші завдання переважно отримують бінарні сигнали від користувачів. Щоб краще імітувати наші виробничі моделі, ми перетворюємо шкалу міток на бінарні, розглядаючи оцінки ≥ 3.5 як позитивні приклади, а решту — як негативні. • Модель та метрики. Ми реалізували стандартну модель DeepFM [9], широко використовувану архітектуру моделі для рекомендаційних завдань. Вона складається з компонента FM та щільного компонента (Малюнок 6). Прогнози оцінюються за допомогою AUC [2], оскільки це основний показник для реальних моделей. • Колізії вкладень. Цей набір даних містить приблизно 160 тис. ідентифікаторів користувачів та 60 тис. ідентифікаторів фільмів. Щоб порівняти з версією таблиці вкладень без колізій, ми провели ще одну групу експериментів, де ідентифікатори попередньо оброблялися за допомогою хешування MD5, а потім відображалися в менший простір ідентифікаторів. В результаті деякі ідентифікатори будуть мати спільне вкладення з іншими. Таблиця 1 показує детальну статистику ідентифікаторів користувачів та фільмів до та після хешування. (2) . Внутрішній набір даних рекомендацій Ми також провели експерименти з рекомендаційною моделлю в робочому середовищі. Ця модель загалом відповідає багаторівневій архітектурі, де кожен рівень відповідає за навчання прогнозування специфічного типу поведінки користувача. Кожна модель має близько 1000 таблиць вкладень, і розподіл розмірів таблиць вкладень дуже нерівномірний; Початковий простір ідентифікаторів таблиці вкладень становив 248. У нашій базовій лінії ми застосували хеш-трик, розклавши його, щоб обмежити розмір таблиці вкладень. Щоб бути більш конкретними, ми використовуємо