Всередині моноліту ByteDance: двигун, що забезпечує розумніші та швидші стрічки контенту

Автори: Чжуоран Лю, Bytedance Inc. Лекі Цзоу, Bytedance Inc. Сюань Цзоу, Bytedance Inc. Кайхуа Ван, Bytedance Inc. Біао Чжан, Bytedance Inc. Да Тан, Bytedance Inc. Болін Чжу∗, Фуданський університет Іцзе Чжу, Bytedance Inc. Пен Ву, Bytedance Inc. Ке Ван, Bytedance Inc. Юлонг Ченґ†, Bytedance Inc. (youlong.cheng@bytedance.com) АНОТАЦІЯ Побудова масштабованої системи рекомендацій у реальному часі є життєво важливою для багатьох бізнесів, керованих чутливим до часу відгуком клієнтів, таких як ранжування коротких відео або онлайн-реклама. Незважаючи на повсюдне впровадження великомасштабних фреймворків глибокого навчання, таких як TensorFlow або PyTorch, ці загального призначення фреймворки не відповідають бізнес-вимогам у сценаріях рекомендацій з різних причин: з одного боку, коригування систем на основі статичних параметрів і щільних обчислень для рекомендацій з динамічними та розрідженими ознаками шкодить якості моделі; з іншого боку, такі фреймворки розроблені з повністю розділеними етапами пакетного навчання та обслуговування, що запобігає взаємодії моделі з відгуками клієнтів у реальному часі. Ці проблеми змусили нас переглянути традиційні підходи та дослідити радикально різні дизайнерські рішення. У цій статті ми представляємо 1, систему, розроблену для онлайн-навчання. Наш дизайн базувався на спостереженнях за нашими робочими навантаженнями та виробничим середовищем, що відображає помітну відмінність від інших систем рекомендацій. Наш внесок є багатогранним: по-перше, ми створили таблицю вбудовування без колізій з оптимізаціями, такими як вичерпні вбудовування та фільтрація частоти, щоб зменшити її розмір пам'яті; по-друге, ми надаємо архітектуру онлайн-навчання, готову до виробництва, з високою відмовостійкістю; нарешті, ми довели, що надійність системи може бути принесена в жертву для навчання в реальному часі. Monolith успішно впроваджено в продукт BytePlus Recommend2. Monolith 1 ВСТУП Минуле десятиліття спостерігало бум бізнесів, що працюють на основі рекомендаційних технік. Для покращення клієнтського досвіду, надання персоналізованого контенту для кожного окремого користувача як відповідь у реальному часі є загальною метою цих бізнес-додатків. Для цього інформація з останньої взаємодії користувача часто використовується як основний вхідний сигнал для навчання моделі, оскільки вона найкраще відображає портрет користувача та робить прогнози щодо інтересів та майбутньої поведінки користувача. Глибоке навчання домінує в рекомендаційних моделях [ , , , , , ], оскільки величезна кількість даних користувачів добре підходить для нейронних моделей, керованих масивом даних. Однак зусилля з використання потужності глибокого навчання в рекомендаційних системах промислового рівня постійно стикаються з проблемами, що виникають через унікальні характеристики даних, отриманих з реальної поведінки користувачів. Ці дані кардинально відрізняються від тих, що використовуються у звичайних задачах глибокого навчання, таких як моделювання мови або комп'ютерний зір, у двох аспектах: 5 6 10 12 20 21 (1) Ознаки переважно розріджені, категоричні та динамічно змінюються; (2) Базовий розподіл навчальних даних є нестаціонарним, тобто дрейф концепції . Такі відмінності створили унікальні виклики для дослідників та інженерів, які працюють над рекомендаційними системами. 1.1 Розрідженість та динамізм Дані для рекомендацій переважно містять розріджені категоричні ознаки, деякі з яких з'являються з низькою частотою. Звичайна практика відображення їх у багатовимірному просторі вбудовування призводить до низки проблем: • На відміну від мовних моделей, де кількість словоформ обмежена, кількість користувачів та предметів ранжування на порядки більша. Така величезна таблиця вбудовування ледь вміщується в пам'ять одного хоста; • Ще гірше, розмір таблиці вбудовування очікується зростати з часом, оскільки додається більше користувачів та предметів, тоді як фреймворки, такі як [ , ], використовують щільні змінні фіксованого розміру для представлення таблиці вбудовування. 1 17 На практиці багато систем використовують хешування з низькою кількістю колізій [ , ] як спосіб зменшити обсяг пам'яті та дозволити зростання ідентифікаторів. Це спирається на надмірно ідеалістичне припущення, що ідентифікатори в таблиці вбудовування розподілені рівномірно за частотою, а колізії нешкідливі для якості моделі. На жаль, це рідко справджується для реальної рекомендаційної системи, де невелика група користувачів або предметів має значно більше входжень. З органічним зростанням розміру таблиці вбудовування збільшується ймовірність колізії хеш-ключів, що призводить до погіршення якості моделі 3 6 . Тому природною потребою для великомасштабних рекомендаційних систем є здатність захоплювати якомога більше ознак у своїх параметрах, а також можливість еластично регулювати кількість користувачів та предметів, які вона намагається вести облік. 1.2 Нестаціонарний розподіл Візуальні та мовні шаблони ледь розвиваються в часовому масштабі століть, тоді як той самий користувач, зацікавлений в одній темі, може змінити свій ентузіазм наступної хвилини. В результаті, базовий розподіл даних користувачів є нестаціонарним, явище, яке зазвичай називають дрейфом концепції . Інтуїтивно, інформація з більш актуальної історії може ефективніше сприяти прогнозуванню змін у поведінці користувача. Щоб зменшити вплив дрейфу концепції, моделі обслуговування повинні оновлюватися на основі нового відгуку користувача якомога ближче до реального часу, щоб відображати останні інтереси користувача. З огляду на ці відмінності та спостереження за проблемами, що виникають у нашому виробництві, ми розробили , великомасштабну систему рекомендацій для вирішення цих проблем. Ми провели обширні експерименти для перевірки та ітерації нашого дизайну в робочому середовищі. Monolith здатний Monolith (1) Забезпечити повну виразну силу для розріджених ознак шляхом розробки хеш-таблиці без колізій та механізму вичерпання динамічних ознак; (2) Зворотний зв'язок із обслуговування до навчання в реальному часі за допомогою онлайн-навчання. Завдяки цим архітектурним можливостям, Monolith стабільно перевершує системи, що використовують хеш-тріки з колізіями, з приблизно подібним використанням пам'яті, та досягає найсучаснішого онлайн-обслуговування AUC без надмірного навантаження на обчислювальну потужність наших серверів. Решта статті організована наступним чином. Спочатку ми детально опишемо, як Monolith вирішує існуючі проблеми за допомогою хеш-таблиці без колізій та навчання в реальному часі в Розділі 2. Експерименти та результати будуть представлені в Розділі 3, разом із висновками, протестованими у виробництві, та деякими обговореннями компромісів між чутливістю до часу, надійністю та якістю моделі. Розділ 4 узагальнює пов'язані роботи та порівнює їх з Monolith. Розділ 5 підсумовує цю роботу. 2 ДИЗАЙН Загальна архітектура Monolith загалом відповідає розподіленому налаштуванню TensorFlow Worker- arameter erver (Рисунок В архітектурі Worker-PS машини отримують різні ролі; машини Worker відповідають за виконання обчислень, визначених графом, а машини PS зберігають параметри та оновлюють їх відповідно до градієнтів, обчислених Workers. P S 2). У рекомендаційних моделях параметри поділяються на два набори: щільні та розріджені. Щільні параметри — це ваги/змінні в глибокій нейронній мережі, а розріджені параметри — це таблиці вбудовування, що відповідають розрідженим ознакам. У нашому дизайні як щільні, так і розріджені параметри є частиною графа TensorFlow і зберігаються на серверах параметрів. Подібно до TensorFlow Variable для щільних параметрів, ми розробили набір високоефективних, без колізій та гнучких операцій HashTable для розріджених параметрів. Як доповнення до обмежень Tensor-Flow, що виникають через розділення навчання та висновку, масштабоване онлайн-навчання Monolith розроблено для ефективної синхронізації параметрів з Training-PS до Online Serving-PS протягом коротких інтервалів, з гарантією стійкості моделі, що забезпечується механізмом відмовостійкості. 2.1 Хеш-таблиця Першим принципом у нашому дизайні представлення розріджених параметрів є уникнення змішування інформації з різних ідентифікаторів в одне вбудовування фіксованого розміру. Симуляція таблиці вбудовування динамічного розміру за допомогою стандартної TensorFlow Variable неминуче призводить до колізій ідентифікаторів, що посилюються при надходженні нових ідентифікаторів та зростанні таблиці. Тому, замість того, щоб спиратися на Variable, ми розробили нову хеш-таблицю ключ-значення для наших розріджених параметрів. Наша 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. Подібно до Variable, пошуки та оновлення також реалізовані як нативні операції TensorFlow для легшої інтеграції та кращої сумісності. 2.2 Онлайн-навчання У Monolith навчання поділяється на два етапи (Рисунок 1): (1) Етап пакетного навчання. Цей етап працює як звичайний цикл навчання TensorFlow: на кожному кроці навчання worker навчання читає один міні-пакет навчальних прикладів зі сховища, запитує параметри з PS, обчислює прямий та зворотний прохід, і нарешті надсилає оновлені параметри до training PS. Трохи відмінно від інших загальних завдань глибокого навчання, ми тренуємо наш набір даних лише один раз. Пакетне навчання корисне для навчання історичних даних, коли ми модифікуємо архітектуру нашої моделі та перетреновуємо модель; (2) Етап онлайн-навчання. Після розгортання моделі для онлайн-обслуговування, навчання не припиняється, а переходить на етап онлайн-навчання. Замість читання міні-пакетів прикладів зі сховища, worker навчання споживає реальні дані на льоту та оновлює training PS. Training PS періодично синхронізує свої параметри з serving PS, що негайно набуває чинності для користувача. Це дозволяє нашій моделі інтерактивно адаптуватися відповідно до відгуків користувача в реальному часі. Monolith побудовано з можливістю безшовної зміни між пакетним та онлайн-навчанням. Це забезпечується нашим дизайном потокового двигуна, як проілюстровано на Рисунку 2.2.1 Streaming Engine. 4. У нашому дизайні ми використовуємо одну чергу Kafka [ ] для логування дій користувачів (наприклад, клік на предмет або вподобання предмета тощо) та іншу чергу Kafka для ознак. В основі двигуна лежить завдання потокової обробки Flink [ ] для об'єднання онлайн-ознак. Онлайн-об'єднувач об'єднує ознаки з мітками з дій користувачів і створює навчальні приклади, які потім записуються до черги Kafka. Черга для навчальних прикладів споживається як онлайн-, так і пакетним навчанням: 13 4 Для онлайн-навчання worker навчання безпосередньо читає дані з черги Kafka; Для пакетного навчання завдання дампінгу даних спочатку скидає дані в HDFS [ ]; Після накопичення певного обсягу даних в HDFS, worker навчання отримує дані з HDFS і виконує пакетне навчання. 18 Оновлені параметри в training PS будуть надіслані до serving PS відповідно до розкладу синхронізації параметрів. У реальних додатках журнали дій користувачів та ознаки передаються в онлайн-об'єднувач (Рисунок без гарантії хронологічного порядку. Тому ми використовуємо унікальний ключ для кожного запиту, щоб дія користувача та ознаки могли правильно співставитися. 2.2.2 Online Joiner. 5) Затримка дії користувача також може бути проблемою. Наприклад, користувач може витратити кілька днів, перш ніж вирішить купити предмет, представлений йому кілька днів тому. Це проблема для об'єднувача, оскільки якщо всі ознаки зберігатимуться в кеші, він просто не вміститься в пам'ять. У нашій системі використовується дискове сховище ключ-значення для зберігання ознак, які чекають надто довго. Коли надходить журнал дій користувача, він спочатку шукає в кеші в пам'яті, а потім шукає в сховищі ключ-значення у разі відсутності в кеші. Ще одна проблема, що виникає в реальних додатках, полягає в тому, що розподіл негативних і позитивних прикладів є надзвичайно нерівномірним, причому кількість перших може бути в рази вищою за другу. Щоб запобігти переважанню позитивних прикладів негативними, поширеною стратегією є негативне семплювання. Це, безумовно, змінить базовий розподіл навченого моделі, налаштувавши його на вищу ймовірність отримання позитивних прогнозів. Як засіб виправлення, ми застосовуємо корекцію логарифмічних шансів [ ] під час обслуговування, гарантуючи, що онлайн-модель є незміщеною оцінкою початкового розподілу. 19 Під час онлайн-навчання кластер навчання Monolith продовжує отримувати дані з модуля онлайн-обслуговування та оновлювати параметри на training PS. Критичним кроком для того, щоб дозволити online serving PS отримати вигоду з цих новонавчених параметрів, є синхронізація оновлених параметрів моделі. У виробничому середовищі ми стикаємося з кількома проблемами: 2.2.3 Синхронізація параметрів. Моделі на online serving PS не повинні припиняти обслуговування під час оновлення. Наші моделі у виробництві зазвичай мають розмір у кілька терабайтів, і в результаті заміна всіх параметрів займає деякий час. Зупинка online PS від обслуговування моделі під час процесу заміни була б неприйнятною, і оновлення повинні здійснюватися на льоту; Передача багатотерабайтної моделі в цілому з training PS до online serving PS створила б величезний тиск як на пропускну здатність мережі, так і на пам'ять на PS, оскільки це вимагає подвійного розміру пам'яті для прийому нової моделі. Щоб онлайн-навчання масштабувалося до розміру нашого бізнес-сценарію, ми розробили механізм інкрементальної періодичної синхронізації параметрів на льоту в Monolith на основі кількох помітних характеристик наших моделей: (1) Розріджені параметри домінують за розміром рекомендаційних моделей; (2) При заданому короткому часовому вікні лише невелика підмножина ідентифікаторів тренується, і їх вбудовування оновлюються; (3) Щільні змінні рухаються набагато повільніше, ніж розріджені вбудовування. Це пов'язано з тим, що в оптимізаторах на основі імпульсу накопичення імпульсу для щільних змінних збільшується гігантським обсягом даних для рекомендаційного навчання, тоді як лише кілька розріджених вбудовувань отримують оновлення в одному пакеті даних. (1) і (2) дозволяють нам використовувати розріджені оновлення для всіх ідентифікаторів ознак. У Monolith ми підтримуємо хеш-множину торкнутих ключів, що представляє ідентифікатори, вбудовування яких тренувалися з моменту останньої синхронізації параметрів. Ми передаємо підмножину розріджених параметрів, ключі яких знаходяться в множині торкнутих ключів, з інтервалом часу від хвилин від training PS до online serving PS. Цей відносно невеликий пакет інкрементного оновлення параметрів є легким для передачі по мережі і не спричиняє різкого стрибка пам'яті під час синхронізації. Ми також використовуємо (3) для подальшого зменшення мережевого вводу-виводу та використання пам'яті, встановлюючи більш агресивний графік синхронізації для розріджених параметрів, тоді як щільні параметри оновлюються рідше. Це може призвести до ситуації, коли щільні параметри, які ми обслуговуємо, є відносно застарілою версією порівняно з розрідженою частиною. Однак така неузгодженість може бути терпимою через причину, зазначену в (3), оскільки помітної втрати не спостерігалося. 2.3 Відмовостійкість Як система у виробництві, Monolith розроблено з можливістю відновлення PS у разі його відмови. Звичайним вибором для відмовостійкості є періодичне створення знімків стану моделі та відновлення з останнього знімка при виявленні відмови PS. Вибір частоти створення знімків має два основні впливи: (1) Якість моделі. Інтуїтивно, якість моделі менше страждає від втрати недавньої історії при збільшенні частоти створення знімків. (2) Накладні витрати на обчислення. Створення знімка багатотерабайтної моделі не є безкоштовним. Це призводить до великих обсягів копіювання пам'яті та дискового вводу-виводу. Як компроміс між якістю моделі та обчислювальними витратами, Monolith робить знімки всіх training PS щодня. Хоча PS втратить один день оновлень у разі відмови, ми виявили, що зниження продуктивності є терпимим завдяки нашим експериментам. Ми проаналізуємо вплив надійності PS у наступному розділі. 3 ОЦІНКА Для кращого розуміння переваг та компромісів, запропонованих нашим дизайном, ми провели кілька експериментів у виробничому масштабі та A/B-тестування з живим трафіком обслуговування для оцінки та перевірки Monolith з різних аспектів. Ми прагнемо відповісти на наступні питання за допомогою наших експериментів: (1) Наскільки ми можемо отримати користь від хеш-таблиці без колізій? (2) Наскільки важливе онлайн-навчання в реальному часі? (3) Чи є дизайн синхронізації параметрів Monolith достатньо надійним у великомасштабному виробничому сценарії? У цьому розділі ми спочатку представимо наші експериментальні налаштування, а потім детально обговоримо результати та наші висновки. 3.1 Експериментальна установка Як описано в Розділі таблиці вбудовування в Monolith реалізовані як хеш-таблиці без колізій. Щоб довести необхідність уникнення колізій у таблицях вбудовування та кількісно оцінити вигоди від нашої реалізації без колізій, ми провели дві групи експериментів на наборі даних Movielens та на нашому внутрішньому виробничому наборі даних відповідно: 3.1.1 Таблиця вбудовування. 2.1, (1) Набір даних ml-25m [ ]. Це стандартний загальнодоступний набір даних для оцінки фільмів, що містить 25 мільйонів оцінок, що охоплюють приблизно 162 000 користувачів та 62 000 фільмів. MovieLens 11 • . Оригінальні мітки — це оцінки від Попередня обробка міток 0.5 до 5.0, тоді як у виробництві наші завдання переважно отримують двійкові сигнали від користувачів. Щоб краще симулювати наші виробничі моделі, ми перетворюємо масштабовані мітки на двійкові, розглядаючи оцінки ≥ 3.5 як позитивні приклади, а решту — як негативні. • Модель та метрики. Ми реалізували стандартну модель DeepFM, широко використовувану модель для рекомендаційних завдань. Вона складається з компонента FM та щільного компонента (Рисунок 6). Прогнози оцінюються за допомогою AUC, оскільки це основний показник для реальних моделей. • Колізії вбудовування. Цей набір даних містить приблизно 160 тис. ідентифікаторів користувачів та 60 тис. ідентифікаторів фільмів. Щоб порівняти з версією таблиці вбудовування без колізій, ми провели ще одну групу експериментів, де ідентифікатори попередньо оброблялися за допомогою хешування MD5, а потім відображалися у менший простір ідентифікаторів. Як наслідок, деякі ідентифікатори ділитимуть своє вбудовування з іншими. Таблиця 1 показує детальну статистику ідентифікаторів користувачів та фільмів до та після хешування. (2) . Внутрішній рекомендаційний набір даних Ми також провели експерименти з рекомендаційною моделлю у виробничому середовищі. Ця модель загалом відповідає багатовежковій архітектурі, де кожна вежа відповідає за вивчення прогнозування спеціалізованого типу поведінки користувача. Кожна модель має близько 1000 таблиць вбудовування, і розподіл розмірів таблиць вбудовування є дуже нерівномірним; Початковий простір ідентифікаторів таблиці вбудовування становив 248. У нашій базовій моделі ми