Инкрементальная подготовка модели ALS

Я пытаюсь выяснить, возможно ли "инкрементное обучение" с использованием MLlib в Apache Spark.

Моя платформа - это Prediction IO, и это в основном оболочка для Spark (MLlib), HBase, ElasticSearch и некоторых других полезных частей.

В моем приложении данные "события" вставляются в режиме реального времени, но для получения обновленных результатов прогнозирования мне нужно "pio train" и "pio deploy". Это занимает некоторое время, и сервер отключается во время повторного развертывания.

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

ОТВЕТЫ

Ответ 1

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

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

Итак, зная это, мы можем искать альтернативы, один рейтинг не должен сильно изменять матрицы, плюс мы имеем подходы оптимизации, которые являются инкрементальными, например SGD. Есть интересная (все еще экспериментальная) библиотека, написанная для случая явных рейтингов, которая делает инкрементные обновления для каждой партии DStream:

https://github.com/brkyvz/streaming-matrix-factorization

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

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

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

Интересные заметки для обновлений SGD:

http://stanford.edu/~rezab/classes/cme323/S15/notes/lec14.pdf

Ответ 2

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

Ou Вы можете посмотреть код:

  • MyMediaLite
  • Oryx - создание фреймворка с парадигмой архитектуры Lambda. И он должен иметь обновления с вставкой новых пользователей/элементов.

Это часть моего ответа для аналогичных question, где были устранены обе проблемы: почти онлайн-обучение и обработка новых пользователей/элементов.

Ответ 3

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

http://ieeexplore.ieee.org/document/7840707/