«Проблема оказалась в контенте, а не в модели»: Amazon Payments поднял конверсию воронки контекстными бандитами

Выбор стал сложнее генерации

Генеративный ИИ сделал массовое производство персонализированного контента быстрым и дешёвым, и на этом задача сместилась: среди всех вариантов нужно решить, какой именно показать конкретному клиенту, и как быстро узнать ответ. Именно проблемой выбора занимается новый материал AWS, продолжающий предыдущую публикацию о генерации персонализированного контента на Amazon Bedrock.

Amazon Payments применила ИИ-персонализацию к воронке приобретения продукта с помощью многоцелевого контекстного многорукого бандита (multi-armed bandit, MAB) на Amazon SageMaker AI. В семинедельном онлайн-тесте A/B у одной группы клиентов наблюдается относительный рост конверсии на последнем шаге воронки в верхнем однозначном диапазоне процентов, тогда как вторая группа не показала улучшения относительно существующего опыта. Как формулирует AWS, проблема оказалась в контенте, а не в модели.

Почему бандит, а не классический A/B-тест

Многорукий бандит — метод обучения с подкреплением для ситуаций, когда вариантов много, а трафика мало. Каждый вариант контента считается «рукой»: бандит пробует руки на живом трафике и постепенно смещает показы к выигрывающим, удерживая долю трафика на проверку остальных. Это и есть компромисс между эксплуатацией, то есть показом текущего лучшего варианта, и исследованием ради сбора доказательств. Бандит не прекращает делать и то и другое, поэтому улучшается по мере добавления вариантов и не обязан ждать завершения теста; классическому A/B/n-тестированию место остаётся, но с ростом числа вариантов, который ускоряет генеративный ИИ, роль бандитов, по ожиданиям AWS, будет расти.

Для Amazon Payments выбран метод Upper Confidence Bound: он берёт руку с наибольшей оценкой награды плюс надбавку за неопределённость, естественным образом балансируя исследование и эксплуатацию. Детерминированное правило выбора даёт проверяемое и воспроизводимое решение для каждого показа, так что любое решение о выдаче контента можно объяснить и повторить. Ограничение обычного бандита в том, что он ищет одну лучшую руку для всей аудитории; персонализация требует учитывать, кто именно пришёл, — для этого служат контекстные бандиты.

Контекст и LinUCB

Контекстный бандит вместо вопроса «какой контент лучший вообще» опирается на признаки визита. Сегментные бандиты держат отдельный экземпляр на каждую группу, но группы задаются вручную, произвольны и каждой нужен свой трафик; контекстный бандит обусловливается сразу вектором признаков (feature vector), поэтому закономерность, выученная в одном контексте, переносится на все похожие визиты без отдельного трафика на группу. В проде Amazon Payments каждый клиент представлен вектором поведенческих сигналов — платёжное поведение, структура транзакций и подобные признаки, — а идентификатор entity_id используется только для маршрутизации рекомендации к нужному посетителю и никогда не подаётся на вход модели.

Из контекстных методов выбран Linear UCB (LinUCB), предложенный Ли и соавторами в 2010 году. Это вычислительно эффективный и проверяемый метод с детерминированным выбором руки, который справляется с большим пространством рук при малых данных для «разогрева». Его ключевое допущение — ожидаемая награда руки линейна по вектору контекста, что даёт обобщение на посетителей, которых модель ещё не видела.

Каждая рука ведёт две накопительные таблицы: b — реестр наград, который показывает, какие сигналы посетителей приводили к конверсиям, и A — реестр опыта, фиксирующий, каких посетителей рука уже видела. Деление награды на опыт даёт оценку θ = A⁻¹·b, а накопленный опыт одновременно уменьшает надбавку за исследование. Итоговая оценка руки складывается из оценки и надбавки за неопределённость, и надбавка зависит от контекста: она велика для типа посетителей, которых рука видела редко, и мала для тех, кого видела часто. Обычный бандит исследует с единой глобальной скоростью, а LinUCB подстраивает объём исследования под каждого посетителя.

Оптимизация всей воронки, а не одной метрики

Путь клиента в этом сценарии состоит из трёх шагов: старт заявки, отправка и одобрение. Значит, цель является многоступенчатым исходом, а не одной метрикой, и ступени движутся не синхронно: контент, оптимизированный под старт заявок, привлекает широкую аудиторию, тогда как одобрение зависит от того, действительно ли предложение подходит заявителю. Оптимизация одной ступени в изоляции может ухудшить другую — в публикации это названо проблемой качелей (seesaw problem). Обратная крайность тоже плоха: оптимизация только по одобрениям лишает модель сигнала, потому что одобрения редки и запаздывают.

Подход Amazon Payments оптимизирует всю воронку сразу: на каждую ступень работает своя модель LinUCB, а их оценки UCB складываются линейной комбинацией с весами ступеней — selected_arm = argmax по рукам от суммы w_start·UCB_start(a, x) + w_submit·UCB_submit(a, x) + w_approve·UCB_approve(a, x). Веса можно назначать по бизнес-приоритетам или подбирать отдельной калибровкой; здесь использованы примерно равные, а heavier-вес на одобрениях AWS предлагает вводить по мере «прогрева» модели или применять границу Парето, если компромисс действительно спорный.

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

Пул рук, надзор и продовая архитектура

Бандит хорош ровно настолько, насколько хорош пул вариантов, поэтому контент собирается из небольшого набора проверенных блоков: изображений на отраслевую тему и теглайнов о выгодах. Пространство рук — декартово произведение этих частей, то есть каждая рука является парой «изображение + теглайн», и скромное число блоков даёт крупный пул различных страниц. Надзор при этом масштабируется за счёт проверки частей, а не комбинаций: отдельные блоки согласуются заранее, а их число остаётся малым и обозримым, тогда как число сочетаний растёт быстро. Целостность внешнего вида обеспечивает дизайн-система — утверждённые цвета, макеты, компоненты и паттерны.

В проде используется пакетная архитектура: недельная задача Amazon SageMaker AI Processing читает результаты клиентов из Amazon S3, обновляет модель и публикует персональные рекомендации в низколатентное key-value-хранилище. Выбор в пользу пакета объясняется двумя причинами — офлайн-природой задачи выбора, где обратная связь накапливается днями, и тем, что поведение посетителей не меняется настолько быстро, чтобы требовать обновления модели в реальном времени. Версия модели хранится в датированных путях Amazon S3, что даёт встроенную историю версий и простой откат, а страница отдаётся одним поиском по entity_id без инференса в реальном времени.

Модели «прогревали» периодом случайного назначения контента — несмещённые данные позволяют бандиту инициализировать представления без смещения отбора и эффективнее тратить бюджет исследования. Чтобы вписаться в бюджет по вычислениям, обратные матрицы по рукам считаются один раз на пакет, а множество потенциальных клиентов режется на блоки и оценивается параллельно через multiprocessing.Pool. Отдельно отмечена защита от просадки: если рекомендации для посетителя нет, страница отдаёт стандартный статический опыт, поэтому ни один клиент не оказывается в худшем положении, чем на базовой линии.

Что показал эксперимент

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

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

Отдельно отмечена интерпретируемость: выученные векторы θ в LinUCB читаются напрямую — большой положительный вес признака означает, что клиенты с сильным таким сигналом чаще конвертируются на этой руке, поэтому через несколько недель можно предметно спросить, какие сигналы отличали отреагировавших на конкретное изображение. Наконец, AWS настаивает, что пакетный режим — полноценный способ эксплуатации: недельная задача обработки, обновляющая модель точными инкрементальными шагами и записывающая рекомендации в Amazon S3, оказалась проверяемой, экономной по ресурсам и естественной для запаздывающей обратной связи.