Построение рекомендательного движка продуктов с использованием Apache Cassandra и Apache Pulsar

Recommendation engine using Apache Cassandra and Apache Pulsar

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

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

Проблема

Это первый день в BigBoxCo в команде “Инфраструктура”. После выполнения обязательных действий в отделе кадров я получил пропуск и направился к своему новому рабочему месту. Познакомившись с командой, мне сообщили, что у нас сегодня утром запланирована встреча с командой “Рекомендации”. Мои права доступа к системе еще не работают, поэтому, надеюсь, IT решит эту проблему пока мы находимся на встрече.

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

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

Рекомендации по продуктам предоставляются пользователям на bigboxco.com через слой микросервисов в облаке. Слой микросервисов использует локальный (облачный) центр обработки данных Apache Cassandra для предоставления результатов.

Однако то, как собираются и предоставляются результаты, совсем другая история. По сути, результаты ассоциаций между продуктами (приобретенными вместе) компилируются во время задачи MapReduce. Это пакетный процесс, который потерпел неудачу на прошлой неделе. Хотя этот пакетный процесс никогда не работал быстро, со временем он стал медленнее и более хрупким. Фактически, иногда процесс занимает два или даже три дня.

Улучшение опыта

После встречи я проверил свой компьютер и, похоже, наконец-то мог войти в систему. Пока я разглядывал, к нам подошел главный инженер (PE) и представился. Я рассказал ему о встрече с командой “Рекомендации”, и он рассказал мне немного больше о истории сервиса “Рекомендации”.

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

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

Он кивает в знак согласия и говорит, что он определенно открыт для предложений по улучшению системы.

Возможно, проблема с графом?

На первый взгляд, это звучит для меня как проблема с графом. У нас есть клиенты, которые входят на сайт и покупают продукты. До этого, когда они просматривают продукт или добавляют его в корзину, мы можем показать рекомендации в виде “Клиенты, которые купили X, также купили Y”. Сайт уже имеет это, поскольку сервис рекомендаций делает именно это: он возвращает четыре дополнительных продукта, которые часто покупаются вместе.

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

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

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

Но, возможно, эту графическую модель можно использовать и здесь. Фактически, описанный выше подход является техникой машинного обучения (ML), известной как “коллаборативная фильтрация”. В основе коллаборативной фильтрации лежит исследование сходства определенных объектов данных на основе активности с другими пользователями, что позволяет нам делать прогнозы на основе этих данных. В нашем случае мы будем неявно собирать данные о корзине/заказе от нашей клиентской базы и будем использовать их для предоставления лучших рекомендаций по продуктам для увеличения онлайн-продаж.

Реализация

Прежде всего, давайте рассмотрим сбор данных. Добавление дополнительного вызова сервиса к функции “оформить заказ” вполне нормально. Фактически, он уже существует; просто данные хранятся в базе данных и обрабатываются позже. Но нельзя ошибиться: мы всё же хотим включить пакетную обработку. Но мы также хотим обрабатывать данные о корзине в реальном времени, чтобы мы могли сразу же вернуть их в онлайн-набор данных и использовать их непосредственно после этого.

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

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

Расширение существующей системы рекомендаций с пакетной обработкой с помощью Apache Pulsar и Apache Cassandra.

Затем мы можем запросить эту таблицу для определенного продукта (“DSH915” в данном примере), например, так:

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

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

Выводы и следующие шаги

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

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

Еще одним улучшением в будущем могло бы быть внедрение платформы искусственного интеллекта/машинного обучения в реальном времени, например, Kaskada, чтобы обрабатывать как потоковую связь продуктов, так и служить рекомендациями непосредственно службе.

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

В следующей статье мы рассмотрим улучшение продуктовых акций с помощью векторного поиска.