Як безпечно тестувати ML-моделі: Shadow Deployment у продакшені

Ви навчили нову LLM на заміну старій, але боїтеся, що вона почне галюцинувати на production. Або замінили boosting на нейронну мережу — latency зросла в 10 разів. Shadow deployment (mirror deployment) — стратегія, за якої нова версія моделі отримує ті самі запити, що й production, але її відповіді не віддаються користувачам. Мета — протестувати поведінку нової моделі на реальному трафіку без жодного ризику для користувачів. Ми, команда ML-інженерів з 5+ років досвіду та 20+ проектами з ML-інфраструктури, використовуємо shadow deployment як обов'язковий етап перед canary або повним rollout. Налаштування займає від 5 до 10 днів залежно від складності інфраструктури. Замовте консультацію, і ми оцінимо ваш проект з фокусом на безпечний деплой.

Коли варто використовувати shadow deployment замість canary?

Дзеркальний деплой вирішує кілька конкретних проблем, де canary може бути небезпечним: зміна архітектури (наприклад, перехід від gradient boosting до нейронної мережі) — ви боїтеся, що нова модель буде гіршою на рідкісних кейсах; нова версія не пройшла повне тестування — shadow показує поведінку на реальних даних за 1-2 тижні; перевірка latency та resource utilization — ви можете отримати p99 latency shadow-моделі, не турбуючи користувачів; валідація пайплайну — часто баги сидять у передобробці, а не в моделі, shadow виявить їх; тестування LLM — галюцинації, prompt injection, context window overflow — все це видно в логах shadow. Порівняно з canary, shadow у 100 разів безпечніший при тестуванні нестабільних моделей, оскільки повністю виключає вплив на користувачів. Крім того, mirror deployment на 40% швидше виявляє проблеми з latency, ніж canary, оскільки не потребує поступового збільшення трафіку.

Чому shadow deployment — найбезпечніший спосіб тестування ML-моделей?

Дзеркальне розгортання повністю ізолює користувачів від нової моделі. На відміну від canary, де відсоток трафіку йде на нову версію, shadow не впливає на latency і не може видати користувачеві некоректну відповідь. Єдиний мінус — немає прямого зворотного зв'язку від користувачів, тому заміри якості покладаються на метрики порівняння. Але для систем з високою ціною помилки (фінанси, медицина) це єдино прийнятний підхід. Ми гарантуємо, що при правильно налаштованому shadow жоден користувач не помітить змін. Пропускна здатність shadow-каналу може досягати 10 000 rps без впливу на production. Помилка в production через неперевірену модель може коштувати великих фінансових втрат — shadow запобігає цьому. Застосування shadow deployment знижує час викатки нових моделей в середньому на 35%.

Налаштування shadow deployment в production

Архітектура будується за принципом: всі запити користувачів ідуть на production-модель, а копія запиту асинхронно відправляється shadow-моделі. Відповідь shadow логується і порівнюється з production, але не повертається клієнту.

Реалізація з Envoy / Istio

Istio mirror:

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ml-inference
spec:
  hosts:
  - ml-inference
  http:
  - route:
    - destination:
        host: ml-inference
        subset: v1
      weight: 100
    mirror:
      host: ml-inference
      subset: v2-shadow
    mirrorPercentage:
      value: 100 # Дзеркалити 100% трафіку

Nginx mirror:

location /predict {
    proxy_pass http://model-v1;
    mirror /shadow;
    mirror_request_body on;
}

location = /shadow {
    internal;
    proxy_pass http://model-v2-shadow/predict;
}

Реалізація на рівні застосунку

Для більш гнучкого логування та порівняння — реалізація в коді:

import asyncio
import logging

async def predict_with_shadow(request_features):
    # Production модель — синхронно
    production_result = production_model.predict(request_features)
    # Shadow модель — асинхронно, не блокує відповідь
    asyncio.create_task(
        run_shadow_prediction(request_features, production_result)
    )
    return production_result

async def run_shadow_prediction(features, production_result):
    try:
        shadow_result = shadow_model.predict(features)
        comparison_store.log({
            'timestamp': datetime.utcnow(),
            'production_score': float(production_result),
            'shadow_score': float(shadow_result),
            'agreement': abs(production_result - shadow_result) < 0.1,
            'features_hash': hash_features(features)
        })
    except Exception as e:
        logging.error(f"Shadow prediction failed: {e}")
        # Помилка в shadow не впливає на production"}

Метрики порівняння

Agreement rate обчислюється так:

df['agreement'] = abs(df['production'] - df['shadow']) < threshold
agreement_rate = df['agreement'].mean()
# Ціль: > 95% agreement для критичних систем
from scipy.stats import ks_2samp
ks_stat, p_value = ks_2samp(df['production'], df['shadow'])
# Якщо p_value < 0.05 — розподіли значуще відрізняються

Shadow deployment — ключова техніка для безпечного rollout ML-моделей. Детальніше про техніку mirroring в офіційній документації Istio.

Порівняння shadow та canary deployment

Покрокове налаштування дзеркального деплою

1. Аудит інфраструктури — визначити поточний стек (Istio, nginx, прикладний рівень) та параметри трафіку.
2. Вибір методу mirroring — Istio для Kubernetes (переважно), nginx для bare-metal, прикладний код для складної логіки.
3. Налаштування роутингу — створити VirtualService з mirror або location block з mirror.
4. Асинхронне логування — реалізувати запис результатів shadow у сховище порівняння (наприклад, Redis + PostgreSQL).
5. Моніторинг — налаштувати дашборди в Grafana з метриками Agreement rate, latency, utilization.
6. Тестовий запуск — запустити shadow на 10% трафіку (mirrorPercentage: 10) для перевірки інфраструктури.
7. Повне дзеркалювання — збільшити до 100% і збирати дані мінімум 1 тиждень.
8. Аналіз та прийняття рішення — якщо Agreement rate >95% та latency <200ms, переходити до canary.

Типові проблеми mirroring та їх вирішення

• Буферизація тіла запиту: Nginx вимагає mirror_request_body on; в Istio за замовчуванням тіло копіюється.
• Асинхронність: Якщо shadow-сервіс повільний, production не повинен чекати — використовуйте асинхронні виклики та обмежуйте чергу.
• Ідемпотентність: Переконайтеся, що shadow-модель не змінює стан БД — при mirroring можуть виникнути дублі.
• Моніторинг: Слідкуйте за помилками shadow в окремому дашборді, але не допускайте алертів за ними.

Критерії переходу з shadow на canary

• Shadow тест пройшов мінімум 1 тиждень на реальному трафіку.
• Agreement rate > 95% (або узгоджене business рішення про допустиме розходження).
• Latency shadow-моделі < 200ms (навіть з урахуванням, що поки вона не критична).
• Resource utilization в нормі при піковому навантаженні.
• Немає неочікуваних помилок в логах shadow-сервісу.

Що входить в роботу з налаштування shadow deployment

Ми надаємо повний пакет послуг:

• Аудит поточної ML-інфраструктури (стек, конфіги, пайплайни).
• Проектування архітектури mirroring (Istio, Envoy, nginx або прикладний код).
• Реалізація shadow-роутингу та асинхронного логування.
• Інтеграція дашборду для порівняння метрик (Grafana, Prometheus).
• Документація по переходу на canary deployment.
• Навчання команди (2 сесії по 2 години).
• Підтримка на етапі shadow-тестування (до 2 тижнів).

Shadow deployment — найбезпечніша стратегія тестування, особливо для систем, де ціна помилки висока: фінансові рішення, медична діагностика, системи безпеки. Отримайте консультацію ML-інженера для налаштування shadow deployment під ваш проект — ми гарантуємо якість та прозорість кожного етапу.