Valuable insights
1.Отказ от подрядчика в пользу собственной разработки рекомендаций: Переход на внутреннюю разработку систем рекомендаций позволил компании отказаться от дорогостоящего подрядчика и начать получать прямую выгоду от улучшений, избегая ежемесячных платежей.
2.Проблемы с подрядчиком: высокая стоимость и негибкость: Работа с внешним подрядчиком оказалась дорогостоящей и медленной, особенно при необходимости реинтеграции после смены юридического лица партнера, что растянуло запланированный месяц работы почти на полгода.
3.Итеративный подход: от простого к сложному в рекомендациях: Стратегия заключалась в последовательной реализации: сначала замены товаров, затем комплементарные товары, и только потом переход к сложным персонализированным моделям, начиная с самого простого.
4.Успех первой итерации: рост конверсии на 7% с заменами: Внедрение базового алгоритма для рекомендаций заменителей товаров, основанного на TF-IDF и косинусном расстоянии, сразу дало рост конверсии в покупку на 7% в A/B тестах.
5.Вторая итерация: ассоциативные правила для комплементарных товаров: Использование ассоциативных правил (Support, Confidence, Lift) позволило рекомендовать сопутствующие товары, однако первоначальный тест показал падение конверсии на 10% по сравнению с подрядчиком.
6.Переход к коллаборативной фильтрации и учету интересов: Для комплементарных рекомендаций была внедрена модель LightFM, учитывающая устаревание интересов пользователей с помощью экспоненциального взвешивания, что значительно повысило ключевые бизнес-метрики.
7.Значительный рост метрик после внедрения персонализации: Персонализированные рекомендации привели к росту CR в покупку на 56% относительно рекомендаций подрядчика и увеличению среднего чека на 3% на этапе чекаута.
8.Важность определения конкурентного преимущества для in-house решений: Решение о разработке in-house должно основываться на том, является ли система рекомендаций ключевым конкурентным преимуществом бизнеса, а не просто фоновой функцией, которую можно купить.
Контекст и причины отказа от подрядчика
Доклад посвящен процессу создания внутренних систем рекомендаций, что позволило отказаться от услуг подрядчика и получить дополнительную экономическую выгоду. X5 Digital, являясь частью X5, отвечает за онлайн-каналы, включая мобильные приложения сетей «Пятёрочка» и «Перекрёсток» (Perekrestok.ru). Различные форматы доставки, такие как экспресс-доставка в течение часа и доставка больших объемов товаров, требуют надежных персонализационных решений.
Исходная модель рекомендаций от подрядчика
На начальном этапе компания использовала услуги внешнего подрядчика, который предоставлял рекомендации в двух точках: на карточке товара и в процессе оформления заказа (чекаут). Предлагаемые виды рекомендаций включали альтернативные товары (замены), комплементарные товары (допродажи, например, чипсы к пиву) и персональное ранжирование этих двух алгоритмов.
Работа с подрядчиком для нас была дорого, больно и долго.
Кризис интеграции и решение о переходе
Необходимость реинтеграции возникла из-за того, что подрядчик сменил российское юридическое лицо, что потребовало повторной интеграции их 'коробочных' алгоритмов. Первоначально на интеграцию и настройку логов отводился месяц, однако из-за доработки фидов и изменения кастомных событий процесс затянулся почти на полгода. Этот опыт убедил руководство в необходимости перехода на in-house разработку.
- Доработка фидов, отправляемых подрядчику.
- Доработка событий, отправляемых подрядчику.
- Настройка кастомных событий, критичных для бизнеса.
Итерация 1: Реализация рекомендаций заменителей (In-house)
Первым шагом в переходе к in-house разработке стали рекомендации заменителей товаров, поскольку обеспечение стопроцентной доступности полки является сложной и дорогостоящей операционной задачей. Принцип заключался в том, чтобы начать с простого, чтобы быстро получить обратную связь. Задача фокусировалась на получении рекомендованных товаров (item-to-item).
Техническая реализация первого шага
Использовались данные о товаре с применением TF-IDF преобразования для оценки важности слов и получения векторов. Эти векторы сохранялись в PostgreSQL. Сервис на Python отдавал рекомендации, используя косинусное расстояние для поиска 100 похожих товаров. Однако производительность Python и выдача из БД не соответствовали требованиям по задержке (latency).
Обновленная схема позволила сервису генерации рекомендаций запускаться только в момент необходимости, записывать результаты в Kafka, а API работало только с каталогом и кэшем. Тестирование показало, что такая схема выдерживает нагрузку.
Результаты A/B теста для заменителей
В A/B тесте на карточке товара 50% пользователей видели рекомендации in-house, а 50% — рекомендации подрядчика при отсутствии основного товара. Первый успех заключался в том, что конверсия в покупку с рекомендации выросла на 7% относительно рекомендаций подрядчика. Это подтвердило рабочий подход, начиная с простого.
Итерация 2: Комплиментарные товары через ассоциативные правила
Следующим шагом стало внедрение комплементарных рекомендаций для увеличения среднего чека, например, рекомендации картофеля к котлетам. Задача трансформировалась в оценку совместной встречаемости товаров в корзинах клиентов, сохраняя при этом простоту архитектуры, подтвержденную на первом этапе.
Применение ассоциативных правил
Для оценки совместных покупок применяются классические метрики ассоциативных правил. Support показывает частоту встречи пары товаров в чеках. Confidence измеряет вероятность покупки рекомендуемого товара при условии наличия исходного товара в корзине. Lift дополняет Confidence, показывая меру увеличения вероятности совместной покупки.
Инфраструктурные изменения и проблемы
Основной проблемой реализации является необходимость хранения и расчета матрицы размером «товары на товары», что требует значительного потребления памяти. Кроме того, возникла проблема «длинного хвоста»: около 30% товаров отсеивалось по минимальному порогу Support. Это решалось снижением порога в 10 раз и добиванием недостающих рекомендаций популярными товарами.
A/B тест показал, что конверсия в покупку упала на 10% по сравнению с подрядчиком, хотя общая экономика продукта оставалась в плюсе из-за отказа от оплаты услуг подрядчика. Это указало на необходимость дальнейшей проработки моделей.
Итерация 3: Персонализация с учетом устаревания интересов
Неудовлетворительные результаты по комплементарным товарам побудили к переходу к более сложным, персонализированным рекомендациям, чтобы обеспечить актуальность предложений для пользователя в конкретный момент времени. Задача трансформировалась в коллаборативную фильтрацию с учетом устаревания интересов.
Моделирование и учет динамики интересов
Для решения задачи была выбрана модель LightFM, поскольку она обеспечивает минимальную проблему холодного старта. Для учета актуальности интересов вводится взвешивание пользовательских взаимодействий, которое стремится к минимуму, когда пользователь давно не покупал товар. Это реализуется через экспоненциальное затухание веса взаимодействия.
- Использование экспоненты в степени минус количества дней с момента последней покупки, деленного на параметр B.
- Параметр B позволяет подбирать скорость угасания интересов: чем меньше B, тем быстрее интерес угасает (график прижимается к оси Y).
Результаты персонализированного A/B теста
В A/B тестах для авторизованных пользователей с более чем двумя покупками применялись персональные рекомендации, а для остальных — базовый алгоритм (CreLL). Результаты оказались ошеломляющими: CR в покупку вырос на 56% относительно персональных рекомендаций подрядчика, а средний чек на чекауте увеличился на 3%.
- Формулировка критериев отбора моделей (например, минимальный холодный старт) помогает выбрать оптимальный путь (LightFM соответствовал этому критерию).
- Даже базовая модель в рамках in-house разработки работает лучше, чем отсутствие каскада у подрядчика.
Общие выводы и принятие решений о in-house разработке
Переход от подрядчика является относительно недорогим удовольствием, поскольку базовые in-house алгоритмы, реализованные небольшой командой, превосходят внешние решения. Это позволяет бизнесу выигрывать за счет увеличения прибыли и экономии на оплате услуг сторонней компании. Важно придерживаться подхода от простого к сложному через частые итерации.
Стратегические рекомендации по разработке
- Если система рекомендаций не является ключевым конкурентным преимуществом, нет смысла тратить ресурсы на собственную разработку.
- Инфраструктурный технический долг (например, использование крон-задач вместо Airflow) допустим на начальном этапе проверки гипотез.
- В случае невозможности превзойти подрядчика, можно использовать его данные для обучения собственных моделей.
В ходе обсуждения также был затронут вопрос о пост-ранжировании с учетом бизнес-метрик и потенциальном использовании эмбеддингов фотографий, что рационально для подбора альтернативных товаров, где визуальное соответствие играет роль.
Questions
Common questions and answers from the video to help you understand the content better.
Как принимается решение о целесообразности разработки рекомендательной системы in-house, а не покупки готового решения у подрядчика?
Ключевым фактором является определение того, насколько система рекомендаций составляет конкурентное преимущество для бизнеса. Если это ядро бизнеса, следует делать in-house; если это фоновая функция, лучше купить готовую коробку.
Каким образом учитывается устаревание интересов пользователя при внедрении персонализированных рекомендаций с помощью LightFM?
Учитывается экспоненциальным взвешиванием взаимодействий: вес покупки уменьшается экспоненциально с увеличением количества дней с момента последней покупки, что позволяет адаптировать модель под разные форматы доставки.
Почему при переходе на комплементарные рекомендации на основе ассоциативных правил наблюдалось падение конверсии на 10% по сравнению с подрядчиком?
Это могло произойти потому, что модель подрядчика использовала персонализированное ранжирование поверх своих базовых алгоритмов, в то время как внутренняя модель на первом этапе использовала только базовые метрики (Support, Confidence, Lift) без ранжирования.
Планируется ли учитывать визуальную составляющую товаров (фотографии) при формировании альтернативных рекомендаций?
Да, использование эмбеддингов фотографий рассматривается как рациональный шаг, особенно для альтернативных товаров, поскольку пользователь выбирает «глазами», и дизайн может влиять на решение о замене товара.
Как решается проблема «длинного хвоста» и нехватки рекомендаций для товаров с низким показателем поддержки при использовании ассоциативных правил?
Проблема решается путем снижения минимального порога поддержки в 10 раз для несформированных товаров, а недостающие рекомендации добиваются за счет добавления популярных товаров в выдачу.
Useful links
These links were generated based on the content of the video to help you deepen your knowledge about the topics discussed.