What a Machine Learning Model Actually Is, and What It Is Not
Last updated:
Strip away the vocabulary
People talk about models as if they were colleagues. The model decided. The model thinks this customer is risky. It is a helpful shorthand and a misleading one, because it hides what you are actually buying, maintaining and relying on.
Physically, a trained model is a file. Sometimes a few kilobytes, sometimes many gigabytes. Inside it are numbers, learned during training, that describe how to turn a set of inputs into an output. Paired with a bit of code, that file becomes a function: give it the details of an invoice, it returns a probability of late payment. That is the whole object.
A recipe analogy that mostly holds
Think of a model as a recipe somebody worked out by tasting thousands of dishes and noting which ingredient amounts produced food people liked. The recipe card is the model. The tasting was the training. Cooking tonight's meal from the card is making a prediction.
The analogy holds in three useful ways. The card does not change unless someone rewrites it. It only knows about ingredients that appeared in the dishes tasted. And if tastes change, the card keeps producing yesterday's favourite.
It breaks in one important way: a real recipe is readable. Many models are not, at least not directly. A simple model might be understandable as 'late payment risk rises with the number of past late payments and falls with account age'. A large neural network is millions of numbers that no person can read, which is why explaining its decisions needs extra tools.
What a model is not
- It is not a database. It does not store your customers or look them up. It stores patterns, which is why it can handle a customer it has never seen.
- It is not self-updating. Unless someone has built a retraining process, the model you deploy in March is the same model in November.
- It is not reasoning. It maps inputs to outputs based on association. It has no idea why late payers are late.
- It is not neutral. It reflects every quirk and bias in the historical decisions it learned from.
- It is not the product. On its own, a model file does nothing for your staff. The value arrives when predictions reach a screen, a workflow or an automated decision.
The parts you are really paying for
When a supplier quotes for 'a model', the useful deliverable is a small system. Knowing its parts helps you compare quotes and spot what is missing.
| Part | What it does | What happens if it is missing |
|---|---|---|
| Data pipeline | Gathers and cleans the inputs from your systems | Predictions on stale or broken data |
| Feature code | Turns raw records into the inputs the model expects | Training and live inputs quietly disagree |
| Trained model file | The learned patterns | Nothing, this is the part everyone remembers |
| Serving layer | Answers requests, often via an API | The model sits on a laptop |
| Integration | Puts predictions in front of people or processes | Nobody uses it |
| Monitoring | Tracks accuracy and input drift over time | It degrades silently |
| Retraining process | Rebuilds the model on newer data | It goes stale within months |
In our experience the model file is perhaps a fifth of the work. The rest is ordinary, careful software engineering, which is why a custom software mindset matters as much as data science on these projects.
Why models go stale
A model is a photograph of the past. The patterns it captured were true in the period its training data covers. When the business changes, the photograph stops matching the view.
A courier firm's delivery time model trained before it opened a second depot will mis-predict every route through the new site. A lead scoring model trained before a price increase will keep favouring leads that no longer convert. None of this produces an error message. The predictions simply become quietly worse.
Models do not break loudly. They drift, and the first sign is usually a manager saying the scores do not feel right any more.
That is why monitoring and a retraining schedule belong in the original budget. Our post on keeping AI accurate over time covers what to measure.
Who owns it, and can you take it with you
Ownership is worth settling in the contract, because there are three separate things to own: the trained model file, the code that built it, and the data it learned from. Owning the file without the training code means you cannot retrain without starting over. Owning the code without the data preparation steps is almost as bad.
Our default at SpiderHunts is that the client owns all three and the whole thing lives in the client's own cloud account or repository. Models trained on a vendor platform you cannot export from are a form of lock-in worth pricing in before you sign.
Questions to ask about any model you are offered
- What exactly goes in, and where does each input come from at prediction time
- What comes out, and is it a probability, a label or a number with a range
- How was accuracy measured, and on data from which period
- What simple baseline did it beat, and by how much
- How will we know when it gets worse
- Who retrains it, how often, and what does that cost
A supplier who answers all six clearly is worth talking to. One who talks mainly about algorithms is selling the fifth of the work you least need to worry about.
Frequently asked questions
Is a machine learning model the same as an algorithm?
Does a model keep learning once it is deployed?
How big is a typical business machine learning model?
Can we see inside a model to check its decisions?
Being quoted for a model and unsure what you would get?
Send us the proposal. We will explain in plain terms what the deliverable is, what running it involves and what it will cost to keep accurate.