Machine Learning — from pattern hunter to job-ready creator
A Koinder Global Limited production
First understand why machine learning had to exist. Then touch the ideas, break them, fix them, code them, and finally ship something that works.
Module 4 · Practitioner Track · 18+ · Creator LabSEE → GUESS → WHY → DISCOVER → TOUCH → BREAK → FIX → CODE → BUILD → EXPLAIN → SHIP
Do not rush to algorithms. A working practitioner first learns to recognise a problem, frame it, question the data, measure failure, and explain what the model is doing.
Before Python. Before models. Before formulas. Start with the problem humans were trying to solve.
Yesterday your bank received 10 loan applications. Tomorrow it expects 2,000,000. For every applicant you must decide: LIKELY TO REPAY or LIKELY TO DEFAULT.
You have only seconds per application. What would you do?
If a rule is clear, stable and easy to write, ordinary programming may be the better tool.
Classify each message. Then Kodi will challenge the rule you think you used.
Kodi: “Beautiful. But I simplified it. That shape mainly describes supervised learning. What happens when nobody has supplied the answers?”
History is useful when it explains why the next idea appeared.
Pharaoh, the king of Egypt, woke up frightened. He had seen seven healthy cows followed by seven thin cows, and the thin cows ate the healthy ones.
Joseph interpreted the pattern as seven years of plenty followed by seven years of famine. Egypt acted on the prediction and stored grain.
This is not a biological brain. It is a mathematical toy that receives signals, combines them and decides whether a threshold has been reached.
Kodi can choose A, B or C. Each action gives a different reward. Run experience repeatedly and watch which action becomes attractive.
Professionals are paid to solve the problem, not to put AI everywhere.
Before training anything, ask:
Is there a decision or prediction that matters?
Do we have enough relevant examples or signals?
Would a simple rule, query or formula solve it more reliably?
What happens when the model is wrong?
Your job is not to immediately choose Random Forest. Translate the complaint into something measurable.
Fill this before modelling. This is the thinking companies actually need.
Examples: default/repaid, spam/not spam, house prices, disease labels.
Question: learn a relationship that predicts an outcome.
Examples: customer groups, strange transactions, product relationships.
Question: what structure is hiding in the data?
Examples: game playing, control systems, simulated robotics.
Question: which actions lead to better long-term outcomes?
| Field | Value | Role |
|---|---|---|
| Age | 32 | Feature |
| Monthly income | ₦420,000 | Feature |
| Existing debt | ₦70,000 | Feature |
| Employment years | 6 | Feature |
| Previous late payments | 0 | Feature |
| Defaulted? | No | Target |
A loan-default model uses the following fields. Click anything that would not legitimately be known at prediction time.
There is no universal percentage split for an ML project. But real practitioners often spend substantial time acquiring, cleaning, understanding and shaping data, evaluating failures, deploying systems and monitoring them. Model training may be the short part.
Click suspicious cells. Find as many data-quality problems as you can before training anything.
| Customer | State | Sales | Date |
|---|---|---|---|
| Amaka | Lagos | ₦5,000 | 12/4/26 |
| AMAKA | lagos | 5000 | 12-04-2026 |
| Emeka | LAG | N/A | April 12 |
| John | Abuja | ₦-900 | 14/04/26 |
| ABUJA | 7,300 | ||
| Tunde | abj | seven thousand | |
| Tunde | Abuja | 7000 | 14/04/26 |
Feature engineering turns raw records into useful signals aligned with the prediction moment.
Customer 77 has these transactions:
| Date | Amount |
|---|---|
| 2026-01-02 | ₦4,300 |
| 2026-01-18 | ₦12,000 |
| 2026-02-01 | ₦2,500 |
| 2026-04-09 | ₦7,600 |
If you let the model see the final examination during training, the score no longer tells you how well it handles new data.
If 81% of customers stay, a model that predicts STAY for everyone already gets 81% accuracy. Your expensive model should prove it adds useful value beyond that.
Suppose only 1 transaction in 1,000 is fraud. A system that calls every transaction “legitimate” can be 99.9% accurate while catching zero fraud.
That is why practitioners choose metrics based on the consequences of mistakes.
Now the learner is ready to meet models — as tools chosen for reasons, not names to memorise.
Why: predict a numerical quantity with a simple relationship.
Watch: outliers, nonlinearity, assumptions.
Why: estimate probability of categories such as default/no default.
Watch: feature scale, linear decision shape.
Why: learn understandable branching decisions.
Watch: deep trees overfit easily.
Why: many varied trees vote, often improving robustness.
Watch: heavier models, less direct interpretability.
Why: sequential models focus on correcting earlier mistakes.
Watch: tuning, leakage, overfitting.
Why: predict using similar nearby examples.
Watch: scaling and slow prediction on large datasets.
Why: simple probabilistic evidence, often useful for text.
Watch: independence assumptions.
Why: discover groups when labels do not exist.
Watch: scale, number of clusters, interpretation.
Why: learn layered representations for complex patterns.
Watch: data needs, compute, tuning, interpretability.
Drag the slider. Your line tries to separate blue examples from orange examples.
Ask 12 small decision trees to vote on the same customer.
No one labelled these customers. Choose how many groups you want Kodi to look for, then inspect the resulting descriptions.
Your cleaning robot receives points. Change the reward design and see whether it creates the behaviour you intended.
A model can learn patterns from past decisions, including undesirable patterns. “The computer learned it” does not automatically make the output acceptable.
Practitioners inspect how errors and outcomes differ across relevant populations, review whether features are legitimate, and ensure humans understand the risks of automated decisions.
A demand model can be perfectly implemented and still deteriorate if prices, regulations, consumer behaviour, seasons or economic conditions change. The model is a claim that patterns in past data remain useful in the current world.
model.fit() is a milestone. It is not the end of the system.
Chase a missing export from another department.
Discover three date formats and decide how to standardise them.
Explain that a requested feature requires data nobody currently collects.
Explain why “99% accuracy” may be bad news.
Check whether last month's model still works on this month's world.
Occasionally train another model.
Which exact code created this result?
Which data snapshot trained this model?
Which parameters, metrics and model version won?
How does another application request predictions?
How do we make the environment reproducible?
Is input data, latency or model quality changing?
When do we teach the model from newer reality?
What if the new model is worse in production?
Later: PyTorch, TensorFlow/Keras where appropriate, XGBoost/LightGBM/CatBoost, experiment tracking and model monitoring.
The idea stays the same while one detail changes. This forces flexible understanding rather than memorising a sentence.
Classification, text features, precision, recall.
Regression, cleaning, missing values, MAE/RMSE.
Images, labels, validation, imbalance.
Clustering, business interpretation.
Imbalance, thresholds, business cost.
SQL, features, classification, API, monitoring.
Time, seasonality, distribution shift.
Similarity and ranking.
Text classification, embeddings, modern NLP.
Data → pipeline → model → API → app → monitoring.
Modern AI becomes much less mysterious when the learner can see how today's systems grew from older ideas.
KoMart gives you 150,000 transactions. Customer IDs are missing in places. Product names disagree. There are duplicates, refunds, strange dates, promotions and customers with only one purchase.
Mission: identify customers at risk of disappearing so the retention team can act before they leave.
The learner should be able to say:
I can frame an ML problem. I can tell when not to use ML. I can clean messy data. I can create features. I can detect obvious leakage. I understand imbalance. I can compare models. I can choose meaningful metrics. I can deploy a prediction service. I can monitor it. I can explain what I built and what could make it fail.