Будь скалой для короля — построить масштабную рекомендательную систему может каждый

предисловие

Что такое персональная рекомендация? Проще говоря, это рекомендация товаров, которые нравятся пользователям. В последние 10 лет, с бурным развитием мобильного Интернета, очень важную роль сыграли персональные рекомендации. Возьмем в качестве примера работу контентного продукта: группа по развитию пользователей продвигает продукт с помощью рекламы и других средств для увеличения DAU; техническая группа по продукту распространяет интересующий пользователей контент, чтобы увеличить удержание и время удержания; группа коммерциализации распределяет заинтересованных пользователей. реклама может повысить эффективность монетизации единичного трафика, коммерческая выручка используется для роста пользователей, формируя положительный цикл. Технология персонализированных рекомендаций проходит через каждую ссылку и стала двигателем быстрого роста для многих компаний.

Как сделать персональную рекомендацию? Обычно для бизнеса сначала определяются несколько целей оптимизации (например, время воспроизведения видео, лайки, перепосты, клики в электронной торговле, надстройки, покупки и т. д.), а затем строятся одна или несколько моделей для прогнозирования этих целей. оцениваются, и, наконец, оценочные баллы нескольких целей объединяются для завершения ранжирования. Для рекомендательной системы основная работа заключается в построении точной модели прогнозирования. На протяжении многих лет рекомендательные модели в отрасли развивались в сторону увеличения масштабов, работы в режиме реального времени и уточнения. Крупномасштабный относится к очень большому объему данных и моделей, обучающим выборкам, достигающим десятков миллиардов или даже триллионов, и одной модели, достигающей ТБ или даже более 10 ТБ; в режиме реального времени относится к обновлениям в реальном времени функций, моделей, и кандидаты; уточнение относится к проектированию признаков и структуре модели, отражены методы оптимизации и многие другие аспекты, а различные инновационные идеи возникают бесконечным потоком.

Внедрение крупномасштабных рекомендательных систем является огромной инженерной задачей. В этой статье мы выбираем системы обучения и обслуживания, которые всем интересны больше всего, и знакомит с проблемами, с которыми придется столкнуться в процессе строительства, и о том, что мы сделали. Ни одной компании не просто построить такую систему с нуля, а инвестиции очень большие. Внутри ByteDance мы также испытали годы исследований и накопления тысяч инженеров, постоянно итерирующих и оптимизирующих систему рекомендаций. Итак, с какими проблемами обычно сталкиваются при построении рекомендательной системы? Начнем с истории:

История компании А

А — компания электронной коммерции. У их продуктов 3 миллиона DAU и команда алгоритмов из 10 человек. Они столкнулись с большими трудностями в процессе построения системы рекомендаций. Давайте посмотрим.

Компания А хочет обучить модель CTR со 100 миллионами показов и 1 миллионом кликов в день. Они хотят обучить модель с данными за 3 месяца и размером выборки 9 млрд. Они разработали 200 функций, включая идентификатор пользователя, идентификатор продукта, последовательность кликов пользователя и т. д. Они хотели назначить 16-мерный вектор каждой функции для представления, а размер модели составлял примерно 500G. После анализа они обнаружили, что необходимо распределенное обучение и хранилище моделей, поэтому они исследовали некоторые решения с открытым исходным кодом:

Tensorflow: система машинного обучения Google с открытым исходным кодом, которая может использовать Partitioned Variable для распределенного хранения Embedded, что позволяет проводить крупномасштабное обучение. Однако из-за фиксированного размера таблицы существует риск конфликта хэшей.
PyTorch: система машинного обучения Facebook с открытым исходным кодом, которая использует Ring All Reduce для синхронизации параметров, требует одной машины для обработки всех параметров и сложна для обучения больших моделей.
XDL: Отечественная система машинного обучения с открытым исходным кодом, система PS собственной разработки, использующая TF в качестве механизма обучения и встроенные некоторые готовые рекомендательные модели. Функционально можно добиться масштабного обучения, но поддержка открытого исходного кода этой системы слаба, и ее использование в продакшене рискованно.
Angel: отечественная система машинного обучения с открытым исходным кодом, которая характеризуется тесной интеграцией с системой больших данных Spark и использованием Spark для завершения предварительной обработки данных и разработки функций. Самостоятельно разработанный сервер параметров, встроенный в Pytorch в качестве механизма обучения, может обучать очень большие модели. Однако онлайн- и офлайн-функции Angel трудно обеспечить согласованность, и они подходят только для офлайн-платформ для обучения.

После сравнения компания А выбрала Tensorflow для распределенного обучения. Однако при обучении модели обнаруживается, что скорость очень низкая, даже если вложено много ресурсов, все равно требуется 5 дней для обучения данных за 3 месяца. Они потратили много времени на изучение Tensorflow, профилирование процесса обучения и обнаружили некоторые проблемы:

Распределенная производительность TensorFlow не очень хороша.Для каждой функции пара операций отправки/получения генерируется отдельно для соединения рабочего процесса и PS, так что один рабочий процесс и PS генерируют 200 операций отправки/получения, что затрудняет планирование TensorFlow. Время выполнения сложное, что снижает скорость распределенного обучения.
Использование ЦП во время обучения очень неустойчиво, и кажется, что ЦП используется не полностью.
Некоторые операторы работают очень медленно, и предполагается, что это может быть связано с пропускной способностью памяти.
Хотя пропускная способность сети загружена не полностью, добавление дополнительных машин больше не может увеличить скорость обучения.
Просматривая официальный сайт TF, я обнаружил, что TF недавно запустил различные распределенные стратегии, которые соответствуют разным топологиям обучающего кластера. Они очень растеряны и не знают, какой из них выбрать.

Хотя было обнаружено много проблем с производительностью, оптимизация оказалась не очень простой. После периода напряженной работы они оптимизировали некоторые задачи и сократили время обучения с 5 до 3 дней, что едва ли приемлемо. Однако, когда обучение достигает 40-го часа, задание обучения зависает из-за машинного OOM. Они пробовали несколько раз и обнаружили, что показатель успешности обучения был относительно низким.После анализа они обнаружили, что основными причинами были:

TF строит кластер на основе конфигурации статической топологии и не поддерживает динамическую работу с сетью, а это значит, что при зависании ps или worker и перезапуске, при изменении ip или порта (например, сбой машины) обучение продолжаться не будет.
Контрольная точка TF содержит только информацию о параметрах, хранящуюся в PS, а не состояние рабочей стороны.Это не является глобально согласованной контрольной точкой и не может обеспечить семантику Exactly-Once.

Сделать хорошую работу по отказоустойчивости — непростая задача, они могут только сначала изолировать независимый кластер, чтобы сделать обучение максимально стабильным. Его нельзя смешивать с другими задачами для планирования, и коэффициент использования ресурсов, естественно, намного ниже.

После нескольких поворотов им удалось обучить модель 500G.Они хотели подтолкнуть модель к обслуживанию онлайн, поэтому они рассмотрели дизайн онлайн-системы. После некоторого обсуждения они пришли к выводу, что система обслуживания должна соответствовать следующим требованиям:

Распределенная: модель рекомендаций характеризуется большим количеством вложений, и модель может легко достичь уровня TB.Учитывая будущие итерации модели, необходимо поддерживать распределенное обслуживание.
Низкая задержка: задержка одной оценки должна быть как можно меньше, а модель точной настройки обычно должна контролироваться в пределах 80 мс. Сложные глубокие модели могут потребовать от графических процессоров обслуживания и выполнения ряда оптимизаций производительности.
Высокая доступность: сбой небольшого количества узлов не влияет на стабильность в сети, как правило, решается множественными копиями, что требует поддержки системы планирования.
Меньше джиттера: обновление модели, онлайн, офлайн и другие операции не вызывают джиттера задержки.
Тест AB: система рекомендаций повторяется очень быстро. Инженеры-алгоритмы проведут множество экспериментов AB. Трафик экспериментальной группы будет динамически регулироваться. Онлайн-система должна поддерживать динамическое планирование моделей и услуг.

В настоящее время ни одна система с открытым исходным кодом не может удовлетворить вышеуказанным требованиям, и все крупные компании являются самостоятельными разработками, и фактические инвестиции немалые. Компания А имеет ограниченный персонал и недостаточный опыт, она может использовать только некоторые средства сжатия модели, позволяющие обслуживать одну машину, и модель не должна быть слишком сложной.

После запуска модели компания А столкнулась с новой проблемой: как обновить модель. Стоимость регулярного полного переобучения высока, а если в сети одновременно несколько моделей ABTest, будет еще хуже. Поэтому как минимум надо добиться инкрементальных обновлений на уровне неба, а обновления в реальном времени естественно лучше. Но добавочные обновления/обновления в реальном времени реализовать непросто. На самом деле, в будущем компанию А ждет еще больше проблем, таких как: как обеспечить согласованность онлайн- и офлайн-функций; что делать, если восходящий поток данных нестабилен; как решить проблему все более крупных моделей. ; как хорошо справиться с мультисценарным гибридным обучением данных; как справиться с проблемой крупномасштабных кандидатов; как решить проблему больших задержек в конверсионных событиях и т. д.

Наша работа

Из истории компании А видно, что разработать масштабную рекомендательную систему действительно сложно и дорого. Итак, существует ли продукт, который может напрямую охватывать весь процесс проверки данных, разработки функций, разработки моделей, онлайн-сервиса, AB-тестирования и т. д., чтобы бизнес мог легко построить первоклассную рекомендательную систему и больше не сталкиваться с головная боль компании А??? имеют.

После того, как Bytedance создала Volcano Engine, мы усердно работали над тем, чтобы сделать технологию рекомендаций Bytedance доступной для внешних клиентов. Сегодня мы можем помочь вам решить эти трудности и болевые точки с помощью интеллектуальной рекомендательной платформы Volcano Engine. В настоящее время эта платформа также открыла некоторые квоты для бесплатного использования предприятиями, конкретную информацию можно найти в конце статьи.

Далее давайте представим крупномасштабное решение для обучения и обслуживания в интеллектуальной рекомендательной платформе. Мы назовем его Monolith (Rock) и надеемся, что оно станет прочной основой для создания рекомендательной системы для всех. Ниже представлена диаграмма архитектуры:

Как видно из рисунка, Monolith — это архитектура PS, посмотрим, как эта архитектура работает:

пакетное/инкрементное обучение

Worker/PS зарегистрируется в ZK при его запуске, и информация будет включать в себя (server_type, index). Затем Worker запрашивает регистрационную информацию у ZK, генерирует информацию о кластере и реализует динамическую сеть, которая является основой отказоустойчивости.
После начала обучения Worker будет получать данные из стандартного ввода или файла и извлекать параметры из PS, затем выполнять прямой/обратный расчет, получать градиент и передавать его в PS.
После получения PS градиента, с одной стороны, оптимизатор используется для обновления внутреннего веса, а с другой стороны, какие данные были обновлены, будет записано. Запустите сеанс TF на PS, и он будет периодически отправлять обновленные параметры на онлайн PS для достижения добавочного обновления в реальном времени. Кроме того, фильтрация признаков, устранение признаков и т. д. также выполняются на PS.
Во время обучения или в конце обучения прописываются контрольные точки. Чтобы ускорить создание контрольных точек, Monolith не расширяет возможности сохранения в TF, а использует прослушиватель сохранения оценщика для выполнения потокового многопоточного доступа, что значительно повышает производительность. Чтобы уменьшить объем контрольных точек, функции с истекшим сроком действия будут удалены.

онлайн рассуждения

Загрузите сохраненную_модель. Entry — это, по сути, TF Serving, который загружает не встраиваемые части из HDFS и регистрируется в ZK для балансировки нагрузки верхним уровнем. Онлайн-PS также сначала зарегистрируется в ZK, затем загрузит параметры из HDFS и удалит вспомогательные параметры оптимизатора в процессе загрузки, преобразует fp32 в fp16, квантует сжатие и т. д.
Для запроса Entry случайным образом выбирает набор сетевых PS, получает от них Embedding и завершает прогноз. Вход/Онлайн PS является многокопийным, пока существует одна копия, услуга доступна. Онлайн PS является многосегментным и может обслуживать очень большие модели. На одном компьютере можно развернуть несколько сегментов или смешать Entry/OnlinePS.
Для некоторых систем с высокой производительностью модели в реальном времени обучающий PS будет связываться с онлайновым PS напрямую через RPC, тем самым сокращая временной интервал для возврата выборок в онлайн-модель до минутного уровня.
Учебный PS может связываться с Online PS и принимать обновления параметров от Training PS; Entry может автоматически считывать обновленные параметры из HDFS, тем самым реализуя постепенное обновление параметров на уровне минут.

Подводя итог, можно сказать, что Monolith включает в себя обучение/обслуживание/синхронизацию параметров и т. д. и представляет собой полноценную систему.

По сравнению с другими системами в отрасли, Monolith успешно справляется со многими задачами и обладает следующими характеристиками:

Устранено узкое место связи TensorFlow PS.

В моделях рекомендаций промышленного уровня мы часто используем сотни или даже тысячи функций, и для каждой функции необходимо создать хеш-таблицу для хранения внедренных функций. Непосредственное создание хеш-таблицы для каждого типа признаков и одновременный поиск по сотням таблиц приводит к двум проблемам:

Соединение между PS и Worker будет генерировать слишком много операций отправки/получения, что сильно повлияет на эффективность работы распределенной среды выполнения.
Эти операции приводят к слишком большому количеству узлов графа модели, слишком большому графу модели и слишком долгому времени инициализации обучения.

В ответ на вышеуказанные проблемы мы оптимизировали на уровне фреймворка: для хеш-таблиц с одинаковой конфигурацией (одинаковыми параметрами dim и оптимизатора) хэш-таблицы объединяются на уровне API Python, чтобы уменьшить количество таблиц, и монолит будет уменьшить количество таблиц для коммуникационных операций.Выполняется дальнейшее слияние, что значительно сокращает операции отправки/получения и решает коммуникационную проблему нативной TensorFlow PS.

Для асинхронного обучения Monolith также разрабатывает функции переменной и встроенной предварительной выборки и градиентного асинхронного обновления.Для большинства моделей пропускная способность и ЦП могут использоваться более эффективно, тем самым повышая скорость обучения и оптимизируя использование ресурсов.

Всесторонняя отказоустойчивость

На основе обнаружения службы, независимо от того, произошла ли ошибка в Worker или PS, ее можно быстро восстановить. Для воркеров нет прямой связи между разными воркерами в Monolith, поэтому сбой одного воркера не повлияет на других воркеров, в то же время воркер будет хранить ход ввода, когда воркер выходит из строя по непредвиденным причинам , ход ввода не будет потерян; при сбое узла PS shard, в зависимости от характера офлайн/онлайн задач, он поддерживает различные режимы частичного восстановления и полного восстановления, а также делает определенные компромиссы в правильности и скорость восстановления.

Распределенное обслуживание

Monolith заполняет пробел в программном обеспечении с открытым исходным кодом в распределенном обслуживании и предоставляет услуги логического вывода для моделей уровня TB. Поддерживает несколько копий и высокую доступность Во время процесса обучения Training PS синхронизирует недавно обновленные Embedding to Serving PS на минутном уровне, тем самым реализуя обновление параметров почти в реальном времени и улучшая эффект рекомендации продукта.

оптимизация производительности

В дополнение к устранению упомянутого выше узкого места связи TensorFlow PS, Monolith также провела очень детальную оптимизацию архитектуры сервера параметров, базовой конструкции хеш-таблицы, сетевой передачи, многопоточного ускорения, OP Fusion, ускорения набора инструкций и других направлений и добилась значительных успехов. результаты, повышение производительности. На примере асинхронного обучения весь процесс обучения показан следующим образом:

Оптимизация сетевой связи: благодаря внедрению предварительной выборки, градиентной пост-пуши, сетевой ввод-вывод и прямой/обратный расчет графа являются асинхронными, и в то же время он поддерживает разделение потока управления и потока данных, сжатие передачи и другие оптимизации;
Оптимизация памяти. Поддерживая фильтрацию функций, сжатие функций, устранение функций и т. д., можно значительно сэкономить использование памяти на этапе обучения/обслуживания;
Оптимизация вычислений: код горячей точки использует оптимизацию набора инструкций AVX, трудоемкую тонкую настройку операций, ручное слияние операций и другие средства для ускорения процесса расчетов вперед/назад;
Другие аспекты: многопоточная оптимизация, детальное проектирование блокировки, асинхронный ввод-вывод и вычисления и т. д.

В настоящее время Monolith был успешно применен к сценариям в различных отраслях, таких как электронная коммерция, сообщество и видео, через платформу рекомендаций, и его эффективность, стабильность и производительность были полностью проверены. В будущем мы продолжим поддерживать высокую скорость итерации и постоянно оптимизировать работу пользователей и функции платформы.

подарок

Спасибо всем за то, что вы здесь. В настоящее время эта интеллектуальная рекомендательная платформа ByteDance открыта для корпоративных партнеров через движок вулкана. Если ваша компания хочет применять алгоритмы рекомендаций, чтобы способствовать развитию бизнеса, но при этом испытывает трудности с созданием системы рекомендаций, вы также можете попробовать интеллектуальную рекомендательную платформу Volcano Engine. Более подробную информацию можно нажатьпорталучиться:

Стоит отметить, что текущая интеллектуальная рекомендательная платформа открыла 30 мест для бесплатного использования деловыми партнерами, а бесплатное время заканчивается 30 ноября 2021 года. Студенты, которые хотят получить место, отсканируйте QR-код ниже, чтобы зарегистрироваться как можно скорее:

напиши в конце

Наконец, позвольте мне представить, что мы являемся группой рекомендаций Volcano Engine-Intelligent, которая стремится предоставить компаниям по всему миру первоклассную систему рекомендаций. Студенты, изучающие систему машинного обучения, рекомендательную архитектуру и рекомендательный алгоритм, приглашаются к нам. Базовые местоположения: Пекин, Шэньчжэнь, Ханчжоу, Сингапур. Электронная почта для доставки резюме:ai-coop@bytedance.com, тема письма: Имя - Годы работы - Интеллектуальная рекомендация Volcano Engine - Должность Направление, надеюсь на сотрудничество с вами!