When You Don't Need Machine Learning

A lot of money gets spent training models to answer questions that a well-written query would have answered in an afternoon. Less often, but expensively, businesses grind away at a problem by hand for years when the pattern was learnable all along.

Here is how to tell the two apart before committing to either.

The Question That Decides It

Does your problem contain a pattern that is too complex for a person to write down as rules, but present enough in your history for an algorithm to learn?

Both halves matter. Too-complex-to-specify without enough data gives you a model that has memorized noise. Plenty of data with a pattern you could have written down in an afternoon gives you an expensive, opaque version of an IF statement.

Where Plain Analysis Wins

Reach for SQL, a spreadsheet, or a straightforward statistical model when:

• The rules are already known and stable — revenue is units times price, and no model is going to improve on that
• You need to explain exactly why you got the number, to an auditor, a regulator, or a skeptical board member
• You have limited history. A few hundred rows will not support learning, whatever the vendor says
• The question is about what happened or why, rather than what happens next
• Getting an answer this week matters more than squeezing out the last few points of accuracy

Plain analysis is faster to build, easier to defend, and it fails loudly rather than quietly. A query that breaks returns an error. A model that has drifted returns a confident number that is wrong, and keeps doing it until someone checks.

Where a Model Earns Its Complexity

Machine learning is worth the overhead when:

• The pattern space is genuinely too large for rules. Fraud, document classification, anything where the useful signal is a combination of many weak indicators rather than a few strong ones
• The relationship shifts and has to adapt. Demand under volatile conditions, where last year's rules stopped applying in March
• It has to work per-item at scale. You cannot hand-write logic for a hundred thousand customers
• You have the history to support it. Enough volume, covering enough varied conditions, collected consistently enough to be comparable across time

That last condition is the one that most often fails, and it fails silently. Data that looks like five years of history is frequently two years of usable history plus three years collected under different definitions.

The Third Thing

Large language models do not fit neatly into either category, and pretending otherwise leads to bad decisions in both directions.

They are not predictive models trained on your data for a specific task, and they are not deterministic analysis. They are good at reading, summarizing, drafting, extracting structure from text, and answering loosely-phrased questions against material you give them. They are unreliable at arithmetic over large tables, and at any answer that must be exactly right every time without being checked.

Used where they fit, they remove a lot of tedious work. Pointed at a job that needed a deterministic calculation, they produce plausible answers that are occasionally wrong in ways that are hard to spot, which is the worst failure mode available.

The Honest Default

Most business questions are answered by getting the data clean and asking it clearly. That is unglamorous, and it is what the majority of useful work turns out to be.

The reason to be strict about this is not purity. It is that every model is a thing somebody has to maintain, monitor, and eventually explain. A model nobody maintains degrades into a number nobody should trust but everybody still uses. If the simpler approach answers the question, it is not a compromise — it is the one still working in three years.

Build the model when the problem actually requires it. Then it is worth the maintenance, and you will be able to say why.