The core idea: a function learned from examples
Most software is written as explicit rules: if the temperature is above a threshold, switch on the fan. A machine learning model takes a different route. Instead of writing the rules, you supply examples and let a training procedure find a rule that fits them. The result is a mathematical function that turns an input (an image, a sentence, a set of sensor readings) into an output (a label, a number, a piece of text).
That function is the model. It is not a small brain or a database of answers. It is a large collection of numbers arranged in a fixed structure, and everything it “knows” is encoded in those numbers.
Parameters: where the learning is stored
The numbers inside a model are called parameters, often also called weights. A model’s structure (its architecture) decides how inputs are combined, and the parameters decide how strongly each combination counts. Before training the parameters are typically set to small random values, so the model’s outputs are essentially noise.
Parameter count is a rough measure of a model’s size. Small models used on hobby hardware may have thousands to millions of parameters, while the large language models offered as online services are generally described as having billions or more. More parameters usually means more memory and more computation, which matters a great deal when you decide where the model will run.
Datasets: what the model learns from
Training needs a dataset: a collection of examples. In supervised learning each example comes with the answer you want, such as a photo labelled “cat” or a vibration reading labelled “bearing worn”. In other setups the model learns patterns without labels, or learns from trial and error with a reward signal. Supervised learning is the most common starting point for builders because it is easiest to reason about.
Datasets are usually split into at least two parts:
- Training set: the examples the model is allowed to learn from.
- Validation or test set: examples held back to check how the model behaves on data it has never seen.
The split exists because a model can memorise its training examples without learning anything general. The quality of the data matters as much as the quantity, a topic covered in more depth under training data and the biases it can carry.
What happens during training
Training is a loop. In rough terms:
- Feed the model some training examples and record its outputs.
- Compare those outputs with the correct answers using a loss function, which turns “how wrong was it?” into a single number.
- Work out how each parameter contributed to the error, and nudge every parameter slightly in the direction that would reduce it.
- Repeat over many passes through the data.
Each full pass through the dataset is usually called an epoch. The size of the nudge is controlled by a setting called the learning rate. Settings like this, which you choose rather than the model learning them, are called hyperparameters. Picking them is partly experiment and partly experience, and the right values vary from project to project.
Training is the expensive phase. It involves a great deal of arithmetic repeated many times, which is why it is commonly done on powerful graphics cards or rented servers rather than on small boards.
Overfitting and underfitting
Two failure modes come up constantly. An underfit model is too simple, or trained too little, to capture the pattern, so it does badly even on its training data. An overfit model has fitted the quirks and noise in the training set so closely that it does worse on new data.
The usual warning sign for overfitting is that performance on the training set keeps improving while performance on the validation set stalls or gets worse. Remedies generally include more varied data, a simpler model, or stopping training earlier. None of these guarantees success, so it is worth checking results on realistic examples from the environment where the model will actually be used.
Inference: using the trained model
Once training is finished, the parameters are fixed and saved to a file. Using that file to produce outputs for new inputs is called inference. Compared with training, inference is a single forward calculation: input goes in, the numbers are combined, an output comes out. There is no comparing with correct answers and no adjusting of parameters.
This distinction shapes project planning:
| Training | Inference | |
|---|---|---|
| Purpose | Find good parameters | Use fixed parameters on new input |
| Compute demand | Typically high | Typically much lower |
| Runs how often | Occasionally | Every time the feature is used |
| Where it often runs | Workstation or rented server | Anywhere, including small devices |
Because inference is lighter, a model trained on a powerful machine can often be run on far more modest hardware, sometimes after being shrunk. The trade-offs involved in picking that hardware are the subject of inference hardware, and the extreme end, where models run on very small chips, is covered under tiny machine learning.
Reusing existing models
Most builders do not train from scratch. Two common shortcuts are worth knowing:
- Pretrained models: someone else has already done the expensive training. You download the parameters and run inference, which is often all a project needs.
- Fine-tuning or transfer learning: you start from a pretrained model and train it a little more on your own smaller dataset so it adapts to your task. This usually needs far less data and computing than starting over, though results depend heavily on how well your data matches the job.
Pretrained models are distributed under various terms, so check software licenses and usage conditions before building them into something you share or sell. Many of the tools for loading and running models come from machine learning libraries that handle the arithmetic for you.
Measuring whether a model works
A single accuracy number can mislead. If 95 out of 100 items in your test set belong to one class, a model that always guesses that class scores 95 per cent while being useless. It helps to look at the kinds of mistakes made, not just how many, and to test on examples that resemble real use, including awkward ones.
Models also drift out of date. If the world your sensors or users produce changes, a model trained earlier may gradually perform worse, which is one reason a deployed model needs occasional checking. Weighing that ongoing effort is part of judging whether an AI feature is worth adding in the first place.
Putting it together for a project
A practical way to think about the whole lifecycle is in four stages: gather and clean data, train (or choose a pretrained model), evaluate on held-out examples, then deploy and monitor. Each stage has a different cost profile. Collecting good data is often the slowest part, training the most computationally demanding, and deployment the one you will live with longest.
If your idea only needs a standard capability, such as recognising common objects or turning speech into text, a pretrained model used for inference may be enough, and the training questions become mostly about understanding what the model was built from. If your task is unusual, expect to spend more time on data than on code.