Создание рекомендательной системы Megogo: использование неявных сигналов. Часть 1

Материал создан в соавторстве с Александром Макеевым, Machine Learning Engineer в R&D MEGOGO

Мы начинаем серию статей о том, как наша команда R&D с чистого листа создает рекомендательную систему видеосервиса. В первой части опишем продвинутый рекомендательный алгоритм, который базируется на данных о просмотрах видео.

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

Акцент в статьях будет смещен с математической составляющей в сторону процесса создания полноценного продукта, использующего machine learning алгоритмы. Мы пройдемся по всему рабочему процессу, начиная от сбора требований, сквозь все шаги нашего data pipeline, до развертывания на серверах.

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

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

Постановка задачи

В самом начале разработки классической рекомендательной системы на основе лайков и дизлайков пользователей было очевидно, что охват зрителей будет не более 5% от общего количества. Чтобы предлагать рекомендации для всех наших зрителей, нам был необходим другой источник данных о пользовательской активности. Таким источником стала внутренняя система трекинга фактических просмотров контента — WatchStat.

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

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

  • CRR — коэффициент удержания клиентов;
  • LTV — пожизненная ценность клиента;
  • среднее количество часов просмотра на пользователя;
  • процент пользовательских сессий без просмотров контента;
  • процент рекомендованных и просмотренных единиц контента из всего каталога.

Использование неявных сигналов

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

Такой подход оставил множество вопросов без ответов. Если пользователь смотрел видео в течение 20 секунд, что это должно нам сказать? Видео понравилось или нет? Может он решил отложить просмотр на вечер? Или вспомнил, что уже однажды смотрел этот фильм и не хочет смотреть его во второй раз? А если пользователь просмотрел 45 минут видео и ушел? Когда нет данных о факте просмотра — это позитивный или негативный сигнал?

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

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

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

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

Немного математики: факторизация матриц

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

Входные данные представляют собой сильно разреженную матрицу вида:

video 1video 2...video N
user 1__1_
user 21__5
..._53_
user N3__1

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

Далее производится разложение исходной матрицы на две матрицы U и V с некоторым выбранным количеством факторов. Эти матрицы представляют собой сжатую проекцию большей части всего распределения данных с некоторыми потерями, конечно. В нашем случае факторы в сжатой форме отражают всё многообразие «вкусов зрителей». Матрица U — проекция зрителей на вкусы. Матрица V — проекция контент-объектов на вкусы. Матрицы факторов должны содержать в себе такой набор значений, чтобы умножение UV давало в результате матрицу с близкими к исходным значениями.

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

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

Главная сложность этого метода — как вообще найти факторы? И тут на помощь приходит машинное обучение в виде метода оптимизации Gradient Descent. Для его работы необходима дифференцируемая метрика (функция потерь), которую мы будем минимизировать. Очевидно, что метрика должна показывать ошибку приближения произведения матриц факторов к исходной матрице. Базовая формула выглядит так:

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

Существует ряд алгоритмов поиска факторов. Один из них — SGD (Stochastic Gradient Descent), работающий на семплах данных, обеспечивая хорошую масштабируемость, но не гарантирующий сходимость. Основной алгоритм в нашей статье — ALS (Alternating Least Squares), который также выполняет градиентный спуск. Его особенность состоит в том, что каждая итерация спуска происходит в два этапа (частное дифференцирование с поочередной фиксацией матриц факторов пользователей и фильмов) и гарантирует плавную сходимость.

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

Теперь исходная матрица Pui — это бинарная матрица фактов просмотра контента, а дополнительная матрица Cui — это уровень доверия факту просмотра. Плюс L2 регуляризация.

Ключевой момент здесь — расчет матрицы уровней доверия Cui. В простейшем случае он выполняется по формуле Cui = 1 + αRui, где Rui — исходная матрица с процентами досмотра, α — эмпирически подбираемый коэффициент. Авторы публикации рекомендуют проводить эксперименты с преобразованием имеющихся данных в уровень доверия. В ходе дальнейшей оптимизации гиперпараметров в формулу расчета была добавлена нелинейность и ещё один оптимизационный параметр. Подробнее об этом мы расскажем в соответствующем разделе статьи.

Учитывая, что сложно реализовывать подобные алгоритмы, способные переработать наш «очень большой» объем данных, мы используем готовую реализацию Apache Spark ALS (как и всю платформу в целом).

С алгоритмами разобрались, можно углубиться в разбор непосредственно реализации.

Hard&Soft

В нашей команде основной язык программирования — Python. Некоторые шаги data pipeline реализованы на Scala в угоду скорости работы на платформе Apache Spark. Для исследований используется Jupyter Notebook. Расчеты производятся, очевидно, тоже на Apache Spark. Базы данных: MongoDB и MySQL.

Все исходные данные собираются и хранятся на in-house серверах в датацентрах Megogo. На них же работает API, раздающий пользователям предварительно рассчитанные рекомендации. Работает API на стандартном стеке: Python, Flask, MongoDB, Memcached, NGINX.

Исследования, разработка и тренировка моделей, запуск production data pipeline производятся на AWS EC2 серверах. Данные, необходимые для расчета моделей, хранятся на AWS S3. Обмен данными между корпоративными подсетями и серверами на AWS производится по защищенным туннелям.

Сырые данные

Нам сильно повезло в том, что система трекинга WatchStat начала свою работу задолго до того, как мы начали использовать собранные ею данные. Как следствие, в нашем распоряжении было «очень много» (мы и сами не знаем полный объем) исторических данных, собранных за несколько лет. Для любого Data Scientist это фантастический старт. Потому что мы сразу перепрыгнули мучительные этапы создания трекинговых систем, бесконечных исправлений багов и долгосрочного сбора первоначального объема данных с приемлемым качеством.

С другой стороны, данные были собраны в «очень много» гигабайт текстовых CSV, разбитых на две раздельные сущности, которые необходимо было объединить по ключу. Данные хранились на HDFS, и у наших бизнес-аналитиков была возможность работать с ними через Hadoop+Hive, но скорость обработки каждого запроса была крайне низкой. Поэтому было принято решение создать ETL (extract, transform, load) процессинг для извлечения из CSV полезных для нас данных и сохранения их в удобном для дальнейшего использования формате.

Исходные данные разбиты на ежесуточные архивы. Каждый архив состоит из:

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

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

ETL

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

Во-первых, с помощью Apache Spark один раз в сутки производится чтение и разбор информации из CSV формата. На этом шаге сырые данные из CSV:

  • проходят предварительную очистку;
  • сессии с информацией о начале просмотра видео и событиях продолжения просмотра соединяются в единый датасет;
  • по идентификатору сессии записи группируются;
  • производится ряд манипуляций для получения последовательностей событий в рамках каждой сессии;
  • самое главное: производится расчет длительности сессии и «процент досмотра», который используется для работы рекомендательного алгоритма ALS;
  • записываются на S3 в Parquet-формате.

Таким образом мы получаем посуточную статистику в интересующем нас формате.

Далее мы берем рассчитанную статистику за длительный период и конвертируем в формат входных данных для алгоритма Spark ALS. По-факту, мы рассчитываем три модели, используя различные промежутки исторических данных (суммарно за 14 месяцев) и на одном из финальных этапов делаем микс результатов. Но подробнее об этом позже.

Стоит отметить, что этап ETL практически линейно масштабируется при увеличении количества процессорных ядер, доступных Apache Spark. Первоначально преобразования выполнялись скриптом на Python. Это влекло за собой необходимость сериализации и передачи данных между Spark и Python-процессами, которые занимались фактической обработкой данных. Несмотря на то, что скорость работы была приемлемой, было очевидно, что процесс можно значительно ускорить. Поэтому задача для Spark была переписана на Scala, что сразу дало прирост скорости выполнения в 2-3 раза на тех же вычислительных ресурсах.

Предварительный анализ данных

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

Перед тем как создавать модель, необходимо понять данные, с которыми мы будем работать. Все исследования производятся в Jupyter Notebook, интегрированными с Apache Spark. Основная цель — выяснить качество данных и на раннем этапе выявить мусор, пропуски и аномальные выбросы. К примеру, попадаются сессии просмотра продолжительностью целые сутки. Есть зрители, высматривающие сотни видео за месяц, и данные о них превращаются в белый шум. Часто в случае сбоя проигрывателя стартует новая сессия просмотра и с точки зрения нашей системы получается два просмотра с низким процентом досмотра.

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

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

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

На данный момент у нас нет полноценной возможности проведения А/Б тестирования. Как следствие, мы вынуждены опираться исключительно на оффлайн-метрики качества. У нас их четыре:

  • MAP@10 — самая жесткая метрика, отражающая точность попадания рекомендаций в видимую область рекомендательной ленты;
  • MAP@50 — точность попадания в рамках всей рекомендательной ленты;
  • процент пользователей, для которых было хотя бы одно попадание рекомендаций;
  • процент каталога контента, предложенного в рекомендациях.

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

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

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

Тренировка модели на базе алгоритма ALS

Мы собрали данные и определились с метриками. Наконец можно рассчитать рекомендации.

Используя классический подход ML, из имеющегося объема данных мы удаляем всех пользователей, у которых меньше 2 просмотров, и разбиваем датасет на две части: тренировочную и проверочную. Конечно, можно использовать технику cross-validation, но учитывая, что один просчет ALS алгоритма даже на очень серьезном железе может занимать несколько часов, для базовых экспериментов мы решили ограничиться разбиением выборки на две.

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

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

Поиск оптимальных значений гиперпараметров

У алгоритма ALS есть несколько важных для нас параметров:

  • rank — количество факторов (об этом шла речь в математической части статьи);
  • maxIter — количество итераций (напоминаем, что алгоритм у нас итеративный — градиентный спуск);
  • alpha — эмпирический коэффициент, влияющий на расчет степени доверия (которая в нашем случае считается на основании процента досмотра);
  • regParam — коэффициент регуляризации, позволяющий управлять переобучением модели.

Кроме того, в ходе исследований мы выяснили, что оригинальный процент досмотра не дает достаточного разделения результирующей степени доверия к просмотру между «скорее всего, нравится» и «скорее всего, не нравится». Например, средний процент досмотра хорошего фильма — 0,8-0,9; не интересного контента — 0,1-0,2. Использование только коэффициента alpha показало, что пользователи продолжают получать на верхних строчках рекомендации фильмов, которые они действительно смотрели, но процент досмотра крайне низкий. Говоря проще, ALS считал позитивными результатами всё, что насмотрел пользователь, несмотря на низкий процент досмотра.

Для решения этой проблемы были проведены эксперименты с исходными данными, в ходе которых мы выяснили, что наилучший результат обеспечивает возведение процента досмотра в степень от 2 до 3. Таким образом, начальная формула преобразования получила вид: Cui = 1 + α(Rui)N, где N стал еще одним гиперпараметром модели.

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

Приведем несколько примеров зависимости значений выбранных метрик от гиперпараметров модели.

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

Здесь продемонстрировано аномальное поведение модели при небольшом значении alpha=1. Более привычно выглядит следующий график, который мы разберем подробно.

Единственное отличие этих экспериментов от предыдущих — в увеличенном значении alpha=10.

С ростом значения регуляризации происходит следующее:

  • падение на 20% количества пользователей с совпадениями предсказаний и реальных просмотров на тренировочной выборке, но при этом незначительные изменения на проверочной выборке;
  • падение на 0,08 значения метрики MAP@10 на тренировочной выборке и рост на 0,05 на проверочной выборке.

Эксперименты показывают, что оптимальное значение регуляризационного параметра равно 1,0.

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

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

На графике легко заметить рост точности на тренировочной выборке с 0,1 до 0,34 и процент пользователей с совпадениями с 66% до 93%. При этом для проверочной выборки точность растет с увеличением количества факторов до 20 и потом плавно падает. Это яркий пример процесса переобучения модели, который необходимо контролировать другими гиперпараметрами.

Поэтому мы фиксируем количество факторов 70, количество итераций 10, alpha=20 и пробуем подобрать необходимый уровень регуляризации.

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

Отдельно хотелось бы сказать об охвате каталога. Чтобы разместить значения метрики на графике, нам пришлось конвертировать абсолютные цифры количества контент-объектов в относительные.

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

  • в худшем случае охват каталога не превышает 300 фильмов;
  • в лучшем случаем — 4800 фильмов.

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

Что касается метрики MAP@10, то цифры такие:

  • худшая модель — 0,012;
  • лучшая модель — 0,050.

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

Подведение промежуточных итогов

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

Читайте также: Архитектура видеосервиса Megogo: варианты решений и переход от монолита к микросервисам

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




17 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Спасибо, познавательная статья

Лучше напишите о том как генеряться фейковые отзывы к трешовым фильмам на вашем ресурсе и о том как саппорт не реагирует на это.

естественным выбором стал алгоритм факторизации матриц

Давно известный метод факторного анализа, проверенный практикой, но позволяющий выявить лишь линейные зависимости
ru.wikipedia.org/wiki/Факторный_анализ

получивший распространение после конкурса Netflix Prize.

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

P.S.
Я как-то посылал через доу аппликешн в Megogo. Отчасти по приколу: вряд ли бы поехал в Украину, но вот удаленно сотрудничать был готов вполне серьезно. Сейчас это уже неактуально (во всяком случае, на ближайшее время), но чисто из любопытства — вы мой аппликешн-то получили? (ответа не было никакого).

в нетфилкс прайзе был ансамбль если не ошибаюсь с 263 моделей. у самого нетфликса 3 уровня предикшена: риал-тайм, пре-риал-тайм и оффлайн рекомендации.
Вообще у них крайне интересные статьи в тех блоге: medium.com/netflix-techblog

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

www.netflixprize.com/...​ressPrize2008_BellKor.pdf
www.netflixprize.com/...​essPrize2008_BigChaos.pdf
Естественно, в победном решении был дикий ансамбль. Но именно факторизация и k-NN были основными опорными алгоритмами, которые в разных вариациях участвовали во всех блендах. И считается, что именно после этого конкурса факторизация стала одним из промышленных стандартов в рекомендашках.

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

но чисто из любопытства — вы мой аппликешн-то получили? (ответа не было никакого).

Василий, ваша кандидатура действительно была на рассмотрении в нашей команде. В первую очередь на тот момент мы не рассматривали кандидатов на удаленную работу, во вторых, в тот момент нам были нужны инженеры с хорошим боевым опытом в создании data pipelines. У команды сложилось впечателние что по этому моменту у нас будет «unmatch». Просим прощения за то, что не дали обратную связь.

Исключаются ли из начальных данных (или снижается ли значение) навязанные просмотры: после перехода с рекламных баннеров, топов и, собственно, рекомендаций рекомендательной системы?

Это отличный вопрос! Учитывая, что большая часть данных приходит из SmartTV, куда вообще невозможно попасть напрямую погуглив название фильма, достижимость контента на конкретной платформе становится ключевым фактором, который на данный момент никак не учитывается. Причина банальна: отсутствие трекинговой системы, достаточно интеллектуальной для сбора необходимой информации и её трансформации в цифры, пригодные для использования как penalty. Но сейчас ведётся активная работа в этом направлении.
В ближайшем будущем будет использоваться информация о внутренних каналах, с которых зрители приходят в плеер, и какие в целом у них были альтернативы. В каком виде эта модель пойдёт до прода, пока говорить не готов. Нет данных-нет исследований-нет результатов. Есть только идеи и пачка whitepapers :)

1) Колаборативныые алгоритмы крайне ненадежная вещь да и точность их очень очень оставляет желать лучшего.
2) MAP метрика крайне странная, я бы брал Precision, Recall, ибо по ним видно че вообще происходит. Проще говоря MAP в 100% = алгоритм который рекомендует только просмотреенные фильмы и никаких новых.
3) Еще помимо этих метрик стоит учитывать заполняемость каталога рекомендаций. ибо если алгоритм рекомендит 1% от все медиатеки это хреново.
4) Реализация Apache ALS крайне хренова и уступает даже пайтоновской либе github.com/benfred/implicit и я не думаю что у вас настолько большой обьем что это нельзя сделать на одном мощном серваке и требует разбития. Так же у некоторых версий спарка есть замечательная тема терять данные незаметно)
5) если мы говорим о рекомендации по 2 фильмам то это гадание на кофейной гуще. На настолько разреженных данных предикшен вообще никакой. И тут либо нужно строить ембединг фильмов и интересов юзера с них либо рекомендовать линейными алгоритмами например по режисеру, рейтингу, актерах и жанру схожие фильмы. Проще говоря, если я посмотрел Чужие 1 то вполне логично рекомендовать и остальные фильмы серии.
6) мы с вами как то общались уже на тему эту и вы говорили о огромном пайплайне с кучей моделей, а в итоге я вижу ALS. я немного огорчен( Надеюсь в след посте будет что то более интересное.

1 — субъективно
2 — MAP, NDCG, MRR — это стандарт для систем ранжирования с учётом позиции. Идеально ещё экспоненциальным снижением весов, т.к. после 5-10 элемента уже в принципе не важно, угадали мы или нет. Precision, Recall совсем не о том.
3 — об этом добрая половина статьи. Считается ряд метрик и находится компромисс.
4 — «Уступает» по каким критериям? В основе лежит довольно простая факторизация матриц, сломать которую весьма сложно. Вопрос исключительно в подготовке данных и тюнинге гиперпараметров. И да, данных «очень много».
5, 6 — Мы в курсе всего state of art :) Но в реальной жизни, когда что-то создаётся с чистого листа и бизнесу нужно «на позавчера», то сначала выкатываются максимально простые и точно работающие модели. И только после этого появляется время и возможность делать более комплексные модели.
6 — Нет, мы говорили конкретно об ALS. На данный момент весь пайплайн только по этой модели от получения данных до выдачи конечному юзеру результатов — 11 последовательных шагов: ETL, просчёт ALS рекомендашек по 3 периодам, bagging, предсказание повторных просмотров (xgboost) и перевзвешивание рекомендашек, доставка результатов в in-house DC. Плюс оркестрация, мониторинг и тесты. Подробнее об этом будет в следующей части. Учитывая размер нашей команды, только это — уже большая работа.
Кроме того, в проде работают рекомендашки для холодных юзеров, рекомендашки на основании мета-информации, на основании лайков, на основании покупок. Сейчас идёт работа в сторону reinforcement learning для учёта неявного негативного фидбека, создания поведенческих профилей юзеров (привет эмбеддингам) и более точной работы с сериальными объектами и франшизами.

1) обычно, так как во всех реальных ситуация данные всегда крайне разрежены.
2) все эти метрики не дают реального понимания результатов. Все перечисленные метрики не более чем score, но в рекомендашках score может быть подсчитан исключительно после респонса реальных юзеров по новым данным. А посему они по большей мере бесполезны.
4) По качеству результатов (данные одни и теже)
5,6) Бизнесу важно бабло/время/улучшение резалта. Какой + в точности ALS например от обычной рекомендации по рейтингу или по схожим режисерам/актерам..
Ну и простая модель != рабочая модель.
6) Я бы тогда начала с полного описания пайплайна а потом уже конккретизировал по каждой его части. Бо сложно понять частное без наличия полной архитектуры проекта.

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

1) Разреженные данные — это как раз то, для чего и предназначен SVD. Лучше могут зайти только ембеддинги. Но это уже другая тема.
2) Давайте смотреть правде в глаза: все метрики кроме результатов А/Б тестов имеют смысл только на Kaggle :) И даже А/Б тесты не очень репрезентативны потому что есть проблема достижимости контента, о которой говорится в соседнем треде. Так что, дискуссия может быть бесконечной. Но факт в том, что теоретическая математика и продакшен с реальными данными и потребностями бизнеса — два разных мира как бы. Всегда приходится искать компромисс.
4) Опять таки, как оценивается качество результатов? Абстрактными оффлайн метриками или онлайн конверсией по АБ тесту между Spark vs Python.
На самом деле implicit щупался в том числе, но он сразу отпал в виду объёма данных. Вопрос даже не в качестве, а в неприменимости на проде.
5,6) В соревновании, которое мы организовываем (упоминается в статье), есть два бейслайна. Один посчитан по ТОП самых популярных фильмов, другой — очень тупой ALS без тюнинга. Разница по метрике MAP@10 — в 3 раза. Легко угадать, в чью пользу :)
6) Один только трекер — 20 листов текста без деталей, чисто архитектура. Крайне сложно это всё упаковать в читабельный и компактный вид. И без лишних подробностей о нашей сугубо внутренней кухне. Но потихоньку это будет делаться.

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

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

1) не совсем так. есть определенные пределы разреженности. например при заполнении столбца на 5% чтолибо предсказывать это мазать масло по стенам. СВД крайне тупая штука. Например даже для импута данных ее юзают ща крайне редко.
2) метрика должна показывать хоть что то иначе смысл ее считать. это как например взять акьюраси бинарной сегментации когда жесткий перекос в один из класов. в итоге она будет 99.9% и если не смотреть в конфьюжен матрицу то проеб гарантирован.
4) время тренировки, результат по реколу и прецижену на 10,25, 50 резалтах, мануальное тестирование рандомных 100 резалтов из топ10
6) 20 листов чисто для архитектуры как то очень дофига.. у меня арха на 200-400 машин занимает отсилы пару слайдов обычно. возможно слишком все детально. тут же надо просто типа путнк 1 — алс, пункт 2- алг1, пункт 3 -алг2 и т..п.

1) какие есть реально рабочие альтернативы?
2) Вот mAP и показывает точность попадания видимой области ленты в реальные просмотры юзера с деградацией веса по позиции. Это очень логичная метрика с точки зрения реального UX. Но! Повторюсь. Любая метрика в контексте конкретно нашей задачи — вещь в себе. Опираться на неё конечно же стоит, но нужно понимать, что выбор юзера по-сути ограничен тем, что мы ему предлагаем в рекомендашках или форсим через рекламу. Это вносит огромный bias. Кроме того, юзер может воспользоваться поиском или зайти в линейный каталог контента. Реальную картину может показать только А/Б тест. И то... Комплексная модель зависит от массы сигналов, рекламные блоки сегментированы, etc. Нельзя просто взять и побить пополам аудиторию и «что-то измерить». Группы должны быть стратифицированы. Следующий вопрос — как? :) Тут не работают подходы а-ля кэггл.
6) Архитектура — это всё же не о слайдах. Это целостное видение системы, изложенное в такой форме, чтобы бизнесу не пришлось начинать всё сначала, если автора вдруг собьёт автобус )) Поэтому: контракты микросервисов, устойчивые пайплайны, оркестрация, логирование, выкатка, альтернативы, планы итеративного развития, бюджет. Это важно зафиксировать для последующей долгосрочной командной работы.

1) для мего разреженых данных только ембединг лучше и больше них нет + можно добавлять рандомайз со смещенным распределением
2) только точность, но не рекол. 100 из 100 это плохой алгоритм. так как это оверфит
Биас убирается тем что это имплисит хрень и для разных источников разная амплитуда реакции.
Прямой А/Б кста работает плохо. Топ Н моделей работате лучше и быстрее. этот же подход юзает нетфликс если что.
Ну и я не то что бы фанат кегла)
6) ну мы ж тут про МЛ.. а посему оркестрация, логи, деплой и прочее никому не интересно да и банально это все. а вот организация МЛ пайпов и самих моделей интересна.

когда «быстрорастущая компания» исправить баги, которым не один год и реализует функционал, который рекламируется, а по факту не присутствует ?

Підписатись на коментарі