Walk through MLflow's core components and how they map to an ML team's daily workflow.
Quick Answer
Tracking logs experiments (params, metrics, artifacts) so runs are comparable and reproducible; the Model Registry versions models with aliases and lifecycle metadata; MLflow Models packages any framework's model behind a uniform interface ('flavors') for serving; and evaluation/tracing features cover LLM apps. Together: experiment -> register -> promote -> serve, with lineage at each step.
Detailed Answer
Day to day: during experimentation, mlflow.log_params/log_metrics/log_model (or autolog) records every run to the tracking server — the team compares runs in the UI instead of spreadsheets, and any result links back to its exact code version, data, and environment. When a candidate looks good, the run's model is registered: the registry assigns version N under a model name, carrying descriptions, tags, and aliases (e.g., 'champion', 'challenger') that deployment tooling resolves. Serving loads the model by URI (models:/fraud@champion) via the pyfunc abstraction, so downstream code doesn't care whether it's sklearn, XGBoost, or PyTorch — that's the 'flavor' system. Modern MLflow (3.x) extends the same spine to LLM apps: tracing captures request-level spans, prompt versions, and evaluation results. The architectural point interviewers look for: MLflow is the metadata and lifecycle layer; it doesn't train, orchestrate, or serve at scale by itself — it plugs into your orchestrator, CI, and serving platform.
Code Example
with mlflow.start_run():
mlflow.log_params(cfg)
mlflow.log_metric('auc', auc)
mlflow.sklearn.log_model(model, 'model',
registered_model_name='fraud-detector',
signature=infer_signature(X_sample, y_sample))
prod = mlflow.pyfunc.load_model('models:/fraud-detector@champion')Interview Tip
Close with what MLflow is NOT (trainer, orchestrator, scale-out server) — scoping the tool correctly is what distinguishes practitioners from tutorial readers.