Understand artificial intelligence, from the ground up.
No maths background needed. We start every idea with a story and a picture — the equations only show up once you already feel why they're true.
What Are We Actually Trying to Build?
Before a single line of code: what does it even mean for a machine to be 'intelligent', and why that question has a surprisingly slippery answer.
In 1950, a British mathematician named Alan Turing sat down to answer a question that sounds like it belongs in a pub argument: can machines think? He quickly realised the question was a trap. Nobody could agree on what 'think' means. So he did something clever — he replaced the impossible question with a practical one: if you were chatting through a screen with a hidden partner, and you genuinely couldn't tell whether it was a human or a machine, would it matter which it was?
That move — stop arguing about the essence of intelligence, start measuring what a system can actually do — is the seed of everything in this course.
Let's begin with the most honest definition we can give. Artificial Intelligence is the project of building machines that perform tasks we'd normally say require human intelligence — recognising a face, understanding a sentence, making a decision, writing an essay. Notice what that definition does not say. It doesn't claim the machine 'understands' anything, or is 'conscious', or thinks the way you do. It only talks about the task and whether the machine can do it.
Here's the intuition to hold onto: AI is defined by behaviour, not by inner experience. A calculator does arithmetic far better than you, but we don't call it intelligent — because arithmetic stopped feeling like 'thinking' the moment machines got good at it. This happens again and again, and it even has a name: the AI effect — 'AI is whatever hasn't been done yet.' Once a problem is solved, we shrug and call it 'just software'.
#The three nested circles
The single most useful picture in the whole field is a set of circles, one inside the next. Almost every confusion a beginner has dissolves the moment this picture is clear.
Read it from the outside in. Artificial Intelligence is the whole field — it includes old-fashioned hand-written rules and modern learning systems. Machine Learning is the slice of AI where, instead of a human writing the rules, the machine figures out the rules by studying examples. Deep Learning is a slice of ML that uses a particular tool — many-layered 'neural networks'. And the chatbots and image generators everyone talks about today live in that innermost circle.
Think of it like vehicles → cars → electric cars → Teslas. Every Tesla is an electric car; every electric car is a car; every car is a vehicle — but a bicycle is a vehicle that is none of the others. In the same way, a hand-coded chess program from 1985 is AI but not machine learning, just as a bicycle is a vehicle but not a car.
#Software you write vs. software that learns
There's one distinction that separates classical programming from machine learning, and it's worth burning into memory because everything later depends on it.
| Classical software | Machine learning | |
|---|---|---|
| Who makes the rules? | A human writes them, line by line | The machine infers them from examples |
| What you provide | The logic: if income > X and age < Y, approve | The data: 100,000 past decisions and their outcomes |
| What comes out | Predictable output for each input | A learned pattern that even its creators can't fully spell out |
| Good when | Rules are known and stable | Rules are fuzzy, complex, or hidden in the data |
A spam filter makes this concrete. The classical approach: a human writes rules like if the subject says 'FREE MONEY', mark as spam. The learning approach: show the system a million emails already labelled spam or not-spam, and let it discover for itself the thousands of subtle signals — including ones no human would ever think to write down.
Misconception: 'AI means robots / human-like minds.' Almost all real AI is invisible and narrow: the system that decides which posts you see, the model that flags a fraudulent transaction, the autocomplete finishing your sentence. None of it is a robot, and none of it 'wants' anything. Keeping this in mind will protect you from a lot of hype in both directions.
We need machines for tasks where writing explicit rules is hopeless — there is no clean if-then formula for 'is this a photo of a cat' or 'is this review positive'. Intelligence-as-behaviour lets us sidestep philosophy and just build useful things.
By **mimicking the outcomes of intelligent behaviour** — often by learning patterns from large amounts of data rather than being told the rules — and judging success by performance on the task, not by any inner 'understanding'.
Everywhere, mostly unseen: search engines, recommendations, fraud detection, translation, voice assistants, medical imaging, and the generative tools (chatbots, image makers) that finally made AI visible to everyone in 2022.
For each system, decide: (a) is it AI? (b) is it machine learning? — a thermostat that switches on below 18°C · a chess engine using hand-coded strategy · Netflix's 'because you watched' row · a calculator · ChatGPT.
Then ask the deeper question for each: could a human realistically have written every rule by hand? That question is the real dividing line between classical software and ML.
Show answer
- **AI is defined by what a system can do, not by whether it 'understands' or is conscious.**
- The AI effect: once we solve a problem, we stop calling it intelligence.
- AI ⊃ ML ⊃ DL — nested circles. Today's chatbots sit in the innermost one.
- Classical software = humans write the rules. Machine learning = the machine learns the rules from examples.
The Age of Rules: Symbolic AI
The first 30 years of AI bet everything on a beautiful idea — that intelligence is just logic — and built systems that could out-diagnose doctors in narrow fields. Here's why that dream was both right and doomed.
In the early 1970s at Stanford, a program called MYCIN sat in a hospital and recommended antibiotics for blood infections. It worked by chaining together about 600 rules that doctors had dictated — if the organism is gram-negative and the patient has a fever, then suspect… In blind tests, MYCIN's recommendations were rated as good as or better than human specialists. For a moment, it looked like the path to machine intelligence was obvious: just write down enough rules.
#The big idea: intelligence = symbols + logic
This era's philosophy is called Symbolic AI (or, affectionately, GOFAI — 'Good Old-Fashioned AI'). The bet was elegant: human reasoning is the manipulation of symbols (CAT, FEVER, INFECTED) according to logical rules, so if we encode enough facts and enough if-then rules, the machine will reason its way to intelligent conclusions.
You already use a symbolic system every day: a recipe, a tax form, or a troubleshooting flowchart ('Is it plugged in? → No → plug it in'). Each is a chain of explicit rules a human can read, follow, and audit. Symbolic AI is that idea taken to its logical extreme — an entire mind built out of flowcharts.
#Expert systems: bottling a specialist
The commercial star of this era was the expert system: interview a human expert, extract their knowledge as rules, and bottle it in software so the expertise could be copied a thousand times. In the 1980s, companies poured fortunes into them. They genuinely worked in narrow, tidy domains — configuring computer orders, diagnosing equipment faults, approving simple loans.
An expert system is like a fantastically detailed instruction manual that reads itself. As long as your problem is one the manual's authors anticipated, it's brilliant and tireless. Step outside the manual's pages, though, and it has nothing — not even the common sense to know it's lost.
#Why the dream cracked
Three cracks eventually broke the symbolic approach — and understanding them tells you exactly why machine learning had to be invented.
- The common-sense problem. The world has a near-infinite number of unwritten facts (water is wet, parents are older than their children, you can't push a rope). Hand-writing them all is impossible — and a system that lacks them makes absurd mistakes.
- Brittleness. Rule systems don't degrade gracefully. Feed them something slightly outside their rules and they don't give a slightly-wrong answer; they break completely or confidently say something ridiculous.
- The knowledge bottleneck. Every rule had to be pried out of a human expert and hand-coded. For messy tasks like 'recognise a face', experts can't even state their rules — you just know your friend's face; you can't write down how.
Misconception: 'Symbolic AI failed and was abandoned.' Not quite. It was eclipsed for general problems, but logic and rules never went away — they run your bank's transaction checks, airline booking systems, and tax software today. The frontier is even circling back: neuro-symbolic AI tries to fuse learned models with explicit logic. Old ideas in this field rarely die; they wait.
Humanity wanted machines that could reason and decide in expert domains — medicine, engineering, finance — where good decisions were valuable and scarce.
By having experts dictate their knowledge as explicit if-then rules, then letting the machine chain those rules together to reach conclusions a human could follow and audit.
Still alive wherever rules are known, stable, and must be explainable: tax and compliance software, business-logic engines, safety interlocks, and the rule layers inside otherwise-learned systems.
- Symbolic AI / GOFAI bet that intelligence = manipulating symbols with logical rules.
- Expert systems bottled a specialist's knowledge as rules — and genuinely worked in narrow domains.
- It broke on common sense, brittleness, and the knowledge bottleneck — you can't hand-write every rule, especially for perception.
- Rules never died; they power critical systems today and are returning via neuro-symbolic approaches.
The AI Winters: When the Money Froze
Twice, AI promised the moon, missed, and watched its funding evaporate. The 'AI winters' are not just history trivia — they're a permanent lesson about hype, and a warning worth carrying into today's boom.
In 1973, the British government commissioned Sir James Lighthill to assess AI research. His report was withering: the field had wildly over-promised and under-delivered. Funding was slashed almost overnight. A similar collapse hit the United States. Researchers learned to avoid the very words 'artificial intelligence' on their grant applications — they'd call it 'informatics' or 'machine learning' or 'pattern recognition' instead, just to get funded. The field had become so toxic it went into hiding under other names.
An AI winter is a period when disappointment in AI leads to a sharp drop in funding and interest. There were two big ones — roughly the mid-1970s and the late 1980s into the early 1990s — and each followed the same heartbreakingly simple pattern.
#The hype cycle, drawn once
The engine of every winter was a mismatch between promises and physics. Researchers in the 1960s genuinely believed human-level AI was a decade away. They weren't lying — they just couldn't see that the problems they'd cracked (logic puzzles, simple games) were the easy ones, and the things humans find trivial (seeing, walking, understanding a sentence) were monstrously hard.
It's the classic mistake of a hiker seeing a tall peak and thinking that's the summit — only to climb it and discover a vast mountain range hidden behind, each peak higher than the last. Early AI climbed the first hill (formal logic) and announced the summit was in sight. Behind it lay common sense, perception, and language: ranges they didn't even know existed.
#Why the rules-based dream specifically ran out of road
The winters weren't random bad luck. They were the symbolic approach (Lesson 1.2) hitting its ceiling. Expert systems were expensive to build, impossible to scale to the messy real world, and brittle the moment reality stepped outside their rules. Meanwhile the hardware was far too weak to try anything more ambitious. The promises had been written for a future that the technology of the day simply couldn't deliver.
Misconception: 'A winter means the science stopped.' The opposite — some of the most important work happened during the cold. Backpropagation, the algorithm that powers modern neural networks (Part 5), was refined in the 1980s, in the depths of the field's unpopularity. Winters freeze funding and attention, not necessarily progress. The seeds of each spring were planted in the previous winter.
Worth sitting with: we are, right now, in the hottest 'AI summer' in history — money and promises are flooding in exactly as they did before. Some of today's claims will prove visionary; some will prove to be 1960s-style over-reach. The winters don't tell you which claims are which. They just teach you to ask, every time: is this promise backed by something that actually works today, or by an extrapolation that assumes the next peak is the last one?
The winters matter because they're the field's hard-won lesson in calibrating hype against reality — a skill that protects you, your decisions, and your money in every boom, including this one.
Each followed the same mechanism: a real advance → inflated promises → heavy investment → collision with genuinely hard problems → disappointment → funding collapse.
The pattern recurs beyond AI — in biotech, crypto, and every 'this changes everything' technology. Recognising the shape lets you spot it forming in real time.
- An AI winter = collapse of funding and interest after AI over-promises and under-delivers. There were two major ones (~mid-1970s and late-1980s/early-1990s).
- Root cause: promises outran the methods and hardware — the easy problems got solved first, hiding how hard the rest were.
- Key work (like backpropagation) continued during the winters — progress and funding aren't the same thing.
- The pattern is a permanent tool for reading hype — including today's boom.
Letting the Data Speak: The Statistical Revolution
In the 1990s, AI quietly reinvented itself by giving up on writing rules and instead letting patterns emerge from data. This is the moment 'machine learning' as we know it was truly born.
Through the 1990s, a quiet revolution happened — not with a famous robot or a dramatic demo, but inside email servers and credit-card networks. Engineers fighting spam had spent years hand-writing rules ('block messages with VIAGRA in the subject'), and spammers simply wrote 'V1AGRA' and 'V-I-A-G-R-A' and walked right around them. It was an endless, losing arms race. Then someone tried something different: instead of writing rules, show the computer thousands of emails already sorted into 'spam' and 'not spam', and let it work out the statistical fingerprint of junk for itself. It worked spectacularly — and quietly reset the entire field.
#The philosophical 180
This is one of the most important turns in the whole story, so let's state it plainly. The symbolic era said: intelligence is logic; let's hand-write the rules. The statistical era said the opposite: don't write the rules at all — collect lots of examples and let the machine find the pattern that fits the data.
The shift is from deduction to induction. Deduction is reasoning from stated rules ('all men are mortal; Socrates is a man; therefore…'). Induction is reasoning from examples ('every swan I've seen is white, so swans are probably white'). Statistical ML is industrial-scale induction: see enough examples, and the general pattern reveals itself — including patterns far too subtle for any human to articulate.
Imagine teaching a child what a 'dog' is. You don't recite a definition ('four legs, fur, barks') — that would let in cats and rule out a three-legged dog. Instead you point at dozens of dogs over months: 'dog… dog… that's a dog too.' The child induces the fuzzy, flexible concept from examples. Statistical ML learns exactly this way — by being shown labelled examples until the pattern clicks into place.
#What got unlocked
Freed from hand-written rules, a toolbox of algorithms (which we'll meet properly in Part 4) powered the first wave of AI that quietly touched ordinary life:
- Spam filters that learned the statistical signature of junk mail and adapted as spammers evolved.
- Fraud detection that flagged transactions deviating from your normal pattern — too subtle for any fixed rule.
- Recommendation engines — the ancestors of 'customers who bought this also bought…'.
- Search engines ranking pages by learned signals of relevance.
Misconception: 'Statistical ML and modern AI are different things.' They're the same lineage. The deep learning and LLMs of today are this exact idea — learn the pattern from data — scaled up with more powerful pattern-finders (neural networks) and oceans more data and compute. The 1990s spam filter and ChatGPT are cousins; one is just vastly larger than the other.
This era also forged the discipline that still keeps machine learning honest — the iron rule of never testing a model on the same data it learned from, and the precise language of features, labels, training, and evaluation. We devote all of Part 3 to it, because these foundations matter more than any single fancy algorithm.
Hand-written rules couldn't keep up with a messy, adversarial, ever-changing world (spammers adapt; fraud evolves). Learning from data meant systems could adapt automatically instead of waiting for a human to patch the rules.
By collecting labelled examples and running a learning algorithm that finds the statistical pattern mapping inputs to outputs — induction at scale, rather than hand-coded deduction.
It powered the first generation of invisible, everyday AI: spam filters, fraud detection, recommendations, search — and it's the direct ancestor of every learning system since.
You want to predict which customers will cancel a subscription next month ('churn'). In the rules mindset you'd try to write conditions like 'if logins < 3 and tenure < 60 days, they'll churn'. In the learning mindset, what would you collect instead — and what's the one thing you must have attached to each past customer for the machine to learn from them?
Show answer
- The 1990s shift: stop writing rules; learn patterns from labelled data. Deduction → induction at scale.
- It powered the first wave of invisible everyday AI: spam filters, fraud detection, recommendations, search.
- Modern deep learning and LLMs are the same idea scaled up — more powerful pattern-finders, far more data and compute.
- This era also created ML's lasting discipline: features, labels, training, and honest evaluation (Part 3).
The Deep Learning Earthquake
In 2012, a neural network shattered a computer-vision contest so decisively that the whole field changed course within months. Three forces had quietly lined up — and when they met, AI exploded.
Every year, researchers competed on ImageNet: look at a photo and name what's in it, across a thousand categories, from 'golden retriever' to 'container ship'. Progress had been creeping along — each year shaving a percent or two off the error rate. Then in 2012, a system called AlexNet, built by Geoffrey Hinton's group in Toronto, didn't shave a percent. It cut the error rate almost in half, leaving every traditional method in the dust. The shock was total. Within a year, essentially the entire computer-vision community had abandoned its old toolkit and switched to deep neural networks. The earthquake had a date.
#So what is a neural network — in one breath?
We'll build neural networks properly and gently in Part 5. For the story, you only need the one-breath version: a neural network is a web of simple units ('neurons'), each doing a trivial weighted sum, stacked in layers. Early layers learn tiny patterns (an edge, a patch of colour); later layers combine those into bigger ideas (a texture, an eye, a whole face). 'Deep' just means many layers stacked up.
Picture an assembly line of specialists. The first worker only spots edges. The next assembles edges into shapes. The next assembles shapes into parts — an ear, a wheel. The last assembles parts into a verdict: 'cat' or 'car'. Nobody told each worker what to look for; they learned their specialty by practising on millions of examples. That layered, learn-it-yourself assembly line is a deep neural network.
#Why 2012 and not 1985?
Here's the twist that ties the whole history together. The math behind AlexNet — neural networks trained by backpropagation — had existed since the 1980s. So why did it lie dormant for nearly three decades and then suddenly conquer everything? Because intelligence wasn't the missing ingredient. Three other things finally arrived at the same time.
| Force | What changed | Why it mattered |
|---|---|---|
| Data | ImageNet: millions of labelled images; the internet at large | Deep networks are hungry — they only shine when fed enormous amounts of examples |
| Compute | GPUs — chips built for video-game graphics | Their math (massively parallel matrix multiplication) is exactly what neural networks need; training went from months to days |
| Algorithms | Refinements to training (better activations, regularisation, initialisation) | Made deep networks actually trainable without collapsing or stalling |
The lesson is profound and worth holding onto for the rest of the course: the breakthrough wasn't a single clever idea — it was a convergence. The idea (neural nets) had waited 30 years for the data and the compute to catch up. This is why people say modern AI is 'data + compute + algorithms arriving together', not one eureka moment. It also explains why the field can lurch forward so suddenly: when several slow-moving forces finally align, progress isn't gradual — it's an earthquake.
Misconception: 'GPUs were invented for AI.' The opposite — GPUs (Graphics Processing Units) were built to render the millions of triangles in video games, fast. It was a happy accident that the same parallel arithmetic is precisely what neural networks need. An entire revolution rode in on hardware designed for Doom and Call of Duty.
Old hand-engineered methods had hit a ceiling on perception (vision, speech). Deep learning learns its own features directly from raw data, blowing past that ceiling — and removing the need for humans to hand-design what to look for.
By stacking many layers of simple neurons that learn increasingly abstract patterns, trained on massive data using GPU compute and refined training tricks — the three forces converging at once.
It took over computer vision, then speech recognition, then translation — and set the stage directly for the Transformer and the generative era in the next lesson.
- AlexNet (2012) crushed the ImageNet vision contest and flipped the whole field to deep learning almost overnight.
- A deep neural network = many layers of simple neurons; early layers learn simple patterns, later layers combine them into complex concepts — learned, not hand-designed.
- The breakthrough was a convergence of three forces — data + compute (GPUs) + algorithmic refinements — not a brand-new idea; the math was from the 1980s.
- Lesson for the whole course: AI lurches forward when slow-moving forces align, which is why progress can feel sudden.
Attention, Generative AI, and the Age of Agents
From a single 2017 paper to ChatGPT to AI that takes actions on its own — the final stretch of the story, and the doorway into everything the rest of this course explains.
In 2017, a team at Google published a paper with an almost cheeky title: 'Attention Is All You Need.' It introduced an architecture called the Transformer. It didn't make headlines outside research circles. But it quietly solved a problem that had bottlenecked machines working with language for decades — and it scaled so beautifully that, five years later, it would put a chatbot in the hands of a hundred million people in two months. Almost every AI system you've heard of since — ChatGPT, Claude, Gemini — is a descendant of that one paper.
#The problem the Transformer solved
Before 2017, the best language models read text the way you might read through a paper towel tube — one word at a time, left to right, trying to hold everything important in a small memory as they went. By the time such a model reached word 50, the memory of word 1 had usually faded. Long-range connections — the kind human language is full of — kept slipping away.
"The trophy didn't fit in the suitcase because it was too big." What does 'it' refer to?
You knew instantly: the trophy. You did it by glancing back across the whole sentence and weighing which earlier words were relevant to 'it'. The Transformer's key trick — attention — does exactly this, mathematically: for every word, it looks at all the other words at once and decides how much each one matters for understanding the current one.
Reading with attention is like a student with a highlighter and the whole page open at once, rather than someone peering through a tube reading word-by-word. To understand 'it', the student highlights 'trophy' and 'suitcase', weighs them, and picks the winner — instantly, using the entire context. We'll unpack attention carefully in Part 8; for now, that image is enough.
Two superpowers fell out of this design. First, because attention looks at every word simultaneously rather than one-at-a-time, it runs in parallel — perfect for GPUs, so you can train on staggering amounts of text. Second, it has no long-range memory loss — word 1 and word 1,000 can connect as directly as neighbours. Parallel + no memory decay = an architecture that gets reliably better as you scale it up. That single property launched the modern era.
#The cascade: from Transformer to today
- 2018 — BERT & GPT. Researchers discovered Transformers scale beautifully: more data + more parameters → reliably better language ability.
- 2022 — ChatGPT. A Transformer-based Large Language Model (Part 9), refined to follow instructions, became the fastest-adopted consumer product in history. AI became visible to everyone at once.
- 2023–24 — Multimodal & generative everything. Models that handle text, images, and audio together; image generators (Part 13) producing photorealistic pictures from a sentence.
- 2024–26 — Reasoning & agents. Models trained to 'think' longer on hard problems, and agents (Part 12) that don't just answer but act — calling tools, running searches, taking multi-step actions toward a goal.
Misconception: 'ChatGPT was a sudden breakthrough out of nowhere.' It was the visible tip of a five-year iceberg: the Transformer (2017), the scaling discovery (2018+), enormous engineering, and a final alignment step (Part 9) that made a raw text-predictor into a helpful assistant. The 'overnight success' took half a decade of groundwork — the same lesson as 2012.
Notice the throughline of the whole story: rules (1.2) → data (1.4) → deep networks (1.5) → attention & scale (1.6). Each era didn't replace the last so much as absorb its lessons and add a new ingredient. You now have the entire map. Everything from here — the maths, the algorithms, neural networks, Transformers, LLMs, RAG, agents — is us zooming into one region of this map at a time.
Earlier language models lost track of long-range meaning and couldn't be trained efficiently at scale. Attention fixed both, unlocking models that keep improving as they grow.
Attention lets every word directly weigh every other word at once; this runs in parallel (great for GPUs) and has no memory decay, so Transformers scale to enormous size on internet-scale text — then get refined to follow instructions.
Everywhere now: chatbots and writing tools, search and coding assistants, image and video generation, and autonomous agents that take actions — the technologies the rest of this course explains.
Look back across the six lessons and write one sentence for each era — rules, winters, statistics, deep learning, transformers. Then answer: which single force (data, compute, algorithms, or money) shows up as the hinge in the most eras? There's no single right answer — the point is to feel how these forces interact rather than memorising dates.
- The Transformer (2017) and its attention mechanism let every word weigh every other word at once — fixing long-range memory loss and enabling parallel training at scale.
- That property made models predictably better as they grow, leading to BERT/GPT → ChatGPT (2022) → multimodal → reasoning models → agents.
- 'Overnight' breakthroughs (2012, 2022) are really years of converging groundwork becoming visible at once.
- The story's arc — rules → data → deep networks → attention & scale — is the map for the rest of this course.
A Friendlier Kind of Maths
Why the maths behind AI is far gentler than school made it look — and the one mindset shift that makes all of it click.
A lot of brilliant people freeze the moment they hear 'we'll need a little maths'. Usually it's not the ideas that scared them off years ago — it was the notation: a wall of Greek letters that hid simple thoughts behind intimidating symbols. Here's a secret working data scientists rarely say out loud: the maths that powers modern AI is mostly five or six everyday ideas, each of which you already use without naming. Averages. Spread. Chance. Comparing two things. Updating your mind when new facts arrive. That's most of it.
This part exists to give you the intuition behind those ideas — the mental pictures — so that when a formula shows up later, it feels like a caption for something you already understand, not a foreign language.
The mindset shift: a formula is compressed intuition, not the other way around. Mathematicians invented symbols to write down ideas quickly, the way an emoji compresses a whole feeling. We'll do the reverse of school — learn the feeling first, and only glance at the shorthand once the intuition is already there.
Think of learning to drive. You don't begin by studying the thermodynamics of the engine — you learn what the wheel and pedals do, build a feel for the car, and the deeper theory can come later if you ever want it. This part teaches you to drive the maths of AI. The 'engine internals' are optional.
#The promise of this part
By the end of Part 2 you'll have a genuine, pictures-first feel for: averages (and when they mislead), spread, probability, the bell curve, the difference between correlation and causation, how to update beliefs with evidence (Bayes), how meaning becomes arrows in space (vectors and embeddings — the heart of modern AI), and how machines 'learn' by walking downhill (gradient descent). Each is one short lesson. None needs algebra you don't already half-remember.
Misconception: 'I need to be good at maths to understand AI.' You need to be good at thinking clearly, which you already are. The arithmetic is done by computers. Your job is to understand what the numbers mean and where they can fool you — and that's a thinking skill, not a calculation skill.
Most people's block with AI isn't the concepts — it's maths anxiety from notation. Removing that unlocks everything downstream.
By teaching each idea as a picture and a story first, treating formulas as optional shorthand that describes an intuition you already hold.
These few ideas underpin every model in the course — regression, neural networks, embeddings, LLMs. Get them once; reuse them forever.
- The maths of AI is a handful of everyday ideas, not a wall of symbols.
- Formulas are compressed intuition — we learn the intuition first, notation last (and optionally).
- Computers do the arithmetic; your job is meaning and pitfalls — a thinking skill you already have.
Averages That Lie: Mean vs Median
The 'average' is the most used — and most abused — number in the world. Learn the two kinds, and the trick to knowing instantly when one of them is fooling you.
A career coach tells a graduating class: 'Alumni from this programme earn an average of £2 million a year!' The students are thrilled — until someone digs in. It turns out 99 graduates earn £40,000, and one founded a company and earns £200 million. Add it all up, divide by 100, and yes — the 'average' is about £2 million. But not a single typical graduate is anywhere near it. The number is true and completely misleading at the same time.
#Two different questions, two different 'averages'
When people say 'average', they almost always mean the mean: add everything up, divide by how many there are. It answers: if we shared everything out equally, how much each? The trouble is that a single extreme value — one billionaire, one outage, one giant order — drags the mean far away from anything typical.
The median answers a different, often more honest question: line everyone up in order — what's the person in the middle? The median doesn't care how extreme the extremes are; it only cares about the middle. In our story, the median salary is £40,000 — a far more honest picture of a typical graduate.
Salaries lined up: £38k £40k £41k ... £40k £200,000,000
| | |
low MEDIAN one outlier
(middle value) drags MEAN up
MEAN = pulled toward the outlier -> ~£2,000,000 (misleading)
MEDIAN = the middle person -> £40,000 (honest)Picture a see-saw. The mean is the exact balance point — so a single very heavy child sitting far out on one end tilts the whole balance toward them, even if ten light children sit on the other side. The median is just the kid sitting in the middle of the row, unbothered by how heavy anyone else is. When you hear 'average', ask: is this a balance point that one heavy outlier could tip?
Rule of thumb: if the data is roughly symmetric (heights, test scores), mean and median agree and either is fine. If it's skewed by a few big values (incomes, house prices, website session lengths, company sizes), the median is usually the honest summary — which is exactly why serious reporting uses 'median household income' and 'median home price', never the mean.
Misconception: 'The average tells me what's typical.' Only when the data is symmetric. With skewed data, the mean tells you the balance point, which can be a place where almost nobody actually sits. Always ask whether a few extreme values might be hiding behind that single number.
A single number has to summarise many — but the wrong summary can be technically true and wildly misleading, leading to bad decisions (salary expectations, pricing, capacity planning).
Mean = total shared equally (sensitive to outliers). Median = the middle value when sorted (ignores how extreme the extremes are). Skew is what splits them apart.
Everywhere data is reported: incomes, house prices, response times, model errors. In ML, the mean-vs-median choice decides whether one weird data point quietly distorts your whole model.
Five website visits last for: 3s, 5s, 4s, 6s, and 1,200s (someone left a tab open over lunch). Compute the mean and the median session length. Which one would you report as 'typical', and why?
Show answer
- Mean = add up, divide by count (the balance point — sensitive to outliers).
- Median = the middle value when sorted (robust to outliers).
- With skewed data (incomes, prices, durations, sizes), the median is usually the honest summary.
- Always ask: could a few extreme values be hiding behind this single 'average'?
Spread: Why the Average Is Only Half the Story
Two datasets can share the same average yet describe completely different worlds. The missing piece is 'spread' — and it quietly drives a huge amount of how AI thinks.
A man drowns crossing a river that is, on average, one metre deep. The average was true. It just didn't mention that the middle of the river was four metres deep. The average told him the centre of the data; it said nothing about how far the data wanders from that centre — and that gap is what killed him. In data, the wandering has a name: spread, or variance.
#Same centre, different worlds
Imagine two factories, each producing bolts that are on average exactly 10mm long. Factory A's bolts are all between 9.9 and 10.1mm. Factory B's range wildly from 6mm to 14mm. Same average — but you'd trust your life to Factory A and never to Factory B. The number that captures this difference is the variance (and its friendlier cousin, the standard deviation, which is just the variance brought back to normal units).
Factory A (low spread) Factory B (high spread)
| .:|:. | . :|: .
| .::|::. | .::::|::::.
| .:::|:::. |.:::::|:::::.
+------|------ mm +------|------ mm
10mm 10mm
tight, predictable wide, unpredictable
...... same MEAN, very different SPREAD ......Standard deviation answers a simple question: on a typical day, how far from the average should I expect to land? Small standard deviation = clustered, predictable, reliable. Large standard deviation = scattered, volatile, risky. You don't need the formula; you need the feeling that average and spread are two separate dials, and you must read both.
Two archers both average a bullseye. One lands every arrow in a tight ring around the centre; the other peppers the whole target — some bullseyes, some near the edge — and averages to the centre by luck. Same average, opposite skill. Spread is what separates the consistent archer from the lucky one.
Spread is everywhere in AI. A model's errors have a spread — a model that's usually close but occasionally catastrophic differs hugely from one that's reliably a little off, even at the same average error. Risk, volatility, and confidence intervals are all spread. And the entire idea of the bell curve (next lesson) is a centre (mean) combined with a spread (standard deviation).
Misconception: 'A good average means good performance.' Not without checking spread. A delivery service averaging '30-minute delivery' could mean everyone gets ~30 minutes, or half get 5 and half get 55. Same average, very different experience. Always ask for the spread.
The average alone hides risk and reliability. Two systems with the same mean can behave completely differently — and the difference (spread) is often what actually matters.
Variance / standard deviation measure the typical distance of values from their average. Small = clustered and predictable; large = scattered and volatile.
Quality control, risk, model-error analysis, confidence intervals, and the bell curve all rest on spread.
- Average and spread are two separate dials — always read both.
- Variance / standard deviation = how far values typically wander from the centre.
- Low spread = predictable/reliable; high spread = volatile/risky.
- Spread underlies risk, model-error analysis, confidence, and the bell curve.
Probability: The Mathematics of 'Maybe'
Probability is just careful thinking about uncertainty — and once you see it as counting possibilities rather than predicting the future, it stops being scary.
People are terrible at probability, and casinos are built on that fact. Ask someone if they'd take a bet, and their gut answer is often exactly backwards. The good news: probability isn't a special talent some people are born with. It's a skill — and at its core it's just one humble idea: count the ways something can happen, and compare that to the total number of things that could happen. Everything else is decoration on that single thought.
#Probability is counting, then dividing
A probability is a number between 0 (impossible) and 1 (certain), often shown as a percentage. To find it: count the outcomes you care about, divide by all the outcomes that could occur. A coin has 2 sides; 1 is heads; so P(heads) = 1/2 = 50%. A die has 6 faces; 1 is a four; so P(four) = 1/6 ≈ 17%. No magic — just careful counting.
P(event) = number of outcomes you want
------------------------------------
total number of possible outcomes
Coin -> heads : 1 / 2 = 50%
Die -> a six : 1 / 6 ~ 17%
Die -> even : 3 / 6 = 50% (2,4,6 out of 1-6)
0 = impossible 0.5 = even odds 1 = certainThe deepest intuition: probability is the long-run frequency. Saying a coin is 50% heads doesn't predict the next flip — it predicts that over thousands of flips, about half land heads. AI models live here: they don't say 'this email is spam', they say 'this email is 94% likely to be spam'. Almost every modern AI output is secretly a probability wearing a confident face.
Weather forecasting is the perfect mental model. '70% chance of rain' doesn't mean it half-rains. It means: on the many days that looked like this one, it rained on about 70% of them. When an AI says it's '90% confident', read it exactly like a weather forecast — a calibrated degree of belief, not a promise.
#Two rules worth their weight in gold
- AND (both happen) → multiply. Chance of two heads in a row = 1/2 × 1/2 = 1/4. Independent events multiply, and probabilities shrink fast — which is why 'everything has to go right' plans so often fail.
- OR (either happens) → add (roughly). Chance of rolling a 1 or a 2 = 1/6 + 1/6 = 2/6. (With overlaps you subtract the double-count, but the instinct 'OR grows, AND shrinks' carries you far.)
Misconception (the gambler's fallacy): 'Red came up five times, so black is due.' A fair wheel has no memory — each spin is still ~50/50. Past results don't 'balance out' in the short run. Independent events don't owe you anything. This single error funds a large share of the gambling industry.
The world is uncertain, and good decisions require reasoning about degrees of belief rather than false certainty. Probability is the only rigorous language for 'maybe'.
By counting favourable outcomes over all possible outcomes, treating probabilities as long-run frequencies; combine with multiply for AND, add for OR.
It's the native language of AI outputs: spam scores, medical-risk estimates, next-word likelihoods in an LLM, fraud probabilities. Models almost always output probabilities, not certainties.
You flip a fair coin three times. (a) What's the probability of heads all three times? (b) What's the probability of at least one tail? (Hint for (b): 'at least one tail' is the opposite of 'all heads' — a trick AI uses constantly.)
Show answer
- Probability = (favourable outcomes) ÷ (total outcomes), a number from 0 to 1.
- Read it as a long-run frequency / degree of belief — like a weather forecast.
- AND → multiply (shrinks); OR → add (grows).
- AI outputs are usually probabilities, not certainties — and the gambler's fallacy (independent events have no memory) is the classic trap.
The Bell Curve: Nature's Favourite Shape
One curve shows up everywhere — in heights, errors, exam scores, and measurement noise. Understanding it explains a huge amount of how the world, and AI, behaves.
In the 1800s, a Belgian astronomer named Quetelet started measuring people — heights, chest sizes — and noticed something uncanny. The measurements always piled up the same way: most people near the middle, fewer toward the extremes, forming a smooth, symmetric hill. He found the same hill in star-measurement errors, in birth rates, in almost everything. He'd stumbled onto perhaps the most important shape in all of statistics: the normal distribution, better known as the bell curve.
#Why so much of the world is bell-shaped
A distribution is just a picture of how often each value occurs. The bell curve is the specific distribution where values cluster symmetrically around a central average, thinning out smoothly on both sides. It appears whenever a result is the sum of many small, independent, random influences — and astonishingly often, that's exactly how nature works.
. - .
. .
. MEAN . <- most values
. | . near the centre
. | .
. | . <- rare values
. ' | ' . at the edges
------------------------------------------------
-3s -2s -1s AVG +1s +2s +3s
<-- about 68% of values within 1 sd of the mean -->
<----------- about 95% within 2 sd ---------------->Here's why it's everywhere. Your height is the sum of many small influences — hundreds of genes, childhood nutrition, sleep, luck. When you add up lots of independent little pushes, the highs and lows mostly cancel, and the totals pile up in the middle. Extreme outcomes need everything to push the same way, which is rare. That pile-in-the-middle is the bell curve — and it's why it shows up in heights, measurement errors, and the noise inside data that AI must see through.
Picture a Galton board (the 'Plinko' wall of pegs). Drop hundreds of balls; each bounces left or right at every peg — many small random choices. They almost never go all-left or all-right; they pile up into a bell shape at the bottom, every single time. That toy is the central insight: many small random effects, summed, make a bell.
The bell curve runs through AI. Measurement noise is usually bell-shaped, so models are built to see the signal through it. The '68–95–99.7' rule (about 68% of values within one standard deviation of the mean, 95% within two, 99.7% within three) is how we judge whether something is 'normal' or a genuine anomaly — the backbone of fraud and outlier detection. And many algorithms quietly assume a bell curve under the hood.
Misconception: 'Everything is normally distributed.' No! Incomes, city sizes, word frequencies, and pandemic case counts are famously not bell-shaped — they're skewed or 'heavy-tailed', where rare giant events dominate (recall the salary story in 2.2). Assuming a bell curve where there isn't one is a classic, expensive modelling error. The bell is common, not universal.
We need to know what 'normal' looks like to spot what's abnormal — and to model the random noise that contaminates almost all real data.
Values formed by summing many small independent effects pile up symmetrically around the mean; the whole shape is captured by just mean (centre) + standard deviation (width), with the 68–95–99.7 rule describing the spread.
Anomaly/fraud detection, quality control, A/B testing, measurement-noise modelling, and the assumptions inside many ML algorithms — but beware skewed, heavy-tailed data where it doesn't apply.
- A distribution shows how often each value occurs; the normal distribution (bell curve) is the symmetric hill around an average.
- It arises whenever a result is the sum of many small independent random effects — hence its ubiquity.
- Summarised by mean + standard deviation; the 68–95–99.7 rule defines 'normal' vs 'anomalous'.
- Not everything is normal — incomes, city sizes, and word frequencies are heavy-tailed; assuming a bell there is a costly mistake.
Correlation Is Not Causation
The most important sentence in all of data analysis — and the mistake that fools experts, headlines, and AI models every single day.
Every summer, two things rise together in a seaside town: ice-cream sales and shark attacks. Plot them month by month and they track each other almost perfectly. A naive analyst might conclude that ice cream causes shark attacks — or that sharks are drawn to people carrying cones. The truth is funnier and far more important: a third, hidden thing — hot weather — drives both. Heat sends people to buy ice cream and into the sea where the sharks are. Neither one causes the other.
#Two ideas that get fatally confused
Correlation means two things move together — when one goes up, the other tends to as well (or reliably down). Causation means one thing actually makes the other happen. Correlation is easy to measure; causation is hard to prove. And the cardinal sin of data analysis is seeing a correlation and assuming causation.
Whenever two things move together, there are always several possible explanations, and 'A causes B' is only one of them: maybe B causes A (reverse), maybe a hidden third factor (a 'confounder') causes both (the heat), or maybe it's pure coincidence (with enough data, random things line up). Spotting a correlation is the start of an investigation, never the end.
Correlation is like noticing that two people always arrive at the office at the same time. Maybe one drives the other (causation). Maybe they just both catch the same train (a shared cause). Maybe it's coincidence. The shared arrival time tells you they're linked somehow — it does not tell you who is driving whom, or whether anyone is.
#Why this matters more in the age of AI, not less
Machine-learning models are, at heart, spectacular correlation-finders. Feed a model enough data and it will discover thousands of patterns that move together — and it has no built-in idea which are causal. A model might learn that 'patients examined by this expensive scanner survive longer' and conclude the scanner heals people, when really only already-healthier patients were sent for the scan. The model found a real correlation and a completely false cause.
Misconception: 'If the data shows a strong link, it must be causal — especially with lots of data.' More data makes correlations cleaner, not more causal. The only reliable way to establish causation is a controlled experiment (an A/B test, a randomised trial) where you actually change one thing and hold everything else equal. Observation alone — however vast — can suggest causes but rarely prove them.
Acting on a false cause wastes money and can do real harm — banning ice cream won't save a single swimmer. Models that confuse the two make confident, expensive, wrong decisions.
Two variables can move together because A→B, B→A, a hidden confounder→both, or coincidence. Only a controlled experiment (randomised A/B test) reliably isolates true cause from mere correlation.
Medicine, economics, marketing attribution, hiring, and every ML model — which find correlations brilliantly and causation not at all unless carefully designed to.
A report finds that employees who attend the company's optional wellness retreat have 30% lower turnover. Leadership wants to make the retreat mandatory to cut turnover. Name at least one reason this correlation might not be causal — and what single experiment would actually test it.
Show answer
- Correlation = things move together. Causation = one actually makes the other happen. They are not the same.
- A correlation has several explanations: reverse causation, a hidden confounder, or coincidence — 'A causes B' is just one.
- ML models are correlation engines and confuse the two unless carefully designed — a major source of real-world failures.
- Only a controlled experiment (A/B test / randomised trial) reliably establishes cause.
Bayes' Theorem: Updating Your Mind With Evidence
A 250-year-old idea for changing your beliefs as new facts arrive — and the reason a '99% accurate' test can still be wrong most of the time.
A disease affects 1 in 1,000 people. A test for it is '99% accurate'. You test positive. How worried should you be? Most people — including, in studies, most doctors — say '99% sure I have it'. The real answer is closer to 9%. That gap, between the gut answer and the true answer, is one of the most consequential blind spots in human reasoning — and the cure is a single, beautiful idea named after the Reverend Thomas Bayes.
#The idea: start with a belief, then let evidence nudge it
Bayes' theorem is a recipe for updating what you believe when new evidence arrives. You start with a prior — how likely something was before the new evidence (here: rare, 1 in 1,000). New evidence (a positive test) doesn't replace that prior; it updates it into a posterior — your revised belief, which still respects how rare the thing was to begin with.
The trick your gut skips: a rare disease means there are far more healthy people than sick ones, so even a small error rate on that huge healthy group produces a flood of false positives — enough to drown out the few true ones. The test's 'accuracy' is real; it just runs into the brute arithmetic of rarity. Bayes forces you to weigh the evidence against the base rate, which intuition refuses to do.
Imagine 1,000 people. Disease is 1 in 1,000.
TRULY SICK: 1 person -> tests POSITIVE (true positive) = 1
HEALTHY: 999 people -> 1% wrongly test POSITIVE ~ 10
(false positives)
Positive tests total ~ 11. Actually sick among them = 1.
P(sick | positive) = 1 / 11 ~ 9% <-- not 99% !Bayes is how a good detective thinks. You begin with priors about who's likely guilty. Each clue doesn't crown a new suspect outright — it shifts the odds. A fingerprint is strong evidence, but if it points to someone who was provably on another continent (a near-zero prior), you don't convict them; you weigh the clue against the prior. Updating beliefs proportionally to evidence and prior plausibility is the whole game.
#Why AI runs on this
Bayesian updating is woven through machine learning. Spam filters literally compute P(spam | the words in this email) by combining the prior rate of spam with the evidence of each word. Medical-AI, fraud systems, and recommendation engines all reason this way: hold a prior, observe evidence, update. Even the broad philosophy of training a model — start with a guess, see data, revise — is Bayesian in spirit.
Misconception: 'A 99%-accurate test means a positive result is 99% likely to be true.' Only if the thing is common. For rare conditions, the base rate dominates and most positives are false — which is exactly why doctors re-test after a surprising positive, and why screening rare conditions in the whole population is statistically tricky. Accuracy and 'chance you actually have it' are different numbers.
We constantly have to revise beliefs as evidence trickles in — and human intuition systematically ignores base rates, leading to confident errors in medicine, law, and risk.
By combining a prior (how likely before) with new evidence to produce a posterior (revised belief) — crucially weighing the evidence against how rare the thing was to start with.
Spam filtering, medical diagnosis, fraud detection, A/B-test analysis, and the very logic of learning from data — see evidence, update belief.
- Bayes' theorem updates a prior belief with evidence to produce a posterior belief.
- It forces you to weigh evidence against the base rate — which human intuition ignores.
- For rare events, even an accurate test produces mostly false positives — hence re-testing.
- Bayesian updating underlies spam filters, medical AI, fraud detection, and the logic of learning itself.
Vectors & Embeddings: Turning Meaning Into Arrows
The single most important mathematical idea in modern AI: how words, images, and ideas become points in space — and why that lets a machine measure 'similar in meaning'.
How do you explain to a computer — which only understands numbers — that 'king' and 'queen' are related, that 'happy' and 'joyful' are nearly the same, and that 'happy' and 'concrete' have nothing to do with each other? For decades this was AI's great wall: meaning is fuzzy and human; numbers are precise and cold. The breakthrough was deceptively simple: turn every word into a list of numbers — a point in space — positioned so that things with similar meaning sit close together. That idea, called an embedding, is the beating heart of every modern language model.
#First, what's a vector?
A vector is just an ordered list of numbers — and you can picture it as an arrow to a point in space. '2 steps east, 3 steps north' is a vector pointing to a spot on a map. With two numbers you get a point on a flat map; with three, a point in a room; with hundreds, a point in a space too big to picture — but the idea stays identical: a list of numbers is a location, and locations can be near or far from each other.
Think of a map of cities. Each city is a pair of numbers (latitude, longitude) — a vector. Cities close on the map are close in the numbers. Now imagine a magical map where the 'cities' are words, arranged so that words used in similar ways are neighbours: 'dog', 'puppy', and 'hound' cluster in one district; 'happy', 'glad', 'joyful' in another, far across town from 'invoice' and 'mortgage'. An embedding is exactly that map — for meaning instead of geography.
Here's the part that feels like magic but is just geometry. Because related words sit in consistent directions, you can do arithmetic on meaning. The famous example: take the point for king, subtract the direction for man, add the direction for woman, and you land almost exactly on queen. The 'gender' relationship became a direction in space, and the 'royalty' relationship another. Meaning turned into geometry — and geometry is something computers are extremely good at.
#Why this unlocked modern AI
Once meaning is a location, two hard problems become easy. 'How similar are these two things?' becomes 'how close are their points?' — a distance you can measure instantly. And 'find me things like this one' becomes 'find the nearest neighbours' — which is exactly how semantic search, recommendations, and the retrieval step in RAG (Part 11) work. Embeddings aren't only for words: images, audio, products, and users all get embedded into spaces where nearby = similar.
Embeddings power an astonishing amount of what you use: semantic search (results by meaning, not just keyword match), recommendations ('similar to what you liked' = nearby vectors), face recognition (your face becomes a vector; matching = a nearby vector), RAG systems that fetch relevant documents for an LLM, and the inside of every Transformer, where each token first becomes an embedding before anything else happens.
Misconception: 'The numbers in an embedding mean something I could read.' Mostly not. No single number is 'the royalty dimension' you can point to; meaning is smeared across hundreds of dimensions that the model learned, not ones a human designed. What's reliable isn't any individual number — it's the relationships: distances and directions between points capture similarity and analogy.
Computers only handle numbers, but meaning is fuzzy and relational. We needed a way to make 'similar in meaning' something a machine can measure — otherwise language, search, and recommendation are impossible.
By embedding each item as a vector (a point in high-dimensional space), learned from data so that similar items land close together and relationships become consistent directions — turning meaning into geometry.
Semantic search, recommendations, face/voice recognition, RAG retrieval, and the input layer of every LLM. If two things in AI are compared for similarity, embeddings are almost certainly underneath.
On a meaning-map, the arrow from 'Paris' to 'France' represents the relationship 'capital-of → country'. If that same direction is consistent across the map, what word should you land on if you start at 'Tokyo' and follow the same arrow? What does this tell you about what the embedding has 'learned'?
Show answer
- A vector is a list of numbers = a point/arrow in space; nearby points are 'similar'.
- An embedding maps words/images/items into a space where closeness = similarity in meaning, learned from data.
- Relationships become directions (king − man + woman ≈ queen) — meaning turned into geometry.
- Embeddings power search, recommendations, recognition, RAG, and the inside of every LLM — arguably the most important idea in modern AI.
Derivatives & Gradient Descent: Learning by Walking Downhill
The one algorithm that secretly powers nearly all of machine learning — explained with a single image: finding the bottom of a valley in thick fog.
Imagine you're standing somewhere on a vast, hilly landscape, blindfolded by thick fog. Your goal: reach the lowest point in the valley. You can't see the bottom. But you can feel the slope of the ground right under your feet. So you do the only sensible thing — feel which way is downhill, take a small step that way, and repeat. Step after step, you descend, until the ground feels flat and you can go no lower. You've just performed gradient descent — the single most important learning algorithm in all of AI, and the engine inside almost every model in this course.
#The valley is 'how wrong the model is'
Here's the translation. Every learning model has knobs (called weights or parameters) it can turn. For each setting of the knobs, there's a number measuring how badly the model is doing — its error (or 'loss'). Picture every possible knob-setting laid out as a landscape, with height = error. High ground = very wrong; the valley floor = as right as the model can be. Learning is just finding the lowest point of that error landscape.
error
| \ /
| \ (you start here) /
| \ o /
| \ /| /
| \ step /
| \ | \ /
| \ v \ /
| \___ \_____ /
| \___ _/
| \____/ <- lowest error: best knob settings
+------------------------------------- knob settings (weights)
gradient descent walks downhill, one small step at a timeThe 'slope under your feet' has a maths name: the derivative (or, in many dimensions, the gradient). A derivative answers one question: if I nudge this knob a little, does the error go up or down, and how steeply? That's all a derivative is — the local slope, a measure of which way and how fast things change. Knowing the slope tells you which way is downhill, which is the only thing you need to take a good step.
It's exactly learning to season a soup. You taste (measure error), decide 'needs more salt' (the direction that improves it), add a little (a small step), taste again, adjust. You never compute the 'perfect' salt level in one go — you iterate toward it with small, feedback-guided steps. A model 'tastes' its error, finds the downhill direction (the gradient), and nudges its knobs, millions of times.
#The one setting that matters most: step size
How big a step you take each time is the learning rate, and it's the most important dial in training. Too small, and you inch down the valley with agonising slowness. Too large, and you leap right across the valley and bound up the other side, possibly never settling. Good training picks a step size that's brisk but careful — a theme you'll meet again in Part 5.
Misconception: 'Gradient descent finds the perfect, guaranteed-best answer.' Not always. A foggy hiker can get stuck in a small dip (a 'local minimum') that isn't the true lowest valley. In practice, clever tricks and the strange geometry of huge models make this far less of a problem than it sounds — but it's why training is part science, part craft, and why the same model trained twice can land in slightly different places.
Gradient descent trains almost everything: linear and logistic regression, every neural network (Part 5), the Transformers behind LLMs (Part 8), image generators (Part 13). When you hear that a model was 'trained for three weeks on thousands of GPUs', that is gradient descent — taking trillions of tiny downhill steps across an unimaginably vast error landscape.
Models have millions or billions of knobs and no human can set them by hand. We need an automatic way to tune them all to minimise error — gradient descent is that way.
Measure the error, compute the slope (derivative/gradient) to find the downhill direction, take a small step (sized by the learning rate), and repeat until the error stops dropping.
It trains virtually every modern model — regression, neural networks, Transformers, LLMs, image generators. It is the learning engine of AI.
You're tuning one knob to reduce error. You nudge it up slightly and the error increases. Which way should your next step go, and why? Then: what would go wrong if every step you took was enormous?
Show answer
- Learning = finding the lowest point of an 'error landscape' (height = how wrong the model is).
- A derivative/gradient is the local slope — which way is downhill and how steep.
- Gradient descent: feel the slope → take a small step downhill → repeat. The learning rate is the step size (too big overshoots; too small crawls).
- It trains almost every model in AI — regression, neural nets, Transformers, LLMs, image generators.
What 'Learning From Data' Really Means
Stripped of mystique, machine learning is one simple act repeated at scale: finding the rule that best fits the examples. Here's that act, made concrete.
A child sees a few dogs and, within weeks, can point at a breed they've never encountered and say 'dog!'. Nobody gave them a definition. They didn't memorise those specific dogs — they extracted the pattern of dog-ness and can now apply it to brand-new cases. That leap, from specific examples to a general rule that handles new cases, is the entire essence of machine learning. Everything else — neural networks, Transformers, the lot — is elaborate machinery for doing exactly this, at scale.
#Learning = finding the rule that fits the examples
Recall the core distinction from Part 1: classical software has a human write the rule; machine learning has the machine discover the rule from examples. Let's make 'discover the rule' concrete. Suppose you have data on past houses — their size and their price. You want a rule that turns size into price. Plot the points, and you can almost see a line running through them. Machine learning is the process of finding that line (or curve) automatically — the one that fits the known examples best, so it can price a new house it has never seen.
price
| . o <- new house: predict
| o . its price from the
| o . learned line
| o .
| o . <- the learned rule (line) that
| o . best fits the known examples (o)
+-------------------------------------- house size
Learning = find the rule that fits the examples,
so you can handle NEW, unseen cases.The goal is not to memorise the training examples — it's to generalise to new ones. A model that perfectly remembers every house it was shown but prices a new house terribly has failed, even though it 'knows' the training data flawlessly. This tension — fit the examples, but actually learn the general pattern — is the central drama of all of machine learning, and we'll return to it again and again (especially in 3.5).
It's the difference between a student who memorises last year's exam answers and one who understands the subject. Give them last year's paper and both ace it. Give them this year's paper — new questions — and only the one who learned the underlying pattern succeeds. Machine learning is always trying to build the second kind of student, and constantly at risk of accidentally building the first.
#The vocabulary you'll reuse forever
Three words unlock every later lesson. A model is the rule the machine learns (the line, the curve, the neural network). Training is the process of adjusting that rule to fit the examples — which, under the hood, is the gradient descent of Lesson 2.9, nudging knobs to reduce error. Inference (or 'prediction') is using the trained model on a new case. Train once on many examples; infer many times on new inputs.
Many real problems have no writable rule — there is no clean formula for 'price this house' or 'is this transaction fraud'. Learning the rule from examples is the only practical path.
By fitting a model (a rule) to known examples so it captures the general pattern, then using it to predict on new, unseen cases — generalisation, not memorisation.
Every supervised AI task: pricing, forecasting, churn, fraud, medical risk, recommendations — and, scaled up enormously, the language models in later parts.
- Machine learning = finding the general rule that fits the examples, so it works on new cases.
- The aim is generalisation, not memorisation — performing on data it hasn't seen.
- Core vocabulary: a model is the learned rule; training fits it (via gradient descent); inference applies it to new inputs.
The Four Ways Machines Learn
Almost every learning system fits into one of four families. Knowing which family a tool belongs to instantly tells you what it can and can't do.
Three teachers run three very different classrooms. In the first, every exercise comes with the correct answer in the back of the book — the student checks their work and improves. In the second, the student is handed a giant box of unlabelled photos and simply asked to 'sort these into groups that go together', with no answer key at all. In the third, there's no book — the student tries things, and the teacher just says 'warmer' or 'colder' after each attempt. These three classrooms are three of the four ways machines learn — and the fourth is a clever trick the others can't do.
#The four families
| Family | The setup | Everyday analogy |
|---|---|---|
| Supervised | Examples with correct answers (labels). Learn input → known output. | Flashcards with answers on the back |
| Unsupervised | Examples with no answers. Find structure/groupings yourself. | Sorting a messy wardrobe into piles that go together |
| Self-supervised | The data creates its own answers (e.g. hide a word, predict it). | Fill-in-the-blank you mark yourself |
| Reinforcement | No answers — just rewards/penalties from trial and error. | Training a dog with treats |
#Supervised: learning from an answer key
The workhorse of practical AI. You show the model thousands of examples labelled with the right answer — emails marked spam/not-spam, houses with their sale prices, scans marked healthy/tumour — and it learns the mapping from input to answer. Most business ML (churn, fraud, pricing, demand forecasting) is supervised. Its appetite is labelled data, which is often expensive to produce, because a human had to label it.
Supervised learning is flashcards with the answer on the back. You see the front (the input), guess, flip to check (the label), and adjust. Do this across thousands of cards and you internalise the pattern. No answers on the backs = no supervised learning.
#Unsupervised: finding structure with no answer key
Here there are no labels at all. You hand the model raw data and ask it to find hidden structure — natural groupings (clustering), or a simpler underlying description (dimensionality reduction). It can't tell you 'this is a high-value customer' (nobody labelled value); it can tell you 'these customers form three distinct groups', and a human interprets what the groups mean.
Unsupervised learning is organising a wardrobe nobody labelled. You don't know the 'right' categories, but you naturally pile shirts with shirts, winter with winter — finding structure that was always there. Customer segmentation works exactly this way: the groups emerge from the data, and you name them afterwards.
#Self-supervised: the trick that built ChatGPT
The newest and most consequential family. The clever idea: let the data label itself. Take a sentence, hide the last word, and ask the model to predict it — the hidden word is the answer, generated for free from the text itself. No human labelling required, so you can train on the entire internet. This 'predict the missing piece' game, repeated trillions of times, is how Large Language Models (Part 9) learn language. It looks unsupervised (no human labels) but works like supervised (there's a right answer) — the best of both.
Self-supervised learning is fill-in-the-blank where the original text is the answer key. 'The cat sat on the ___.' You guess 'mat'; the original sentence reveals if you're right. Because the answers come free from the data, you can play this game on a near-infinite scale — which is precisely why it scaled into modern LLMs.
#Reinforcement: learning from reward
No answer key — just consequences. The model (here called an agent) takes actions, receives rewards for good outcomes and penalties for bad ones, and gradually learns a strategy that maximises reward. It's how AI mastered Go and video games, how robots learn to walk, and — importantly — part of how LLMs are tuned to be helpful (RLHF, Part 9).
Reinforcement learning is training a dog. You can't explain 'sit' in words. So when the dog happens to sit, you give a treat (reward); over many tries, it links the action to the reward and learns the behaviour. The agent explores, gets feedback, and converges on what works — no instructions, just consequences.
Misconception: 'These are competing rivals; one is best.' They're tools for different jobs. Got labelled answers? Supervised. Need to discover hidden groups? Unsupervised. Have oceans of raw text/images? Self-supervised. Optimising behaviour through trial and feedback? Reinforcement. Modern systems often combine them — LLMs use self-supervised pretraining then reinforcement fine-tuning.
Different problems come with different ingredients — sometimes labelled answers, sometimes none, sometimes only rewards. Matching the learning family to what you actually have is the first real decision in any AI project.
Supervised learns input→label from answers; unsupervised finds structure with no answers; self-supervised manufactures answers from the data itself; reinforcement learns from rewards via trial and error.
Supervised → fraud/churn/pricing. Unsupervised → segmentation/anomaly detection. Self-supervised → LLMs and modern foundation models. Reinforcement → games, robotics, and aligning LLMs.
For each task, name the learning family: (a) group your customers into segments you didn't pre-define; (b) predict which customers will churn, using past customers labelled churned/stayed; (c) train a model on billions of web pages by having it predict missing words; (d) teach a warehouse robot to stack boxes efficiently through trial and error.
Show answer
- Supervised = learn from labelled answers (flashcards). The workhorse of business ML.
- Unsupervised = find structure with no answers (sorting a wardrobe). Clustering, segmentation.
- Self-supervised = the data labels itself (fill-in-the-blank). How LLMs are pretrained.
- Reinforcement = learn from rewards by trial and error (training a dog). Games, robotics, LLM alignment.
Features and Labels: The Raw Materials
Before any model can learn, the world has to be turned into a table of numbers. How you do that — choosing the 'features' — matters more than which algorithm you pick.
A team spent months trying fancier and fancier algorithms to predict customer churn, and nothing moved the needle. Then someone added one new column to the data: days since the customer last logged in. Accuracy jumped overnight. The lesson stung and stuck: the columns you feed a model usually matter more than the model itself. A simple model with great inputs beats a brilliant model with poor ones, almost every time.
#Turning the world into a table
Every supervised learning problem starts by arranging data as a table. Each row is one example (a customer, a house, an email). The input columns are the features — the clues the model gets to use. The one column you're trying to predict is the label (or 'target'). Learning is finding the pattern that maps the features to the label.
FEATURES (the clues) LABEL (the answer)
+----------+---------+--------------+ +----------------+
| tenure | logins | support_tix | | churned? |
+----------+---------+--------------+ +----------------+
| 24 mo | 3 | 5 | | YES | <- example 1
| 60 mo | 40 | 0 | | NO | <- example 2
| 2 mo | 1 | 8 | | YES | <- example 3
+----------+---------+--------------+ +----------------+
inputs the model learns FROM what it learns to PREDICTA feature is just a measurable clue about each example. A label is the answer you want to predict. The model's whole job is to learn how the features combine to predict the label. So the quality of your features sets a ceiling on how good any model can be: if the real signal isn't in your columns, no algorithm — however clever — can conjure it from thin air.
#Feature engineering: where the craft lives
Feature engineering is the art of creating better input columns — and it's where much of real-world ML skill actually lives. Raw data rarely arrives in the most useful form. A raw timestamp of last login is far less useful than the derived feature 'days since last login'. A raw birth date is less useful than 'age'. Combining, transforming, and inventing features to expose the signal is often what separates a model that works from one that doesn't.
Features are the ingredients; the algorithm is the recipe. A world-class recipe can't rescue rotten ingredients, but a simple recipe with superb ingredients makes a great dish. Time spent sourcing better ingredients (features) usually pays off more than time spent on a fancier recipe (algorithm).
Misconception: 'More features always help.' Not so. Irrelevant features add noise and can mislead a model; redundant features that say the same thing (highly correlated columns) cause their own trouble (you'll meet this as multicollinearity in Part 4). The goal is informative features, not many features — quality over quantity.
Feature thinking is everywhere: a fraud model's features might include transaction amount, time of day, and distance from the last purchase; a medical model's might be blood pressure, age, and test results; a marketing model's might be ad spend by channel, day of week, and seasonality. In modern deep learning, networks learn some features automatically (Part 5) — but for the structured, tabular data most businesses run on, human feature engineering is still king.
Algorithms can only learn from what they're given. If the signal isn't in the columns, no model can find it — so the inputs are the real ceiling on performance.
By arranging data as a table of features (input clues) and a label (the answer), then engineering features that expose the signal — transforming, combining, and deriving better columns.
Every tabular ML problem in business: churn, fraud, credit, pricing, demand. Great features routinely beat fancy algorithms — and often beat more data, too.
You're predicting whether a customer will buy again. You have their raw signup date and the raw date of their last order. Name two engineered features you could derive from those two raw dates that would likely predict repeat purchase far better than the raw dates themselves.
Show answer
- Data becomes a table: rows = examples, features = input clues, label = the answer to predict.
- Feature engineering (deriving better columns, e.g. 'days since last login') is where much real ML skill lives.
- Features set the ceiling — the signal must be in the inputs for any algorithm to find it.
- More features isn't better; informative features are — irrelevant or redundant ones hurt.
The Golden Rule: Train, Validation, Test
There is one discipline that separates real machine learning from self-deception. Break it, and your model will look brilliant and fail in the real world.
A team builds a model that predicts stock movements with 95% accuracy. Champagne is ordered. They deploy it with real money — and it loses steadily. What happened? They had tested the model on the same data it learned from. Of course it scored 95% — it had effectively seen the answers. It was like grading a student on the exact questions they'd studied. The moment it faced genuinely new data, it had no idea. This single mistake — testing on training data — is the most common and most catastrophic error in all of machine learning.
#Why you must hide some data from the model
Remember the goal: generalisation — doing well on new data. But if you only ever measure a model on the data it trained on, you learn nothing about how it handles new cases. You only learn how well it memorised. To get an honest measurement, you must keep some data hidden during training and only reveal it to test the finished model — simulating the new, unseen world.
#The three-way split
So we split the data into three parts before training, like an exam with study material, a mock exam, and the real exam:
| Set | Role | Exam analogy |
|---|---|---|
| Training set (~70%) | The model learns from this — it sees the answers. | The textbook and homework you study |
| Validation set (~15%) | Used to tune the model and pick between options, without touching the test set. | Mock exams to check progress and adjust |
| Test set (~15%) | Touched once, at the very end, to estimate real-world performance. | The final exam — seen only once |
ALL DATA
|------------------------- 70% -----------------|--15%--|--15%--|
| TRAIN (model learns) | VALID | TEST |
^ ^
tune / choose judge once,
models here at the endThe test set is sacred: it must stay locked away until the very end, and you peek at it exactly once. The instant you start tweaking your model to improve its test score, the test set has secretly become training data — and your final number becomes a lie again. The validation set exists precisely so you have something to tweak against without spoiling the test set.
Imagine a driving test where the examiner uses the exact route you practised on a hundred times. Passing proves nothing about driving on real, unfamiliar roads. The whole point of a test is that it's unseen. A machine-learning test set is the unfamiliar route — and peeking at it beforehand defeats its entire purpose.
Misconception: 'A high training accuracy means a good model.' It can mean the opposite — a model that scored 100% on training data may simply have memorised it and will flop on new data. The only number that matters is performance on data the model has never seen. Treat a suspiciously perfect training score as a red flag, not a trophy.
Without hidden data, you can't tell memorisation from genuine learning — and a model that looks perfect can fail completely in production, sometimes expensively.
Split before training: learn on the training set, tune/choose on the validation set, and measure real-world performance once on the locked-away test set.
Every serious ML project — and the reason reputable results report test-set performance, not training scores. (Cross-validation is a refinement of the same principle.)
- Never test a model on the data it trained on — you'd only measure memorisation.
- Split data into training (learn), validation (tune/choose), and test (judge once).
- The test set is sacred: locked away until the end, used a single time.
- High training accuracy ≠ good model; only performance on unseen data counts.
Overfitting and Underfitting: The Central Struggle
Every model walks a tightrope between learning too little and learning too much. Falling off either side ruins it — and balancing on it is the core craft of machine learning.
Two students prepare for an exam. The first barely studies and learns only 'there will be questions about history' — far too vague to answer anything (he underfit). The second memorises every word of last year's exam, including the typos, but never grasps the actual history — so a single reworded question defeats her (she overfit). The student who passes learns the real patterns: enough to handle new questions, not so rigidly that small changes break them. Machine learning models face this exact tightrope, and it has a name: the bias–variance tradeoff.
#Two ways to fail
Underfitting is learning too little — the model is too simple to capture the real pattern, so it does poorly on both the training data and new data. Overfitting is learning too much — the model latches onto the noise and quirks of the training data (the 'typos'), so it does brilliantly on training data and badly on new data. The sweet spot — 'just right' — sits between them.
UNDERFIT (too simple) JUST RIGHT OVERFIT (too complex)
o o o o o o
___________ _ /‾\_/‾\_ /\ /\ /\
o o o o o o o o o V o\/o o
straight line smooth curve wiggly line hitting
misses the pattern follows the trend every point incl. noise
bad on train & new good on new data perfect on train,
terrible on newHere's the deep tension. A model flexible enough to capture complex real patterns is also flexible enough to memorise random noise. A model simple enough to ignore noise may be too simple to catch the real pattern. You can't simply 'add more power' and win — more power risks overfitting; less risks underfitting. Managing this tradeoff is the practical craft of machine learning.
Overfitting is memorising answers; underfitting is barely studying; good learning is understanding. The understander handles new questions because they grasped the pattern, not the specific examples. This is the same memorise-vs-understand theme from Lesson 3.1 — and it's so central that it reappears in every part of this course.
#How we catch and fight it
The train/test split (3.4) is how we detect the problem: a big gap between high training accuracy and low test accuracy is the signature of overfitting; poor scores on both signal underfitting. To fight overfitting, practitioners use more data (harder to memorise a bigger set), simpler models, and regularisation — techniques that gently penalise unnecessary complexity, nudging the model toward smoother, more general rules. (Regularisation reappears with regression in Part 4.)
Misconception: 'A more powerful, complex model is always better.' Often it's worse. Beyond a point, extra complexity just means more capacity to memorise noise — overfitting. The best model is the simplest one that captures the real pattern, a principle so old it has a name: Occam's razor. Power without discipline is a liability.
This tradeoff is why training huge models is subtle. The largest modern models have billions of parameters — enormous capacity to overfit — yet they generalise remarkably well, thanks to vast data and careful regularisation. Why they generalise as well as they do, given their size, is still an active area of research. The tightrope never goes away; it just gets more interesting at scale.
A model that memorises (overfits) or one that's too simple (underfits) both fail on the new data that actually matters — so we must deliberately steer between them.
Underfit = too simple, poor everywhere. Overfit = too complex, learns the noise, fails on new data. We detect the gap with the train/test split and fight overfitting with more data, simpler models, and regularisation.
Every model ever trained. The constant question 'is this overfitting?' shadows all of ML, from a tiny regression to a frontier LLM.
A model scores 99% on its training set but 62% on its test set. (a) Is this overfitting or underfitting? (b) Name two things you could try to fix it. Then: a different model scores 65% on training and 64% on test — what's wrong with that one?
Show answer
- Underfitting = too simple, fails on training and new data. Overfitting = too complex, memorises noise, fails on new data.
- The bias–variance tradeoff: flexibility enough to learn the pattern is also enough to memorise noise — balance is the craft.
- Detect overfitting via the train/test gap; fight it with more data, simpler models, and regularisation.
- The best model is the simplest that captures the real pattern (Occam's razor).
Measuring Success: Why Accuracy Often Lies
'95% accurate' sounds great — until you learn it can describe a completely useless model. Here's how to measure a model honestly.
A hospital proudly unveils an AI that detects a rare cancer with 99% accuracy. Impressive — until a statistician points out that the cancer occurs in just 1% of patients. A model that simply says 'no cancer' to everyone would also be 99% accurate… while catching exactly zero cancers. The headline number was technically true and medically worthless. To measure a model honestly, accuracy alone is not enough — and knowing which number to look at can be a matter of life and death.
#Why accuracy breaks on imbalanced problems
Accuracy is the fraction of predictions that are correct. It works fine when the classes are balanced (roughly equal spam and non-spam). But when one outcome is rare — fraud, disease, churn — accuracy becomes dangerously misleading, because always guessing 'the common case' scores high while being useless. We need numbers that focus on the rare, important cases.
#Precision and recall: two different worries
Two numbers split the question apart, and the difference between them is one of the most useful things in all of applied ML.
- Recall asks: of all the real positives, how many did we catch? High recall = few misses. This matters most when missing a case is catastrophic — a missed cancer, a missed fraud.
- Precision asks: of everything we flagged as positive, how many truly were? High precision = few false alarms. This matters most when a false alarm is costly — wrongly blocking a legitimate customer's card.
Reality
POSITIVE NEGATIVE
+-------------+-------------+
Model POS | True Pos | False Pos | <- precision asks about
| (caught it) | (false alarm)| THIS ROW: of flags,
+-------------+-------------+ how many were real?
NEG | False Neg | True Neg |
| (missed it!)| (correct no)| recall asks about the
+-------------+-------------+ POSITIVE COLUMN: of real
positives, how many caught?There's almost always a tradeoff: flag more cases and you catch more real ones (recall up) but raise more false alarms (precision down); flag fewer and the reverse. Which you favour depends entirely on the cost of the two mistakes. A cancer screen leans toward recall (never miss one — extra false alarms get re-checked). A spam filter leans toward precision (never bin a real email — a little spam getting through is tolerable). The F1 score blends the two into one number when you care about both.
Think of a fishing net. A huge net catches every fish you want (high recall) but also scoops up boots and seaweed (low precision). A tiny, selective net catches only prize fish (high precision) but lets many swim past (low recall). There's no universally 'best' net — only the right net for what it costs you to miss a fish versus haul up a boot.
#For predicting numbers, not categories
When a model predicts a number (a price, a temperature) rather than a category, we measure the size of its errors instead. MAE (mean absolute error) is the average miss in plain units ('off by £12k on average'). RMSE is similar but punishes big misses much harder — useful when occasional large errors are especially bad. R² reports what fraction of the variation the model explains, from 0 (useless) to 1 (perfect).
Misconception: 'Higher accuracy = better model.' Only on balanced problems. On rare-event problems, accuracy is the wrong tool entirely — you must look at precision, recall, F1, or similar. Always ask: what's the base rate, and what does each kind of mistake actually cost? The right metric is the one that mirrors the real-world consequences.
A single careless metric can make a useless model look excellent and hide exactly the failures that matter most — a real danger in medicine, fraud, and safety.
Use metrics that fit the problem: precision (false-alarm cost), recall (miss cost), F1 (both), for classification; MAE/RMSE/R² for numeric predictions — always read against the base rate and the cost of each error.
Every deployed model. Picking the right metric is a core part of framing any ML problem — and getting it wrong has caused real, documented harm.
You're building a model to flag fraudulent transactions, where fraud is ~0.5% of all transactions. Your boss is excited that it's '99.6% accurate'. Explain why that number is nearly meaningless here, and name the metric you'd insist on tracking instead — and why.
Show answer
- Accuracy lies on rare-event problems — always guessing the common case scores high but catches nothing.
- Recall = of real positives, how many caught (miss cost). Precision = of flags, how many right (false-alarm cost). F1 blends them.
- For numeric predictions, use MAE / RMSE / R².
- Choose the metric that mirrors the real cost of each mistake — and always check the base rate.
The Machine Learning Pipeline, End to End
Zoom out from individual ideas to the whole assembly line — the repeatable journey from raw data to a model that keeps working in the real world.
A brilliant model that wins every offline benchmark gets deployed — and quietly rots. Six months later it's making worse decisions than the simple rule it replaced. Nothing 'broke'. The world changed: customer behaviour shifted, new products launched, a pandemic rewrote the patterns. The team had treated the model as a finished product rather than a living system. Building a model is a project; keeping it useful is a process — and that process is the ML pipeline.
#The assembly line, stage by stage
Nearly every real ML project follows the same shape. You'll recognise every stage from this part — now strung together into one flow:
- 1 · Data collection & cleaning. Gather data and fix the mess — missing values, errors, duplicates. Usually the largest chunk of real work; 'garbage in, garbage out' is iron law.
- 2 · Feature engineering. Turn raw data into informative columns (Lesson 3.3) — often where the biggest performance gains hide.
- 3 · Splitting. Carve out train / validation / test before training (Lesson 3.4), so your evaluation stays honest.
- 4 · Training. Fit the model — gradient descent nudging knobs to reduce error (Lesson 2.9).
- 5 · Evaluation. Measure with the right metric for the problem (Lesson 3.6), on the held-out test set.
- 6 · Deployment. Put the model to work making real predictions — where engineering reality (speed, cost, reliability) begins.
- 7 · Monitoring. Watch performance over time and retrain when it decays. The loop never truly ends.
The crucial mental shift: the pipeline is a loop, not a line. The final arrow bends back to the start. Models live in a changing world, so 'done' is temporary. The discipline of monitoring and retraining is what separates a one-off demo from a system businesses can actually rely on for years.
A deployed model is like a garden, not a statue. A statue is finished the day it's unveiled. A garden, left alone, is overtaken by weeds — it needs ongoing tending as the seasons (the data) change. Treating models as statues is why so many 'successful' AI projects quietly stop working a year later.
#The silent killer: drift
Drift is when the real-world data gradually stops resembling the data the model trained on — so its once-accurate patterns slowly go stale. A fraud model trained before a new scam emerges won't recognise it. A demand model trained pre-pandemic mispredicts during one. Drift is usually gradual and invisible until it's done damage, which is exactly why monitoring is a stage in its own right, not an afterthought.
Misconception: 'Once a model is deployed, the project is finished.' Deployment is the middle of the story, not the end. Without monitoring and periodic retraining, every model decays as the world moves on. The teams that win with AI treat it as ongoing infrastructure — the discipline that, in later parts, grows into MLOps and LLMOps (Part 14).
Ad-hoc model-building doesn't survive contact with the real world — data is messy, evaluation gets fudged, and models silently decay. A repeatable pipeline keeps the whole thing honest and durable.
A seven-stage loop: collect & clean → engineer features → split → train → evaluate → deploy → monitor → (retrain). Each stage has a discipline from this part; the loop closes back to the start.
Every production AI system. This shape scales from a spreadsheet model to the infrastructure behind global services — and matures into MLOps/LLMOps in Part 14.
- The ML pipeline is a loop: collect & clean → features → split → train → evaluate → deploy → monitor → retrain.
- Data cleaning and feature work usually dominate the real effort; 'garbage in, garbage out'.
- Deployment is the middle, not the end — models are gardens, not statues.
- Drift (the world changing) silently decays models, which is why monitoring + retraining is its own stage (and grows into MLOps in Part 14).
Linear & Logistic Regression: Drawing the Best Line
The humble straight line is the foundation of machine learning — and its cousin, logistic regression, is still one of the most-used models on Earth.
In 1886, Francis Galton noticed that tall parents tend to have tall children — but slightly less tall than themselves, drifting back toward the average. He drew a line through his data to capture the trend and called the effect 'regression to the mean'. The name stuck, and the tool — fitting a line through data — became the bedrock of statistics and, a century later, of machine learning. Almost every model you'll meet is, in some sense, a fancier version of Galton's line.
Linear regression finds the straight line that best fits a cloud of points, so you can predict a number: given house size, predict price; given ad spend, predict sales. 'Best fit' means the line that makes the total error (the gaps between line and points) as small as possible — found, of course, by gradient descent (Lesson 2.9).
y (price) The line is: | . o y = b0 + b1 * x | o / b0 = where it starts | o / . b1 = its slope (rate) | . o / Predict y for any new x | o / . by reading off the line. +------------------------- x (size)
The line has just two knobs: a starting point (where it crosses zero) and a slope (how fast the output rises per unit of input). That slope is pure gold — it's an interpretable statement like 'each extra £1,000 of ad spend yields ~25 more sign-ups'. Few modern models hand you such a clear, defensible number, which is why regression endures.
Logistic regression is the twist for yes/no questions (will this customer churn? is this email spam?). Instead of an unbounded line, it bends the output through an S-shaped curve that squashes everything into a probability between 0 and 1. Despite the name, it's a classifier, and it's everywhere — credit scoring, medical risk, click prediction — because it's fast, reliable, and explainable.
Linear regression answers 'how much?' (a number on a dial); logistic regression answers 'which one?' (a probability tipping toward yes or no). Same idea — weigh the inputs — but one reads out a quantity and the other a likelihood.
We constantly need to predict a number or a yes/no from some inputs, and explain why — for decisions that must be defensible (loans, pricing, risk).
Fit the best line (linear) or an S-curve (logistic) through the data by minimising error with gradient descent; read predictions straight off it.
Everywhere: pricing, forecasting, credit scoring, medical risk, click-through prediction, and as the baseline every fancier model must beat. Media-mix models in marketing are regularised regressions at heart.
- Linear regression fits the best line to predict a number; its slope is an interpretable 'rate'.
- Logistic regression bends that line into an S-curve to predict a probability (yes/no) — a classifier.
- Both are fast, explainable, and the baseline every other model must beat — still among the most-used models in the world.
Decision Trees: Twenty Questions, Learned
A model that thinks in yes/no questions — readable by any human, and the building block of some of the most powerful tabular models around.
You play '20 Questions': Is it alive? Bigger than a breadbox? Can it fly? Each answer slices the possibilities in half until only one remains. A decision tree is a machine that learns the best questions to ask — and in what order — to reach an answer. Its great gift is transparency: you can read the whole tree like a flowchart and see exactly why it decided what it did.
At each step the tree picks the single question that best separates the data into purer groups — pushing 'approve' cases one way and 'decline' the other. Repeat, and you carve the data into clean regions. Because the result is just a chain of plain if-then questions, a non-technical person can follow — and challenge — every decision.
A decision tree is a medical triage flowchart: Fever? → Cough? → Rash? — each answer routes you down a branch to a recommendation. The tree just learns the best flowchart from data instead of having a doctor write it by hand.
Misconception: 'A single tree is powerful.' On its own, one tree tends to overfit — grow it deep enough and it memorises the training data, branching on noise. Its real power comes from combining many trees (next two lessons), which is where trees become world-class.
We often need decisions that are **accurate and fully explainable** — and that handle messy mixes of numeric and categorical data without much preparation.
Learn the best yes/no questions, in the best order, to split data into ever-purer groups, ending in a prediction at each leaf.
Credit decisions, medical triage, churn, eligibility rules — and as the building block of random forests and gradient boosting, the champions of tabular ML.
- A decision tree learns the best sequence of yes/no questions to reach an answer — readable as a flowchart.
- It splits data into purer and purer groups; its strength is interpretability.
- A single deep tree overfits — the real power comes from ensembles of many trees (next lessons).
Random Forests: The Wisdom of Crowds
Take hundreds of flawed decision trees, let them vote, and — astonishingly — you get one of the most reliable models in machine learning.
At a county fair in 1906, 800 people guessed the weight of an ox. No single guess was exact, but the average of all guesses — 1,197 lbs — was within one pound of the true 1,198. The crowd, as a whole, knew more than almost any individual in it. This 'wisdom of crowds' is the exact principle behind the random forest: combine many imperfect predictors, and their errors cancel out into something remarkably accurate.
A single tree overfits because it latches onto the quirks of its data. A random forest builds hundreds of trees, each on a slightly different random slice of the data and features, so each overfits differently. When they vote, the idiosyncratic mistakes cancel and the shared, real signal survives. Diversity is the secret: you want trees that are good and that err in different ways.
Asking one expert is risky — they have blind spots. Asking a diverse panel of 500 experts and taking the majority view smooths out any single person's quirks. A random forest is that panel: many imperfect trees whose combined verdict beats any one of them.
Single models are either too simple (underfit) or overfit to their data's quirks. We need accuracy and robustness without endless hand-tuning.
Train many diverse decision trees on random subsets of data and features, then average or vote their predictions so individual errors cancel (an 'ensemble').
Fraud, churn, risk scoring, feature-importance analysis — a dependable, low-fuss default for tabular data, and a benchmark serious projects routinely run.
- A random forest combines hundreds of diverse decision trees and lets them vote/average.
- Diversity makes their errors cancel, slashing overfitting (wisdom of crowds).
- A robust, low-fuss default for tabular data — accurate and relatively hard to misuse.
Gradient Boosting: Learning From Your Mistakes
The reigning champion of spreadsheet-style data. The idea is beautifully human: build models one after another, each one fixing the last one's errors.
Imagine a student who, after each practice test, studies only the questions they got wrong, then takes another test and again focuses only on the new mistakes. Round after round, the remaining errors shrink. That relentless, error-focused improvement is exactly how gradient boosting works — and tools built on it (XGBoost, LightGBM) win a huge share of data-science competitions on tabular data, and quietly power countless production systems.
Random forests build trees in parallel and average them. Boosting builds trees in sequence: the first makes rough predictions; the second is trained specifically to correct the first's errors; the third corrects what's still wrong, and so on. Each new tree is small and humble, but stacking hundreds of error-corrections yields stunning accuracy. The cost: because each step chases the residual mistakes, boosting can overfit if pushed too far — so it's tuned carefully.
Forest (parallel): Boosting (sequential): T1 T2 T3 ... -> vote T1 -> errors -> T2 -> errors -> T3 ... independent, averaged each tree fixes the previous one's mistakes reduces VARIANCE reduces BIAS, squeezes out remaining error
Boosting is sculpting: the first chisel strokes rough out the shape (big errors gone), and each subsequent stroke refines what's still off, removing smaller and smaller imperfections until the figure emerges. Many small corrections, applied in sequence, produce a masterpiece.
On structured/tabular data (the spreadsheets businesses run on), we want the highest possible accuracy — and neural networks often lose to boosting here.
Build trees sequentially, each trained to fix the errors of the ensemble so far, gradually driving the remaining error down (gradient descent on the errors themselves).
The go-to winner for tabular data: fraud, credit, ranking, demand forecasting, click prediction. XGBoost and LightGBM are industry staples.
- Gradient boosting builds trees in sequence, each fixing the previous ones' mistakes.
- Stacking many small error-corrections yields top-tier accuracy on tabular data (XGBoost, LightGBM).
- More powerful but more prone to overfitting than forests — so it's tuned with care.
K-Means Clustering: Sorting Without Labels
The classic way to discover natural groups in data when nobody has labelled anything — the workhorse of customer segmentation.
A retailer has a million customers and no idea how to think about them. Nobody has labelled anyone as 'bargain hunter' or 'loyal big spender' — those categories don't exist yet. K-Means clustering finds them automatically: it sifts the customers into natural groups based on how similar their behaviour is, and then a human looks at each group and gives it a name. It's unsupervised learning (Lesson 3.2) at its most useful.
You tell the algorithm how many groups to look for (the 'K'), and it does a simple dance: drop K group-centres at random, assign every point to its nearest centre, move each centre to the middle of its assigned points, and repeat. Within a few rounds, the centres settle over the natural clumps in the data. It's gradient-descent-like in spirit — small repeated improvements until things stop moving.
Before: scattered points After K=3 clustering:
. . . . . [A A] [B B]
. . . . . . -> [A A A] [B B B]
. . . . [C C C C]
no groups yet three natural groups foundIt's organising a wardrobe nobody labelled (the image from Lesson 3.2 made literal). You don't know the 'correct' categories in advance, but you naturally cluster similar items — shirts here, winter coats there. K-Means finds those piles for you; you decide afterward what each pile means.
Misconception: 'The algorithm tells you what the groups mean.' It doesn't — it only finds clumps. You interpret them ('this cluster is high-spend, low-frequency'). And you must choose K yourself; pick badly and you'll split natural groups or merge distinct ones.
Often we have no labels but suspect hidden structure — natural segments, types, or patterns — that could guide strategy if only we could see them.
Place K centres, assign each point to its nearest centre, move centres to the middle of their points, and repeat until stable — revealing natural clusters.
Customer segmentation, market research, image compression, anomaly grouping — the default first tool for 'find the natural groups in this data'.
- K-Means finds natural groups in unlabelled data (unsupervised).
- It iterates: assign points to nearest centre → move centres → repeat, until clusters stabilise.
- You choose K and interpret the groups — the algorithm only finds the clumps. The classic tool for segmentation.
K-Nearest Neighbours: You Are Your Neighbours
Perhaps the most intuitive algorithm of all: to predict something new, just look at the most similar examples you've already seen.
You move to a new city and want to know if a neighbourhood is right for you. The simplest approach? Look at the nearest houses — who lives there, what they're like — and assume you'll fit in similarly. K-Nearest Neighbours (KNN) does exactly this: to classify a new point, it finds the K most similar examples in the data and takes their majority vote. No training, no equations — just 'what are the closest examples, and what were they?'
KNN leans entirely on the embedding idea from Lesson 2.8: similar things sit close together in space. To predict a new case, measure its distance to all known cases, grab the K nearest, and let them vote. It's 'lazy' — it does no upfront learning, just stores the data and searches at prediction time. Beautifully simple, but slow on huge datasets and reliant on a sensible notion of 'distance'.
o = type A x = type X ? = new point
o o With K=3, the new point's
o o x 3 nearest neighbours are
? x x -> 2 x's and 1 o -> predict X
o x x "you are the company you keep"
KNN is judging a restaurant by its three nearest neighbours on the street — if they're all great, this one probably is too. The prediction for something new is simply the consensus of the most similar things you already know about.
Sometimes the simplest, most transparent rule is best: 'this new case resembles those known cases, so treat it the same.' No model assumptions, no training.
Store all examples; for a new point, find the K nearest by distance and take their majority vote (or average). Relies on a good similarity/distance measure.
Recommendation ('similar users liked…'), simple classification, filling in missing values, and as an intuitive baseline. Its 'nearest in embedding space' idea underpins modern semantic search.
- KNN predicts a new case from the majority vote of its K most similar known examples.
- It's 'lazy' — no upfront training; it searches for neighbours at prediction time.
- Relies on a good distance/similarity measure (the embedding idea) — the intuition behind modern semantic search.
PCA & SVM: Compressing and Separating
Two more classics worth knowing: one shrinks data without losing its essence, the other finds the cleanest possible dividing line.
#PCA: keeping the essence, dropping the bulk
A photograph has millions of pixels, but you can shrink it to a fraction of the size and still recognise everything in it — because most of those pixels are redundant, repeating their neighbours. Principal Component Analysis (PCA) does this for data: it finds the few underlying 'directions' that carry most of the information and discards the redundant rest, compressing many columns into a few without losing the story.
PCA is compressing a photograph (the requested image, made literal). A JPEG throws away redundant detail you'd never miss, keeping the essence at a fraction of the size. PCA throws away redundant dimensions — combining correlated columns into a handful of 'principal components' that capture most of the variation.
PCA is used to visualise high-dimensional data in 2-D, to speed up other models by feeding them fewer inputs, and to tame redundant, highly-correlated features (the multicollinearity problem from Part 3) — a reason it appears in marketing-mix and other regression workflows.
#SVM: the widest possible street
To separate two groups of points, you could draw many possible dividing lines. Which is best? A Support Vector Machine (SVM) picks the line with the widest margin — the one that stays as far as possible from the nearest points of either group, leaving the biggest 'safety buffer'. A confident, well-cushioned boundary generalises better than one drawn right up against the data.
o o o |<-- margin -->| x x x
o o o o o | (widest | x x x x
o o o | street) | x x x
^ SVM picks the boundary with the
biggest gap to the nearest pointsOnly the points closest to the boundary — the 'support vectors' — actually matter; the rest could move freely without changing the line. With a clever trick (the 'kernel'), SVMs can also draw curved boundaries, separating groups that no straight line could. Before deep learning, SVMs were often the strongest classifiers around.
PCA: too many redundant features slow models and obscure structure. SVM: among many possible boundaries, we want the most robust one.
PCA finds the directions of greatest variation and keeps only those (compression). SVM finds the separating boundary with the maximum margin to the nearest points.
PCA → visualisation, speed-ups, de-correlating features. SVM → text and image classification, bioinformatics; a strong classic classifier, especially on smaller datasets.
- PCA compresses many redundant features into a few 'principal components' that keep most of the information — like a JPEG for data.
- SVM separates classes with the widest-margin boundary; only the nearest points (support vectors) matter, and kernels allow curved boundaries.
- PCA → visualisation, speed, de-correlation. SVM → a strong classic classifier, especially on smaller datasets.
The Artificial Neuron: A Tiny Voting Machine
The entire edifice of deep learning rests on one humble unit. Understand this one thing and the rest is just repetition.
In 1943 — before modern computers even existed — a neuroscientist and a logician sketched a wildly simplified cartoon of a brain cell: something that gathers signals from others, and 'fires' if the combined signal is strong enough. It was a crude caricature of real biology, but it turned out to be a profoundly useful idea. Stack enough of these cartoon neurons and you get systems that recognise faces, translate languages, and write essays.
Picture a committee deciding whether to approve a project. Each member has an opinion (an input) and a different level of influence (a weight). The chair tallies the weighted opinions; if the total clears a threshold, the project is approved (the neuron 'fires'); if not, it's rejected. An artificial neuron is exactly this: a tiny weighted vote that outputs 'fire' or 'don't' — and the weights are what it learns.
inputs weights x1 -------( w1 )\ x2 -------( w2 )--> [ sum them up ] -> [ activation ] -> output x3 -------( w3 )/ (+ a bias) (fire?) Each input is scaled by its weight, summed, and passed through an on/off-ish function. Learning = tuning the weights.
A single neuron does three trivial things: multiply each input by a learned weight (its importance), add them up (plus a bias that shifts the threshold), and pass the total through an activation function that decides the output. That's it. A lone neuron is barely more than the logistic regression of Part 4 — its magic only appears when you connect millions of them.
We needed a simple, repeatable learning unit that could be wired together into something far more powerful than any single rule — a building block, not a finished model.
Each neuron weighs its inputs, sums them, and fires through an activation function; the weights are learned by gradient descent. Power comes from connecting many.
Every neural network — vision, speech, language, generation — is built from billions of these units. This is the literal atom of deep learning.
- An artificial neuron weighs its inputs, sums them, and fires through an activation function — a tiny weighted vote.
- What it learns are the weights (input importances), via gradient descent.
- A single neuron is weak (≈ logistic regression); the power comes from connecting millions of them.
Layers and Depth: Why 'Deep' Learning Works
Stacking neurons into layers is what turns a trivial voting unit into a system that can recognise a cat. Here's the magic of depth.
When researchers peered inside trained image networks, they found something beautiful. The first layer's neurons had learned to detect tiny edges and colour patches. The next layer combined those edges into corners and textures. Deeper layers assembled textures into parts — an eye, a wheel — and the final layers assembled parts into whole objects. Nobody programmed this hierarchy; it emerged from training. Depth had discovered how to see, one level of abstraction at a time.
Each layer builds on the one before, transforming simple features into more abstract ones. Early layers see primitives; later layers see concepts. This is representation learning — the network discovers, by itself, the right features at each level, which is exactly the hand-crafted feature-engineering job (Part 3) that humans used to do manually. Depth automates the search for good features.
It's an assembly line of specialists (the image from Part 1, now precise): the first worker only spots edges, the next assembles them into shapes, the next into parts, the last into a verdict. Each worker is simple; the sequence produces sophistication. 'Deep' just means a long assembly line — many layers.
Misconception: 'Deeper is always better.' Up to a point depth helps, but very deep networks are hard to train (signals fade or explode as they pass through many layers) and hungry for data and compute. Architectural innovations (and a lot of engineering) were needed to make great depth trainable at all — the difference between the idea (1980s) and the breakthrough (2012).
A single layer can only learn simple patterns. Real-world data (images, language) has layered structure — and we needed models that learn features automatically rather than by hand.
Stack layers so each transforms the previous layer's features into more abstract ones — primitives → parts → concepts — learning the right representation at every level.
All of deep learning: vision (edges→objects), language (letters→words→meaning), audio, and the Transformers behind LLMs. Depth = automatic feature discovery.
- Layers stack so each transforms the previous layer's features into more abstract ones (edges → parts → objects).
- This is representation learning — the network discovers useful features by itself, automating feature engineering.
- Deeper isn't automatically better — great depth is powerful but hard to train and data-hungry, which is why it took until ~2012 to work.
Activation Functions: The Spark of Non-Linearity
One small ingredient is what separates a deep network from an expensive straight line. Without it, depth is pointless.
Here's a sobering fact that nearly sank neural networks: if every neuron just did weighted sums, stacking a hundred layers would collapse — mathematically — into a single layer. A hundred straight lines chained together is still just a straight line. All that depth would buy you nothing beyond plain regression. The fix is a small non-linear 'kink' inside each neuron called an activation function — and it's the reason deep learning can learn curves, not just lines.
After summing its inputs, a neuron passes the total through an activation — a simple non-linear function. The most common, ReLU, is almost comically simple: if the total is negative, output zero; otherwise pass it through. That tiny 'bend' is enough. Sprinkle these bends throughout the network and it can suddenly model curved, complex, wiggly relationships — the kind real data actually has.
Without activation: With activation (ReLU):
layers collapse to a line output | /
y = (just a straight line) | /
-> no more powerful than | /
plain regression _____|/______ input
(flat, then rises: a 'bend')
The bend is what lets the network learn curves.Without activations, a deep network is like a row of mirrors reflecting a straight beam — the beam stays straight no matter how many mirrors. Activations are like lenses that bend the beam: now you can steer light into any shape. The bends are where the expressive power lives.
Stacked linear layers collapse into one line, wasting all that depth. We needed each neuron to add a non-linear twist so the network could learn complex, curved relationships.
Pass each neuron's summed input through a non-linear activation (e.g. ReLU: zero out negatives, pass positives). These 'bends', repeated, let the network model any shape.
Inside every neuron of every neural network. Without activations, deep learning would be no more powerful than regression — they're the spark that makes depth matter.
- Without activation functions, stacked layers collapse into a single line — depth becomes useless.
- An activation adds a non-linear 'bend' (e.g. ReLU: zero out negatives) at each neuron.
- These bends let the network learn curved, complex relationships — the spark that makes depth powerful.
How Networks Learn: Loss and Backpropagation
Millions of weights, all needing adjustment — how does a network figure out which knob to turn, and by how much? The answer is one of the most elegant ideas in computing.
A football team loses a match. To improve, they need to know who contributed to the loss and how much — the striker who missed, the defender out of position, the midfielder who lost the ball. Assigning blame fairly, then having each player adjust, is how the team improves. A neural network with millions of weights faces the same problem after every wrong prediction: which weights were to blame, and how should each change? The algorithm that answers this is backpropagation.
Learning happens in a loop. (1) A forward pass: data flows through the network to a prediction. (2) A loss function measures how wrong that prediction was — one number capturing the error. (3) Backpropagation works backwards through the layers, using calculus's chain rule to compute exactly how much each weight contributed to the error. (4) Gradient descent (Lesson 2.9) nudges every weight a little in the direction that reduces the error. Repeat millions of times, and the network learns.
Backpropagation is blame assignment flowing backwards. The error at the output is traced back layer by layer — 'you caused 3% of this mistake, you caused 0.1%' — so each weight knows precisely how to adjust. It's the team review after the match, distributing responsibility fairly all the way down the lineup.
Misconception: 'Backprop is some mysterious AI magic.' It's 'just' the chain rule from calculus — a systematic way to compute how a tiny change in each weight affects the final error. Old and unglamorous, it's nonetheless the algorithm that makes training deep networks possible, and its practicality at scale (with GPUs) is what unlocked 2012.
A network has millions of weights and one error signal — we need a way to figure out how every weight should change to reduce that error, efficiently.
Forward pass → measure loss → backpropagate (chain rule assigns blame to each weight) → gradient descent nudges each weight downhill. Repeat until error is low.
The training procedure for every neural network ever built — vision, language, generation. Backprop + gradient descent is the universal learning engine of deep learning.
- Training loops: forward pass → loss (how wrong) → backpropagation (blame each weight) → gradient descent (nudge).
- Backpropagation = the chain rule, assigning each weight its share of the error so it can be adjusted.
- Repeated millions of times, this is how every neural network learns — the universal training engine.
Epochs, Batches, and Learning Rates: The Dials of Training
The practical knobs that decide whether training succeeds, fails, or takes a month. A short, demystifying tour.
Training a network means showing it the data many times and nudging weights along the way. Three terms describe how: an epoch is one full pass through all the training data; a batch is the small chunk of examples processed at a time (because the whole dataset rarely fits in memory at once, and small chunks make learning more stable); and the learning rate is how big each weight-nudge is — the single most important dial in all of training.
Think of studying for an exam. An epoch is reading the whole textbook once (you'll do several passes). A batch is studying one chapter at a time rather than the entire book in one sitting. The learning rate is how dramatically you revise your beliefs after each chapter — overreact to every chapter (too high) and your understanding lurches around wildly; barely update (too low) and you'll need forever to learn anything.
learning rate too HIGH: learning rate just RIGHT: too LOW:
bounces across the valley steps smoothly downhill crawls,
o o o o o o o o o o
\ / \ / \ (never settles) \ (very slow)
v v \_o_ -> reaches bottomMisconception: 'More epochs always means a better model.' Past a point, extra epochs make the network start memorising the training data — overfitting (Part 3) creeps back in. Practitioners watch validation performance and stop when it stops improving ('early stopping'). More training is not automatically more learning.
Training is iterative, and how you iterate hugely affects success — a bad learning rate alone can make a perfectly good model fail to learn at all.
Process data in batches, loop over the full set for several epochs, and update weights by a step sized by the learning rate — tuned to descend the error landscape without overshooting or crawling.
Every neural-network training run. These 'hyperparameters' are set before training and tuned on the validation set; getting them right is a core practical skill.
- An epoch = one full pass through the data; a batch = a small chunk processed at a time.
- The learning rate = the size of each weight update — the most important training dial (too high overshoots, too low crawls).
- More epochs isn't always better — too many cause overfitting; watch validation and use early stopping.
Why Images Break Ordinary Networks
Before the solution, feel the problem: why you can't just throw a photo at a normal neural network and hope.
To a computer, a photo isn't a scene — it's a giant grid of numbers, one per pixel for brightness and colour. A modest phone photo has millions of these numbers. Feed them all into an ordinary neural network where every pixel connects to every neuron, and you get billions of weights to learn from your first image alone — hopelessly many. Worse, the network would learn that a cat in the top-left is a totally different thing from the same cat in the bottom-right. Something smarter was needed.
Two problems sink the naive approach. Scale: connecting every pixel to every neuron explodes the number of weights beyond what any data could train. Position-blindness needed: a cat is a cat wherever it appears, but a plain network has to re-learn 'cat' separately for every location. The fix must (a) drastically cut connections and (b) recognise patterns regardless of where they appear.
Imagine trying to understand a painting by memorising the exact colour of every single dot, in every position, independently. You'd drown in detail and never grasp that 'an eye is an eye' wherever it sits. Humans don't see that way — we spot local patterns (edges, shapes) and recognise them anywhere on the canvas. CNNs are built to do the same.
Images are huge grids of numbers with meaningful local structure and movable objects — properties that overwhelm and confuse ordinary fully-connected networks.
We need an architecture that shares pattern-detectors across the whole image (so far fewer weights) and recognises features wherever they appear — the job of convolution (next lesson).
All of computer vision: photo tagging, medical imaging, self-driving perception, quality inspection, face recognition — every task starts with this challenge.
- To a computer an image is a grid of pixel numbers — millions of them.
- Ordinary networks need too many weights and must re-learn objects per position — both fatal.
- Vision needs shared, position-tolerant pattern detectors — the motivation for convolution.
Convolution: A Sliding Magnifying Glass
The one idea that made machine vision work: small detectors that slide across the image, finding patterns wherever they hide.
Instead of staring at the whole image at once, imagine sliding a small magnifying glass across it, looking for one specific pattern — say, a vertical edge — and noting everywhere you find it. Then do it again with a different glass for horizontal edges, another for a patch of colour, and so on. This 'slide a small detector everywhere' operation is called convolution, and it is the heart of the CNN.
Each detector is a tiny grid of weights called a filter (or kernel). It slides across the image, and at each spot it measures how strongly that local patch matches its pattern. The output is a feature map: a new image highlighting where that pattern was found. Crucially, the same filter is reused across the whole image — so the network learns 'vertical edge' once and finds it everywhere, solving both problems from the last lesson (few weights, position-tolerant).
Image: Filter (edge detector) slides across: . . | . . [ slide the 3x3 filter over every patch ] . . | . . -> produces a FEATURE MAP highlighting . . | . . where the pattern (the vertical edge | ) . . | . . appears in the image. One filter, reused everywhere -> few weights, finds pattern anywhere.
A filter is a rubber stamp tester pressed across the whole page: wherever the page matches the stamp's shape, it lights up. The network learns a whole set of stamps — edges, curves, textures — and early layers stamp simple patterns while deeper layers stamp combinations of them (recall the edges→parts→objects hierarchy of Part 5).
We needed pattern-detectors that use few weights and find features anywhere in an image — neither possible with fully-connected layers.
A small filter slides across the image (convolution), reused everywhere, producing a feature map of where its pattern occurs; many filters detect many patterns, stacked into a deep hierarchy.
Every image task: object detection, medical scans, face recognition, self-driving vision — and convolution-style ideas appear in audio and even some text models.
- Convolution slides small filters across the image, producing feature maps of where each pattern appears.
- The same filter is reused everywhere — few weights, and patterns are detected at any position.
- Stacked filters learn a hierarchy (edges → textures → parts → objects) — the engine of computer vision.
Pooling and the Full Picture
The finishing touches that let a CNN zoom out, ignore tiny shifts, and assemble simple patterns into a confident answer.
After convolution highlights patterns, pooling shrinks the feature maps by keeping only the strongest signal in each small region — a deliberate 'zoom out'. This does two useful things: it makes the network tolerant to small shifts (a cat nudged a few pixels still registers), and it cuts the data down so deeper layers can focus on bigger structures. Convolution finds detail; pooling steps back to see the forest for the trees.
Pooling is stepping back from a painting. Up close you see brushstrokes (fine detail); step back and you see the subject. By alternating convolution (look closely) and pooling (step back), a CNN moves from pixels → edges → parts → whole objects, exactly mirroring how depth builds abstraction (Part 5).
This convolution-and-pooling stack powered a decade of breakthroughs: photo tagging, medical imaging (spotting tumours often at expert level), self-driving perception (reading lanes, signs, pedestrians), face unlock, document scanning, and industrial quality inspection. CNNs were the workhorse of vision — and remain central even as newer Transformer-based vision models emerge.
Networks must tolerate small shifts and manage the flood of pixel data while building from fine detail up to whole objects.
Alternate convolution (detect local patterns) with pooling (zoom out, keep the strongest signals), stacking until the network combines simple features into a confident object-level answer.
The architecture behind modern computer vision — medical imaging, self-driving, face recognition, inspection — and a template now partly shared with vision Transformers.
- Pooling shrinks feature maps (keeps the strongest signals) — a 'zoom out' that adds shift-tolerance and efficiency.
- Alternating convolution + pooling builds from edges → parts → objects.
- This CNN stack powered a decade of vision: medical imaging, self-driving, face recognition, inspection.
The Problem of Order and Memory
Why sentences and time-series need a fundamentally different kind of network from images.
'Dog bites man' and 'Man bites dog' use identical words — only the order differs, and it changes everything. Now consider: 'I grew up in France, so I speak fluent ___.' To fill the blank you must remember 'France' from the start of the sentence. Sequences carry meaning in their order and demand memory of what came before. A CNN, brilliant at static images, has neither — so language needed its own kind of network.
A sequence is data where order matters and earlier items influence later ones: words in a sentence, days in a sales history, notes in a melody. To process them, a model needs two things ordinary and convolutional networks lack: an awareness of sequence (position) and a memory that carries relevant context forward as it reads.
Reading a sentence is like following a story: you carry a running understanding that updates with each new word, and the ending only makes sense because you remember the beginning. A model that forgets the start of the sentence by the time it reaches the end can't understand language — exactly the challenge the next lessons tackle.
Order and long-range context carry meaning in language, time-series, and audio — but image-style models treat inputs as orderless and memoryless.
We need architectures that process items in sequence while maintaining a running memory of relevant earlier context — leading to RNNs, then the breakthrough of attention.
Language, translation, speech, music, forecasting, and any time-ordered data — the entire domain that culminates in LLMs.
- Sequences (text, time-series, audio) encode meaning in order and require memory of earlier context.
- Image-style networks are orderless and memoryless — unsuitable for language.
- This motivates RNNs/LSTMs and, ultimately, the attention mechanism behind Transformers.
RNNs and LSTMs: Memory, and Its Limits
The first networks with memory — how they worked, why they forgot, and the clever upgrade that bought them more time before Transformers took over.
A Recurrent Neural Network (RNN) reads a sequence one item at a time, maintaining a hidden state — a running memory — that it updates with each new word and carries forward. In principle, this lets context from early words influence later ones. In practice, RNNs suffer from short memory: by the time they've read a long sentence, the influence of the first words has faded almost to nothing (the 'vanishing gradient' problem). They remember the recent past well and the distant past poorly.
word1 -> [RNN] -> word2 -> [RNN] -> word3 -> [RNN] -> ...
| carries a running 'memory' forward |
Problem: by word 50, the memory of word 1 has faded.
LSTM adds 'gates' that decide what to KEEP, FORGET, and ADD,
protecting important long-range information for longer.An RNN is like listening to a long story while only able to hold the last few sentences in mind — you lose the thread of how it began. An LSTM (Long Short-Term Memory) is like having a notepad alongside: gates decide what's important enough to jot down and keep, what to cross out, and what to add — so key facts from the start survive to the end.
Misconception: 'LSTMs solved memory for good.' They helped a lot and powered translation and speech for years — but they still read strictly one-step-at-a-time (slow, hard to parallelise) and still strained on very long-range links. Both limits were swept away by attention (Part 8), which lets every word reach every other word directly and in parallel. RNNs/LSTMs are now mostly historical for language, though still useful for some time-series.
Sequences need memory, but a simple running memory fades over distance — long-range dependencies (the 'France…French' link) kept slipping away.
RNNs carry a hidden-state memory updated each step; LSTMs add gates (keep / forget / add) to protect important information across longer spans.
Historically the backbone of translation, speech recognition, and text generation; today largely replaced by Transformers for language, with niche time-series use remaining.
- An RNN reads a sequence step-by-step, carrying a running memory (hidden state) — but it fades over distance.
- An LSTM adds gates (keep/forget/add) to preserve important long-range information longer.
- Both read one step at a time and still strain on long contexts — limits that attention (Part 8) removed, making them largely historical for language.
The Breakthrough That Changed Everything
A recap and a promise: why a single 2017 idea reorganised the entire field, and what we're about to unpack.
We met the Transformer in Part 1 as the hinge of history. Now we earn it. In 2017, 'Attention Is All You Need' made a radical claim hiding in its title: you don't need the step-by-step memory machinery of RNNs at all. You just need attention — a mechanism that lets every word look at every other word, all at once. That single move fixed the two great weaknesses of older models — fading long-range memory and slow sequential processing — in one stroke. Everything from ChatGPT to image generators descends from it.
Two superpowers, worth restating because the rest of this part elaborates them. Parallelism: attention looks at all words simultaneously rather than one-at-a-time, so it trains efficiently on GPUs at enormous scale. No memory decay: any word can directly connect to any other, however far apart, so long-range meaning is never lost. Parallel + no-decay = an architecture that keeps getting better the more you scale it — the property that launched the modern era.
An RNN reads a sentence through a drinking straw, one word at a time, struggling to remember the start. A Transformer lays the whole sentence on a table and lets every word freely compare itself to every other, simultaneously. That shift — from a straw to a table — is the essence of the revolution.
Older sequence models were slow (sequential) and forgetful (fading memory) — a ceiling on how capable and large language models could become.
Replace step-by-step recurrence with attention: every position attends to every other, in parallel, with no distance penalty — unlocking massive scale.
Nearly all modern AI: every major LLM (GPT, Claude, Gemini), plus vision, audio, and multimodal models. The Transformer is the shared foundation of the field today.
- The Transformer (2017) replaced step-by-step recurrence with attention — every word sees every other word at once.
- This gives parallel training (scales on GPUs) and no long-range memory loss simultaneously.
- It's the shared foundation of nearly all modern AI — LLMs, vision, audio, multimodal.
Attention: Reading With a Highlighter
The single most important mechanism in modern AI, built entirely from one everyday intuition.
Read this: 'The trophy didn't fit in the suitcase because it was too big.' What does 'it' mean? You answered 'the trophy' instantly — and you did it by glancing back across the sentence, weighing which words were relevant to 'it', and settling on the trophy. Swap one word — 'because it was too small' — and suddenly 'it' means the suitcase. You re-weighed the context automatically. That act of weighing relevance is attention, and it's the whole idea.
For every word it processes, an attention mechanism asks: which other words should I pay attention to, and how much? It assigns each other word a relevance weight, then blends their information accordingly — paying lots of attention to the relevant words and little to the rest. To understand 'it', the model puts high weight on 'trophy' and 'suitcase' and near-zero on 'because'. Meaning emerges from these weighted relationships, computed for every word against every other.
Processing the word "it":
The trophy didn't ... suitcase because it was big
. HIGH . HIGH . (me) . .
attention weights: 'it' attends strongly to 'trophy' & 'suitcase',
weakly to the rest -> resolves what 'it' refers to.Attention is reading with a highlighter and the whole page visible. To understand any word, you highlight the few others that matter most and blend their meaning in. Do this for every word, weighing its relationship to all the others, and you've understood the sentence the way a Transformer does.
Understanding language requires linking each word to the right other words, often far away ('it' ↔ 'trophy') — the exact thing older models lost over distance.
For each word, compute a relevance weight to every other word, then blend their information by those weights — focusing on what matters, ignoring what doesn't.
Inside every Transformer and LLM. Attention is how these models resolve references, track topics, follow grammar, and hold a long context together.
- Attention = for each word, weigh how relevant every other word is, then blend their meaning by those weights.
- It's the everyday act of reading with a highlighter — focus on what matters, with the whole context visible.
- This mechanism is what lets Transformers resolve references and hold long context — the heart of every LLM.
Queries, Keys, and Values: The Library Analogy
How attention is actually computed — explained through searching a library, no equations required.
To compute attention, each word produces three vectors (Lesson 2.8). A Query ('what am I looking for?'), a Key ('what do I offer?'), and a Value ('the information I'll hand over if chosen'). A word's Query is compared against every other word's Key to get relevance scores; those scores decide how much of each word's Value gets blended into the result. Query-meets-Key produces the attention weights; the weights pull in the Values.
Picture a library search. Your Query is what you type into the catalogue ('books about volcanoes'). Each book has a Key — its catalogue tags — and your query is matched against all of them. The books whose Keys match best are pulled, and you receive their Value — the actual content. Attention is this search, run for every word at once: each word queries all the others, matches on Keys, and collects Values from the best matches.
word "it" --Query--> compared against every word's --Key-->
produces match scores (relevance weights)
-> blend each word's --Value--> weighted by its score
Query = what I seek Key = what I offer Value = info I giveMisconception: 'Queries, Keys, and Values are looked up in a database.' They're not fixed entries — they're vectors the model computes for each word, learned during training. The 'library' is a vivid metaphor for the math of matching and retrieving by relevance, all done with the vectors and distances from Lesson 2.8.
Attention needs a concrete way to decide how much each word should draw from each other word — a mechanism for relevance-based retrieval.
Each word emits a Query, Key, and Value; Query·Key sets the attention weights, which blend the Values — a learned, soft 'search and retrieve' over the whole sequence.
The computational core of every attention layer in every Transformer — the precise machinery beneath the highlighter intuition of the previous lesson.
- Each word computes a Query (what I seek), Key (what I offer), and Value (info I give).
- Query matched against Keys sets the attention weights; the weights blend the Values.
- It's a learned, soft 'library search' over the whole sequence — the math beneath the highlighter intuition.
Self-Attention and Many Heads
Two refinements that turn basic attention into the powerhouse inside real Transformers.
Self-attention simply means the words attend to each other within the same sentence (rather than to some separate text) — every word querying every other word in its own context. That's what builds a rich, context-aware understanding of a passage. Multi-head attention then runs several attention computations in parallel, each a separate 'head' free to focus on a different kind of relationship — one head might track grammar, another track which noun a pronoun refers to, another track topic.
Imagine several expert readers each going through the same sentence with a different concern: a grammarian watches sentence structure, an editor tracks who 'it' and 'they' refer to, a topic-spotter follows the theme. Each highlights different words. Combine all their notes and you get a far richer understanding than any single reader. Multi-head attention is that panel of specialist readers, run in parallel.
Multi-head attention on one sentence: Head 1: tracks grammar -> \ Head 2: tracks references -> } combine -> rich understanding Head 3: tracks topic -> / Each head attends to different words for a different reason.
Misconception: 'Each head is hand-assigned a job like grammar.' No — the heads learn what to specialise in during training; researchers only discover their roles afterward by inspection, and the division is messy, not tidy. The design simply allows multiple relationship-types to be tracked at once; training decides how.
A single attention pass can only emphasise one kind of relationship at a time, but language weaves many together (grammar, reference, topic) simultaneously.
Self-attention has every word attend to every other in the same context; multi-head runs several such passes in parallel, each learning to focus on a different relationship, then combines them.
The core layer of every Transformer. Stacks of multi-head self-attention (plus simple processing layers) are what an LLM is, repeated dozens of times.
- Self-attention: every word attends to every other word in the same context, building context-aware meaning.
- Multi-head attention: several attention passes in parallel, each learning a different relationship, then combined.
- Stacks of multi-head self-attention are the Transformer — repeated dozens of times in an LLM.
Positional Encoding and the Full Block
Two final pieces: how a model that looks at all words at once still knows their order, and how everything assembles into the block that builds an LLM.
Attention has a curious blind spot. Because it looks at all words simultaneously, it has no inherent sense of order — to raw attention, 'dog bites man' and 'man bites dog' look like the same bag of words. But order is meaning. The fix is elegant: before the words enter, the model adds a positional signal to each one — a kind of 'you are word #3' stamp — so order information rides along even though processing is parallel.
Positional encoding injects each word's position into its representation, restoring the order that parallel attention would otherwise ignore. With that in place, a full Transformer block is just: multi-head self-attention (mix information across words) → a small feed-forward network (process each word's enriched representation) → repeat. Stack dozens of these blocks, feed in word embeddings (Lesson 2.8) plus positions, and you have the skeleton of a Large Language Model.
Positional encoding is like numbering the seats before a meeting where everyone speaks at once. Even though all voices are heard simultaneously (parallel attention), the seat numbers preserve who's where, so order isn't lost. Without the numbers, the conversation would be an orderless jumble.
Parallel attention is order-blind, but word order carries meaning — so order must be restored without giving up parallelism.
Add positional encodings to the word embeddings; then a Transformer block = multi-head self-attention + feed-forward, stacked many times, to produce deep contextual understanding.
The complete architecture behind every LLM — and, with minor variations, behind vision and multimodal Transformers too. You now know how the engine is built.
- Parallel attention is order-blind, so positional encoding stamps each word with its position.
- A Transformer block = multi-head self-attention + a feed-forward network, stacked dozens of times.
- Embeddings + positions + stacked blocks = the architecture of every LLM. You now understand the engine.
Tokens: How Models Read
Before an LLM can think about language, it has to chop text into pieces it can handle. Those pieces — tokens — quietly shape everything the model does.
You might assume a language model reads word by word, like we do. It doesn't quite. It breaks text into tokens — chunks that are often whole words, but sometimes word-fragments. 'Cat' is one token; 'unbelievable' might split into 'un', 'believ', 'able'. This sounds like a technical detail, but it explains a surprising amount: why models sometimes miscount letters, why they handle rare words gracefully, and why you're billed per token when using AI tools.
Tokenisation balances two needs. Use whole words and your vocabulary becomes impossibly huge (every plural, typo, and name). Use single letters and sequences become impossibly long. Subword tokens are the compromise: common words stay whole, rare ones split into reusable fragments — so the model can spell out a word it's never seen from familiar pieces. Each token is then turned into an embedding (Lesson 2.8) before the Transformer touches it.
"Understanding tokenization isn't hard"
| | | |
[Under][standing] [token][ization] [isn't] [hard]
common words -> whole tokens; rare words -> split into pieces
each token then becomes an embedding the model can process.Misconception: 'The model sees letters like we do.' It sees tokens, not characters — which is exactly why a model can sometimes fumble 'how many r's in strawberry': the word is a couple of tokens, not a string of letters it counts. Knowing this demystifies a whole class of odd AI behaviour.
Models work with numbers, not raw text, and need a unit small enough to handle any word yet large enough to keep sequences manageable.
Subword tokenisation splits text into common-whole / rare-fragmented chunks; each token becomes an embedding fed into the Transformer.
Every LLM interaction. Tokens determine context limits, pricing, and several quirks — counting letters, handling rare names, and multilingual behaviour.
- LLMs read tokens (often whole words, sometimes fragments), not letters.
- Subword tokenisation balances vocabulary size against sequence length and handles rare words.
- Tokens explain context limits, pricing, and quirks like miscounting letters in a word.
Pretraining: Learning Language by Prediction
The astonishing core of every LLM: it learned essentially everything it knows by playing one simple game — guess the next token — trillions of times.
How do you teach a machine to write, reason, translate, and code — without labelling any of it by hand? You don't. You make it play fill-in-the-blank on the entire internet. Show it 'The capital of France is ___' and have it predict 'Paris'. Do this trillions of times across books, articles, and code, and something remarkable happens: to get good at predicting the next word, the model is forced to absorb grammar, facts, reasoning patterns, and style. Prediction, at enormous scale, becomes understanding-like behaviour.
This is self-supervised learning (Lesson 3.2) at planetary scale. The 'label' for each example is just the actual next token in the text — free, no humans needed — which is why training can consume a huge fraction of the written internet. This phase, pretraining, is where the model's raw knowledge and language ability come from. It produces a 'base model': fluent and knowledgeable, but not yet a helpful, instruction-following assistant.
Pretraining game, trillions of times:
"The Eiffel Tower is in ___" -> predict: "Paris"
"for i in range(10): print(___" -> predict: "i"
"Water boils at 100 degrees ___" -> predict: "Celsius"
To predict well, the model must absorb grammar, facts, reasoning.It's like someone who read an entire library and constantly tried to guess each next word before turning to it. To play that game well across millions of books, they'd have to internalise how language works, what facts tend to follow what, and how arguments are structured. The base LLM is that voracious reader — vast knowledge, but no manners yet.
Misconception: 'The model looks up facts in a stored database.' It doesn't — it has no built-in database. Its 'knowledge' is baked into billions of weights as statistical patterns, which is precisely why it can be confidently wrong (hallucinate, Part 14) and why grounding it in real documents (RAG, Part 11) matters so much.
We needed to give models broad knowledge and language ability without hand-labelling — impossible at internet scale by any other means.
Self-supervised next-token prediction over enormous text: the next word is its own free label, forcing the model to learn grammar, facts, and reasoning into its weights.
The foundation phase of every LLM. It yields a knowledgeable 'base model' that later stages (next lesson) refine into a helpful assistant.
- Pretraining = predicting the next token across vast text, trillions of times (self-supervised — labels are free).
- To predict well, the model must absorb grammar, facts, reasoning, and style into its weights.
- This yields a knowledgeable base model — fluent but not yet a helpful assistant. Its knowledge lives in weights, not a database (hence hallucination).
From Base Model to Assistant: SFT and RLHF
A raw pretrained model is a brilliant, unruly text-predictor. Two more steps turn it into something helpful, honest, and safe to talk to.
Ask a raw base model 'What is the capital of France?' and it might reply with 'What is the capital of Germany? What is the capital of Spain?' — because on the internet, questions are often followed by more questions. It learned to continue text, not to help you. Turning that knowledgeable-but-unruly predictor into the assistant you actually want takes two further stages of training: teaching it to follow instructions, then shaping it toward responses people prefer.
#Stage 2 — Supervised Fine-Tuning (SFT)
First, human experts write thousands of high-quality examples of good instruction-following: a question and an ideal answer, a request and a helpful response. The model is fine-tuned on these, learning the behaviour of being a helpful assistant — answering rather than echoing, following instructions rather than merely continuing text. It already had the knowledge; SFT teaches it the job.
#Stage 3 — Alignment (RLHF)
Then, refinement by preference. The model generates several answers; humans (or a model trained on human preferences) rank which is best; and the model is nudged — via reinforcement learning (Lesson 3.2) — toward producing more of the preferred kind. This RLHF (Reinforcement Learning from Human Feedback) is where helpfulness, tone, honesty, and safety are shaped.
1. PRETRAIN -> vast knowledge, but just continues text
|
2. SFT -> learns to FOLLOW INSTRUCTIONS (expert examples)
|
3. RLHF -> tuned toward answers humans PREFER
| (helpful, honest, safe, well-toned)
a helpful assistantPretraining is raising someone with an encyclopaedic education. SFT is job training — teaching them the specific role of a helpful assistant. RLHF is the mentorship and feedback that refines their judgement, manners, and tone until they're someone you actually want to work with. Knowledge, then skill, then polish.
Misconception: 'Fine-tuning and RLHF teach the model new facts.' Mostly they shape behaviour, not knowledge — how to respond, what tone to take, what to refuse. The bulk of what the model knows was set during pretraining. SFT and RLHF make a knowledgeable model usable and aligned, not smarter about facts.
A pretrained model has knowledge but continues text instead of helping, and isn't shaped for honesty, safety, or tone — unusable as an assistant on its own.
SFT teaches instruction-following from expert examples; RLHF uses ranked human preferences and reinforcement learning to tune toward helpful, honest, safe, well-toned responses.
How every modern chat assistant is finished (ChatGPT, Claude, Gemini). It's why today's models feel helpful and aligned rather than like raw autocomplete.
- Three stages: pretraining (knowledge) → SFT (instruction-following) → RLHF (preferences, safety, tone).
- SFT uses expert example answers; RLHF uses ranked human preferences + reinforcement learning.
- These stages shape behaviour, not facts — turning a raw predictor into a helpful, aligned assistant.
Context Windows and Emergent Abilities
Two ideas that explain both the power and the limits of today's models: how much they can 'hold in mind', and the surprising skills that appear only at scale.
The context window is how much text — measured in tokens — a model can consider at once: your prompt plus its reply, plus any documents you paste. It's the model's working memory for a single conversation. Early models held a few thousand tokens; frontier models now hold hundreds of thousands. Anything beyond the window is simply invisible to the model — it has no memory of earlier conversations unless that text is fed back in.
The context window is the model's desk space. A small desk holds a few pages; a large one holds a whole report. The model can only reason about what's currently on the desk — clear it, and that information is gone. This is why long documents must fit (or be retrieved in pieces, via RAG) and why a model doesn't 'remember' you between separate chats unless the app re-supplies the history.
#Emergent abilities: skills that switch on with scale
As models grew larger and trained on more data, researchers noticed something strange: certain abilities — multi-step arithmetic, translation, step-by-step reasoning — were nearly absent in smaller models and then appeared, fairly abruptly, once models passed a certain size. These emergent abilities weren't explicitly trained; they surfaced from scale alone, and they're a big reason the field has pushed toward ever-larger models.
Misconception: 'A bigger context window means the model remembers everything forever.' It only means a bigger single working memory. Cross the window and information falls off the desk; close the chat and (by default) it's gone. Persistent memory across sessions is a feature apps build around the model, not an inherent property of it.
Emergent abilities are genuinely debated. Some researchers argue certain 'sudden' jumps are partly artefacts of how we measure them rather than true phase-changes. It's a live, unsettled question — a good reminder (echoing Part 1's winters) to hold confident claims about scaling, in either direction, a little loosely.
Models need a working memory for each conversation, and the field needed to understand what extra scale actually buys in capability.
The context window caps how many tokens the model can attend to at once; emergent abilities are skills that appear only past certain scale thresholds, without being explicitly trained.
Context limits shape every real application (long docs, chat history, RAG); emergence drives the industry's bet on scale — though both are nuanced and partly contested.
- The context window = how many tokens the model can hold 'on its desk' at once (its per-conversation working memory).
- Beyond the window, text is invisible; persistent cross-session memory is built by apps, not inherent.
- Emergent abilities appear with scale without being explicitly trained — a key driver of bigger models, though partly debated.
Zero-Shot, Few-Shot, and In-Context Learning
The remarkable fact that you can teach a model a new task inside the prompt itself — and the simplest way to do it.
Here's something that genuinely surprised researchers: you can give an LLM a task it was never specifically trained on, show it a couple of examples in the prompt, and it will often just… do it. No retraining, no new data, no engineering. The model learns the pattern from the prompt itself, on the spot. This ability — in-context learning — is what makes prompting such a powerful, accessible skill.
Zero-shot is asking directly with no examples ('Classify this review as positive or negative'). Few-shot is giving a handful of examples first, so the model infers the exact pattern and format you want. Few-shot shines when the task is unusual, the output format is specific, or zero-shot results are inconsistent — the examples act as a live demonstration the model imitates.
ZERO-SHOT: "Is this review positive or negative? 'Loved it!'"
FEW-SHOT: "'Terrible.' -> negative
'Amazing!' -> positive
'Loved it!' -> ?"
The examples teach the pattern & format inside the prompt itself.Few-shot prompting is like showing a sharp new colleague two or three worked examples before handing them the next case. They don't need a training course — they pattern-match from your examples and carry on. The model does the same, learning your task from the demonstration in the prompt.
Retraining a model for every small task is slow and costly — we need to steer behaviour instantly, with no new training.
In-context learning: the model adapts from the prompt alone. Zero-shot asks directly; few-shot provides examples that demonstrate the desired pattern and format.
Everyday use of any LLM — classification, extraction, formatting, style-matching — all achievable by prompt design, no engineering required.
- In-context learning: LLMs adapt to new tasks from the prompt alone — no retraining.
- Zero-shot = ask directly; few-shot = show a few examples first to lock in the pattern/format.
- Use few-shot for unusual tasks or specific formats, or when zero-shot is inconsistent.
Chain-of-Thought: Asking the Model to Think
A near-magical one-line trick that makes models dramatically better at anything requiring reasoning.
Ask a model a tricky multi-step word problem and demand the answer immediately, and it often blurts a wrong number. Add five words — 'Let's think step by step' — and accuracy jumps, sometimes enormously. By letting the model lay out its reasoning before committing to an answer, you give it room to work the problem through rather than guess. This is chain-of-thought prompting, and it's one of the highest-leverage tricks in the toolbox.
An LLM generates one token at a time, so a complex answer demanded in one leap has nowhere to 'show its work'. Inviting step-by-step reasoning lets each intermediate step inform the next — the model effectively thinks on paper. Hard problems (maths, logic, multi-part analysis) benefit most; simple lookups don't need it.
WITHOUT: "A shop has 23 apples, sells 7, buys 12. How many?"
-> "28" (often wrong, guessed in one leap)
WITH: "...Let's think step by step."
-> "Start 23, minus 7 = 16, plus 12 = 28." (reasons it out)
Showing the steps lets each one inform the next -> better answers.It's the difference between shouting an answer to a maths problem and working it out on scratch paper. The scratch paper doesn't make you smarter — it stops you skipping steps and lets you catch errors as you go. Chain-of-thought is scratch paper for the model.
The latest reasoning models (Part 14) bake this idea in — they're trained to 'think' at length internally before answering, automating what chain-of-thought prompting does by hand. The principle is the same: more deliberate steps, better answers on hard problems.
Demanding a complex answer in one leap gives the model no room to reason, so it guesses and errs on multi-step problems.
Chain-of-thought prompts the model to lay out intermediate steps before answering, so each step informs the next — reasoning 'on paper' rather than blurting.
Maths, logic, planning, multi-part analysis — and the seed of today's dedicated reasoning models, which internalise the technique.
- Chain-of-thought: prompt the model to reason step-by-step before answering.
- It gives the model 'scratch paper' so each step informs the next — big gains on hard, multi-step problems.
- Modern reasoning models automate this by thinking at length internally before replying.
Roles, System Prompts, and Structured Output
The practical levers that make an LLM behave consistently and produce output your software can actually use.
Three reliable levers. A role/persona ('You are a careful financial analyst…') sets the model's voice, expertise, and priorities. A system prompt is a persistent instruction that governs the whole conversation — its standing rules, tone, and constraints — set once, applied throughout. And structured output asks for a specific machine-readable format (like JSON), so the result can flow straight into other software rather than being free-form prose.
The system prompt is a job description handed to an actor before the scene — it shapes every line they deliver. The role is the character. Structured output is asking them to deliver their lines on a labelled form rather than as a monologue, so the next department can process it without re-reading everything.
SYSTEM: "You are a concise legal assistant. Always cite sources."
ROLE: sets voice/expertise for the whole chat
USER: "Summarise this contract."
ASK FOR STRUCTURE: "Return JSON: {risk_level, key_clauses[]}"
-> output your code can parse directly, not loose prose.Misconception: 'Prompting is just casual chatting.' For one-off questions, sure. But building reliable products on LLMs is real engineering: careful system prompts, well-chosen examples, structured outputs, and testing. The casual surface hides a genuine discipline — which is why 'prompt engineering' is a job, not a gimmick.
To use LLMs in real products, we need consistent behaviour and outputs that software can consume — not just charming free-form replies.
Set a persistent system prompt (standing rules), assign a role/persona (voice and expertise), and request structured output (e.g. JSON) for machine-readable, reliable results.
Every serious LLM application: assistants, data-extraction pipelines, agents (next part). These levers turn an unpredictable chatbot into a dependable component.
- Role/persona sets voice and expertise; system prompt sets persistent, conversation-wide rules and tone.
- Structured output (e.g. JSON) makes results machine-readable for downstream software.
- Reliable LLM products are real engineering — prompts, examples, structure, and testing, not just casual chat.
The Open-Book Exam
Why even the most capable model needs RAG — and the simple idea that grounds its answers in real, current, private information.
An LLM's knowledge is frozen at the moment its training ended, and it never saw your internal documents at all. So ask it about your company's refund policy or yesterday's news, and it will either admit ignorance or — worse — confidently invent a plausible-sounding answer (a hallucination, Part 14). Retrieval-Augmented Generation (RAG) fixes this by handing the model the relevant documents at question time, so it answers from real sources instead of fuzzy memory.
It's the difference between a closed-book and an open-book exam. A closed-book exam tests frozen memory — and tempts confident guessing when memory fails. An open-book exam lets you look up the actual material and answer from it. RAG turns every question into an open-book exam: fetch the right pages first, then answer grounded in them. (This is the requested image, made literal.)
WITHOUT RAG: question -> LLM answers from frozen memory
-> may be stale, ignorant of your data, or made up
WITH RAG: question -> FETCH relevant documents
-> give them to the LLM with the question
-> answer grounded in real, current sourcesRAG separates knowing from reasoning. The LLM stays the brilliant reasoner and writer; an external store holds the facts — your documents, current data, private knowledge — and supplies the relevant bits on demand. This makes answers current, source-grounded, and far less prone to invention, without retraining the model at all.
LLM knowledge is frozen, generic, and occasionally invented — useless for private, current, or factual-critical questions on its own.
Retrieve the most relevant documents at question time and feed them to the LLM with the question, so it answers grounded in real sources rather than memory.
The dominant pattern for business AI: support bots over company docs, research assistants, internal knowledge tools — anywhere answers must be current, private, and trustworthy.
- LLM knowledge is frozen, generic, and sometimes invented — RAG fixes this.
- RAG = open-book exam: fetch relevant documents first, then answer grounded in them.
- It separates reasoning (the LLM) from facts (your documents) — the standard pattern for trustworthy business AI.
How RAG Works: Chunk, Embed, Retrieve
The machinery behind the open book — and why the embeddings you met in Part 2 are doing the heavy lifting.
RAG runs in two phases. Preparation (once): split your documents into bite-sized chunks, convert each chunk into an embedding (Lesson 2.8 — a vector capturing its meaning), and store them in a vector database built for similarity search. At question time: embed the user's question the same way, find the chunks whose embeddings are nearest to it (most similar in meaning), and hand those chunks plus the question to the LLM to compose a grounded answer.
The vector database is a **librarian who files every passage by its meaning, not its title.** Ask a question and she instantly pulls the few passages most semantically related — even if they share no exact keywords — because nearby embeddings mean similar ideas (Lesson 2.8). Those passages become the model's open book.
Misconception: 'RAG is keyword search.' It's semantic search — matching by meaning via embeddings, so 'how do I get my money back?' can retrieve a passage titled 'Refund Policy' despite zero shared words. That meaning-based retrieval is what makes RAG work where old keyword search failed.
Quality hinges on the unglamorous details: chunks too big bury the answer in noise; too small lose context. Retrieve too few and you miss the answer; too many and you overwhelm the model. Tuning chunking and retrieval is where most real RAG effort goes — and where good systems are won or lost.
To ground answers, the system must **find the right passages** from possibly millions — fast, and by meaning rather than exact words.
Chunk → embed → store documents in a vector database; at query time embed the question and retrieve the nearest chunks (semantic similarity), then let the LLM answer from them.
Every RAG system — and the reason vector databases and embeddings are core infrastructure for modern AI applications.
- RAG: chunk → embed → store in a vector DB; then embed the question → retrieve nearest chunks → LLM answers from them.
- It's semantic (meaning-based) search via embeddings — not keyword matching.
- Most real-world effort goes into chunking and retrieval tuning; embeddings and vector databases are core infrastructure.
From Answering to Acting
What turns a chatbot into an agent — and why giving an LLM a loop and some tools changes everything.
Ask a normal chatbot to 'book me the cheapest flight next Tuesday' and it can only describe how you might do it — it can't actually check prices or book anything. An agent can: it searches flights (a tool), reads the results, compares options, and takes the booking step — looping until the goal is met. The leap from answering to acting is what 'agentic AI' means, and it's the current frontier.
An agent is an LLM placed in a loop and given tools. The loop: receive a goal → decide the next action → use a tool (run a search, query a database, call an API, do a calculation) → observe the result → decide the next action → repeat until done. The LLM is the reasoning 'brain'; the tools are its hands; the loop is what lets it take many steps instead of answering in one shot.
A plain LLM is a brilliant advisor trapped behind a desk with no phone — full of knowledge, unable to do anything. An agent gives that advisor a phone, a computer, and permission to act: now they can look things up, place orders, and follow a task through to completion, step by step.
Many real tasks need multiple steps and real-world actions (look something up, compute, call a service) that a single one-shot answer can't accomplish.
Wrap an LLM in a loop with tools: decide → act (tool) → observe → repeat until the goal is met — the LLM reasons, the tools execute.
Coding assistants, research agents, customer-service automations, data-analysis agents — and the broad direction of the field toward more autonomous systems.
- An agent = an LLM in a loop with tools: decide → act → observe → repeat until the goal is done.
- It shifts AI from answering to acting — taking multiple real-world steps.
- Powers coding assistants, research and data agents, automations — the field's current frontier.
Tools, Memory, Planning, and Multi-Agent Systems
The four capabilities that make agents genuinely useful — and the honest limits you must design around.
Four ingredients turn the basic loop into something capable. Tool calling: the model is given a menu of tools with descriptions and outputs structured requests to use them. Memory: a scratchpad (and longer-term stores) so it remembers earlier steps and findings within a task. Planning: breaking a big goal into an ordered sequence of sub-steps before diving in. Multi-agent systems: several specialised agents collaborating — a 'researcher', a 'writer', a 'checker' — each handling part of the job.
TOOLS -> the agent's hands (search, code, APIs, databases) MEMORY -> remembers earlier steps & findings within the task PLANNING -> breaks a big goal into ordered sub-steps MULTI-AGENT -> specialised agents collaborate (research / write / check) Together: an LLM that can pursue complex, multi-step goals.
A multi-agent system is a small project team. A lone generalist can do a complex job slowly and erratically; a team with a researcher, a writer, and a reviewer divides the work, checks each other, and produces better results. Specialisation and review help agents just as they help people.
Misconception: 'Agents are reliable and autonomous today.' They're powerful but brittle: errors compound across steps (a wrong step three feeds a wrong step four), they can loop or wander, and a tool misfire can derail the whole task. Real deployments lean heavily on guardrails, human checkpoints, and limited scope. Treat agents as capable assistants needing oversight, not hands-off autopilots.
A bare loop isn't enough for hard goals — agents need to use tools, remember, plan ahead, and divide labour to handle real complexity reliably.
Add tool calling (structured tool use), memory (scratchpad + stores), planning (decompose goals), and multi-agent collaboration (specialised roles) on top of the decide-act-observe loop.
Coding agents, research and analysis agents, workflow automation — with the caveat that reliability still demands guardrails and human oversight.
- Four capabilities: tool calling (hands), memory (scratchpad), planning (decompose goals), multi-agent (specialised collaboration).
- Multi-agent = a small project team of specialised agents that check each other.
- Agents are powerful but brittle — errors compound across steps, so guardrails and human oversight are essential.
GANs: The Forger and the Detective
The clever competition that first made AI-generated images shockingly realistic.
How do you teach a machine to create convincing fake images? Pit two networks against each other. One, the generator, plays an art forger trying to produce fakes good enough to pass as real. The other, the discriminator, plays a detective trying to spot the fakes. They train in competition: every time the detective catches a fake, the forger improves; every time a fake slips through, the detective sharpens. This arms race — a Generative Adversarial Network (GAN) — drove the first wave of eerily realistic AI faces.
GENERATOR (forger) --makes fake--> [ image ]
|
DISCRIMINATOR (detective) --judges--> real or fake?
- catches a fake -> forger improves
- fooled by fake -> detective improves
They escalate until fakes are indistinguishable from real.It's a counterfeiter versus a bank's fraud expert, locked in escalation. Each forces the other to get better, and the end product — the counterfeit — becomes nearly perfect. The competition itself is the teacher; neither network could reach that quality alone.
Misconception: 'GANs are how today's image tools work.' They were the breakthrough, but most leading image generators have moved to diffusion (next lesson), which is more stable to train and produces higher-quality, more controllable results. GANs are a brilliant idea now largely superseded for mainstream image generation.
We needed a way to train a model to create realistic images, with no direct formula for 'looks real' — so we let a critic learn what real looks like.
Two networks compete: a generator makes fakes, a discriminator judges them, each improving the other until fakes are indistinguishable from real.
Historically the engine of realistic AI faces and image synthesis; today largely replaced by diffusion for mainstream generation, though still used in niches.
- A GAN pits a generator (forger) against a discriminator (detective); competition makes both improve.
- This drove the first wave of realistic AI-generated images.
- Mostly superseded by diffusion today — more stable and higher quality.
Diffusion: Sculpting Images From Noise
The idea behind today's leading image generators — and why 'start with static and remove the noise' works so astonishingly well.
Imagine taking a photo and adding a tiny bit of random static, again and again, until it's pure noise — total visual snow. Now imagine a model trained to reverse that process: to look at noisy static and predict what a slightly less noisy version would look like. Run that reversal many times, starting from pure random static, and a coherent image gradually emerges from the chaos — guided by your text prompt at every step. That is diffusion, and it powers most of today's leading image generators.
TRAINING: real image --add noise--> ... --> pure static
(learn to reverse each step)
GENERATING: pure static --remove noise--> ... --> clear image
guided by your text prompt at every step
"a cat astronaut" -> emerges from the noiseIt's like restoring an old, damaged photograph (the requested image, made literal) — except the model starts from pure damage (random static) and, step by careful step, removes the noise until a clear picture appears, steered toward your description. Sculpture is the other apt image: the figure was 'in' the noise all along, and denoising chisels it out.
Why is this so much better than GANs? Diffusion breaks an impossibly hard task ('make a perfect image in one shot') into many tiny, easy ones ('make this slightly less noisy'). Each small step is manageable, training is stable, and the gradual process gives fine control — including steering toward a text prompt at every step via the embeddings of Part 2.
Diffusion underpins the household-name image generators and is rapidly extending to video and audio. Multimodal models increasingly combine a language model's understanding with a diffusion-style generator, so a single system can read your words and produce matching images — the union of everything in this course.
Generating a perfect complex image in one shot is too hard — we needed to break creation into small, learnable steps with fine control.
Train a model to reverse noise one small step at a time; to generate, start from pure static and denoise repeatedly, guided by a text prompt, until a coherent image emerges.
Today's leading image generators, increasingly video and audio, and multimodal systems that pair language understanding with diffusion generation.
- Diffusion trains a model to reverse noise; generation starts from static and denoises step-by-step into an image.
- It splits an impossibly hard task into many easy steps — stable, controllable, prompt-guided (like restoring a photo).
- Powers today's leading image generators, extending to video/audio and multimodal systems.
MLOps & LLMOps: Keeping AI Alive
Models are software that decays. The discipline of deploying, monitoring, and maintaining them is where most real-world AI value is won or lost.
A celebrated model is deployed to applause — then slowly, silently degrades, until a year later it quietly performs worse than the simple rule it replaced. Nothing 'broke'; the world moved on (recall drift, Part 3). This is why the unglamorous discipline of operating models — MLOps — matters as much as building them. The model is the engine; MLOps is everything that keeps the car running safely on the road.
MLOps applies software-engineering discipline to ML systems: monitor performance and drift in production, run automated evaluations to catch regressions before release, version data and models so you can roll back, and retrain on a schedule or when metrics decay. LLMOps extends this to LLM apps, where new things also need managing: prompts become versioned 'code', and cost & latency (you pay per token, and responses take time) turn into real engineering constraints at scale.
MLOps loop: deploy -> monitor (drift?) -> evaluate -> retrain -> redeploy
LLMOps adds: version PROMPTS like code
track COST & LATENCY (per-token billing, response time)
evaluate outputs (quality, safety) continuouslyDeploying a model without MLOps is like buying a car and never servicing it. It runs beautifully at first, then drifts out of tune until it fails when you least expect it. MLOps is the regular service, the dashboard warning lights, and the mechanic on call — the difference between a demo and dependable infrastructure.
Models decay as the world changes, and LLM apps add cost, latency, and prompt-management challenges — ad-hoc operation leads to silent failure and runaway bills.
MLOps: monitor drift, automate evaluation, version data/models, retrain. LLMOps adds prompt versioning and cost/latency monitoring for LLM-based systems.
Every production AI system. This operational discipline is where a large share of real-world AI value — and reliability — actually comes from.
- Models decay with drift — MLOps monitors, evaluates, versions, and retrains them in production.
- LLMOps adds prompt versioning and cost/latency management for LLM apps.
- Operating models well (not just building them) is where much real-world AI value and reliability live.
Hallucination, Bias, and Brittleness
The three structural limitations of modern AI — not occasional bugs to be patched, but properties of how these systems work, to be designed around.
Three limits recur, and the key insight is that they're structural, not accidental. Hallucination: an LLM predicts plausible-sounding text, not verified facts — so it can state falsehoods with total confidence (mitigated, not cured, by RAG and tools). Bias: models learn from real-world data and inherit its biases — historical, social, representational — which can produce unfair outcomes in hiring, lending, and beyond. Brittleness: performance can drop sharply on inputs subtly unlike the training data (odd edge cases, adversarial tricks).
HALLUCINATION -> fluent, confident, sometimes flat wrong
(predicts plausible text, not verified facts)
BIAS -> inherits unfairness present in training data
BRITTLENESS -> can fail on edge cases / adversarial inputs
These are PROPERTIES of how the systems work -> design around them.An LLM is like a supremely fluent, well-read improviser who never says 'I don't know' — they'll always produce a confident, plausible continuation, whether or not it's true. You wouldn't take such a person's word on a critical fact without checking. The same discipline — verification, grounding, human review — is how you deploy AI responsibly.
Misconception: 'These flaws will simply be fixed with bigger models.' They can be reduced — by grounding (RAG), better data, evaluation, and human oversight — but they stem from how the systems fundamentally work, so the right posture is to design around them (verification, guardrails, human-in-the-loop), not to assume they'll vanish.
Deploying AI safely requires understanding its failure modes — confidently wrong outputs, inherited unfairness, and fragile edge-case behaviour can cause real harm if ignored.
Hallucination (plausible-but-false text), bias (inherited from data), and brittleness (edge-case failure) are structural; manage them with grounding, evaluation, diverse data, and human review.
Every real deployment — especially in medicine, law, finance, and hiring, where a confident error or unfair outcome carries serious consequences.
- Hallucination (confident falsehoods), bias (inherited from data), and brittleness (edge-case failure) are structural, not bugs.
- They're reduced, not cured — by grounding (RAG), better data, evaluation, and human oversight.
- The right posture is to design around them with verification and human-in-the-loop, especially in high-stakes domains.
Alignment and the Question of Control
As AI systems grow more capable and autonomous, one research question rises above the rest: how do we make sure they reliably do what we actually intend?
Grant a system a goal and enough freedom, and it may pursue that goal in ways you never meant — optimising the letter of your instruction while missing its spirit. A famous thought experiment imagines a system told to maximise paperclips doing so to absurd, harmful extremes. The cartoon is silly, but it dramatises a serious question that grows with capability and autonomy (agents, Part 12): how do we ensure AI reliably does what we actually want? That question is the field of alignment.
Alignment is the work of making AI systems' behaviour match human intentions and values — not just their literal instructions. RLHF (Part 9) is one practical, partial tool: shaping models toward human-preferred behaviour. But broader alignment research — interpretability (understanding why a model does what it does), robustness, and scalable oversight (supervising systems that may exceed us in some skills) — remains an active, unsolved, and increasingly important area as systems gain autonomy.
It's the old genie problem: you get exactly what you wished for, not what you meant. Wishing well — specifying goals so a powerful optimiser can't satisfy them in harmful, unintended ways — turns out to be genuinely hard. Alignment research is, in part, the science of wishing carefully and verifying you got what you intended.
This isn't science fiction or settled fact — it's a live research field with serious people doing serious work and genuine disagreement about how hard the problem is and how soon it matters. The honest stance: take it seriously without melodrama, follow the evidence, and treat confident certainty in either direction — 'trivial' or 'doomed' — with healthy skepticism.
As AI grows more capable and autonomous, ensuring it reliably does what we intend (not just what we literally say) becomes essential to deploying it safely.
Alignment shapes behaviour toward human intent and values; RLHF is one partial technique, alongside research in interpretability, robustness, and scalable oversight — much of it unsolved.
A central, active research field shaping how powerful AI is built and governed — increasingly important as agents take on more autonomy.
- Alignment = ensuring AI does what we intend, not merely what we literally instruct (the 'genie problem').
- RLHF is one partial tool; interpretability, robustness, and scalable oversight remain active and unsolved.
- It's a serious, live research field with genuine disagreement — take it seriously, without melodrama.
The Road Ahead, Honestly
Reasoning models, scaling debates, and AGI timelines — the field's biggest open questions, presented as genuine disagreements rather than settled prophecy.
It's tempting to end a course like this with confident predictions. Instead, the most useful thing — and the most honest — is to map the genuine debates, because the experts themselves disagree, often sharply. Carrying the right questions, and a healthy skepticism toward confident answers in any direction, will serve you far better than any forecast. Recall the AI winters (Part 1): the field's history is a graveyard of confident predictions.
#Current directions
- Reasoning models. Models trained to 'think' longer before answering — internalising chain-of-thought (Part 10) — are a clear current frontier, improving hard maths, coding, and logic.
- Multimodality & agents. Systems that natively handle text, images, and audio together, and that take multi-step autonomous actions (Part 12), are advancing quickly.
#Genuine open debates
- Will scaling keep working? Some researchers expect continued gains from more data, compute, and size; others think we're nearing diminishing returns and need new architectural ideas. Genuinely unsettled.
- AGI timelines. Credible experts range from 'a few years away' to 'decades off, or further than people assume'. The definition of AGI itself is contested. Treat any confident timeline — utopian or apocalyptic — with skepticism.
Misconception: 'Experts broadly agree on where this is going.' They don't. On scaling, timelines, risk, and even what current models 'understand', there's real, informed disagreement. Anyone projecting total certainty about AI's trajectory is overstating what's known. Comfort with that uncertainty is a feature of clear thinking, not a gap in it.
You now hold the whole map — from Turing's question through rules, data, deep learning, attention, LLMs, RAG, agents, and generation, to the open frontier. The goal was never to make you predict the future, but to let you reason about it: to read a headline, a product, or a claim and judge it on its merits. That ability — not any single fact — is what this course was for.
Understanding AI's trajectory and open questions lets you make better decisions and cut through hype — in either direction — for years to come.
By mapping the real debates (scaling, timelines, capabilities) as genuine disagreements among experts, with skepticism toward confident claims, rather than as settled predictions.
Strategy, investment, policy, and your own judgement. The lasting skill is reasoning about AI on the merits — which you now have the foundations to do.
- Current frontiers: reasoning models and multimodal agents.
- Big debates — will scaling keep working? and AGI timelines — are genuinely unsettled; experts disagree.
- Treat confident predictions (utopian or apocalyptic) with skepticism; the lasting skill is reasoning about AI on the merits — which you now have.
Books
Papers
Videos & visual learning
Courses
Docs, blogs & communities
#A suggested learning roadmap
This course gives you the map. Here's a sensible order for going from understanding to doing — each stage builds on the last.
- Solidify intuition (you're here). Finish this course; you now understand the landscape end-to-end.
- Get hands-on with classic ML. Work through An Introduction to Statistical Learning and build small models (regression, trees, K-Means) on real datasets.
- Learn the tools. Python with pandas, scikit-learn, and a notebook environment. Reproduce a churn or pricing model end-to-end (the Part 3 pipeline).
- Go deep on deep learning. Andrew Ng's or fast.ai's courses; build a small neural network and a CNN from scratch.
- Build with LLMs. Prototype a prompt-engineered tool, then a small RAG system over your own documents, then a simple agent with one or two tools.
- Operate it. Learn evaluation, monitoring, and the MLOps/LLMOps basics from Part 14 — the difference between a demo and something dependable.
You don't need heavy maths to start building. Add depth (the maths of Part 2, then linear algebra and calculus) as specific projects demand it — pulled in by need, not memorised up front.
#Career paths in AI
| Role | What they do | Leans on |
|---|---|---|
| Data Analyst | Turn data into insight and decisions. | Stats, SQL, visualisation, communication |
| Data Scientist | Build predictive models to answer business questions. | Classic ML, feature engineering, evaluation |
| ML Engineer | Put models into reliable production systems. | Software engineering, MLOps, deep learning |
| AI / LLM Engineer | Build applications on top of LLMs (RAG, agents). | Prompting, RAG, tool use, LLMOps |
| Research Scientist | Advance the methods themselves. | Strong maths, deep learning, publishing |
| AI Product Manager | Decide what to build and why; bridge tech and users. | This course's breadth + product sense |
Notice that several of these roles lean mostly on understanding and judgement — exactly what this course builds — rather than heavy mathematics. Breadth is a career asset in its own right.
#Cheat sheet — pick the right approach
| If you want to… | Reach for… | Part |
|---|---|---|
| Predict a number | Linear regression → gradient boosting | 4, 2.9 |
| Predict a yes/no | Logistic regression → boosting | 4 |
| Find natural groups (no labels) | K-Means clustering | 4.5 |
| Best accuracy on spreadsheet data | Gradient boosting (XGBoost/LightGBM) | 4.4 |
| Work with images | CNN (or a vision Transformer) | 6, 8 |
| Understand or generate language | Transformer / LLM | 8, 9 |
| Answer from your own documents | RAG | 11 |
| Take multi-step actions | An agent with tools | 12 |
| Generate images | Diffusion model | 13 |
| Explain a model's decision | SHAP / feature importance | 2.7 note, 4 |
#Cheat sheet — avoid the classic traps
- Testing on training data → inflated, dishonest scores. Always hold out a test set (3.4).
- Trusting accuracy on rare events → useless models look great. Use precision/recall/F1 (3.6).
- Confusing correlation with causation → confident, expensive wrong decisions. Experiment to prove cause (2.6).
- Assuming a bell curve everywhere → broken models on skewed data like incomes (2.5).
- Treating a deployed model as 'done' → silent decay via drift. Monitor and retrain (3.7, 14.1).
- Believing LLM outputs as fact → hallucination. Ground with RAG and verify (11, 14.2).
You finished. You now hold a genuine, end-to-end mental model of artificial intelligence — its history, its maths, its algorithms, its modern engines, and its open questions. The lasting value isn't any single fact; it's that you can now reason about almost anything in AI from first principles. That's exactly what this course set out to give you.