Here's a habit so universal in machine learning that we've stopped seeing it as a choice: you train on your data, the pipeline hands you back <em>one</em> model, and that model becomes The Model. It gets evaluated, deployed, argued about, and eventually blamed. Every downstream conversation assumes its singularity.
But the data never said there was one model. For most realistic problems — especially the noisy, limited-data problems that matter — there isn't a single best model at all. There's an enormous <em>set</em> of models that fit the data essentially equally well. Different structures, different variables, different logic, indistinguishable on the metrics. Researchers have a lovely name for this: the <strong>Rashomon set</strong>, after the film in which every witness tells a different but internally consistent version of the same event.
Once you take the Rashomon set seriously, a lot of standard ML practice starts to look strange. We take a space containing potentially millions of equally good models and collapse it — arbitrarily, by whatever the optimizer happened to converge to — down to one. Then we present that one to the people who actually understand the problem and ask them to live with it.
The interaction bottleneck
I've watched what happens next often enough to give it a name: the interaction bottleneck.
You hand a domain expert — a physician, a credit-risk officer, a reliability engineer — a single interpretable model. Because it's interpretable, they can actually read it. And because they can read it, they find problems with it. "This variable shouldn't be here; it's a proxy for something we're not allowed to use." "This threshold contradicts twenty years of clinical experience." "This feature is collected inconsistently at night."
This is exactly the feedback you want! But in the one-model workflow, every piece of feedback triggers a full round trip: reformulate the problem, retrain, return with a new single model, and hope it doesn't offend some <em>other</em> piece of domain knowledge. Iterating this way is agonizing — a giant mess of retraining loops in which the expert's knowledge enters the process one complaint at a time, through a straw.
The bottleneck was never the expert. It was the interface: we gave them veto power over one model at a time, when what they actually possess is the ability to evaluate <em>whole regions</em> of the model space at once.
Flip the workflow: return them all
So flip it. Instead of returning one model, return the good ones — as many of the near-optimal set as you can enumerate — and build an interface that lets domain experts <em>search</em> it.
The moment you do this, the expert's role transforms. Instead of critiquing a single artifact, they browse — the way you'd browse an encyclopedia or a well-organized catalog. "Show me the models that don't use this variable at all." A whole region of the space disappears. "Nothing that looks like this family — that shape can't be right." Another region gone. "These three are plausible; we'd want more data about this factor before choosing among them." Now you know exactly what data to collect next.
Two things about this flip are easy to underestimate.
<strong>First, the constraints being applied are unwriteable.</strong> The expert is enforcing knowledge that never made it into the loss function and never could have — regulatory nuance, institutional context, decades of pattern recognition about which relationships are real and which are artifacts. There is no way to encode all of that up front. But given a navigable set of good models, experts apply it <em>fluently</em>, narrowing millions of candidates to a shortlist in a way no metric could.
<strong>Second, the accuracy cost is zero.</strong> Every model in the set fits the data equally well — that's the definition of the set. Whatever the expert picks, you lose nothing statistically. The choice among equally-accurate models gets made by domain knowledge instead of by optimizer happenstance. It's a free lunch, and we've been leaving it on the table for decades because our tooling only knew how to serve one dish.
There's a quieter benefit too: legitimacy. A model <em>chosen</em> by the people accountable for the decisions it supports is a fundamentally different object — politically, organizationally, ethically — from a model handed down by a pipeline. Adoption problems that look like "resistance to AI" are often just experts declining to be accountable for something they had no hand in shaping. Give them the hand.
Why this hasn't been the norm
Partly it's technical: enumerating and storing a huge set of near-optimal models, and building visual interfaces good enough to make that set searchable, is real work — an active research frontier sitting at the intersection of machine learning and human-computer interaction. The early tools are promising, and user studies are still shaping what "browsing a model space" should even feel like.
But mostly, I think, it's habit. The one-model workflow is what our libraries return, what our courses teach, what our MLOps stacks assume. Multiplicity feels like an inconvenience to be optimized away rather than what it actually is: information. If a million different models explain your data equally well, that fact <em>tells you something</em> — about how underdetermined your problem is, about how much room your domain experts legitimately have to shape the answer, and about how silly it is to treat any single model's quirks as truth.
The takeaway
If you build ML systems for domains where experts must trust and act on the output, stop asking "what's the best model?" Start asking "what does the set of good models look like, and who should choose from it?"
Practically: prefer interpretable model classes so the set is browsable at all. Invest in the interface, not just the optimizer — the bottleneck is interaction, not accuracy. And treat your domain experts as co-designers with search tools, not as reviewers with veto power over whatever the pipeline happened to emit.
The data was never going to pick your model for you. It only ever narrowed the field. The last step — the one that decides what actually gets deployed on real people — was always a human choice. The only question is whether you make that choice deliberately, with the right people holding the map, or accidentally, inside an optimizer nobody was watching.
