Рекомендательные системы на больших данных

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

Сегодня мы поговорим о современном статусе рекомендательных систем, о том, как они работают, какие данные необходимы для того, чтобы построить рекомендательную систему. Поговорим о том, чем отличаются РС и как измерять качество работы РС (о метриках качества). Подумаем над вопросом — стоит ли писать РС самостоятельно (это возможно, это не rocket science) или лучше приобрести готовое решение. Сколько это может потенциально стоить, во что предстоит инвестировать. Немного поговорим об алгоритмах, чтобы понимать, как примерно это работает (основной — это SVD). О специалистах, которые для этого нужны. И о направлениях развития.

В теме «рекомендательные системы» есть три основных понятия, которые следует помнить. Во-первых, это пользователи (users), второе — это товары (items), третье — события (events) . События состоят в том, что пользователю U понравился (или не понравился) товар I. Можно также говорить об оценке, которая характеризует степень, насколько товар понравился или не понравился. То есть событием r[u,i] может быть то, что U поставил товару I оценку R. Это «базовая механика» рекомендательной системы.

Основная задача рекомендательной системы заключается в том, чтобы по каким-то имеющися у нас данным для каждого пользователя предсказать, какую оценку R он поставит каждому из товаров. Зная оценки, мы сможем давать какие-то рекомендации. Например, если мы прогнозируем, что для товара I пользователь U поставит высокую оценку, то стоит этому пользователю об этом товаре рассказать. Скажем, если у нас есть некий набор товаров, то мы можем их отранжировать по прогнозируемым R, затем выбрать Топ-5, исходя из максимума R, и предложить эти Топ-5 товаров вниманию пользователя.

Как это может работать?

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

Начнем с простых алгоритмов, которые на уровне идеи понятны многим из вас. Первая очевидная идея заключается в том, что похожие люди смотрят похожие фильмы (покупают похожие товары). И наоборот, люди, покупающие похожие товары, вероятно, похожи. Соответствующие методы получили название Content-based или Item-based.

Как они работают?

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

Есть более универсальный способ — это так называемая коллоборативная фильтрация или алгоритм SVD.

Для рекомендаций используется история оценок, как самого пользователя, так и других пользователей. Это более универсальный подход, который часто дает лучший результат. На сегодня он наиболее распространен, в том числе и в силу понятности, а также потому, что он хорошо сводится к задачам машинного обучения (ML). У метода есть свои проблемы, в частности, «холодный старт». Что делать в этой ситуации?

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

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

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

Кейс рекомендательной системы

Рассмотрим кейс крупного интернет-магазина. Примерно по такой схеме работает, например, рекомендательная система Озона.

архитектура рекомендательной системы

Какие объекты есть в процессе — есть пользователи, есть товары, есть события. Ясно, что нужно собрать как можно больше данных о товарах, о пользователя и о действиях пользователя. Данные пользователя на первом этапе — это данные его регистрационной анкеты, в частности. Данные о товаре магазин, как правило, получает от поставщика вместе с товаром, либо из других источников. С ними, как правило, проблем нет. В частности, в нашем примере речь идет примерно о 8 млн постоянно обновляемых товарах, их описаниях, цене, доступности. Для их хранения хватит и обычной информационной базы предприятия. То же и данные о пользователях, анкетные данные могут храниться в обычной таблице, в реляционных базах данных, в SQL сервере, который есть у любого магазина.

Иное дело — данные о транзакциях, о действиях пользователей. Пользователь отобрал товар в корзину. Пользователь поставил лайк. Пользователь просмотрел каталог. Таких действий очень много — это примерно в среднем 100 событий в секунду, такой поток данных по примерной оценке «весит» 15 ГБ/день. Для хранения таких объемов данных желательна уже какая-то продвинутая система.

Откуда берутся данные о действиях пользователей? Вы знаете, что практически на всех сайтах стоят счетчики, фиксирующие практически любые действия пользователей. Эти данные поступают в очередь и складываются в Hadoop-кластер, в нашу файловую систему HDFS через такие инструменты очереди, как RabbitMQ и Flume. Hive в этой системе позволяет простыми запросами получать необходимые выборки из распределенной файловой системы.

Такая рекомендательная система, это уже пример работы с Big Data. Алгоритм работает с данными в Hadoop-кластере, куда также добавляются через Sqoop данные о пользователях и товарах.

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

При этом Hadoop кластер не обязательно строить внутри компании. Впрочем, сейчас часто компания считает, что это её конкурентное преимущество и предпочитает его создать у себя.

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

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

Ожидаемый плюс был бы — быстрота работы. Минусы просматривались такие: программировать на Java достаточно непросто, язык «многословный», математикам трудно принимать участие в работе — расширять или улучшать алгоритм по мере надобности. Кроме того, в Java бедный MapReduce API. Например, а каждый tuple (кортеж) приходится заводить свой класс.

В итоге решили взять Apache Spark.

Почему сейчас столь популярен Spark? Представьте, что у вас есть кластер Hadoop, в частности, есть HDFS-система, в которой лежит множество логов. И вы хотите делать какие-то итеративные вычисления. Что-то взять, посчитать что-то по этим данным, а затем положить результат обратно. Все алгоритмы машинного обучения итеративны — для них это оптимальная схема работы. Многие из вас знают, что читать данные с диска в ОЗУ, и затем выгружать данные на диск — это достаточно дорогие операции.

Что позволяет делать Spark? В вашем кластере помимо большого числа недорогих жестких дисков есть оперативная память. Фреймворк Spark грузит данные в оперативную память и в ней работает. На диск будет затем записан только конечный результат множества различных операций. Это серьезно сокращает число операций I/O. Это обеспечило Spark немалую популярность. Из других плюсов — Spark очень неплохо подключается к Hive-таблицам, можно прямо из Spark доставать данные из кластера. Код на Spark лаконичный. В Spark есть немало библиотек, в частности в нем есть модуль «рекомендательная система», которой можно «скормить» ту таблицу о которой мы ранее говорили (пользователи/фильмы/оценки), и этот модуль выдаст некие рекомендации.

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

Рекомендательную систему решили написать на языке Hive. SQL-запросы поверх больших таблиц писать проще, они выразительнее и понятнее, чем даже Python-код на Spark.

Все, что можно сформулировать в виде SQL-запроса считается алгоритмом быстро. Минус в том, что если в SQL-виде запрос написать не получается, то придется писать UDF (User-Defined Function) на Java.

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

40% Apache Spark (Python) + 50% Hive on TEZ + 10% Hive UDF (Java)

Плюсы такого подхода. Удобно парсить данные в Spark на Python. Далее эти данные можно сложить в Hive-таблицу и работать с ними SQL-запросами. И поскольку данные хранятся в кластере, с ними можно вести любые ETL-работы, готовить их так, как нам необходимо. Это занимает чуть не половину всего времени и делается инструментом Hive, который близок аналитикам, знакомым с SQL-запросами к корпоративному хранилищу.
Если возникают сложности, то пользуются Hive UDF, для сложных преобразований.

Достигается 70% переиспользование кода на пути от прототипа к продакшену, как правило, на UDF переписываются только критичные по производительности и не очень сложные функции, которые универсальны. В отличие от ML, где зачастую прототип приходится затем переписывать на продуктовой стадии на других языках программирования, в случае с Apache Spark мы изначально работаем с производительной структурой и потому формируемый алгоритм, как только он начинает работать, можно будет довести до продуктивного решения сравнительно быстро.

Математики могут улучшать алгоритм, если конечно они знают Python и SQL!

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

Про внедрение рекомендательной системы и вопросы консультанту

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

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

Второе. Все начиналось с Hadoop/Java. Но Java — это время. В смысле — большие затраты времени. На Java программировать долго. Да, она стабильна, она надежна. Но когда система динамически меняется, а это с рекомендательными системами случается сплошь и рядом, то Java — не лучший инструмент. Но другие инструменты практически все «в процессе развития».

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

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

Как оценить качество работы рекомендательной системы?

Нам нужно прогнозировать, какую оценку поставил пользователь u фильму i ? Т.е. нам нужно уметь спрогнозировать число. Т.е. это задача регрессии. Как оценить прогноз, который сделает наш алгоритм.

оценка алгоритма

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

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

Поэтому всякий раз, когда речь идет о задачах машинного обучения, желательно смотреть не на одну, а на несколько различных метрик. В частности на известные метрики Precision и Recall. Для множества рекомендованных объектов R и множества объектов, которые на самом деле нравятся пользователю:

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

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

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

Проблемы при запуске рекомендательных систем

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

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

Далее возможны варианты. Например, можно экспертным путем определить стереотипы, пример — предлагать мультфильмы только людям моложе X лет. Некоторые до сих пор так работают.

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

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

Источник

Data Scientist # 1

Машинное обучение, большие данные, наука о данных, анализ данных, цифровой маркетинг, искусственный интеллект, нейронные сети, глубокое обучение, data science, data scientist, machine learning, artificial intelligence, big data, deep learning

Данные — новый актив!

Эффективно управлять можно только тем, что можно измерить.
Copyright © 2016-2021 Data Scientist. Все права защищены.