Каждый месяц в игры внутри приложения Альфа-Банка заходят миллионы пользователей. В игре человек выполняет задания ради бонусов или энергии, а для банка эти задания — реальные действия: оплата ЖКХ, заправка через приложение или заказ новой карты. Это отличный способ нативно продвигать продукты без назойливых рекламных баннеров.

Если в играх мало заданий, то их можно просто показать всем. Но когда механик становится много, появляется классическая рекомендательная задача: что именно предложить конкретному клиенту, в каком порядке, и как оценить эффект?

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

Немного про игры

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

Внутри приложения Альфа-Банка периодически запускаются игры. Они могут существовать в приложении несколько месяцев и иногда перезапускаться. Как уже упоминалось выше, в  играх есть задания, и за их выполнение пользователь получает игровые ресурсы: энергию, внутриигровую валюту или призы. То есть мотивация у игрока игровая, а ценность для банка — продуктовая.

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

Игра № 1 — «Ассоциации». Игра в стиле «Угадай слово». Есть загаданное понятие, игрок вводит слова, а игра подсказывает, насколько он близок: «холодно», «тепло», «горячо». Задания лежат в отдельной вкладке: пользователь видит сразу несколько карточек и сам выбирает, какое выполнять.

Игра №2 — «Это мошенники». Здесь механика иная: на поле нужно соединять одинаковые предметы, чтобы получать новые (три предмета, называемых Мини‑Грин, складываются в письмо и так далее). Помимо канала продаж у игры есть образовательная часть: сюжет обыгрывает разные схемы мошенников, например, вам звонит «банк», «необходим» срочно перевод средств на безопасный счет и прочие уловки. В отличие от «Ассоциаций», задания выдаются по одному — по мере прохождения уровней. Поэтому порядок показа становится не вариацией оформления с сомнительной пользой от перестановки местами заданий (мы проверили, пользователь в состоянии долистать список до конца и в списке заданий порядок ему не важен), а действительно важной механикой.

Решаем задачу рекомендательных систем

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

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

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

Первая математическая постановка получается простой. Для пользователя u и задания a хотим оценить вероятность целевого действия y после показа:

А дальше выбрать задание с максимальной оценкой:

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

Успех стратегии «покажем всё» и отказ от нее

Еще во время постановки задачи возникло желание проверить гипотезу о том, что максимальная конверсия будет в случае, если дать клиенту выбирать самостоятельно. Здесь нужно будет забежать вперед и сказать, что в игре «ассоциации» нам удалось пропилотировать её сразу вместе с моделями. Ожидаемо, так и случилось — общая конверсия в группе с показом всех заданий оказалась лучше.

На этом месте возникает логичный вопрос: «Зачем тогда вообще нужен ML?».

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

В базовом варианте мы хотим максимизировать следующую величину:

Где ожидаемую доходность можно разложить как:

Здесь:

• P(y = 1 | u, a) — вероятность того, что пользователь выполнит задание;

• value(a) — бизнес-ценность действия;

• cost(a) — стоимость бонуса.

И здесь стратегия «покажем всё» начинает быть не такой выгодной — она даёт пользователю максимальную свободу, но почти не позволяет управлять тем, какие именно продуктовые сценарии получают внимание. Более того, при росте числа заданий она начинает упираться в интерфейс, ограниченность внимания пользователя и интересы разных продуктовых команд одновременно.

Одна модель на все задания

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

Первый напрашивающийся ML-вариант — обучить одну модель, добавить тип задания как признак, и попросить её предсказывать отклик. На схеме всё удобно: один пайплайн, одна модель, один скоринг, один способ деплоя.

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

Мы пробовали бороться с этим весами классов с помощью under- и oversampling заданий и отдельной настройкой loss. В чём-то становилось лучше, но процесс явно выглядел не оптимальным — нужно было подобрать веса для десятка типов заданий и каждое в комбинации с несколькими играми при достаточно долгом обучении. Также совершенно не прозрачно выглядел процесс перенастройки весов в случае добавления новых параметров.  

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

Почему мы ушли в отдельные бинарные модели

В итоге рабочий вариант оказался более приземленным — отдельная бинарная модель на каждый тип задания.

Для оплаты ЖКУ своя модель, для брони отелей своя, для реферальной программы своя, и так далее. На выходе каждая модель отдает склонность конкретного пользователя выполнить конкретное целевое действие.

Это не самая элегантная архитектура, зато очень понятная в эксплуатации.

• Появился новый продукт — добавили модель.

• По одному продукту качество просело — чиним его, не трогая остальные.

• Где данных мало — отдельно думаем про то, что с этим делать.

• Где продукты похожи друг на друга — можно обсудить объединение.

В банке такая управляемость иногда важнее архитектурной красоты.

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

Главный минус — появляется много моделей, которые нужно обучать, версионировать, валидировать, переобучать, деплоить, мониторить..

С практической точки зрения это компромисс: больше сущностей в поддержке, зато меньше проблем внутри каждой сущности.

Калибровка

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

Для проверки я сравнивал оригинальные скоры и после калибровки с помощью sigmoid и isotonic. Выбор делали по Brier Score:

Интересный для меня практический момент был в том, что бустинг часто отдавал вполне приличные вероятности и без дополнительной калибровки. Не всегда, но достаточно часто, чтобы не считать калибровщик автоматическим улучшением. Иногда оригинальные скоры из бустинга были лучше (иногда помогали sigmoid или isotonic).

Отдельно мы старались сделать одинаковую логику взаимодействия с моделями. Когда моделей много, не хочется, чтобы каждая жила в своем API и требовала отдельной ветки кода. Поэтому снаружи весь зоопарк  должен выглядеть одинаково: пришли признаки — вернулась вероятность.

Неприятная часть здесь в переносимости отклика между играми. Если в одной игре задание про оплату ЖКУ хорошо откликается из‑за конкретной механики, то это не значит, что в следующей игре шкала вероятностей останется такой же. Она была очевидна при разработке ещё во время попытки создания одной модели с тонкой настройкой весов каждому объекту. Но я все же упустил этот момент при калибровке скоров и вскрылся он лишь на пилотах.

Multiclass, multilabel и learn-to-rank. Почему не они?

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

Multilabel ближе к реальности. Там модель может сказать: «По этому пользователю есть склонность к нескольким заданиям сразу». На выходе получаются K вероятностей:

И да, дальше их можно ранжировать.

Минусы в другом.

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

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

Learn-to-rank методологически ближе к задаче, потому что мы хотим порядок элементов. Но для нормального LTR нужны логи, где для каждой сессии понятен набор кандидатов, порядок показа, позиция, действие пользователя и желательно вероятность того, почему именно такой порядок был выбран. Иначе мы обучаем ранжирование на следах старой политики.

Для pairwise/listwise-подходов хочется иметь наблюдения вида:

У нас на первой итерации такой чистой постановки не было. Поэтому LTR не «хуже», он просто требовал более правильного сбора данных и более зрелого эксперимента, чем отдельные бинарные модели.

Uplift и bandits

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

Это uplift-постановка:

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

Bandits звучат еще соблазнительнее: есть набор действий, есть награда, алгоритм постепенно учится, что показывать чаще. На формуле всё красиво: минимизируем regret, то есть потери относительно лучшей стратегии.

Но дальше начинается инфраструктура. Бандиты хотят быстро получать фидбек, обновляться, контролировать exploration, логировать propensity и жить в контуре, где можно безопасно менять политику показа. Однако в нашем случае рекомендации готовятся заранее, игра выкатывается отдельным релизным процессом, быстрого reward не дождаться. Поэтому бандиты на данном этапе подходят лишь в теории.

Two-tower: сложность есть, а пользы нет

Two-tower-подход мы тоже попробовали. Вместе с @qeqochec быстро довели его до рабочего состояния. Но здесь наверно худшие результаты с точки зрения простоты разработки и эффекта, которого удалось достичь на коленке, за пару недель, чтобы понять, есть ли там быстрый выигрыш. Идея такая: одна башня кодирует пользователя в embedding, другая башня кодирует задание и/или игру, а дальше мы считаем близость между ними.

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

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

Как это оценивать?

На оффлайн-метриках всё не заканчивается. Да, можно смотреть Gini/AUC, PR_AUC и т.д., отдельно качество по продуктам. Но для этой задачи есть другая ловушка: модель может научиться находить просто активных клиентов. Такие клиенты и так чаще делают почти всё: платят, кликают, открывают продукты, заходят в приложение.

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

Условно для двух продуктов a и b можно смотреть:

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

Ещё одна проблема оффлайн‑оценки — мы видим результат старой политики показов. Пользователь выполнил или не выполнил то, что ему показали. А что было бы, если бы ему показали другое задание выше, мы не знаем. Поэтому оффлайн‑метрики здесь полезны как фильтр совсем плохих решений, но не как финальный судья. Финальный судья — пилот, A/B и бизнес‑метрики, если они корректно поставлены.

Пилоты: взгляд на результаты

Теперь можно приземлить это на пилоты. Практически каждый запуск игры шёл вместе с пилотом какой-либо механики рекомендаций. Детальнее расскажем о тех, которые упоминались выше. Они же — два первых пилота

Пилот в игре «Ассоциации»

Это та игра, которая позволила нам проверить гипотезу, что показывать всё скорее всего будет лучше. В ней мы сделали три группы. В тесте пользователю показывали 3 задания из 6 с максимальной склонностью по модели (моделям), в контроле — 3 случайных задания из тех же 6, а остальным клиентам оставили исходный вариант со всеми доступными заданиями.

Результат получился ожидаемый. На части действий модель дала заметный рост, например, по одному из сценариев покупки конверсия из показа в выполнение была около 2,4% против 0,5% в контроле, а абсолютных выполнений стало больше, хотя показов было примерно втрое меньше. По некоторым другим сценариям абсолютных выполнений тоже стало больше.

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

Самое интересное: группа с моделью была значительно сильнее контроля. А группа, где пользователю были доступны сразу все задания была ещё сильнее.  И тут возник вопрос, стоит ли сворачивать с ранее намеченного пути и двигаться дальше с показом всех заданий? Гибкое управление выдачей оказалось в приоритете.

Пилот в «Это мошенники»

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

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

После этого дизайн поправили: из тестовой группы исключили примерно нижние 20% клиентов по среднему скору склонности и показывали им задания, которые не приносят банку прибыли. На втором этапе статистически значимый рост появился ещё по нескольким заданиям.

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

Почему рекомендации ломаются в играх

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

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

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

Ещё один вопрос — что именно оптимизировать. Если максимизировать только вероятность выполнения задания, модель(и) будет предпочитать простые действия с быстрым откликом. Но бизнесу не всегда нужен самый легкий клик. Более честная функция могла бы выглядеть так:

Часть ее нам уже знакома. Это матожидание прибыли банка. А fatigue это условный штраф за раздражение, повторение или перегруз интерфейса. На данном этапе внедрение подобной метрики ещё на этапе обсуждения.

Что получилось и что бы я сделал иначе

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

Главное, что получилось: появилась управляемая первая версия.

• Новое задание можно добавить отдельной моделью.

• Проблемный продукт можно чинить отдельно.

• Результаты можно обсуждать по продуктам, а не только по одной общей метрике.

Пилоты это подтвердили не идеально, но подтвердили: модель местами давала кратный рост конверсии относительно случайного порядка, но всё же кое-где давала просадку.

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

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

Дальше я бы двигался не в сторону «давайте срочно сложнее», а в сторону более честной постановки.

• Сначала — ценность действия вместо одной конверсии. Если у разных заданий разная бизнес‑цена, ранжировать только по вероятности выполнения не совсем верно.

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

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

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

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

Если коротко: первая версия работает, но работает грубо. Она лучше случайной выдачи и лучше экспертной, но в ней много инженерных и методологических компромиссов.