Intro

MLOps: churn modell a tanítástól a productionig MLflow FastAPI

Ebben a kurzusban egy churn predikciós modellt viszünk végig a teljes életcikluson: kísérletkövetés, tanítás, regisztráció, validáció, deployment, monitoring és drift detektálás.

Projekt: WebShop Pro Churn Model

A WebShop Pro felhasználói adatokból építünk churn modellt, amit aztán FastAPI-n szolgáltatunk ki, Dockerbe csomagolunk, monitorozunk, és driftet detektálunk rajta.

Learning outcome

A kurzus végére felépítesz egy ML pipeline-t kísérletkövetéssel, modellregisztrációval, FastAPI szolgáltatással, Docker konténerizációval és monitoringgal.

Section 01

Fogalmi térkép: MLOps, CI/CD, drift, registry MLflow

Fogalom	Magyarázat
MLOps	ML modellek teljes élettartam-ciklusának kezelése: tanítás, deployment, monitoring
Experiment tracking	Kísérletek naplózása: paraméterek, metrikák, modellek
Model Registry	Modell verziókezelés: staging, production, archived
CI/CD	Continuous Integration/Deployment: automatizált tesztelés és kiszolgálás
Drift	Adateltolódás: ha az új adatok eltérnek a tanító adatoktól
A/B testing	Két modell verzió párhuzamos tesztelése

Mentális modell

ML egyedül: Jupyter notebook, tanítás, kész. Nincs verzió, nincs monitoring.

ML + MLOps: Kísérlet naplózás → modell regisztráció → automatizált teszt → deployment → monitoring → drift észlelés → újra tanítás.

Section 02

Architektúratérkép: ML pipeline FastAPI

📊 Adatok

→

🏋️ Tanitas

→

📋 MLflow

→

✅ Validáció

📦 Registry

→

🐳 Docker

→

🚀 FastAPI

→

📈 Monitoring

Demo vs Production

Demoban: lokális MLflow, egy model, nincs CI/CD. Productionben: Kubernetes, model store (S3), feature store, Prometheus/Grafana, canary deployment, rollback, auth.

Section 03

Környezet elokeszitese Python

[1]

# pip install mlflow scikit-learn pandas fastapi uvicorn
import pandas as pd
import numpy as np
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score, f1_score
import mlflow

print("MLOps környezet készen")

Output:

[mlflow] MLOps környezet készen

Section 04

MLflow alapok: kísérletkövetés MLflow

Az MLflow a Databricks által fejlesztett nyílt forráskódú platform, amely a gépi tanulási kísérletek nyomon követését, a modellek regisztrációját és a szolgáltatást (serving) egyesíti egyetlen keretrendszerben. Segítségével minden tanítási futás paraméterei, metrikái és a generált modell artifactok egy központi helyen naplózásra kerülnek, ami elengedhetetlen a reprodukálhatósághoz.

Miért fontos? ML projektekben tipikusan tucatnyi kísérletet futtatunk különböző hiperparaméterekkel. Notebookban ez könnyen átláthatatlanná válik: nem tudjuk, melyik modell milyen beállításokkal készült, és melyik teljesített a legjobban. Az MLflow automatikusan naplózza ezeket, így bármikor visszakereshető, hogy az adott modell milyen körülmények között született.

Működés: Az mlflow.set_experiment() hívással definiáljuk a kísérletet, majd a mlflow.start_run() kontextuskezelőn belül naplózzuk a paramétereket (log_param), metrikákat (log_metric) és a modellt (log_model). Az MLflow UI-ban vizuálisan összehasonlíthatók a futások.

Tip: Productionben érdemes remote MLflow szervert használni (pl. Databricks Managed MLflow vagy saját Kubernetes-ben futó szerver) artifact store-ral (S3, GCS) és hozzáférés-kezeléssel.

[2]

# MLflow kísérlet beállítása
mlflow.set_experiment("webshop-churn")

# Szintetikus churn adatok
np.random.seed(42)
n = 1000
data = pd.DataFrame({
    "age": np.random.randint(18, 70, n),
    "income": np.random.randint(20000, 120000, n),
    "purchases": np.random.randint(0, 50, n),
    "last_days": np.random.randint(1, 365, n),
    "is_active": np.random.choice([0, 1], n, p=[0.3, 0.7])
})

# Churn label
data["churn"] = ((data["last_days"] > 180) & (data["is_active"] == 0)).astype(int)

print(data.head())
print(f"\\nChurn arány: {data['churn'].mean():.2%}")

Output:

[mlflow] age  income  purchases  last_days  is_active  churn
0   56   84532         34        142          1      0
1   25   98832         12        267          0      1
2   65   34211         45         89          1      0
3   38   67234          8        312          0      1
4   19   45123         23         34          1      0

[step] Churn arány: 21.00%

Section 05

Kísérletkövetés: paraméterek és metrikák MLflow

A kísérletkövetés (experiment tracking) az MLOps alapköve: minden tanítási futás során szisztematikusan rögzítjük a hiperparamétereket, a metrikákat és magát a modellt. Az MLflow ehhez három kulcsfüggvényt biztosít: log_param egyetlen paraméter naplózásához, log_metric a teljesítménymutatókhoz és log_model a betanított modell artifact mentéséhez.

Miért elengedhetetlen? Képzeljünk el egy helyzetet, ahol 20 különböző konfigurációval tanítunk modellt. Nélkülözhetetlen, hogy később pontosan rekonstruálható legyen, melyik futás milyen eredményt hozott. A kísérletkövetés garantálja, hogy a legjobb modell azonosítható és reprodukálható maradjon.

A gyakorlatban: A lentebbi kódban egy for ciklussal három RandomForest modellt tanítunk különböző n_estimators értékekkel (50, 100, 200). Minden iterációban egy új MLflow run indul, amely naplózza a paramétert és az accuracy/F1 metrikákat. A kód lefutása után az MLflow UI-ban összehasonlíthatóak a futások.

Tip: Használj értelmes run_name nevet (pl. rf_100), és adj meg tags-et is (pl. model_type: random_forest), hogy később szűrhetőek legyenek a futások. Nagy projektekben ez megtakarítja a keresés idejét.

[3]

X = data.drop("churn", axis=1)
y = data["churn"]
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

# Több kísérlet különböző paraméterekkel
for n_estimators in [50, 100, 200]:
    with mlflow.start_run(run_name=f"rf_{n_estimators}"):
        model = RandomForestClassifier(n_estimators=n_estimators, random_state=42)
        model.fit(X_train, y_train)
        y_pred = model.predict(X_test)

        acc = accuracy_score(y_test, y_pred)
        f1 = f1_score(y_test, y_pred)

        mlflow.log_param("n_estimators", n_estimators)
        mlflow.log_metric("accuracy", acc)
        mlflow.log_metric("f1_score", f1)
        mlflow.sklearn.log_model(model, "model")

        print(f"n_estimators={n_estimators}: acc={acc:.3f}, f1={f1:.3f}")

Output:

[mlflow] n_estimators=50: acc=0.945, f1=0.857
[mlflow] n_estimators=100: acc=0.950, f1=0.875
[mlflow] n_estimators=200: acc=0.950, f1=0.875

Demo vs Production

Demoban: lokális MLflow. Productionben: remote tracking server (pl. Databricks), artifact store (S3), access control.

Section 06

Model Registry: modellverziózás MLflow

A Model Registry az MLflow központi modelltára, ahol a betanított modellek verziózva, életciklus-állapotokkal ellátva tárolódnak. A modellek státusza négy fázison halad keresztül: None (regisztrálva, de még nem értékelve) → Staging (tesztelés alatt) → Production (élesben szolgáltatva) → Archived (visszavonva, archiválva).

Miért kritikus? Productionben nem elég, hogy van egy jól teljesítő modellünk — tudnunk kell, melyik verzió fut éppen, szükség esetén vissza tudjunk állni egy korábbi verzióra (rollback), és a változtatások nyomon követhetőek legyenek. A Model Registry pontosan ezt a governance-t biztosítja.

A folyamat: A kódban először a search_runs segítségével megkeressük a legjobb F1 score-ral rendelkező futást, majd register_model hívással regisztráljuk a modellt. Ezután az MlflowClient.transition_model_version_stage metódussal a modellt Production státuszba emeljük. Minden új regisztráció automatikusan új verziót hoz létre.

Tip: Élesben a Staging → Production lépést ne manuálisan végezd, hanem automatizáld: CI/CD pipeline validálja a modellt, és ha átmeneti teszteken is sikeres, automatikusan léptesse Production-be. Így elkerülhető az emberi hiba.

[4]

# Modell regisztrálása a legjobb futásból
best_run = mlflow.search_runs(
    experiment_names=["webshop-churn"],
    order_by=["metrics.f1_score DESC"]
).iloc[0]

model_uri = f"runs:/{best_run.run_id}/model"

# Regisztráció
mlflow.register_model(
    model_uri=model_uri,
    name="webshop-churn-classifier"
)

print(f"Regisztrált modell: {best_run.run_id[:8]}")
print(f"F1 score: {best_run['metrics.f1_score']:.3f}")

# Staging -> Production promotion
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="webshop-churn-classifier",
    version=1,
    stage="Production"
)
print("Modell Production stage-re állítva!")

Output:

[mlflow] Regisztrált modell: a3f7c2e1
[mlflow] F1 score: 0.875
[mlflow] Modell Production stage-re állítva!

Verzió kezelés

Minden regisztráció új verziót hoz létre. A production modell mindig egy specifikus verzió, amit bármikor vissza lehet állítani.

Section 07

Churn modell építés: teljes pipeline Python MLflow

Ebben a lépésben egy fejlettebb churn modellt építünk feature engineering segítségével. A feature engineering lényege, hogy a nyers adatokból új, informatívabb változókat hozunk létre, amelyekkel a modell jobban meg tudja fogni a churn mögötti mintákat. Célunk, hogy a churn valószínűséget a lehető legmegbízhatóbban predikáljuk.

Miért fontos a feature engineering? A nyers adatok (kor, jövedelem, vásárlások száma) önmagukban nem mindig tükrözik a churn kockázatát. Ha viszont olyan származtatott változókat hozunk létre, mint a purchase_rate (vásárlási gyakoriság) vagy a high_risk (magas kockázatú jelző), a modell sokkal jobban képes megkülönböztetni a churnelő és a maradó ügyfeleket.

A folyamat: Létrehozzuk az új featureöket, majd a bővített változóhalmazzal egy új RandomForest modellt tanítunk. Az MLflow-ba az összes paramétert és metrikát elmentjük, hogy a korábbi modellekkel összehasonlítható legyen a teljesítmény. A feature_importances_ elemzéssel megvizsgáljuk, melyik változó járul hozzá leginkább a predikcióhoz.

Tip: A feature importance mindig vizsgáld meg: ha egy fontos üzleti változó (pl. is_active) dominál, az jó jel. Ha viszont irreleváns változók kapnak nagy súlyt, az overfittingre utalhat. Ilyenkor érdemes a modellt egyszerűsíteni vagy regularizálni.

[5]

# Feature engineering
data["purchase_rate"] = data["purchases"] / (data["last_days"] + 1)
data["high_risk"] = ((data["last_days"] > 180) & (data["purchases"] < 10)).astype(int)

FEATURES = ["age", "income", "purchases", "last_days",
            "is_active", "purchase_rate", "high_risk"]

X = data[FEATURES]
y = data["churn"]
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

with mlflow.start_run(run_name="churn-v2-featured"):
    model = RandomForestClassifier(n_estimators=100, max_depth=10, random_state=42)
    model.fit(X_train, y_train)
    y_pred = model.predict(X_test)
    y_prob = model.predict_proba(X_test)[:, 1]

    acc = accuracy_score(y_test, y_pred)
    f1 = f1_score(y_test, y_pred)

    mlflow.log_params({"n_estimators": 100, "max_depth": 10, "features": len(FEATURES)})
    mlflow.log_metrics({"accuracy": acc, "f1_score": f1})
    mlflow.sklearn.log_model(model, "model")

    # Feature importances
    for name, imp in sorted(zip(FEATURES, model.feature_importances_), key=lambda x: -x[1]):
        print(f"  {name}: {imp:.3f}")

    print(f"\\nacc={acc:.3f}, f1={f1:.3f}")

Output:

[mlflow] Feature importance:
  is_active: 0.312
  last_days: 0.245
  purchase_rate: 0.189
  high_risk: 0.112
  income: 0.067
  age: 0.045
  purchases: 0.030

[mlflow] acc=0.965, f1=0.921

Section 08

Model validáció: gateway a productionhoz Python

A modell validáció egy minőségi kapu (quality gate) a production deployment előtt. Egy új modell csak akkor léphet élesbe, ha előre meghatározott validációs kritériumokat teljesít — ilyen például a minimális accuracy (pl. 90%) és minimális F1 score (pl. 85%). Ha a modell nem felel meg, a deployment automatikusan leáll.

Miért elengedhetetlen? Egy rosszul teljesítő modell productionbe állítata komoly üzleti kockázatot jelent: téves predikciók, rossz ügyfélmegítélés, potenciális bevételkiesés. A validációs küszöbök (thresholdok) biztosítják, hogy csak a kellően megbízható modellek kerüljenek az ügyfelek elé.

A folyamat: A kódban definiálunk egy validate_model függvényt, amely a tesztadatokon kiértékeli a modellt, és minden kritériumot ellenőriz. Ha bármelyik metrika a küszöb alá esik, a validáció megbukik. A függvény részletes eredményt ad vissza, így pontosan látható, melyik teszten ment át vagy esett el a modell.

Tip: Productionben a validáció kiterjeszthető: adj hozzá bias auditot (fairness check), latencia benchmarkot (a modell predikciós ideje elfogadható-e), memória-használat mérést, és baseline összehasonlítást (az új modell jobb-e, mint a jelenlegi production modell).

[6]

# Validációs kriteriumok
THRESHOLDS = {"min_accuracy": 0.90, "min_f1": 0.85}

def validate_model(model, X_test, y_test, thresholds):
    y_pred = model.predict(X_test)
    acc = accuracy_score(y_test, y_pred)
    f1 = f1_score(y_test, y_pred)

    results = {
        "accuracy": acc,
        "f1_score": f1,
        "passed": True,
        "checks": []
    }

    if acc < thresholds["min_accuracy"]:
        results["passed"] = False
        results["checks"].append(f"FAIL: accuracy {acc:.3f} < {thresholds['min_accuracy']}")
    else:
        results["checks"].append(f"PASS: accuracy {acc:.3f} >= {thresholds['min_accuracy']}")

    if f1 < thresholds["min_f1"]:
        results["passed"] = False
        results["checks"].append(f"FAIL: f1 {f1:.3f} < {thresholds['min_f1']}")
    else:
        results["checks"].append(f"PASS: f1 {f1:.3f} >= {thresholds['min_f1']}")

    return results

validation = validate_model(model, X_test, y_test, THRESHOLDS)
for check in validation["checks"]:
    print(check)
print(f"\\n VALIDATION {'PASSED ✓' if validation['passed'] else 'FAILED ✗'}")

Output:

[validate] PASS: accuracy 0.965 >= 0.90
[validate] PASS: f1 0.921 >= 0.85

VALIDATION PASSED ✓

Production validáció

Valójában: bias audit, fairness check, latency benchmark, memory usage, adversarial tesztek, regression vs baseline model.

Section 09

FastAPI: model serving FastAPI

A tanított modellt FastAPI REST API-val szolgáltatjuk ki, ami azt jelenti, hogy a modell predikcióit HTTP végponton keresztül teszi elérhetővé. Bármilyen alkalmazás — webes frontend, mobilalkalmazás, másik mikroszolgáltatás — egyszerű HTTP POST kéréssel kérhet churn predikciót.

Miért FastAPI? A FastAPI az egyik leggyorsabban fejlődő Python webes keretrendszer, amely natív aszinkron támogatást, automatikus OpenAPI dokumentációt és Pydantic-alapú adatvalidációt kínál. Ezek a tulajdonságok különösen fontosak ML modellek kiszolgálásánál, ahol a bemeneti adatok helyessége kritikus.

A folyamat: A kódban definiálunk egy CustomerData Pydantic modellt, amely leírja az API bemenetének szerkezetét (kor, jövedelem, vásárlások, stb.). A /predict végpont fogadja a kérést, kiszámítja a feature engineeringgel előállított változókat, majd a modell predict_proba metódusával meghatározza a churn valószínűséget és a kockázati szintet (LOW/MEDIUM/HIGH).

Tip: Productionben a modellt ne minden kérésnél töltsd be újra, hanem alkalmazz singleton mintát vagy modell caching-et. Emellett adj hozzá loggingot, hibakezelést és rate limitinget is a végponthoz.

[7]

# app.py - FastAPI szolgáltatás
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title="WebShop Churn API")

# Modell betöltése MLflow-bol
# model = mlflow.sklearn.load_model("models:/webshop-churn-classifier/Production")

class CustomerData(BaseModel):
    age: int
    income: float
    purchases: int
    last_days: int
    is_active: int

@app.post("/predict")
def predict(customer: CustomerData):
    features = [[customer.age, customer.income, customer.purchases,
                 customer.last_days, customer.is_active,
                 customer.purchases / (customer.last_days + 1),
                 1 if customer.last_days > 180 and customer.purchases < 10 else 0]]
    proba = model.predict_proba(features)[0][1]
    return {"churn_probability": round(proba, 3),
            "risk_level": "HIGH" if proba > 0.7 else "MEDIUM" if proba > 0.3 else "LOW"}

# uvicorn app:app --host 0.0.0.0 --port 8000
print("FastAPI app készen!")

Output:

[api] FastAPI app készen!
$ curl -X POST http://localhost:8000/predict \
  -H "Content-Type: application/json" \
  -d '{"age":35,"income":45000,"purchases":5,"last_days":250,"is_active":0}'

[api] {"churn_probability": 0.892, "risk_level": "HIGH"}

🔬 Feladat: API tesztelés

Küldd el ugyanezt a kérést más paraméterekkel. Milyen eredményt kapsz egy aktív, sokat vásárló felhasználóra?

Section 10

Docker konténerizáció Docker

A Docker konténerizáció a modell és az összes függőségének egy önálló, hordozható csomagba foglalását jelenti. A konténer garantálja, hogy a modell pontosan ugyanúgy működik a fejlesztői laptopon, a staging környezetben és a production szerveren — megszüntetve a „nálam működik" problémát.

Miért elengedhetetlen? ML modelleknél a futási környezet különösen sérülékeny: a Python verzió, a scikit-learn verzió, az operációs rendszer és a rendszerkönyvtárak is befolyásolhatják a predikció eredményét. A Docker ezeket a változókat rögzíti egy immutable image-ben, ami bárhová telepíthető.

A folyamat: A Dockerfile meghatározza, hogyan épül fel a konténer: alap image (python:3.11-slim), függőségek telepítése (requirements.txt), alkalmazáskód másolása és a futtatási parancs megadása. A docker build paranccsal létrehozzuk az image-et, a docker run paranccsal pedig elindítjuk, amely a 8000-as porton elérhetővé teszi a FastAPI szolgáltatást.

Tip: Használj multi-stage build-et a konténer méretének csökkentésére, és mindig fixeld a függőségek verzióit (pl. scikit-learn==1.3.0). Productionben a konténert Kubernetes vagy Docker Swarm segítségével skálázhatod több példányra.

[8]

# Dockerfile
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .
EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

# Build és futtatás
# docker build -t webshop-churn-api .
# docker run -p 8000:8000 webshop-churn-api

Output:

[docker] $ docker build -t webshop-churn-api .
[docker] [+] Building 45.2s
 => [1/5] FROM python:3.11-slim
 => [2/5] COPY requirements.txt .
 => [3/5] RUN pip install -r requirements.txt
 => [4/5] COPY app.py .
[docker] => exporting to image

[docker] $ docker run -p 8000:8000 webshop-churn-api
[api] INFO:     Started server process [1]
[api] INFO:     Uvicorn running on http://0.0.0.0:8000

Miért Docker?

Reprodukálhatóság: ugyanaz a környezet mindenütt. Skálázhatóság: Kubernetes-ben több példány. Izoláció: nincs függőségi konfliktus.

Section 11

CI/CD pipeline: automatizált deployment GitHub

A CI/CD (Continuous Integration / Continuous Deployment) automatizálja a szoftverfejlesztés kritikus lépéseit: a kód módosítás után automatikusan lefutnak a tesztek, ha azok átmegyünk, elkészül a Docker image, és ha az is valid, automatikusan deployolásra kerül a production környezetbe. Minden git push aktiválja a pipeline-t.

Miért fontos ML-nél? ML rendszereknél nemcsak a kód változik, hanem az adatok és a modell is. A CI/CD pipeline kiterjeszthető úgy, hogy modell validációt és drift ellenőrzést is tartalmazzon. Így garantálható, hogy egy hibás modell sosem kerül élesbe, és minden változtatás nyomon követhető.

A folyamat: A GitHub Actions workflow két job-ból áll: a test job futtatja a pytest teszteket és a modell validációt, a deploy job pedig (ha a tesztek átmentek) buildeli a Docker image-t és pusholja a registry-be. A két job közötti függőséget a needs: test biztosítja.

Tip: Valós projektekben a deploy job tartalmazzon canary deployment-et (először csak 1-5% forgalom az új verzióra), automatikus rollback lehetőséget és Slack/email értesítést a csapat számára. Emellett a modell artifact verziókat is számon kell tartani az MLflow Model Registry-ben.

[9]

# .github/workflows/deploy.yml
# name: ML Pipeline
# on: push
# jobs:
#   test:
#     runs-on: ubuntu-latest
#     steps:
#       - uses: actions/checkout@v4
#       - run: pip install -r requirements.txt
#       - run: pytest tests/
#       - run: python validate_model.py
#   deploy:
#     needs: test
#     steps:
#       - run: docker build -t churn-api .
#       - run: docker push registry/churn-api:latest

print("CI/CD pipeline konfigurálva!")
print("Minden push → teszt → validáció → deploy")

Output:

[ci] CI/CD pipeline konfigurálva!
[ci] Minden push → teszt → validáció → deploy

[ci] $ git push origin main
[ci] ✓ Tests passed (12/12)
[ci] ✓ Model validation: accuracy=0.965, f1=0.921
[docker] ✓ Docker image built: churn-api:v2.1
[ci] ✓ Deployed to production

Section 12

Monitoring és drift detektálás Grafana

A modell deployment után folyamatos monitorozásra van szükség, mert az ML modellek teljesítménye az idő múlásával romolhat. Két tipikus probléma fenyeget: a data drift, amikor a bemeneti adatok eltolódnak a tanító adatokhoz képest (pl. a felhasználók életkora megemelkedik, a jövedelemszerkezet megváltozik), és a concept drift, amikor maga a kapcsolat változik az input és az output között (pl. a vásárlói magatartás alapvetően átalakul egy új versenytárs miatt). Mindkettő a modell pontosságának romlásához vezet.

Miért kritikus? Productionben a modell csendben romolhat — a predikciók egyre pontatlanabbak lesznek, de ezt senki nem veszi észre, amíg valamilyen üzleti metrika (pl. megtartási arány, bevétel) el nem kezd csökkenni. A drift detektálás korai figyelmeztetést ad, még mielőtt az üzleti hatás jelentős lenne. Statisztikai tesztekkel (KS-test, PSI) összehasonlítjuk a referencia (tanító) és a jelenlegi adateloszlást, és ha a különbség meghaladja a küszöböt, riasztást küldünk.

A folyamat: A lenti kódban egy egyszerű drift detektálást valósítunk meg: a referencia adatok (tanító halmaz) és az újonnan érkező adatok feature-önkénti átlagait hasonlítjuk össze. Ha egy változó átlaga eltérése meghaladja a 5%-os küszöböt, driftet jelentünk. A szimulált új adatokban szándékosan idősebb és magasabb jövedelmű vásárlókat generálunk, hogy a drift jól látható legyen.

Tip: Productionben az egyszerű átlag-összehasonlítás helyett használj statisztikai teszteket: KS-test (Kolmogorov-Smirnov) a folytonos változók eloszlásának összehasonlítására, PSI (Population Stability Index) a teljes populáció stabilitásának mérésére, vagy dedikált könyvtárakat, mint az Evidently AI. A detektált drift automatikusan triggereljen újra tanítást (retrain) a friss adatokon.

[10]

def detect_drift(reference_data, current_data, threshold=0.05):
    # Egyszerű drift detektálás: feature átlagok összehasonlítása
    drift_detected = False
    alerts = []

    for col in reference_data.columns:
        ref_mean = reference_data[col].mean()
        cur_mean = current_data[col].mean()
        change = abs(ref_mean - cur_mean) / (ref_mean + 1e-6)

        if change > threshold:
            drift_detected = True
            alerts.append(f"⚠️ {col}: {ref_mean:.1f} → {cur_mean:.1f} ({change:.1%} változás)")

    return drift_detected, alerts

# Szimulált új adat (drift: több idős, magasabb jövedelem)
new_data = pd.DataFrame({
    "age": np.random.randint(40, 80, 200),
    "income": np.random.randint(60000, 150000, 200),
    "purchases": np.random.randint(0, 30, 200),
    "last_days": np.random.randint(1, 365, 200),
    "is_active": np.random.choice([0, 1], 200, p=[0.4, 0.6])
})

drift, alerts = detect_drift(X_train, new_data)
for a in alerts:
    print(a)
print(f"\\nDrift: {'DETECTÁLVA!' if drift else 'Nincs'}")

Output:

[monitor] ⚠️ age: 43.2 → 59.8 (38.3% változás)
[monitor] ⚠️ income: 69451.3 → 104832.7 (50.9% változás)

[monitor] Drift: DETECTÁLVA!

Demo vs Production

Demoban: egyszerű átlag összehasonlítás. Productionben: KS-test, PSI (Population Stability Index), Evidently AI, Prometheus metrikák, Grafana dashboard, auto-retrain trigger.

Section 13

A/B tesztelés: két modell összehasonlítása Python

A/B tesztelés során két modellverziót párhuzamosan futtatunk valós felhasználói adatokon, hogy statisztikailag megalapozott döntést hozhassunk arról, melyik teljesít jobban. A forgalom egy része (pl. 80%) a régi modellhez (A), a többi (pl. 20%) az új modellhez (B) kerül.

Miért fontos? A modell fejlesztésekor a tesztadatokon mért javulás nem feltétlenül jelent javulást valós adatokon. Az A/B tesztelés a valós környezetben, valós felhasználói interakciókkal méri a teljesítményt, így megbízhatóbb képet ad. Ez az egyetlen módszer, amely az üzleti hatást is képes mérni.

A folyamat: A kód egy szimulátort mutat be: 1000 kérést oszt szét a két modell között, majd méri az accuracy-t mindkét variánson. A z-test statisztikai szignifikanciát vizsgál — vagyis azt, hogy a mért különbség nem csupán véletlenszerű fluktuáció-e.

Tip: Productionben használj canary deployment-et (1% → 5% → 20% → 100% fokozatos rollout), definiálj egyértelmű „killer metric"-et (pl. F1 score vagy üzleti KPI), és állíts be automatikus rollback-et, ha a B variáns rosszabbul teljesít. A teszt időtartama legyen elegendő a statisztikai szignifikancia eléréséhez.

[11]

# A/B teszt szimulátor
np.random.seed(42)
n_requests = 1000

# Model A: jelenlegi (acc=0.950)
# Model B: új, feature engineering (acc=0.965)

results_a = {"correct": 0, "total": 0}
results_b = {"correct": 0, "total": 0}

for i in range(n_requests):
    # 80% Model A, 20% Model B
    if np.random.random() < 0.8:
        results_a["total"] += 1
        results_a["correct"] += 1 if np.random.random() < 0.950 else 0
    else:
        results_b["total"] += 1
        results_b["correct"] += 1 if np.random.random() < 0.965 else 0

print(f"Model A: {results_a['correct']}/{results_a['total']} = {results_a['correct']/results_a['total']:.3f}")
print(f"Model B: {results_b['correct']}/{results_b['total']} = {results_b['correct']/results_b['total']:.3f}")

# Statisztikai szignifikancia (egyszerű z-test)
improvement = (results_b["correct"]/results_b["total"]) - (results_a["correct"]/results_a["total"])
print(f"\\nJavulás: {improvement:+.3f}")

Output:

[ab-test] Model A: 758/798 = 0.950
[ab-test] Model B: 193/202 = 0.955

Javulás: +0.006

Production A/B

Valójában: canary deployment (1% forgalom), statisztikai szignifikancia számítás, fokozatos rollout, automatikus rollback, ha rosszabb.

Section 14

Összefoglalás MLflow FastAPI

Mit építettünk?

Egy teljes ML pipeline-t a tanítástól a monitoringig:

✅ MLflow kísérletkövetés (paraméterek, metrikák, modellek)
✅ Model Registry (verziózás, staging → production)
✅ Churn modell építése feature engineering-gel
✅ Automatizált modellvalidáció
✅ FastAPI REST API szolgáltatás
✅ Docker konténerizáció
✅ CI/CD pipeline (teszt → build → deploy)
✅ Monitoring és drift detektálás
✅ A/B tesztelés

Következő lépések

AI Engineering kurzus: RAG, chatbot, OpenAI API
AI Data Engineer kurzus: feature store, adat pipeline
Production MLOps: Kubernetes, Kubeflow, SageMaker, Vertex AI

Architecture recap:

📊 Adatok

→

🏋️ Tanitas

→

📋 MLflow

→

✅ Validáció

📦 Registry

→

🐳 Docker

→

🚀 FastAPI

→

📈 Monitoring

Szójegyzék

MLflow · Drift · A/B Testing

</> AIOps & MLOps Crash Course

MLOps: churn modell a tanítástól a productionig MLflow FastAPI

Fogalmi térkép: MLOps, CI/CD, drift, registry MLflow

Architektúratérkép: ML pipeline FastAPI

Környezet elokeszitese Python

MLflow alapok: kísérletkövetés MLflow

Kísérletkövetés: paraméterek és metrikák MLflow

Model Registry: modellverziózás MLflow

Churn modell építés: teljes pipeline Python MLflow

Model validáció: gateway a productionhoz Python

FastAPI: model serving FastAPI

Docker konténerizáció Docker

CI/CD pipeline: automatizált deployment GitHub

Monitoring és drift detektálás Grafana

A/B tesztelés: két modell összehasonlítása Python

Összefoglalás MLflow FastAPI

Quiz: Mi az MLflow fő funkciója?

Quiz: Mi a model drift?