MLOps Pipeline — od experimentu do produkce

87 % machine learning modelů se nikdy nedostane do produkce. Problém není v algoritmech — je v operacích. MLOps je disciplína, která přináší DevOps principy do ML světa: verzování, automatizace, monitoring, reprodukovatelnost. Tady je náš přístup k MLOps pipeline v roce 2020.

Proč Jupyter notebook nestačí¶

Data scientist vytvoří model v Jupyter notebooku. Funguje skvěle na jeho laptopu, na jeho datasetu, s jeho verzí knihoven. A pak přijde otázka: „Jak to nasadíme do produkce?”

Tady začíná problém. Notebook není deployment artifact. Nemá testy, nemá dependency management, nemá verzování dat, nemá monitoring. Přechod z experimentu do produkce je manuální, bolestivý a nereprodukovatelný proces, který typicky trvá 3-6 měsíců.

MLOps pipeline — pět vrstev¶

Na základě zkušeností z projektů v roce 2020 jsme definovali pětivrstevný MLOps pipeline:

1. Data management¶

Všechno začíná daty. A data se mění — nové záznamy, opravené chyby, změněné schéma. Bez verzování dat nemůžete reprodukovat experiment.

• DVC (Data Version Control): Git pro data. Verzuje velké soubory a datasety pomocí metadat v gitu a úložiště v S3/Azure Blob
• Feature Store: centrální repozitář feature definic — Feast (open-source) nebo managed řešení v Azure ML. Konzistentní features pro trénink i serving
• Data validation: automatická kontrola kvality dat před tréninkem — Great Expectations pro schema validation, distribution checks, missing values

2. Experiment tracking¶

Každý experiment musí být zaznamenán — hyperparametry, metriky, artefakty, verze kódu a dat. MLflow Tracking je v roce 2020 de facto standard:

import mlflow

with mlflow.start_run():

mlflow.log_param(“learning_rate”, 0.01)

mlflow.log_param(“n_estimators”, 200)

model = train_model(X_train, y_train)

mlflow.log_metric(“auc”, evaluate(model, X_test))

mlflow.sklearn.log_model(model, “model”)

Každý run je trackovatelný, porovnatelný a reprodukovatelný. Konec „ten dobrý model jsem trénoval minulý čtvrtek, ale nevím s jakými parametry”.

3. Model registry a CI/CD¶

MLflow Model Registry poskytuje centrální katalog modelů s lifecycle management — Staging, Production, Archived. Promotion modelu z vývoje do produkce prochází automatizovaným pipeline:

1. Data scientist registruje model v registry jako „Staging”
2. CI pipeline spustí automatické testy — unit testy na predikční funkci, integration testy na API endpoint, performance testy na latenci
3. Automatická validace metrik — nový model musí být lepší než aktuální produkční (A/B test na holdout datasetu)
4. Code review a approval od ML engineering týmu
5. Automatický deploy do produkce — canary deployment s postupným náběhem traffic

4. Model serving¶

Jak model nasadit? V roce 2020 vidíme tři hlavní patterny:

• REST API: Model zabalený do Flask/FastAPI kontejneru za load balancerem. Jednoduchý, univerzální, ale latence závisí na síťovém roundtripu
• Batch inference: Spark job, který periodicky skóruje celý dataset. Vhodné pro doporučovací systémy, scoring, segmentaci
• Edge deployment: Model konvertovaný do ONNX a nasazený přímo v aplikaci nebo na edge zařízení. Minimální latence, žádná síťová závislost

Pro klienta z e-commerce jsme nasadili doporučovací model jako Azure ML real-time endpoint — managed Kubernetes cluster, autoscaling na základě request queue depth, A/B testing mezi verzemi modelu. Průměrná latence inference: 23ms.

5. Monitoring a retraining¶

Model v produkci degraduje. Data drift — distribuce vstupních dat se mění. Concept drift — vztah mezi vstupy a výstupy se posouvá.