MLflow for Experiment Tracking

Key facts, with sources

• The global MLOps market was estimated at about 3.03 billion US dollars in 2025 and is projected to grow at a 40.5% compound annual growth rate from 2025 to 2030. (Grand View Research)
• Precedence Research projects the MLOps market will reach about 56.6 billion US dollars by 2035, up from roughly 2.43 billion in 2025. (Precedence Research)
• An analysis of MIT and Harvard research covering 128 model-dataset pairs across 32 datasets in four industries found 91% of machine learning models degrade over time in production. (NannyML)
• Models left unchanged in production for six months or longer see error rates jump about 35% on new data, according to a 2025 model drift and retraining guide summarizing industry research. (SmartDev)
• A 2024 practitioner study on ML deployment and monitoring found most organizations monitor less than 40% of their production models, with the most common answer being under 20%. (arXiv)

The five-minute setup

MLflow's tracking API is deliberately boring: start a run, log things, end the run. Locally it writes to a folder and the UI runs on localhost; for a team, point MLFLOW_TRACKING_URI at a shared server backed by Postgres and object storage. The API is identical either way, so starting local costs nothing.

import mlflow

mlflow.set_experiment("ticket-router")

with mlflow.start_run(run_name="tfidf-logreg-bigrams"):
    mlflow.log_params({
        "vectorizer": "tfidf",
        "ngram_range": "1-2",
        "C": 1.0,
        "class_weight": "balanced",
        "train_rows": len(X_train),
        "data_snapshot": "tickets-2026-07-01",  # reproducibility anchor
    })

    model.fit(X_train, y_train)

    mlflow.log_metrics({
        "f1_macro": f1_macro,
        "accuracy": acc,
        "f1_worst_class": worst_class_f1,  # averages hide failures
    })
    mlflow.sklearn.log_model(model, name="model")

# Browse everything: `mlflow ui` → http://localhost:5000

Log for reproducibility, not for decoration

The accuracy number is the least valuable thing in a run record — you'll remember roughly how good the model was. What you won't remember in three months is everything needed to rebuild it: which data snapshot trained it, which feature-engineering commit processed that data, which library versions were installed. Log a dataset identifier (a snapshot name, a query plus date, or a data hash), let MLflow capture the git commit (it does automatically when you run from a repo), and log the environment via the model artifact's dependency capture.

The test of a good tracking habit: could a new teammate reproduce your best run from the MLflow record alone, without asking you anything? If the answer is no, you have a leaderboard, not experiment tracking.

Conventions that keep a shared server useful

Tracking servers rot socially, not technically — a hundred runs named 'test' with three logged params each is write-only noise. Three conventions prevent it. One experiment per problem, not per person: 'ticket-router', not 'dhairya-experiments'. Run names that state the hypothesis: 'bigrams-vs-unigrams', not 'run-47'. And tags for lifecycle: tag runs as candidate, shipped, or archived so the registry promotion story is visible in the tracking UI.

Also log the metric that reflects the product, not just the modeling default — for an imbalanced routing problem, macro-F1 and the worst class's F1, because the overall accuracy will look fine while one queue silently gets everything wrong.

From tracking to registry: closing the loop

Tracking answers 'what did we try'; the model registry answers 'what is running in production'. They connect: register the winning run's model, promote it through aliases (staging, production), and your deployment layer loads by alias. Now every production model traces back through the registry to the exact run — parameters, data snapshot, code commit — that created it. That lineage is what turns a production incident from archaeology into a lookup.

When to adopt a managed alternative instead of self-hosting: if nobody on the team wants to own a tracking server's uptime, backups, and auth, hosted options are worth their cost — the tracking discipline matters far more than where the server runs.

When to hire senior help

Consider senior MLOps help once models are making real decisions and nobody can answer what version is live, when it was last retrained, or whether accuracy is drifting, since most organizations monitor under 40% of their production models. The failure mode it prevents, silent degradation discovered through business losses, is far more expensive than the engagement itself. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships ML — MLOps projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Buying a full MLOps platform for one or two models, adding process overhead before the models have proven business value
• ✕Monitoring only infrastructure metrics like latency and CPU while prediction drift and input data quality degrade silently
• ✕Skipping model and data versioning, so a bad release cannot be rolled back or a past prediction reproduced for debugging
• ✕Retraining on a fixed calendar schedule rather than on detected drift, either wasting compute or reacting months too late

Frequently asked questions

Sources

• Grand View Research
• Precedence Research
• NannyML
• SmartDev
• arXiv