AIQ
AIQ
Part of the Learning from Examples lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 🔧 Builder (8–10) · ⚡ Architect (15–18)
Skip the childhood-memory framing for this age band and go straight at the scope of it, reading the app's own line:
"Supervised learning is the most common type of AI. You give it labeled examples and it learns the pattern.
Let's see how it works under the hood."
Add: "Almost every AI system you've actually used — spam filters, face unlock, recommendation feeds, medical image screening — is trained this way. Today we're not just naming the idea, we're opening it up: what does 'learning the pattern' actually mean, mechanically, inside the system?" Write four words on the board without explaining them yet: training set, loss, gradient descent, overfitting. Tell the class these are the real terms behind what they're about to see, and they'll be able to define all four by the end of the lesson.
Ask one more question before opening the app: "If I told you a model scored 99% on a test made of questions it had already seen the answers to, would you be impressed?" Most students will correctly sense something's off. Hold that instinct — it's exactly the instinct behind why real machine learning always tests on unseen data, which is the first technical idea this lesson builds toward.
Run the app's three scenes, but use each one as a launching point into the more technical layer this age band's quiz actually tests — the scenes themselves don't spell these terms out, so this is where you add them.
🏷️ Supervised Learning. After the app shows Labeled Data and Training Set, introduce the split real systems use: a training set the model learns from, a validation set used to tune settings along the way, and a test set — data the model never touches until the very end, used purely to check honestly how well it generalizes. Connect this directly to the app's own Make Predictions card, which shows the model being tested on a photo it hasn't seen: "That's the test set in action. If you only ever checked the model against data it trained on, you'd have no way to tell real learning from simple memorization." A concrete number helps here: a typical split might be 70% of the data for training, 15% for validation, 15% for testing — the exact ratios vary by project, but the principle of holding data back doesn't.
👨🏫 Teaching AI. This is the core of the lesson technically. When the app shows "Wrong = Adjust," give the real name: the gap between the model's guess and the correct label is measured by a loss function — a single running number that says how wrong the model currently is overall. Training then uses gradient descent: for each of the model's many internal numbers (its parameters), the algorithm calculates which direction, if you nudged that number, would reduce the loss — and takes a small step in that direction. Do this repeatedly, across every example, across many epochs, and the loss trends downward as the model gets better. A workable board analogy: you're trying to find the lowest point in a hilly, foggy field by feel alone — at each step you check which direction slopes downward under your feet and take a small step that way. You can't see the whole landscape, but repeating "step downhill" enough times gets you close to the bottom. Point out one thing the analogy shouldn't oversell: gradient descent finds a low point, not necessarily the single lowest point possible — a real loss landscape can have multiple valleys, and the model can settle into a decent one without it being the mathematically best one available. This is why training the same architecture twice, from different random starting points, can sometimes produce slightly different final results.
Then introduce overfitting directly, since it's the quiz's first question: a model that trains on the same limited set for too long can start memorizing quirks specific to those exact examples — noise, coincidences, even file artifacts — rather than learning the general pattern. It looks fantastic on the training data and falls apart on anything new. This is precisely why the train/validation/test split from the previous scene exists: it's the mechanism that catches overfitting before a model ships.
🌍 Real Examples. For each of the four (spam filter, medical AI, Shazam, weather prediction), ask the class to name what the loss function might be measuring and what overfitting would look like in that specific system. For example: a spam filter that overfit might perfectly sort the exact training emails but fail on any new spam pattern it hasn't seen; a medical AI that overfit might ace the exact X-rays it trained on but miss real cases with slightly different imaging equipment. This is a good moment to raise the stakes question: a spam filter's mistakes are annoying, but what does it mean for a medical AI to be tested honestly before it's trusted? Push one step further with Shazam: ask what its training set probably had to include beyond just "millions of songs" — likely many different recordings of the same song (studio, live, covers, different audio quality), specifically so it doesn't overfit to one exact recording and fail to recognize a slightly different version of a song it technically "knows."
Close the activity with the practice matching round (AI system next to a look-alike non-AI object — labeled training data / paper clip, trained spam filter / mailbox, and so on) as a quick sanity check that the class can still tell "trained on data" apart from "just built to do one fixed job," even after the added technical depth.
Wrap the activity by returning to the board's four words and having the class define each one out loud, in order, as a chain: "We start with a training set of labeled examples. As the model trains, a loss number tracks how wrong it currently is. Gradient descent is the procedure that nudges the model's numbers to bring that loss down, repeated across many epochs. And overfitting is the risk of doing that so much, on such a limited set, that the model memorizes instead of generalizes — which is exactly why we test on data it's never seen."
These four questions are the technical payoff of the activity — they test the exact vocabulary chain you just built on the board, so if a student is stuck, walk them back through that chain (training set → loss → gradient descent → overfitting) rather than restating the answer choices.
Close with: "Every one of the four words we wrote on the board at the start — training set, loss, gradient descent, overfitting — describes one link in the exact same chain: label data, measure how wrong the guess was, nudge the model a little, repeat, and check honestly on data it's never seen. That chain is running, right now, behind almost every AI system you interact with."
Extension activity — Design a supervised learning pipeline on paper: In pairs or small groups, have students pick a classification task of their own choosing (sorting school uniforms as compliant/non-compliant, sorting cafeteria feedback as positive/negative, anything concrete). On paper, they should specify: (1) what their labeled training data would consist of and roughly how much of it they'd want, (2) one realistic way their model could overfit given that data, and (3) how they would split their data into training, validation, and test sets to catch it. Groups present their pipeline to the class in two minutes, and the class asks one question each about a possible source of bias in the training data. This stretches the 10–15 minute core lesson into a full class period and forces the vocabulary from the whiteboard into active use.
For a group that finishes early, add a harder follow-up: "Your model gets 98% accuracy on your training set but only 70% on your test set. Using the four board words, explain what probably happened and name one concrete change to your pipeline that might fix it." A strong answer names overfitting directly and proposes something specific — more or more varied training data, or reserving a larger validation set to catch the problem earlier — rather than a vague "make it better."