40 экспериментов за 2 года: как мы строили рекомендательную систему в «Литрес»

Меня зовут Евгения, я менеджер продукта команды поиска и рекомендаций в группе компаний «Литрес», в которую входит один из крупнейших сервисов цифровых книг в России и странах СНГ. Ассортимент Литрес – более 1,7 миллиона единиц контента на русском и иностранных языках. Помимо поштучной продажи и выдачи по подписке электронных, аудиокниг, подкастов и комиксов, Литрес предоставляет возможность любому человеку самостоятельно и бесплатно опубликовать и продавать свою книгу с помощью проекта Литрес Авторы.

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

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

Рекомендательную систему можно рассматривать не просто как ML-модель, а как процесс, с помощью которого можно обеспечить рост бизнес и пользовательских метрик.

Мы начали активно заниматься рекомендациями 2 года назад. На тот момент было реализовано самое простое решение для двух сценариев – item-2-item, user-2-item – ALS-модель, которая отбирала кандидатов на основе алгоритма коллаборативной фильтрации.

Система имела ряд проблем. Например, мы могли рекомендовать пользователям книги, которые они уже прочитали, и редко обновляли рекомендации. Доля взятий книг из рекомендаций была небольшой – около 5%. Рекомендации мы не развивали, так как в тот момент фокусировались на других гипотезах.

Итак, у нас была простая система рекомендаций. Насколько хорошо она работала? Мы решили проверить. Для этого мы провели A/B-тест, в котором сравнили рекомендации с рандомной выдачей книг. Оказалось, что рекомендации работали – конверсия в покупку и взятие книг по подписке оказались в 2,5 раза выше, чем у рандомной выдачи. Таким образом, мы получили минимальный уровень качества, от которого могли отталкиваться.

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

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

Что мы учитывали при определении задач рекомендаций:

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

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

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

Что в неё входило:

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

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

Наши эксперименты разделялись на несколько групп:

Для того чтобы обеспечить непрерывность экспериментов, мы построили роадмап, где старались поддерживать баланс экспериментов разного масштаба. Мы стремились оставаться гибкими и корректировали дорожную карту по мере необходимости, постепенно добавляли в неё разные этапы, если понимали, что в них есть потребность. Например, мы внедрили этап post-launch после выкатки фичи на всех пользователей, в рамках которого мы наблюдали, нет ли различий с поведением, которое мы получили в рамках A/B-теста.

За 2 года мы провели около 40 разного вида экспериментов, в рамках которых мы выучили несколько уроков, выводами из них я бы хотела поделиться.

В одном из экспериментов, который касался проблемы разнообразия топа рекомендаций, мы планировали скрывать книги, которые пользователь видел в рекомендациях, но не стал с ними ничего делать. Оффлайн-прогноз показал, что за счёт такой ротации топ рекомендаций станет менее релевантным. Но когда мы внедрили это решение, эффект оказался обратным – ценность разнообразия для пользователей оказалась выше, чем статичная релевантность.

Оффлайн-метрики – это способ отбора и диагностики решений, но финальное качество продукта определяется онлайн-поведением пользователей.

В подобных проектах легко допустить ошибку на любом этапе и важно оставаться бдительным. Несколько раз мы попадали в ситуации, в которых не видели роста онлайн-метрики, хотя оффлайн-метрики прогнозировали рост. Во всех случаях мы находили проблемы на разных этапах: на уровне данных, интерпретации A/B-теста и др.

Чем сложнее изменения, тем сложнее понимать, что пошло не так в процессе релиза или проведения теста, если ожидания не совпали с реальностью. Например, мы внедряли feature store и совместно с этим в том же эксперименте проверяли новые фичи в модели. Проблемы в реализации feature store помешали нам оценить эффект от изменений модели.

Не стоит тратить время на A/B-тест, если изменение станет безусловным улучшением. Например, когда мы перестали рекомендовать книги, которые пользователи уже читали или отмечали прочитанными, рост метрик был виден невооружённым взглядом. Тестируйте гипотезы, в которых ответ неочевиден.

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

Одна из проблем, с которой мы столкнулись: алгоритмы рекомендаций и метрики, которые мы использовали, были сложными для понимания для бизнес-стейкхолдеров. Например, не было понятно, почему мы не можем предлагать в рекомендациях пользователям только что появившийся контент, который ещё никто не покупал. Будьте готовы объяснять механизмы работы и ограничения алгоритмов.

CES-оценка рекомендаций – популярный метод для сбора обратной связи от пользователей. В нашем случае было парадоксально, что по мере улучшения качества решения рекомендаций, по мере роста retention – CES-оценка пользователей практически не выросла. Мы сделали вывод, что не стоит искать прямую корреляцию между подобной оценкой и ростом пользовательских метрик, так как этот метод субъективен и подвержен множеству факторов. Сам метод мы продолжаем использовать и получаем с его помощью большое количество инсайтов.

За 2 года мы прошли большой путь – от простого решения рекомендательной системы до отлаженного процесса, в рамках которого команда умеет формировать и приоритизировать гипотезы и обеспечивать непрерывный поток экспериментов. За это время мы увеличили долю покупок из рекомендаций в 5 раз – с 5 до 25%.

К текущему этапу мы пришли за 4 шага:

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

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

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