Як безпечно тестувати 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 під ваш проект — ми гарантуємо якість та прозорість кожного етапу.

MLOps: інфраструктура для навчання, деплою та моніторингу ML-моделей

Модель навчена, метрики — F1 0.94 на валідації. Через три місяці в продакшені якість падає на 12%. Ніхто не знає, коли саме — немає моніторингу. Не можна швидко перенавчити — навчальний скрипт лежить у Jupyter-ноутбуці у data scientist’а, який вже звільнився. Дані для ретрейну збирають вручну з трьох розрізнених систем. Приблизно половина проєктів приходять до нас із цим болем. Ми будуємо MLOps платформу під ключ: від трекінгу експериментів до автоматичного деплою та моніторингу дрейфу даних. Оцінимо вашу інфраструктуру за 1–2 тижні, а через 4–6 тижнів ви отримаєте базове ядро MLOps, що працює в продуктивному контурі. Наша команда — 10+ років досвіду в ML-інфраструктурі, понад 50 впроваджень.

Як побудувати MLOps-інфраструктуру?

Experiment tracking та відтворюваність

Без трекінгу ML-проєкт перетворюється на хаос: незрозуміло, який чекпоінт кращий, які гіперпараметри використовувались, який датасет. Відтворити результат через місяць — квест.

MLflow — open source стандарт для трекінгу. Логує параметри, метрики, артефакти (моделі, графіки) та код. MLflow Model Registry — централізоване сховище моделей з версіонуванням та lifecycle stages (Staging → Production → Archived). Деплой через MLflow Serving або інтеграція із зовнішніми системами.

Типова ініціалізація в коді:

import mlflow

mlflow.set_experiment("fraud-detection-v2")
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 3e-4, "batch_size": 64, "epochs": 10})
    mlflow.log_metric("val_f1", val_f1, step=epoch)
    mlflow.pytorch.log_model(model, "model")

Це мінімум. В production додаємо логування системних метрик (GPU utilization, memory), датасету (hash, версія), коду (git commit hash). Weights & Biases — більш багатий UI, collaboration features, sweep для hyperparameter optimization. MLflow — для on-premise deployment без зовнішніх залежностей.

DVC (Data Version Control) — версіонування даних та моделей поверх git. Дані зберігаються в S3/GCS/Azure Blob, у git — лише метадані (хеші). dvc repro відтворює весь пайплайн від сирих даних до метрик.

Як забезпечити відтворюваність навчання?

Фіксуйте random seeds (torch.manual_seed, numpy.random.seed, random.seed) та записуйте їх у метадані експерименту. Без цього дебагінг нерегулярних результатів — біль. Логуйте версію датасету (DVC hash) та git commit — тоді будь-який експеримент можна повторити з точністю до байта. Це скорочує час на відтворення результатів у 2–3 рази.

Оркестрація пайплайнів: Kubeflow, Airflow, Prefect

Коли потрібен оркестратор пайплайнів?

Скрипт навчання на 100 рядків у cron — нормально для простих задач. Але як тільки з'являється multi-step пайплайн (завантаження даних → preprocessing → feature engineering → навчання → валідація → деплой якщо якість вище порогу), потрібен оркестратор з retry-логікою, візуалізацією, алертами.

Kubeflow — Kubernetes-native оркестратор для ML. Кожен крок — Docker-контейнер. Підтримує паралельні кроки, умовні гілки, артефакти між кроками. Інтегрується з Katib (AutoML), KServe (serving), Feast (feature store). Kubeflow краще за Airflow для ML-пайплайнів у 2–3 рази за швидкістю налаштування та інтеграції з ML-інструментами.

Apache Airflow — більш загальний DAG-оркестратор. Широка екосистема операторів (S3, Spark, DBT, Kubernetes). Простіше розгорнути, якщо в компанії вже є Airflow.

Prefect / Metaflow — менше boilerplate. Prefect 2.x з декораторами @flow та @task — швидкий старт для невеликих команд.

Типова архітектура навчального пайплайну на Kubeflow:

1. Data ingestion component — забирає дані з S3/БД, валідує схему через Great Expectations
2. Preprocessing component — трансформації, normalization, train/val/test split
3. Training component — навчання на GPU, логування в MLflow
4. Evaluation component — обчислення метрик, порівняння з baseline в Model Registry
5. Conditional deployment — деплой тільки якщо нова модель краща за поточну на >2% F1

Кожен component — окремий Docker-образ. Пайплайн версіонується в git. Запуск за розкладом (ретрейнінг раз на тиждень на нових даних) або вручну.

from kfp import dsl

@dsl.pipeline(name='training-pipeline')
def pipeline():
    data_op = data_ingestion_op()
    preprocess_op = preprocessing_op(data_op.output)
    train_op = training_op(preprocess_op.output)
    eval_op = evaluation_op(train_op.output)
    with dsl.Condition(eval_op.output > 0.95):
        deploy_op = deployment_op(train_op.output)

Model Registry та управління життєвим циклом

Model Registry — не просто сховище чекпоінтів. Це централізована система, яка знає:

• Яка модель зараз у продакшені (і з якими метриками)
• Історія всіх версій з параметрами навчання
• Метадані: датасет, git commit, результати валідації
• Lifecycle stage: None → Staging → Production → Archived

MLflow Model Registry — стандарт. Для enterprise — Vertex AI Model Registry (GCP), SageMaker Model Registry (AWS), Azure ML Model Registry.

Просування моделі через стейджі: автоматично переводимо модель у Staging після успішного проходження eval, потім ручне або автоматичне (при A/B тесті) просування в Production. Rollback — перемикання на попередню Production-версію за секунди.

Serving: від FastAPI до Triton Inference Server

Простий випадок. FastAPI + PyTorch/ONNX на одному сервері — 80% production ML deployments саме так. Достатньо для більшості задач з навантаженням до 100 req/s.

from fastapi import FastAPI
import onnxruntime as ort

app = FastAPI()
session = ort.InferenceSession("model.onnx", providers=["CUDAExecutionProvider"])

@app.post("/predict")
async def predict(request: PredictRequest):
    inputs = preprocess(request.text)
    outputs = session.run(None, {"input_ids": inputs})
    return {"label": postprocess(outputs)}

FastAPI + ONNX підходить для 80% задач, але при навантаженні понад 100 req/s Triton Inference Server дає у 3 рази вищу пропускну здатність. Triton — production-стандарт для високих навантажень (500+ req/s). Dynamic batching, concurrent model execution, model ensemble. Підтримує TensorRT, ONNX, PyTorch TorchScript, TensorFlow SavedModel.

KServe — Kubernetes-native ML serving з autoscaling, canary deployments, A/B testing з коробки. Scale-to-zero для неактивних моделей — економія на інфраструктурі до 40%.

Моніторинг: data drift, model drift, інфраструктурні метрики

Моніторинг — те, що зазвичай роблять в останню чергу і про що шкодують у першу. Три рівні.

Інфраструктурний моніторинг. Latency (P50/P95/P99), throughput (req/s), error rate (4xx, 5xx), GPU/CPU utilization. Prometheus + Grafana — стандарт. Алерт при P99 latency > threshold або error rate > 1%.

Data drift моніторинг. Розподіл вхідних даних змінюється з часом. Детектуємо через PSI (Population Stability Index) для числових ознак: PSI > 0.2 — сильний дрейф. Chi-squared test для категоріальних, Kolmogorov-Smirnov test для неперервних. Evidently AI — open source бібліотека з готовими дрейф-тестами.

Model drift моніторинг. Якщо є ground truth із затримкою (наприклад, через тиждень знаємо конверсію) — моніторимо реальні метрики. Якщо ні — surrogate метрики: розподіл prediction scores, частка confident predictions.

Alerting. Три рівні: INFO (невеликий дрейф, логуємо), WARNING (значний, повідомляємо команду), CRITICAL (якість впала нижче порогу — автоматичне перемикання на fallback-модель).

Чому важливий моніторинг дрейфу даних?

Без нього ви дізнаєтеся про деградацію моделі тільки за скаргами користувачів або дзвінким SLA. Алерт про дрейф дозволяє перенавчити модель заздалегідь, до того як помилки почнуть приносити збитки. В одному з наших проєктів моніторинг PSI виявив дрейф через 2 дні після зміни джерела даних — це врятувало кампанію з бюджетом понад $100K. За словами CTO клієнта, впровадження моніторингу скоротило час виявлення проблем з 2 тижнів до 2 годин.

Feature Store

Feature Store вирішує проблему training-serving skew. Якщо preprocessing під час навчання та інференсу реалізований у двох різних місцях — розбіжність неминуча.

Коли потрібен Feature Store?

• Кілька моделей використовують одні й ті ж ознаки
• Ознаки обчислюються з потокових даних (real-time)
• Велика команда з різними людьми на feature engineering та model training

Feast — open source Feature Store. Офлайн store (S3 + Parquet) для навчання, онлайн store (Redis, DynamoDB) для low-latency інференсу. Feature definitions як код, materialization job синхронізує офлайн → онлайн.

Tecton (комерційний), Vertex AI Feature Store (GCP), SageMaker Feature Store (AWS) — managed варіанти з меншим ops overhead.

Як автоматизувати CI/CD для ML?

ML CI/CD — звичайний CI/CD плюс специфічні ML-кроки.

ML-специфічні checks в CI:

• Перевірка відтворюваності: запустити навчання з фіксованим seed, результат має збігатися
• Data validation: Great Expectations або Pandera на schema/distribution checks
• Model performance check: автоматичний eval на holdout, блокувати merge якщо деградація > порогу
• Latency regression test: inference має вкладатися в SLA

GitOps для деплою. Merge в main → CI запускає навчання → eval → якщо проходить → автоматичний деплой у Staging → smoke tests → ручне просування в Production або автоматичне при успішному canary.

Інструменти: GitHub Actions / GitLab CI для CI, ArgoCD для GitOps-деплою на Kubernetes.

Що входить у розробку MLOps-платформи

Ми надаємо повний цикл робіт, документацію та навчання команди.

Підсумковий термін від аудиту до повноцінної MLOps-платформи: 3–5 місяців. Базовий рівень (трекінг + serving) за 4–6 тижнів. Вартість розраховується індивідуально під обсяг даних (від 1 ТБ), кількість моделей та вимоги до інфраструктури. Замовте аудит MLOps-інфраструктури — отримайте roadmap за 1–2 тижні. Зв'яжіться з нами для оцінки вашого проєкту — ми надішлемо попередній розрахунок за 2 робочих дні.

Гарантія на архітектурні рішення — 12 місяців. Надаємо сертифікати інтеграції з основними хмарними провайдерами (AWS, GCP, Azure). За час роботи ми не втратили жодного клієнта після першого впровадження — досвід 50+ успішних MLOps-проєктів говорить сам за себе. Отримайте консультацію щодо побудови MLOps платформи вже сьогодні.