You will be able to explain when hand-written rules work well and when learning from examples beats them.
When you file your income tax, the system works out what you owe from a table. Each slice of your income is taxed at a set rate, the slices are published by IRAS, and two people with the same income and the same reliefs get the same bill. Nobody wants a tax computer with a feel for the job. They want one that follows the rules exactly, every time.
Now think about the spam folder in your work email. Nobody could write down the rules for that one. Spam changes every few weeks, and the people sending it study the filters and work around them. This lesson is about why those two jobs are built so differently, and why the second kind is where machine learning took over.
A rule-based system is a set of instructions a person writes in advance: if this happens, do that. It works well when two things are true. The task stays the same over time, and you can describe every case in full.
Income tax brackets pass both tests. So does checking whether a leave application asks for more days than the employee has left, or whether a claim is over the limit in the company's expense policy. The logic can be long, but it is complete. A person can read it, test it and explain any answer it gives.
That is the great strength of rules. When a payroll system deducts the wrong amount, someone can trace exactly which line caused it and fix that line. Nothing about the fix is a guess.
Rules struggle when the pattern is fuzzy, or when it keeps moving.
Spam is fuzzy and moving at once. You might start with a rule like "block any email that says you have won a prize". Spammers change the wording to "you have been selected". You add that. They switch to images instead of text, or misspell words on purpose. After a year you have hundreds of rules, some of them catching real emails from your bank, and you are still a step behind.
Card fraud works the same way. A rule such as "flag any card used in two countries within an hour" catches some fraud and annoys every traveller passing through Changi. Fraudsters learn the rule and keep their transactions inside it.
Handwriting is fuzzy without moving at all. Try writing rules for reading a handwritten 7. Some people cross it, some do not, and some slant it until it looks like a 1. You know a 7 when you see one, but you cannot write down how you know. Plenty of everyday skills are like this: we can do them, but we cannot list the steps.
For tasks like these, machine learning takes a different route. Instead of writing the rules, you collect many examples with the right answer attached, such as thousands of emails already marked spam or not spam, and let the system find the pattern itself. Module 2 shows how that finding works.
The practical gain shows up when things change. With rules, every new trick means a person has to spot the gap, write a new rule and check it does not break the old ones. With a learned system, you gather fresh examples of the new trick, label them and train the system again. It adjusts its own pattern to fit.
Picture a bank's fraud team facing a new scam. Under rules, that means meetings, a change request and weeks of testing. Under learning, it means collecting recent cases marked fraud and retraining. That still costs money and still needs people who know what they are doing, but it keeps up in a way a pile of thousands of hand-written rules cannot.
Here is the trade, and the rest of this course keeps coming back to it. Rules give you control. You know what the system will do, and you can explain any decision it makes. A learned system gives you flexibility, and by default you lose both of those things.
You cannot always predict what a learned system will do with a case it has never seen. When it makes a decision, there may be no line you can point to, because its pattern lives in a large set of numbers rather than in sentences anyone wrote. Builders can add tools that help explain its choices, but that takes extra work.
This is why many real systems mix the two. A bank may use a learned model to score how suspicious a payment looks, then apply fixed rules on top of the score: anything above a set level goes to a person, and some kinds of transfer are always held. The learned part handles the fuzzy pattern, and the rules keep the parts that must be predictable.
So the useful question about any task is whether it is stable and fully describable, or fuzzy and shifting. Your own job almost certainly has both. Approving a claim against a fixed policy table sits on one side. Spotting which customer emails are complaints written politely sits on the other. Sorting a couple of your own tasks this way is the next step, and it is a habit you will use again when you build your capability map in module 8.
Pick two tasks from your job and write a short note on whether each would be better handled by fixed rules or by a system that learns from examples, and why.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).