Я занимался этой темой последние три года в Ubisoft, но до сих пор не нашел подходящих наборов данных для экспериментов в своем блоге.

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

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

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

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

Чтобы строить рекомендации и управлять взаимодействиями, я создал like index со следующими правилами:

  • Если оценка находится между 1 и 5, аналогичный индекс будет равен 0
  • В противном случае (более 5 баллов) аналогичный индекс будет равен 1.

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

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

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

  • Случайный рекомендатель (с контентом, основанным на определенном периоде)
  • Самый популярный рекомендатель контента (то же самое с контентом, найденным за определенный период)

Для популярности возможны две модели:

  • Популярность за появление
  • Популярность по сумме положительных отзывов/критик (при индексе лайков, равном 1)

В этих моделях используются базовые подходы, и их несложно превзойти (#mostpopularrulestheworld), но все же полезно иметь эти модели для создания базы для создания новых моделей.

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

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

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

Для оценки предыдущих моделей шаги будут следующими:

  • Сформировать рекомендации для людей, оставивших положительный отзыв (с индексом лайка равным 1) 15 июля 2021 г.
  • Рекомендации будут построены на основе данных обо всех действиях, которые произошли до 15 июля.
  • Рекомендации могут иметь две формы:
  • Более академический / теоретический с 25 лучшими материалами, которые можно рекомендовать (все категории смешаны).
  • Более реалистичный с пятью лучшими элементами в каждой возможной категории, он выглядит как обычно то, что нужно на работе (не самый оптимальный с точки зрения производительности, но он связан с ограничениями UX / UI).

Последний пункт основан на моем опыте работы; вы обычно не обслуживаете все элементы, ранжированные и доступные в ваших приложениях. Вы должны применять правила, соответствующие ограничениям UI/UX (например, вы можете отображать только X элементов этой категории в этих конкретных плитках).

Отказ от ответственности:

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

Весь код, использованный в этом разделе, можно найти здесь (еще раз работа продолжается)

Просто и понятно: соотношение попаданий

Это просто, список рекомендаций строится для пользователя. Контент, который понравится, был в этом списке:

Вот как это выглядит для нашего текущего примера (чем больше, тем лучше):

Для 25 лучших элементов контента или ограничения списка с правилами показа предыдущий рекомендатель контента занимает третье место после самых популярных моделей (№1 — модель, основанная на частоте появления контента).

С моей точки зрения, по этому показателю

✅

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

❌

  • Не влияет место контента в рекомендациях (то же самое, если контент первый в списке или последний)

Недостаткам этой метрики можно противопоставить другие метрики, которые мы увидим позже.

Рекомендации по построению — проблема классификации

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

Простая настройка широко распространена в мире машинного обучения, поэтому можно использовать все метрики этой области (точность, полнота и т. д.). Я не буду перечислять все метрики и рекомендую вам взглянуть на такой пакет, как scikit Learn, если вы не слишком знакомы с этими метриками (с глоссарием google ML, если вы хотите больше деталей). Но из этой настройки классификации некоторые показатели очень часто используются для оценки рекомендательных систем:

  • mAP (для средней средней точности) и mAR (для среднего среднего отзыва), будьте дотошны в названии и в том, как вычислять метрики, которые могут сбивать с толку, но есть отличный ресурс для объяснения метрик здесь. Это не та метрика, которую я обычно использую, но вокруг меня есть специалисты по данным, которые ее использовали, поэтому я думаю, что хорошо поделиться
  • NDCG (Normalized Discounted Cumulative Gain), есть краткое объяснение показателя и связанных с ним элементов; Я обычно использую реализацию, найденную в этом репозитории.

В нашем текущем примере это выглядит так (чем больше, тем лучше):

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

Вот плюсы и минусы NDCG:

✅

  • Учитывается положение элемента в списке рекомендаций.

❌

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

Этот показатель не идеален, но он дает больше информации о качестве рекомендаций.

Создание рекомендаций — проблема регрессии

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

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

Рекомендации основаны не только на эффективности

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

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

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

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

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

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

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

Рекомендатель должен быть развернут

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

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

По типу оценки:

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

Модель не так уж плоха по метрикам вывода.

Бонус: частота обновления

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

Мои исследования по этому вопросу недавно привели меня к метрике, используемой во время Spotify Million Playlist Dataset Challenge, называемой рекомендуемыми кликами по песням, которую я переработал для своего случая использования.

Идея довольно проста:

  • Правила UX заключаются в том, чтобы в каждой категории было пять лучших элементов; все будет отображаться на первой странице
  • В нашем контексте оценки мы представим, что есть кнопка обновления (например, Spotify для обновления отображаемого контента и отображения следующего контента с лучшим рейтингом в списке).
  • Для оценки цель состоит в том, чтобы получить, сколько кликов вам потребуется, чтобы отобразить нужный контент на главной странице.
  • Если количество кликов превысило заданный порог (в моем случае 10), значение будет установлено на 10.

Вот пример этой метрики для моего контекста.

Как мы видим, самые популярные рекомендатели контента работают лучше, чем другие модели.

Моя точка зрения:

✅

  • Учитывать положение элемента в списке рекомендаций.
  • Учитывайте правила UI/UX
  • Легко понять

❌

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

Теперь, когда мы рассмотрели некоторые KPI, которые можно использовать для оценки эффективности рекомендательной системы, давайте поговорим о процессе оценки.

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

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

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

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

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

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

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

  • Один из документов по ​​оценке рекомендательных систем, который вы увидите в большинстве оценочных документов.
  • Увлекательный пакет с множеством метрик от Клэр Лонго
  • У Microsoft есть отличный рекомендательный репозиторий с некоторыми записными книжками, связанными с оценкой.
  • Посоветую пройтись по следам оценки на конференции типа recsys

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

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

Первоначально опубликовано на https://www.the-odd-dataguy.com 1 сентября 2021 г.