9.4. Хорошие свойства рекомендательных систем

Введение

Предположим, выдача нашей рекомендательной системы имеет высокие значения метрик ранжирования. Значит ли это, что система действительно хорошая? Не всегда просто ответить на этот вопрос. Оптимизируя определенные метрики, можно выкрутить кликбейт, и пользователи будут охотно кликать в моменте, но больше не станут пользоваться таким сервисом. Соответственно, нужно как-то измерять «счастье пользователей», попытаться формализовать свойства, которыми должна обладать хорошая рекомендательная система. Однозначного ответа на этот вопрос нет, всё зависит от контекста применения рекомендательной системы. В этом разделе мы поговорим о наиболее распространённых критерях, которые довольно часто оказываются важными.

Полнота (Coverage)

Под полнотой в данном контексте понимается доля рекомендованных объектов среди всех объектов .

Эта метрика была предложенна в статье Ge, M., Delgado-Battenfeld, C., Jannach, D. (2010, September). Beyond accuracy: evaluating recommender systems by coverage and serendipity. In Proceedings of the fourth ACM conference on Recommender systems (pp. 257-260).

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

Еще одним фактором, влияющим на полноту, является алгоритм холодного старта, который может использоваться для того чтобы найти подходящие объекты для нового пользователя или подходящих пользователей для нового объекта. Часто пользователям на этапе холодного старта показывают самые популярные объекты. Из-за этого свежедобавленные объекты (например, музыкальные треки) могут неявно пессмимизироваться алгоритмом. Один из способов решения проблемы – бустить свежие объекты в течение определённого времени, чтобы они показывались чаще. Настроки логики холодного старта могут сильно повлиять на метрику полноты.

Среди других актуальных вопросов, которыми стоит задаваться:

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

Чтобы ответить на эти вопросы, нужно принимать во внимание ряд факторов:

  • Какой объём трафика у системы рекомендаций?
  • Есть ли у бизнеса ограничения, влияющие на конечный список рекомендаций?
  • Имеет ли алгоритм рекомендаций достаточную степень персонализации?
  • Можно ли регулировать режимы exploration и exploitation во время работы рекомендательной системы?

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

Новизна (Novelty)

Один из способов оценить новизну рекомендательной системы – использовать статистическую меру собственной информации объекта (self information), которая используется в теории информации и тесно связана с понятием энтропии. Значение собственной информации для события равняется логарифму вероятности наступления данного события. Согласно теории, чем меньше вероятность наступления события, тем больше потенциальной информации принесет это событие при его наступлении. Единицей информации при использовании логарифма по основании является бит.

Теперь если переносить идею собственной информации в парадигму рекомендательных систем, то получается, что чем менее популярен объект, тем более вероятно, что он будет новым для пользователя. А значит мера информации у такого объекта будет выше. Для каждого рекомендованного объекта считаем вероятность, с которой его порекомендуют случайному пользователю: $ P_{i} = \frac{m_{i}}{N} $, где $ m_{i} $ – количество пользователей, которым был показан -й объект, а – общее число пользователей. Для заданного пользователя усредняем значение собственной информации по списку его рекомендаций и получаем итоговое значение метрики:

Разнообразие (Diversity)

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

diversity

Разнообразие можно рассчитывать на основе комбинаций метрик полноты и новизны. Также мерой разнообразия может быть дисперсия рекомендаций за заданный промежуток времени. Помимо этого популярны подходы, использующие эмбединги объектов для оценки попарной похожести объектов и расчёта на основе неё значения разнообразия. Одна из таких метрик – Intra List Similarity (ILS). Чтобы ее посчитать, нужно иметь эмбединги объектов рекомендаций, находящиеся в едином векторном пространстве. Для расчёта разнообразия для одного пользователя нужно усреднить попарную схожесть между рекомендованными объектами:

где – это набор рекомендованных пользователю объектов.

Для того чтобы добиться большего разнообразия, метрику нужно минимизировать. Мера схожести должна быть больше для более похожих объектов. Чаще всего используется косинусная близость (cosine similarity).

Serendipity

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

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

serendipity

Serendipity – довольно субъективное свойство и его сложно формализовать. Более того рекомендации, удовлетворяющие этому свойству, встречаются редко, что усложняет интерпретацию и измерение serendipity. Нет консенсуса о том, какой метрикой можно оценить его. Мы расскажем о способе, предложенном в статье T. Murakami, K. Mori, R. Orihara, Metrics for evaluating the serendipity of recommendation lists, in: New Frontiers in Artificial Intelligence, Vol. 4914, Springer Berlin Heidelberg, Berlin, Heidelberg, 2008, pp. 40–46.

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

Значение метрики можно усреднить по всем пользователям тестовой выборки. Чем больше значение, тем больше модель удовлетворяет свойству Serendipity.

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

Отдельный вопрос – как оптимизировать Serendipity. Нужно улучшать способность модели к персонализации:

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

Кроме того, имеет смысл оптимизировать модель по метрике serendipity на офлайн тестовой выборке.

Заключение

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

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

Отмечайте параграфы как прочитанные чтобы видеть свой прогресс обучения

Вступайте в сообщество хендбука

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

Методы кластеризации: K-Means, агломеративная кластеризация, DBSCAN. Оценка качества кластеризации