What is MLflow for, and what are its four components?

Question

FDEInterviews · Accepted Answer

TL;DR: MLflow answers "where did this model come from" through four components: Tracking (runs, params, metrics), Projects (packaged training code, the least-adopted one), Models (the packaging format and signature), and Registry (versioning, lineage, and alias-based promotion). The differentiator is one practitioner-grade opinion per component, not the four names. How to approach it This is a knowledge check, common in Databricks-stack loops and phone screens. The four names are table stakes; differentiation comes from saying one practitioner-grade thing about each. Answer in thirty seconds of structure, then add the texture that proves usage. A strong answer MLflow solves the "where did this model come from" problem, it makes experiments comparable, models packageable, and the path to production auditable. Four components: Tracking logs runs: parameters, metrics, artifacts, source commit, environment. The practitioner detail: autologging gets you 80% (one line for sklearn/XGBoost/PyTorch), but the value shows up when you log the things autolog can't know, the dataset snapshot version and the evaluation slice metrics, because that's what you need six months later when someone asks why March's model behaved differently. Projects packages training code with its environment (MLproject file, conda/Docker) for reproducible runs. Honest take that reads senior: this is the least-adopted component in practice. Most teams already standardize on their own Docker images and an orchestrator like Airflow or SageMaker Pipelines, so Projects ends up redundant. Saying so signals you've actually shipped with the stack rather than memorized the docs page. Models is the packaging format, a model plus its "flavors" (sklearn, pyfunc, onnx) and signature, so any downstream tool can load and serve it uniformly. The signature matters more than people think: it's your first schema contract between training and serving, and it catches "the API sends strings, the model expects floats" at registration instead of in production. Model Registry is the lifecycle layer: versions per model name, lineage back to the run that produced each version, annotations, and controlled promotion. The current-knowledge marker interviewers listen for: fixed stages (Staging/Production) are the legacy pattern; modern MLflow uses aliases, mutable named pointers like @champion and @challenger, so serving code loads models:/fraud@champion and promotion is an alias reassignment, atomic and instantly reversible. The "where did this model come from" promise stays abstract until you walk the chain under incident pressure, so walk it. A pricing analyst reports that March approvals look systematically looser than February's. The audit runs backward, one hop per artifact: serving config says it loads models:/fraud@champion; the registry shows @champion was reassigned from version 22 to version 23 on March 3; version 23's lineage points at run 4f9a...; the run's logged params show scaleposweight changed and its logged dataset tag shows training moved from the January to the February snapshot, the one that includes a promotion period with unusual approval patterns. Twenty minutes, no archaeology, and you can now say which of two changes to investigate first. Then say the quiet part: every hop in that chain existed because someone logged it at training time. The team that skipped logging the dataset tag has an unanswerable question and a model they can only rebuild blind, which is why tracking discipline is an operational control, not research hygiene. If asked where it runs: self-hosted tracking server backed by a database plus S3 for artifacts, or managed inside Databricks/SageMaker, and on shared instances, access control around who can reassign a production alias is the part that needs real thought. How the four pieces hand off: The dashed Projects edge is deliberate: most teams substitute their own Docker images, so it rarely sits on the critical path. What interviewers probe next "Which component would you drop?", Projects; environment reproducibility is better handled by the Docker images your CI already builds. Having a defensible opinion here is the point. "How does the Registry hook into CI/CD?", registration events trigger webhooks (or a polling job) that kick off validation; promotion to @champion only happens after gates pass. The registry is the interface between training and deployment, not a parking lot. "MLflow versus Weights & Biases?", W&B has the better experiment UX for research-heavy teams; MLflow wins when the registry and serving integration matter and you're on Databricks or want self-hosted. Pick based on whether your bottleneck is experimentation or production lifecycle. "How do you trace a registry version back to its training data?", version → run → logged params and dataset version; if you didn't log the data snapshot, the chain is broken, which is why data versioning is a logging discipline, not a feature you enable. Common mistakes…