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%, тайм-аутів стало втричі більше, хибних відмов — на 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. Вона поєднує моделі, дані, інфраструктуру, експерименти, спостережуваність, обмеження, відкат і бізнес-метрики. Навчання готує модель, а продакшен-інженерія вирішує, чи заслуговує вона на довіру.