5

Я использую Spark для создания прототипа системы рекомендаций. Пройдя несколько уроков, я смог подготовить MatrixFactorizationModel по моим данным.Spark - Как использовать подготовленную модель рецептора в производстве?

Однако модель, подготовленная Spark mllib, является только Serializable. Как я могу использовать эту модель для рекомендации для реальных пользователей? Я имею в виду, как я могу сохранить модель в какой-то базе данных или обновить ее, если пользовательские данные были увеличены?

Например, модель, подготовленная библиотекой рекомендаций Mahout, может быть сохранена в таких базах данных, как Redis, после чего мы можем запросить список рекомендуемых элементов позже. Но как мы можем делать подобные вещи в Spark? Любое предложение?

ответ

8

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

Но я согласен, что во многих случаях вы хотите отправить модель в другое место и обслуживать ее. Как вы видите, другие модели в Spark: Serializable, но не MatrixFactorizationModel. (Да, даже если он помечен как таковой, он не будет сериализоваться.) Аналогичным образом, существует стандартная сериализация для прогнозируемых моделей под названием PMML, но в ней нет словарного запаса для модели с факторизацией.

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

Аналогично, в Spark это означает, что фактические матрицы - это RDD s, которые не могут быть сериализованы напрямую. Вы можете сохранять эти RDD на хранение, перечитывать их в другом месте с помощью Spark и вручную воссоздать MatrixFactorizationModel.

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

Я не против предлагать здесь проект Oryx, поскольку его задача заключается в том, чтобы управлять именно этим аспектом, в частности для рекомендации ALS. Фактически, проект Oryx 2 основан на Spark и хотя в alpha уже содержит полный конвейер для сериализации и служит для вывода MatrixFactorizationModel. Я не знаю, соответствует ли это вашим потребностям, но может быть, по крайней мере, интересной точкой отсчета.

+0

Спасибо за отличное и подробное объяснение! Я попробую Oryx :) – shihpeng

2

Другим способом создания речей с помощью Spark является метод поисковой системы. Это в основном рекомендация cooccurrence, поданная Solr или Elasticsearch. Сравнение факторизованного с cooccurrence выходит за рамки этого вопроса, поэтому я просто опишу последний.

Вы передаете взаимодействия (идентификатор пользователя, идентификатор объекта) в файл spark-itemsimilarity Махута. Это создает список аналогичных элементов для каждого элемента, отображаемого в данных взаимодействия. Он будет отображаться по умолчанию как csv и поэтому может быть сохранен в любом месте. Но он должен быть проиндексирован поисковой системой.

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

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

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

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

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

Описания здесь:

0

Вы можете использовать функцию .save (sparkContext, outputFolder), чтобы сохранить модель в папке по вашему выбору. Предоставляя рекомендации в реальном времени, вам просто нужно использовать MatrixFactorizationModel.load (sparkContext, modelFolder) функция для загрузки его как объекта MatrixFactorizationModel.

Вопрос к @Sean Owen: Разве не MatrixFactorizationObject содержат матрицы Факторизации: пользователь функции и п-функциональные матрицы вместо рекомендаций/предсказанных рейтинги.

Смежные вопросы