Откройте для себя современные подходы к построению RecSys

# 1 Проблема информационной перегрузки

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

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

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

# 2 Варианты использования RecSys в отрасли

Вам нужен рекомендатель?

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

Например, если вы хотите создать панель «Элементы, похожие на…» или «Вам также может понравиться…» на странице описания элемента, вы должны написать запрос SQL. который извлек top xx items для текущего category элемента.

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

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

Факторы, влияющие на необходимость рекомендательной системы

Размер каталога товаров:

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

Отсутствие структурированных данных:

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

Повторяемый процесс улучшения бизнес-показателей:

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

Примеры использования RecSys

Ниже приведены примеры использования рекомендательных систем, которые широко распространены в обществе, с разбивкой по отраслям:

Примеры использования RecSys в промышленности:

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

Архитектура и создание RecSys

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

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

# 3 Рекомендательный дизайн системы

На приведенной выше диаграмме показан стандарт де-факто для построения рекомендательных систем. Современные рекомендательные системы (SOTA) разделяют разработку такой системы на этот трехэтапный процесс.

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

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

Генерация кандидатов; Retrieval

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

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

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

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

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

Почему бы сразу не перейти к этапу подсчета очков?

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

Здесь следует учитывать несколько моментов:

  1. Создание вложений — ключевой этап проектирования функций. Векторные значения могут быть повторно использованы нижестоящими в качестве значений входных признаков для дальнейшего повышения точности модели оценки последующих потоков.
  2. Модели генерации кандидатов могут обучаться на неструктурированных данных и представлять атрибуты неструктурированных данных элемента или пользователя с использованием многомерного вектора. Эта полезная информация, такая как текст, изображения, аудио, видео, в противном случае остались бы незадействованными.
  3. Семантическое визуальное понимание каждого элемента или пользователя в пространстве встраивания. Вы можете визуализировать многомерные векторы в двумерном пространстве с помощью таких инструментов, как TensorBoard Embedding Projector. Поступая таким образом, вы также получаете возможность наблюдать и применять алгоритмы кластеризации для обнаружения кластеров похожих объектов.
  4. Результат модели генерации кандидатов направлен на установление сходства между элементами или пользователями. Эта идея лежит в основе большинства продуктов рекомендательных систем. На ум приходят такие примеры, как «Элементы, похожие на…» или «Пользователям, похожим на вас, также понравились…».
  5. Подавайте результаты модели эффективно. Обслуживание модели генерации кандидатов также эффективно с использованием механизма приближенных ближайших соседей (ANN). Для получения дополнительной информации об алгоритме ANN, пожалуйста, обратитесь к видео: Approximate Nearest Neighbours: Data Science Concepts. Сравните это с этапом оценки, где у вас есть дополнительные накладные расходы на вычисление всех инженерных функций, которые использовались для обучения модели оценки, прежде чем API сможет вернуть вам результаты модели.

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

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

Альтернативный подход заключается в записи внедрений объектов в базу данных, а нижестоящие системы запрашивают базу данных для их извлечения. По сути, это то, что Spotify делает с помощью Cloud Bigtable.

Подсчет очков; Рейтинг

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

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

Оценка – необязательный этап

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

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

Чтобы обслуживать выходные данные модели оценки, вы можете опубликовать конечную точку API с версией модели, которую хотите развернуть. Нижестоящая система должна будет вызвать API с базовыми входными функциями (мы должны быть осторожны, чтобы не вызвать утечку данных), а модель оценки будет вычислять инженерные функции, прежде чем возвращать ранжированный список элементов, каждый со своей вероятностью. счет.

Есть простые варианты развертывания такой конечной точки на всех 3 провайдерах общедоступных облаков:

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

Переоценка

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

  1. Качество элементов — удаление вредоносных элементов, таких как поддельные / пиратские / мошеннические продукты, списки предметов низкого качества, кликбейты и т. д., которые могут негативно повлиять на доверие пользователей и отбить у них желание использовать платформу.
  2. Разнообразие элементов — вместо того, чтобы рекомендовать элементы, которые пользователи видели раньше, мы можем рекомендовать менее известные списки элементов или различные категории элементов, которые пользователь обычно просматривает, чтобы стимулировать открытие и исследование на платформе.

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

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

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

# 4 Особая благодарность / рекомендации

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

Первоначально опубликовано на https://natworkeffects.com 10 февраля 2023 г.