Classical ML Still Ships

I already made the case for starting simple in Less Is More. This post picks up where that one left off. The question people should be asking isn’t which model scores highest on a benchmark. It’s what the model costs you for the next five years, and almost nobody prices that in before they train and ship a model.

Total cost of ownership is the number that matters to a client, and it’s made of four things: what hardware the model needs to run on, how often it needs retraining, how easily an engineer can debug it at 2 a.m., and whether the team maintaining it in year three can actually reason about how it works. A transformer that wins on accuracy in a paper can still be the wrong choice once you add up what it costs to keep alive.

The hardware bill never stops

An SVM runs on a microcontroller. A gradient-boosted tree runs on whatever CPU happens to be sitting in the enclosure already. A modern vision transformer wants a GPU, and it wants that GPU available at inference time, not just during training. For an inspection system running at the edge, on a device whose power budget and network connection you may not control, that decides the budget. It’s the difference between a commodity single-board computer and an embedded GPU carrier costing many times more, multiplied by every unit you deploy.

Worse, that cost doesn’t show up in a proof-of-concept. It shows up eighteen months later when the client wants to deploy the system to twenty more sites and the hardware line item triples the project budget. I’ve seen teams pick an architecture based on what ran well on a workstation with a 4090 in it, then discover the field hardware has none of that headroom. The model was never wrong. The deployment target was never part of the decision.

This is where Mask R-CNN-era architectures, and classical approaches more broadly, keep earning their keep. They were designed in an era that assumed less compute, and that constraint turns out to still be relevant, because most production environments have less compute than a research lab.

Retraining cadence is a cost center

Every model has a shelf life. Sensor drift, new part revisions, lighting changes, or upstream data pipeline changes will eventually invalidate your training distribution, and the model needs to be retrained. The question is what that retraining costs you, in engineer time and in calendar time, and how often you have to pay it.

A large deep learning model needs a real training run: curated data, a GPU or cloud training job, a validation pass, and someone who understands the architecture well enough to know if the retrain actually improved things or just moved the failure modes around. That’s a project, and it recurs.

An SVM retrains in the time it takes to run a script on a laptop. The feature set is small and interpretable, so when performance drifts, you can usually tell why by looking at a handful of engineered features rather than re-deriving what a million-parameter network learned to key on. That difference compounds. If a client’s environment changes twice a year, you want a retraining loop that costs an afternoon.

Debuggability is the real differentiator

This argument doesn’t get made often enough: a support vector machine is debuggable in a way a deep network is not. When an SVM misclassifies something, you can inspect the support vectors, look at the decision boundary, and reason about which features drove the call. When a CNN misclassifies something, you’re looking at activation maps and hoping they tell you a story. Sometimes they do. Often they don’t, and you end up retraining and hoping the next version is better without ever knowing exactly why the first one failed.

For a one-person studio, or for any team that has to maintain a system without a dedicated ML ops function standing behind it, that’s a practical matter: it’s the difference between fixing a bug in an afternoon and re-running an entire experiment pipeline to see if the fix helped. Team familiarity matters here too: an engineer who understands kernels and margins can debug an SVM cold. An engineer inheriting someone else’s fine-tuned transformer is starting from much further behind, and production systems get inherited constantly, by future me, by a client’s internal team, or by whoever’s on call.

None of this means classical methods win everywhere. Segmentation problems with high intra-class variation, unstructured scenes, or tasks where the signal isn’t linearly separable in any reasonable feature space are still where deep learning is the right tool, and no amount of feature engineering will get an SVM there. If the failure mode of getting it wrong is severe enough (safety-critical detection, for instance), the accuracy ceiling of a heavier model can be worth the TCO premium outright. I still reach for Mask R-CNN-class architectures for exactly that reason, as I said in my earlier post. Simpler doesn’t always win. But the case against it has to be made on the numbers that recur: hardware, retraining, debugging, and who’s left to maintain it. A leaderboard score isn’t one of them.

That’s the conversation I have with every client before we pick an architecture, and it’s the same conversation behind the AI integration work I do: model choice is a five-year commitment dressed up as a one-time decision. Price it like one.