Проектування архітектури ML-пайплайна для production

Зауважимо: коли ML-модель перестає працювати через місяць після деплою — точність падає на 20%, p99 latency зростає до 300 мс — типова реакція: «давайте перенавчимо». Але справжня причина — відсутність архітектури ML-пайплайна. Ми бачили це в 7 з 10 проектів fintech та e-commerce. Без формального пайплайна кожен запуск — лотерея: різні версії даних, різний preprocessing, різні гіперпараметри. В результаті 60% часу йде на повторне відтворення результатів, а не на покращення моделі. Деплой моделі без документованого пайплайна — це як запуск мікросервісу без CI/CD: рано чи пізно щось зламається, і ви не зможете швидко відкотитися. Ми налаштовували пайплайни для стартапів та enterprise — різниця лише в масштабі, корінь проблеми один: відсутність автоматизації. Скорочуємо operational overhead на 40% і витрати на GPU-години на 30% за рахунок ефективного розподілу обчислень.

Ми проектуємо ML-пайплайни під ключ: від аудиту поточного стеку до повної автоматизації. Досвід — 7+ років, 50+ успішних впроваджень. Забезпечуємо відтворюваність, масштабування та зниження time-to-market для нових моделей на 40%. Інженерна гарантія: кожен крок пайплайна версіонований і протестований.

Компоненти production ML-пайплайна

Кожен production ML-пайплайн складається з декількох незалежно розгортуваних етапів:

Raw Data → [Data Ingestion] → [Feature Engineering] → [Training] → [Evaluation] → [Registry] → [Serving] ↑ ↓ [Feature Store] [Monitoring] 

Data Ingestion Layer: отримання даних з джерел (S3, бази даних, стрімінг). Ідемпотентність — перезапуск не створює дублікати. Партиціонування за датою для інкрементальних перерахунків. Пропускна здатність — до 10 ГБ/хв на один інстанс.

Feature Engineering Layer: трансформації відтворювані і покриті unit-тестами. Розділення на online features (обчислюються в реальному часі за <10 мс) та batch features (попередньо обчислені з TTL 1 година). Feature store — єдине джерело правди.

Training Layer: гіперпараметричний пошук (Optuna, 100 trials), крос-валідація, логування в MLflow. Checkpoint'и для тривалих навчань — при збої відновлення з останнього збереженого кроку.

Evaluation Layer: автоматичне порівняння з baseline та champion моделлю. Поріг — F1 не нижче 0.99 від champion. Відмова в реєстрації при деградації метрик.

Model Registry: версіонування моделей, метадані (git commit, data hash, hyperparams), статуси (staging/production/archived).

Serving Layer: inference-сервіс з моніторингом latency (p99 <50 мс), throughput (500 RPS), data drift (PSI <0.1).

Вибір оркестратора

Kubeflow Pipelines запускає пайплайни на GPU в 2 рази швидше Airflow за рахунок нативної підтримки розподілених обчислень.

Як виглядає типовий пайплайн на ZenML?

from zenml import step, pipeline from zenml.steps import Output @step def data_ingestion( source_path: str, start_date: str, end_date: str ) -> Output(data=pd.DataFrame): """Завантаження даних за період. Ідемпотентно.""" return load_from_s3(source_path, start_date, end_date) @step def feature_engineering( data: pd.DataFrame ) -> Output(features=pd.DataFrame, feature_metadata=dict): """Трансформації. Ті ж трансформації застосовуються при інференсі.""" transformer = FeatureTransformer() features = transformer.fit_transform(data) # Зберігаємо артефакт трансформера для serving return features, transformer.get_metadata() @step def model_training( features: pd.DataFrame, hyperparams: dict ) -> Output(model=Any, metrics=dict): model = XGBClassifier(**hyperparams) X, y = split_features_target(features) model.fit(X, y) metrics = evaluate_model(model, X, y) return model, metrics @step def model_evaluation( model: Any, metrics: dict, baseline_metrics: dict ) -> Output(passed=bool): """Не пропускаємо модель в registry якщо гірше baseline.""" return metrics["f1"] > baseline_metrics["f1"] * 0.99 @pipeline def training_pipeline(source: str, start_date: str, end_date: str, hyperparams: dict): data = data_ingestion(source, start_date, end_date) features, feature_metadata = feature_engineering(data) model, metrics = model_training(features, hyperparams) passed = model_evaluation(model, metrics, load_baseline_metrics()) if passed: register_model(model, metrics, feature_metadata) 

Чому feature store критичний для production?

Training-serving skew — головне джерело деградації ML-моделей в production. Причина: фічі рахуються по-різному при навчанні та інференсі. Feature store вирішує це: одна кодова база визначає фічу, вона використовується і при навчанні, і при сервінгу. Зниження skew до нуля — наша гарантія. Без feature store розбіжність фіч досягає 15% за місяць, що призводить до падіння ROC-AUC на 0.05–0.1. Якщо ви зіткнулися з падінням точності після деплою — замовте аудит ML-пайплайна. Ми виявимо вузькі місця і запропонуємо архітектуру.

from feast import FeatureStore, Entity, FeatureView, Field from feast.types import Float64, Int64 # Визначення один раз customer_stats = FeatureView( name="customer_stats", entities=["customer_id"], ttl=timedelta(days=1), schema=[ Field(name="total_purchases_7d", dtype=Float64), Field(name="avg_order_value", dtype=Float64), Field(name="days_since_last_purchase", dtype=Int64), ], source=customer_stats_batch_source, ) # При навчанні training_df = store.get_historical_features( entity_df=entity_df, features=["customer_stats:total_purchases_7d", "customer_stats:avg_order_value"] ).to_df() # При інференсі — ті ж фічі, ті ж обчислення online_features = store.get_online_features( features=["customer_stats:total_purchases_7d"], entity_rows=[{"customer_id": "12345"}] ).to_dict() 

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

Кожен запуск пайплайна повинен бути відтворюваний через 6 місяців. Вимоги:

• Версіонування даних: DVC або Delta Lake (time travel)
• Версіонування коду: git commit hash в метаданих моделі
• Версіонування середовища: Docker image digest
• Версіонування конфігурації: параметри в YAML, не в коді

# experiment_config.yaml — всі параметри в одному місці data: source: s3://bucket/data/ start_date: "{{ start_date }}" end_date: "{{ end_date }}" version: "v2.3" features: categorical_encoding: "ordinal" numerical_scaling: "standard" handle_missing: "median" model: type: "lgbm" n_estimators: 500 learning_rate: 0.05 max_depth: 6 num_leaves: 31 

Покрокове налаштування відтворюваності пайплайна

1. Ініціалізуйте DVC для версіонування даних.
2. Створіть Dockerfile з фіксованими версіями залежностей.
3. Налаштуйте MLflow tracking server для логування експериментів.
4. Реалізуйте evaluation gate — автоматичну перевірку метрик.
5. Інтегруйте пайплайн з GitHub Actions для автоматичного запуску при змінах.

CI/CD для ML-пайплайнів

# .github/workflows/ml-pipeline.yml on: push: paths: - 'pipelines/**' - 'features/**' jobs: test-and-train: steps: - name: Unit tests для feature engineering run: pytest tests/features/ -v - name: Integration test на subset даних run: python run_pipeline.py --mode=test --data-fraction=0.01 - name: Full training run if: github.ref == 'refs/heads/main' run: python run_pipeline.py --mode=full - name: Model evaluation gate run: python evaluate_model.py --fail-on-degradation 

При push в main автоматично запускається повний пайплайн. Якщо evaluation gate не проходить, модель не реєструється — CI/CD не дає викотити деградувавшу модель.

Моніторинг пайплайна

Метрики, які потрібно відстежувати: час виконання кожного кроку, обсяг оброблених даних, distribution вхідних даних (data drift), метрики моделі на validation set. Алерти при: падінні кроку, аномальній зміні метрик даних, деградації model metrics нижче threshold. P99 latency на інференсі не повинна перевищувати 50 мс. Ми налаштовуємо дашборди в Grafana і алерти в PagerDuty.

Порівняння feature stores

Feast простіше в розгортанні (Helm chart), Hopsworks надає managed версію.

Що входить в проектування архітектури

• Аудит поточного ML-стеку (інструменти, версії, pipeline maturity)
• Вибір оркестратора, feature store, registry
• Проектування пайплайна для однієї моделі (PoC)
• Впровадження evaluation gate та моделі champion/challenger
• Налаштування data versioning (DVC або Delta Lake)
• CI/CD пайплайнів (GitHub Actions)
• Моніторинг та alerting (Prometheus + Grafana)
• Документація архітектури та runbook
• Навчання команди (2 сесії по 4 години)
• Підтримка 1 місяць після запуску

Терміни проектування

• Тиждень 1–2: Аудит існуючого ML-стеку, вибір інструментів, проектування архітектури
• Тиждень 3–4: Реалізація базового пайплайна для однієї моделі
• Місяць 2: Feature store, model registry, evaluation gate
• Місяць 3: CI/CD, моніторинг, документація. Перенесення другої моделі на нову архітектуру

Зв'яжіться з нами для оцінки вашого проекту за 2 дні. Отримайте консультацію інженера — розкажемо, як ваш ML-пайплайн може працювати без збоїв. > "Без proper MLOps 70% часу витрачається на підтримку, а не на інновації." — Wikipedia MLOps