Rules versus examples
Traditional software works by rules. A programmer decides in advance what should happen: if the invoice total is over a set amount, send it for approval. The computer does exactly that, every time.
Some problems resist rules. How would you write a precise rule for “this email looks like spam”? You could list suspicious phrases, but spammers change wording, and legitimate messages sometimes use the same phrases. The list would grow forever and still miss things.
Machine learning takes a different route. Instead of writing the rules, you show the system many examples of the thing you care about, such as thousands of emails marked “spam” or “not spam,” and let it work out for itself which features tend to go with each label. The result is a model: a set of learned patterns that can be applied to new cases it has not seen.
A simple mental picture
Imagine teaching a new employee to sort incoming mail by showing them a big box of past examples with the correct destination written on each. After going through enough of them, they start to notice patterns: invoices have certain layouts, complaint letters use certain wording. Eventually they can sort a new letter without being told the rule.
Machine learning is like that, except the “employee” is a mathematical system and the “noticing” is a process of adjusting many internal settings until its guesses match the labeled examples as well as possible. The system does not understand mail; it has found statistical regularities.
The basic steps
Most machine learning projects follow a similar shape.
- Collect examples. These could be past transactions, tickets, photos or messages. The collection is called training data, and its quality matters enormously.
- Label or define the goal. Sometimes people mark the correct answer for each example. Sometimes the goal is simply to find groupings or unusual cases without labels.
- Train. The system repeatedly compares its guesses with the correct answers and adjusts itself to reduce its mistakes.
- Test on new examples. A portion of the data is held back so you can see how the model performs on cases it has never encountered.
- Use and monitor. Once in use, results need ongoing checking, because the world changes.
Common types of learning
You do not need technical detail, but three broad categories show up in product descriptions.
- Supervised learning. Learning from labeled examples to predict a label or number. Sorting tickets by department and forecasting sales both fit here. It underlies much of what happens in demand forecasting.
- Unsupervised learning. Finding structure in unlabeled data, such as grouping customers with similar buying habits.
- Learning from feedback. Improving behavior based on a signal of what worked, as in some recommendation and routing systems.
Newer tools that generate text and images are also built using machine learning. How the text versions work is explained in how large language models generate text, and the contrast with forecasting tools is covered in generative versus predictive AI.
Where you meet it at work
Machine learning is quietly present in many ordinary tools:
- email filters that separate junk from real mail
- tools that read forms and sort documents, part of natural language processing and document processing
- fraud and anomaly flags in finance and threat detection systems
- recommendations in online stores
- speech-to-text features, discussed under speech recognition
- image-reading features, covered under computer vision
What can go wrong
Understanding that a model is built from examples helps explain its characteristic failures.
It reflects its data. If the examples were incomplete or skewed, the model will be too. A model trained mostly on one region’s customers may handle others poorly. If historical decisions were unfair, a model may reproduce that unfairness, the concern behind algorithmic bias.
Overfitting. A model can memorize quirks of its examples rather than learning the general pattern. It then looks excellent on the data it was trained on and disappoints on new data. This is why testing on held-back examples matters, and why a vendor’s demonstration on its own data tells you little.
Drift. Patterns change. Customer behavior shifts, products change, fraudsters adapt. A model trained on last year’s world may slowly become less accurate. Someone has to watch for it.
Errors are built in. A model gives its best guess based on patterns, not a guarantee. Even a good one will be wrong some of the time. What matters is whether the error rate is acceptable for the decision, and what happens in the cases where it fails.
It can be hard to explain. Some models make decisions in ways that even their builders cannot easily describe, which complicates accountability when something goes wrong.
When machine learning is the wrong tool
If a task has clear, stable rules, writing the rules is usually cheaper, faster and easier to audit. Approval limits, tax calculations and simple routing are examples. Learned systems earn their place where the rules are too numerous or fuzzy to write down, or where the input is messy, such as language, images or sound. The tradeoffs are discussed further in the comparison between rules-based automation and AI automation.
It also needs enough relevant examples. A small organization with only a handful of past cases may find there is too little to learn from, though some products come pre-trained on broader data and can be adapted.
Taking the next step
When evaluating a tool that claims to use machine learning, useful questions include: What was it trained on? How was it tested, and on what? How will you know if its performance drops? What happens when it is unsure? Include these among your vendor questions.
No learning system is guaranteed to be accurate, and performance varies by setting. For decisions affecting people’s health, jobs, money or legal standing, keep human review in the loop.