MLOps Pipeline v produkci: Od experimentu k spolehlivému ML systému¶

Většina ML projektů selže ne kvůli špatnému modelu, ale kvůli špatné infrastruktuře kolem něj. 87 % ML modelů se nikdy nedostane do produkce (Gartner, 2025). MLOps je disciplína, která tento problém řeší.

Anatomie produkčního ML pipeline¶

┌────────────┐   ┌──────────────┐   ┌─────────────┐   ┌──────────────┐
│  Data       │──▶│  Feature      │──▶│  Training    │──▶│  Model       │
│  Ingestion  │   │  Engineering  │   │  Pipeline    │   │  Registry    │
└────────────┘   └──────────────┘   └─────────────┘   └──────────────┘
                        │                                       │
                        ▼                                       ▼
                 ┌──────────────┐                       ┌──────────────┐
                 │  Feature      │                       │  Serving      │
                 │  Store        │──────────────────────▶│  (API/Batch)  │
                 └──────────────┘                       └──────────────┘
                                                               │
                                                               ▼
                                                        ┌──────────────┐
                                                        │  Monitoring   │
                                                        │  & Drift      │
                                                        └──────────────┘

1. Feature Store — srdce ML infrastruktury¶

Feature store je centrální úložiště pro ML features — vyčištěné, transformované datové atributy připravené pro trénink i inference.

Proč feature store?¶

• Konzistence: stejné features v tréninku i produkci (eliminace training-serving skew)
• Znovupoužitelnost: features sdílené mezi týmy a modely
• Časová správnost: point-in-time correct joins (žádný data leakage)
• Latence: online store pro real-time serving (< 10ms)

Implementace¶

# Feast (open-source feature store) — definice features
from feast import Entity, Feature, FeatureView, FileSource
from feast.types import Float32, Int64

customer = Entity(name="customer_id", value_type=Int64)

customer_features = FeatureView(
    name="customer_features",
    entities=[customer],
    schema=[
        Feature(name="total_orders_30d", dtype=Int64),
        Feature(name="avg_order_value", dtype=Float32),
        Feature(name="days_since_last_order", dtype=Int64),
        Feature(name="churn_risk_score", dtype=Float32),
    ],
    source=FileSource(path="s3://features/customer_daily.parquet"),
    ttl=timedelta(days=1),
)

Doporučené nástroje (2026):

Nástroj	Typ	Best for
Feast	Open-source	Startups, flexibilita
Tecton	Managed	Enterprise, real-time
Hopsworks	Open-source + managed	Full MLOps platform
Databricks Feature Store	Managed	Databricks ekosystém
Redis + custom	DIY	Ultra-low latency

2. Training Pipeline — reprodukovatelnost na prvním místě¶

Každý trénovací run musí být 100 % reprodukovatelný:

# DVC pipeline (dvc.yaml)
stages:
  prepare:
    cmd: python src/prepare.py
    deps:
      - src/prepare.py
      - data/raw/
    outs:
      - data/processed/
    params:
      - prepare.split_ratio
      - prepare.seed

  train:
    cmd: python src/train.py
    deps:
      - src/train.py
      - data/processed/
    outs:
      - models/latest/
    params:
      - train.learning_rate
      - train.epochs
      - train.batch_size
    metrics:
      - metrics/train.json:
          cache: false

  evaluate:
    cmd: python src/evaluate.py
    deps:
      - src/evaluate.py
      - models/latest/
      - data/processed/test/
    metrics:
      - metrics/eval.json:
          cache: false
    plots:
      - metrics/confusion_matrix.csv
      - metrics/roc_curve.csv

Klíčové principy¶

1. Verzování dat — DVC, LakeFS nebo Delta Lake
2. Verzování kódu — Git (samozřejmě)
3. Verzování prostředí — Docker + requirements.txt s pinned versions
4. Experiment tracking — MLflow, Weights & Biases, nebo Neptune
5. Hyperparameter management — Hydra nebo config YAML v Gitu

# MLflow experiment tracking
import mlflow

with mlflow.start_run(run_name="xgboost-v3"):
    mlflow.log_params({
        "learning_rate": 0.01,
        "max_depth": 6,
        "n_estimators": 500,
        "feature_set": "customer_v3",
    })

    model = train_model(X_train, y_train, params)
    metrics = evaluate_model(model, X_test, y_test)

    mlflow.log_metrics({
        "auc_roc": metrics["auc_roc"],
        "precision": metrics["precision"],
        "recall": metrics["recall"],
        "f1": metrics["f1"],
    })

    mlflow.sklearn.log_model(model, "model",
        registered_model_name="churn-predictor")

3. Model Registry — governance a lifecycle¶

Model registry = centrální katalog všech modelů s verzemi, metadaty a lifecycle stavem.

┌──────────────────────────────────────┐
│         Model Registry               │
├──────────────────────────────────────┤
│ churn-predictor                      │
│   v1.0 → Archived                   │
│   v1.1 → Archived                   │
│   v2.0 → Production (since 2026-01) │
│   v2.1 → Staging (canary 5%)        │
│                                      │
│ fraud-detector                       │
│   v3.0 → Production                 │
│   v3.1 → Staging                    │
│                                      │
│ recommendation-engine                │
│   v1.0 → Production                 │
└──────────────────────────────────────┘

Lifecycle stavy: None → Staging → Production → Archived

Governance checklist před Production: - ✅ Metriky nad threshold (AUC > 0.85, latence < 50ms) - ✅ A/B test minimálně 7 dní - ✅ Bias audit (fairness metriky) - ✅ Data lineage dokumentace - ✅ Rollback plan otestovaný

4. Model Serving — API i batch¶

Online serving (real-time)¶

# FastAPI + ONNX Runtime pro nízkou latenci
from fastapi import FastAPI
import onnxruntime as ort
import numpy as np

app = FastAPI()
session = ort.InferenceSession("model.onnx")

@app.post("/predict")
async def predict(features: dict):
    input_array = np.array([list(features.values())], dtype=np.float32)
    result = session.run(None, {"input": input_array})
    return {
        "prediction": int(result[0][0]),
        "probability": float(result[1][0][1]),
        "model_version": "v2.0",
    }

Latence optimalizace: - ONNX Runtime (2-5× rychlejší než sklearn/pytorch) - Model quantization (FP32 → INT8) - Batching (dynamické micro-batching) - Feature caching (Redis pro opakované dotazy)

Batch serving¶

# Spark batch inference
from pyspark.sql import SparkSession
import mlflow

spark = SparkSession.builder.appName("batch-predict").getOrCreate()
model = mlflow.pyfunc.spark_udf(spark, "models:/churn-predictor/Production")

df = spark.read.parquet("s3://features/customer_daily/")
predictions = df.withColumn("churn_probability", model(*feature_columns))
predictions.write.parquet("s3://predictions/churn/2026-02-20/")

5. Monitoring — model decay je nevyhnutelný¶

ML modely degradují. Data se mění, svět se mění. Monitoring není nice-to-have, je to nutnost.

Co monitorovat¶

Kategorie	Metriky	Alert
Data quality	Missing values, schema drift, volume	> 5 % missing
Feature drift	PSI, KS test, Wasserstein distance	PSI > 0.2
Prediction drift	Distribution of outputs	KS p < 0.01
Model performance	AUC, precision, recall (s ground truth)	AUC drop > 5 %
Latence	p50, p95, p99	p99 > 100ms
Throughput	Requests/sec, error rate	Error > 1 %

Drift detection¶

# Population Stability Index (PSI)
def psi(expected: np.ndarray, actual: np.ndarray, bins: int = 10) -> float:
    """PSI < 0.1 = stable, 0.1-0.2 = moderate, > 0.2 = significant drift."""
    breakpoints = np.quantile(expected, np.linspace(0, 1, bins + 1))
    expected_pct = np.histogram(expected, breakpoints)[0] / len(expected)
    actual_pct = np.histogram(actual, breakpoints)[0] / len(actual)

    # Avoid log(0)
    expected_pct = np.clip(expected_pct, 0.001, None)
    actual_pct = np.clip(actual_pct, 0.001, None)

    return np.sum((actual_pct - expected_pct) * np.log(actual_pct / expected_pct))

Retraining triggers¶

1. Scheduled: týdenní/měsíční retrain na čerstvých datech
2. Drift-based: automatický retrain při PSI > 0.2
3. Performance-based: retrain při poklesu metriky pod threshold
4. Event-based: retrain po významné business změně

6. CI/CD pro ML¶

# GitHub Actions — ML pipeline CI/CD
name: ML Pipeline
on:
  push:
    paths: ['src/**', 'configs/**', 'data/dvc.lock']

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r requirements.txt
      - run: pytest tests/ -v
      - run: python src/validate_data.py
      - run: python src/train.py --config configs/ci.yaml
      - run: python src/evaluate.py --threshold-file configs/thresholds.yaml

  deploy-staging:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: mlflow models serve -m "models:/churn-predictor/Staging" --port 8080 &
      - run: python tests/integration/test_serving.py
      - run: kubectl apply -f k8s/staging/

  promote-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production  # Manual approval gate
    steps:
      - run: python scripts/promote_model.py --from staging --to production
      - run: kubectl apply -f k8s/production/

Závěr¶

MLOps v roce 2026 není o nástrojích — je to o disciplíně. Klíčové principy:

1. Reprodukovatelnost — každý experiment musí být opakovatelný
2. Automatizace — manuální kroky = zdroj chyb
3. Monitoring — model bez monitoringu je časovaná bomba
4. Governance — kdo schválil model, na jakých datech, s jakými metrikami

CORE SYSTEMS implementuje MLOps pipeline od návrhu architektury po produkční provoz. Pomáháme firmám dostat ML modely z Jupyteru do produkce — spolehlivě a bezpečně.

---

Chcete zavést MLOps ve vaší organizaci? Kontaktujte nás pro konzultaci.