Налаштування CI/CD для ML-моделей (автоматичне навчання та деплой)

Налаштування CI/CD для ML-моделей: автоматичне навчання та деплой

CI/CD для ML принципово відрізняється від класичного software CI/CD: тут потрібно тестувати як код, а й дані, метрики моделі, продуктивність інференсу. Повноцінний ML pipeline включає автоматичний запуск перенавчання, валідацію якості моделі, promotion у staging/production та відкочування при деградації.

Архітектура ML CI/CD

[Git Push] → [Data Validation] → [Model Training] → [Model Evaluation]
     → [Model Registry] → [Staging Deploy] → [Integration Tests]
     → [Canary Deploy] → [Production Promote] → [Monitoring]

Кожен етап - окреме завдання у пайплайні з явними критеріями success/failure.

Інструменти оркестрації

GitHub Actions / GitLab CI - підходять для невеликих команд. Достатньо для запуску навчання на self-hosted runners з GPU.

Kubeflow Pipelines - Kubernetes-native оркестратор для ML. Кожен крок – окремий контейнер. Підтримує кешування проміжних результатів, візуальний граф пайплайну, версіонування.

MLflow Projects + Prefect/Airflow – менш монолітний підхід. Prefect або Airflow оркеструють, MLflow трекає.

Vertex AI Pipelines / SageMaker Pipelines - managed варіанти для відповідних хмар.

Приклад пайплайну на GitHub Actions

name: ML Training Pipeline

on:
  schedule:
    - cron: '0 2 * * 1'  # Еженедельно по понедельникам
  push:
    paths:
      - 'src/train.py'
      - 'params.yaml'

jobs:
  validate-data:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v3
      - name: Run Great Expectations
        run: python validate_data.py --suite training_data

  train-model:
    needs: validate-data
    runs-on: [self-hosted, gpu]
    steps:
      - name: Train
        run: python train.py --config params.yaml
      - name: Evaluate
        run: python evaluate.py --threshold 0.92

  promote-to-staging:
    needs: train-model
    runs-on: ubuntu-latest
    steps:
      - name: Register and promote
        run: |
          python scripts/promote_model.py \
            --stage staging \
            --min-f1 0.92

Тестування моделі як частина CI

Data validation (Great Expectations, Pandera): перевірка схеми, розподілів, наявності викидів у навчальних даних перед запуском навчання.

Model evaluation gates: модель проходить у наступний етап тільки якщо метрики перевищують граничні значення. Важливо порівнювати не з абсолютним порогом, а з поточною production-моделлю: нова версія має бути кращою за існуючу хоча б на 1-2%.

Inference latency tests: автоматична перевірка p95 latency інференсу. Якщо модель стала точнішою, але в 3 рази повільнішою – це не прогрес.

Shadow testing: нова модель проганяє production-трафік паралельно з поточною, результати порівнюються без впливу на користувачів.

Стратегії деплою

Rollback механізм

Автоматичний відкат повинен спрацьовувати за умови:

• Business-метрика впала більш як на X% (CTR, конверсія)
• Error rate інференс-сервісу перевищив поріг
• Latency p99 вийшов за SLA

# Мониторинг и автооткат
if current_model_metrics['f1'] < production_model_metrics['f1'] * 0.97:
    model_registry.transition_to_stage(current_version, 'Archived')
    model_registry.transition_to_stage(previous_version, 'Production')
    alert_team("Auto-rollback triggered")

Терміни налаштування

Базовий пайплайн (навчання + деплой у staging): 1 тиждень. Повноцінний pipeline з тестами, canary deployment та автороллбеком: 3-4 тижні. Enterprise-варіант з Kubeflow та повною інтеграцією в корпоративний CI/CD: 6-8 тижнів.