Эта глава из темы 3 фокусируется на AI/ML workflows, feature pipelines и rollout-контуры. Здесь важно не только предложить рабочую схему, но и показать, как она ведёт себя при росте нагрузки и сбоях.
Используйте структуру разбора: требования -> архитектура -> критический deep dive -> эволюция. Такой подход делает решение прозрачным и интервью-устойчивым.
Offline/Online Parity
Контролируйте консистентность фичей и схему данных между training и serving слоями.
Rollout Safety
Canary, shadow, rollback и drift-alerting должны быть частью базовой архитектуры.
Data Quality
Нужны guardrails для freshness, lineage и предотвращения training-serving skew.
Platform Efficiency
Оптимизируйте стоимость pipelines, feature storage и inference latency.
Playbook прохождения кейса
Определите feature contract
Фаза 1Согласуйте схему и семантику фичей между offline и online контурами.
Постройте rollout-политику
Фаза 2Опишите canary/shadow/rollback и мониторинг качества модели.
Закройте data quality риски
Фаза 3Добавьте проверки freshness, lineage и drift/скос распределений.
Оптимизируйте стоимость
Фаза 4Покажите баланс между SLA инференса и ценой feature/model pipelines.
Связанная глава
Machine Learning System Design
Фреймворк для ML-кейсов: требования, метрики, данные, эксплуатационные риски.
ML Ops Pipeline - это системный кейс про то, как довести модель от эксперимента до стабильной production-эксплуатации. На интервью проверяют, умеете ли вы проектировать end-to-end lifecycle: данные, обучение, release, serving, мониторинг и безопасную деградацию при сбоях.
Границы скоупа главы
Покрываем в этой главе
- Сквозной lifecycle: ingest -> training/eval -> registry/release -> serving -> monitoring -> retraining.
- Release governance: quality gates, rollout policy (canary/shadow/A-B) и rollback readiness.
- Операционная модель: SLO, ownership, runbooks и реакция на drift/quality incidents.
Что не покрываем
- Низкоуровневый дизайн feature registry и schema evolution на уровне конкретного API.
- Детали online/offline retrieval контрактов, key design, TTL и hot-key mitigation в online store.
- Глубокая механика materialization jobs и конфликт-резолвинг batch/stream обновлений.
Детальный runtime-разбор Feature Store и serving контрактов вынесен в Feature Store & Model Serving.
Функциональные требования
- Собрать единый pipeline: от сырых событий и данных до production inference.
- Поддержать reproducible training: versioned datasets, feature definitions и model artifacts.
- Обеспечить controlled rollout моделей (canary/shadow/A-B) с безопасным rollback.
- Собрать feedback loop: онлайн-метрики, drift-сигналы и повторное обучение.
Нефункциональные требования
- p95 latency online inference < 150 мс для user-facing сценариев.
- Feature freshness SLA: 1-5 минут для критичных поведенческих сигналов.
- Доступность inference контура 99.95% с деградацией через fallback baseline.
- Полная auditability: lineage для данных, фичей, моделей и rollout-решений.
Масштаб и предположения
| Параметр | Оценка | Почему важно |
|---|---|---|
| DAU | 8M | Продукт с постоянным потоком пользовательских событий и персонализацией в реальном времени. |
| Peak inference QPS | 120k | Нагрузка распределена по нескольким user-surface: feed, search, recommendations. |
| Feature updates | 1.5B/day | События требуют near real-time materialization в online feature store. |
| Model retraining cadence | daily + emergency retrains | Модель должна адаптироваться к сезонности, кампаниям и distribution shifts. |
| Peak artifact size | 2-8 GB/model | Нужны надежные policy для хранения, доставки и rollback артефактов. |
High-Level Architecture
Stage 1: Data & Feature Pipelines
Ingestion через batch + streaming, quality checks, point-in-time joins и публикация фичей в offline/online stores.
Stage 2: Training & Validation
Оркестрация train/eval jobs, experiment tracking, reproducible datasets и проверка model-quality guardrails.
Stage 3: Registry & Release Management
Model registry со stage transitions (staging -> canary -> prod), approval policy и rollback-ready пакетами.
Stage 4: Serving & Monitoring
Online inference API, fallback policy, latency/error/freshness SLO и drift monitoring с auto-alerting.
Типовой контур: события и данные попадают в ingest pipeline, фичи публикуются в offline/online stores, оркестратор запускает train/eval, registry управляет версиями и rollout, а serving слой замыкает feedback loop через online-метрики и drift сигналы.
Deep Dives и trade-offs
Freshness vs reproducibility
Чем быстрее обновляете фичи и модели, тем лучше реакция на новый сигнал, но выше риск потери воспроизводимости и сложнее расследовать regressions.
Batch simplicity vs streaming responsiveness
Batch-контур дешевле и проще в поддержке, но проигрывает по актуальности. Streaming уменьшает lag, но резко повышает операционную сложность.
Single model vs multi-model routing
Одна универсальная модель упрощает управление, но часто уступает качеством. Routing по сегментам повышает качество, но усложняет контроль версий и rollout.
Strict guardrails vs скорость релизов
Жесткие quality gates уменьшают риск инцидента, но замедляют delivery. Нужен баланс через risk-tier policies и автоматизированные проверки.
Типичные антипаттерны
Feature logic дублируется в train notebook и production code без общего registry и versioning.
Модель деплоится без canary/shadow проверки и без fallback, что делает инцидент мгновенно продуктовым.
Нет point-in-time контроля: в train попадают future-сигналы, а в проде качество резко падает.
Drift мониторинг включен только на model output, без контроля входных feature distributions.
Рекомендации
Фиксируйте контракты pipeline: schema, ownership, SLO, rollback-процедуры и runbook для каждого этапа.
Собирайте единый lineage граф: source data -> features -> model version -> release decision.
Выделяйте минимум два режима деградации: fallback model и rule-based baseline.
Закладывайте budget-aware inference: ограничения по latency/cost и приоритизация критичных surface.
Что проговорить на интервью
- Как в вашей схеме предотвращается training-serving skew и data leakage?
- Какие quality gates блокируют rollout, и какие сигналы считаются допустимыми для canary?
- Как меняется архитектура при росте inference QPS в 10x?
- Какие SLO/метрики мониторятся end-to-end: data lag, feature freshness, model quality, latency, fallback rate?
Связанные главы
- Feature Store & Model Serving - Детализация offline/online parity, serving контрактов и operational guardrails.
- Recommendation System - Прикладной ML-кейс с candidate generation, ranking и model quality в продукте.
- Data Pipeline / ETL / ELT Architecture - Фундамент для ingestion, backfill, orchestration и data quality контуров.
- Observability & Monitoring Design - Подход к SLO-мониторингу, алертингу и инцидентам для production систем.
- ML-платформа в Т-Банке - Реальный платформенный кейс с эволюцией ML workflows в крупной компании.
- Precision и recall на пальцах - База для интерпретации model quality перед rollout и после релиза.