The counterintuitive result is that smaller can be better.
The industry’s working assumption for years was that the biggest model, most parameters, most data, wins. For a lot of work, the opposite turns out to be true, and understanding why is the starting point.
Frontier models are general-purpose all-rounders. To answer almost any question, they carry hundreds of billions of parameters; some run beyond a trillion. That breadth is real and valuable for open-ended, creative, reasoning-heavy problems. But a great deal of business-critical work isn’t open-ended. Translating a financial disclosure, checking a patent, scoring a document for quality: these are well-defined, repeatable, high-volume tasks. On work like that, a model built for the task can beat a far larger model built for everything.
The reason is specialisation. A general model’s breadth is exactly what lets it pick the wrong meaning of a word like “equity” (ownership in a company, or the value of a home above its mortgage) and quietly corrupt a disclosure. A model trained narrowly on one domain learns that field’s terminology and rules, and gets those details right more often. For scale: Straker’s models run at three to seven billion parameters against frontier systems up-to hundreds of times larger.
The interesting claim isn’t “smaller and nearly as good”; it’s that the smallness and the accuracy come from the same thing: focus.
This is not an absolute. General models still lead on some tasks, and any honest account says so. The point is narrower: on specialised, regulated work, a purpose-built model rarely loses to a generalist.
The data problem.
Here is a constraint that shapes the whole field. The largest AI labs have, in effect, started to run out of human-written text to train on. The open internet has been largely consumed, and to keep scaling, frontier labs increasingly train on synthetic data, text generated by other AI models. More and more, the newest models are learning from older models’ best guesses.
That matters most where accuracy is non-negotiable. So the harder, more useful question isn’t “how much data can we scrape?” but “how do we build the right data for this specific problem?” That is work done in partnership with the customer, capturing the terminology, conventions and corrections that live inside their own organisation, and turning that expertise into a clean, structured training set built for their domain. The resulting model has learned from the real thing, and carries the customer’s own standards rather than the internet’s average. It’s a different discipline from renting a general model: a frontier model is available this afternoon, but a dataset that genuinely encodes a customer’s domain has to be built, deliberately, with them.
The unglamorous part of proving a model is actually better.
Most people assume the hard part of model-building is training. In practice, training is the well-understood step. The genuinely difficult, and most overlooked, problems sit on either side of it.
The first is evaluation. Anyone can fine-tune a model; very few can demonstrate, objectively, that the result is better than what came before. Standard scores can be actively misleading, a higher number sometimes just means the output echoes its training data. Doing this properly means testing on data the model has never seen, kept rigorously clean of training material; ranking outputs through blind, multi-judge comparison so no single grader’s bias decides; and building domain and safety-specific checks that catch the errors generic metrics miss entirely. A guiding principle runs through it: you never let a model grade its own homework.
This is not a one and done process. A model needs to be evaluated against new datasets, continuously, over time, to ensure you’re not drifting from the trained domain or style. This is a key concept that so many in the space fail to grasp. The work is not done once your first evaluation gate is passed.
The second is production. Serving several kinds of model reliably, and metering every use accurately enough to bill and monitor, turns out to be as important as training them. You’re going to need to build custom inference frameworks, and at the same time, support the major cloud providers. Straker builds models that can run anywhere.
Most of the real engineering lives in these two layers, and both are heavily backed by continuous deep research.
What it means to know what doesn’t work.
There’s a quieter asset that rarely gets discussed: accumulated judgement. A serious model team doesn’t only produce the models that ship. It runs experiments against genuinely uncertain questions, and a large share of them end in “no”. Whole approaches are investigated properly and then deliberately set aside because the evidence didn’t support them.
That record of dead ends is not a waste. It’s a map of where not to dig, and it can’t be copied. A competitor starting today has the same questions to answer, one experiment at a time.
The data and the shipped models are part of the moat; the years of knowing what fails, and why, are the part that can’t be shortcut. It’s accumulated judgement, not just accumulated data.
Why this is difficult to assemble, and what it adds up to.
Each capability here is scarce on its own: data engineering that turns decades of messy language into clean signal; research that can specialise a model without breaking it; evaluation science that can prove the result; the infrastructure to serve and meter at scale; and the domain expertise to know what “correct” looks like in an earnings report. Holding all of them in one team, on top of a proprietary data history, is the rare thing, and not something an organisation can hire into in a quarter.
That difficulty is the point. The layer you own is the value you keep. A business that wraps someone else’s model has no defensible asset; its margins and roadmap belong to a supplier who is increasingly also a competitor.
Owning the models (and the data, evaluation and judgement behind them) is what turns AI from a recurring cost into a compounding asset.
The team publishes its work (experiments, results, and the dead ends included) in the open at Straker Labs.
If you are interested in learning more about small language models and their place in the AI ecosystem, some of the articles below are a good starting point: