When to build custom models, when not to, and the bar to clear first
I have had a lot of personal experience with this question: when do you actually fine-tune, and when is it a mistake that shows up in so many different ways, in dollars, in time, and in hurt egos. So I just wanted to share my thoughts about it.
Intelligence Is Not the Problem. Context Is.
Here is the sense I have been getting for a while now. The intelligence of the model is not the problem, unless you are looking at very particular and peculiar use cases. The context is the problem. Getting the right depth of context to the model at the right time, under the right guardrails and governance, at the right cost, is the harder and more valuable problem to solve.
The strongest evidence I have seen for this comes from "Why Do Multi-Agent LLM Systems Fail?", a study of over 1,600 annotated failure traces across seven multi-agent frameworks. It catalogues "14 unique modes, clustered into 3 categories: (i) system design issues, (ii) inter-agent misalignment, and (iii) task verification." Read that list again: not one of the three categories is about the model not being smart enough. The agents were mostly reasoning correctly on broken context.
And unless you are right at the frontier, most business problems are about building a resilient system, not about building frontier tech. Before you reach for a custom model, ask whether what you actually have is a context problem, a retrieval problem, or a reliability problem, rather than a model problem.
Why the Pull Toward Custom Models Exists
I am a little cautious saying all this, and here is why. The AI wave has largely been driven by academia, by researchers and universities, through the papers that were written. Some of them we all know, some we keep coming across. Even now, many of the top technical positions are occupied by researchers, because we are at a point where the defaults have not been established. We have not put together repeatable practices yet, so a lot of researchers are trying a lot of things, and that is exactly what the moment needs.
But a researcher's default and intuition is to push the needle of what we know, and pushing the needle requires research on training new models, which most often means fine-tuning, reinforcement learning, and everything that comes with them. So in a lot of organizations, and in a lot of tech blogs we all read, I sometimes do not see enough valid reasons for going in that direction. If it is exploratory, that is fine. But if your business relies on that decision, and you have to stick with it, then sometimes it just feels forced.
Reading between the lines, part of what some of those blogs are building is a brand: we are an AI leader. And I almost sense that the companies that have gotten it right are mostly not training new models at all. They are hosting models and building the infrastructure around them, because they have not found good enough reasons to train from scratch. That is an indicator startups could take seriously.
Databricks is a good example. It is about as technology-forward as companies get, with some of the best researchers and engineers at its disposal after acquiring MosaicML. They made a serious attempt at their own model, DBRX, in 2024. And then they stepped back: within a year, DBRX was retired from their own fine-tuning platform, and the company put its weight behind hosting models, serving them, and building the infrastructure and governance around them. A company with that level of talent, that much data, and every reason to own a model looked at the frontier race and decided the better business was around the models, not in them. If they could not justify staying in, most companies should think hard before buying in.
There is even a hiring version of this mistake. The right engineer for a retrieval product is a fundamentally different person from an ML researcher for a fine-tuning project, and getting that wrong costs months of misaligned effort. Choosing fine-tuning is not just a technical bet. It quietly decides who you hire, what infrastructure you build, and what your team spends its year on.
A Year I Watched Go Sideways
One case I saw up close: a team I worked closely with was set on baking general knowledge about the product into a model, with a continuous learning pipeline to keep that model updated. That can be done, but it is very, very hard to do well, compared to retrieval. A scalable RAG system was being built in parallel, but because of the friction between the two teams, it never got the investment it needed to become actually reliable. So neither path got a fair chance to prove itself, and honestly, I feel it cost close to a year: wasted time, a lot of friction, a lot of hurt egos, and real business lost. Product knowledge changes constantly. Weights do not want to change constantly. Retrieval was built for exactly this, and the metrics to prove or disprove that were never really put on the table first. That is the part I keep coming back to.
This failure mode is well documented by now. Baking changeable knowledge into weights puts you on a retraining treadmill: the facts change, and the only way to update them is another training run. The consensus that has settled is fine-tune for behavior, use retrieval for knowledge.
The Bar: Data, Strategy, Metrics
One thing I have really come to understand is that teams should not rush out and start fine-tuning models and building custom models unless three things are true:
- They have data. Actual data, quality data. Not a plan to get data, not a hope that data will show up. And ideally not a one-time pile but a source that keeps producing, because fine-tunes need refreshing.
- They have a really, really good strategy for it. Who trains it, who maintains it, how it gets updated when the product changes, what happens when a better base model releases next quarter.
- They have the metrics which justify moving to that kind of a solution. Numbers showing that existing open-source or frontier models with good context are not enough, backed by an actual baseline comparison rather than a feeling.
There are areas where fine-tuning is more obvious than others, especially when you are dealing with very domain-specific businesses, software, and products. But a lot of the time it is not obvious, and that is where it helps to put together an SOP that can drive the decision. Something that forces a structured conversation: what are the tenets that make sense to us, that are relevant to us, and particularly relevant to this product and business? And how do those tenets actually factor into the decision we ultimately have to take? Writing that down before the debate starts is what keeps the debate honest.
The research backs the data bar harder than most people expect. "LIMA: Less Is More for Alignment" took a model "fine-tuned with the standard supervised loss on only 1,000 carefully curated prompts and responses" and found its "responses from LIMA are either equivalent or strictly preferred to GPT-4 in 43% of cases." Their conclusion: "almost all knowledge in large language models is learned during pretraining, and only limited instruction tuning data is necessary." So the question is never whether you can collect rows. It is whether you have a source of high-quality examples that look like your real users, with labels an expert would sign off on. And when enterprise fine-tuning projects underdeliver, the post-mortems almost always land in the same place: the training run was fine, the data was not.
The Caveat I Want to End On
I want to call all of this out with a caveat I genuinely believe: we do need researchers driving this AI wave, because right now it is more about innovation than repeatable engineering practices, and innovation is what researchers are for. My hope is just that the other factor, whether you are actually working back from a customer problem, starts to chime in and play its part as we go about this hard innovation. Fine-tune when the data, the strategy, and the metrics say so. Until then, spend the effort on context, retrieval, and resilience.