In May 1997 a computer beat the world chess champion. In March 2016 a computer beat one of the world’s best Go players. Both made headlines as triumphs of artificial intelligence, and both were. But the two machines had almost nothing in common. Deep Blue did not learn to play chess. AlphaGo did almost nothing but learn. The difference between those two machines is the difference between artificial intelligence and machine learning, and once you see it you will notice it everywhere.

Two words with two histories

Artificial intelligence was named in 1955, in a proposal for a summer workshop at Dartmouth College written by John McCarthy and three colleagues. Their ambition was the whole thing: machines that use language, form concepts, solve problems reserved for humans, and improve themselves. AI is the goal. It says nothing about the method.

Machine learning was named four years later by Arthur Samuel, an IBM engineer who had written a checkers program that got better by playing against itself. He defined it as giving computers the ability to learn without being explicitly programmed. Machine learning is one method. It is a way of getting to AI, or to a lot of things that nobody would call AI, by letting a program adjust itself from examples instead of following rules written by a person.

So the relationship is simple. Machine learning is a subset of artificial intelligence. Everything that learns from data to do something intelligent-looking is AI. But a great deal of AI, historically most of it, never learned anything.

flowchart TB

AI[Artificial intelligence: the goal] --> R[Rule-based systems]

AI --> ML[Machine learning: learn from examples]

R --> R1[Deep Blue, 1997]

R --> R2[Expert systems, 1970s to 80s]

R --> R3[Route planning, chess openings, tax software]

ML --> S[Supervised: labelled examples]

ML --> U[Unsupervised: find structure]

ML --> RL[Reinforcement: reward and punishment]

S --> DL[Deep learning: learned features]

DL --> D1[AlphaGo, 2016]

DL --> D2[Speech, vision, language models]

The rules era

For its first thirty years, AI mostly meant writing rules. The Logic Theorist of 1956 proved theorems by searching through logical steps. Chess programs searched millions of positions per second and scored them with evaluation functions that grandmasters helped design. Expert systems of the 1970s and 80s, such as MYCIN for diagnosing blood infections and XCON for configuring computer orders at Digital Equipment Corporation, encoded the judgement of human specialists as thousands of if-then rules. XCON reportedly saved the company tens of millions of dollars a year.

This was genuinely intelligent behaviour by any reasonable standard of the time, and none of it was learned. Deep Blue is the peak of this era. It won because it could search two hundred million positions a second and because its evaluation function had been tuned by hand over years. Show it a new game and it would have been helpless.

The rules era ran into a wall that its own practitioners named: the knowledge acquisition bottleneck. Every rule had to be extracted from a human expert and written down. Experts disagreed, could not articulate what they knew, and the rules interacted in ways nobody could predict. The systems were brittle, expensive to build, and impossible to maintain. By the late 1980s funding collapsed in what is now called the second AI winter.

The learning era

The alternative had been there since the beginning. Frank Rosenblatt’s perceptron of 1958 learned to classify simple images by adjusting weights from examples, and Samuel’s checkers program learned from self-play. But learning needed two things the rules approach did not: large amounts of data and large amounts of computation. Neither was available.

Three things changed. The backpropagation algorithm, popularised in 1986, made it practical to train networks with many layers. The internet produced data at a scale nobody had imagined. And graphics cards built for video games turned out to be ideal for the arithmetic that neural networks need. The moment usually cited as the turning point is 2012, when a deep network called AlexNet cut the error rate on the ImageNet image recognition benchmark by a margin that made the entire field switch approaches within about two years.

AlphaGo is the peak of this era so far. Go has too many positions to search the way Deep Blue searched chess, and no human could write an evaluation function for it. So AlphaGo learned one, first from thirty million positions from expert games, then from millions of games against itself. Its successor, AlphaZero, dropped the human games entirely and learned chess, Go and shogi from nothing but the rules, and beat the best rule-based chess engine in the world in a matter of hours.

Spot the difference in daily life

The distinction is not academic. It tells you how a system will fail, what it needs to work, and who is responsible when it is wrong.

Notice that the rule-based column is not the losing side. Your GPS, your tax software and your compiler are all rules, and they should be. The learned column wins only where the rules cannot be written down, which is the subject of the next article.

Where neuroscience sits in this

The brain was the inspiration for the learning side from the start. Rosenblatt was a psychologist, and the perceptron was explicitly a model of how neurons might learn. The modern neural network keeps the name and the rough idea, a network of simple units whose connections strengthen with experience, and discards nearly everything else about biology. That gap is the subject of the Neuroscience meets AI track on this site: what the brain does that our learners do not, and which of those differences matter.

It also cuts the other way. Neuroscience today uses both columns of the table above. A threshold detector is a rule. A spike sorter is a learner. A decoder that turns motor cortex activity into cursor movement is a learner, but the safety limits around it are rules. Knowing which is which is part of being able to build and trust these systems.

Further reading: Nils Nilsson, The Quest for Artificial Intelligence, is the standard history and is free online. Arthur Samuel’s 1959 paper on checkers is short and still readable.

In 1954 a team from IBM and Georgetown University demonstrated a computer translating Russian sentences into English. It handled about sixty sentences using six grammar rules and a vocabulary of 250 words. The press reported that machine translation would be solved within five years. Twelve years later a government committee, the ALPAC report of 1966, concluded that after all that funding, machine translation was slower, worse and more expensive than a human, and recommended the money stop. It did, for two decades.

The problem was not effort or talent. It was that the researchers had picked the wrong kind of solution for the problem. Translation looked like a rules problem. It is not one. Knowing the difference is one of the most useful judgements a programmer can make, and it is the subject of this article.

The one question

Before anything else, ask: could a competent person write down the rules? Not in principle, in practice, on paper, completely enough that a program following them would be correct.

If yes, write the program. Sorting a list, computing payroll, validating a form, routing a packet, rendering a web page: these are rules problems, and every one of them has a correct, testable, explainable solution that a person wrote. Using machine learning here is not just unnecessary. It replaces a correct program with an approximate one, and hides the logic where nobody can inspect it.

If no, ask why not. There are three common reasons, and only some of them point to machine learning.

flowchart TD

Q1{Can a person write the rules down completely?} -- yes --> P[Write a regular program]

Q1 -- no --> Q2{Why not?}

Q2 -- The answer is a search or optimisation --> S[Use an algorithm: search, dynamic programming, solvers]

Q2 -- Humans do it but cannot say how --> Q3{Do you have many examples with the right answers?}

Q2 -- The pattern keeps changing --> Q3

Q3 -- no --> G[Get data first, or use rules as a stopgap]

Q3 -- yes --> Q4{Is an occasional wrong answer acceptable?}

Q4 -- no --> H[Rules or human review around any model]

Q4 -- yes --> ML[Machine learning is the right tool]

Reason 1: the rules exist, but the answer is a search

Finding the fastest route across a city, scheduling flights, packing a truck, playing chess. Nobody can write down the answer, but the rules of the problem are perfectly clear. These are algorithm problems, and computer science has spent seventy years on them: shortest-path search, dynamic programming, constraint solvers, linear programming. They give exact or provably near-optimal answers, and they do not need training data. Reaching for machine learning here is a common and expensive mistake.

Reason 2: humans do it easily but cannot say how

Recognising a face. Understanding a spoken sentence. Telling a cat from a dog. Reading a handwritten postal code. Deciding whether an email is spam. You do these effortlessly, and if asked to write down the rules you would fail, as decades of researchers did before you. This is the home territory of machine learning: the knowledge exists, in human judgement, and can be captured as examples even though it cannot be captured as rules.

Translation is here. The rules approach failed for forty years. In the early 1990s an IBM group tried something that sounded like giving up: instead of grammar, feed the computer millions of sentence pairs from the Canadian parliament, which publishes everything in English and French, and let it learn which words and phrases tend to correspond. It worked better than the rule systems almost immediately. Frederick Jelinek, who led IBM’s speech group, is remembered for the remark that every time he fired a linguist, the recogniser improved. Modern translation is the descendant of that decision.

Reason 3: the rules keep changing

Spam filters are the clean example. In the late 1990s, filters were lists of forbidden words. Spammers responded with misspellings and images within weeks, and every update to the rules was answered by an update to the spam. In 2002 Paul Graham published a short essay proposing a filter that learned from each user’s own mail, and within a few years every major email provider used a learned filter. The point was not that the learned filter was cleverer. It was that it could be retrained overnight, while the rule-writers could not keep up. Fraud detection, recommendation, and ad targeting are the same shape: the target moves, so the program has to move with it.

Two more questions before you commit

Do you have the examples?

Machine learning is a way of turning examples into a program. No examples, no program. The examples must be numerous, must include the correct answer, and must look like the cases the system will meet in use. A model trained on hospital scans from one machine can fail on scans from another. A model trained on last year’s customers can fail on this year’s. If you cannot get the data, you are not ready, and a rule-based stopgap that collects data while it runs is often the right first version.

Can you afford to be wrong sometimes?

A learned system is approximate by construction. It will be wrong on some fraction of inputs, and it will not tell you which. Where a wrong answer costs a little and can be corrected, as in a recommendation or a spam folder, that is fine. Where a wrong answer is expensive or irreversible, the model needs rules around it: hard limits, human review, or a fallback. A brain-computer interface that moves a wheelchair is a learned decoder wrapped in rule-based safety limits, and it should be.

Real problems, sorted

A test you can run on your own problem

Try to write the program. Spend an hour, or a day, writing the rules as if you had to. One of three things happens:

1. You finish, and you have a program. It is probably better than any model would have been.
2. You realise the rules are clear but the answer is a search or an optimisation. Look for the algorithm before you look for the model.
3. You keep adding exceptions, the exceptions need exceptions, and you can feel the rules turning to mush. That feeling is the signal. If you have examples, and being wrong sometimes is acceptable, this is a machine learning problem.

The researchers of 1954 never ran this test, because it was not yet possible to fail it honestly. You can. It takes an afternoon and it can save a year.

Further reading: the ALPAC report of 1966 is short and surprisingly readable. Paul Graham’s essay A Plan for Spam (2002) is the best single account of why learning beat rules for a moving target.