Deployment стратегии моделей на собесе MLE
Зачем deployment стратегии на собесе MLE
Новая модель готова — как её безопасно довести до 100% production traffic? Прямой выкат — риск катастрофы: модель может работать на test данных и фейлить на real distribution. На собесе ML Engineer deployment-стратегии — обязательная тема для middle+.
Слабый ответ — «git push, deploy». Сильный — про canary, shadow, blue-green, A/B-тесты, rollback plan.
Shadow deployment
Идея: новая модель работает параллельно с production, делает predictions, но они не используются.
Применение:
- Compare predictions: old_model vs new_model на real traffic
- Measure latency / cost / accuracy без user impact
- Stress test инфры
Минусы:
- 2x compute cost
- Нет real user feedback (никто не видит predictions новой модели)
Когда: перед canary, для validation.
Canary deployment
Идея: small % traffic → new model. Постепенно увеличиваем при OK metrics.
Schedule (пример):
- Day 1: 5% canary
- Day 2: 25%
- Day 3: 50%
- Day 4: 100%
Что мониторить:
- ML metrics (accuracy, prediction distribution)
- Latency / error rate
- Business metrics (CTR, conversion)
Rollback при degradation:
- Auto-rollback при alert
- Manual review для borderline cases
Tools: k8s + Istio / Linkerd для traffic splitting.
Blue-green deployment
Идея: две полные environment (blue = current, green = new). Switch traffic полностью.
Plus:
- Instant rollback (switch traffic back)
- Full validation на green перед switch
Минусы:
- 2x infra cost (temporary)
- Не градиент — risk большого blast radius
Когда: мажорные обновления, где canary неприменим (например, schema change).
A/B-тесты моделей
Compare two models на real users с statistical rigor.
Setup:
- 50/50 split traffic
- Same business metric (conversion, revenue)
- Compute power / sample size заранее
- Random assignment
Duration: 1-2 недели типично. Зависит от effect size.
Analysis:
- Significance test (t-test / chi-square / bootstrap)
- Practical significance (effect size > business threshold)
- Segmented analysis (subgroups behave одинаково?)
Подробнее — A/B-эксперименты.
Multi-armed bandit
Альтернатива A/B для когда нужно быстрее адаптироваться.
Идея: алгоритм dynamically адаптирует traffic к winning model.
Methods:
- ε-greedy
- Thompson sampling
- UCB (Upper Confidence Bound)
Plus vs A/B:
- Меньше exposure к losing model
- Адаптация в real-time
Минус: меньше statistical rigor, harder для validation.
Rollback plan
Без plan B — катастрофа.
Auto-rollback triggers:
- Error rate > threshold
- Latency p99 > target
- Business metric drop > X%
Manual rollback:
- One-click revert в deployment tool
- Previous model image в registry
- Traffic shift через service mesh
Test rollback: regularly. «Disaster recovery drill».
Versioning
Model versions:
- v1.0.0 (production)
- v1.1.0 (canary)
- v0.9.0 (archived rollback target)
Lineage:
- Каждая версия → training data + code commit + hyperparameters
Compatibility:
- New version returns same prediction format
- Schema evolution: backward compatible
Типичные вопросы
«Новая модель — как доводишь до production?»
- Validate в staging на synthetic + small real data sample.
- Shadow deployment: compare predictions старая vs новая.
- Canary 5% → 25% → 50% → 100% с monitoring.
- Auto-rollback configured.
- Post-deploy validation: business metrics не упали.
«Canary 5% видит degradation — что делаешь?»
Auto-rollback (если configured) или manual. Investigate: regressed для каких segments, для каких features. Iterate на модели, не push дальше.
«A/B-тест модели — как design?»
Define metric (business, не ML). Power calculations → sample size. Random assignment. Duration (часто 1-2 недели). Statistical + practical significance.
«Blue-green или canary?»
Canary для постепенного, контролируемого rollout. Blue-green для big bang updates (e.g., полная архитектура изменения).
«ML model rollback отличается от обычного backend?»
В целом нет — image + traffic switch. Но: model may have feature dependencies (если feature definitions поменялись — rollback ломается). Best: lock feature versions вместе с моделью.
Частые ошибки
- Прямой deploy в 100%. Без canary — risk катастрофы.
- Без rollback plan. Не плохой деплой, плохая incident response.
- Без shadow validation. В production узнаем, что новая модель ломается.
- A/B без power calc. Запустили тест, не знаем, какой effect мы можем detect.
- No monitoring during rollout. Деплой и забыли — узнают через 3 дня от support.
FAQ
Canary % — какой стартовый?
5% — стандарт. Если страх — 1%. Если risk-tolerant — 10%.
Сколько ждать на каждом canary stage?
Зависит от traffic. Goal: достаточно data для statistical confidence. Обычно 1-24 часа per stage.
Service mesh обязателен?
Не обязателен, но упрощает. Без него — application-level routing.
A/B vs bandit?
A/B для strong statistical evidence. Bandit для faster adaptation при known reward function.
Можно ли rollback после 100%?
Да. Image + версия в registry — keep. Switch traffic к previous version.