Machine Learning Explained with a Matatu Route

McTaba runs coding and data bootcamps in Kenya. This guide is written to be useful whether or not you ever join one.

It is 5 PM at the Thika Road stage. A conductor tells you, "Forty minutes to town." It is raining. He is wrong, and you both know it. On a dry Sunday morning the same trip takes twenty.

That conductor is already doing prediction. He has seen hundreds of trips and carries a rough rule in his head: later hours, weekdays and rain make the trip slower. Machine learning is a way to write that rule down from data, instead of keeping it in one person's memory.

Everything below uses made-up numbers. They show the method. They are not real travel times. If you are choosing a career, the data science career guide for Kenya shows where this skill leads.

Every machine learning problem has two parts. The label is the thing you want to predict. The features are the facts you give the model to predict it.

For example, imagine you ride the same route for a month and note each trip. Your label is the minutes taken. Your features are the hour of departure, the day of the week and whether it was raining. Three small features, one label.

Imagine the first rows of your notebook look like this. These numbers are invented for the example.

Hour	Day	Rain	Minutes (label)
7	Monday	No	45
7	Monday	Yes	62
13	Wednesday	No	25
17	Friday	Yes	75
10	Sunday	No	20

Real work would use hundreds or thousands of rows. Choosing good features is half the job. If you forget to record "schoolchildren on holiday", the model cannot learn from it.

If you want to practise this kind of table-building on real Kenyan data, our Data Science programme in Nairobi starts from Python and pandas and works up to models like this one.

Training means letting the program look at the rows and adjust itself until its guesses come close to the real minutes. The simplest model draws a line: each extra hour toward the evening adds some minutes, and rain adds some more.

Imagine you have 200 trips. You train on 160 and hide 40. The hidden 40 are your test set. The model never sees their minutes while learning. This is like a student who practises on past papers and then sits a paper she has not seen.

Without the hidden set you would fool yourself. A model can memorise its training rows, scoring perfectly on trips it has already seen, and still fail the first morning it meets a new one.

In code, this takes about six lines with a library called scikit-learn. You do not need to follow the code to follow the idea: split the data, fit a model on the larger part, check it on the smaller part. A gentle start on the tools is in the Python for data science guide.

Now ask the model to predict the 40 hidden trips and compare with what happened. For example, imagine it said 50 minutes for a Tuesday 8 AM trip that actually took 58. The error is 8 minutes.

Average the size of those errors across all 40 trips. If the average is, say, 9 minutes, you can tell a passenger, "My prediction is usually within about 9 minutes." That sentence is honest and useful. The model need not be perfect to beat the conductor's guess.

Always compare with a dumb baseline. The baseline might be "always say the overall average trip". If your model's error is not clearly below that, the model has learned nothing.

Look at where the errors cluster. Perhaps the model is badly wrong on the day a matatu strike blocks the road, because no feature tells it about strikes. That is not a failure of mathematics. It is a missing feature, and it shows you what to collect next.

Roads change. A new bypass opens, a stage moves, a fare war empties the route. A model trained in March describes March. By November it may be off by twice as much.

So you keep a simple routine. Each week, record new trips. Each month, check the model's error on the latest trips. When error creeps up, retrain on fresh data, including recent months, and test again. Teams call this monitoring, and it matters as much as the first model.

This loop (collect, train, test, watch, retrain) is the same whether the model predicts a trip time, a fraud alert on M-Pesa or a customer's chance of repaying a loan. The data and the cost of a wrong guess change. The loop does not.

To see how the same idea applies to money, read mobile money fraud detection with machine learning. To see how the parent field fits together, read AI vs machine learning vs data science.

Try it with paper first. Write 20 of your own trips in a notebook with hour, day, weather and minutes. Guess the next five trips from your own table, then compare. You have just done the whole loop by hand.

When you are ready for the real thing, you need Python, a little statistics and projects with Kenyan data. A first project can be as simple as this one. Our Data Science programme in Nairobi teaches the Machine Learning phase after the data handling and statistics that come before it, then ships a model behind an API or dashboard.

If statistics worries you, statistics for data science explains what you actually need.