Opening the MLflow UI has become useless: the default experiment holds 400-plus
runs, most named test, test2, or the auto-generated animal names, many with no
metrics at all. Finding last month's winning run takes twenty minutes of clicking.
Teammates have quietly gone back to noting scores in chat messages, and the team
lead asks whether MLflow "is even worth it".
Three months after tracking was adopted with enthusiasm and no rules. Every debugging attempt, crashed script and half-finished experiment logged itself into the default experiment. Nobody named runs, nobody deleted anything, and nobody owned the table. The tool did exactly what it was told — which is the problem. Linked module: 4.4.
This is not a tool failure; it is hygiene debt. Tracking's value is retrieval — the
Tuesday question answered in seconds — and retrieval dies when the signal-to-junk
ratio collapses. Read the table to confirm the pattern: runs with no metrics are
crashed or abandoned scripts; runs named test are debugging sessions that were
never meant to be kept; everything sits in one default experiment, so real sweeps
and scratch work are interleaved. The give-away that discipline, not the tool, is
the cause: the few properly named runs (like logreg-C0.5) are findable instantly
even now.
Run a one-time cleanup with a simple triage: runs with no metrics are deleted;
unnamed runs older than a month are deleted unless someone claims them this week;
real work is moved into purpose-named experiments (churn-tuning,
churn-features) using search_runs to find and re-tag what is worth keeping.
Automate the sweep with MlflowClient — delete_run in a loop over a search_runs
filter — rather than clicking 400 times. Then declare the new rules in the repo
README, where the next joiner will actually read them.
Three rules keep the table readable forever. Naming: experiments are named for
purpose, runs for what changed — a run named test is a future mystery. Scratch
space: debugging runs go into a scratch experiment that is deleted weekly,
guilt-free. The metrics rule: a run that logs no metrics gets deleted on sight,
because it can never answer a question. Periodic cleanup — ten minutes at sprint
end — costs less than one drowned-table archaeology session.
Q: "You join a team whose tracking server holds 400 junk runs and the team has stopped using it. Tool problem or team problem, and what do you do?" Strong answer: team problem wearing a tool costume — tracking records whatever discipline feeds it; give the triage (no-metrics runs deleted, unnamed runs claimed or deleted, real work re-homed into named experiments), then the standing rules: naming convention, scratch experiment with weekly deletion, cleanup as a recurring ritual. Bonus signal: automating the cleanup with search_runs + delete_run instead of clicking.