Machine learning (ML) helps a computer find patterns in data and use them for a defined task. Instead of writing a rule for every situation, you give a learning process examples and test whether its model works on new cases. ML is useful for tasks such as filtering spam, forecasting demand, and recognizing patterns in images, but it is not a shortcut around clear goals or good data.
In this tutorial, you will follow a small delivery example from raw observations to a prediction. The numbers are illustrative rather than a model you should deploy; their purpose is to make the workflow visible before you use a library or a large dataset.
Define the question before collecting data
Suppose a delivery team wants to know which orders are likely to arrive late. “Improve deliveries” is too broad. A testable question is: “Given the route distance and whether it is rush hour, predict if this order will be late.” This defines the input, the desired output, and the moment when a prediction would be useful.
The columns used as input are called features. The answer recorded for a past example is its label. In this example, distance and rush-hour status are features; “late” or “on time” is the label.
Example: A tiny delivery dataset
| Past order | Distance | Rush hour? | Actual result |
|---|---|---|---|
| A | 2 km | No | On time |
| B | 8 km | Yes | Late |
| C | 3 km | No | On time |
| D | 9 km | No | Late |
| E | 5 km | Yes | Late |
A person might notice that longer routes and rush hour appear related to lateness. That is a hypothesis, not proof. Five examples cannot tell you whether the relationship holds across other roads, drivers, seasons, or cities.
Build a simple baseline
Before training a complex model, try a clear rule. For example: predict “late” for routes over 6 km, and “on time” otherwise. This rule gets some rows right and misses order E, which was only 5 km but happened during rush hour. A second rule could include rush hour. A useful ML model must beat a sensible baseline on representative new orders, not merely look clever on the rows used to build it.
For this dataset, always predicting the most common label—“late”—would be correct for three of five rows. That is 60% on these rows, but it tells us almost nothing about future performance. This is why the baseline and the test set matter.
Train the model
Training adjusts a model using examples. A model might learn that increasing distance changes the chance of lateness, while rush hour adds further risk. Different algorithms learn in different ways: a decision tree splits cases using conditions; a linear model combines weighted features; a neural network adjusts many parameters across layers.
The model does not learn what “late” means unless the dataset defines it consistently. If one dispatcher marks an order late after five minutes and another after fifteen, the labels conflict. Poor or biased data can teach the wrong pattern regardless of the algorithm.
Test on unseen examples
Keep some suitable examples separate while developing the model. After training, ask it to predict their labels and compare predictions with the real results. This tests how well the pattern generalizes beyond the training rows. In a real delivery system, a time-based split can be more realistic than a random split: train on earlier orders and test on later ones, so information from the future does not leak into the past.
Also look beyond overall accuracy. If only one in twenty orders is late, a model that always says “on time” scores 95% accuracy while failing at the very job you care about. Check missed late orders, false alarms, and the cost of each error. Choose a threshold that fits the decision the team will make.
Use the model for a new order
Inference means using the trained model for a new case. Suppose a new route is 7 km at rush hour. The system supplies those two features and receives a predicted class or probability. The team may use that result to warn a customer or assign extra time, but it should not treat the prediction as a guaranteed arrival time.
Inputs at inference must match the meaning and format of the training data. If training distance was measured in kilometers but the live system sends miles, predictions can fail silently. Check this kind of data contract before trusting a deployed model.
Watch for overfitting and changing conditions
Overfitting happens when a model matches training examples too closely and performs poorly on new ones. It might learn accidental details, such as a particular driver ID, rather than a useful delivery pattern. Evaluate on unseen data, compare with a simple baseline, and avoid adding complexity without evidence that it helps.
Even a good test result can age. A new route network, different weather season, or changed delivery policy can alter the data. Monitor results after release and review the model when performance drops.
Tip: Ask four questions about any ML claim: What is the label? Which features are available when the prediction is made? How was it tested on new cases? What happens when it is wrong?
Conclusion
Machine learning starts with a specific prediction task. Features describe each case, labels provide known answers, training finds a pattern, and inference applies that pattern to a new case. A baseline, an honest unseen test, and ongoing monitoring are as important as the algorithm. Learn this workflow first; then a code example or ML library will make much more sense.