Classic ML, Deep Learning or an LLM: How We Choose
Last updated:
Start with the data, not the fashion
Clients sometimes arrive having already decided the answer. Someone has read that large language models can do anything, so the churn prediction should use one. Or a previous supplier proposed a neural network for a problem that fits comfortably in a spreadsheet. We understand why. But the technique should follow from the data and the decision, and on most business problems that points somewhere less fashionable.
Our default is the simplest approach that clears the success threshold. Simpler models are cheaper to run, faster to retrain and much easier to explain to the people who have to trust them. We move to something heavier only when the evidence says the simpler one is not good enough.
The quick answer by data type
| Your data looks like | Where we usually start | Why |
|---|---|---|
| Rows and columns: orders, customers, transactions | Gradient boosting (XGBoost, LightGBM) or a linear baseline | Strong accuracy on tabular data, fast, explainable |
| Time series: sales, demand, sensor readings | Classical forecasting and boosted models with time features | Handles seasonality well; deep models rarely justify the extra cost at SME scale |
| Images or video | A pre-trained deep learning model adapted to your images | Learns visual patterns no hand-written feature could |
| Free text: emails, tickets, documents | An LLM or a smaller language model, sometimes a fine-tuned classifier | Understands language without thousands of labelled examples |
| A mixture of text and numbers | A hybrid: language model extracts, classical model predicts | Each part does what it is good at |
Why tabular problems nearly always start with classic ML
Most business machine learning is tabular. Predicting late payment, churn, demand, fraud or lead conversion all come down to rows of customers or transactions with columns of attributes. On this kind of data, gradient boosting remains extremely hard to beat, and it has practical advantages that matter more than a small difference in a score.
- It trains in minutes on ordinary hardware, so retraining is cheap and routine
- It works with thousands of examples rather than needing millions
- It can show which factors drove each prediction, which people need before they trust it
- It runs in milliseconds without a GPU, which keeps hosting costs small
We have seen deep learning proposed for tabular problems many times. It occasionally wins by a small margin, and almost always costs more to build, run and explain. Unless that margin is worth real money, we do not take the trade.
When deep learning earns its cost
Deep learning is the right tool when the useful patterns cannot be described as columns: defects on a product photo, a damaged parcel in a warehouse image, an anomaly in a vibration signal. Here, we rarely train from scratch. A pre-trained model adapted to a few hundred or few thousand of your labelled examples is usually faster and more accurate.
The costs are different in kind. Labelling images takes human time, training needs GPU compute, and explaining a prediction is harder. We budget for all three in the proposal rather than discovering them in week five, and we keep an eye on smaller models that can run on-device or at the edge when images cannot leave a site.
Where large language models fit, and where they do not
LLMs are excellent at reading and classifying language: routing an email, extracting fields from a contract, summarising a call. For those tasks they often replace what would once have needed a large labelled dataset and a custom text model. We cover how we pick between providers in how we choose the right AI model.
They are poor at numeric prediction from structured data, and poor at arithmetic generally. Asking a language model to forecast next month's demand from a table is asking the wrong tool, and it will produce a confident number with no basis. For that, a classical model is cheaper, more accurate and repeatable.
The best systems we build often use both: a language model to turn messy text into structured fields, and a classical model to make the prediction from those fields.
The other questions that can overrule the default
- Does the decision need explaining? Credit, hiring or anything affecting individuals pushes firmly towards explainable models, and the EU AI Act obligations phasing in make that more than a preference for some uses.
- Can the data leave your environment? If not, a self-hosted smaller model may beat a more capable hosted one.
- How fast must the answer arrive? A real-time checkout decision rules out anything slow or expensive per call.
- How often will it retrain? Weekly retraining favours models that train in minutes.
- Who will maintain it? If your own team will own it later, we choose tools they can realistically support.
How we test the choice rather than argue about it
When the right approach is genuinely unclear, we do not settle it in a meeting. During the proof of value we run the simple baseline and one or two candidate approaches against the same evaluation set and the same agreed threshold. The numbers, the running cost and the explainability are then compared side by side in the report.
That approach has changed our own minds more than once, in both directions. Occasionally the heavier model earns its place; more often the gap is small and the simpler one wins on everything else. Either way you see the evidence. If you want the wider comparison of models against fixed logic, when a rule beats a model is worth reading, and our machine learning service shows the stack we build with.
Frequently asked questions
Is deep learning more accurate than classic machine learning?
Can we use ChatGPT-style models for prediction?
Do you fine-tune language models?
What if our team wants a specific framework?
Not sure which kind of model your problem needs?
Describe the decision and show us a few rows of the data. We will tell you which approach we would start with, and why the simpler one might be enough.