Введение и обзор

Мы написали эту книгу, чтобы помочь инженерам по машинному обучению (ML) и специалистам по данным успешно проходить собеседования по проектированию ML-систем. Книга также будет полезна тем, кто хочет получить общее представление о том, как ML применяется в реальном мире.

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

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

Для успешного проектирования сложных ML-систем крайне важно следовать определённой структуре. Неструктурированные ответы затрудняют понимание хода мысли. В этом введении мы предлагаем фреймворк, который используется на протяжении всей книги для решения задач проектирования ML-систем. Фреймворк состоит из следующих ключевых шагов:

1. Уточнение требований
2. Формулировка задачи как ML-задачи
3. Подготовка данных
4. Разработка модели
5. Оценка
6. Развёртывание и обслуживание
7. Мониторинг и инфраструктура

Каждое собеседование по проектированию ML-системы уникально, потому что задача открытая и нет универсального рецепта успеха. Фреймворк призван помочь вам структурировать мысли, но не нужно следовать ему строго. Будьте гибкими. Если интервьюер в основном интересуется разработкой модели, придерживайтесь этого направления.

Давайте разберём каждый шаг фреймворка.

Уточнение требований

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

• Бизнес-цель. Если нас просят создать систему рекомендации аренды жилья для отпуска, возможными мотивациями могут быть увеличение числа бронирований и рост выручки.
• Функции системы. Какие функции должна поддерживать система, которые могут повлиять на проектирование ML-системы? Например, предположим, что нас просят спроектировать систему рекомендации видео. Нам может понадобиться знать, могут ли пользователи ставить «лайк» или «дизлайк» рекомендованным видео, поскольку эти взаимодействия могут использоваться для разметки обучающих данных.
• Данные. Каковы источники данных? Насколько велик датасет? Размечены ли данные?
• Ограничения. Сколько вычислительных ресурсов доступно? Это облачная система или система должна работать на устройстве? Ожидается ли автоматическое улучшение модели со временем?
• Масштаб системы. Сколько у нас пользователей? Сколько объектов, например видео, мы обрабатываем? Каков темп роста этих показателей?
• Производительность. Насколько быстрым должно быть предсказание? Ожидается ли решение в реальном времени? Что важнее — точность или задержка?

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

Формулировка задачи как ML-задачи

Эффективная формулировка задачи играет ключевую роль в решении ML-проблем. Предположим, интервьюер просит вас повысить вовлечённость пользователей видеостримингового сервиса. Низкая вовлечённость — это, безусловно, проблема, но не ML-задача. Поэтому нам нужно сформулировать её как ML-задачу. На практике сначала нужно определить, необходим ли ML для решения данной задачи. На собеседовании по проектированию ML-системы можно смело предполагать, что ML полезен. Итак, мы можем сформулировать задачу следующим образом:

• Определить ML-цель
• Задать входные и выходные данные системы
• Выбрать подходящую категорию ML

Определение ML-цели

Бизнес-целью может быть увеличение продаж на 20% или улучшение удержания пользователей. Но цель может быть нечётко определена, и мы не можем обучить модель, просто сказав ей «увеличь продажи на 20%». Чтобы ML-система решала задачу, нам нужно перевести бизнес-цель в чётко определённую ML-цель. Хорошая ML-цель — та, которую ML-модели могут решить. Посмотрим на примеры в Таблице 1.1. В последующих главах мы увидим больше примеров.

Таблица 1.1: Перевод бизнес-цели в ML-цель

Определение входных и выходных данных системы

Как только мы определились с ML-целью, необходимо задать входные и выходные данные системы. Например, для системы обнаружения вредоносного контента в социальной сети входными данными является публикация, а выходными — вывод о том, является ли эта публикация вредоносной или нет.

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

Ещё одно важное соображение: может существовать несколько способов задать входы и выходы каждой модели. На Рисунке 1.4 показан пример.

Выбор подходящей категории ML

Существует множество способов сформулировать задачу как ML-задачу. Большинство задач можно отнести к одной из категорий ML (листовые узлы), показанных на Рисунке 1.5. Поскольку большинство читателей уже знакомы с ними, мы лишь кратко их опишем.

Обучение с учителем. Модель обучения с учителем решает задачу с использованием обучающего датасета. На практике многие задачи попадают в эту категорию, поскольку обучение на размеченных данных обычно даёт лучшие результаты.

Обучение без учителя. Модели обучения без учителя делают предсказания, обрабатывая данные, не содержащие правильных ответов. Цель модели обучения без учителя —

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

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

Модель классификации. Классификация — это задача предсказания дискретной метки класса; например, следует ли классифицировать входное изображение как «собака», «кошка» или «кролик». Модели классификации можно разделить на две группы:

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

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

Темы для обсуждения

Вот некоторые темы, которые стоит обсудить на собеседовании:

• Что такое хорошая ML-цель? Как сравниваются различные ML-цели? Каковы их плюсы и минусы?
• Каковы входные и выходные данные системы с учётом ML-цели?
• Если в ML-системе используется более одной модели, каковы входные и выходные данные каждой модели?
• Нужно ли решать задачу методом обучения с учителем или без учителя?
• Лучше ли решить задачу с помощью модели регрессии или классификации? В случае классификации — бинарной или многоклассовой? В случае регрессии — каков диапазон выходных значений?

Подготовка данных

ML-модели обучаются непосредственно на данных, что означает: данные с предсказательной силой необходимы для обучения ML-модели. Этот раздел направлен на подготовку высококачественных входных данных для ML-моделей посредством двух ключевых процессов: инженерии данных и инженерии признаков. Мы рассмотрим важные аспекты каждого процесса.

Инженерия данных

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

Источники данных

ML-система может работать с данными из многих различных источников. Знание источников данных — хороший способ ответить на многие контекстные вопросы: кто их собрал? Насколько чисты данные? Можно ли доверять источнику данных? Данные генерируются пользователями или системой?

Хранилище данных

Хранилище данных, также называемое базой данных, — это репозиторий для постоянного хранения коллекций данных и управления ими. Различные базы данных созданы для разных задач, поэтому важно на высоком уровне понимать, как работают разные СУБД. На собеседованиях по проектированию ML-систем обычно не требуется знание внутреннего устройства баз данных.

Извлечение, преобразование и загрузка (ETL)

ETL состоит из трёх этапов:

• Извлечение (Extract). Этот процесс извлекает данные из различных источников.
• Преобразование (Transform). На этом этапе данные очищаются, сопоставляются и преобразуются в определённый формат для удовлетворения операционных нужд.
• Загрузка (Load). Преобразованные данные загружаются в целевое хранилище, которым может быть файл, база данных или хранилище данных [1].

Типы данных

В ML типы данных отличаются от типов в языках программирования, таких как int, float, string и т.д. На высоком уровне типы данных можно разделить на два вида: структурированные и неструктурированные данные, как показано на Рисунке 1.9.

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

Таблица 1.2: Сравнение структурированных и неструктурированных данных

Как показано на Рисунке 1.10, ML-модели работают по-разному в зависимости от типа данных. Понимание и уточнение того, являются ли данные структурированными или неструктурированными, помогает выбрать подходящую ML-модель на этапе разработки модели.

Числовые данные

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

Категориальные данные

Категориальные данные — это данные, которые можно хранить и идентифицировать на основе присвоенных им имён или меток. Например, пол является категориальными данными, поскольку его значение берётся из ограниченного набора. Категориальные данные можно разделить на две группы: номинальные и порядковые.

Номинальные данные — это данные без числовой взаимосвязи между категориями. Например, пол является номинальными данными, поскольку между «мужским» и «женским» нет никакой взаимосвязи. Порядковые данные — это данные с заранее определённым или последовательным порядком. Например, данные рейтинга, принимающие три уникальных значения — «недоволен», «нейтрально» и «доволен», — являются примером порядковых данных.

Инженерия признаков

Инженерия признаков включает два процесса:

• Использование предметных знаний для выбора и извлечения предсказательных признаков из необработанных данных
• Преобразование предсказательных признаков в формат, пригодный для использования моделью

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

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

Операции инженерии признаков

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

Обработка пропущенных значений

Данные в производственной среде часто содержат пропущенные значения, которые обычно можно устранить двумя способами: удалением или импутацией.

Удаление. Этот метод удаляет все записи с пропущенным значением в любом из признаков. Удаление можно разделить на удаление строк и удаление столбцов. При удалении столбцов мы удаляем весь столбец, представляющий признак, если в нём слишком много пропущенных значений. При удалении строк мы удаляем строку, представляющую точку данных, если в ней много пропущенных значений.

Недостаток удаления в том, что оно уменьшает количество данных, которые модель потенциально может использовать для обучения. Это нежелательно, поскольку ML-модели, как правило, работают лучше при доступе к большему объёму данных.

Импутация. Alternatively, мы можем импутировать пропущенные значения, заполнив их определёнными значениями. Некоторые распространённые подходы:

• Заполнение пропущенных значений значениями по умолчанию
• Заполнение пропущенных значений средним, медианой или модой (наиболее часто встречающимся значением)

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

Масштабирование признаков

Масштабирование признаков — это процесс приведения признаков к стандартному диапазону и распределению. Давайте сначала разберёмся, зачем может понадобиться масштабирование признаков.

Многим ML-моделям трудно решать задачу, когда признаки датасета имеют разные диапазоны. Например, такие признаки, как возраст и доход, могут иметь разные диапазоны значений. Кроме того, некоторым моделям трудно решать задачу, когда признак имеет асимметричное распределение. Каковы некоторые методы масштабирования признаков? Давайте рассмотрим.

Нормализация (минимаксное масштабирование). При этом подходе признаки масштабируются так, чтобы все значения находились в диапазоне [0,1][0, 1][0,1] по следующей формуле:

Обратите внимание, что нормализация не изменяет распределение признака. Чтобы изменить распределение признака до стандартного, используется стандартизация.

Стандартизация (Z-нормализация). Стандартизация — это процесс изменения распределения признака так, чтобы оно имело среднее значение 000 и стандартное отклонение 111. Для стандартизации признака используется следующая формула:

Где μ\muμ — среднее значение признака, а σ\sigmaσ — стандартное отклонение.

Логарифмическое масштабирование. Для снижения асимметрии признака широко применяется логарифмическое масштабирование по следующей формуле:

Логарифмическое преобразование может сделать распределение данных менее асимметричным и ускорить сходимость алгоритма оптимизации.

Дискретизация (Бакетирование)

Дискретизация — это процесс преобразования непрерывного признака в категориальный. Например, вместо того чтобы представлять рост как непрерывный признак, мы можем разделить значения роста на дискретные бакеты и представить каждое значение роста через принадлежащий ему бакет. Это позволяет модели сосредоточиться на обучении нескольким категориям вместо бесконечного числа возможностей.

Дискретизацию можно применять и к дискретным признакам. Например, возраст пользователя является дискретным признаком, но дискретизация уменьшает количество категорий, как показано в Таблице 1.3.

Таблица 1.3: Дискретизация числовых атрибутов возраста

Кодирование категориальных признаков

В большинстве ML-моделей все входные и выходные данные должны быть числовыми. Это означает, что если признак является категориальным, его следует закодировать в числа перед передачей в модель. Существует три распространённых метода преобразования категориальных признаков в числовые представления: целочисленное кодирование, унитарное кодирование (one-hot encoding) и обучение эмбеддингов.

Целочисленное кодирование. Каждому уникальному значению категории присваивается целочисленное значение. Например, «Отлично» — это 111, «Хорошо» — 222, «Плохо» — 333. Этот метод полезен, если целочисленные значения имеют естественную взаимосвязь.

Однако когда между категориальными признаками нет порядкового соотношения, целочисленное кодирование не является хорошим выбором. Унитарное кодирование (one-hot encoding), которое мы рассмотрим далее, решает эту проблему.

Унитарное кодирование (One-hot encoding). При использовании этого метода для каждого уникального значения создаётся новый бинарный признак. Как показано на Рисунке 1.14, мы заменяем исходный признак (цвет) тремя новыми бинарными признаками (красный, зелёный и синий). Например, если точка данных имеет «красный» цвет, мы заменяем его на «111, 000, 000».

Обучение эмбеддингов. Ещё один способ кодирования категориального признака — использование обучения эмбеддингов. Эмбеддинг — это отображение категориального признака в NNN-мерный вектор. Обучение эмбеддингов — это процесс изучения N-мерного вектора для каждого уникального значения, которое может принимать категориальный признак. Этот подход полезен, когда количество уникальных значений признака очень велико. В этом случае унитарное кодирование не является хорошим вариантом, поскольку приводит к очень большим размерам вектора. Мы увидим больше примеров в последующих главах.

Темы для обсуждения

Вот некоторые темы, которые стоит обсудить на собеседовании:

• Доступность данных и сбор данных: Каковы источники данных? Какие данные доступны нам и как мы их собираем? Каков объём данных? Как часто поступают новые данные?
• Хранение данных: Где сейчас хранятся данные? В облаке или на устройствах пользователей? Какой формат данных подходит для хранения? Как хранить мультимодальные данные, например, точку данных, которая может содержать как изображения, так и тексты?
• Инженерия признаков: Как мы обрабатываем необработанные данные в форму, полезную для моделей? Что делать с пропущенными данными? Требуется ли инженерия признаков для этой задачи? Какие операции используются для преобразования необработанных данных в формат, пригодный для ML-модели? Нужно ли нормализовать признаки? Какие признаки следует конструировать из необработанных данных? Как планируется объединять данные разных типов, например тексты, числа и изображения?
• Конфиденциальность: Насколько чувствительны доступные данные? Беспокоятся ли пользователи о конфиденциальности своих данных? Требуется ли анонимизация пользовательских данных? Можно ли хранить данные пользователей на наших серверах или доступ к ним возможен только на их устройствах?
• Предвзятость: Есть ли в данных какие-либо предвзятости? Если да, какие виды предвзятости присутствуют и как их исправить?

Разработка модели

Разработка модели — это процесс выбора подходящей ML-модели и её обучения для решения поставленной задачи.

Выбор модели

Выбор модели — это процесс определения наилучшего ML-алгоритма и архитектуры для задачи прогнозирующего моделирования. На практике типичный процесс выбора модели включает:

• Установление простого базового уровня. Например, в системе рекомендации видео базовый уровень можно получить, рекомендуя наиболее популярные видео.
• Эксперименты с простыми моделями. После установления базового уровня хорошей практикой является изучение ML-алгоритмов, которые быстро обучаются, например логистической регрессии.
• Переход к более сложным моделям. Если простые модели не дают удовлетворительных результатов, можно рассмотреть более сложные модели, например глубокие нейронные сети.
• Использование ансамбля моделей для более точных предсказаний. Использование ансамбля нескольких моделей вместо одной может улучшить качество предсказаний. Создание ансамбля можно осуществить тремя способами: бэггинг [2], бустинг [3] и стекинг [4], которые будут рассмотрены в последующих главах.

На собеседовании важно изучить различные варианты моделей и обсудить их плюсы и минусы. Некоторые типичные варианты моделей включают:

• Логистическая регрессия
• Линейная регрессия
• Деревья решений
• Деревья с градиентным бустингом и случайные леса
• Метод опорных векторов (SVM)
• Наивный байесовский классификатор
• Машины факторизации (FM)
• Нейронные сети

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

• Объём данных, необходимый для обучения модели
• Скорость обучения
• Гиперпараметры для настройки и методы подбора гиперпараметров
• Возможность непрерывного обучения
• Вычислительные требования. Более сложная модель может давать более высокую точность, но может требовать больших вычислительных ресурсов, например GPU вместо CPU
• Интерпретируемость модели [5]. Более сложная модель может давать лучшую производительность, но её результаты могут быть менее интерпретируемыми

Не существует единственного лучшего алгоритма, решающего все задачи. Интервьюер хочет убедиться, что вы хорошо понимаете различные ML-алгоритмы, их плюсы и минусы, и способны выбирать модель на основе требований и ограничений. Чтобы помочь вам улучшить навык выбора модели, книга содержит множество примеров. Предполагается, что читатель знаком с распространёнными ML-алгоритмами. Для повторения материала рекомендуем [6].

Обучение модели

После завершения выбора модели приходит время её обучения. На этом шаге есть различные темы, которые стоит обсудить на собеседовании:

• Конструирование датасета
• Выбор функции потерь
• Обучение с нуля vs. дообучение (fine-tuning)
• Распределённое обучение

Рассмотрим каждый пункт.

Конструирование датасета

На собеседовании обычно полезно поговорить о конструировании датасета для обучения и оценки модели. Как показывает Рисунок 1.15, существует 5 шагов построения датасета.

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

Сбор необработанных данных

Это подробно обсуждается на этапе подготовки данных, поэтому здесь мы не повторяемся.

Определение признаков и меток

На этапе инженерии признаков мы уже обсудили, какие признаки использовать. Поэтому сосредоточимся на создании меток для данных. Существует два распространённых способа получить метки: ручная разметка и естественная разметка.

Ручная разметка. Это означает, что отдельные аннотаторы размечают данные вручную. Например, аннотатор размечает, содержит ли публикация дезинформацию или нет. Ручная разметка даёт точные метки, поскольку в процессе участвует человек. Однако у ручной разметки много недостатков: она дорогостоящая и медленная, вносит предвзятость, требует предметных знаний и представляет угрозу для конфиденциальности данных.

Естественная разметка. При естественной разметке истинные метки определяются автоматически без участия человека-аннотатора. Рассмотрим пример для лучшего понимания естественных меток.

Предположим, мы хотим спроектировать ML-систему, которая ранжирует новостные ленты по релевантности. Один из способов решить эту задачу — обучить модель, которая принимает пользователя и публикацию на входе и выдаёт вероятность того, что пользователь нажмёт кнопку «нравится» после просмотра этой публикации. В этом случае обучающими данными являются пары ⟨\langle⟨ пользователь, публикация ⟩\rangle⟩ и соответствующие метки: 1, если пользователю понравилась публикация, и 0, если нет. Таким образом, мы можем естественным образом размечать обучающие данные без участия человека-аннотатора.

На этом шаге важно чётко сообщить, как мы получаем обучающие метки и как выглядят обучающие данные.

Выбор стратегии выборки

Зачастую нецелесообразно собирать все данные, поэтому выборка — эффективный способ сократить объём данных в системе. Распространённые стратегии выборки включают случайную выборку, снежный ком, стратифицированную выборку, резервуарную выборку и выборку по значимости. Подробнее о методах выборки можно прочитать в [7].

Разделение данных

Разделение данных — это процесс разбиения датасета на обучающий, оценочный (валидационный) и тестовый. Подробнее о методах разделения данных см. в [8].

Устранение дисбаланса классов

Датасет с перекошенными метками классов называется несбалансированным датасетом. Класс, составляющий большую долю датасета, называется большинством, а класс, занимающий меньшую долю — меньшинством.

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

Ресемплинг обучающих данных

Ресемплинг — это процесс корректировки соотношения между различными классами для более сбалансированного представления данных. Например, можно применить оверсемплинг (увеличение выборки) для класса меньшинства (Рисунок 1.17) или андерсемплинг (уменьшение выборки) для класса большинства (Рисунок 1.18).

Изменение функции потерь

Этот метод изменяет функцию потерь, чтобы сделать её более устойчивой к дисбалансу классов. Общая идея состоит в том, чтобы придавать больший вес точкам данных из класса меньшинства. Более высокий вес в функции потерь сильнее штрафует модель за неправильное предсказание в отношении класса меньшинства. Это вынуждает модель более эффективно обучаться на классах меньшинства. Две широко применяемые функции потерь для устранения дисбаланса классов — это class-balanced loss [9] и focal loss [10][11].

Выбор функции потерь

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

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

Обучение с нуля vs. дообучение (fine-tuning)

Одна тема, которую может быть полезно кратко обсудить, — это обучение с нуля в сравнении с дообучением (fine-tuning). Fine-tuning означает продолжение обучения модели на новых данных путём внесения небольших изменений в её выученные параметры. Это архитектурное решение, которое может потребоваться обсудить с интервьюером.

Распределённое обучение

Обучение в масштабе становится всё более важным, поскольку модели со временем становятся больше, а объём датасетов также резко увеличивается. Распределённое обучение широко используется для обучения модели путём распределения работы между несколькими рабочими узлами. Эти узлы работают параллельно, чтобы ускорить обучение модели. Существует два основных типа распределённого обучения: параллелизм данных [12] и параллелизм модели [13].

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

Темы для обсуждения

Ниже приведён список тем для обсуждения:

• Выбор модели: Какие ML-модели подходят для задачи и каковы их плюсы и минусы. Вот список тем для рассмотрения при выборе модели: Время, необходимое для обучения Объём обучающих данных, которые ожидает модель Вычислительные ресурсы, которые может потребовать модель Задержка модели при инференсе Можно ли развернуть модель на устройстве пользователя? Интерпретируемость модели. Усложнение модели может повысить её производительность, но результаты могут быть труднее интерпретировать Можно ли использовать непрерывное обучение или нужно обучать с нуля? Сколько параметров у модели? Сколько памяти требуется? Для нейронных сетей стоит обсудить типичные архитектуры/блоки, например ResNet или архитектуры на основе Transformer. Также можно обсудить выбор гиперпараметров, таких как количество скрытых слоёв, количество нейронов, функции активации и т.д.
• Метки датасета: Как получать метки? Размечены ли данные, и если да, насколько хороши аннотации? Если доступны естественные метки, как их получить? Как получать обратную связь от пользователей? Сколько времени требуется для получения естественных меток?
• Обучение модели. Какую функцию потерь следует выбрать? (например, Cross-entropy [14], MSE [15], MAE [16], Huber loss [17] и т.д.) Какую регуляризацию использовать? (например, L1 [19], L2 [18], Entropy Regularization [19], K-fold CV [20] или dropout [21]) Что такое обратное распространение ошибки? Может потребоваться описать распространённые методы оптимизации, такие как SGD [22], AdaGrad [23], Momentum [24] и RMSProp [25]. Какие функции активации использовать и почему? (например, ELU [26], ReLU [27], Tanh [28], Sigmoid [29]). Как работать с несбалансированным датасетом? В чём состоит компромисс смещения/дисперсии? Каковы возможные причины переобучения и недообучения? Как с ними бороться?
• Непрерывное обучение: Хотим ли мы обучать модель онлайн для каждой новой точки данных? Нужно ли персонализировать модель для каждого пользователя? Как часто нужно переобучать модель? Некоторые модели нужно переобучать ежедневно или еженедельно, другие — ежемесячно или ежегодно.

Оценка

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

Офлайн-оценка

Офлайн-оценка — это оценка производительности ML-моделей на этапе разработки модели. Для оценки модели мы обычно сначала делаем предсказания с использованием оценочного датасета. Затем используем различные офлайн-метрики для измерения того, насколько предсказания близки к истинным значениям. В Таблице 1.4 показаны некоторые из наиболее распространённых метрик для различных задач.

Таблица 1.4: Популярные метрики при офлайн-оценке

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

Онлайн-оценка

Онлайн-оценка — это процесс оценки того, как модель работает в производственной среде после развёртывания. Для измерения влияния модели необходимо определить различные метрики. Онлайн-метрики — это те, которые используются при онлайн-оценке и обычно привязаны к бизнес-целям. В Таблице 1.5 показаны различные метрики для разных задач.

Таблица 1.5: Возможные метрики при онлайн-оценке

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

На этом шаге интервьюер оценивает ваше бизнес-чутьё. Поэтому полезно объяснять свой ход мышления и причины выбора тех или иных метрик.

Темы для обсуждения

Вот некоторые темы для обсуждения на этапе оценки:

• Онлайн-метрики: Какие метрики важны для измерения эффективности ML-системы в онлайн-режиме? Как эти метрики соотносятся с бизнес-целью?
• Офлайн-метрики: Какие офлайн-метрики хорошо оценивают предсказания модели на этапе разработки?
• Справедливость и предвзятость: Имеет ли модель потенциал для предвзятости в отношении различных атрибутов, таких как возраст, пол, раса и т.д.? Как это исправить? Что произойдёт, если злоумышленник получит доступ к вашей системе?

Развёртывание и обслуживание

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

• Облачное vs. локальное (на устройстве) развёртывание
• Сжатие модели
• Тестирование в производственной среде
• Пайплайн предсказаний

Рассмотрим каждый пункт.

Облачное vs. локальное (на устройстве) развёртывание

Развёртывание модели в облаке отличается от развёртывания на мобильном устройстве. В Таблице 1.6 приведены основные различия между локальным и облачным развёртыванием.

Таблица 1.6: Компромиссы между облачным и локальным развёртыванием

Сжатие модели

Сжатие модели — это процесс уменьшения размера модели. Это необходимо для снижения задержки инференса и размера модели. Для сжатия моделей широко используются три метода:

• Дистилляция знаний (Knowledge distillation): цель дистилляции знаний — обучить маленькую модель (студент), чтобы она имитировала большую модель (учитель).
• Прунинг (Pruning): прунинг — это процесс нахождения наименее полезных параметров и установки их в ноль. Это приводит к более разреженным моделям, которые можно хранить более эффективно.
• Квантизация (Quantization): параметры модели обычно представлены 32-битными числами с плавающей точкой. При квантизации для представления параметров используется меньше бит, что уменьшает размер модели. Квантизация может происходить во время обучения или после него [37].

Подробнее о сжатии модели рекомендуем прочитать в [38].

Тестирование в производственной среде

Единственный способ убедиться, что модель будет хорошо работать в производственной среде, — протестировать её на реальном трафике. Широко используемые методы тестирования моделей включают теневое развёртывание [39], A/B-тестирование [40], канареечный релиз [41], эксперименты с чередованием [42], бандиты [43] и др.

Чтобы продемонстрировать понимание тестирования в производственной среде, стоит упомянуть хотя бы один из этих методов. Кратко рассмотрим теневое развёртывание и A/B-тестирование.

Теневое развёртывание

При этом методе мы развёртываем новую модель параллельно с существующей. Каждый входящий запрос направляется в обе модели, но только предсказание существующей модели возвращается пользователю.

Теневое развёртывание модели минимизирует риск ненадёжных предсказаний до тех пор, пока новая модель не будет тщательно протестирована. Однако это дорогостоящий подход, удваивающий количество предсказаний.

A/B-тестирование

При этом методе мы развёртываем новую модель параллельно с существующей. Часть трафика направляется к новой модели, а оставшиеся запросы — к существующей.

Для правильного проведения A/B-тестирования необходимо учитывать два важных фактора. Во-первых, трафик, направляемый к каждой модели, должен быть случайным. Во-вторых, A/B-тесты должны проводиться на достаточном количестве точек данных, чтобы результаты были достоверными.

Пайплайн предсказаний

Для обработки запросов в производственной среде нам нужен пайплайн предсказаний. Важное архитектурное решение — выбор между онлайн-предсказанием и батч-предсказанием.

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

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

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

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

Как уже обсуждалось, разработка ML-системы включает гораздо больше, чем просто ML-моделирование. Предложение общей архитектуры ML-системы на собеседовании демонстрирует глубокое понимание того, как различные компоненты работают вместе как единое целое. Интервьюеры часто воспринимают это как ключевой сигнал.

На Рисунке 1.23 показан пример архитектуры ML-системы для персонализированной новостной ленты. Мы рассмотрим её более подробно в Главе 10.

Темы для обсуждения

• Требуется ли сжатие модели? Какие широко используемые методы сжатия существуют?
• Что более подходит — онлайн-предсказание или батч-предсказание? Каковы компромиссы?
• Возможен ли доступ к признакам в реальном времени? Каковы проблемы?
• Как следует тестировать развёрнутую модель в производственной среде?
• ML-система состоит из различных компонентов, работающих вместе для обработки запросов. Каковы обязанности каждого компонента в предложенной архитектуре?
• Какие технологии следует использовать для обеспечения быстрого и масштабируемого обслуживания?

Мониторинг

Мониторинг — это задача отслеживания, измерения и логирования различных метрик. ML-система в производственной среде может выходить из строя по многим причинам. Мониторинг помогает обнаруживать сбои системы при их возникновении, чтобы их можно было исправить как можно быстрее.

Мониторинг — важная тема для обсуждения на собеседованиях по проектированию ML-систем. Две основные области, которые стоит обсудить:

• Почему система даёт сбои в производственной среде
• Что отслеживать

Почему система даёт сбои в производственной среде

Есть различные причины, по которым ML-система может дать сбой после развёртывания в производственной среде. Одна из наиболее распространённых — сдвиг распределения данных.

Сдвиг распределения данных — это сценарий, при котором данные, с которыми модель сталкивается в производственной среде, отличаются от тех, с которыми она сталкивалась во время обучения. На Рисунке 1.24 показан пример, где обучающие данные включали изображения чашек спереди, но во время обслуживания в ML-модель передаётся изображение чашки под другим углом.

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

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

Что отслеживать

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

Операционные метрики: эти метрики обеспечивают работоспособность системы. К ним относятся среднее время обслуживания, пропускная способность, количество запросов предсказаний, загрузка CPU/GPU и т.д.

ML-специфичные метрики:

• Мониторинг входных/выходных данных. Модели настолько хороши, насколько хороши данные, которые они потребляют, поэтому мониторинг входных и выходных данных модели крайне важен.
• Дрейф. Входные данные системы и выходные данные модели отслеживаются для выявления изменений в их базовом распределении.
• Точность модели. Например, мы ожидаем, что точность будет в определённом диапазоне.
• Версии модели. Отслеживание того, какая версия модели развёрнута.

Инфраструктура

Инфраструктура — это фундамент для обучения, развёртывания и поддержания ML-систем.

На многих ML-собеседованиях вопросы об инфраструктуре не задаются. Однако некоторые ML-роли, такие как DevOps и MLOps, могут требовать знаний об инфраструктуре. Поэтому важно уточнить ожидания интервьюера по данной теме.

Инфраструктура — очень обширная тема, которую невозможно резюмировать в нескольких строках. Если вы хотите узнать больше об инфраструктуре ML, обратитесь к [44][45][46].

Резюме

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

Наконец, ни один инженер не может быть экспертом во всех аспектах жизненного цикла ML. Одни инженеры специализируются на развёртывании и производственной среде, другие — на разработке моделей. Одни компании могут не беспокоиться об инфраструктуре, другие могут уделять большое внимание мониторингу и инфраструктуре. Роли в области data science, как правило, требуют больше инженерии данных, тогда как прикладные ML-роли фокусируются на разработке моделей и их внедрении в производство. В зависимости от роли и предпочтений интервьюера некоторые шаги могут обсуждаться подробнее, другие — кратко или даже пропускаться. В целом кандидату следует стремиться вести беседу самостоятельно, при этом будучи готовым следовать за интервьюером, если он задаёт вопрос.

Теперь, понимая эти основы, мы готовы приступить к решению наиболее распространённых вопросов на собеседованиях по проектированию ML-систем.

Ссылки

1. Data warehouse. https://cloud.google.com/learn/what-is-a-data-warehouse.
2. Bagging technique in ensemble learning. https://en.wikipedia.org/wiki/Bootstrap_aggregating.
3. Boosting technique in ensemble learning. https://aws.amazon.com/what-is/boosting/.
4. Stacking technique in ensemble learning. https://machinelearningmastery.com/stacking-ensemble-machine-learning-with-python/.
5. Interpretability in Machine Mearning. https://blog.ml.cmu.edu/2020/08/31/6-interpretability/.
6. Traditional machine learning algorithms. https://machinelearningmastery.com/a-tour-of-machine-learning-algorithms/.
7. Sampling strategies. https://www.scribbr.com/methodology/sampling-methods/.
8. Data splitting techniques. https://machinelearningmastery.com/train-test-split-for-evaluating-machine-learning-algorithms/.
9. Class-balanced loss. https://arxiv.org/pdf/1901.05555.pdf.
10. Focal loss paper. https://arxiv.org/pdf/1708.02002.pdf.
11. Focal loss. https://medium.com/swlh/focal-loss-an-efficient-way-of-handling-class-imbalance-4855ae1db4cb.
12. Data parallelism. https://www.telesens.co/2017/12/25/understanding-data-parallelism-in-machine-learning/.
13. Model parallelism. https://docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-intro.html.
14. Cross entropy loss. https://en.wikipedia.org/wiki/Cross_entropy.
15. Mean squared error loss. https://en.wikipedia.org/wiki/Mean_squared_error.
16. Mean absolute error loss. https://en.wikipedia.org/wiki/Mean_absolute_error.
17. Huber loss. https://en.wikipedia.org/wiki/Huber_loss.
18. L1 and l2 regularization. https://www.analyticssteps.com/blogs/l2-and-l1-regularization-machine-learning.
19. Entropy regularization. https://paperswithcode.com/method/entropy-regularization.
20. K-fold cross validation. https://en.wikipedia.org/wiki/Cross-validation_(statistics).
21. Dropout paper. https://jmlr.org/papers/volume15/srivastava14a/srivastava14a.pdf.
22. Stochastic gradient descent. https://en.wikipedia.org/wiki/Stochastic_gradient_descent.
23. AdaGrad optimization algorithm. https://optimization.cbe.cornell.edu/index.php?title=AdaGrad.
24. Momentum optimization algorithm. https://optimization.cbe.cornell.edu/index.php?title=Momentum.
25. RMSProp optimization algorithm. https://optimization.cbe.cornell.edu/index.php?title=RMSProp.
26. ELU activation function. https://ml-cheatsheet.readthedocs.io/en/latest/activation_functions.html#elu.
27. ReLU activation function. https://ml-cheatsheet.readthedocs.io/en/latest/activation_functions.html#relu.
28. Tanh activation function. https://ml-cheatsheet.readthedocs.io/en/latest/activation_functions.html#tanh.
29. Sigmoid activation function. https://ml-cheatsheet.readthedocs.io/en/latest/activation_functions.html#softmax.
30. FID score. https://en.wikipedia.org/wiki/Fr%C3%A9chet_inception_distance.
31. Inception score. https://en.wikipedia.org/wiki/Inception_score.
32. BLEU metrics. https://en.wikipedia.org/wiki/BLEU.
33. METEOR metrics. https://en.wikipedia.org/wiki/METEOR.
34. ROUGE score. https://en.wikipedia.org/wiki/ROUGE_(metric).
35. CIDEr score. https://arxiv.org/pdf/1411.5726.pdf.
36. SPICE score. https://arxiv.org/pdf/1607.08822.pdf.
37. Quantization-aware training. https://pytorch.org/docs/stable/quantization.html.
38. Model compression survey. https://arxiv.org/pdf/1710.09282.pdf.
39. Shadow deployment. https://christophergs.com/machine%20learning/2019/03/30/deploying-machine-learning-applications-in-shadow-mode/.
40. A/B testing. https://en.wikipedia.org/wiki/A/B_testing.
41. Canary release. https://blog.getambassador.io/cloud-native-patterns-canary-release-1cb8f82d371a.
42. Interleaving experiment. https://netflixtechblog.com/interleaving-in-online-experiments-at-netflix-a04ee392ec55.
43. Multi-armed bandit. https://vwo.com/blog/multi-armed-bandit-algorithm/.
44. ML infrastructure. https://www.run.ai/guides/machine-learning-engineering/machine-learning-infrastructure.
45. Interpretability in ML. https://fullstackdeeplearning.com/spring2021/lecture-6/.
46. Chip Huyen. Designing Machine Learning Systems: An Iterative Process for Production-Ready Application. " O'Reilly Media, Inc.", 2022.

Система визуального поиска

Система помогает пользователям находить изображения, визуально похожие на выбранное. В этой главе мы проектируем систему визуального поиска, аналогичную Pinterest [1][2].

Уточнение требований

Вот типичный диалог между кандидатом и интервьюером.

Кандидат: Нужно ли ранжировать результаты от наиболее похожих к наименее похожим? Интервьюер: Изображения, которые появляются первыми в списке, должны быть более похожи на запросное изображение.

Кандидат: Должна ли система поддерживать видео? Интервьюер: Давайте сосредоточимся только на изображениях.

Кандидат: Платформа вроде Pinterest позволяет пользователям выбирать фрагмент изображения и находить похожие изображения. Должны ли мы поддерживать эту функциональность? Интервьюер: Да.

Кандидат: Являются ли отображаемые изображения персонализированными для пользователя? Интервьюер: Для простоты давайте не будем сосредотачиваться на персонализации. Запросное изображение даёт одинаковые результаты независимо от того, кто его ищет.

Кандидат: Может ли модель использовать метаданные запросного изображения, такие как теги? Интервьюер: На практике модель использует метаданные изображений. Но для простоты предположим, что мы не полагаемся на метаданные, а используем только пиксели изображения.

Кандидат: Могут ли пользователи выполнять другие действия, такие как сохранение, публикация или лайк? Эти действия могут помочь в разметке обучающих данных. Интервьюер: Хорошее замечание. Для простоты предположим, что единственное поддерживаемое действие — это клик по изображению.

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

Кандидат: Мы можем конструировать обучающие данные онлайн и размечать их на основе взаимодействий пользователей. Это ожидаемый способ конструирования обучающих данных? Интервьюер: Да, это звучит разумно.

Кандидат: Насколько быстрым должен быть поиск? Предполагая, что на платформе 100–200 миллиардов изображений, система должна уметь быстро находить похожие изображения. Это разумное предположение? Интервьюер: Да, это разумное предположение.

Подведём итог постановки задачи. Нас просят спроектировать систему визуального поиска. Система находит изображения, похожие на запросное изображение пользователя, ранжирует их по степени сходства и отображает пользователю. Платформа поддерживает только изображения, видео и текстовые запросы недопустимы. Для простоты персонализация не требуется.

Формулировка задачи как ML-задачи

В этом разделе мы выбираем чётко определённую ML-цель и формулируем задачу визуального поиска как ML-задачу.

Определение ML-цели

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

Определение входных и выходных данных системы

Входными данными системы визуального поиска является запросное изображение, предоставленное пользователем. Система выводит изображения, визуально похожие на запросное, ранжированные по степени сходства. На Рисунке 2.2 показаны входные и выходные данные системы визуального поиска.

Выбор подходящей категории ML

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

Обучение представлений. При обучении представлений [3] модель обучается преобразовывать входные данные, такие как изображения, в представления, называемые эмбеддингами. Иначе говоря, модель отображает входные изображения в точки в N-мерном пространстве, называемом пространством эмбеддингов. Эти эмбеддинги обучаются так, чтобы похожие изображения имели близко расположенные эмбеддинги в этом пространстве. На Рисунке 2.3 показано, как два похожих изображения отображаются в две близко расположенные точки в пространстве эмбеддингов. Для наглядности мы визуализируем эмбеддинги изображений (обозначенные «xxx») в 222-мерном пространстве. В реальности это пространство является NNN-мерным, где NNN — размер вектора эмбеддинга.

Как ранжировать изображения с помощью обучения представлений?

Сначала входные изображения преобразуются в векторы эмбеддингов. Затем мы вычисляем оценки сходства между запросным изображением и другими изображениями на платформе, измеряя расстояния в пространстве эмбеддингов. Изображения ранжируются по оценкам сходства, как показано на Рисунке 2.4.

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

Подготовка данных

Инженерия данных

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

• Изображения
• Пользователи
• Взаимодействия пользователей с изображениями

Изображения

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

Таблица 2.1: Метаданные изображений

Пользователи

Данные о пользователях содержат демографические атрибуты, связанные с пользователями, такие как возраст, пол и т.д. В Таблице 2.2 показан пример данных о пользователях.

Таблица 2.2: Данные о пользователях

Взаимодействия пользователей с изображениями

Данные о взаимодействиях содержат различные типы пользовательских взаимодействий. Согласно собранным требованиям, основные типы взаимодействий — это показы и клики. В Таблице 2.3 показан обзор данных о взаимодействиях.

Таблица 2.3: Данные о взаимодействиях пользователей с изображениями

Инженерия признаков

В этом разделе от вас ожидается обсуждение создания хороших признаков и их подготовки в качестве входных данных модели. Это обычно зависит от того, как мы сформулировали задачу и каковы входные данные модели. В разделе «Формулировка задачи как ML-задачи» мы представили систему визуального поиска как задачу ранжирования и использовали обучение представлений для её решения. В частности, мы применили модель, которая принимает изображение на вход. Изображение необходимо предобработать перед передачей в модель. Рассмотрим распространённые операции предобработки изображений:

• Изменение размера (Resizing): модели обычно требуют фиксированных размеров изображений (например, 224×224224 \times 224224×224)
• Масштабирование (Scaling): масштабирование значений пикселей изображения до диапазона от 000 до 111
• Z-нормализация (Z-score normalization): масштабирование значений пикселей так, чтобы они имели среднее значение 000 и дисперсию 111
• Согласованность (Consistent): обеспечение единого цветового режима изображений (например, RGB или CMYK)

Разработка модели

Выбор модели

Мы выбираем нейронные сети по следующим причинам:

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

Какие архитектуры нейронных сетей следует использовать? Важно, чтобы архитектура работала с изображениями. Архитектуры на основе CNN, такие как ResNet [4], или более современные архитектуры на основе Transformer [5], такие как ViT [6], хорошо работают со входными данными в виде изображений. На Рисунке 2.5 показана упрощённая архитектура модели, преобразующей входное изображение в вектор эмбеддинга. Количество свёрточных слоёв, количество нейронов в полносвязных слоях и размер вектора эмбеддинга — это гиперпараметры, которые обычно выбираются экспериментально.

Обучение модели

Для поиска визуально похожих изображений модель должна обучиться строить представления (эмбеддинги) в процессе обучения. В этом разделе мы обсудим, как обучить модель создавать представления изображений.

Распространённым методом обучения представлений изображений является контрастивное обучение [7]. С его помощью мы обучаем модель различать похожие и непохожие изображения. Как показано на Рисунке 2.6, мы предоставляем модели запросное изображение (слева), одно похожее на него изображение (выделенное изображение собаки справа) и несколько непохожих изображений (тоже справа). В процессе обучения модель учится создавать представления, в которых похожее изображение ближе к запросному, чем другие изображения на правой стороне Рисунка 2.6.

Для обучения модели с использованием метода контрастивного обучения нам сначала нужно сконструировать обучающие данные.

Конструирование датасета

Как описано ранее, каждая точка данных, используемая для обучения, содержит запросное изображение, позитивное изображение, похожее на запросное, и n−1{n-1}n−1 негативных изображений, не похожих на запросное. Истинная метка точки данных — это индекс позитивного изображения. Как показано на Рисунке 2.7, вместе с запросным изображением (q) у нас есть nnn других изображений, одно из которых похоже на q (изображение собаки), а остальные n−1{n-1}n−1 изображения непохожи. Истинная метка для этой точки данных — индекс позитивного изображения, равный 222 (второе изображение среди nnn изображений на Рисунке 2.7).

Для конструирования точки обучающих данных мы случайным образом выбираем запросное изображение и n−1{n-1}n−1 изображений в качестве негативных. Для выбора позитивного изображения у нас есть три варианта:

• Использование человеческих суждений
• Использование взаимодействий, таких как клики пользователей, как прокси для сходства
• Искусственное создание похожего изображения из запросного (самонаблюдение, self-supervision)

Оценим каждый вариант.

Использование человеческих суждений

Этот подход основывается на том, что люди-подрядчики вручную находят похожие изображения. Участие людей обеспечивает точные обучающие данные, но использование аннотаторов дорого и требует много времени.

Использование взаимодействий, таких как клики пользователей, как прокси для сходства

В этом подходе мы измеряем сходство на основе данных о взаимодействиях. Например, когда пользователь нажимает на изображение, это изображение считается похожим на запросное изображение q.

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

Искусственное создание похожего изображения из запросного

В этом подходе мы искусственно создаём похожее изображение из запросного. Например, можно аугментировать запросное изображение путём его поворота и использовать вновь созданное изображение как похожее. Недавно разработанные фреймворки, такие как SimCLR [7] и MoCo [8], используют аналогичный подход.

Преимущество этого метода в том, что ручная работа не требуется. Мы можем реализовать простую логику аугментации данных для создания похожих изображений. Кроме того, конструируемые обучающие данные не зашумлены, поскольку аугментация изображения всегда даёт похожее изображение. Главный недостаток этого подхода состоит в том, что конструируемые обучающие данные отличаются от реальных. На практике похожие изображения — это не аугментированные версии запросного изображения; они визуально и семантически похожи, но являются самостоятельными изображениями.

Какой подход лучше всего подходит в нашем случае?

На собеседовании крайне важно предлагать различные варианты и обсуждать их компромиссы. Обычно не существует единственного лучшего решения, которое всегда работает. Здесь мы используем вариант самонаблюдения по двум причинам. Во-первых, с ним не связаны начальные затраты, поскольку процесс можно автоматизировать. Во-вторых, различные фреймворки, такие как SimCLR [7], показали многообещающие результаты при обучении на больших датасетах. Поскольку у нас есть доступ к миллиардам изображений на платформе, этот подход может хорошо подойти.

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

Как только датасет сконструирован, пора обучать модель с подходящей функцией потерь.

Выбор функции потерь

Как показано на Рисунке 2.9, модель принимает изображения на вход и создаёт эмбеддинг для каждого входного изображения. Ex{E_x}Ex​ обозначает эмбеддинг изображения xxx.

Цель обучения — оптимизировать параметры модели так, чтобы похожие изображения имели близкие эмбеддинги в пространстве эмбеддингов. Как показано на Рисунке 2.10, позитивное изображение и запросное должны сближаться в процессе обучения.

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

Кратко опишем работу упрощённой контрастивной функции потерь. Если вы хотите узнать больше о контрастивных функциях потерь, обратитесь к [9].

Как показано на Рисунке 2.11, мы вычисляем контрастивные потери в три шага.

Вычисление сходства. Сначала мы вычисляем сходство между запросным изображением и эмбеддингами других изображений. Скалярное произведение [10] и косинусное сходство [11] широко применяются для измерения сходства между точками в пространстве эмбеддингов. Евклидово расстояние [12] также может измерять сходство. Однако евклидово расстояние обычно плохо работает в высоких измерениях из-за проклятия размерности [13]. Подробнее о проблемах проклятия размерности можно прочитать в [14].

Softmax. К вычисленным расстояниям применяется функция softmax. Это гарантирует, что значения в сумме дают единицу, что позволяет интерпретировать их как вероятности.

Кросс-энтропия (Cross-entropy). Кросс-энтропия [15] измеряет, насколько близки предсказанные вероятности к истинным меткам. Когда предсказанные вероятности близки к истинным, это показывает, что эмбеддинги достаточно хороши для различения позитивного изображения от негативных.

На собеседовании также можно обсудить возможность использования предобученной модели. Например, можно использовать предобученную контрастивную модель и дообучить (fine-tune) её на обучающих данных. Эти предобученные модели уже обучены на больших датасетах, поэтому они выучили хорошие представления изображений. Это значительно сокращает время обучения по сравнению с обучением модели с нуля.

Оценка

После разработки модели можно обсудить её оценку. В этом разделе мы рассмотрим важные метрики для офлайн- и онлайн-оценок.

Офлайн-метрики

Согласно предъявленным требованиям, для офлайн-оценки доступен оценочный датасет. Предположим, что каждая точка данных содержит запросное изображение, несколько изображений-кандидатов и оценку сходства для каждой пары изображение-кандидат/запросное изображение. Оценка сходства — целое число от 000 до 555, где 000 означает отсутствие сходства, а 555 — что два изображения визуально и семантически очень похожи. Для каждой точки данных в оценочном датасете мы сравниваем ранжирование, произведённое моделью, с идеальным ранжированием на основе истинных оценок.

Теперь рассмотрим офлайн-метрики, широко используемые в поисковых системах. Обратите внимание, что поисковые, информационно-поисковые и рекомендательные системы обычно используют одни и те же офлайн-метрики.

• Среднее обратное ранговое значение (MRR)
• Recall@k
• Precision@k
• Средняя точность (mAP)
• Нормализованный дисконтированный кумулятивный выигрыш (nDCG)

MRR. Эта метрика оценивает качество модели, учитывая ранг первого релевантного элемента в каждом выходном списке, созданном моделью, а затем усредняя их. Формула:

Где mmm — общее количество выходных списков, а rankirank_iranki​ — ранг первого релевантного элемента в i-м выходном списке.

На Рисунке 2.13 показано, как это работает. Для каждого из 4 ранжированных списков мы вычисляем обратное ранговое значение (RR) и затем рассчитываем среднее значение RR для получения MRR.

Рассмотрим недостаток этой метрики. Поскольку MRR учитывает только первый релевантный элемент и игнорирует другие релевантные элементы в списке, она не измеряет точность и качество ранжирования в списке. Например, на Рисунке 2.14 показаны выходные данные двух разных моделей. Выходные данные модели 1 содержат 3 релевантных элемента, а модели 2 — 1 релевантный элемент. Однако обратное ранговое значение обеих моделей равно 0,5. Из-за этого недостатка мы не будем использовать эту метрику.

Recall@k. Эта метрика измеряет отношение числа релевантных элементов в выходном списке к общему числу релевантных элементов, доступных во всём датасете. Формула:

Хотя recall@k измеряет, сколько релевантных элементов модель не включила в выходной список, это не всегда хорошая метрика. Разберёмся, почему. В некоторых системах, таких как поисковые системы, общее количество релевантных элементов может быть очень большим. Это отрицательно влияет на recall, поскольку знаменатель очень велик. Например, когда запросное изображение — изображение собаки, в базе данных может быть миллионы изображений собак. Цель — не вернуть каждое изображение собаки, а найти несколько наиболее похожих изображений собак.

Поскольку recall@k не измеряет качество ранжирования модели, мы не будем её использовать.

Precision@k. Эта метрика измеряет долю релевантных элементов среди топ-k элементов в выходном списке. Формула:

Эта метрика измеряет точность выходных списков, но не учитывает качество ранжирования. Например, на Рисунке 2.15, если мы поставим более релевантные элементы выше в списке, точность не изменится. Эта метрика не идеальна для нашего случая, поскольку нам нужно измерять как точность, так и качество ранжирования результатов.

mAP. Эта метрика сначала вычисляет среднюю точность (AP) для каждого выходного списка, а затем усредняет значения AP.

Сначала разберёмся, что такое AP. Она принимает список из kkk элементов, например изображений, и усредняет precision@k при разных значениях kkk. AP высокая, если более релевантные элементы расположены в верхней части списка. Формула AP для списка размером kkk:

Рассмотрим пример для лучшего понимания метрики. На Рисунке 2.16 показаны вычисления AP для каждого из 4 выходных списков, созданных моделью.

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

nDCG. Эта метрика измеряет качество ранжирования выходного списка и показывает, насколько хорошо ранжирование по сравнению с идеальным. Сначала объясним DCG, а затем обсудим nDCG.

Что такое DCG?

DCG вычисляет кумулятивный выигрыш элементов в списке путём суммирования оценки релевантности каждого элемента. Затем оценка накапливается сверху вниз по выходному списку, при этом оценка каждого результата дисконтируется на более низких рангах. Формула:

Где relirel_ireli​ — истинная оценка релевантности изображения, стоящего на позиции iii.

Что такое nDCG?

Поскольку DCG суммирует оценки релевантности элементов и дисконтирует их позиции, результат DCG может быть любым значением. Для получения более осмысленной оценки DCG необходимо нормализовать. Для этого nDCG делит DCG на DCG идеального ранжирования. Формула:

Где IDCGp{IDCG_p}IDCGp​ — DCGDCGDCG идеального ранжирования (ранжирование, упорядоченное по оценкам релевантности элементов). Обратите внимание, что в идеальной системе ранжирования DCG равно IDCG.

Рассмотрим пример для лучшего понимания nDCG. На Рисунке 2.17 показан список выходных изображений и связанные с ними истинные оценки релевантности, созданные поисковой системой.

Мы можем вычислить nDCG в 3 шага:

1. Вычислить DCG
2. Вычислить IDCG
3. Разделить DCG на IDCG

Вычисление DCG: DCG для текущего ранжирования, созданного моделью:

Вычисление IDCG: Вычисление идеального ранжирования аналогично вычислению DCG, за исключением того, что первыми рекомендуются наиболее релевантные элементы (Рисунок 2.18).

IDCG для идеального ранжирования:

Деление DCG на IDCG:

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

Онлайн-метрики

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

Кликабельность (CTR). Эта метрика показывает, как часто пользователи нажимают на отображаемые элементы. CTR можно рассчитать по следующей формуле:

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

Среднее ежедневное, еженедельное и ежемесячное время, проведённое с предложенными изображениями. Эта метрика показывает, насколько пользователи вовлечены в работу с предложенными изображениями. Когда поисковая система точна, ожидается рост этой метрики.

Обслуживание

При обслуживании система возвращает ранжированный список похожих изображений на основе запросного изображения. На Рисунке 2.19 показаны пайплайн предсказаний и пайплайн индексирования. Рассмотрим каждый пайплайн подробнее.

Пайплайн предсказаний

Сервис генерации эмбеддингов

Этот сервис вычисляет эмбеддинг входного запросного изображения. Как показано на Рисунке 2.20, он предобрабатывает изображение и использует обученную модель для определения эмбеддинга.

Сервис ближайших соседей

Получив эмбеддинг запросного изображения, нам нужно найти похожие изображения в пространстве эмбеддингов. Это делает сервис ближайших соседей.

Дадим более формальное определение поиска ближайших соседей. Для запросной точки «q» и набора других точек S он находит ближайшие к «q» точки в множестве S. Обратите внимание, что эмбеддинг изображения — это точка в NNN-мерном пространстве, где NNN — размер вектора эмбеддинга. На Рисунке 2.21 показаны 3 ближайших соседа изображения q. Мы обозначаем запросное изображение как q, а другие изображения — как xxx.

Сервис перестановки (Re-ranking)

Этот сервис включает бизнес-логику и правила. Например, он фильтрует неподходящие результаты, гарантирует, что мы не включаем приватные изображения, удаляет дубликаты и близкие дубликаты и применяет другую аналогичную логику перед отображением окончательных результатов пользователю.

Пайплайн индексирования

Сервис индексирования

Все изображения на платформе индексируются этим сервисом для улучшения производительности поиска.

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

Индексирование увеличивает использование памяти, поскольку мы храним эмбеддинги всех изображений в таблице индексов. Доступны различные оптимизации для уменьшения использования памяти, такие как векторная квантизация [16] и квантизация произведений [17].

Производительность алгоритмов ближайших соседей (NN)

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

Алгоритмы NN можно разделить на две категории: точные и приближённые. Рассмотрим каждую подробнее.

Точный поиск ближайших соседей

Точный поиск ближайших соседей, также называемый линейным поиском, является простейшей формой NN. Он работает путём поиска по всей таблице индексов, вычисления расстояния каждой точки от запросной точки q и извлечения kkk ближайших точек. Временная сложность — O(N×D)O(N \times D)O(N×D), где NNN — общее количество точек, а DDD — размерность точки.

В крупномасштабной системе, где NNN может легко достигать миллиардов, линейная временная сложность слишком медленна.

Приближённый поиск ближайших соседей (ANN)

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

В алгоритмах ANN используется специальная структура данных для снижения временной сложности поиска NN до сублинейной (например, O(D×logN)O(D \times logN)O(D×logN)). Они обычно требуют предварительной обработки или дополнительного пространства.

Алгоритмы ANN можно разделить на следующие три категории:

• ANN на основе деревьев
• ANN на основе локально-чувствительного хэширования (LSH)
• ANN на основе кластеризации

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

ANN на основе деревьев

Алгоритмы на основе деревьев формируют дерево, разбивая пространство на несколько разделов. Затем они используют характеристики дерева для выполнения более быстрого поиска.

Мы формируем дерево, итеративно добавляя новые критерии в каждый узел. Например, одним из критериев для корневого узла может быть: gender === male. Это означает, что любая точка с атрибутом «женский» принадлежит левому поддереву.

В дереве нелистовые узлы делят пространство на два раздела согласно критерию. Листовые узлы указывают на конкретную область в пространстве. На Рисунке 2.23 показан пример пространства, разделённого на 7 областей. Алгоритм ищет только тот раздел, которому принадлежит запросная точка.

Типичные методы на основе деревьев: R-деревья [18], Kd-деревья [19] и Annoy (Approximate Nearest Neighbor Oh Yeah) [20].

Локально-чувствительное хэширование (LSH):

LSH использует специальные хэш-функции для уменьшения размерности точек и группировки их в бакеты. Эти хэш-функции отображают близко расположенные точки в один и тот же бакет. LSH выполняет поиск только среди тех точек, которые принадлежат тому же бакету, что и запросная точка q. Подробнее о LSH можно прочитать в [21].

ANN на основе кластеризации

Эти алгоритмы формируют кластеры, группируя точки на основе сходства. После формирования кластеров алгоритмы выполняют поиск только среди подмножества точек в кластере, которому принадлежит запросная точка.

Какой алгоритм следует использовать?

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

Учитывая объём данных, доступных в современных системах, метод ANN является более практичным решением. В нашей системе визуального поиска мы используем ANN для нахождения похожих эмбеддингов изображений.

Для прикладной ML-роли интервьюер может попросить вас реализовать ANN. Два широко используемых инструмента — Faiss [22] (разработан Meta) и ScaNN [23] (разработан Google). Каждый поддерживает большинство методов, описанных в этой главе. Рекомендуется ознакомиться хотя бы с одной из этих библиотек, чтобы лучше понять концепции и обрести уверенность в реализации поиска ближайших соседей на ML-собеседовании с практическим заданием.

Дополнительные темы для обсуждения

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

• Модерация контента в системе путём выявления и блокировки неподходящих изображений [24].
• Различные виды предвзятости в системе, такие как позиционная предвзятость [25][26].
• Как использовать метаданные изображений, такие как теги, для улучшения результатов поиска. Это рассматривается в Главе 3: Система размытия Google Street View.
• Умное кадрирование с использованием обнаружения объектов [27].
• Как использовать графовые нейронные сети для построения лучших представлений [28].
• Поддержка возможности поиска изображений по текстовому запросу. Мы рассматриваем это в Главе 4.
• Как использовать активное обучение [29] или ML с участием человека (human-in-the-loop) [30] для более эффективной разметки данных.

Ссылки

1. Visual search at pinterest. https://arxiv.org/pdf/1505.07647.pdf.
2. Visual embeddings for search at Pinterest. https://medium.com/pinterest-engineering/unifying-visual-embeddings-for-visual-search-at-pinterest-74ea7ea103f0.
3. Representation learning. https://en.wikipedia.org/wiki/Feature_learning.
4. ResNet paper. https://arxiv.org/pdf/1512.03385.pdf.
5. Transformer paper. https://arxiv.org/pdf/1706.03762.pdf.
6. Vision Transformer paper. https://arxiv.org/pdf/2010.11929.pdf.
7. SimCLR paper. https://arxiv.org/pdf/2002.05709.pdf.
8. MoCo paper.
9. Contrastive representation learning methods. https://lilianweng.github.io/posts/2019-11-10-self-supervised/.
10. Dot product. https://en.wikipedia.org/wiki/Dot_product.
11. Cosine similarity. https://en.wikipedia.org/wiki/Cosine_similarity.
12. Euclidean distance. https://en.wikipedia.org/wiki/Euclidean_distance.
13. Curse of dimensionality. https://en.wikipedia.org/wiki/Curse_of_dimensionality.
14. Curse of dimensionality issues in ML. https://www.mygreatlearning.com/blog/understanding-curse-of-dimensionality/.
15. Cross-entropy loss. https://en.wikipedia.org/wiki/Cross_entropy.
16. Vector quantization. http://ws.binghamton.edu/fowler/fowler%20personal%20page/EE523_files/Ch_10_1%20VQ%20Description%20(PPT).pdf.
17. Product quantization. https://towardsdatascience.com/product-quantization-for-similarity-search-2f1f67c5fddd.
18. R-Trees. https://en.wikipedia.org/wiki/R-tree.
19. KD-Tree. https://kanoki.org/2020/08/05/find-nearest-neighbor-using-kd-tree/.
20. Annoy. https://towardsdatascience.com/comprehensive-guide-to-approximate-nearest-neighbors-algorithms-8b94f057d6b6.
21. Locality-sensitive hashing. https://web.stanford.edu/class/cs246/slides/03-lsh.pdf.
22. Faiss library. https://github.com/facebookresearch/faiss/wiki.
23. ScaNN library. https://github.com/google-research/google-research/tree/master/scann.
24. Content moderation with ML. https://appen.com/blog/content-moderation/.
25. Bias in AI and recommendation systems. https://www.searchenginejournal.com/biases-search-recommender-systems/339319/#close.
26. Positional bias. https://eugeneyan.com/writing/position-bias/.
27. Smart crop. https://blog.twitter.com/engineering/en_us/topics/infrastructure/2018/Smart-Auto-Cropping-of-Images.
28. Better search with gnns. https://arxiv.org/pdf/2010.01666.pdf.
29. Active learning. https://en.wikipedia.org/wiki/Active_learning_(machine_learning).
30. Human-in-the-loop ML. https://arxiv.org/pdf/2108.00941.pdf.

Система размытия Google Street View

Google Street View [1] — это технология в Google Maps, предоставляющая интерактивные панорамные изображения улиц множества общественных дорожных сетей по всему миру. В 2008 году Google создала систему, которая автоматически размывает лица людей и номерные знаки для защиты персональных данных пользователей. В этой главе мы проектируем систему размытия, аналогичную Google Street View.

Уточнение требований

Ниже приведён типичный диалог между кандидатом и интервьюером.

Кандидат: Можно ли считать, что бизнес-цель системы — защита персональных данных пользователей? Интервьюер: Да.

Кандидат: Мы хотим спроектировать систему, которая обнаруживает все лица людей и номерные знаки на изображениях Street View и размывает их перед отображением пользователям. Это верно? Могу ли я предположить, что пользователи могут сообщать об изображениях, которые были размыты некорректно? Интервьюер: Да, это справедливые предположения.

Кандидат: Есть ли у нас аннотированный датасет для этой задачи? Интервьюер: Предположим, у нас есть выборка из 1 миллиона изображений. Лица людей и номерные знаки на них размечены вручную.

Кандидат: Датасет может не содержать лиц некоторых расовых групп, что может привести к предвзятости в отношении определённых человеческих характеристик, таких как раса, возраст, пол и т.д. Это справедливое предположение? Интервьюер: Хорошее замечание. Для простоты давайте не будем сегодня фокусироваться на честности и предвзятости.

Кандидат: Моё понимание таково, что задержка не является большой проблемой, поскольку система может обнаруживать объекты и размывать их в автономном режиме. Это верно? Интервьюер: Да. Мы можем отображать пользователям существующие изображения, пока новые обрабатываются в автономном режиме.

Давайте подведём итог постановки задачи. Мы хотим спроектировать систему размытия для Street View, которая автоматически размывает номерные знаки и лица людей. Нам предоставлен обучающий датасет из 1 миллиона изображений с аннотированными лицами людей и номерными знаками. Бизнес-цель системы — защита персональных данных пользователей.

Формулировка задачи как ML-задачи

В этом разделе мы формулируем задачу как ML-задачу.

Определение ML-цели

Бизнес-цель этой системы — защитить персональные данные пользователей, размыв видимые номерные знаки и лица людей на изображениях Street View. Но защита персональных данных — это не ML-цель, поэтому нам нужно перевести её в ML-цель, которую может решить ML-система. Одна из возможных ML-целей — точное обнаружение интересующих объектов на изображении. Если ML-система может точно обнаружить эти объекты, мы можем размыть их перед отображением изображений пользователям.

В этой главе мы используем слово «объекты» вместо «лица людей и номерные знаки» для краткости.

Определение входных и выходных данных системы

Входные данные модели обнаружения объектов — это изображение с нулём или несколькими объектами в разных местах. Модель обнаруживает эти объекты и выводит их местоположения. На рисунке 3.2 показана система обнаружения объектов вместе с её входными и выходными данными.

Выбор подходящей категории ML

В общем случае система обнаружения объектов решает две задачи:

• Прогнозирование местоположения каждого объекта на изображении
• Прогнозирование класса каждого ограничивающего прямоугольника (например, собака, кошка и т.д.)

Первая задача является задачей регрессии, поскольку местоположение может быть представлено координатами (x,y)(x, y)(x,y), которые являются числовыми значениями. Вторая задача может быть сформулирована как задача многоклассовой классификации.

Традиционно архитектуры обнаружения объектов делятся на одноэтапные и двухэтапные сети. Недавно архитектуры на основе Transformer, такие как DETR [2], показали перспективные результаты, но в этой главе мы в основном рассматриваем двухэтапные и одноэтапные архитектуры.

Двухэтапные сети

Как следует из названия, в двухэтапных сетях используются две отдельные модели:

1. Сеть предложения регионов (RPN): сканирует изображение и предлагает кандидатные регионы, которые, вероятно, содержат объекты.
2. Классификатор: обрабатывает каждый предложенный регион и классифицирует его как класс объекта.

На рисунке 3.3 показаны эти два этапа.

Широко используемые двухэтапные сети: R-CNN [3], Fast R-CNN [4] и FasterRCNN [5].

Одноэтапные сети

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

Широко используемые одноэтапные сети: архитектуры YOLO [6] и SSD [7].

Одноэтапные против двухэтапных

Двухэтапные сети состоят из двух компонентов, которые работают последовательно, поэтому они обычно медленнее, но точнее.

В нашем случае датасет содержит 1 миллион изображений, что не является огромным по современным меркам. Это означает, что использование двухэтапной сети не увеличивает стоимость обучения чрезмерно. Поэтому для данного упражнения мы начнём с двухэтапной сети. Когда объём обучающих данных увеличивается или прогнозы нужно делать быстрее, мы можем перейти на одноэтапные сети.

Подготовка данных

Разработка данных

В главе «Введение» мы обсуждали основы разработки данных. Кроме того, обычно полезно обсудить конкретные данные, доступные для текущей задачи. Для этой задачи доступны следующие данные:

• Аннотированный датасет
• Изображения Street View

Рассмотрим каждый из них подробнее.

Аннотированный датасет

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

Таблица 3.1: Несколько точек данных из аннотированного датасета

Каждый ограничивающий прямоугольник представляет собой список из 4 чисел: координаты X и Y верхнего левого угла, затем ширина и высота объекта.

Изображения Street View

Это изображения Street View, собранные командой получения данных. ML-система обрабатывает эти изображения для обнаружения лиц людей и номерных знаков. В таблице 3.2 показаны метаданные изображений.

Таблица 3.2: Метаданные изображений Street View

Разработка признаков

На этапе разработки признаков мы сначала применяем стандартные методы, такие как изменение размера и нормализация. После этого мы увеличиваем размер датасета с помощью метода аугментации данных. Рассмотрим это подробнее.

Аугментация данных

Метод аугментации данных предполагает добавление слегка изменённых копий исходных данных или создание новых данных искусственным образом из исходных. По мере увеличения размера датасета модель способна обучаться более сложным паттернам. Этот метод особенно полезен, когда датасет несбалансирован, поскольку увеличивает количество точек данных в классах меньшинства.

Особым видом аугментации данных является аугментация изображений. Среди широко используемых методов аугментации:

• Случайная обрезка
• Случайное изменение насыщенности
• Вертикальное или горизонтальное отражение
• Поворот и/или трансляция
• Аффинные преобразования
• Изменение яркости, насыщенности или контраста

На рисунке 3.5 показано изображение с применёнными к нему различными методами аугментации данных.

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

Аугментация данных используется в автономной или онлайн-форме.

• Автономная: аугментация изображений перед обучением
• Онлайн: аугментация изображений на лету во время обучения

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

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

На рисунке 3.6 показан процесс подготовки датасета. При предобработке изображения изменяются в размере, масштабируются и нормализуются. При аугментации изображений количество изображений увеличивается. Предположим, что количество увеличивается с 1 миллиона до 10 миллионов.

Разработка модели

Выбор модели

Как упоминалось в разделе «Формулировка задачи как ML-задачи», мы выбираем двухэтапные сети. На рисунке 3.7 показана типичная двухэтапная архитектура.

Рассмотрим каждый компонент.

Свёрточные слои

Свёрточные слои [9] обрабатывают входное изображение и выдают карту признаков.

Сеть предложения регионов (RPN)

RPN предлагает кандидатные регионы, которые могут содержать объекты. В качестве архитектуры используются нейронные сети; на вход поступает карта признаков, созданная свёрточными слоями, а выходом являются кандидатные регионы на изображении.

Классификатор

Классификатор определяет класс объекта для каждого кандидатного региона. На вход поступают карта признаков и предложенные кандидатные регионы, и каждому региону присваивается класс объекта. Этот классификатор обычно основан на нейронных сетях.

На собеседованиях по проектированию ML-систем от вас, как правило, не ожидают обсуждения архитектуры этих нейронных сетей.

Обучение модели

Процесс обучения нейронной сети обычно включает три шага: прямое распространение, вычисление потерь и обратное распространение. Читатели должны быть знакомы с этими шагами, но для получения дополнительной информации см. [10]. В этом разделе мы обсуждаем функции потерь, обычно используемые для обнаружения объектов.

Ожидается, что модель обнаружения объектов будет хорошо выполнять две задачи. Во-первых, предсказанные ограничивающие прямоугольники объектов должны иметь высокое перекрытие с ground truth ограничивающими прямоугольниками. Это задача регрессии. Во-вторых, предсказанные вероятности для каждого класса объекта должны быть точными. Это задача классификации. Давайте определим функцию потерь для каждой из них.

Потери регрессии: эти потери измеряют, насколько предсказанные ограничивающие прямоугольники совпадают с ground truth ограничивающими прямоугольниками. Мы используем стандартные функции потерь регрессии, такие как среднеквадратическая ошибка (MSE) [11], и обозначаем её LregL_{r e g}Lreg​ :

Где:

• MMM : общее количество предсказаний
• xix_ixi​ : ground truth координата X верхнего левого угла
• x^i\hat{x}_ix^i​ : предсказанная координата X верхнего левого угла
• yiy_iyi​ : ground truth координата Y верхнего левого угла
• y^i\hat{y}_iy^​i​ : предсказанная координата Y верхнего левого угла
• wiw_iwi​ : ground truth ширина
• w^i:\hat{w}_i:w^i​: предсказанная ширина
• hih_ihi​ : ground truth высота
• h^i\hat{h}_ih^i​ : предсказанная высота

Потери классификации: это измерение того, насколько точны предсказанные вероятности для каждого обнаруженного объекта. Здесь мы используем стандартную функцию потерь классификации, такую как log loss (кросс-энтропия) [12], и обозначаем её LclsL_{c l s}Lcls​ :

Где:

• MMM : общее количество обнаруженных ограничивающих прямоугольников
• CCC : общее количество классов
• yiy_iyi​ : ground truth метка для обнаружения iii
• y^i:\hat{y}_i:y^​i​: предсказанная метка класса для обнаружения iii

Для определения итоговой функции потерь, измеряющей общую производительность модели, мы объединяем потери классификации и потери регрессии, взвешенные балансирующим параметром λ\lambdaλ :

L=Lcls+λLregL=L_{c l s}+\lambda L_{r e g}L=Lcls​+λLreg​

Оценка

На собеседовании крайне важно обсудить, как оценивать ML-систему. Интервьюер обычно хочет знать, какие метрики вы бы выбрали и почему. В этом разделе описывается, как обычно оцениваются системы обнаружения объектов, а затем выбираются важные метрики для автономной и онлайн-оценки.

Модель обнаружения объектов обычно должна обнаруживать N\mathrm{N}N различных объектов на изображении. Для измерения общей производительности модели мы оцениваем каждый объект отдельно, а затем усредняем результаты.

На рисунке 3.8 показан вывод модели обнаружения объектов. На нём показаны как ground truth, так и обнаруженные ограничивающие прямоугольники. Как видно, модель обнаружила 6 ограничивающих прямоугольников, хотя у нас есть только два экземпляра объекта.

Когда предсказанный ограничивающий прямоугольник считается правильным? Чтобы ответить на этот вопрос, нам нужно понять определение пересечения по объединению.

Пересечение по объединению (IOU): IOU измеряет перекрытие между двумя ограничивающими прямоугольниками. На рисунке 3.93.93.9 показано визуальное представление IOU.

IOU определяет, является ли обнаруженный ограничивающий прямоугольник правильным. IOU равный 1 является идеальным, что указывает на полное совпадение обнаруженного и ground truth ограничивающего прямоугольника. На практике IOU равный 1 встречается редко. Более высокое значение IOU означает, что предсказанный ограничивающий прямоугольник точнее. Порог IOU обычно используется для определения того, является ли обнаруженный ограничивающий прямоугольник правильным (истинно положительным) или неправильным (ложно положительным). Например, порог IOU 0,70,70,7 означает, что любое обнаружение с перекрытием 0,70,70,7 или выше с ground truth ограничивающим прямоугольником является правильным обнаружением.

Теперь, зная, что такое IOU и как определить правильные и неправильные предсказания ограничивающих прямоугольников, обсудим метрики для автономной оценки.

Автономные метрики

Разработка модели — это итеративный процесс. Мы используем автономные метрики для быстрой оценки производительности новых разработанных моделей. Вот некоторые метрики, которые могут быть полезны для системы обнаружения объектов:

• Precision
• Average precision
• Mean average precision

Precision

Это доля правильных обнаружений среди всех обнаружений на всех изображениях. Высокое значение precision показывает, что обнаружения системы более надёжны.

Для вычисления precision нам нужно выбрать порог IOU. Рассмотрим пример, чтобы лучше понять это. На рисунке 3.103.103.10 показан набор ground truth ограничивающих прямоугольников и обнаруженных ограничивающих прямоугольников с соответствующими значениями IOU.

Вычислим precision для трёх различных порогов IOU: 0,7, 0,5 и 0,1.

• Порог IOU =0,7=0.7=0,7 Из шести общих обнаружений два имеют IOU выше 0,7. Следовательно, у нас два правильных предсказания при этом пороге. Precision 0.7= Correct detections Total detections =26=0.33\text { Precision }_{0.7}=\frac{\text { Correct detections }}{\text { Total detections }}=\frac{2}{6}=0.33 Precision 0.7​= Total detections Correct detections ​=62​=0.33
• Порог IOU =0,5=0.5=0,5 При этом пороге у нас три обнаружения с IOU выше 0,50,50,5 : Precision 0.5= Correct detections Total detections =36=0.5\text { Precision }_{0.5}=\frac{\text { Correct detections }}{\text { Total detections }}=\frac{3}{6}=0.5 Precision 0.5​= Total detections Correct detections ​=63​=0.5
• Порог IOU =0,1=0.1=0,1 На этот раз у нас четыре правильных обнаружения: Precision 0.1= Correct detections Total detections =46=0.67\text { Precision }_{0.1}=\frac{\text { Correct detections }}{\text { Total detections }}=\frac{4}{6}=0.67 Precision 0.1​= Total detections Correct detections ​=64​=0.67

Как вы могли заметить, основным недостатком этой метрики является то, что precision варьируется при разных порогах IOU. Поэтому трудно понять общую производительность модели, глядя на оценку precision при конкретном пороге IOU. Average precision устраняет это ограничение.

Average Precision (AP) Эта метрика вычисляет precision при различных порогах IOU и рассчитывает их среднее. Формула AP:

Где P(r)P(r)P(r) — precision при пороге IOU rrr.

Вышеприведённую формулу можно аппроксимировать дискретным суммированием по предопределённому списку порогов. Например, в бенчмарке pascal VOC2008 [13] AP вычисляется по 11 равномерно распределённым пороговым значениям.

AP суммирует общую precision модели для конкретного класса объектов (например, лица людей). Для измерения общей precision модели по всем классам объектов (например, лица людей и номерные знаки) нам нужно использовать mean average precision.

Mean average precision (mAP) Это среднее значение AP по всем классам объектов. Эта метрика суммирует общую производительность модели. Вот формула:

Где CCC — общее количество классов объектов, которые модель обнаруживает.

Метрика mAP широко используется для оценки систем обнаружения объектов. Чтобы узнать, какие пороги используются в стандартных бенчмарках, обратитесь к [14] [15].

Онлайн-метрики

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

В завершение раздела оценки: мы используем mAP и AP в качестве автономных метрик. mAP измеряет общую precision модели, а AP даёт нам представление о precision модели для конкретных классов. Основная метрика онлайн-оценки — «жалобы пользователей».

Обслуживание

В этом разделе мы сначала рассмотрим общую проблему, которая может возникать в системах обнаружения объектов: перекрывающиеся ограничивающие прямоугольники. Затем предлагаем общий дизайн ML-системы.

Перекрывающиеся ограничивающие прямоугольники

При запуске алгоритма обнаружения объектов на изображении очень часто можно видеть перекрывающиеся ограничивающие прямоугольники. Это происходит потому, что сеть RPN предлагает различные сильно перекрывающиеся ограничивающие прямоугольники вокруг каждого объекта. Важно сузить эти ограничивающие прямоугольники до одного на каждый объект во время вывода.

Широко используемым решением является алгоритм «Подавление немаксимумов» (NMS) [16]. Рассмотрим, как он работает.

NMS

NMS — это алгоритм постобработки, предназначенный для выбора наиболее подходящих ограничивающих прямоугольников. Он сохраняет высоко уверенные ограничивающие прямоугольники и удаляет перекрывающиеся. На рисунке 3.11 показан пример.

NMS — часто запрашиваемый алгоритм на собеседованиях по проектированию ML-систем, поэтому рекомендуется хорошо его понимать [17].

Проектирование ML-системы

Как показано на рисунке 3.12, мы предлагаем дизайн ML-системы для системы размытия.

Рассмотрим каждый конвейер подробнее.

Конвейер пакетного прогнозирования

Согласно собранным требованиям, задержка не является большой проблемой, поскольку мы можем отображать пользователям существующие изображения, пока новые обрабатываются. Поскольку мгновенные результаты не требуются, мы можем использовать пакетное прогнозирование и предвычислять результаты обнаружения объектов.

Предобработка Этот компонент предобрабатывает исходные изображения. Данный раздел не обсуждает операции предобработки, поскольку они уже были рассмотрены в разделе разработки признаков.

Сервис размытия Он выполняет следующие операции с изображением Street View:

1. Предоставляет список объектов, обнаруженных на изображении.
2. Уточняет список обнаруженных объектов с помощью компонента NMS.
3. Размывает обнаруженные объекты.
4. Сохраняет размытое изображение в объектном хранилище (размытые изображения Street View).

Обратите внимание, что в дизайне сервисы предобработки и размытия разделены. Причина в том, что предобработка изображений, как правило, является процессом, ограниченным CPU, тогда как сервис размытия зависит от GPU. Разделение этих сервисов имеет два преимущества:

• Независимое масштабирование сервисов в зависимости от получаемой нагрузки.
• Лучшее использование ресурсов CPU и GPU.

Конвейер данных

Этот конвейер отвечает за обработку отчётов пользователей, генерацию новых обучающих данных и подготовку обучающих данных для использования моделью. Компоненты конвейера данных в основном говорят сами за себя. Единственный компонент, требующий дополнительного объяснения, — это извлечение трудных отрицательных примеров.

Извлечение трудных отрицательных примеров. Трудные отрицательные примеры — это примеры, которые явно создаются как отрицательные из неправильно предсказанных примеров, а затем добавляются в обучающий датасет. При повторном обучении модели на обновлённом обучающем датасете она должна показывать лучшие результаты.

Дополнительные темы для обсуждения

Если время позволяет, вот некоторые дополнительные темы для обсуждения:

• Чем архитектуры обнаружения объектов на основе Transformer отличаются от одноэтапных или двухэтапных моделей, и каковы их преимущества и недостатки [18].
• Методы распределённого обучения для улучшения обнаружения объектов на большем датасете [19] [20].
• Как Общий регламент по защите данных (GDPR) в Европе может повлиять на нашу систему [21].
• Оценка предвзятости в системах обнаружения лиц [22] [23].
• Как непрерывно дообучать модель [24].
• Как использовать активное обучение [25] или ML с участием человека [26] для выбора точек данных для обучения.

Ссылки

1. Google Street View. https://www.google.com/streetview.
2. DETR. https://github.com/facebookresearch/detr.
3. RCNN family. https://lilianweng.github.io/posts/2017-12-31-object-recognition-part-3.
4. Fast R-CNN paper. https://arxiv.org/pdf/1504.08083.pdf.
5. Faster R-CNN paper. https://arxiv.org/pdf/1506.01497.pdf.
6. YOLO family. https://pyimagesearch.com/2022/04/04/introduction-to-the-yolo-family.
7. SSD. https://jonathan-hui.medium.com/ssd-object-detection-single-shot-multibox-detector-for-real-time-processing-9bd8deac0e06.
8. Data augmentation techniques. https://www.kaggle.com/getting-started/190280.
9. CNN. https://en.wikipedia.org/wiki/Convolutional_neural_network.
10. Forward pass and backward pass. https://www.youtube.com/watch?v=qzPQ8cEsVK8.
11. MSE. https://en.wikipedia.org/wiki/Mean_squared_error.
12. Log loss. https://en.wikipedia.org/wiki/Cross_entropy.
13. Pascal VOC. http://host.robots.ox.ac.uk/pascal/VOC/voc2008/index.html.
14. COCO dataset evaluation. https://cocodataset.org/#detection-eval.
15. Object detection evaluation. https://github.com/rafaelpadilla/Object-Detection-Metrics.
16. NMS. https://en.wikipedia.org/wiki/NMS.
17. Pytorch implementation of NMS. https://learnopencv.com/non-maximum-suppression-theory-and-implementation-in-pytorch/.
18. Recent object detection models. https://viso.ai/deep-learning/object-detection/.
19. Distributed training in Tensorflow. https://www.tensorflow.org/guide/distributed_training.
20. Distributed training in Pytorch. https://pytorch.org/tutorials/beginner/dist_overview.html.
21. GDPR and ML. https://www.oreilly.com/radar/how-will-the-gdpr-impact-machine-learning.
22. Bias and fairness in face detection. http://sibgrapi.sid.inpe.br/col/sid.inpe.br/sibgrapi/2021/09.04.19.00/doc/103.pdf.
23. AI fairness. https://www.kaggle.com/code/alexisbcook/ai-fairness.
24. Continual learning. https://towardsdatascience.com/tag/fine-tuning/.
25. Active learning. https://en.wikipedia.org/wiki/Active_learning_(machine_learning).
26. Human-in-the-loop ML. https://arxiv.org/pdf/2108.00941.pdf.

Поиск видео на YouTube

На видеохостинговых платформах, таких как YouTube, количество видео может быстро вырасти до миллиардов. В этой главе мы проектируем систему поиска видео, которая может эффективно обрабатывать такой объём контента. Как показано на рисунке 4.1, пользователь вводит текст в поисковую строку, и система отображает наиболее релевантные видео для данного текста.

Уточнение требований

Ниже приведён типичный диалог между кандидатом и интервьюером.

Кандидат: Поисковый запрос только текстовый, или пользователи могут искать с помощью изображения или видео? Интервьюер: Только текстовые запросы.

Кандидат: Контент на платформе представлен только в форме видео? А как насчёт изображений или аудиофайлов? Интервьюер: Платформа обслуживает только видео.

Кандидат: Система поиска YouTube очень сложная. Могу ли я предположить, что релевантность видео определяется исключительно его визуальным содержимым и текстовыми данными, связанными с видео, такими как название и описание? Интервьюер: Да, это справедливое предположение.

Кандидат: Есть ли какие-либо обучающие данные? Интервьюер: Да, предположим, у нас есть десять миллионов пар ⟨\langle⟨ видео, текстовый запрос ⟩\rangle⟩.

Кандидат: Нужно ли поддерживать другие языки в системе поиска? Интервьюер: Для простоты предположим, что поддерживается только английский.

Кандидат: Сколько видео доступно на платформе? Интервьюер: Один миллиард видео.

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

Подведём итог постановки задачи. Нам необходимо спроектировать систему поиска видео. Входными данными является текстовый запрос, а выходными — список видео, релевантных текстовому запросу. Для поиска релевантных видео мы используем как визуальное содержимое видео, так и текстовые данные. Нам предоставлен датасет из десяти миллионов пар ⟨\langle⟨ видео, текстовый запрос ⟩\rangle⟩ для обучения модели.

Формулировка задачи как ML-задачи

Определение ML-цели

Пользователи ожидают, что поисковые системы будут предоставлять релевантные и полезные результаты. Один из способов перевести это в ML-цель — ранжировать видео по их релевантности текстовому запросу.

Определение входных и выходных данных системы

Как показано на рисунке 4.2, система поиска принимает текстовый запрос в качестве входных данных и выводит ранжированный список видео, отсортированных по релевантности текстовому запросу.

Выбор подходящей категории ML

Для определения релевантности между видео и текстовым запросом мы используем как визуальное содержимое, так и текстовые данные видео. Общий обзор дизайна можно увидеть на рисунке 4.3.

Кратко рассмотрим каждый компонент.

Визуальный поиск

Этот компонент принимает текстовый запрос в качестве входных данных и выводит список видео. Видео ранжируются на основе сходства между текстовым запросом и визуальным содержимым видео.

Обучение представлений (Representation learning) — широко используемый подход для поиска видео путём обработки их визуального содержимого. В этом подходе текстовый запрос и видео кодируются отдельно двумя энкодерами. Как показано на рисунке 4.4, ML-модель содержит видеоэнкодер, который генерирует вектор embedding из видео, и текстовый энкодер, который генерирует вектор embedding из текста. Оценка сходства между видео и текстом вычисляется с помощью скалярного произведения их представлений.

Для ранжирования видео, визуально и семантически схожих с текстовым запросом, мы вычисляем скалярное произведение между текстом и каждым видео в пространстве embeddings, а затем ранжируем видео по оценкам сходства.

Текстовый поиск

На рисунке 4.5 показано, как работает текстовый поиск, когда пользователь вводит текстовый запрос: «dogs playing indoor». Видео с наиболее схожими названиями, описаниями или тегами с текстовым запросом отображаются в качестве результата.

Инвертированный индекс — распространённый метод создания компонента текстового поиска, обеспечивающий эффективный полнотекстовый поиск в базах данных. Поскольку инвертированные индексы не основаны на машинном обучении, затрат на обучение нет. Популярной поисковой системой, которую часто используют компании, является Elasticsearch — масштабируемый поисковый движок и хранилище документов. Для получения дополнительной информации и более глубокого понимания Elasticsearch обратитесь к [1].

Подготовка данных

Разработка данных

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

Таблица 4.1: Аннотированный датасет

Разработка признаков

Почти все ML-алгоритмы принимают только числовые входные значения. Неструктурированные данные, такие как тексты и видео, на этом шаге необходимо преобразовать в числовое представление. Рассмотрим, как подготовить текстовые и видеоданные для модели.

Подготовка текстовых данных

Как показано на рисунке 4.64.64.6, текст обычно представляется как числовой вектор с помощью трёх шагов: нормализация текста, токенизация и преобразование токенов в идентификаторы [2].

Рассмотрим каждый шаг подробнее.

Нормализация текста

Нормализация текста, также известная как очистка текста, обеспечивает согласованность слов и предложений. Например, одно и то же слово может быть написано немного по-разному: «dog», «dogs» и «DOG!» означают одно и то же, но написаны по-разному. То же самое верно для предложений. Возьмём два предложения, например:

• «A person walking with his dog in Montréal !»
• «a person walks with his dog, in Montreal.»

Оба предложения означают одно и то же, но имеют разные знаки препинания и формы глаголов. Вот некоторые типичные методы нормализации текста:

• Приведение к нижнему регистру: перевод всех букв в нижний регистр, поскольку это не меняет смысла слов или предложений
• Удаление знаков препинания: удаление знаков препинания из текста. Распространённые знаки препинания — точка, запятая, вопросительный знак, восклицательный знак и т.д.
• Обрезка пробелов: удаление ведущих, конечных и множественных пробелов
• Нормализационная форма KD (NFKD) [3]: разложение составных графем в комбинацию простых
• Удаление диакритических знаков: удаление знаков ударения из слов. Например: Màlaga →\rightarrow→ Malaga, Noël →\rightarrow→ Noel
• Лемматизация и стемминг: определение канонического представителя для набора связанных словоформ. Например: walking, walks, walked →\rightarrow→ walk

Токенизация

Токенизация — это процесс разбиения текста на более мелкие единицы, называемые токенами. В общем случае существует три типа токенизации:

• Токенизация по словам: разбиение текста на отдельные слова на основе определённых разделителей. Например, фраза «I have an interview tomorrow» становится ["I", "have", "an", "interview", "tomorrow"]
• Токенизация по подсловам: разбиение текста на подслова (или n-граммы символов)
• Токенизация по символам: разбиение текста на набор символов Детали различных алгоритмов токенизации обычно не являются основным предметом внимания на собеседованиях по проектированию ML-систем. Если вас интересует узнать больше, обратитесь к [4].

Токены в идентификаторы

Получив токены, нам нужно преобразовать их в числовые значения (идентификаторы). Представление токенов числовыми значениями можно выполнить двумя способами:

• Таблица поиска
• Хэширование

Таблица поиска. В этом методе каждый уникальный токен сопоставляется с идентификатором. Затем создаётся таблица поиска для хранения этих отображений 1:11: 11:1. На рисунке 4.74.74.7 показано, как может выглядеть таблица сопоставления.

Хэширование. Хэширование, также называемое «хэшированием признаков» или «трюком хэширования», — это метод с эффективным использованием памяти, который использует хэш-функцию для получения идентификаторов без хранения таблицы поиска. На рисунке 4.84.84.8 показано, как хэш-функция используется для преобразования слов в идентификаторы.

Сравним таблицу поиска с методом хэширования.

Таблица 4.2: Таблица поиска против хэширования признаков

Подготовка видеоданных

На рисунке 4.9 показан типичный рабочий процесс предобработки исходного видео.

Разработка модели

Выбор модели

Как обсуждалось в разделе «Формулировка задачи как ML-задачи», текстовые запросы преобразуются в embeddings текстовым энкодером, а видео — видеоэнкодером. В этом разделе рассматриваются возможные архитектуры моделей для каждого энкодера.

Типичные входные и выходные данные текстового энкодера показаны на рисунке 4.10.

Текстовый энкодер преобразует текст в векторное представление [6]. Например, если два предложения имеют схожий смысл, их embeddings более похожи. Для построения текстового энкодера доступны две широкие категории: статистические методы и методы на основе ML. Рассмотрим каждый из них.

Статистические методы

Эти методы основаны на статистике для преобразования предложения в вектор признаков. Два популярных статистических метода:

• Мешок слов (Bag of Words, BoW)
• TF-IDF (Term Frequency Inverse Document Frequency)

BoW. Этот метод преобразует предложение в вектор фиксированной длины. Он моделирует вхождения слов в предложения, создавая матрицу с строками, представляющими предложения, и столбцами, представляющими индексы слов. Пример BoW показан на рисунке 4.11.

Рисунок 4.11: BoW-представления различных предложений

BoW — простой метод, который быстро вычисляет представления предложений, но имеет следующие ограничения:

• Не учитывает порядок слов в предложении. Например, «let's watch TV after work» и «let's work after watch TV» будут иметь одинаковое BoW-представление.
• Полученное представление не отражает семантический и контекстуальный смысл предложения. Например, два предложения с одинаковым смыслом, но разными словами, имеют совершенно разные представления.
• Вектор представления разреженный. Размер вектора представления равен общему количеству уникальных токенов. Это число обычно очень велико, поэтому каждое представление предложения в основном заполнено нулями.

TF-IDF. Это числовая статистика, призванная отразить, насколько важно слово для документа в коллекции или корпусе. TF-IDF создаёт ту же матрицу предложение-слово, что и BoW, но нормализует матрицу на основе частоты слов. Чтобы узнать больше о математике, лежащей в основе этого, обратитесь к [7].

Поскольку TF-IDF придаёт меньший вес частым словам, его представления обычно лучше, чем BoW. Однако он имеет следующие ограничения:

• Необходим шаг нормализации для пересчёта частот терминов при добавлении нового предложения.
• Не учитывает порядок слов в предложении.
• Полученное представление не отражает семантический смысл предложения.
• Представления разреженные.

В итоге, статистические методы обычно быстры. Однако они не улавливают контекстуальный смысл предложений, а представления разреженные. Методы на основе ML решают эти проблемы.

Методы на основе ML

В этих методах ML-модель преобразует предложения в значимые word embeddings так, что расстояние между двумя embeddings отражает семантическое сходство соответствующих слов. Например, если два слова, такие как «rich» и «wealth», семантически схожи, их embeddings близки в пространстве embeddings. На рисунке 4.124.124.12 показана простая визуализация word embeddings в 2D2 \mathrm{D}2D пространстве embeddings. Как видно, похожие слова сгруппированы вместе.

Существует три распространённых подхода на основе ML для преобразования текстов в embeddings:

• Слой embedding (слой поиска)
• Word2vec
• Архитектуры на основе Transformer

Слой embedding (слой поиска) В этом подходе слой embedding используется для сопоставления каждого идентификатора с вектором embedding. На рисунке 4.13 показан пример.

Использование слоя embedding — простое и эффективное решение для преобразования разреженных признаков, таких как идентификаторы, в embedding фиксированного размера. Мы увидим больше примеров его использования в последующих главах.

Word2vec Word2vec [8] — это семейство связанных моделей, используемых для создания word embeddings. Эти модели используют неглубокую архитектуру нейронных сетей и используют совместные вхождения слов в локальном контексте для обучения word embeddings. В частности, модель обучается предсказывать центральное слово по его окружающим словам во время обучения. После обучения модель способна преобразовывать слова в значимые embeddings.

Существует две основные модели, основанные на word2vec: Continuous Bag of Words (CBOW) [9] и Skip-gram [10]. На рисунке 4.144.144.14 показано, как работает CBOW на высоком уровне. Если вас интересует узнать об этих моделях подробнее, обратитесь к [8].

Хотя word2vec и слои embedding просты и эффективны, недавние архитектуры на основе Transformer показывают перспективные результаты.

Модели на основе Transformer Эти модели учитывают контекст слов в предложении при их преобразовании в embeddings. В отличие от моделей word2vec, они создают разные embeddings для одного и того же слова в зависимости от контекста.

На рисунке 4.15 показана модель на основе Transformer, которая принимает предложение — набор слов — в качестве входных данных и создаёт embedding для каждого слова.

Transformer очень эффективны для понимания контекста и создания значимых embeddings. Несколько моделей, таких как BERT [11], GPT3 [12] и BLOOM [13], продемонстрировали потенциал Transformer для выполнения широкого спектра задач NLP. В нашем случае мы выбираем архитектуру на основе Transformer, такую как BERT, в качестве текстового энкодера.

На некоторых собеседованиях интервьюер может попросить вас глубже погрузиться в детали модели на основе Transformer. Чтобы узнать больше, обратитесь к [14].

Видеоэнкодер

У нас есть два варианта архитектуры для кодирования видео: У нас есть два варианта архитектуры для кодирования видео:

• Модели на уровне видео
• Модели на уровне кадров

Модели на уровне видео обрабатывают всё видео для создания embedding, как показано на рисунке 4.16. Архитектура модели обычно основана на 3D-свёрточных сетях [15] или Transformer. Поскольку модель обрабатывает всё видео целиком, она требует значительных вычислительных ресурсов.

Модели на уровне кадров работают иначе. Можно извлечь embedding из видео с помощью модели уровня кадров, разбив процесс на три шага:

• Предобработать видео и выбрать кадры.
• Запустить модель на выбранных кадрах для создания embeddings кадров.
• Агрегировать (например, усреднить) embeddings кадров для получения embedding видео.

Поскольку эта модель работает на уровне кадров, она часто быстрее и менее ресурсоёмка в вычислительном плане. Однако модели уровня кадров обычно не способны понимать временны́е аспекты видео, такие как действия и движения. На практике модели уровня кадров предпочтительны во многих случаях, когда временно́е понимание видео не является критичным. Здесь мы используем модель уровня кадров, такую как ViT [16], по двум причинам:

• Улучшение скорости обучения и обслуживания
• Сокращение количества вычислений

Обучение модели

Для обучения текстового энкодера и видеоэнкодера мы используем подход контрастного обучения. Если вас интересует узнать больше об этом, смотрите раздел «Обучение модели» в Главе 2, Система визуального поиска.

Объяснение того, как вычисляются потери во время обучения модели, показано на рисунке 4.18.

Оценка

Автономные метрики

Вот некоторые автономные метрики, которые обычно используются в поисковых системах. Рассмотрим, какие из них наиболее релевантны.

Precision@k и mAP

В оценочном датасете данный текстовый запрос связан только с одним видео. Это означает, что числитель формулы precision@k равен не более 1. Это приводит к низким значениям precision@k. Например, для данного текстового запроса, даже если мы ранжируем связанное с ним видео на первом месте, precision@10 составляет всего 0,1. Из-за этого ограничения метрики precision, такие как precision@k и mAP, не очень полезны.

Recall@k. Эта метрика измеряет отношение количества релевантных видео в результатах поиска к общему количеству релевантных видео.

Как описано ранее, «общее количество релевантных видео» всегда равно 1. С учётом этого мы можем перевести формулу recall@k следующим образом:

recall@ k=1\mathrm{k}=1k=1, если релевантное видео находится среди топ kkk видео, иначе 0

Каковы преимущества и недостатки этой метрики?

Преимущества

• Она эффективно измеряет способность модели найти связанное видео для данного текстового запроса.

Недостатки

• Она зависит от kkk. Выбор правильного k\mathrm{k}k может быть сложным.
• Когда релевантное видео не входит в kkk видео в выходном списке, recall@k всегда равен 0. Например, рассмотрим случай, когда модель A ранжирует релевантное видео на 15-м месте, а модель B ранжирует то же видео на 50-м месте. Если мы используем recall@10 для оценки качества этих двух моделей, обе получат recall@10=0, хотя модель A лучше модели B.

Mean Reciprocal Rank (MRR). Эта метрика измеряет качество модели, усредняя ранг первого релевантного элемента в каждом результате поиска. Формула:

Эта метрика устраняет недостатки recall@k и может использоваться в качестве нашей автономной метрики.

Онлайн-метрики

В рамках онлайн-оценки компании отслеживают широкий спектр метрик. Рассмотрим некоторые из наиболее важных:

• CTR (Click-through rate)
• Процент просмотренных видео до конца
• Общее время просмотра результатов поиска

CTR. Эта метрика показывает, как часто пользователи нажимают на найденные видео. Основная проблема CTR в том, что он не отслеживает, являются ли нажатые видео релевантными для пользователя. Несмотря на этот недостаток, CTR по-прежнему является хорошей метрикой для отслеживания, поскольку показывает, сколько людей нажимало на результаты поиска.

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

Общее время просмотра результатов поиска. Эта метрика отслеживает общее время, которое пользователи потратили на просмотр видео, возвращённых в результатах поиска. Пользователи, как правило, тратят больше времени на просмотр, если результаты поиска релевантны. Эта метрика является хорошим показателем релевантности результатов поиска.

Обслуживание

Во время обслуживания система отображает ранжированный список видео, релевантных данному текстовому запросу. На рисунке 4.194.194.19 показан упрощённый дизайн ML-системы.

Рассмотрим каждый конвейер подробнее.

Конвейер прогнозирования

Этот конвейер состоит из:

• Визуальный поиск
• Текстовый поиск
• Слой слияния
• Сервис переранжирования

Визуальный поиск. Этот компонент кодирует текстовый запрос и использует сервис ближайших соседей для поиска наиболее схожих с текстовым embedding embeddings видео. Для ускорения поиска NN мы используем алгоритмы приближённого поиска ближайших соседей (ANN), как описано в Главе 2, Система визуального поиска.

Текстовый поиск. Используя Elasticsearch, этот компонент находит видео с названиями и тегами, которые пересекаются с текстовым запросом.

Слой слияния. Этот компонент принимает два разных списка релевантных видео с предыдущего шага и объединяет их в новый список видео.

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

Сервис переранжирования. Этот сервис изменяет ранжированный список видео, включая бизнес-логику и политики.

Конвейер индексации видео

Обученный видеоэнкодер используется для вычисления embeddings видео, которые затем индексируются. Эти индексированные embeddings видео используются сервисом ближайших соседей.

Конвейер индексации текста

Использует Elasticsearch для индексации названий, ручных тегов и автоматически сгенерированных тегов.

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

Дополнительные темы для обсуждения

Прежде чем завершить эту главу, важно отметить, что мы упростили дизайн системы поиска видео. На практике она гораздо сложнее. Некоторые улучшения могут включать:

• Использование многоэтапного дизайна (генерация кандидатов + ранжирование).
• Использование большего количества видеопризнаков, таких как длина видео, популярность видео и т.д.
• Вместо аннотированных данных использовать взаимодействия (например, нажатия, лайки и т.д.) для построения и разметки данных. Это позволяет непрерывно обучать модель.
• Использовать ML-модель для поиска названий и тегов, семантически схожих с текстовым запросом. Эта модель может быть объединена с Elasticsearch для улучшения качества поиска.

Если в конце собеседования осталось время, вот некоторые дополнительные темы для обсуждения:

• Важная тема в поисковых системах — понимание запросов, такое как исправление орфографии, определение категории запроса и распознавание именованных сущностей. Как создать компонент понимания запросов? [17].
• Как создать мультимодальную систему, обрабатывающую речь и аудио для улучшения результатов поиска [18].
• Как расширить эту работу для поддержки других языков [19].
• Почти дублирующиеся видео в итоговом результате могут негативно влиять на пользовательский опыт. Как обнаружить почти дублирующиеся видео, чтобы удалить их перед отображением результатов [20][20][20]?
• Текстовые запросы можно разделить на head, torso и tail запросы. Какие различные подходы обычно используются в каждом случае [21]?
• Как учитывать популярность и свежесть при формировании выходного списка [22]?
• Как работают реальные поисковые системы [23][24][25].

Ссылки

1. Elasticsearch. https://www.tutorialspoint.com/elasticsearch/elasticsearch_query_dsl.htm.
2. Preprocessing text data. https://huggingface.co/docs/transformers/v4.42.0/preprocessing.
3. NFKD normalization. https://unicode.org/reports/tr15/.
4. What is Tokenization summary. https://huggingface.co/docs/transformers/tokenizer_summary.
5. Hash collision. https://en.wikipedia.org/wiki/Hash_collision.
6. Deep learning for NLP. http://cs224d.stanford.edu/lecture_notes/notes1.pdf.
7. TF-IDF. https://en.wikipedia.org/wiki/Tf%E2%80%93idf.
8. Word2Vec models. https://www.tensorflow.org/tutorials/text/word2vec.
9. Continuous bag of words. https://www.kdnuggets.com/2018/04/implementing-deep-learning-methods-feature-engineering-text-data-cbow.html.
10. Skip-gram model. http://mccormickml.com/2016/04/19/word2vec-tutorial-the-skip-gram-model/.
11. BERT model. https://arxiv.org/pdf/1810.04805.pdf.
12. GPT3 model. https://arxiv.org/pdf/2005.14165.pdf.
13. BLOOM model. https://bigscience.huggingface.co/blog/bloom.
14. Transformer implementation from scratch. https://peterbloem.nl/blog/transformers.
15. 3D convolutions. https://www.kaggle.com/code/shivamb/3d-convolutions-understanding-use-case/notebook.
16. Vision Transformer. https://arxiv.org/pdf/2010.11929.pdf.
17. Query understanding for search engines. https://www.linkedin.com/pulse/ai-query-understanding-daniel-tunkelang/.
18. Multimodal video representation learning. https://arxiv.org/pdf/2012.04124.pdf.
19. Multilingual language models. https://arxiv.org/pdf/2107.00676.pdf.
20. Near-duplicate video detection. https://arxiv.org/pdf/2005.07356.pdf.
21. Generalizable search relevance. https://livebook.manning.com/book/ai-powered-search/chapter-10/v-10/20.
22. Freshness in search and recommendation systems. https://developers.google.com/machine-learning/recommendation/dnn/re-ranking.
23. Semantic product search by Amazon. https://arxiv.org/pdf/1907.00937.pdf.
24. Ranking relevance in Yahoo search. https://www.kdd.org/kdd2016/papers/files/adf0361-yinA.pdf.
25. Semantic product search in E-Commerce. https://arxiv.org/pdf/2008.08180.pdf.

Обнаружение вредоносного контента

Многие платформы социальных сетей, такие как Facebook [1], LinkedIn [2] и Twitter [3], имеют стандартные руководства для соблюдения целостности и обеспечения безопасности своих платформ для пользователей. Эти руководства запрещают определённые действия, активности и контент, вредоносные для сообщества. Крайне важно иметь технологии и ресурсы для выявления вредоносного контента и нарушителей. Мы можем разделить акцент обеспечения целостности на две категории:

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

В этой главе мы сосредоточимся на обнаружении публикаций, которые могут содержать вредоносный контент. В частности, мы проектируем систему, которая проактивно отслеживает новые публикации, обнаруживает вредоносный контент и удаляет или понижает его, если контент нарушает правила платформы. Чтобы понять, как компании строят систему обнаружения вредоносного контента на практике, обратитесь к [4] [5] [6].

Уточнение требований

Ниже приведён типичный диалог между кандидатом и интервьюером.

Кандидат: Система обнаруживает и вредоносный контент, и плохих акторов? Интервьюер: Оба одинаково важны. Для простоты давайте сосредоточимся только на обнаружении вредоносного контента.

Кандидат: Публикация может содержать только текст, или допускаются изображения и видео? Интервьюер: Содержимое публикации может быть текстом, изображением, видео или их любой комбинацией.

Кандидат: Какие языки поддерживаются? Только английский? Интервьюер: Система должна обнаруживать вредоносный контент на различных языках. Для простоты предположим, что мы можем использовать предобученную многоязычную модель для векторизации текстового содержимого.

Кандидат: Какие конкретные категории вредоносного контента мы хотим обнаруживать? Я могу думать о насилии, обнажённости, разжигании ненависти, дезинформации и т.д. Есть ли другие категории вреда для рассмотрения? Интервьюер: Отлично, вы упомянули основные. Дезинформация более сложна и спорна. Для простоты давайте не будем сосредотачиваться на дезинформации.

Кандидат: Есть ли разметчики для ручной разметки публикаций? Интервьюер: Платформа получает более 500 миллионов публикаций каждый день. Просить людей размечать все из них было бы очень дорого и трудоёмко. Однако вы можете предположить, что аннотация доступна для ограниченного числа публикаций, скажем, 10 000 в день.

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

Кандидат: Должны ли мы объяснять, почему публикация считается вредоносной и удаляется? Интервьюер: Да. Объяснение пользователям причины удаления публикации необходимо. Это помогает пользователям согласовывать будущие публикации с правилами.

Кандидат: Каково требование к задержке системы? Нам нужно прогнозирование в реальном времени, то есть система немедленно обнаруживает вредоносный контент и блокирует его, или мы можем использовать пакетное прогнозирование, то есть обнаружение вредоносного контента в автономном режиме ежечасно или ежедневно? Интервьюер: Это очень важный вопрос. Каковы ваши мысли?

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

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

Формулировка задачи как ML-задачи

Определение ML-цели

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

Определение входных и выходных данных системы

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

Углубимся в детали входной публикации. Как показано на рисунке 5.3, публикация может быть гетерогенной и потенциально мультимодальной.

Для точных прогнозов система должна учитывать все модальности. Рассмотрим два широко используемых метода слияния для объединения гетерогенных данных: позднее слияние и раннее слияние.

Позднее слияние

При позднем слиянии ML-модели обрабатывают различные модальности независимо, затем объединяют их прогнозы для формирования окончательного прогноза. На рисунке ниже показано, как работает позднее слияние.

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

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

Во-вторых, комбинация модальностей может быть вредоносной, даже если каждая из них по отдельности безвредна. Это часто встречается с мемами, объединяющими изображения и текст. В таких случаях позднее слияние не может предсказать, является ли контент вредоносным. Это происходит потому, что каждая модальность безвредна, поэтому модели предсказывают безвредность при обработке каждой модальности. Вывод слоя слияния — безвредный, поскольку вывод каждой отдельной модальности безвреден. Но это неверно, так как комбинация модальностей может быть вредоносной.

Раннее слияние

При раннем слиянии модальности сначала объединяются, а затем модель делает прогноз. На рисунке 5.5 показано, как работает раннее слияние.

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

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

Какой метод слияния следует использовать?

Используется метод раннего слияния, поскольку он позволяет нам обнаруживать публикации, которые могут быть в целом вредоносными, даже если каждая модальность сама по себе безвредна. Кроме того, при публикации около 500 миллионов публикаций каждый день у модели достаточно данных для обучения.

Выбор подходящей категории ML

В этом разделе рассматриваются следующие варианты категорий ML:

• Единственный бинарный классификатор
• Один бинарный классификатор на каждый класс вреда
• Многолейбловый классификатор
• Многозадачный классификатор

Единственный бинарный классификатор

В этом варианте модель принимает объединённые признаки в качестве входных данных и прогнозирует вероятность того, что публикация является вредоносной (рисунок 5.6). Поскольку вывод является бинарным результатом, модель представляет собой бинарный классификатор.

Недостаток этого варианта в том, что трудно определить, к какому классу вреда, например насилию, относится публикация. Это ограничение вызывает две основные проблемы:

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

Поскольку необходимо объяснять причины удаления публикации, единственный бинарный классификатор не является хорошим вариантом.

Один бинарный классификатор на каждый класс вреда

В этом варианте мы используем один бинарный классификатор для каждого класса вреда. Как показано на рисунке 5.75.75.7, каждая модель определяет, относится ли публикация к конкретному классу вреда или нет. Каждая модель принимает объединённые признаки в качестве входных данных и прогнозирует вероятность отнесения публикации к классу вреда.

Преимущество этого варианта в том, что мы можем объяснить пользователям, почему публикация была удалена. Кроме того, мы можем отслеживать различные модели и улучшать их независимо.

Однако этот вариант имеет один серьёзный недостаток. Поскольку у нас несколько моделей, их необходимо обучать и поддерживать отдельно. Раздельное обучение этих моделей трудоёмко и дорого.

Многолейбловый классификатор

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

Использование общей модели для всех классов вреда делает обучение и поддержку модели менее затратными. Если вы хотите узнать больше об этом методе, обратитесь к подходу WPIE [7].

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

Многозадачный классификатор

Многозадачное обучение — это процесс, при котором модель обучается нескольким задачам одновременно. Это позволяет модели изучать сходства между задачами. Тем самым мы избегаем ненужных вычислений, когда определённое преобразование входных данных полезно для нескольких задач.

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

Общие слои Общий слой, как показано на рисунке 5.10, — это набор скрытых слоёв, которые преобразуют входные признаки в новые. Эти новые преобразованные признаки используются для прогнозирования по каждому классу вреда.

Специфические для задачи слои Специфические для задачи слои — это набор независимых слоёв ML (также называемых головами классификации). Каждая голова классификации преобразует признаки таким образом, который оптимален для прогнозирования конкретной вероятности вреда.

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

Благодаря этим преимуществам мы применяем метод многозадачной классификации. На рисунке 5.125.125.12 показано, как мы формулируем задачу.

Подготовка данных

Разработка данных

Доступны следующие данные:

• Пользователи
• Публикации
• Взаимодействия пользователей с публикациями

Пользователи

Ниже показана схема данных пользователей.

Таблица 5.1: Схема данных пользователей

Публикации

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

Таблица 5.2: Данные публикаций

Взаимодействия пользователей с публикациями

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

Таблица 5.3: Данные о взаимодействиях пользователей с публикациями

Разработка признаков

В разделе «Формулировка задачи как ML-задачи» мы сформулировали задачу как многозадачную классификацию, где входными данными является публикация. В этом разделе мы исследуем прогностические признаки, которые можно извлечь из публикации. Публикация может включать следующие элементы:

• Текстовое содержимое
• Изображение или видео
• Реакции пользователей на публикацию
• Автор
• Контекстуальная информация

Рассмотрим каждый элемент.

Текстовое содержимое

Текстовое содержимое публикации может использоваться для определения, является ли публикация вредоносной или нет. Как описано в Главе 4 «Поиск видео на YouTube», текстовые данные обычно подготавливаются в два шага:

• Предобработка текста (например, нормализация, токенизация)
• Векторизация: преобразование предобработанного текста в значимый вектор признаков Сосредоточимся на векторизации, поскольку она специфична для этой главы. Для векторизации текста и извлечения вектора признаков можно использовать статистические или ML-методы. Статистические методы, такие как BoW или TF-IDF, просты в реализации и быстры в вычислении. Однако они не могут кодировать семантику текста. Для нашей системы понимание семантики текстового содержимого важно для определения вредоносности, поэтому мы применяем ML-метод. Для преобразования текста в вектор признаков мы используем предобученную языковую модель на основе Transformer, такую как BERT [8]. Однако оригинальный BERT имеет две проблемы:
• Создание text embedding занимает много времени из-за большого размера модели. Поскольку это медленный процесс, использование его для онлайн-прогнозирования не является идеальным.
• BERT был обучен только на английских данных. Таким образом, он не создаёт значимых embeddings для текстов на других языках.

DistilmBERT [9], более эффективный вариант BERT, решает эти две проблемы. Если два предложения имеют одинаковый смысл, но на двух разных языках, их embeddings очень схожи. Если вас интересует узнать больше о многоязычных языковых моделях, обратитесь к [10].

Изображение или видео

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

• Предобработка: декодирование, изменение размера и нормализация данных.
• Извлечение признаков: после предобработки мы используем предобученную модель для преобразования неструктурированных данных в вектор признаков. Это позволяет нам представить изображение или видео вектором признаков. Для изображений предобученные модели, такие как визуальный энкодер CLIP [11] или SimCLR [12], являются жизнеспособными вариантами. Для видео предобученные модели, такие как VideoMoCo [13], могут работать хорошо.

Реакции пользователей на публикацию

Также можно определить, является ли публикация вредоносной, на основе реакций пользователей, особенно когда содержимое неоднозначно. Как показано на рисунке 5.13, по мере накопления комментариев всё более очевидным становится, что публикация содержит контент, связанный с причинением вреда себе.

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

Количество лайков, репостов, комментариев и жалоб: обычно мы масштабируем эти числовые значения для ускорения сходимости во время обучения модели.

Комментарии: как показано на рисунке 5.13, комментарии могут помочь нам выявить вредоносный контент. Для подготовки признаков мы преобразуем комментарии в числовые представления следующим образом:

• Используем ту же предобученную модель, что применялась ранее, для получения embedding каждого комментария.
• Агрегируем (например, усредняем) embeddings для получения итогового embedding.

Сводка описанных нами признаков приведена на рисунке 5.14.

Признаки автора

Прошлые взаимодействия автора могут использоваться для определения того, является ли публикация вредоносной или нет. Создадим признаки, связанные с автором публикации.

История нарушений автора

• Количество нарушений: числовое значение, представляющее количество раз, когда автор нарушал правила в прошлом.
• Общее количество жалоб пользователей: числовое значение, представляющее количество раз, когда пользователи жаловались на публикации автора.
• Доля нецензурных слов: числовое значение, представляющее долю нецензурных слов, использованных в предыдущих публикациях и комментариях автора. Заранее определённый список нецензурных слов используется для определения, является ли слово нецензурным.

Демографические данные автора

• Возраст: возраст пользователя является одним из наиболее важных прогностических признаков.
• Пол: этот категориальный признак представляет пол пользователя. Для представления пола используется унитарное кодирование.
• Город и страна: как город, так и страна принимают множество различных значений. Для представления признаков мы используем слой embedding для преобразования города и страны в векторы признаков. Обратите внимание, что унитарное кодирование не является эффективным методом для представления города и страны, поскольку их представления будут длинными и разреженными.

Информация об аккаунте

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

Контекстуальная информация

• Время суток: это время суток, когда автор опубликовал запись. Мы разбиваем это на несколько категорий, таких как утро, полдень, день, вечер или ночь. Для представления этого признака используется унитарное кодирование.
• Устройство: устройство, используемое автором, например смартфон или настольный компьютер. Для представления этого признака используется унитарное кодирование.

На рисунке 5.15 приведены некоторые из наиболее важных признаков системы обнаружения вредоносного контента.

Разработка модели

Выбор модели

Нейронная сеть — наиболее распространённая модель, используемая для многозадачного обучения. При разработке нашей модели мы применяем нейронные сети.

Какие факторы следует учитывать при выборе нейронной сети? Необходимо определить архитектурный дизайн нейронной сети и оптимальный выбор гиперпараметров, таких как скрытые слои, функция активации, скорость обучения и т.д. Оптимальный выбор гиперпараметров обычно определяется настройкой гиперпараметров. Кратко рассмотрим её.

Настройка гиперпараметров — это процесс нахождения наилучших значений гиперпараметров для достижения наилучшей производительности модели. Для настройки гиперпараметров обычно используется поиск по сетке. Процедура включает обучение новой модели для каждой комбинации значений гиперпараметров, оценку каждой модели, а затем выбор гиперпараметров, приводящих к наилучшей модели. Если вас интересует узнать больше о настройке гиперпараметров, обратитесь к [14].

Обучение модели

Построение датасета

Для обучения многозадачной модели классификации нам сначала нужно построить датасет. Датасет включает входные данные модели (признаки) и выходные данные (метки), которые модель должна предсказывать. Для построения входных данных мы обрабатываем публикации в автономном режиме пакетами и вычисляем объединённые признаки, как описано ранее. Эти признаки могут быть сохранены в хранилище признаков для будущего обучения. Для создания меток для каждого входного элемента у нас есть два варианта:

• Ручная разметка
• Естественная разметка

При ручной разметке сотрудники-подрядчики размечают публикации вручную. Этот вариант производит точные метки, но он дорог и трудоёмок. При естественной разметке мы используем жалобы пользователей для автоматической разметки публикаций. Хотя этот вариант создаёт более зашумлённые метки, они создаются быстрее. Для оценочного датасета мы используем ручную разметку для обеспечения точности меток, а для обучающего датасета — естественную разметку для повышения скорости разметки. Точка данных из построенного датасета показана на рисунке 5.16.

Выбор функции потерь

Обучение многозадачной нейронной сети очень похоже на то, как мы обычно обучаем модели нейронных сетей. Прямое распространение выполняет вычисления для формирования прогноза, функция потерь измеряет правильность прогноза, а обратное распространение оптимизирует параметры модели для уменьшения потерь на следующей итерации. Рассмотрим функцию потерь. При многозадачном обучении каждой задаче назначается функция потерь на основе её категории ML. В нашем случае каждая задача формулируется как бинарная классификация, поэтому мы применяем стандартную функцию потерь бинарной классификации, такую как кросс-энтропия, для каждой задачи. Общие потери вычисляются путём объединения специфических для задачи потерь, как показано на рисунке 5.175.175.17.

Распространённой проблемой при обучении мультимодальных систем является переобучение [15]. Например, когда скорость обучения варьируется между различными модальностями, одна модальность (например, изображение) может доминировать в процессе обучения. Два метода для решения этой проблемы — смешивание градиентов и focal loss. Если вас интересует узнать больше об этих методах, обратитесь к [16] [17].

Оценка

Автономные метрики

Для оценки производительности модели бинарной классификации широко используются автономные метрики, такие как precision, recall и F1. Однако precision или recall в отдельности недостаточны для понимания общей производительности. Например, модель с высокой precision может иметь очень низкий recall. Кривая precision-recall (PR) и кривая рабочей характеристики приёмника (ROC) устраняют эти ограничения. Рассмотрим каждую из них.

PR-кривая. PR-кривая показывает компромисс между precision и recall модели. Как показано на рисунке 5.185.185.18, мы получаем PR-кривую, строя precision модели при различных порогах вероятности от 0 до 1. Для обобщения компромиссов между precision и recall PR-AUC (площадь под кривой precision-recall) вычисляет площадь под PR-кривой. В общем случае высокое значение PR-AUC указывает на более точную модель.

ROC-кривая. ROC-кривая показывает компромиссы между долей истинно положительных результатов (recall) и долей ложно положительных результатов. Подобно PR-кривой, ROC-AUC обобщает производительность модели путём вычисления площади под ROC-кривой.

ROC и PR-кривые — два разных способа обобщить производительность модели классификации. Чтобы узнать о различиях между PR-кривой и ROC-кривой, прочитайте [18].

В нашем случае мы используем оба — ROC-AUC и PR-AUC — в качестве автономных метрик.

Онлайн-метрики

Рассмотрим несколько важных метрик для оценки безопасности платформы.

Распространённость (Prevalence). Эта метрика измеряет долю вредоносных публикаций, которые мы не предотвратили, среди всех публикаций на платформе.

Недостаток этой метрики в том, что она одинаково обрабатывает все вредоносные публикации. Например, одна вредоносная публикация со 100 тысячами просмотров или показов более вредоносна, чем две публикации с 10 просмотрами каждая.

Вредоносные показы (Harmful impressions). Мы предпочитаем эту метрику показателю распространённости. Причина в том, что количество вредоносных публикаций на платформе не показывает, сколько людей подвергалось воздействию этих публикаций, тогда как количество вредоносных показов фиксирует эту информацию.

Успешные апелляции (Valid appeals). Процент публикаций, признанных вредоносными, но обжалованных и восстановленных.

Проактивная доля (Proactive rate). Процент вредоносных публикаций, найденных и удалённых системой до того, как пользователи сообщили о них.

Жалобы пользователей по классу вреда (User reports per harmful class). Эта метрика измеряет производительность системы, анализируя жалобы пользователей для каждого класса вреда.

Обслуживание

На рисунке 5.19 показан высокоуровневый дизайн ML-системы. Рассмотрим каждый компонент подробнее.

Сервис обнаружения вредоносного контента

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

Сервис применения нарушений

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

Сервис понижения

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

Затем публикация сохраняется в хранилище для ручной проверки людьми. Команда проверки вручную просматривает публикацию и присваивает ей метку из одного из предопределённых классов вреда. Мы будем использовать эти размеченные публикации в будущих итерациях обучения для улучшения модели.

Дополнительные темы для обсуждения

• Работа с предвзятостями, вносимыми ручной разметкой [19].
• Адаптация системы для обнаружения трендовых вредоносных классов (например, Covid-19, выборы) [20].
• Как создать систему обнаружения вредоносного контента, использующую временну́ю информацию, такую как последовательность действий пользователей [21][22].
• Как эффективно отбирать образцы публикаций для ручной проверки [23].
• Как обнаруживать подлинные и фейковые аккаунты [24].
• Как работать с пограничным контентом [25], то есть типами контента, которые не запрещены правилами, но близки к красным линиям, обозначенным этими политиками.
• Как сделать систему обнаружения вредоносного контента эффективной для развёртывания на устройстве [26].
• Как заменить архитектуры на основе Transformer линейными Transformer для создания более эффективной системы [27] [28].

Ссылки

1. Facebook's inauthentic behavior. https://transparency.fb.com/policies/community-standards/inauthentic-behavior/.
2. LinkedIn's professional community policies. https://www.linkedin.com/legal/professional-community-policies.
3. Twitter's civic integrity policy. https://help.twitter.com/en/rules-and-policies/election-integrity-policy.
4. Facebook's integrity survey. https://arxiv.org/pdf/2009.10311.pdf.
5. Pinterest's violation detection system. https://medium.com/pinterest-engineering/how-pinterest-fights-misinformation-hate-speech-and-self-harm-content-with-machine-learning-1806b73b40ef.
6. Abusive detection at LinkedIn. https://engineering.linkedin.com/blog/2019/isolation-forest.
7. WPIE method. https://ai.facebook.com/blog/community-standards-report/.
8. BERT paper. https://arxiv.org/pdf/1810.04805.pdf.
9. Multilingual DistilBERT. https://huggingface.co/distilbert-base-multilingual-cased.
10. Multilingual language models. https://arxiv.org/pdf/2107.00676.pdf.
11. CLIP model. https://openai.com/blog/clip/.
12. SimCLR paper. https://arxiv.org/pdf/2002.05709.pdf.
13. VideoMoCo paper. https://arxiv.org/pdf/2103.05905.pdf.
14. Hyperparameter tuning. https://cloud.google.com/ai-platform/training/docs/hyperparameter-tuning-overview.
15. Overfitting. https://en.wikipedia.org/wiki/Overfitting.
16. Focal loss. https://amaarora.github.io/posts/2020-06-29-FocalLoss.html.
17. Gradient blending in multimodal systems. https://arxiv.org/pdf/1905.12681.pdf.
18. ROC curve vs precision-recall curve. https://machinelearningmastery.com/roc-curves-and-precision-recall-curves-for-classification-in-python/.
19. Introduced bias by human labeling. https://labelyourdata.com/articles/bias-in-machine-learning.
20. Facebook's approach to quickly tackling trending harmful content. https://ai.facebook.com/blog/harmful-content-can-evolve-quickly-our-new-ai-system-adapts-to-tackle-it/.
21. Facebook's TIES approach. https://arxiv.org/pdf/2002.07917.pdf.
22. Temporal interaction embedding. https://www.facebook.com/atscaleevents/videos/730968530723238/.
23. Building and scaling human review system. https://www.facebook.com/atscaleevents/videos/1201751883328695/.
24. Abusive account detection framework. https://www.youtube.com/watch?v=YeX4MdU0JNk.
25. Borderline contents. https://transparency.fb.com/features/approach-to-ranking/content-distribution-guidelines/content-borderline-to-the-community-standards/.
26. Efficient harmful content detection. https://about.fb.com/news/2021/12/metas-new-ai-system-tackles-harmful-content/.
27. Linear Transformer paper. https://arxiv.org/pdf/2006.04768.pdf.
28. Efficient AI models to detect hate speech. https://ai.facebook.com/blog/how-facebook-uses-super-efficient-ai-models-to-detect-hate-speech/.

Система рекомендаций видео

Рекомендательные системы играют ключевую роль в сервисах потокового видео и музыки. Например, YouTube рекомендует видео, которые могут понравиться пользователю, Netflix рекомендует фильмы, которые пользователь может захотеть посмотреть, а Spotify рекомендует музыку пользователям.

В этой главе мы проектируем систему рекомендаций видео, аналогичную YouTube [1]. Система рекомендует видео на домашней странице пользователя на основе его профиля, прошлых взаимодействий и т.д.

Рекомендательные системы часто очень сложны в проектировании, и требуется значительные инженерные усилия для разработки эффективной и масштабируемой системы. Не беспокойтесь, никто не ожидает, что вы создадите идеальную систему за 45-минутное собеседование. Интервьюера в первую очередь интересует наблюдение за вашим мыслительным процессом, коммуникационными навыками, способностью проектировать ML-системы и обсуждать компромиссы.

Уточнение требований

Ниже приведён типичный диалог между кандидатом и интервьюером.

Кандидат: Могу ли я предположить, что бизнес-цель создания системы рекомендаций видео — увеличение вовлечённости пользователей? Интервьюер: Верно.

Кандидат: Система рекомендует похожие видео на видео, которое пользователь смотрит прямо сейчас? Или показывает персонализированный список видео на домашней странице пользователя? Интервьюер: Это система рекомендаций видео для домашней страницы, которая рекомендует персонализированные видео пользователям при загрузке домашней страницы.

Кандидат: Поскольку YouTube является глобальным сервисом, могу ли я предположить, что пользователи находятся по всему миру и видео на разных языках? Интервьюер: Это справедливое предположение.

Кандидат: Могу ли я предположить, что мы можем создать датасет на основе взаимодействий пользователей с видеоконтентом? Интервьюер: Да, звучит хорошо.

Кандидат: Может ли пользователь группировать видео, создавая плейлисты? Плейлисты могут быть информативными для ML-модели в процессе обучения. Интервьюер: Для простоты давайте предположим, что функция плейлиста отсутствует.

Кандидат: Сколько видео доступно на платформе? Интервьюер: У нас около 10 миллиардов видео.

Кандидат: Как быстро система должна рекомендовать видео пользователю? Могу ли я предположить, что рекомендация не должна занимать более 200 миллисекунд? Интервьюер: Звучит хорошо.

Подведём итог постановки задачи. Нас просят спроектировать систему рекомендаций видео для домашней страницы. Бизнес-цель — увеличение вовлечённости пользователей. Каждый раз, когда пользователь загружает домашнюю страницу, система рекомендует наиболее увлекательные видео. Пользователи находятся по всему миру, а видео могут быть на разных языках. На платформе около 10 миллиардов видео, и рекомендации должны отображаться быстро.

Формулировка задачи как ML-задачи

Определение ML-цели

Бизнес-цель системы — увеличение вовлечённости пользователей. Для перевода бизнес-целей в чётко определённые ML-цели доступно несколько вариантов. Рассмотрим некоторые из них и обсудим их компромиссы.

Максимизация количества кликов пользователей. Система рекомендаций видео может быть спроектирована для максимизации кликов пользователей. Однако у этой цели есть один серьёзный недостаток. Модель может рекомендовать так называемые «кликбейт»-видео, то есть название и эскиз выглядят привлекательно, но содержимое видео может быть скучным, нерелевантным или даже вводящим в заблуждение. Кликбейт-видео снижают удовлетворённость и вовлечённость пользователей со временем.

Максимизация количества просмотренных видео до конца. Система также может рекомендовать видео, которые пользователи с высокой вероятностью досмотрят до конца. Серьёзная проблема этой цели в том, что модель может рекомендовать более короткие видео, которые быстрее смотреть.

Максимизация общего времени просмотра. Эта цель создаёт рекомендации, на просмотр которых пользователи тратят больше времени.

Максимизация количества релевантных видео. Эта цель создаёт рекомендации, релевантные пользователям. Инженеры или менеджеры по продукту могут определять релевантность на основе правил. Такие правила могут основываться на неявных и явных реакциях пользователей. Например, одно определение может гласить, что видео релевантно, если пользователь явно нажал кнопку «лайк» или посмотрел хотя бы половину. Как только мы определяем релевантность, мы можем построить датасет и обучить модель для предсказания оценки релевантности между пользователем и видео.

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

Определение входных и выходных данных системы

Как показано на рисунке 6.2, система рекомендаций видео принимает пользователя в качестве входных данных и выводит ранжированный список видео, отсортированных по оценкам релевантности.

Выбор подходящей категории ML

В этом разделе рассматриваются три распространённых типа персонализированных рекомендательных систем.

• Контентная фильтрация
• Коллаборативная фильтрация
• Гибридная фильтрация

Рассмотрим каждый тип подробнее.

Контентная фильтрация

Этот метод использует признаки видео для рекомендации новых видео, похожих на те, которые пользователь счёл релевантными в прошлом. Например, если пользователь ранее взаимодействовал со многими видео о лыжах, этот метод предложит больше лыжных видео. На рисунке 6.46.46.4 показан пример.

Вот объяснение диаграммы.

1. Пользователь A взаимодействовал с видео X\mathrm{X}X и Y\mathrm{Y}Y в прошлом
2. Видео Z\mathrm{Z}Z похоже на видео X\mathrm{X}X и видео Y\mathrm{Y}Y
3. Система рекомендует видео Z\mathrm{Z}Z пользователю A\mathrm{A}A

Контентная фильтрация имеет преимущества и недостатки.

Преимущества:

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

Недостатки:

• Трудно обнаружить новые интересы пользователя.
• Метод требует знания предметной области. Нам часто нужно вручную создавать видеопризнаки.

Коллаборативная фильтрация (CF)

CF использует сходство пользователь-пользователь (CF на основе пользователей) или видео-видео (CF на основе элементов) для рекомендации новых видео. CF работает на основе интуитивной идеи, что похожие пользователи интересуются похожими видео. Пример CF на основе пользователей можно увидеть на рисунке 6.5.

Объясним диаграмму. Цель — рекомендовать новое видео пользователю A.

1. Найти похожего пользователя на A\mathrm{A}A на основе их прошлых взаимодействий; скажем, пользователя B\mathrm{B}B
2. Найти видео, с которым взаимодействовал пользователь B, но которое пользователь A ещё не видел; скажем, видео Z\mathrm{Z}Z
3. Рекомендовать видео Z\mathrm{Z}Z пользователю A\mathrm{A}A

Главное различие между контентной фильтрацией и CF заключается в том, что CF не использует признаки видео и полностью полагается на исторические взаимодействия пользователей для формирования рекомендаций. Рассмотрим преимущества и недостатки CF.

Преимущества:

• Не требует знания предметной области. CF не зависит от признаков видео, что означает отсутствие необходимости в знании предметной области для создания признаков из видео.
• Легко обнаруживает новые области интересов пользователей. Система может рекомендовать видео на новые темы, которые другие похожие пользователи смотрели в прошлом.
• Эффективность. Модели на основе CF обычно быстрее и менее ресурсоёмки, чем контентная фильтрация, поскольку не зависят от признаков видео.

Недостатки:

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

Таблица 6.1: Сравнение контентной фильтрации и CF

Сравнение двух типов фильтрации показано в таблице 6.1. Как видно, два метода дополняют друг друга.

Гибридная фильтрация

Гибридная фильтрация использует как CF, так и контентную фильтрацию. Как показано на рисунке 6.6, гибридная фильтрация объединяет CF-основанные и контентно-основанные рекомендательные системы последовательно или параллельно. На практике компании обычно используют последовательную гибридную фильтрацию [2].

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

Какой метод следует выбрать?

Многие компании используют гибридную фильтрацию для улучшения рекомендаций. Например, статья Google [2] описывает, как YouTube использует CF-модель на первом этапе (генератор кандидатов), а затем контентно-основанную модель на втором этапе для рекомендации видео. Благодаря преимуществам гибридной фильтрации мы выбираем этот вариант.

Подготовка данных

Разработка данных

Доступны следующие данные:

• Видео
• Пользователи
• Взаимодействия пользователей с видео

Видео

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

Таблица 6.2: Метаданные видео

Пользователи

Следующая простая схема представляет данные пользователей.

Таблица 6.3: Схема данных пользователей

Взаимодействия пользователей с видео

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

Таблица 6.4: Данные о взаимодействиях пользователей с видео

Разработка признаков

ML-система должна предсказывать видео, релевантные пользователям. Создадим признаки, помогающие системе делать обоснованные прогнозы.

Видеопризнаки

К важным видеопризнакам относятся:

• Идентификатор видео
• Длительность
• Язык
• Названия и теги

Идентификатор видео

Идентификаторы являются категориальными данными. Для их представления числовыми векторами мы используем слой embedding, который обучается в процессе обучения модели.

Длительность

Это примерная длительность видео от начала до конца. Эта информация важна, поскольку некоторые пользователи могут предпочитать более короткие видео, тогда как другие предпочитают более длинные.

Язык

Язык видео является важным признаком. Это связано с тем, что пользователи естественным образом предпочитают определённые языки. Поскольку язык является категориальной переменной и принимает конечный набор дискретных значений, для его представления мы используем слой embedding.

Названия и теги

Названия и теги используются для описания видео. Они либо предоставляются вручную загрузчиком, либо неявно предсказываются отдельными ML-моделями. Названия и теги видео являются ценными предикторами. Например, видео с названием «как приготовить пиццу» указывает, что видео связано с пиццей и приготовлением пищи.

Как подготовить? Для тегов мы используем лёгкую предобученную модель, такую как CBOW [3], для преобразования их в векторы признаков.

Для названия мы преобразуем его в вектор признаков с помощью контекстно-зависимой модели word embedding, такой как предобученный BERT [4].

На рисунке 6.7 показан обзор подготовки видеопризнаков.

Признаки пользователей

Мы классифицируем признаки пользователей по следующим категориям:

• Демографические данные пользователя
• Контекстуальная информация
• Исторические взаимодействия пользователей

Демографические данные пользователя

Обзор демографических признаков пользователей показан на рисунке 6.8.

Контекстуальная информация

Вот несколько важных признаков для сбора контекстуальной информации:

• Время суток. Пользователь может смотреть разные видео в разное время суток. Например, разработчик программного обеспечения может смотреть больше образовательных видео вечером.
• Устройство. На мобильных устройствах пользователи могут предпочитать более короткие видео.
• День недели. В зависимости от дня недели у пользователей могут быть разные предпочтения в отношении видео.

Исторические взаимодействия пользователей

Исторические взаимодействия пользователей играют важную роль в понимании их интересов. Несколько признаков, связанных с историческими взаимодействиями:

• История поисков
• Понравившиеся видео
• Просмотренные видео и показы

История поисков Почему это важно?

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

Как подготовить?

Используем предобученную модель word embedding, такую как BERT, для преобразования каждого поискового запроса в вектор embedding. Обратите внимание, что история поиска пользователя — это список текстовых запросов переменного размера. Для создания вектора признаков фиксированного размера, суммирующего все поисковые запросы, мы усредняем embeddings запросов.

Понравившиеся видео Почему это важно?

Видео, которые пользователь ранее лайкал, могут быть полезны для определения типа контента, который его интересует.

Как подготовить?

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

Просмотренные видео и показы Процесс разработки признаков для «просмотренных видео» и «показов» очень похож на то, что мы делали для понравившихся видео. Поэтому повторять не будем.

На рисунке 6.10 обобщены признаки, связанные с взаимодействиями пользователей с видео.

Разработка модели

В этом разделе рассматриваются две модели на основе embeddings, которые обычно используются в рекомендательных системах на основе CF или контентной фильтрации:

• Матричная факторизация
• Двухбашенная нейронная сеть

Матричная факторизация

Для понимания модели матричной факторизации важно знать, что такое матрица обратной связи.

Матрица обратной связи

Также называемая матрицей полезности, это матрица, представляющая мнения пользователей о видео. На рисунке 6.11 показана бинарная матрица обратной связи пользователей с видео, где каждая строка представляет пользователя, а каждый столбец — видео. Записи в матрице указывают мнение пользователя: 1 означает «наблюдаемое» или «положительное».

Как мы можем определить, считает ли пользователь рекомендованное видео релевантным? У нас есть три варианта:

• Явная обратная связь
• Неявная обратная связь
• Комбинация явной и неявной обратной связи

Явная обратная связь. Матрица обратной связи строится на основе взаимодействий, явно указывающих на мнение пользователя о видео, таких как лайки и репосты. Явная обратная связь точно отражает мнение пользователя, поскольку пользователи явно выразили свой интерес к видео. Однако этот вариант имеет один серьёзный недостаток: матрица разрежена, поскольку лишь небольшая часть пользователей предоставляет явную обратную связь. Разреженность затрудняет обучение ML-моделей.

Неявная обратная связь. Этот вариант использует взаимодействия, неявно указывающие на мнение пользователя о видео, такие как «клики» или «время просмотра». С неявной обратной связью доступно больше точек данных, что приводит к лучшей модели после обучения. Её основной недостаток — она напрямую не отражает мнение пользователей и может быть зашумлённой.

Комбинация явной и неявной обратной связи. Этот вариант объединяет явную и неявную обратную связь с помощью эвристик.

Какой вариант лучший для построения нашей матрицы обратной связи?

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

В нашем случае ML-цель — максимизация релевантности, где релевантность определяется как комбинация явной и неявной обратной связи. Таким образом, последний вариант комбинирования явной и неявной обратной связи является наилучшим выбором.

Модель матричной факторизации

Матричная факторизация — это простая модель на основе embeddings. Алгоритм разлагает матрицу обратной связи пользователей с видео на произведение двух матриц меньшей размерности. Одна матрица меньшей размерности представляет embeddings пользователей, а другая — embeddings видео. Другими словами, модель обучается отображать каждого пользователя в вектор embedding, а каждое видео — в вектор embedding таким образом, что расстояние между ними представляет их релевантность. На рисунке 6.126.126.12 показано, как матрица обратной связи разлагается на embeddings пользователей и видео.

Обучение матричной факторизации

В процессе обучения мы стремимся создать матрицы embeddings пользователей и видео таким образом, чтобы их произведение было хорошим приближением матрицы обратной связи (рисунок 6.13).

Для обучения этих embeddings матричная факторизация сначала случайно инициализирует две матрицы embeddings, затем итеративно оптимизирует embeddings для уменьшения потерь между «матрицей предсказанных оценок» и «матрицей обратной связи». Выбор функции потерь является важным соображением. Рассмотрим несколько вариантов:

• Квадратичное расстояние по наблюдаемым парам ⟨\langle⟨ пользователь, видео ⟩\rangle⟩
• Взвешенная комбинация квадратичного расстояния по наблюдаемым и ненаблюдаемым парам

Квадратичное расстояние по наблюдаемым парам ⟨\langle⟨ пользователь, видео ⟩\rangle⟩ Эта функция потерь измеряет сумму квадратичных расстояний по всем парам наблюдаемых (ненулевых) записей в матрице обратной связи. Это показано на рисунке 6.14.

AijA_{i j}Aij​ относится к записи со строкой iii и столбцом jjj в матрице обратной связи, UiU_iUi​ — embedding пользователя i,Vji, V_ji,Vj​ — embedding видео jjj, а суммирование выполняется только по наблюдаемым парам.

Суммирование только по наблюдаемым парам приводит к плохим embeddings, поскольку функция потерь не штрафует модель за плохие предсказания по ненаблюдаемым парам. Например, матрицы embeddings, заполненные единицами, имели бы нулевые потери на обучающих данных. Однако такие embeddings могут плохо работать для невидимых пар ⟨\langle⟨ пользователь, видео ⟩\rangle⟩.

Квадратичное расстояние по обоим — наблюдаемым и ненаблюдаемым парам ⟨\langle⟨ пользователь, видео ⟩\rangle⟩ Эта функция потерь рассматривает ненаблюдаемые пары как отрицательные точки данных и присваивает им ноль в матрице обратной связи. Как показано на рисунке 6.15, потери вычисляют сумму квадратичных расстояний по всем записям матрицы обратной связи.

Эта функция потерь решает предыдущую проблему, штрафуя за плохие предсказания для ненаблюдаемых записей. Однако она имеет серьёзный недостаток. Матрица обратной связи обычно разрежена (много ненаблюдаемых пар), поэтому ненаблюдаемые пары доминируют над наблюдаемыми во время обучения. Это приводит к предсказаниям, которые в основном близки к нулю. Это нежелательно и ведёт к плохой производительности обобщения на невидимых парах ⟨\langle⟨ пользователь, видео ⟩\rangle⟩.

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

Первое суммирование в формуле потерь вычисляет потери по наблюдаемым парам, а второе суммирование вычисляет потери по ненаблюдаемым парам. WWW — гиперпараметр, взвешивающий два суммирования. Он обеспечивает, чтобы одно не доминировало над другим в фазе обучения. Эта функция потерь с правильно настроенным WWW хорошо работает на практике [5]. Мы выбираем эту функцию потерь для системы.

Оптимизация матричной факторизации

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

• Стохастический градиентный спуск (SGD): этот алгоритм оптимизации используется для минимизации потерь [6].
• Взвешенные чередующиеся наименьшие квадраты (WALS): этот алгоритм оптимизации специфичен для матричной факторизации. Процесс в WALS следующий: Зафиксировать одну матрицу embedding (U) и оптимизировать другую (V) Зафиксировать другую матрицу embedding (V) и оптимизировать матрицу embedding (U) Повторить. WALS обычно сходится быстрее и допускает параллелизацию. Чтобы узнать больше о WALS, читайте [7]. Здесь мы используем WALS, поскольку он сходится быстрее.

Вывод матричной факторизации

Для предсказания релевантности между произвольным пользователем и кандидатным видео мы вычисляем сходство между их embeddings с помощью меры сходства, такой как скалярное произведение. Например, как показано на рисунке 6.17, оценка релевантности между пользователем 2 и видео 5 равна 0,320.320.32.

На рисунке 6.18 показаны предсказанные оценки для всех пар ⟨\langle⟨ пользователь, видео ⟩\rangle⟩. Система возвращает рекомендованные видео на основе оценок релевантности.

Прежде чем завершить тему матричной факторизации, обсудим её преимущества и недостатки.

Преимущества:

• Скорость обучения: матричная факторизация эффективна на этапе обучения. Это объясняется тем, что нужно обучить только две матрицы embeddings.
• Скорость обслуживания: матричная факторизация быстра во время обслуживания. Обученные embeddings статичны, то есть после обучения мы можем повторно использовать их без преобразования входных данных во время запроса.

Недостатки:

• Матричная факторизация полагается только на взаимодействия пользователей с видео. Она не использует другие признаки, такие как возраст пользователя или язык. Это ограничивает прогностические возможности модели, поскольку такие признаки, как язык, полезны для улучшения качества рекомендаций.
• Обработка новых пользователей затруднена. Для новых пользователей недостаточно взаимодействий, чтобы модель могла создать значимые embeddings. Следовательно, матричная факторизация не может определить, релевантно ли видео пользователю, вычисляя скалярное произведение их embeddings.

Посмотрим, как двухбашенные нейронные сети решают недостатки матричной факторизации.

Двухбашенная нейронная сеть

Двухбашенная нейронная сеть состоит из двух башен-энкодеров: башни пользователя и башни видео. Энкодер пользователя принимает признаки пользователя в качестве входных данных и отображает их в вектор embedding (embedding пользователя). Видеоэнкодер принимает признаки видео в качестве входных данных и отображает их в вектор embedding (embedding видео). Расстояние между их embeddings в общем пространстве embeddings представляет их релевантность.

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

Построение датасета

Мы строим датасет, извлекая признаки из различных пар ⟨\langle⟨ пользователь, видео ⟩\rangle⟩ и размечая их как положительные или отрицательные на основе обратной связи пользователя. Например, мы помечаем пару как «положительную», если пользователь явно лайкнул видео или посмотрел не менее половины.

Для построения отрицательных точек данных мы можем выбрать случайные видео, которые не релевантны, или выбрать те, которые пользователь явно не одобрил, нажав кнопку «дизлайк». На рисунке 6.20 показан пример построенных точек данных.

Обратите внимание, что пользователи обычно находят лишь небольшую часть видео релевантной. При построении обучающих данных это ведёт к несбалансированному датасету, где отрицательных пар значительно больше, чем положительных. Обучение модели на несбалансированном датасете проблематично. Для решения проблемы дисбаланса данных можно использовать методы, описанные в Главе 1 «Введение и обзор».

Выбор функции потерь

Поскольку двухбашенная нейронная сеть обучается предсказывать бинарные метки, задачу можно классифицировать как задачу классификации. Мы используем типичную функцию потерь классификации, такую как кросс-энтропия, для оптимизации энкодеров во время обучения. Этот процесс показан на рисунке 6.21.

Вывод двухбашенной нейронной сети

Во время вывода система использует embeddings для поиска наиболее релевантных видео для данного пользователя. Это классическая задача «ближайших соседей». Мы используем методы приближённого поиска ближайших соседей для эффективного поиска топ k\mathrm{k}k наиболее схожих embeddings видео.

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

Рассмотрим преимущества и недостатки двухбашенной нейронной сети.

Преимущества:

• Использует признаки пользователей. Модель принимает признаки пользователей, такие как возраст и пол, в качестве входных данных. Эти прогностические признаки помогают модели делать лучшие рекомендации.
• Обрабатывает новых пользователей. Модель легко обрабатывает новых пользователей, поскольку полагается на признаки пользователей (например, возраст, пол и т.д.).

Недостатки:

• Более медленное обслуживание. Модели необходимо вычислять embedding пользователя во время запроса. Это делает модель медленнее в обслуживании запросов. Кроме того, если мы используем модель для контентной фильтрации, ей необходимо преобразовывать признаки видео в embedding видео, что увеличивает время вывода.
• Обучение более затратно. Двухбашенные нейронные сети имеют больше обучаемых параметров, чем матричная факторизация. Следовательно, обучение более ресурсоёмко.

Матричная факторизация против двухбашенной нейронной сети

В таблице 6.5 представлено сравнение матричной факторизации и двухбашенной нейронной сети.

Таблица 6.5: Матричная факторизация против двухбашенных нейронных сетей

Оценка

Производительность системы можно оценить с помощью автономных и онлайн-метрик.

Автономные метрики

Рассмотрим следующие автономные метрики, обычно используемые в рекомендательных системах.

Precision@k. Эта метрика измеряет долю релевантных видео среди топ k\mathrm{k}k рекомендованных видео. Можно использовать несколько значений k\mathrm{k}k (например, 1,5,101,5,101,5,10).

mAP. Эта метрика измеряет качество ранжирования рекомендованных видео. Она хорошо подходит, поскольку оценки релевантности в нашей системе бинарные.

Разнообразие (Diversity). Эта метрика измеряет, насколько непохожи рекомендованные видео друг на друга. Эта метрика важна для отслеживания, поскольку пользователей больше интересуют разнообразные видео. Для измерения разнообразия мы вычисляем среднее попарное сходство (например, косинусное сходство или скалярное произведение) между видео в списке. Низкое среднее попарное сходство указывает на разнообразие списка.

Обратите внимание, что использование разнообразия в качестве единственной меры качества может привести к вводящим в заблуждение интерпретациям. Например, если рекомендованные видео разнообразны, но нерелевантны для пользователя, он может не счесть рекомендации полезными. Поэтому следует использовать разнообразие с другими автономными метриками для обеспечения как релевантности, так и разнообразия.

Онлайн-метрики

На практике компании отслеживают много метрик во время онлайн-оценки. Рассмотрим некоторые из наиболее важных:

• CTR (Click-through rate)
• Количество просмотренных видео до конца
• Общее время просмотра
• Явная обратная связь пользователей

CTR. Соотношение между нажатыми видео и общим количеством рекомендованных видео. Формула:

CTR является информативной метрикой для отслеживания вовлечённости пользователей, но недостаток CTR в том, что мы не можем обнаружить или измерить кликбейт-видео.

Количество просмотренных видео до конца. Общее количество рекомендованных видео, которые пользователи смотрят до конца. Отслеживая эту метрику, мы можем понять, как часто система рекомендует видео, которые пользователи просматривают.

Общее время просмотра. Общее время, затраченное пользователями на просмотр рекомендованных видео. Когда рекомендации интересны пользователям, они тратят больше времени на просмотр видео в целом.

Явная обратная связь пользователей. Общее количество видео, которые пользователи явно лайкнули или дизлайкнули. Эта метрика точно отражает мнение пользователей о рекомендованных видео.

Обслуживание

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

Учитывая, что у нас миллиарды доступных видео, скорость обслуживания будет медленной, если мы выберем тяжёлую модель, принимающую много признаков. С другой стороны, если мы выберем лёгкую модель, она может не давать высококачественных рекомендаций. Что делать? Естественным решением является использование более одной модели в многоэтапном дизайне. Например, в двухэтапном дизайне лёгкая модель быстро сужает видео на первом этапе, называемом генерацией кандидатов. На втором этапе используется более тяжёлая модель, точно оценивающая и ранжирующая видео, называемом оцениванием. На рисунке 6.236.236.23 показано, как генерация кандидатов и оценивание работают вместе для получения релевантных видео.

Рассмотрим компоненты конвейера прогнозирования подробнее.

• Генерация кандидатов
• Оценивание
• Переранжирование

Генерация кандидатов

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

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

На рисунке 6.246.246.24 показан рабочий процесс генерации кандидатов. Генерация кандидатов получает embedding пользователя от башни пользователя. После завершения вычислений она извлекает наиболее схожие видео из сервиса приближённого поиска ближайших соседей. Эти видео ранжируются по сходству в пространстве embeddings и возвращаются в качестве вывода.

На практике компании могут использовать более одного генератора кандидатов, поскольку это может улучшить производительность рекомендации. Рассмотрим почему.

Пользователи могут быть заинтересованы в видео по многим причинам. Например, пользователь может выбрать просмотр видео, потому что оно популярно, в тренде или релевантно его местоположению. Чтобы включить эти видео в рекомендации, обычно используется более одного генератора кандидатов, как показано на рисунке 6.25.

Как только мы сузили потенциальные видео с миллиардов до тысяч, мы можем использовать компонент оценивания для ранжирования этих видео перед их отображением.

Оценивание

Также известное как ранжирование, оценивание принимает пользователя и кандидатные видео в качестве входных данных, оценивает каждое видео и выводит ранжированный список видео.

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

Переранжирование

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

• Видео с региональными ограничениями
• Свежесть видео
• Видео, распространяющие дезинформацию
• Дублирующиеся или почти дублирующиеся видео
• Справедливость и предвзятость

Проблемы систем рекомендаций видео

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

Скорость обслуживания

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

В частности, мы используем лёгкую модель на первом этапе для быстрого сужения кандидатных видео с миллиардов до тысяч. YouTube использует аналогичный подход [2], а Instagram применяет многоэтапный дизайн [8].

Точность

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

Разнообразие

Большинство пользователей предпочитают видеть разнообразный выбор видео в рекомендациях. Чтобы наша система создавала разнообразный набор видео, мы используем несколько генераторов кандидатов, как объяснено в разделе генерации кандидатов.

Проблема холодного старта

Как наша система справляется с проблемой холодного старта?

Для новых пользователей: когда новые пользователи начинают использовать нашу платформу, у нас нет данных о взаимодействиях с ними.

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

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

Масштабируемость обучения

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

В нашем случае модели основаны на нейронных сетях и спроектированы для лёгкого дообучения.

Дополнительные темы для обсуждения

Если в конце собеседования осталось время, вот некоторые дополнительные темы для обсуждения:

• Компромисс между исследованием и эксплуатацией в рекомендательных системах [9].
• Различные типы предвзятостей в рекомендательных системах [10].
• Важные этические соображения при создании рекомендательных систем [11].
• Учёт сезонности — изменений в поведении пользователей в разные сезоны — в рекомендательной системе [12].
• Оптимизация системы для нескольких целей вместо одной [13].
• Как извлечь пользу из отрицательной обратной связи, например дизлайков [14].
• Использование последовательности видео в истории поиска или просмотра пользователя [2].

Ссылки

1. YouTube recommendation system. https://blog.youtube/inside-youtube/on-youtubes-recommendation-system.
2. DNN for YouTube recommendation. https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45530.pdf.
3. CBOW paper. https://arxiv.org/pdf/1301.3781.pdf.
4. BERT paper. https://arxiv.org/pdf/1810.04805.pdf.
5. Matrix factorization. https://developers.google.com/machine-learning/recommendation/collaborative/matrix.
6. Stochastic gradient descent. https://en.wikipedia.org/wiki/Stochastic_gradient_descent.
7. WALS optimization. https://fairyonice.github.io/Learn-about-collaborative-filtering-and-weighted-alternating-least-square-with-tensorflow.html.
8. Instagram multi-stage recommendation system. https://ai.facebook.com/blog/powered-by-ai-instagrams-explore-recommender-system/.
9. Exploration and exploitation trade-offs. https://en.wikipedia.org/wiki/Multi-armed_bandit.
10. Bias in AI and recommendation systems. https://www.searchenginejournal.com/biases-search-recommender-systems/339319/#close.
11. Ethical concerns in recommendation systems. https://link.springer.com/article/10.1007/s00146-020-00950-y.
12. Seasonality in recommendation systems. https://www.computer.org/csdl/proceedings-article/big-data/2019/09005954/1hJsfgT0qL6.
13. A multitask ranking system. https://daiwk.github.io/assets/youtube-multitask.pdf.
14. Benefit from a negative feedback. https://arxiv.org/abs/1607.04228?context=cs.

Система рекомендаций мероприятий

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

Уточнение требований

Вот типичное взаимодействие между кандидатом и интервьюером.

Кандидат: Какова бизнес-цель? Могу я предположить, что основная бизнес-цель — увеличение продаж билетов? Интервьюер: Да, звучит хорошо.

Кандидат: Помимо посещения мероприятий, могут ли пользователи бронировать отели или рестораны на платформе?

Интервьюер: Для простоты предположим, что поддерживаются только мероприятия.

Кандидат: Мероприятие считается эфемерным одноразовым событием, которое происходит лишь однажды, а затем истекает. Это предположение верно? Интервьюер: Отличное наблюдение.

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

Кандидат: Есть ли у нас аннотированные данные? Интервьюер: У нас нет датасета с ручными метками. Вы можете использовать данные о мероприятиях и взаимодействиях пользователей для построения обучающего датасета.

Кандидат: Есть ли у нас доступ к текущему местоположению пользователя? Интервьюер: Да. Поскольку эта задача сосредоточена на системе рекомендаций на основе местоположения, предположим, что пользователи согласились делиться своими данными о местоположении.

Кандидат: Могут ли пользователи дружить на платформе? Информация о дружбе ценна для построения персонализированной системы рекомендаций мероприятий. Интервьюер: Хороший вопрос. Да, предположим, что пользователи могут заводить друзей на нашей платформе. Дружба двунаправленная: если A является другом B, то B тоже является другом A.

Кандидат: Могут ли пользователи приглашать других на мероприятия? Интервьюер: Да.

Кандидат: Может ли пользователь подтвердить участие в мероприятии (RSVP)? Интервьюер: Для простоты предположим, что для мероприятия доступна только опция регистрации.

Кандидат: Мероприятия платные или бесплатные? Интервьюер: Нам нужно поддерживать оба варианта.

Кандидат: Сколько пользователей и мероприятий доступно? Интервьюер: Ежемесячно мы размещаем около 1 миллиона мероприятий.

Кандидат: Сколько ежедневных активных пользователей посещает сайт/приложение? Интервьюер: Предположим, что у нас один миллион уникальных пользователей в день.

Кандидат: Поскольку мы создаём систему рекомендаций мероприятий на основе местоположения, важно эффективно вычислять расстояние и время в пути между двумя точками. Можем ли мы предположить, что для получения таких данных можно использовать внешние API, такие как Google Maps API или другие картографические сервисы? Интервьюер: Хорошее замечание. Предположим, что мы можем использовать сторонние сервисы для получения данных о местоположении.

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

Формулировка задачи как ML-задачи

Определение ML-цели

Согласно требованиям, бизнес-цель — увеличение продаж билетов. Один из способов перевести это в чётко определённую ML-цель — максимизировать количество регистраций на мероприятия.

Определение входных и выходных данных системы

Входными данными системы является пользователь, а выходными — топ-k мероприятий, ранжированных по релевантности для пользователя.

Выбор подходящей категории ML

Существуют разные способы решения задачи рекомендаций:

• Простые правила, например рекомендация популярных мероприятий
• Модели на основе embeddings, использующие контентную или коллаборативную фильтрацию
• Переформулировка задачи как задачи ранжирования

Методы на основе правил — хорошая отправная точка для создания базового решения. Однако ML-подходы обычно дают лучшие результаты. В этой главе мы переформулируем задачу как задачу ранжирования и используем Learning to Rank (LTR) для её решения.

LTR — это класс алгоритмических техник, применяющих обучение с учителем для решения задач ранжирования. Задача ранжирования формально определяется так: «имея запрос и список элементов, какой оптимальный порядок элементов от наиболее до наименее релевантного запросу?» Существуют три подхода LTR: точечный (pointwise), попарный (pairwise) и списочный (listwise). Кратко рассмотрим каждый из них. Детальное объяснение этих подходов выходит за рамки данной книги. Если вас интересует более подробное изучение LTR, обратитесь к [1].

Точечный LTR (Pointwise LTR)

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

Итоговое ранжирование достигается сортировкой предсказанных оценок релевантности.

Попарный LTR (Pairwise LTR)

В этом подходе модель берёт два элемента и предсказывает, какой из них более релевантен запросу.

Среди наиболее популярных попарных алгоритмов LTR — RankNet [2], LambdaRank [3] и LambdaMART [4].

Списочный LTR (Listwise LTR)

Списочные подходы предсказывают оптимальный порядок всего списка элементов для данного запроса.

Среди популярных списочных алгоритмов LTR — SoftRank [5], ListNet [6] и AdaRank [7].

В целом попарные и списочные подходы дают более точные результаты, но их сложнее реализовать и обучать. Для простоты мы используем точечный подход. В частности, мы применяем модель бинарной классификации, которая берёт одно мероприятие за раз и предсказывает вероятность того, что пользователь на него зарегистрируется. Этот подход показан на рисунке 7.6.

Подготовка данных

Инженерия данных

Для эффективного построения признаков сначала нужно понять, какие исходные данные доступны в системе. Поскольку платформа управления мероприятиями ориентирована прежде всего на пользователей и мероприятия, предположим, что доступны следующие данные:

• Пользователи
• Мероприятия
• Дружба
• Взаимодействия

Пользователи

Схема данных о пользователях показана ниже.

Таблица 7.1: Схема данных о пользователях

Мероприятия

В таблице 7.2 показано, как могут выглядеть данные о мероприятиях.

Таблица 7.2: Данные о мероприятиях

Дружба

В таблице 7.3 каждая строка представляет дружбу между двумя пользователями, а также метку времени её установления.

Таблица 7.3: Данные о дружбе

Взаимодействия

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

Таблица 7.4: Данные о взаимодействиях

Инженерия признаков

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

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

• Признаки, связанные с местоположением
• Признаки, связанные со временем
• Социальные признаки
• Признаки пользователя
• Признаки мероприятия

Признаки, связанные с местоположением

Насколько доступно место проведения мероприятия?

Доступность места проведения мероприятия является важным фактором. Например, если мероприятие проводится высоко в горах, далеко от общественного транспорта, дорога может отпугнуть пользователей. Создадим следующие признаки для оценки доступности:

• Walk score (пешеходный рейтинг): число от 0 до 100, измеряющее пешеходную доступность адреса на основе расстояния до ближайших объектов инфраструктуры. Он вычисляется путём анализа различных факторов: расстояния до объектов, удобства для пешеходов, плотности населения и т.д. Предполагаем, что walk score можно получить из внешних источников данных, таких как Google Maps, Open Street Map и т.д. В таблице 7.5 walk score разбит на 5 категорий.

Таблица 7.5: Категории walk score

• Сходство walk score: разница между walk score мероприятия и средним walk score предыдущих мероприятий, на которые регистрировался пользователь.
• Transit score (рейтинг общественного транспорта), сходство transit score, bike score (велосипедный рейтинг), сходство bike score.

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

• Если страна пользователя совпадает со страной мероприятия — признак равен 1, иначе 0
• Если город пользователя совпадает с городом мероприятия — признак равен 1, иначе 0

Комфортно ли пользователю расстояние? Некоторые пользователи предпочитают мероприятия очень близко к своему местоположению, другие — более удалённые. Используем следующие признаки для отражения этого:

• Расстояние между местоположением пользователя и местом проведения мероприятия. Это значение можно получить из внешних API и разбить на несколько категорий. Например: 0: менее мили 1: 1–5 миль 2: 5–20 миль 3: 20–50 миль 4: 50–100 миль 5: более 100 миль
• Сходство расстояния: разница между расстоянием до текущего мероприятия и средним расстоянием (на практике можно использовать медиану или перцентильный диапазон) до мероприятий, на которые ранее регистрировался пользователь.

Признаки, связанные со временем

Насколько удобно оставшееся до мероприятия время? Некоторые пользователи планируют посещение мероприятий за несколько дней, другие — нет. Создадим следующие признаки:

• Оставшееся время до начала мероприятия. Этот признак можно разбить на различные категории и закодировать методом one-hot. Например: 0: менее 1 часа до начала мероприятия 1: 1–2 часа 2: 2–4 часа 3: 4–6 часов 4: 6–12 часов 5: 12–24 часа 6: 1–3 дня 7: 3–7 дней 8: более 7 дней
• Сходство оставшегося времени: разница между «оставшимся временем» и средним «оставшимся временем» для мероприятий, на которые ранее регистрировался пользователь.
• Расчётное время в пути от местоположения пользователя до места проведения мероприятия. Это значение получается из внешних сервисов и разбивается на категории.
• Сходство расчётного времени в пути: разница между расчётным временем в пути до данного мероприятия и средним расчётным временем в пути к мероприятиям, на которые ранее регистрировался пользователь.

Удобны ли пользователю дата и время? Некоторые пользователи предпочитают мероприятия в выходные дни, другие — в будни. Некоторые предпочитают утренние мероприятия, а другие — вечерние. Для отражения исторических предпочтений пользователя по дням недели мы создаём профиль пользователя. Этот профиль — вектор размера 7, где каждое значение подсчитывает количество мероприятий, посещённых пользователем в конкретный день. Разделив эти значения на общее количество посещённых мероприятий, мы получаем исторический показатель посещаемости мероприятий по дням недели. На рисунке 7.8 показано распределение ранее посещённых пользователем мероприятий по дням. Как видим, этот пользователь никогда не посещал мероприятия в понедельник или среду, поэтому отображение мероприятия в среду может оказаться неудачной рекомендацией. Аналогичным образом можно создать почасовые профили пользователей, а также добавить признаки сходства по дням и часам.

Сводка признаков, связанных со временем, показана на рисунке 7.9.

Социальные признаки

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

• Количество пользователей, зарегистрировавшихся на мероприятие
• Отношение общего числа зарегистрировавшихся пользователей к числу показов
• Сходство зарегистрированных пользователей: разница между количеством зарегистрировавшихся на данное мероприятие и на ранее посещённые мероприятия

Признаки, связанные с посещаемостью друзьями Пользователь с большей вероятностью зарегистрируется на мероприятие, если его друзья тоже на него идут. Вот некоторые признаки:

• Количество друзей пользователя, зарегистрировавшихся на данное мероприятие
• Отношение числа зарегистрировавшихся друзей к общему числу друзей
• Сходство зарегистрировавшихся друзей: разница между количеством зарегистрировавшихся друзей на данное мероприятие и на ранее посещённые мероприятия

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

• Количество друзей, пригласивших данного пользователя на мероприятие
• Количество других пользователей, пригласивших данного человека на мероприятие

Является ли организатор мероприятия другом пользователя? Пользователи склонны посещать мероприятия, созданные их друзьями. Создаём бинарный признак: если организатор мероприятия является другом пользователя — значение равно 1, иначе 0.

Как часто пользователь посещал предыдущие мероприятия данного организатора? Некоторые пользователи заинтересованы в отслеживании мероприятий конкретного организатора.

Признаки пользователя

Возраст и пол Некоторые мероприятия ориентированы на определённый возраст и пол. Например, «Женщины в технологиях» и «Жизненные уроки для успеха после 30» — примеры мероприятий для конкретных демографических групп. Создадим два признака:

• Пол пользователя, закодированный методом one-hot encoding
• Возраст пользователя, разбитый на несколько категорий и закодированный методом one-hot encoding

Признаки мероприятия

Цена мероприятия: Цена мероприятия может влиять на решение пользователя зарегистрироваться. Некоторые признаки:

• Цена мероприятия, разбитая на несколько категорий. Например: 0: Бесплатно 1: $1–$99 2: $100–$499 3: $500–$1,999 4: +$2,000
• Сходство цены: разница между ценой данного мероприятия и средней ценой мероприятий, на которые ранее регистрировался пользователь.

Насколько описание этого мероприятия похоже на описания ранее посещённых мероприятий? Это отражает интересы пользователя на основе ранее посещённых мероприятий. Например, если слово «концерт» неоднократно встречается в описаниях предыдущих мероприятий, это может указывать на интерес пользователя к концертам. Для фиксации этого создаём признак, представляющий сходство между описанием мероприятия и описаниями мероприятий, на которые ранее регистрировался пользователь. Для вычисления сходства описание преобразуется в числовой вектор с помощью TF-IDF, а сходство вычисляется с использованием косинусного расстояния.

Обратите внимание, этот признак может быть зашумлённым, поскольку описания предоставляются организаторами вручную. Можно провести эксперимент, обучив модель с этим признаком и без него, чтобы измерить его важность.

На рисунке 7.10 показан обзор признаков пользователя, признаков мероприятия и социальных признаков.

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

• Пакетные и потоковые признаки: пакетные (статические) признаки меняются редко, например возраст, пол и описание мероприятия. Они могут периодически вычисляться с помощью пакетной обработки и храниться в хранилище признаков. Напротив, потоковые (динамические) признаки меняются быстро. Например, количество зарегистрировавшихся на мероприятие и оставшееся время — динамические признаки. Интервьюер может попросить подробнее рассмотреть эту тему и обсудить пакетную и онлайн-обработку в ML. Если вас интересует подробное изучение, обратитесь к [8].
• Эффективность вычисления признаков. Вычисление признаков в реальном времени неэффективно. Стоит обсудить эту проблему и возможные способы её избежать. Например, вместо вычисления расстояния между текущим местоположением пользователя и местом проведения мероприятия в качестве признака можно передавать оба местоположения в модель как два отдельных признака и позволить модели неявно извлекать полезную информацию из них. Подробнее о подготовке данных о местоположении для ML-моделей см. [9].
• Использование коэффициента затухания для признаков, основанных на последних X взаимодействиях пользователя. Коэффициент затухания придаёт больший вес недавним взаимодействиям/поведению пользователя.
• Использование обучения embeddings для преобразования каждого мероприятия и пользователя в вектор embedding. Эти векторы используются как признаки, представляющие мероприятия и пользователей.
• Создание признаков из атрибутов пользователей может порождать предвзятость. Например, опора на возраст или пол при определении пригодности соискателя для работы может привести к дискриминации. Поскольку мы создаём признаки из атрибутов пользователей, важно осознавать потенциальные проблемы предвзятости.

Разработка модели

Выбор модели

Задачи бинарной классификации можно решать различными ML-методами. Рассмотрим следующие:

• Логистическая регрессия
• Дерево решений
• Градиентный бустинг деревьев решений (GBDT)
• Нейронная сеть

Логистическая регрессия (LR)

LR моделирует вероятность бинарного результата, используя линейную комбинацию одного или нескольких признаков. Подробности об LR см. в [10].

Рассмотрим плюсы и минусы LR.

Плюсы:

• Быстрая скорость вывода. Вычисление взвешенной комбинации входных признаков происходит быстро.
• Эффективное обучение. Благодаря простой архитектуре легко реализовать, интерпретировать и быстро обучить.
• Хорошо работает, когда данные линейно разделимы (рисунок 7.12).
• Интерпретируемость и простота понимания. Веса, присвоенные каждому признаку, указывают на важность различных признаков, что даёт понимание того, почему было принято то или иное решение.

Минусы:

• Нелинейные задачи не могут быть решены с помощью LR, поскольку она использует линейную комбинацию входных признаков.
• Мультиколлинеарность возникает, когда два или более признаков сильно коррелируют. Одним из известных ограничений LR является то, что она плохо справляется с задачей при наличии мультиколлинеарности во входных признаках.

В нашей системе количество входных признаков может быть очень большим. Зачастую эти признаки имеют сложные нелинейные отношения с целевой переменной (бинарным результатом). Такую сложность LR может не осилить.

Дерево решений

Деревья решений — ещё один класс методов обучения, использующих древовидную модель решений и их возможных последствий для прогнозирования. На рисунке 7.13 показано простое дерево решений с двумя признаками: возраст и пол, а также соответствующая граница решения. Каждый листовой узел в дереве решений указывает на бинарный результат: «+» означает, что входные данные классифицируются как положительный класс, «-» — как отрицательный. Подробнее о деревьях решений см. [11].

Плюсы:

• Быстрое обучение: деревья решений обучаются быстро.
• Быстрый вывод: деревья решений быстро делают предсказания во время вывода.
• Минимальная подготовка данных: модели деревьев решений не требуют нормализации или масштабирования данных, поскольку алгоритм не зависит от распределения входных признаков.
• Интерпретируемость и простота понимания. Визуализация дерева даёт хорошее представление о том, почему было принято решение и какие факторы были определяющими.

Минусы:

• Неоптимальная граница решения: модели деревьев решений создают границы решений, параллельные осям в пространстве признаков (рисунок 7.13). Это может оказаться неоптимальным способом поиска границы для определённых распределений данных.
• Переобучение: деревья решений очень чувствительны к небольшим вариациям данных. Небольшое изменение входных данных может привести к разным результатам во время обслуживания. Аналогично, небольшое изменение обучающих данных может привести к совершенно другой структуре дерева. Это серьёзная проблема, делающая предсказания менее надёжными.

На практике наивные деревья решений используются редко из-за их высокой чувствительности к вариациям входных данных. Для снижения этой чувствительности применяются два метода:

• Bootstrap-агрегирование (Bagging)
• Бустинг

Оба метода широко используются в технологической отрасли. Важно понимать, как они работают. Рассмотрим их подробнее.

Bagging

Bagging — метод ансамблевого обучения, при котором набор ML-моделей обучается параллельно на множестве подвыборок обучающих данных. В bagging предсказания всех обученных моделей объединяются для получения итогового предсказания. Это значительно снижает чувствительность модели к изменениям данных (дисперсию).

Пример bagging — широко используемая модель «случайный лес» [12]. Случайный лес строит несколько деревьев решений параллельно во время обучения, чтобы снизить чувствительность модели. Для предсказания каждое дерево решений независимо предсказывает выходной класс (положительный или отрицательный) для заданных входных данных, а затем механизм голосования объединяет эти предсказания. На рисунке 7.14 показан случайный лес с тремя деревьями решений.

Метод bagging имеет следующие преимущества:

• Снижает эффект переобучения (высокой дисперсии).
• Не значительно увеличивает время обучения, поскольку деревья решений можно обучать параллельно.
• Не добавляет существенной задержки при выводе, поскольку деревья решений могут обрабатывать входные данные параллельно.

Несмотря на преимущества, bagging не помогает при недообучении модели (высоком смещении). Для устранения этого недостатка рассмотрим другой метод — бустинг.

Бустинг

В ML бустинг предполагает последовательное обучение нескольких слабых классификаторов для снижения ошибок предсказания. «Слабый классификатор» — простой классификатор, работающий лишь немного лучше случайного угадывания. При бустинге несколько слабых классификаторов объединяются в одну сильную модель. На рисунке 7.15 показан пример бустинга.

Плюсы:

• Бустинг снижает смещение и дисперсию. Объединение слабых классификаторов создаёт сильную модель, менее чувствительную к изменениям данных. Подробнее о компромиссе смещения/дисперсии см. [13]. Минусы:
• Более медленное обучение и вывод. Поскольку классификаторы обучаются на основе ошибок предыдущих, они работают последовательно. Это увеличивает время обслуживания из-за последовательного характера бустинга.

На практике бустинг обычно предпочтительнее bagging, поскольку bagging не помогает в случаях смещения, тогда как бустинг снижает эффект как смещения, так и дисперсии.

Типичные деревья решений на основе бустинга — AdaBoost [14], XGBoost [15] и Gradient boost [16]. Они широко применяются для обучения классификационных моделей.

GBDT

GBDT — широко используемая древовидная модель, использующая GradientBoost для улучшения деревьев решений. Некоторые варианты GBDT, такие как XGBoost [15], продемонстрировали высокую производительность в различных ML-соревнованиях [17]. Подробнее о GBDT см. [18][19].

Плюсы и минусы модели GBDT.

Плюсы:

• Простая подготовка данных: аналогично деревьям решений, не требует подготовки данных.
• Снижение дисперсии: GBDT снижает дисперсию, используя технику бустинга.
• Снижение смещения: GBDT снижает ошибку предсказания за счёт нескольких слабых классификаторов, итеративно улучшая неправильно классифицированные точки предыдущих классификаторов.
• Хорошо работает со структурированными данными.

Минусы:

• Много гиперпараметров для настройки: количество итераций, глубина дерева, параметры регуляризации и т.д.
• GBDT плохо работает с неструктурированными данными, такими как изображения, видео, аудио и т.д.
• Не подходит для непрерывного обучения на потоковых данных.

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

Главным недостатком GBDT является непригодность для непрерывного обучения. В системе рекомендаций мероприятий новые данные непрерывно поступают в систему: недавние взаимодействия, регистрации, новые мероприятия и даже новые пользователи. Кроме того, вкусы и интересы пользователей могут меняться со временем. Важно, чтобы хорошая система рекомендаций мероприятий непрерывно адаптировалась к новым данным. Без возможности непрерывного обучения регулярное переобучение GBDT с нуля обходится очень дорого. Далее мы рассмотрим нейронные сети, которые преодолевают это ограничение.

Нейронная сеть (NN)

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

Нейронные сети отлично справляются с этими задачами. Они способны обучаться сложным задачам с нелинейными границами решений. Кроме того, модели NN можно легко дообучать на новых данных, что делает их идеальными для непрерывного обучения. Если вы не знакомы с деталями NN, рекомендуем обратиться к [20].

Плюсы:

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

Минусы:

• Вычислительно затратное обучение.
• Качество входных данных сильно влияет на результат: NN чувствительны к входным данным. Например, если входные признаки имеют очень разные диапазоны, модель может медленно сходиться во время обучения. Важным шагом для NN является подготовка данных: нормализация, логарифмическое масштабирование, one-hot encoding и т.д.
• Для обучения NN требуются большие объёмы обучающих данных.
• Природа «чёрного ящика»: NN не интерпретируемы — сложно понять влияние каждого признака на результат, поскольку входные признаки проходят через несколько слоёв нелинейных преобразований.

Какую модель выбрать?

Выбор правильной модели — непростая задача. Зачастую необходимо экспериментировать с разными моделями, чтобы определить, какая работает лучше. Выбор модели основывается на различных факторах:

• Сложность задачи
• Распределение и тип данных
• Требования или ограничения продукта: стоимость обучения, скорость, размер модели и т.д. В данной задаче GBDT и NN — хорошие кандидаты для экспериментов. Начнём с варианта GBDT — XGBoost, поскольку его быстро реализовать и обучить. Результат можно использовать как начальный базовый уровень.

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

• В системе доступны огромные объёмы обучающих данных. Пользователи непрерывно взаимодействуют с системой: регистрируются на мероприятия, приглашают друзей, публикуют новые мероприятия и т.д. Учитывая количество пользователей, это создаёт огромный массив данных для обучения.
• Данные могут не быть линейно разделимыми, а нейронные сети способны обучаться нелинейным данным.

При проектировании архитектуры NN необходимо учитывать несколько гиперпараметров: количество скрытых слоёв, количество нейронов в каждом слое, функцию активации и т.д. Они могут быть определены с помощью методов настройки гиперпараметров. Детали архитектуры NN обычно не являются основным фокусом на собеседованиях по проектированию ML-систем, поскольку нет систематического способа выбора правильной архитектуры.

Обучение модели

Построение датасета

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

Для построения одной точки данных мы извлекаем пару ⟨пользователь, мероприятие⟩ из данных о взаимодействиях и вычисляем входные признаки из этой пары. Затем помечаем точку данных меткой 1, если пользователь зарегистрировался на мероприятие, и 0 в противном случае.

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

• Использовать focal loss или class-balanced loss для обучения классификатора
• Применить undersampling для класса большинства

Выбор функции потерь

Поскольку модель является моделью бинарной классификации, мы используем типичную функцию потерь классификации — бинарную кросс-энтропию — для оптимизации нейронной сети.

Оценка

Офлайн-метрики

Для оценки системы ранжирования рассмотрим следующие варианты.

Recall@k или Precision@k. Эти метрики не подходят, поскольку не учитывают качество ранжирования выходных данных.

MRR, nDCG или mAP. Все три метрики широко используются для измерения качества ранжирования. Но какая из них наилучшая?

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

nDCG хорошо работает, когда оценка релевантности между пользователем и элементом небинарная. Напротив, mAP работает только с бинарными оценками релевантности. Поскольку мероприятия либо релевантны (пользователь на них зарегистрировался), либо нерелевантны (пользователь видел мероприятие, но не зарегистрировался), mAP подходит лучше.

Онлайн-метрики

В нашем случае бизнес-цель — увеличение дохода за счёт роста продаж билетов. Для измерения влияния системы на доход рассмотрим следующие метрики:

• Click-through rate (CTR)
• Коэффициент конверсии
• Коэффициент сохранения в закладки
• Прирост выручки

CTR. Показатель, отражающий, как часто пользователи, видящие рекомендованные мероприятия, кликают на них.

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

Однако опора только на CTR как онлайн-метрику может быть недостаточной. Некоторые мероприятия являются кликбейтом. В идеале нам нужно измерять релевантность рекомендованных мероприятий для пользователя. Эта метрика называется коэффициентом конверсии.

Коэффициент конверсии. Показатель, отражающий, как часто пользователи, видящие рекомендованные мероприятия, регистрируются на них. Формула:

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

Коэффициент сохранения в закладки. Показатель, отражающий, как часто пользователи сохраняют рекомендованные мероприятия в закладки. Основан на предположении, что платформа позволяет пользователям сохранять мероприятия.

Прирост выручки. Увеличение дохода в результате рекомендаций мероприятий.

Обслуживание

В этом разделе мы предлагаем дизайн ML-системы для обслуживания запросов. Как показано на рисунке 7.20, в дизайне есть два основных пайплайна:

• Пайплайн онлайн-обучения
• Пайплайн предсказания

Пайплайн онлайн-обучения

Как описано ранее, рекомендации мероприятий по своей природе сталкиваются с холодным стартом и постоянной проблемой новых элементов. Следовательно, модель должна непрерывно дообучаться для адаптации к новым данным. Этот пайплайн отвечает за непрерывное обучение новых моделей с включением новых данных, оценку обученных моделей и их развёртывание.

Пайплайн предсказания

Пайплайн предсказания отвечает за предсказание топ-k наиболее релевантных мероприятий для данного пользователя. Рассмотрим наиболее важные компоненты пайплайна предсказания.

Фильтрация мероприятий

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

Сервис ранжирования

Этот сервис принимает пользователя и мероприятия-кандидаты от компонента фильтрации, вычисляет признаки для каждой пары ⟨пользователь, мероприятие⟩, сортирует мероприятия по вероятностям, предсказанным моделью, и выдаёт ранжированный список топ-k наиболее релевантных мероприятий.

Сервис ранжирования взаимодействует с компонентом вычисления признаков, отвечающим за вычисление признаков, которые ожидает модель. Статические признаки получаются из хранилища признаков, а динамические вычисляются в реальном времени из исходных данных.

Дополнительные темы для обсуждения

Если в конце собеседования осталось время, вот некоторые дополнительные темы для обсуждения:

• Какие типы предвзятости могут наблюдаться в данной системе [21].
• Как использовать пересечение признаков (feature crossing) для достижения большей выразительности [22].
• Некоторые пользователи предпочитают разнообразный список мероприятий. Как обеспечить разнообразие и новизну рекомендованных мероприятий [23]?
• Для обучения модели мы используем атрибуты пользователей, а также их геолокацию в реальном времени. Какие дополнительные соображения связаны с конфиденциальностью и безопасностью [24]?
• Платформы управления мероприятиями — двусторонние торговые площадки, где организаторы мероприятий являются поставщиками, а пользователи — стороной спроса. Как обеспечить, чтобы система не оптимизировалась только для одной стороны? Как поддерживать справедливость для разных организаторов? Подробнее об уникальных проблемах двусторонних торговых площадок см. [25].
• Как избежать утечки данных при построении датасета [26].
• Как определить правильную частоту обновления моделей [27].

Ссылки

1. Learning to rank methods. https://livebook.manning.com/book/practical-recommender-systems/chapter-13/53.
2. RankNet paper. https://icml.cc/2015/wp-content/uploads/2015/06/icml_ranking.pdf.
3. LambdaRank paper. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/lambdarank.pdf.
4. LambdaMART paper. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/MSR-TR-2010-82.pdf.
5. SoftRank paper. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/SoftRankWsdm08Submitted.pdf.
6. ListNet paper. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2007-40.pdf.
7. AdaRank paper. https://dl.acm.org/doi/10.1145/1277741.1277809.
8. Batch processing vs stream processing. https://www.confluent.io/learn/batch-vs-real-time-data-processing/#:~:text=Batch%20processing%20is%20when%20the,data%20flows%20through%20a%20system.
9. Leveraging location data in ML systems. https://towardsdatascience.com/leveraging-geolocation-data-for-machine-learning-essential-techniques-192ce3a969bc#:~:text=Location%20data%20is%20an%20important,based%20on%20your%20customer%20data.
10. Logistic regression. https://www.youtube.com/watch?v=yIYKR4sgzI8.
11. Decision tree. https://careerfoundry.com/en/blog/data-analytics/what-is-a-decision-tree/.
12. Random forests. https://en.wikipedia.org/wiki/Random_forest.
13. Bias/variance trade-off. http://www.cs.cornell.edu/courses/cs578/2005fa/CS578.bagging.boosting.lecture.pdf.
14. AdaBoost. https://en.wikipedia.org/wiki/AdaBoost.
15. XGBoost. https://xgboost.readthedocs.io/en/stable/.
16. Gradient boosting. https://machinelearningmastery.com/gentle-introduction-gradient-boosting-algorithm-machine-learning/.
17. XGBoost in Kaggle competitions. https://www.kaggle.com/getting-started/145362.
18. GBDT. https://blog.paperspace.com/gradient-boosting-for-classification/.
19. An introduction to GBDT. https://www.machinelearningplus.com/machine-learning/an-introduction-to-gradient-boosting-decision-trees/.
20. Introduction to neural networks. https://www.youtube.com/watch?v=i2fmaabIs5w.
21. Bias issues and solutions in recommendation systems. https://www.youtube.com/watch?v=pPq9iyGIZZ8.
22. Feature crossing to encode non-linearity. https://developers.google.com/machine-learning/crash-course/feature-crosses/encoding-nonlinearity.
23. Freshness and diversity in recommendation systems. https://developers.google.com/machine-learning/recommendation/dnn/re-ranking.
24. Privacy and security in ML. https://www.microsoft.com/en-us/research/blog/privacy-preserving-machine-learning-maintaining-confidentiality-and-preserving-trust/.
25. Two-sides marketplace unique challenges. https://www.uber.com/blog/uber-eats-recommending-marketplace/.
26. Data leakage. https://machinelearningmastery.com/data-leakage-machine-learning/.
27. Online training frequency. https://huyenchip.com/2022/01/02/real-time-machine-learning-challenges-and-solutions.html#towards-continual-learning.

Прогнозирование кликов по рекламе в социальных сетях

Введение

Онлайн-реклама позволяет рекламодателям делать ставки и размещать рекламу на платформе для получения измеримых откликов: показов, кликов и конверсий. Отображение релевантной рекламы пользователям — фундаментальная задача многих онлайн-платформ, таких как Google, Facebook и Instagram.

В этой главе мы проектируем систему прогнозирования кликов по рекламе (также известную как ad click prediction), аналогичную используемым популярными социальными сетями.

Уточнение требований

Вот типичное взаимодействие между кандидатом и интервьюером.

Кандидат: Могу я предположить, что бизнес-цель системы прогнозирования рекламы — максимизация дохода? Интервьюер: Да, верно.

Кандидат: Существуют различные типы рекламы: видео и графическая. Кроме того, реклама может отображаться в разных размерах и форматах: в лентах пользователей, во всплывающих окнах и т.д. Для простоты могу я предположить, что реклама размещается только в лентах пользователей и каждый клик генерирует одинаковый доход? Интервьюер: Звучит хорошо.

Кандидат: Может ли система показывать одну и ту же рекламу одному пользователю более одного раза? Интервьюер: Да, рекламу можно показывать более одного раза. Иногда реклама превращается в клик после нескольких показов. На практике компании применяют «период усталости»: они не показывают одну и ту же рекламу одному пользователю в течение X дней, если пользователь неоднократно её игнорирует. Для простоты предположим, что периода усталости нет.

Кандидат: Поддерживаем ли мы функцию «скрыть эту рекламу»? А что насчёт «заблокировать этого рекламодателя»? Такие виды негативной обратной связи помогают обнаруживать нерелевантную рекламу. Интервьюер: Хороший вопрос. Предположим, что пользователи могут скрывать нежелательную рекламу. «Заблокировать рекламодателя» — интересная функция, но нам не нужно поддерживать её сейчас.

Кандидат: Можно ли предположить, что обучающий датасет должен формироваться на основе данных о пользователях и рекламе, а метки — на основе взаимодействий пользователей с рекламой? Интервьюер: Конечно.

Кандидат: Мы можем строить положительные обучающие примеры через клики пользователей, но как генерировать отрицательные примеры? Можно ли предположить, что любой показ без клика является отрицательным примером? Что если пользователь прокручивает страницу быстро и не успевает увидеть рекламу? Что если мы считаем показ отрицательным, но пользователь в итоге кликает на него? Интервьюер: Отличные вопросы. Что вы думаете?

Кандидат: Если реклама была видна на экране пользователя в течение определённого времени, но не была нажата, мы можем считать это отрицательным примером. Альтернативный подход — считать показы отрицательными до тех пор, пока не наблюдается клик. Кроме того, можно опираться на негативную обратную связь — «скрыть рекламу» — для разметки отрицательных примеров. Интервьюер: Логично! На практике могут использоваться более сложные методы разметки отрицательных примеров. В рамках этого собеседования продолжим с вашими предложениями.

Кандидат: В системах прогнозирования кликов по рекламе критически важно непрерывно обучать модель на новых взаимодействиях. Можно ли предположить, что непрерывное обучение здесь необходимо? Интервьюер: Отличное замечание. Эксперименты показали, что даже 5-минутная задержка обновления моделей может ухудшить производительность [1].

Подведём итог формулировки задачи. Нас просят спроектировать систему прогнозирования кликов по рекламе. Бизнес-цель системы — максимизация дохода. Реклама размещается только в лентах пользователей, и каждый клик приносит одинаковый доход. Непрерывное обучение модели на новых взаимодействиях является необходимым. Датасет формируется из данных о пользователях и рекламе, метки назначаются на основе взаимодействий. В этой главе мы не будем рассматривать специфические темы AdTech, поскольку они не релевантны для ML-собеседований. Подробнее об AdTech см. [2].

Формулировка задачи как ML-задачи

Определение ML-цели

Цель системы прогнозирования кликов по рекламе — увеличение дохода за счёт показа пользователям рекламы, на которую они с большей вероятностью кликнут. Это можно сформулировать как ML-цель: предсказать, будет ли реклама нажата. Корректное предсказание вероятностей кликов позволяет системе показывать пользователям релевантную рекламу, что ведёт к росту дохода.

Определение входных и выходных данных системы

Система прогнозирования кликов по рекламе принимает пользователя как входные данные и выдаёт ранжированный список рекламных объявлений по вероятностям кликов.

Выбор подходящей категории ML

На рисунке 8.2 показано, как задача прогнозирования рекламы может быть сформулирована как задача ранжирования. Как описано в главе 7 о системе рекомендаций мероприятий, точечный Learning to Rank (LTR) является хорошей отправной точкой для решения задач ранжирования. Точечный LTR использует модель бинарной классификации, принимающую пару ⟨пользователь, реклама⟩ как входные данные и предсказывающую, кликнет ли пользователь на рекламу. На рисунке 8.3 показаны входные и выходные данные модели.

Подготовка данных

Инженерия данных

В этой системе доступны следующие исходные данные:

• Рекламные объявления
• Пользователи
• Взаимодействия пользователей с рекламой

Рекламные объявления

Данные о рекламе показаны в таблице 8.1. На практике с каждым объявлением может быть связано сотни атрибутов. Для простоты перечислены только важнейшие.

Таблица 8.1: Данные о рекламе

Пользователи

Схема данных о пользователях показана ниже.

Таблица 8.2: Схема данных о пользователях

Взаимодействия пользователей с рекламой

В этой таблице хранятся взаимодействия пользователей с рекламой: показы, клики и конверсии.

Таблица 8.3: Данные о взаимодействиях пользователей с рекламой

Инженерия признаков

Цель этого раздела — инженерия признаков, которые помогут нам предсказывать клики пользователей.

Признаки рекламы

Признаки рекламы включают:

• Идентификаторы (ID)
• Изображения/видео
• Категория и подкатегория
• Количество показов и кликов

Рассмотрим каждый подробнее.

Идентификаторы (ID)

Это ID рекламодателя, кампании, группы объявлений, объявления и т.д.

Почему это важно? ID представляют рекламодателя, кампанию, группу объявлений и само объявление. Эти идентификаторы используются как предиктивные признаки для отражения уникальных характеристик различных рекламодателей, кампаний, групп объявлений и объявлений.

Как подготовить? Слой embeddings преобразует разреженные признаки, такие как ID, в плотные векторы признаков. Каждый тип ID имеет собственный слой embeddings.

Изображения/видео

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

Как подготовить? Изображения или видео предварительно обрабатываются. Затем используется предобученная модель, такая как SimCLR [3], для преобразования неструктурированных данных в вектор признаков.

Категория и подкатегория рекламы

Категория и подкатегория рекламы, предоставленные рекламодателем. Например, вот список широких типов категорий: Arts & Entertainment, Autos & Vehicles, Beauty & Fitness и т.д.

Почему это важно? Помогает модели понять, к какой категории принадлежит реклама.

Как подготовить? Предоставляются рекламодателем вручную на основе предопределённого списка категорий и подкатегорий. Подробнее о подготовке текстовых данных см. главу 4, «Поиск видео на YouTube».

Количество показов и кликов

• Общее количество показов/кликов по рекламному объявлению
• Общее количество показов/кликов по рекламе от рекламодателя
• Общее количество показов кампании

Почему это важно? Эти числа показывают, как другие пользователи реагировали на рекламу. Например, пользователи с большей вероятностью кликнут на рекламу с высоким click-through rate (CTR).

Признаки пользователя

Аналогично предыдущим главам, мы выбираем следующие признаки:

• Демография: возраст, пол, город, страна и т.д.
• Контекстная информация: устройство, время суток и т.д.
• Признаки на основе взаимодействий: нажатая реклама, историческая статистика активности пользователя и т.д.

Рассмотрим подробнее признаки, связанные с взаимодействиями.

Нажатая реклама

Реклама, ранее нажатая пользователем.

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

Как подготовить? Аналогично описанному в разделе «Признаки рекламы».

Историческая статистика активности пользователя

Исторические показатели активности пользователя, такие как общее количество просмотров рекламы и частота кликов.

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

Как подготовить? Статистика активности представлена числовыми значениями. Для подготовки масштабируем их значения в схожий диапазон.

Прежде чем завершить раздел подготовки данных, рассмотрим распространённую проблему систем прогнозирования кликов по рекламе. В большинстве случаев такие системы работают с большим количеством высококардинальных категориальных признаков. Например, «категория рекламы» принимает значения из огромного списка всех возможных категорий. Аналогично, «ID рекламодателя» и «ID пользователя» могут принимать потенциально миллионы уникальных значений в зависимости от количества активных пользователей или рекламодателей на платформе. Учитывая огромное, как правило, пространство признаков, обычно возникает ситуация с тысячами или миллионами признаков, преимущественно заполненных нулями. В разделе выбора модели мы рассмотрим методы преодоления этих уникальных проблем.

Разработка модели

Выбор модели

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

• Логистическая регрессия
• Пересечение признаков + логистическая регрессия
• Градиентный бустинг деревьев решений
• Градиентный бустинг деревьев решений + логистическая регрессия
• Нейронные сети
• Deep & Cross Network (DCN)
• Factorization Machines (FM)
• Deep Factorization Machines (DeepFM)

Логистическая регрессия (LR)

LR моделирует вероятность бинарного результата с помощью линейной комбинации одного или нескольких признаков. LR быстро обучается и легко реализуется. Однако система прогнозирования кликов на основе LR имеет следующие недостатки:

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

Учитывая эти два недостатка, LR — не лучший выбор для системы прогнозирования рекламы. Однако благодаря быстрой реализации и лёгкому обучению многие компании используют её для создания базовой модели.

Пересечение признаков + LR

Для лучшего захвата взаимодействий признаков используется техника пересечения признаков (feature crossing).

Что такое пересечение признаков?

Пересечение признаков — техника ML для создания новых признаков из существующих. Она предполагает комбинирование двух или более существующих признаков в один новый посредством произведения, суммирования или иной комбинации. Таким образом можно захватывать нелинейные взаимодействия между исходными признаками, что может улучшить производительность ML-моделей. Например, взаимодействия вроде «молодёжь и баскетбол» или «США и футбол» могут положительно влиять на способность модели предсказывать вероятность клика.

Как создавать пересечения признаков?

При пересечении признаков мы вручную добавляем новые признаки к существующим на основе предварительных знаний. Как показано на рисунке 8.6, пересечение двух признаков, таких как «страна» и «язык», добавляет шесть новых признаков к существующему пространству признаков. Подробнее о пересечении см. [4].

Как использовать пересечение признаков + LR?

Как показано на рисунке 8.7, пересечение признаков + LR работает следующим образом:

1. Применить пересечение признаков к исходному набору признаков для извлечения новых признаков (скрещённых признаков)
2. Использовать исходные и скрещённые признаки как входные данные для модели LR для предсказания кликов

Этот метод позволяет модели захватывать определённые попарные (второго порядка) взаимодействия признаков. Однако у него есть три недостатка:

• Ручной процесс: требуется участие человека для выбора признаков для скрещивания, что трудоёмко и затратно.
• Требует экспертных знаний: пересечение признаков требует экспертизы в предметной области. Для определения прогностически значимых взаимодействий признаков необходимо заранее понимать задачу и пространство признаков.
• Не может захватывать сложные взаимодействия: скрещённых признаков может быть недостаточно для захвата всех сложных взаимодействий из тысяч разреженных признаков.
• Разреженность: исходные признаки могут быть разреженными. При пересечении признаков мощность скрещённых признаков может значительно увеличиться, что приводит к большей разреженности.

Учитывая недостатки, этот метод не является идеальным решением для системы прогнозирования рекламы.

Градиентный бустинг деревьев решений (GBDT)

Мы рассматривали GBDT в главе 7, «Система рекомендаций мероприятий». Здесь рассмотрим только плюсы и минусы GBDT применительно к системе прогнозирования кликов по рекламе.

Плюсы

• GBDT интерпретируем и прост для понимания

Минусы

• Неэффективен для непрерывного обучения. В системах прогнозирования кликов мы непрерывно собираем новые данные: пользователей, рекламу и взаимодействия. Для непрерывного обучения модели на новых данных обычно есть два варианта: 1) обучение с нуля или 2) дообучение модели на новых данных. GBDT не предназначен для дообучения на новых данных. Поэтому обычно требуется обучение с нуля, что неэффективно в больших масштабах.
• Не позволяет обучать слои embeddings. В системах прогнозирования рекламы распространены разреженные категориальные признаки, а слой embeddings является эффективным способом их представления. Однако GBDT не может использовать слои embeddings.

GBDT + LR

Этот подход состоит из двух шагов:

1. Обучить модель GBDT для решения задачи.
2. Вместо использования обученной модели для предсказаний использовать её для выбора и извлечения новых предиктивных признаков. Вновь сгенерированные признаки и исходные признаки используются как входные данные в модели LR для предсказания кликов.

Использование GBDT для отбора признаков Отбор признаков направлен на сокращение числа входных признаков до наиболее полезных и информативных. С помощью деревьев решений можно отбирать подмножество признаков на основе их важности. Подробнее о том, как деревья решений используются для генерации признаков, см. [5].

Использование GBDT для извлечения признаков Цель извлечения признаков — уменьшить количество признаков путём создания новых из существующих. Ожидается, что вновь извлечённые признаки обладают лучшей предиктивной силой. На рисунке 8.8 объясняется, как извлекать признаки с помощью GBDT.

Обзор использования GBDT с последующим LR показан на рисунке 8.9.

Рассмотрим плюсы и минусы этого подхода.

Плюсы:

• В отличие от существующих признаков, вновь созданные GBDT более предиктивны, что облегчает модели LR обучение задаче.

Минусы:

• Не может захватывать сложные взаимодействия. Аналогично LR, этот подход не способен обучаться попарным взаимодействиям признаков.
• Непрерывное обучение проходит медленно. Дообучение моделей GBDT на новых данных занимает время, что в целом замедляет непрерывное обучение.

Нейронная сеть (NN)

NN — ещё один кандидат для построения системы прогнозирования кликов по рекламе. Для предсказания вероятностей кликов с помощью NN есть два архитектурных варианта:

• Единственная NN
• Двухбашенная архитектура

Единственная NN: используя исходные признаки как входные данные, нейронная сеть выдаёт вероятность клика (рисунок 8.10).

Двухбашенная архитектура: в этом варианте используются два энкодера: энкодер пользователя и энкодер рекламы. Сходство между embeddings рекламы и пользователя определяет релевантность, то есть вероятность клика. На рисунке 8.11 показан обзор этой архитектуры.

Несмотря на многочисленные преимущества NN, они могут не быть лучшим выбором для систем прогнозирования кликов по рекламе, поскольку:

• Разреженность: учитывая, что пространство признаков обычно огромно и разреженно, большинство признаков заполнены нулями. NN может не справиться с обучением задаче эффективно из-за недостатка данных.
• Сложно захватывать все попарные взаимодействия признаков из-за большого количества признаков.

Учитывая эти ограничения, NN здесь не используются.

Deep & Cross Network (DCN)

В 2017 году Google предложил архитектуру DCN [6] для автоматического обнаружения взаимодействий признаков. Это решает проблемы ручного метода пересечения признаков. В методе используются две параллельные сети:

• Глубокая сеть (Deep network): обучает сложные и обобщаемые признаки с помощью архитектуры Deep Neural Network (DNN).
• Крест-сеть (Cross network): автоматически захватывает взаимодействия признаков и обучает хорошие пересечения признаков.

Выходы глубокой и крест-сети конкатенируются для получения итогового предсказания.

Существуют два типа архитектур DCN: стековая и параллельная. На рисунке 8.12 показана архитектура параллельной DCN. Подробнее о стековой архитектуре см. [7]. На ML-собеседованиях обычно не ожидается предоставление деталей DCN. Если вас интересует подробное изучение DCN, см. [7][8].

Архитектура DCN эффективнее нейронных сетей, поскольку неявно обучает пересечения признаков. Однако крест-сеть моделирует только определённые взаимодействия признаков, что может негативно сказаться на производительности модели.

Factorization Machines (FM)

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

Рассмотрим, как работает FM. Она автоматически моделирует все попарные взаимодействия признаков, обучая вектор embedding для каждого признака. Взаимодействие между двумя признаками определяется скалярным произведением их embeddings. Рассмотрим формулу для лучшего понимания:

Где xi — i-й признак, wi — обученный вес, а vi — embedding i-го признака. ⟨vi, vj⟩ обозначает скалярное произведение двух embeddings.

Формула может выглядеть сложно, но на самом деле она понятна. Первые два члена вычисляют линейную комбинацию признаков, аналогично логистической регрессии. Третий член моделирует попарные взаимодействия признаков. На рисунке 8.13 показан высокоуровневый обзор FM. Подробнее о деталях FM см. [9].

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

Deep Factorization Machines (DeepFM)

DeepFM — ML-модель, объединяющая преимущества NN и FM. Сеть DNN захватывает сложные признаки высшего порядка, а FM захватывает низкоуровневые попарные взаимодействия признаков. На рисунке 8.14 показана высокоуровневая архитектура DeepFM. Если вас интересует подробное изучение DeepFM, см. [10].

Одно из возможных улучшений — комбинирование GBDT и DeepFM. GBDT преобразует исходные признаки в более предиктивные, а DeepFM работает с новыми признаками. Этот метод побеждал в различных соревнованиях по прогнозированию кликов [11]. Однако добавление GBDT к DeepFM негативно влияет на скорость обучения и вывода, а также замедляет непрерывное обучение.

На практике правильная модель обычно выбирается путём проведения экспериментов. В нашем случае начнём с простой LR для создания базового уровня. Затем проведём эксперименты с DCN и DeepFM, поскольку обе широко используются в технологической индустрии.

Обучение модели

Построение датасета

Для каждого показа рекламы строим новую точку данных. Входные признаки вычисляются на основе пользователя и рекламы. Точке данных присваивается метка по следующей стратегии:

• Положительная метка: если пользователь кликает на рекламу менее чем через t секунд после её показа, точка данных помечается как «положительная». Обратите внимание, что t — гиперпараметр, настраиваемый экспериментально.
• Отрицательная метка: если пользователь не кликает на рекламу менее чем за t секунд, точка данных помечается как «отрицательная».

На практике компании используют более сложные методы для нахождения оптимальной стратегии разметки отрицательных примеров. Подробнее см. [1].

Для поддержания адаптивности модели к новым данным её необходимо непрерывно обучать. В результате новые точки обучающих данных должны непрерывно генерироваться из новых взаимодействий. Непрерывное обучение подробнее обсуждается в разделе обслуживания.

Выбор функции потерь

Поскольку мы обучаем модель бинарной классификации, выбираем кросс-энтропию в качестве функции потерь классификации.

Оценка

Офлайн-метрики

Для оценки системы прогнозирования кликов обычно используются две метрики:

• Кросс-энтропия (CE)
• Нормализованная кросс-энтропия (NCE)

CE. Эта метрика измеряет, насколько предсказанные вероятности модели близки к истинным меткам. CE равна нулю в идеальной системе, которая предсказывает 0 для отрицательных классов и 1 для положительных. Чем ниже CE, тем выше точность предсказания. Формула:

где p — истинное распределение, q — предсказанная вероятность, C — общее количество классов.

Для бинарной классификации формулу CE можно переписать как:

где yi — истинная метка i-й точки данных, а ŷi — предсказанная вероятность i-й точки данных.

Рассмотрим конкретный пример, показанный на рисунке 8.16.

Помимо использования CE как метрики, она также широко применяется как стандартная функция потерь в задачах классификации во время обучения модели.

Нормализованная кросс-энтропия (NCE). NCE — отношение CE нашей модели к CE фонового CTR (среднего CTR в обучающих данных). Иными словами, NCE сравнивает модель с простым базовым уровнем, который всегда предсказывает фоновый CTR. Низкий NCE указывает на то, что модель превосходит простой базовый уровень. NCE ≥ 1 означает, что модель не превосходит простой базовый уровень.

Рассмотрим конкретный пример для лучшего понимания расчёта NCE. Как показано на рисунке 8.17, простая базовая модель всегда предсказывает 0,6 (CTR в обучающих данных). В этом случае NCE равна 0,324 (меньше 1), что указывает на то, что модель A превосходит простой базовый уровень.

Онлайн-метрики

Рассмотрим некоторые метрики для онлайн-оценки:

• CTR
• Коэффициент конверсии
• Прирост выручки
• Частота скрытия рекламы

CTR. Эта метрика измеряет отношение между нажатой рекламой и общим количеством показанных объявлений.

CTR — отличная онлайн-метрика для систем прогнозирования кликов, поскольку максимизация кликов пользователей напрямую связана с ростом дохода.

Коэффициент конверсии. Эта метрика измеряет отношение между количеством конверсий и общим количеством показанных рекламных объявлений.

Эта метрика важна для отслеживания, поскольку показывает, сколько раз рекламодатели фактически извлекали пользу из системы. Это важно, потому что рекламодатели в конечном итоге потеряют интерес и перестанут тратить на рекламу, если их объявления не приводят к конверсиям.

Прирост выручки. Измеряет процентное увеличение дохода со временем.

Частота скрытия рекламы. Эта метрика измеряет отношение между количеством скрытых пользователями объявлений и количеством показанных объявлений.

Эта метрика помогает понять, сколько нерелевантной рекламы система показала пользователям (ложноположительные результаты).

Обслуживание

Во время обслуживания система выдаёт список рекламных объявлений, ранжированных по вероятностям кликов. Предлагаемый дизайн ML-системы показан на рисунке 8.18. Рассмотрим каждый из следующих пайплайнов:

• Пайплайн подготовки данных
• Пайплайн непрерывного обучения
• Пайплайн предсказания

Пайплайн подготовки данных

Пайплайн подготовки данных выполняет две задачи:

1. Вычисление онлайн- и пакетных признаков
2. Непрерывная генерация обучающих данных из новых объявлений и взаимодействий

Для вычисления признаков используются два варианта: пакетное и онлайн-вычисление признаков. Рассмотрим их различия.

Пакетное вычисление признаков Некоторые выбранные признаки статичны, то есть меняются очень редко. Например, изображение и категория рекламы — статические признаки. Этот компонент периодически вычисляет статические признаки (например, каждые несколько дней или недель) с помощью пакетных заданий и сохраняет их в хранилище признаков. Это повышает производительность системы при обслуживании, поскольку признаки предварительно вычислены.

Онлайн-вычисление признаков Некоторые признаки динамичны и часто меняются. Например, количество показов и кликов рекламы — динамические признаки. Эти признаки необходимо вычислять во время запроса, и данный компонент используется для их вычисления.

Пайплайн непрерывного обучения

Согласно требованиям, непрерывное обучение модели является критически важным. Этот пайплайн отвечает за дообучение модели на новых обучающих данных, оценку новой модели и её развёртывание при улучшении метрик. Он обеспечивает, чтобы пайплайн предсказания всегда использовал модель, адаптированную к наиболее актуальным данным.

Пайплайн предсказания

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

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

Затем модель ранжирования получает кандидаты от сервиса генерации кандидатов, ранжирует их по вероятности клика и выдаёт топовые объявления. Этот компонент взаимодействует с тем же хранилищем признаков и компонентом онлайн-вычисления признаков. После получения статических и динамических признаков сервис ранжирования использует модель для получения предсказанной вероятности клика для каждого кандидата. Эти вероятности используются для ранжирования объявлений и вывода тех, у которых наибольшая вероятность клика.

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

Дополнительные темы для обсуждения

Если в конце собеседования осталось время, вот некоторые потенциальные темы для обсуждения:

• В системах ранжирования и рекомендаций важно избегать утечки данных [12][13].
• В системах прогнозирования кликов модель необходимо калибровать. Обсудите калибровку модели и методы калибровки [14].
• Распространённый вариант FM — field-aware Factorization Machine (FFM). Стоит рассказать о FFM и её отличиях от FM [15].
• Распространённый вариант DeepFM — XDeepFM. Расскажите о XDeepFM и его отличиях от DeepFM [10].
• Мы описали, почему непрерывное обучение необходимо для систем прогнозирования кликов. Однако непрерывное обучение на новых данных может привести к катастрофическому забыванию. Обсудите, что такое катастрофическое забывание и каковы распространённые решения [16].

Ссылки

1. Addressing delayed feedback. https://arxiv.org/pdf/1907.06558.pdf.
2. AdTech basics. https://advertising.amazon.com/library/guides/what-is-adtech.
3. SimCLR paper. https://arxiv.org/pdf/2002.05709.pdf.
4. Feature crossing. https://developers.google.com/machine-learning/crash-course/feature-crosses/video-lecture.
5. Feature extraction with GBDT. https://towardsdatascience.com/gradient-boosted-decision-trees-explained-9259bd8205af/.
6. DCN paper. https://arxiv.org/pdf/1708.05123.pdf.
7. DCN V2 paper. https://arxiv.org/pdf/2008.13535.pdf.
8. Microsoft's deep crossing network paper. https://www.kdd.org/kdd2016/papers/files/adf0975-shanA.pdf.
9. Factorization Machines. https://www.jefkine.com/recsys/2017/03/27/factorization-machines/.
10. Deep Factorization Machines. https://d2l.ai/chapter_recommender-systems/deepfm.html.
11. Kaggle's winning solution in ad click prediction. https://www.youtube.com/watch?v=4Go5crRVyuU.
12. Data leakage in ML systems. https://machinelearningmastery.com/data-leakage-machine-learning/.
13. Time-based dataset splitting. https://www.linkedin.com/pulse/time-based-splitting-determining-train-test-data-come-manraj-chalokia/?trk=public_profile_article_view.
14. Model calibration. https://machinelearningmastery.com/calibrated-classification-model-in-scikit-learn/.
15. Field-aware Factorization Machines. https://www.csie.ntu.edu.tw/~cjlin/papers/ffm.pdf.
16. Catastrophic forgetting problem in continual learning. https://www.cs.uic.edu/~liub/lifelong-learning/continual-learning.pdf.

Похожие объявления на платформах аренды жилья

Рекомендация элементов, похожих на те, что пользователь просматривает в данный момент, — ключевая технология, позволяющая людям обнаруживать потенциально релевантный контент на крупных платформах. Например, Airbnb рекомендует похожие объявления об аренде жилья, Amazon — похожие товары, а Expedia — похожие впечатления.

В этой главе мы проектируем функцию «похожие объявления», напоминающую используемые на сайтах аренды жилья вроде Airbnb и Vrbo. Когда пользователь нажимает на конкретное объявление, ему рекомендуется список похожих объявлений.

Уточнение требований

Вот типичное взаимодействие между кандидатом и интервьюером.

Кандидат: Могу я предположить, что бизнес-цель — увеличение числа бронирований? Интервьюер: Да.

Кандидат: Как определяется «похожесть»? Ожидается ли, что рекомендованные объявления похожи на то, которое пользователь просматривает в данный момент? Интервьюер: Да, верно. Два объявления считаются похожими, если они находятся в одном районе, городе, ценовом диапазоне и т.д.

Кандидат: Персонализированы ли рекомендованные объявления для пользователей? Интервьюер: Мы хотим, чтобы эта функция работала как для авторизованных, так и для анонимных пользователей. На практике мы по-разному подходим к двум группам и применяем персонализацию только для авторизованных пользователей. Однако для простоты предположим, что мы одинаково обрабатываем авторизованных и анонимных пользователей.

Кандидат: Сколько объявлений доступно на платформе? Интервьюер: 5 миллионов объявлений.

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

Кандидат: Как долго новые объявления появляются в результатах похожих объявлений? Интервьюер: Предположим, что новые объявления могут появляться в рекомендациях через один день после публикации. За это время система собирает данные о взаимодействиях для новых объявлений.

Подведём итог формулировки задачи. Нас просят спроектировать функцию «похожие объявления» для платформ аренды жилья. Входными данными является конкретное объявление, которое пользователь просматривает в данный момент, а выходными — ранжированный список похожих объявлений, на которые пользователь, вероятно, кликнет. Рекомендации должны быть одинаковыми для анонимных и авторизованных пользователей. На платформе около 5 миллионов объявлений, и новые объявления могут появляться в рекомендациях через один день. Бизнес-цель системы — увеличить число бронирований.

Формулировка задачи как ML-задачи

Определение ML-цели

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

Определение входных и выходных данных системы

Как показано на рисунке 9.2, система «похожие объявления» принимает объявление, которое пользователь просматривает в данный момент, и выдаёт ранжированный список объявлений, отсортированных по вероятности клика.

Выбор подходящей категории ML

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

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

Сессионные системы рекомендаций

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

Как сравнивают сессионные и традиционные системы рекомендаций?

В традиционных системах рекомендаций интересы пользователей контекстно-независимы и не меняются слишком часто. В сессионных системах интересы пользователей динамичны и быстро эволюционируют. Цель традиционной системы рекомендаций — изучить общие интересы пользователей. Напротив, сессионные системы рекомендаций направлены на понимание краткосрочных интересов пользователей на основе их недавней истории просмотра.

Широко используемая техника построения сессионных систем рекомендаций — обучение embeddings элементов на основе их совместного появления в истории просмотра пользователей. Например, Instagram обучает embeddings аккаунтов для функции «Explore» [1], Airbnb обучает embeddings объявлений для функции похожих объявлений [2], а word2vec [3] использует аналогичный подход для обучения значимых word embeddings.

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

Для рекомендации похожих объявлений мы ищем в пространстве embeddings объявления, ближайшие к просматриваемому. Рассмотрим пример. На рисунке 9.4 каждое объявление отображено в 2D-пространство. Для рекомендации похожих объявлений для Lt выбираем топ-3 объявления с наиближайшими embeddings.

Подготовка данных

Инженерия данных

Доступны следующие данные:

• Пользователи
• Объявления
• Взаимодействия пользователей с объявлениями

Пользователи

Упрощённая схема данных о пользователях показана ниже.

Таблица 9.1: Схема данных о пользователях

Объявления

Данные об объявлениях содержат атрибуты каждого объявления: цену, количество кроватей, ID хозяина и т.д. В таблице 9.2 показан простой пример данных об объявлениях.

Таблица 9.2: Данные об объявлениях

Взаимодействия пользователей с объявлениями

В таблице 9.3 хранятся взаимодействия пользователей с объявлениями: показы, клики и бронирования.

Таблица 9.3: Данные о взаимодействиях пользователей с объявлениями

Инженерия признаков

Как описано в разделе «Формулировка задачи как ML-задачи», модель использует только историю просмотра пользователей во время обучения. Другая информация не используется: цена объявления, возраст пользователя и т.д.

В этой главе история просмотра называется «поисковыми сессиями». Поисковая сессия — последовательность ID нажатых объявлений, завершающаяся в итоге забронированным объявлением, без прерываний. На рисунке 9.5 показан пример поисковой сессии: сессия пользователя началась, когда пользователь нажал на L1, и завершилась, когда пользователь в итоге забронировал L20.

На этапе инженерии признаков мы извлекаем поисковые сессии из данных о взаимодействиях. В таблице 9.4 показан простой пример поисковых сессий.

Таблица 9.4: Данные поисковых сессий

Разработка модели

Выбор модели

Нейронная сеть — стандартный метод для обучения embeddings. Выбор хорошей архитектуры зависит от различных факторов: сложности задачи, объёма обучающих данных и т.д. Один из распространённых способов выбора гиперпараметров нейронной сети — запуск экспериментов и выбор архитектуры с наилучшим результатом. В нашем случае выбираем неглубокую нейросетевую архитектуру для обучения embeddings объявлений.

Обучение модели

Как показано на рисунке 9.6, для заданного входного объявления задача модели — предсказать объявления в контексте входного объявления.

Процесс обучения начинается с инициализации embeddings объявлений случайными векторами. Эти embeddings постепенно обучаются путём чтения поисковых сессий с использованием метода скользящего окна. По мере скольжения окна embedding центрального объявления в окне обновляется, чтобы быть похожим на embeddings других объявлений в окне, и непохожим на объявления за пределами окна. Затем модель использует эти embeddings для предсказания контекста данного объявления.

Для адаптации модели к новым объявлениям мы обучаем её ежедневно на вновь построенных обучающих данных.

Построение датасета

Существуют разные способы построения датасета. В нашем случае мы выбираем технику «негативной выборки» (negative sampling) [4], широко используемую для обучения embeddings.

Для построения обучающих данных мы создаём положительные и отрицательные пары из поисковых сессий. Положительные пары — объявления, у которых ожидаются похожие embeddings, отрицательные пары — объявления с непохожими embeddings.

Точнее, для каждой сессии мы читаем объявления методом скользящего окна. По мере скольжения окна мы используем центральное объявление в окне и его контекстные объявления для создания положительных пар. Центральное объявление и случайно выбранные объявления образуют отрицательные пары. Положительные пары получают метку 1, отрицательные — метку 0.

На рисунке 9.7 показано, как положительные и отрицательные пары генерируются скольжением по поисковой сессии.

Выбор функции потерь

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

1. Вычислить расстояние (например, скалярное произведение) между двумя embeddings.
2. Использовать функцию Sigmoid для преобразования вычисленного расстояния в значение вероятности от 0 до 1.
3. Использовать кросс-энтропию как стандартные потери классификации для измерения потерь между предсказанной вероятностью и истинной меткой.

На рисунке 9.8 показаны шаги расчёта потерь.

Потери могут быть представлены следующей формулой:

Где:

• c — центральное объявление, p — положительное объявление (совместно появляющееся с c в контексте), n — отрицательное объявление (не совместно появляющееся с c)
• Ec представляет вектор embedding центрального объявления c
• En представляет вектор embedding отрицательного объявления n
• Ep представляет вектор embedding положительного объявления p
• Dp — положительное множество пар ⟨c, p⟩, представляющих кортежи (центральное объявление, контекстное объявление), векторы которых сближаются
• Dn — отрицательное множество пар ⟨c, n⟩, представляющих кортежи (центральное объявление, случайное объявление), векторы которых отталкиваются

Первое суммирование вычисляет потери по положительным парам, второе — по отрицательным.

Можно ли улучшить функцию потерь для обучения лучших embeddings?

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

Во-вторых, отрицательные пары, генерируемые ранее, в основном состоят из объявлений из разных регионов, поскольку они выбираются случайным образом. Однако пользователи обычно ищут только в определённом регионе, например в Сан-Франциско. Это может привести к embeddings, плохо работающим для объявлений из одного региона: тех, что не встречаются совместно в контексте, но находятся в том же регионе.

Устраним эти недостатки.

Использование в итоге забронированного объявления как глобального контекста Для обучения embeddings, хорошо предсказывающих в итоге забронированные объявления, мы обрабатываем в итоге забронированное объявление как глобальный контекст во время обучения. По мере скольжения окна некоторые объявления входят или выходят из контекстного множества, тогда как в итоге забронированное объявление всегда остаётся в глобальном контексте и используется для обновления вектора центрального объявления.

Для использования в итоге забронированного объявления как глобального контекста при обучении мы добавляем пары ⟨центральное объявление, в итоге забронированное объявление⟩ в обучающие данные и помечаем их как положительные. Это заставляет модель сближать embedding в итоге забронированного объявления с каждым из нажатых объявлений в сессии во время обучения, как показано на рисунке 9.9.

Добавление отрицательных пар из того же региона в обучающие данные

По мере скольжения окна мы выбираем объявление из того же района, что и центральное, которое не входит в контекст центрального объявления. Мы помечаем пару как отрицательную и добавляем в обучающие данные. Рассмотрим обновлённую функцию потерь, учитывающую вновь добавленные обучающие данные.

Где:

• Eb представляет вектор embedding в итоге забронированного объявления b
• Dbooked — пары ⟨c, b⟩, представляющие кортежи (центральное объявление, забронированное объявление), векторы которых сближаются
• Dhard — сложные отрицательные пары ⟨c, n⟩, представляющие кортежи (центральное объявление, отрицательное объявление из того же региона), векторы которых отталкиваются

Первые два суммирования мы объясняли ранее. Третье суммирование вычисляет потери по вновь добавленным положительным парам, содержащим глобальный контекст. Оно помогает модели сближать embeddings центральных объявлений с embeddings в итоге забронированных объявлений.

Четвёртое суммирование вычисляет потери по вновь добавленным отрицательным парам из того же региона. Оно заставляет модель отталкивать их embeddings друг от друга.

Оценка

Офлайн-метрики

На этапе разработки модели офлайн-метрики используются для измерения качества выходных данных модели и сравнения новых моделей со старыми. Один из способов оценки обученных embeddings — проверить, насколько хорошо они предсказывают в итоге забронированное объявление, исходя из последнего клика пользователя. Создадим метрику «средний ранг в итоге забронированного объявления» и обсудим её подробнее.

Средний ранг в итоге забронированного объявления. Рассмотрим пример. На рисунке 9.10 показана поисковая сессия пользователя, состоящая из семи объявлений. Первое — то, которое пользователь просмотрел первым (L0). Следующие пять — объявления, последовательно нажатые пользователем. Последнее (L6) — объявление, которое пользователь в итоге забронировал.

Мы используем модель для вычисления сходства между первым нажатым объявлением и другими объявлениями в пространстве embeddings. После вычисления сходства объявления ранжируются. Позиция в итоге забронированного объявления показывает, насколько высоко в ранжировании новая модель могла бы порекомендовать его (L6). Как видно на рисунке 9.10, новая модель (вторая строка) смогла поставить в итоге забронированное объявление (L6) на второе место.

Если модель ставит в итоге забронированное объявление на высокую позицию, это означает, что обученные embeddings способны помещать забронированное объявление раньше в рекомендательном списке. Мы усредняем ранг в итоге забронированных объявлений по всем сессиям в валидационном датасете для вычисления значения этой метрики.

Онлайн-метрики

Согласно требованиям, бизнес-цель — увеличение числа бронирований. Вот некоторые варианты онлайн-метрик:

• Click-through rate (CTR)
• Частота бронирования сессии

CTR. Показатель, отражающий, как часто люди, видящие рекомендованные объявления, в итоге кликают на них.

Эта метрика используется для измерения вовлечённости пользователей. Например, когда пользователи чаще кликают на объявления, повышается вероятность того, что некоторые нажатые объявления приведут к бронированию. Но поскольку CTR не измеряет фактическое число бронирований на платформе, мы дополняем его метрикой «частота бронирования сессии».

Частота бронирования сессии. Показатель, отражающий, какая доля поисковых сессий завершается бронированием.

Эта метрика напрямую связана с бизнес-целью — увеличением числа бронирований. Чем выше «частота бронирования сессии», тем больший доход генерирует платформа.

Обслуживание

Во время обслуживания система рекомендует объявления, похожие на то, которое пользователь просматривает в данный момент. На рисунке 9.11 показан обзор дизайна ML-системы.

Рассмотрим основные компоненты подробно.

Пайплайн обучения

Пайплайн обучения дообучает модель с использованием новых объявлений и взаимодействий. Это обеспечивает постоянную адаптацию модели к новым взаимодействиям и объявлениям.

Пайплайн индексирования

С обученной моделью embeddings всех объявлений на платформе могут быть предварительно вычислены и сохранены в индексной таблице. Это значительно ускоряет пайплайн предсказания.

Пайплайн индексирования создаёт и поддерживает индексную таблицу. Например, когда становится доступным новый embedding объявления, пайплайн добавляет его в индексную таблицу. Кроме того, когда становится доступной вновь обученная модель, пайплайн перевычисляет все embeddings с использованием новой модели и обновляет индексную таблицу.

Пайплайн предсказания

Пайплайн предсказания рекомендует похожие объявления на то, которое пользователь просматривает в данный момент. Пайплайн предсказания, как показано на рисунке 9.11, состоит из:

• Сервиса получения embeddings
• Сервиса ближайших соседей
• Сервиса повторного ранжирования

Рассмотрим каждый компонент.

Сервис получения embeddings

Этот сервис принимает просматриваемое объявление как входные данные и работает по-разному в зависимости от того, видела ли модель это объявление во время обучения.

Входное объявление встречалось модели при обучении

Если объявление встречалось при обучении, его вектор embedding уже обучен и доступен в индексной таблице. В этом случае сервис получения embeddings напрямую извлекает embedding объявления из индексной таблицы.

Входное объявление не встречалось модели при обучении

Если входное объявление новое, модель его не видела при обучении. Это проблематично, поскольку без embedding данного объявления невозможно найти похожие.

Для решения этой проблемы сервис получения embeddings использует эвристики для обработки новых объявлений. Например, можно использовать embedding географически близкого объявления, когда объявление новое. Когда для нового объявления накопится достаточно данных о взаимодействиях, пайплайн обучения узнает его embedding путём дообучения модели.

Сервис ближайших соседей

Для рекомендации похожих объявлений необходимо вычислить сходство между embedding просматриваемого объявления и embeddings других объявлений на платформе. Здесь на помощь приходит сервис ближайших соседей. Этот сервис вычисляет сходства и выдаёт ближайшие по embedding объявления.

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

Сервис повторного ранжирования

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

Дополнительные темы для обсуждения

Если в конце собеседования осталось время, вот некоторые дополнительные темы для обсуждения:

• Что такое позиционное смещение (positional bias) и как с ним бороться [5].
• Как сессионный подход сравнивается со случайным блужданием [6] и как случайное блуждание с перезапуском (RWR) может использоваться для рекомендации похожих объявлений [7].
• Как персонализировать результаты сессионной системы рекомендаций с учётом долгосрочных интересов пользователей (персонализация внутри сессии) [2].
• Учитывая, что сезонность сильно влияет на аренду жилья, как следует включать сезонность в систему похожих объявлений [8].

Ссылки

1. Instagram's Explore recommender system. https://ai.facebook.com/blog/powered-by-ai-instagrams-explore-recommender-system.
2. Listing embeddings in search ranking. https://medium.com/airbnb-engineering/listing-embeddings-for-similar-listing-recommendations-and-real-time-personalization-in-search-601172f7603e.
3. Word2vec. https://en.wikipedia.org/wiki/Word2vec.
4. Negative sampling technique. https://www.baeldung.com/cs/nlps-word2vec-negative-sampling.
5. Positional bias. https://eugeneyan.com/writing/position-bias/.
6. Random walk. https://en.wikipedia.org/wiki/Random_walk.
7. Random walk with restarts. https://www.youtube.com/watch?v=HbzQzUaJ_9I.
8. Seasonality in recommendation systems. https://www.computer.org/csdl/proceedings-article/big-data/2019/09005954/1hJsfgT0qL6.

Персонализированная лента новостей

Введение

Лента новостей — функция платформ социальных сетей, которая удерживает пользователей, показывая им последние активности друзей в их лентах. Большинство социальных сетей, таких как Facebook [1], Twitter [2] и LinkedIn [3], персонализируют ленту новостей для поддержания вовлечённости пользователей.

В этой главе нас просят спроектировать систему персонализированной ленты новостей.

Уточнение требований

Вот типичное взаимодействие между кандидатом и интервьюером.

Кандидат: Могу я предположить, что мотивация для персонализированной ленты новостей — удержание пользователей на платформе? Интервьюер: Да, мы размещаем спонсорскую рекламу между публикациями, и большая вовлечённость ведёт к росту дохода.

Кандидат: Когда пользователь обновляет ленту, мы показываем ему публикации с новыми активностями. Могу я предположить, что эта активность включает как непросмотренные публикации, так и публикации с непросмотренными комментариями? Интервьюер: Это разумное предположение.

Кандидат: Может ли публикация содержать текст, изображения, видео или их комбинацию? Интервьюер: Может быть любая комбинация.

Кандидат: Для удержания пользователей система должна размещать наиболее интересный контент вверху ленты, поскольку пользователи с большей вероятностью взаимодействуют с первыми публикациями. Это верно? Интервьюер: Да, верно.

Кандидат: Есть ли конкретный тип вовлечённости, который мы оптимизируем? Предполагаю, что существуют разные типы вовлечённости: клики, лайки, репосты. Интервьюер: Хороший вопрос. Разные реакции имеют разную ценность на нашей платформе. Например, лайк публикации ценнее простого клика на неё. Идеально, если система при ранжировании учитывает основные реакции. Предоставлю вам возможность самостоятельно определить «вовлечённость» и выбрать, что оптимизировать модели.

Кандидат: Какие основные реакции доступны на платформе? Предполагаю, что пользователи могут кликать, лайкать, делиться, комментировать, скрывать, блокировать другого пользователя и отправлять запросы на подключение. Есть ли другие реакции, которые нужно учитывать? Интервьюер: Вы перечислили основные. Сосредоточимся на них.

Кандидат: Насколько быстро должна работать система? Интервьюер: Мы ожидаем, что система отобразит ранжированные публикации быстро после того, как пользователи обновят ленту или откроют приложение. Если это займёт слишком долго, пользователи заскучают и уйдут. Предположим, что система должна отображать ранжированные публикации менее чем за 200 миллисекунд (мс).

Кандидат: Сколько у нас ежедневных активных пользователей? Сколько обновлений ленты мы ожидаем ежедневно? Интервьюер: Всего у нас почти 3 миллиарда пользователей. Около 2 миллиардов — ежедневно активные пользователи, проверяющие ленту дважды в день.

Подведём итог формулировки задачи. Нас просят спроектировать систему персонализированной ленты новостей. Система извлекает непросмотренные публикации или публикации с непросмотренными комментариями и ранжирует их по степени интереса для пользователя. Это должно занимать не более 200 мс. Цель системы — повысить вовлечённость пользователей.

Формулировка задачи как ML-задачи

Определение ML-цели

Рассмотрим три возможные ML-цели:

• Максимизация числа определённых неявных реакций, таких как время просмотра (dwell time) или клики
• Максимизация числа определённых явных реакций, таких как лайки или репосты
• Максимизация взвешенной оценки на основе как неявных, так и явных реакций

Обсудим каждый вариант подробнее.

Вариант 1: Максимизация числа определённых неявных реакций, таких как dwell time или клики В этом варианте мы выбираем неявные сигналы как косвенный показатель вовлечённости пользователей. Например, оптимизируем ML-систему для максимизации кликов.

Преимущество: у нас больше данных о неявных реакциях, чем о явных. Больший объём обучающих данных обычно ведёт к более точным моделям.

Недостаток: неявные реакции не всегда отражают реальное мнение пользователя о публикации. Например, пользователь может кликнуть на публикацию, но не счесть её стоящей для прочтения.

Вариант 2: Максимизация числа определённых явных реакций, таких как лайки, репосты и скрытие

В этом варианте мы выбираем явные реакции как косвенный показатель мнений пользователей о публикации.

Преимущество: явные сигналы обычно весомее неявных. Например, лайк публикации отправляет более сильный сигнал вовлечённости, чем простой клик.

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

Вариант 3: Максимизация взвешенной оценки на основе как неявных, так и явных реакций

В этом варианте мы используем как неявные, так и явные реакции для определения вовлечённости пользователя с публикацией. В частности, мы назначаем вес каждой реакции исходя из её ценности. Затем оптимизируем ML-систему для максимизации взвешенной оценки реакций.

В таблице 10.1 показано соответствие между различными реакциями и весами. Как видно, нажатие кнопки «лайк» весомее клика, а репост ценнее лайка. Кроме того, негативные реакции — скрытие и блокировка — имеют отрицательный вес. Обратите внимание, что эти веса могут быть выбраны исходя из бизнес-потребностей.

Таблица 10.1: Веса различных реакций

Какой вариант выбрать?

Мы выбираем итоговый смешанный вариант, поскольку он позволяет назначать разные веса разным реакциям. Это важно, так как мы можем оптимизировать систему в соответствии с приоритетами бизнеса.

Определение входных и выходных данных системы

Как показано на рисунке 10.2, система персонализированной ленты новостей принимает пользователя как входные данные и выдаёт ранжированный список непросмотренных публикаций или публикаций с непросмотренными комментариями, отсортированных по оценке вовлечённости.

Выбор подходящей категории ML

Система персонализированной ленты новостей формирует ранжированный список публикаций исходя из их интереса для пользователя. Точечный Learning to Rank (LTR) — простой, но эффективный подход, персонализирующий ленту новостей путём ранжирования публикаций по оценкам вовлечённости. Чтобы понять, как вычисляются оценки вовлечённости между пользователями и публикациями, рассмотрим конкретный пример.

Как показано на рисунке 10.3, мы применяем несколько бинарных классификаторов для предсказания вероятностей различных неявных и явных реакций для пары ⟨пользователь, публикация⟩.

После предсказания этих вероятностей вычисляем оценку вовлечённости. На рисунке 10.4 показан пример расчёта оценки вовлечённости.

Рисунок 10.4: Вычисление оценки вовлечённости

Подготовка данных

Инженерия данных

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

• Пользователи
• Публикации
• Взаимодействия пользователей с публикациями
• Дружба

Пользователи

Схема данных о пользователях показана ниже.

Таблица 10.2: Схема данных о пользователях

Публикации

В таблице 10.3 показаны данные о публикациях.

Таблица 10.3: Данные о публикациях

Взаимодействия пользователей с публикациями

В таблице 10.4 показаны данные о взаимодействиях пользователей с публикациями.

Таблица 10.4: Данные о взаимодействиях пользователей с публикациями

Дружба

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

Таблица 10.5: Данные о дружбе

Инженерия признаков

В этом разделе мы создаём предиктивные признаки и подготавливаем их для модели. В частности, строим признаки из каждой из следующих категорий:

• Признаки публикаций
• Признаки пользователей
• Сходство пользователя с автором

Признаки публикаций

На практике каждая публикация имеет много атрибутов. Мы не можем охватить всё, поэтому обсуждаем только наиболее важные.

• Текстовый контент
• Изображения или видео
• Реакции
• Хэштеги
• Возраст публикации

Текстовый контент

Что это? Текстовый контент — основное тело публикации.

Почему это важно? Текстовый контент помогает определить, о чём публикация.

Как подготовить? Мы предобрабатываем текстовый контент и используем предобученную языковую модель для преобразования текста в числовой вектор. Поскольку текстовый контент обычно представлен предложениями, а не отдельными словами, используем контекстно-зависимую языковую модель — BERT [4].

Изображения или видео

Что это? Публикация может содержать изображения или видео.

Почему это важно? Из изображений можно извлекать важные сигналы. Например, изображение оружия может указывать на то, что публикация небезопасна для детей.

Как подготовить? Сначала предобрабатываем изображения или видео. Затем используем предобученную модель для преобразования неструктурированных данных изображения/видео в вектор embedding. Например, можно использовать ResNet [5] или недавно представленную модель CLIP [6] как предобученную модель.

Реакции

Что это? Это количество лайков, репостов, ответов и т.д. для публикации.

Почему это важно? Количество лайков, репостов, скрытий и т.д. указывает на то, насколько интересной пользователи считают публикацию. Пользователь с большей вероятностью будет взаимодействовать с публикацией с тысячами лайков, чем с публикацией с десятью лайками.

Как подготовить? Эти значения представлены числовыми значениями. Мы масштабируем их для приведения в схожий диапазон.

Хэштеги

Почему это важно? Пользователи используют хэштеги для группировки контента по определённой теме. Хэштеги представляют темы, к которым относится публикация. Например, публикация с хэштегом «#women_in_tech» указывает на контент, связанный с технологиями и женщинами, поэтому модель может принять решение ранжировать её выше для людей, интересующихся технологиями.

Как подготовить? Подробные шаги предобработки текста уже объяснены в главе 4, «Поиск видео на YouTube», поэтому здесь остановимся только на уникальных шагах для подготовки хэштегов.

• Токенизация: хэштеги вроде «lifeisgood» или «programmer_lifestyle» содержат несколько слов. Для токенизации хэштегов используем алгоритмы вроде Viterbi [7]. Например, «lifeisgood» разбивается на 3 слова: «life», «is», «good».
• Токены в ID: хэштеги в социальных сетях быстро эволюционируют и меняются по мере появления новых трендов. Техника хеширования признаков хорошо подходит, поскольку способна присваивать индексы неизвестным хэштегам.
• Векторизация: используем простые методы текстового представления, такие как TF-IDF [8] или word2vec [9], вместо Transformer-based моделей для векторизации хэштегов. Объясним почему. Transformer-based модели полезны, когда контекст данных имеет существенное значение. В случае хэштегов каждый из них обычно представляет собой одно слово или фразу, и для понимания значения хэштега контекст зачастую не нужен. Поэтому предпочтительны более быстрые и лёгкие методы текстового представления.

Возраст публикации

Что это? Этот признак показывает, сколько времени прошло с момента публикации автором.

Почему это важно? Пользователи склонны взаимодействовать с более свежим контентом.

Как подготовить? Разбиваем возраст публикации на несколько категорий и используем one-hot encoding. Например:

• 0: менее 1 часа
• 1: от 1 до 5 часов
• 2: от 5 до 24 часов
• 3: от 1 до 7 дней
• 4: от 7 до 30 дней
• 5: более месяца

Признаки пользователей

Некоторые из наиболее важных признаков, связанных с пользователем:

• Демография: возраст, пол, страна и т.д.
• Контекстная информация: устройство, время суток и т.д.
• Историческая история взаимодействий пользователя с публикациями
• Упоминание пользователя в публикации

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

Историческая история взаимодействий пользователя с публикациями

Все публикации, на которые пользователь поставил лайк, представлены списком ID публикаций. Та же логика применяется к репостам и комментариям.

Почему это важно? Предыдущие взаимодействия пользователей обычно помогают определить их будущую вовлечённость.

Как подготовить? Извлечь признаки из каждой публикации, с которой пользователь взаимодействовал.

Упоминание в публикации

Что это? Упоминание пользователя в публикации. Почему это важно? Пользователи обычно уделяют больше внимания публикациям, в которых их упоминают.

Как подготовить? Этот признак представлен бинарным значением. Если пользователь упомянут в публикации — признак равен 1, иначе 0.

На рисунке 10.6 представлена сводка подготовки признаков пользователей.

Сходство пользователя с автором

Согласно исследованиям, признаки сходства (affinity), такие как связь между пользователем и автором, являются одними из наиболее важных факторов в предсказании вовлечённости пользователей на Facebook [10]. Создадим несколько признаков для отражения сходства пользователя с автором.

Частота лайков/кликов/комментариев/репостов

Частота, с которой пользователь реагировал на предыдущие публикации автора. Например, частота лайков 0,95 означает, что пользователь ставил лайки публикациям данного автора в 95% случаев.

Продолжительность дружбы

Количество дней, в течение которых пользователь и автор дружат на платформе. Этот признак можно получить из данных о дружбе.

Почему это важно? Пользователи склонны больше взаимодействовать со своими друзьями.

Близкие друзья и члены семьи

Бинарное значение, показывающее, включили ли пользователь и автор друг друга в список близких друзей и членов семьи.

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

Разработка модели

Выбор модели

Выбираем нейронные сети по следующим причинам:

• Нейронные сети хорошо работают с неструктурированными данными, такими как текст и изображения.
• Нейронные сети позволяют использовать слои embeddings для представления категориальных признаков.
• С архитектурой нейронных сетей можно дообучать предобученные модели, используемые при инженерии признаков. Это невозможно с другими моделями.

Перед обучением нейронной сети необходимо выбрать её архитектуру. Есть два архитектурных варианта для построения и обучения нейронных сетей:

• N независимых DNN
• Многозадачная DNN

Рассмотрим каждый вариант.

Вариант 1: N независимых DNN В этом варианте используем N независимых глубоких нейронных сетей (DNN), по одной на каждую реакцию. Это показано на рисунке 10.8.

У этого варианта два недостатка:

• Затратное обучение. Обучение нескольких независимых DNN требует больших вычислительных ресурсов и времени.
• Для менее частых реакций может не хватить обучающих данных. Это означает, что система не способна точно предсказывать вероятности редких реакций.

Вариант 2: Многозадачная DNN Для преодоления этих проблем используем подход многозадачного обучения (рисунок 10.9).

Многозадачное обучение мы объясняли в главе 5, «Обнаружение вредоносного контента», поэтому здесь лишь кратко его упомянем. В целом многозадачное обучение — это процесс одновременного обучения нескольким задачам. Это позволяет модели обучаться сходствам между задачами и избегать ненужных вычислений. Для многозадачной нейросетевой модели важно выбрать подходящую архитектуру. Выбор архитектуры и связанных гиперпараметров обычно определяется путём экспериментов: обучения и оценки модели на разных архитектурах с выбором наилучшей.

Улучшение архитектуры DNN для пассивных пользователей

До сих пор мы использовали DNN для предсказания реакций: репостов, лайков, кликов и комментариев. Однако многие пользователи используют платформу пассивно: они мало взаимодействуют с контентом в своей ленте. Для таких пользователей текущая модель DNN будет предсказывать очень низкие вероятности для всех реакций, поскольку они редко реагируют на публикации. Поэтому необходимо изменить архитектуру DNN для учёта пассивных пользователей.

Для этого добавляем две неявные реакции к списку задач:

• Dwell-time: время, которое пользователь проводит на публикации.
• Пропуск (Skip): если пользователь проводит на публикации менее t секунд (например, 0,5 секунды), предполагается, что пользователь пропустил её.

На рисунке 10.10 показана многозадачная модель DNN с дополнительными задачами.

Обучение модели

Построение датасета

На этом шаге строим датасет из исходных данных. Поскольку модель DNN должна обучаться нескольким задачам, для каждой из них создаются положительные и отрицательные точки данных (например, клики, лайки и т.д.).

Используем тип реакции «лайк» в качестве примера для объяснения создания положительных/отрицательных точек данных. Каждый раз, когда пользователь ставит лайк публикации, добавляем точку данных в датасет, вычисляем признаки ⟨пользователь, публикация⟩ и помечаем её как положительную.

Для создания отрицательных точек данных выбираем показы, не приведшие к реакции «лайк». Обратите внимание, что количество отрицательных точек обычно значительно превышает положительные. Для избежания несбалансированного датасета создаём отрицательные точки данных в количестве, равном положительным. На рисунке 10.11 показаны положительные и отрицательные точки данных для реакции «лайк».

Тот же процесс можно использовать для создания положительных и отрицательных меток для других реакций. Однако поскольку dwell-time — задача регрессии, она строится иначе. Как показано на рисунке 10.12, истинная метка — это dwell-time показа.

Выбор функции потерь

Многозадачные модели обучаются одновременно нескольким задачам. Это означает, что необходимо вычислять потери для каждой задачи отдельно, а затем объединять их для получения общих потерь. Обычно для каждой задачи определяется функция потерь в зависимости от категории ML. В нашем случае используем бинарную кросс-энтропию для каждой задачи бинарной классификации и функцию потерь регрессии — MAE [11], MSE [12] или потери Хьюбера [13] — для задачи регрессии (предсказание dwell-time). Общие потери вычисляются объединением задача-специфичных потерь, как показано на рисунке 10.13.

Оценка

Офлайн-метрики

При офлайн-оценке измеряем производительность модели в предсказании различных реакций. Для оценки отдельного типа реакции можно использовать метрики бинарной классификации: precision и recall. Однако этих метрик в отдельности может быть недостаточно для понимания общей производительности модели бинарной классификации. Поэтому используем ROC-кривую для понимания компромисса между долей верных положительных результатов и долей ложных положительных. Кроме того, вычисляем площадь под ROC-кривой (ROC-AUC) для обобщения производительности бинарной классификации числовым значением.

Онлайн-метрики

Используем следующие метрики для измерения вовлечённости пользователей с разных сторон:

• Click-through rate (CTR)
• Частота реакций
• Общее время, проведённое на платформе
• Уровень удовлетворённости пользователей по результатам опроса

CTR. Отношение числа кликов к числу показов.

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

Частота реакций. Набор метрик, отражающих реакции пользователей. Например, частота лайков измеряет отношение между публикациями с лайком и общим числом публикаций, отображённых в лентах пользователей.

Аналогично отслеживаем другие реакции: «частота репостов», «частота комментариев», «частота скрытий», «частота блокировок» и «частота пропусков». Это более сильные сигналы, чем CTR, поскольку пользователи явно выразили предпочтение.

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

Общее время, проведённое на платформе. Общее время, которое пользователи проводят в ленте за фиксированный период, например 1 неделю. Эта метрика измеряет общую вовлечённость как пассивных, так и активных пользователей.

Уровень удовлетворённости пользователей по результатам опроса. Другой способ измерения эффективности системы персонализированной ленты — явно спросить пользователей об их мнении о ленте или об интересности публикаций. Поскольку мы ищем явную обратную связь, это точный способ измерить эффективность системы.

Обслуживание

Во время обслуживания система отвечает на запросы, выдавая ранжированный список публикаций. На рисунке 10.14 показана архитектурная схема системы персонализированной ленты новостей. Система включает следующие пайплайны:

• Пайплайн подготовки данных
• Пайплайн предсказания

Пайплайн подготовки данных мы не рассматриваем подробно, поскольку он очень похож на описанный в главе 8, «Прогнозирование кликов по рекламе в социальных сетях». Рассмотрим пайплайн предсказания.

Пайплайн предсказания

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

Сервис извлечения

Этот компонент извлекает публикации, которые пользователь не видел, или те, у которых есть непросмотренные им комментарии. Подробнее об эффективном получении непросмотренных публикаций см. [14].

Сервис ранжирования

Этот компонент ранжирует извлечённые публикации, назначая каждой оценку вовлечённости.

Сервис повторного ранжирования

Этот сервис изменяет список публикаций, добавляя дополнительную логику и пользовательские фильтры. Например, если пользователь явно выразил интерес к определённой теме, такой как футбол, этот сервис назначает более высокий ранг соответствующей публикации.

Дополнительные темы для обсуждения

Если в конце собеседования осталось время, вот некоторые дополнительные темы для обсуждения:

• Как обрабатывать публикации, которые становятся вирусными [15].
• Как персонализировать ленту новостей для новых пользователей [16].
• Как смягчить позиционное смещение, присутствующее в системе [17].
• Как определить оптимальную частоту переобучения [18].

Ссылки

1. News Feed ranking in Facebook. https://engineering.fb.com/2021/01/26/ml-applications/news-feed-ranking/.
2. Twitter's news feed system. https://blog.twitter.com/engineering/en_us/topics/insights/2017/using-deep-learning-at-scale-in-twitters-timelines.
3. LinkedIn's News Feed system LinkedIn. https://engineering.linkedin.com/blog/2020/understanding-feed-dwell-time.
4. BERT paper. https://arxiv.org/pdf/1810.04805.pdf.
5. ResNet model. https://arxiv.org/pdf/1512.03385.pdf.
6. CLIP model. https://openai.com/blog/clip/.
7. Viterbi algorithm. https://en.wikipedia.org/wiki/Viterbi_algorithm.
8. TF-IDF. https://en.wikipedia.org/wiki/Tf%E2%80%93idf.
9. Word2vec. https://en.wikipedia.org/wiki/Word2vec.
10. Serving a billion personalized news feed. https://www.youtube.com/watch?v=Xpx5RYNTQvg.
11. Mean absolute error loss. https://en.wikipedia.org/wiki/Mean_absolute_error.
12. Means squared error loss. https://en.wikipedia.org/wiki/Mean_squared_error.
13. Huber loss. https://en.wikipedia.org/wiki/Huber_loss.
14. A news feed system design. https://liuzhenglaichn.gitbook.io/system-design/news-feed/design-a-news-feed-system.
15. Predict viral tweets. https://towardsdatascience.com/using-data-science-to-predict-viral-tweets-615b0acc2e1e.
16. Cold start problem in recommendation systems. https://en.wikipedia.org/wiki/Cold_start_(recommender_systems).
17. Positional bias. https://eugeneyan.com/writing/position-bias/.
18. Determine retraining frequency. https://huyenchip.com/2022/01/02/real-time-machine-learning-challenges-and-solutions.html#towards-continual-learning.

Люди, которых вы можете знать

Введение

«Люди, которых вы можете знать» (PYMK) — список пользователей, с которыми вы, возможно, захотите установить контакт, основываясь на том, что у вас общего: общие друзья, школа или место работы. Многие социальные сети, такие как Facebook, LinkedIn и Twitter, используют ML для реализации функционала PYMK.

В этой главе мы спроектируем функцию PYMK, аналогичную LinkedIn. Система принимает пользователя как входные данные и рекомендует список потенциальных контактов.

Уточнение требований

Вот типичное взаимодействие между кандидатом и интервьюером.

Кандидат: Могу я предположить, что мотивация создания функции PYMK — помочь пользователям обнаруживать потенциальные контакты и расширять свою сеть? Интервьюер: Да, это хорошее предположение.

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

Кандидат: На LinkedIn два человека являются друзьями тогда и только тогда, когда каждый из них является другом другого. Верно? Интервьюер: Да, дружба симметрична. Когда кто-то отправляет запрос на подключение другому пользователю, получатель должен принять запрос для установки контакта.

Кандидат: Каково общее число пользователей на платформе? Сколько из них — ежедневно активные? Интервьюер: У нас почти 1 миллиард пользователей и 300 миллионов ежедневно активных.

Кандидат: Сколько контактов в среднем у одного пользователя? Интервьюер: 1 000 контактов.

Кандидат: Социальный граф большинства пользователей не очень динамичен: их контакты не меняются существенно за короткое время. Могу я использовать это предположение при проектировании PYMK? Интервьюер: Отличное замечание. Да, это разумное предположение.

Подведём итог формулировки задачи. Нас просят спроектировать систему PYMK, аналогичную LinkedIn. Система принимает пользователя как входные данные и рекомендует ранжированный список потенциальных контактов. Мотивация — дать пользователям возможность легче обнаруживать новые контакты и расширять свои сети. На платформе 1 миллиард пользователей, и у пользователя в среднем 1 000 контактов.

Формулировка задачи как ML-задачи

Определение ML-цели

Распространённая ML-цель в системах PYMK — максимизация числа установленных контактов между пользователями. Это помогает пользователям быстро расширять свои сети.

Определение входных и выходных данных системы

Входными данными системы PYMK является пользователь, а выходными — список контактов, ранжированных по релевантности. Это показано на рисунке 11.2.

Выбор подходящей категории ML

Рассмотрим два подхода, обычно используемых для построения PYMK: точечный Learning to Rank (LTR) и предсказание рёбер.

Точечный LTR

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

Однако этот подход имеет существенный недостаток: поскольку входными данными модели являются два отдельных пользователя, он не учитывает доступный социальный контекст. Хотя это упрощает задачу, исключение информации о связях пользователя может снизить точность предсказаний.

Рассмотрим пример, показывающий, как социальный контекст может предоставлять важные инсайты. Предположим, мы хотим предсказать, является ли ⟨пользователь A, пользователь B⟩ потенциальным контактом.

Рассматривая их однохоповое окружение (контакты пользователя A или B), мы получаем больше информации для определения, является ли ⟨пользователь A, пользователь B⟩ потенциальным контактом. Как показано на рисунке 11.5, рассмотрим два сценария.

В сценарии 1 пользователи A и B имеют по четыре общих контакта, и между контактами C, D, E и F есть взаимные связи.

В сценарии 2 пользователи A и B имеют по два друга, и между контактами пользователя A и пользователя B нет связей.

Глядя на их однохоповое окружение, можно ожидать, что ⟨пользователь A, пользователь B⟩ с большей вероятностью установят контакт в сценарии 1, чем в сценарии 2. На практике можно даже использовать двух- или трёххоповые окружения для получения более полезной информации из социального контекста.

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

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

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

• Предсказание на уровне графа. Например, по химическому соединению, представленному графом, предсказываем, является ли оно ферментом.
• Предсказание на уровне узла. Например, по графу социальной сети предсказываем, является ли конкретный пользователь (узел) спамером.
• Предсказание на уровне рёбер. Предсказываем, существует ли ребро между двумя узлами. Например, по графу социальной сети предсказываем, вероятно ли, что два пользователя установят контакт.

Рассмотрим подход предсказания рёбер для построения системы PYMK.

Предсказание рёбер

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

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

Помимо типичных признаков, модель также опирается на дополнительные знания, извлечённые из социального графа, для предсказания существования ребра между двумя узлами.

Подготовка данных

Инженерия данных

В этом разделе обсуждаем доступные исходные данные:

• Пользователи
• Контакты
• Взаимодействия

Пользователи

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

Таблица 11.1: Данные об образовательном бэкграунде пользователей

Одна из сложностей с такими исходными данными — конкретный атрибут может быть представлен в разных формах. Например, «computer science» и «CS» имеют одинаковое значение, но текст различается. Поэтому важно стандартизировать исходные данные на этапе инженерии данных, чтобы не трактовать разные формы одного атрибута по-разному. Существуют различные подходы к стандартизации исходных данных. Например:

• Обязать пользователей выбирать атрибуты из предопределённого списка.
• Использовать эвристики для группировки различных представлений атрибута.
• Использовать ML-методы, такие как кластеризация [1] или языковые модели, для группировки похожих атрибутов.

Контакты

Упрощённый пример данных о контактах показан в таблице 11.2. Каждая строка представляет контакт между двумя пользователями и время его установления.

Таблица 11.2: Данные о контактах

Взаимодействия

Существуют различные типы взаимодействий: пользователь отправляет запрос на контакт, принимает запрос, подписывается на другого пользователя, ищет сущность, просматривает профиль, ставит лайк или реагирует на публикацию и т.д. На практике данные о взаимодействиях могут храниться в разных базах данных, но для простоты включаем всё в одну таблицу.

Таблица 11.3: Данные о взаимодействиях

Инженерия признаков

Для определения потенциальных контактов пользователя (например, пользователя A) модели необходимо использовать информацию о пользователе A: возраст, пол и т.д. Кроме того, полезны сходства между пользователем A и другими пользователями. В этом разделе обсуждаем некоторые из наиболее важных признаков.

Признаки пользователей

Демография: возраст, пол, город, страна и т.д.

Демографические данные помогают определить, вероятно ли установление контакта между двумя пользователями. Пользователи склонны устанавливать контакты с людьми, имеющими схожую демографию.

В демографических данных могут быть пропущенные значения. Подробнее о том, как работать с пропущенными значениями, см. главу «Введение и обзор».

Количество контактов, подписчиков, подписок и ожидающих запросов

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

Возраст аккаунта

Аккаунты, созданные совсем недавно, менее надёжны, чем существующие уже давно. Например, если аккаунт создан вчера, он с большей вероятностью является спамом. Поэтому не стоит рекомендовать его пользователям.

Количество полученных реакций

Числовые значения, представляющие общее количество полученных реакций: лайков, репостов, комментариев за определённый период, например за одну неделю. Пользователи склонны устанавливать контакты с более активными участниками платформы, получающими больше взаимодействий от других пользователей.

Сходство пользователей

Сходство между двумя пользователями — хороший сигнал для предсказания, установят ли они контакт. Рассмотрим некоторые важные признаки, отражающие сходство пользователей.

Сходство по образованию и работе

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

Социальное сходство

• Просмотры профиля: количество раз, когда пользователь просматривал профиль другого пользователя.
• Количество общих контактов (взаимных связей): если у двух пользователей много общих контактов, они с большей вероятностью установят связь. Этот признак является одним из наиболее важных предиктивных [2].
• Взаимные контакты с учётом времени (time-discounted mutual connections): этот признак взвешивает взаимные контакты по продолжительности их существования. Рассмотрим пример для понимания обоснования.

Представим, что мы хотим определить, является ли пользователь B потенциальным контактом для пользователя A. Рассмотрим два сценария: в сценарии 1 контакты пользователя A были установлены совсем недавно, тогда как в сценарии 2 — давно. Это показано на рисунке 11.8.

В сценарии 1 сеть пользователя A недавно выросла, что означает большую вероятность установления контакта с пользователем B. В сценарии 2 шансы, что пользователь A знает о пользователе B, но решил не устанавливать контакт, выше.

Разработка модели

Выбор модели

Ранее мы сформулировали задачу PYMK как задачу предсказания рёбер, где модель принимает социальный граф как входные данные и предсказывает вероятность существования ребра между двумя пользователями. Для задачи предсказания рёбер выбираем модель, способную обрабатывать входные данные в виде графа. Граф-нейронные сети (GNN) предназначены для работы с данными в виде графов. Рассмотрим их подробнее.

GNN

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

Как показано на рисунке 11.9, GNN принимает граф как входные данные. Этот входной граф содержит атрибуты, связанные с узлами и рёбрами. Например, узлы могут хранить информацию о возрасте, поле и т.д., а рёбра — характеристики связей между пользователями: количество общих школ и мест работы, продолжительность контакта и т.д. Имея входной граф и связанные атрибуты, GNN создаёт embeddings узлов для каждого узла.

После создания embeddings узлов они используются для предсказания вероятности установления контакта между двумя узлами с помощью меры сходства, например скалярного произведения. Как показано на рисунке 11.10, мы вычисляем скалярное произведение embeddings узла 2 и узла 4 для предсказания существования ребра между ними.

В последние годы было разработано множество GNN-архитектур: GCN [3], GraphSAGE [4], GAT [5] и GIT [6]. Эти варианты имеют разные архитектуры и разные уровни сложности. Для определения наилучшей архитектуры требуются обширные эксперименты. Подробнее о GNN-архитектурах см. [7].

Обучение модели

Для обучения модели GNN предоставляем ей снимок социального графа в момент времени t. Модель предсказывает контакты, которые установятся в момент t+1. Рассмотрим, как строить обучающие данные.

Построение датасета

Для построения датасета выполняем следующие шаги:

1. Создать снимок графа в момент времени t
2. Вычислить начальные признаки узлов и рёбер графа
3. Создать метки

1. Создание снимка графа в момент времени t. Первый шаг в построении обучающих данных — создание входных данных для модели. Поскольку модель GNN ожидает социальный граф как входные данные, мы создаём снимок социального графа в момент t с использованием доступных исходных данных. На рисунке 11.11 показан пример графа в момент t.

2. Вычисление начальных признаков узлов и рёбер. Как показано на рисунке 11.12, извлекаем признаки пользователей: возраст, пол, возраст аккаунта, количество контактов и т.д. Они используются как начальные векторы признаков узлов.

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

3. Создание меток На этом шаге создаём метки, которые модель должна предсказывать. Для определения положительных или отрицательных меток используем снимок графа в момент t+1. Рассмотрим конкретный пример.

Как показано на рисунке 11.14, положительные и отрицательные метки создаются в зависимости от того, образуется ли новое ребро в момент t+1. В частности, пара узлов помечается как положительная, если они устанавливают контакт в момент t+1. В противном случае помечается как отрицательная.

Выбор функции потерь

После создания входного графа и меток мы готовы к обучению модели GNN. Детальное объяснение того, как работает обучение GNN и какие функции потерь применять, выходит за рамки этой книги. Подробнее об этом см. [7].

Оценка

Офлайн-метрики

При офлайн-оценке оцениваем производительность модели GNN и системы PYMK.

Модель GNN

Поскольку модель GNN предсказывает наличие рёбер, её можно рассматривать как модель бинарной классификации. Для измерения производительности модели используется метрика ROC-AUC.

Система PYMK

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

Онлайн-метрики

На практике компании отслеживают множество онлайн-метрик для измерения влияния систем PYMK. Рассмотрим две наиболее важные:

• Общее количество запросов на подключение, отправленных за последние X дней
• Общее количество принятых запросов на подключение за последние X дней

Общее количество запросов на подключение, отправленных за последние X дней. Эта метрика помогает понять, увеличивает или уменьшает модель количество запросов на подключение. Например, если модель приводит к росту общего числа отправленных запросов на 5%, можно предположить, что модель оказывает положительное влияние на бизнес-цель.

Однако эта метрика имеет существенный недостаток. Новый контакт устанавливается между двумя пользователями только тогда, когда получатель принимает запрос. Например, пользователь может отправить 1 000 запросов, но получатели примут лишь небольшой их процент. Эта метрика может не отражать реальный рост сети пользователей. Устраним этот недостаток следующей метрикой.

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

Обслуживание

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

Эффективность

Как обсуждалось в разделе сбора требований, общее число пользователей на платформе — 1 миллиард. Это означает необходимость просматривать 1 миллиард embeddings для поиска потенциальных контактов для одного пользователя. Ещё сложнее то, что алгоритм должен выполняться для каждого пользователя. Очевидно, это нереалистично в нашем масштабе. Для решения проблемы применяются два распространённых метода: 1) использование друзей друзей (FoF) и 2) предварительное вычисление PYMK.

Использование FoF

Согласно исследованию Meta [2], 92% новых дружеских связей устанавливаются через FoF. Этот метод использует FoF пользователя для сужения пространства поиска.

Как упоминалось ранее, у пользователя в среднем 1 000 друзей. Это означает в среднем 1 миллион (1000×1000) FoF. Это сокращает пространство поиска с 1 миллиарда до 1 миллиона.

Предварительное вычисление PYMK

Давайте отступим и рассмотрим варианты онлайн- или пакетного предсказания.

Онлайн-предсказание В PYMK онлайн-предсказание означает генерацию потенциальных контактов в реальном времени, когда пользователь загружает главную страницу. В этом подходе рекомендации не генерируются для неактивных пользователей. Поскольку рекомендации вычисляются «на лету», долгое время их расчёта приводит к плохому пользовательскому опыту.

Пакетное предсказание Пакетное предсказание означает, что система предварительно вычисляет потенциальные контакты для всех пользователей и сохраняет их в базе данных. Когда пользователь загружает главную страницу, предварительно вычисленные рекомендации извлекаются напрямую, поэтому для конечного пользователя рекомендация выдаётся мгновенно. Недостаток пакетного предсказания — возможные ненужные вычисления. Представьте, что 20% пользователей заходят ежедневно. Если генерировать рекомендации для всех пользователей ежедневно, вычислительные мощности для генерации 80% рекомендаций будут потрачены впустую.

Какой вариант выбрать: онлайн- или пакетный? Рекомендуем пакетное предсказание по двум причинам. Во-первых, согласно собранным требованиям, ежедневно активных пользователей 300 миллионов. Вычисление PYMK в реальном времени для всех 300 миллионов пользователей может оказаться слишком медленным для качественного пользовательского опыта.

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

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

Дизайн ML-системы

На рисунке 11.19 показан дизайн ML-системы PYMK. Дизайн включает два пайплайна:

• Пайплайн генерации PYMK
• Пайплайн предсказания

Рассмотрим каждый из них.

Пайплайн генерации PYMK

Этот пайплайн отвечает за генерацию PYMK для всех пользователей и сохранение результатов в базе данных. Рассмотрим его подробнее.

Сначала для конкретного пользователя сервис FoF сужает контакты до подмножества кандидатов (2-хоповые соседи). Это показано на рисунке 11.20.

Затем сервис оценки принимает кандидатов, полученных от сервиса FoF, оценивает каждого из них с помощью модели GNN, а затем генерирует ранжированный список PYMK для пользователя. PYMK сохраняется в базе данных. Когда поступает запрос пользователя, можно просто извлечь индивидуальный список PYMK напрямую из базы данных. Этот поток показан на рисунке 11.21.

Пайплайн предсказания

Когда поступает запрос, сервис PYMK сначала проверяет наличие предварительно вычисленных PYMK. Если они существуют, рекомендации извлекаются напрямую. Если нет — отправляется разовый запрос в пайплайн генерации PYMK.

Обратите внимание, что предложенная система упрощена. Если на собеседовании попросят её оптимизировать, вот несколько потенциальных тем:

• Предварительное вычисление PYMK только для активных пользователей.
• Использование лёгкого ранжировщика для сокращения числа сгенерированных кандидатов до меньшего подмножества перед тем, как сервис оценки присвоит им оценку.
• Использование сервиса повторного ранжирования для добавления разнообразия в итоговый список PYMK.

Дополнительные темы для обсуждения

Если в конце собеседования осталось время, вот некоторые дополнительные темы для обсуждения:

• Персонализированное случайное блуждание [8] — ещё один метод, часто используемый для формирования рекомендаций. Поскольку он эффективен, это удобный способ создания базового уровня.
• Проблема предвзятости. Активные пользователи обычно более широко представлены в обучающих данных, чем случайные пользователи. Из-за неравномерного представления в обучающих данных модель может стать предвзятой в пользу одних групп и против других. Например, в списке PYMK активным пользователям могут рекомендоваться другие пользователи с более высокой частотой. Впоследствии эти пользователи могут устанавливать ещё больше контактов, что делает их ещё более представленными в обучающих данных [9].
• Когда пользователь игнорирует рекомендованные контакты неоднократно, возникает вопрос: как учитывать это при будущих повторных ранжированиях? В идеале проигнорированные рекомендации должны получать более низкий ранг [9].
• Пользователь может не отправить запрос на подключение немедленно после нашей рекомендации. Это может занять несколько дней или недель. Так когда же следует помечать рекомендованный контакт как отрицательный? В целом, как работать с задержанной обратной связью в системах рекомендаций [10]?

Ссылки

1. Clustering in ML. https://developers.google.com/machine-learning/clustering/overview.
2. PYMK on Facebook. https://youtu.be/Xpx5RYNTQvg?t=1823.
3. Graph convolutional neural networks. http://tkipf.github.io/graph-convolutional-networks/.
4. GraphSage paper. https://cs.stanford.edu/people/jure/pubs/graphsage-nips17.pdf.
5. Graph attention networks. https://arxiv.org/pdf/1710.10903.pdf.
6. Graph isomorphism network. https://arxiv.org/pdf/1810.00826.pdf.
7. Graph neural networks. https://distill.pub/2021/gnn-intro/.
8. Personalized random walk. https://www.youtube.com/watch?v=HbzQzUaJ_9I.
9. LinkedIn's PYMK system. https://engineering.linkedin.com/blog/2021/optimizing-pymk-for-equity-in-network-creation.
10. Addressing delayed feedback. https://arxiv.org/pdf/1907.06558.pdf.