MLOps in 2026: MLflow, Model Registry en technische sollicitatievragen

MLOps-sollicitatievragen zijn in 2026 verschoven van een nichespecialisatie naar een kernonderdeel van de werving van data scientists en machine learning engineers. Teams vragen niet langer alleen hoe een model wordt getraind; ze onderzoeken hoe het wordt getraceerd, geversioneerd, uitgerold en gemonitord zodra echt verkeer het bereikt. Deze gids behandelt de vragen die telkens terugkeren in MLOps-gesprekken, gegroepeerd per fase van de levenscyclus, met MLflow-voorbeelden die productieopstellingen weerspiegelen.

MLOps-sollicitatievragen over de machine learning-levenscyclus

Q1: Wat is MLOps en hoe verschilt het van DevOps?

MLOps past DevOps-principes zoals automatisering, CI/CD en monitoring toe op machine learning-systemen en voegt er vervolgens drie zorgen aan toe die traditionele software niet kent: dataversionering, modelversionering en continue validatie tegen live datadistributies. In klassieke DevOps is code het enige artefact dat verandert. In MLOps versioneren code, data en het getrainde model elk onafhankelijk, en elk van de drie kan de outputkwaliteit stilzwijgend verslechteren zonder dat er ook maar één regel code verandert. De vaak geciteerde paper Hidden Technical Debt in Machine Learning Systems maakt duidelijk dat modelcode slechts een klein deel van een echt ML-systeem vormt, waarbij datapijplijnen, monitoring en configuratie het grootste oppervlak innemen.

Q2: Loop door de fasen van een ML-levenscyclus in productie.

Een sterk antwoord benoemt vijf fasen en het artefact dat elke fase oplevert: data-inname en -validatie (een geversioneerde dataset), experimenteren (getraceerde runs met metrics), modelregistratie (een geversioneerd, promoveerbaar model), uitrol (een serving-endpoint of batchtaak) en monitoring (drift- en prestatietelemetrie die terugvloeit naar hertraining). Interviewers letten op de feedbacklus: monitoring moet terugkoppelen naar het experimenteren, anders is het systeem een eenrichtingspijplijn die na verloop van tijd wegrot.

Experiment tracking met een MLflow-tutorialvoorbeeld

Experiment tracking is de basis waarop de meeste MLOps-vragen voortbouwen, dus een MLflow-tutorialantwoord dat echte logging laat zien, weegt zwaar. MLflow legt per run parameters, metrics en artefacten vast, waardoor elk resultaat reproduceerbaar wordt vanuit de run-ID.

Q3: Hoe legt MLflow-tracking een experiment vast en waarom is de run-ID belangrijk?

Elke aanroep van mlflow.start_run() opent een run die hyperparameters, metrics en het geserialiseerde model logt. De run-ID is de onveranderlijke verwijzing die een metric terugkoppelt aan exact de code, parameters en datamomentopname die deze produceerden, en dat maakt een experiment maanden later nog reproduceerbaar.

# train_with_mlflow.py
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("http://localhost:5000")  # tracking server
mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="rf-baseline") as run:
    params = {"n_estimators": 300, "max_depth": 12}
    model = RandomForestClassifier(**params).fit(X_train, y_train)

    f1 = f1_score(y_val, model.predict(X_val))

    mlflow.log_params(params)                       # hyperparameters
    mlflow.log_metric("val_f1", f1)                 # validation metric
    mlflow.sklearn.log_model(model, name="model")   # MLflow 3.x uses name=

    print("run_id:", run.info.run_id)               # reproducibility handle

Het argument name vervangt het verouderde artifact_path in MLflow 3.x, een wijziging die het vermelden waard is om kennis van de huidige API te tonen. Kandidaten die verwijzen naar feature- en datasettracking via validatiepatronen voor ML-pijplijnen scoren doorgaans hoger, omdat reproduceerbaarheid afhangt van de hele pijplijn en niet alleen van het model.

Model Registry 2026: versionering en promotie

De MLflow Model Registry maakt van een run-artefact een beheerd, promoveerbaar object. De grootste recente verschuiving, en een veelvoorkomende sollicitatievraag in 2026, is de overstap weg van benoemde stages.

Q4: Hoe promoot de MLflow Model Registry een model en wat is er veranderd in 2026?

Eerdere MLflow-versies promoveerden modellen via vaste stages met de namen Staging, Production en Archived. MLflow 3.x verklaart die stages verouderd ten gunste van aliassen en tags, omdat een hardgecodeerde lijst met stages geen echte uitroltopologieën zoals champion, challenger of shadow kon uitdrukken. Een alias is een veranderlijke verwijzing naar één versie, waardoor promotie neerkomt op het opnieuw toewijzen van de alias in plaats van het muteren van het model.

# register_and_promote.py
import mlflow
from mlflow import MlflowClient

client = MlflowClient()

# Register a logged run artifact as a new model version
result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="churn-classifier"
)

# MLflow 3.x: aliases replace deprecated stages
client.set_registered_model_alias(
    name="churn-classifier",
    alias="champion",        # production traffic resolves here
    version=result.version
)

# Any service loads the current champion without knowing the version
model = mlflow.pyfunc.load_model("models:/churn-classifier@champion")

Omdat consumenten models:/churn-classifier@champion laden, is een rollback één enkele hertoewijzing van de alias naar een eerdere versie, zonder opnieuw uit te rollen. De officiële documentatie van de MLflow Model Registry behandelt aliasbeheer en webhooktriggers uitgebreid.

Machine learning-uitrolpatronen en serving

Uitrolvragen scheiden kandidaten die modellen in productie hebben gebracht van kandidaten die ze alleen hebben getraind. De patroonkeuze volgt het latentiebudget, niet de persoonlijke voorkeur.

Q5: Vergelijk batch-, online- en streaming-uitrol van machine learning.

| Patroon | Latentie | Typische use case | Serving-oppervlak | |---------|---------|------------------|-----------------| | Batch | Uren tot dagelijks | Churn-scoring, verversen van aanbevelingen | Geplande taak die naar een tabel schrijft | | Online (realtime) | Tientallen milliseconden | Fraudecontroles, ranking op moment van verzoek | REST- of gRPC-endpoint | | Streaming | Subseconde, continu | Anomaliedetectie op eventstromen | Consumer op een message queue |

De vervolgvraag gaat vrijwel altijd over hoe je de online-casus serveert. Een MLflow-model verpakt zijn eigen omgeving, dus het serveren ervan is één commando tegen een registry-URI.

# serve_model.sh
# Serve the current champion as a REST endpoint on port 5001
mlflow models serve \
  --model-uri "models:/churn-classifier@champion" \
  --host 0.0.0.0 --port 5001 --env-manager uv

Q6: Hoe verminderen blue-green- en canary-uitrollen het risico bij een modeluitrol?

Blue-green houdt twee identieke omgevingen aan en schakelt al het verkeer in één keer om nadat het nieuwe model de controles heeft doorstaan, wat een onmiddellijk rollbackpad oplevert. Canary stuurt een klein percentage van het verkeer naar de nieuwe versie, bewaakt live metrics en schaalt vervolgens geleidelijk op. Voor modellen is canary meestal veiliger, omdat kwaliteitsproblemen van een model pas aan het licht komen bij echte input, en een canary beperkt de impactstraal tot een fractie van de gebruikers.

Testen en CI/CD voor machine learning-pijplijnen

Q7: Wat test CI/CD in een ML-pijplijn dat een standaard softwarepijplijn niet test?

Een software-CI-pijplijn draait unit- en integratietests op code. Een ML-pijplijn voegt daar data- en modeltests aan toe: schemavalidatie op inkomende data, distributiecontroles zodat een trainingsrun niet stilzwijgend beschadigde features inleest, en een modelkwaliteitspoort die de build laat mislukken wanneer een kandidaat lager scoort dan de huidige champion op een vaste holdout-set. Continuous delivery voor ML promoveert daarom een modelartefact, niet alleen een containerimage, en de promotiepoort is een metricdrempel in plaats van uitsluitend een groene testsuite. Een strikte pijplijn pint bovendien datamomentopnamen en afhankelijkheidsversies vast zodat elke herhaling deterministisch is, en dat is wat een reproduceerbare build onderscheidt van een build die vandaag toevallig slaagt.

Monitoring, datadrift en hertraining van modellen

Een uitgerold model verslechtert naarmate de wereld eronder verschuift, dus bij monitoringvragen komt het seniorsignaal naar boven.

Q8: Hoe wordt datadrift gedetecteerd en welke metric kwantificeert het?

Datadrift betekent dat de distributie van productie-input is weggedreven van de trainingsdistributie. De Population Stability Index (PSI) is een veelgebruikte, framework-onafhankelijke maatstaf: hij verdeelt een referentiedistributie in bins, vergelijkt productiefrequenties met die bins en telt de gewogen logverschillen op.

# population_stability_index.py
import numpy as np

def psi(reference, production, bins=10):
    # Bin edges come from the reference (training) distribution
    edges = np.quantile(reference, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf

    ref_pct = np.histogram(reference, edges)[0] / len(reference)
    prod_pct = np.histogram(production, edges)[0] / len(production)

    # Clip to avoid division by zero and log(0)
    ref_pct = np.clip(ref_pct, 1e-6, None)
    prod_pct = np.clip(prod_pct, 1e-6, None)

    return float(np.sum((prod_pct - ref_pct) * np.log(prod_pct / ref_pct)))

# PSI < 0.1 stable | 0.1-0.25 moderate shift | > 0.25 major drift, investigate
score = psi(reference_scores, production_scores)

Naast een zelfgebouwde metric grijpen productieteams naar tooling zoals Evidently om featuredrift, targetdrift en datakwaliteit volgens een schema te volgen. Een compleet antwoord onderscheidt datadrift (de input verschuift) van conceptdrift (de relatie tussen input en output verschuift), omdat de tweede niet te betrappen is door alleen naar de input te kijken en gelabelde uitkomsten vereist.

Q9: Wat zou een hertrainingspijplijn moeten triggeren?

Tijdgebaseerde hertraining op een vast ritme is de eenvoudigste optie, maar verspilt rekenkracht wanneer er niets is veranderd en reageert traag wanneer er iets breekt. Betere triggers zijn metricgebaseerd: hertrainen wanneer de PSI een drempel overschrijdt, wanneer een live evaluatiemetric onder een ondergrens zakt, of wanneer een geplande backtest op vers gelabelde data achteruitgaat. De hertrainingstaak registreert vervolgens een challenger, die een canary-uitrol vergelijkt met de huidige champion voordat een alias opnieuw wordt toegewezen.

MLOps-sollicitatievragen over systeemontwerp

Q10: Ontwerp een platform dat honderden modellen bedient met consistente features.

Het verwachte middelpunt is een feature store, die training-serving skew oplost door features één keer te berekenen en identieke waarden te serveren aan zowel training als inference. Tools zoals Feast bieden een offline store voor training en een online store met lage latentie voor serving. Een volledig ontwerp benoemt daarnaast een model registry voor versionering, een tracking-server voor lineage, een orchestrator voor pijplijnen en een monitoringlaag die de lus terug naar hertraining sluit. Het antwoord onderbouwen met echt featurewerk, zoals de afwegingen in deze gids met sollicitatievragen over feature engineering, wijst op praktijkervaring in plaats van het napraten van een diagram.

Conclusie

• Kader MLOps als DevOps plus data- en modelversionering: reproduceerbaarheid, veilige promotie en monitoring zijn de drie assen waarop interviewers beoordelen
• Ken de API-verschuiving in MLflow 3.x: aliassen en tags vervangen de verouderde stages Staging en Production, en log_model neemt nu name in plaats van artifact_path
• Stem het uitrolpatroon af op het latentiebudget en kies standaard voor canary boven blue-green bij modeluitrollen, omdat kwaliteitsproblemen alleen bij live input verschijnen
• Kwantificeer drift met een concrete metric zoals PSI en maak onderscheid tussen datadrift en conceptdrift, aangezien slechts één ervan zichtbaar is zonder labels
• Trigger hertraining op basis van metrics in plaats van de kalender, en leid de resulterende challenger via een canary voordat de champion-alias opnieuw wordt toegewezen
• Benoem een feature store in elk systeemontwerpantwoord om de kloof van training-serving skew te dichten voordat deze als vervolgvraag wordt opgeworpen