Shadow, canary, A/B и бандиты: как безопасно выкатывать ML-модели

Допустим, команда несколько месяцев делала новую модель машинного обучения, и офлайн-оценка выглядит отлично: выше precision, выше recall, меньше ложных срабатываний и приемлемая задержка. Естественный вопрос: можно ли выпускать её в продакшен? Скорее всего, можно. Но за ним следует вопрос поважнее: отдавать ли ей сразу 100% продакшен-трафика? Обычно нет. Модель, которая блистает на исторических данных, может повести себя совсем иначе, столкнувшись с реальными клиентами, реальным трафиком, неожиданными входными данными, сбоями инфраструктуры и меняющимися распределениями данных.

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

• Теневое развёртывание (shadow) позволяет наблюдать за новой моделью, не действуя на основе её ответов.
• Canary-релиз открывает её небольшой доле живого трафика.
• A/B-тест сравнивает её со старой напрямую.
• Многорукий бандит по мере поступления результатов смещает трафик к тому, что работает лучше.

Сквозной пример: обнаружение мошенничества

Финансовая платформа обрабатывает 1 миллион транзакций в день, и каждая проходит через модель обнаружения мошенничества. Текущая модель в продакшене — V1. ML-команда собрала V2.

Customer Transaction
        ↓
    Payment API
        ↓
  Feature Service
        ↓
 Fraud Model V1
        ↓
  Fraud Risk Score
        ↓
 ┌──────┼────────┐
 ↓      ↓        ↓
Approve Review  Decline

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

Теневое развёртывание: сначала наблюдать

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

Production Transaction
                         ↓
               ┌─────────┴─────────┐
               ↓                   ↓
          🟢 Model V1         🔵 Model V2
           Production             Shadow
               ↓                   ↓
       Actual Decision        Log Prediction
               ↓
            Customer

Возьмём такую транзакцию:

Amount: $4,800
Location: Dallas
Device: New device
Transactions last 5 min: 4
Merchant risk: Medium

V1 оценивает вероятность мошенничества в 0,31 и одобряет её. V2 выдаёт 0,82 и отправила бы её на проверку. Поскольку V2 работает в теневом режиме, её ответ клиента не касается, он только записывается. Со временем по логам можно сравнить:

• Расхождения в предсказаниях
• Precision и recall
• Ложноположительные и ложноотрицательные результаты
• Задержку инференса
• Доступность признаков
• Дрейф данных
• Потребление ресурсов

Теневой режим отвечает на вопрос, как V2 повела бы себя в продакшене, не отдавая ей управление. Shadow — это посмотреть, прежде чем переключать.

Canary-релиз: начать с малого и расти уверенно

Допустим, после теневого тестирования V2 выглядит здоровой. Теперь она должна принимать настоящие решения, но переход идёт не с 0% сразу на 100%. Всё начинается с крошечной доли трафика:

Production Traffic
                 ↓
          ┌──────┴──────┐
          ↓             ↓
        99%             1%
          ↓             ↓
     🟢 Model V1   🟡 Model V2

Из миллиона ежедневных транзакций примерно 990 000 по-прежнему уходят в V1 и около 10 000 — в V2, и решения V2 теперь имеют значение. Пока метрики держатся, доля растёт ступенями (1%, 5%, 10%, 25%, 50%, затем 100%). На каждом этапе стоит отслеживать потери от мошенничества, отклонённых добросовестных клиентов, долю одобрений, задержку, ошибки и тайм-ауты, число случаев на ручной проверке и нагрузку на инфраструктуру.

Теперь предположим, что при 10% у V2 резко растёт число ложных отказов:

V2 reaches 10%
       ↓
🚨 Guardrail triggered
       ↓
Stop rollout
       ↓
Rollback
       ↓
100% → V1

Canary отвечает на вопрос, достаточно ли V2 безопасна для постепенного выката. Canary — это контроль радиуса поражения.

A/B-тестирование: пусть решают данные

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

Eligible Traffic
                    ↓
            Random Assignment
              ↙           ↘
            50%           50%
             ↓             ↓
        🔵 Model V1   🟣 Model V2
          Group A       Group B

Затем результаты сравнивают. Значения ниже приведены только для иллюстрации.

Метрика	Модель V1	Модель V2
Обнаружение мошенничества	92,0%	95,1%
Ложные отказы	1,8%	1,2%
Средняя задержка	42 мс	51 мс
Ручная проверка	4,5%	3,7%

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

Не путайте эти два метода. Canary спрашивает, можно ли безопасно выпустить V2. A/B-тест спрашивает, действительно ли V2 лучше V1. Во втором случае победителя пусть выбирают данные.

Многорукие бандиты: учиться, оптимизируя

В A/B-тесте распределение трафика обычно фиксировано на всё время эксперимента. Бандиты отличаются тем, что распределение может меняться по мере обучения системы. Представьте три рекомендательные модели, которые стартуют с равного деления:

Model A → 33%
Model B → 33%
Model C → 34%

После сбора результатов:

A → 3.0% conversion
B → 4.2% conversion 🏆
C → 2.7% conversion

Дальше система может постепенно сместить трафик:

Model A → 20%
Model B → 70% 🚀
Model C → 10%

Почему бы не отправить всё в B? Потому что системе всё ещё нужно учиться. В этом и состоит напряжение между исследованием (exploration), когда пробуют альтернативы, чтобы узнать, нет ли чего-то лучше, и использованием (exploitation), когда больше трафика отдают варианту с лучшей наградой на данный момент.

Explore
   ↓
Learn
   ↓
Update Expected Reward
   ↓
Exploit
   ↓
Continue Learning

Среди распространённых алгоритмов — epsilon-greedy, UCB и сэмплирование Томпсона. Бандиты подходят для рекомендаций, ранжирования в поиске, рекламы, подбора предложений, персонализации контента и оптимизации уведомлений. Коротко: учиться, адаптироваться, оптимизировать.

Бандиты для решений по мошенничеству?

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

Собираем всё вместе

Зрелый путь ML-модели в продакшен может выглядеть так:

🧠 Train Model V2
        ↓
📊 Offline Evaluation
        ↓
🔵 Shadow Deployment
        ↓
🔍 Compare V1 vs V2
        ↓
🟢 Canary Release
        ↓
   1% → 5% → 10%
        ↓
🟣 A/B Testing
        ↓
📈 Validate Business KPIs
        ↓
🚀 Full Rollout
        ↓
👀 Continuous Monitoring
        ↓
🔄 Retraining / Model V3

Для подходящих задач оптимизации он продолжается так:

Continuous Monitoring
        ↓
🟠 Multi-Armed Bandit
        ↓
Learn + Optimize

Когда что-то идёт не так

Представьте, что V2 получила 25% трафика, а мониторинг сообщает: задержка выросла на 45%, тайм-аутов стало в 3 раза больше, ложных отказов — на 2,1% больше. Продакшен-система должна отреагировать сама:

🚨 Threshold Exceeded
        ↓
🛑 Stop Rollout
        ↓
↩️ Route Traffic to V1
        ↓
🔔 Alert ML / SRE Teams
        ↓
🔍 Investigate

Именно поэтому наблюдаемость — часть развёртывания ML с самого начала, а не что-то, о чём вспоминают потом. Отслеживать стоит три группы метрик:

• Метрики модели: насколько хороши предсказания (precision, recall, F1, AUC, оба вида ошибок) и дрейф данных
• Системные метрики: как держится сервис — задержка, пропускная способность, ошибки, тайм-ауты, CPU, память и время безотказной работы
• Бизнес-метрики: чего стоит результат (конверсия, выручка, потери от мошенничества, отклонённые клиенты, ручные проверки, вовлечённость)

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

Те же идеи для рекомендаций в e-commerce

В условиях с меньшим риском стратегии выглядят иначе:

• Shadow: V2 формирует рекомендации, но клиенты по-прежнему видят рекомендации V1.
• Canary: 5% клиентов начинают видеть рекомендации V2.
• A/B-тест: 50% получают V1, 50% — V2, и вы сравниваете CTR, конверсию, средний чек, выручку на сессию и удержание.
• Бандит: трафик смещается к стратегиям с лучшей наградой, а контролируемое исследование продолжается.

Четыре стратегии рядом

Стратегия	Главный вопрос	Влияние на клиентов	Трафик
Shadow	Как поведёт себя V2?	Нет	Зеркалируется
Canary	Безопасна ли V2?	Да	Постепенно растёт
A/B	Лучше ли V2?	Да	Фиксированное деление в эксперименте
Бандит	Какой вариант должен получать больше трафика сейчас?	Да	Динамический

Простая подсказка для памяти: shadow наблюдает, canary аккуратно выпускает, A/B сравнивает, а бандит постоянно переоптимизирует.

Управление рисками

Разговоры об ИИ и ML обычно крутятся вокруг алгоритмов, признаков, обучения, точности и GPU. Продакшен добавляет ещё одно измерение — управление рисками. Настоящий вопрос не только в том, хорошо ли модель предсказывает. Он в том, можно ли её безопасно внедрить, наблюдать за ней, измерять, что она делает, держать радиус поражения небольшим, ловить сбои и откатывать её. Успешная продакшен-платформа для ML — это больше, чем модель за API. Она объединяет модели, данные, инфраструктуру, эксперименты, наблюдаемость, ограничения, откат и бизнес-метрики. Обучение готовит модель, а продакшен-инженерия решает, заслуживает ли она доверия.