How Computers Read

Learning Objectives

"How Computers Read" is the third lesson in World 2's perception arc, after "How Computers See" (2.1.1) and "How Computers Hear" (2.1.2). Vision and hearing both end at the same idea — a computer converts a signal (pixels, sound waves) into numbers and then finds patterns in those numbers. This lesson applies that exact same idea to text, which is why it opens by directly saying reading is "incredibly hard" for a machine even though it's effortless for a person. By the end, a student should be able to:

• State that computers don't see letters or words the way people do — text has to be converted into numbers before any AI can do anything with it at all.
• Describe, at whatever depth fits their age band, how that conversion works — text gets broken into pieces called tokens (often word-parts, not whole words), and each token becomes a list of numbers called an embedding.
• Explain why similar words end up with similar numbers — "happy" and "joyful" get embeddings that are numerically close together, which is what lets AI group, compare, and relate meanings mathematically instead of just matching exact spellings.
• Name real products built on this pattern — predictive keyboards, spam filters, translation apps, search engines, and chatbots all work by turning text into numbers and finding patterns in those numbers.
• For Hacker and Architect mode specifically: connect this to real model architecture — what a Transformer's self-attention mechanism does, and the mechanical difference between BERT-style bidirectional models and GPT-style autoregressive ones.

Teacher Background

You don't need a linguistics or computer science degree to teach this well, but it helps to have a correct mental picture of what's actually happening, because students will ask "but how does it know what a word MEANS?" and a vague answer will undersell (or overclaim) what's really going on.

Start with the conversion step, because everything else depends on it. A computer only ever works with numbers — it has no native concept of a letter or a word. So the very first thing any text-processing AI does is break a sentence into small chunks called tokens. A token is often smaller than a whole word: "playing" might become "play" + "ing," because splitting common prefixes and suffixes lets the same small vocabulary of tokens cover far more words than if every whole word needed its own entry. Each token is then converted into a list of numbers — often hundreds of numbers long — called an embedding. Nobody hand-writes these numbers; a model learns them by processing enormous amounts of text and noticing which words tend to appear in similar situations.

The reason this matters, and the reason the lesson spends real time on it, is that the resulting numbers aren't arbitrary — they capture something like meaning. Picture each embedding as a point plotted in space (real embeddings use hundreds of dimensions, but the app's "meaning space" metaphor, and the GPS-coordinates comparison it uses for older students, both point at the same idea). Words used in similar contexts end up as nearby points. "Happy" and "joyful" land close together; "happy" and "bulldozer" land far apart. This is what the famous example the lesson uses — king − man + woman ≈ queen — is illustrating: if you take the embedding for "king," subtract the embedding for "man," and add the embedding for "woman," doing that arithmetic on the actual number-lists lands you close to the embedding for "queen." Treat it as a famous (and somewhat fragile — it doesn't always work as cleanly as advertised) illustration from an older generation of word embeddings, word2vec and GloVe, which give each word one fixed vector — not as settled proof. In practice the analogy typically only holds if you exclude "king," "man," and "woman" themselves from the nearest-neighbor search, and it doesn't reliably generalize to other word pairs. It's also a different technique from the contextual embeddings (BERT/GPT-style, where a word's vector shifts depending on its sentence) the rest of this lesson teaches — worth naming explicitly so students don't take it as proof of how modern models like BERT and GPT work. The underlying point still holds, though: whatever relationship shows up here was never hand-specified — it was inferred purely from patterns in how those words are used across huge amounts of text.

For the two AI-processing scenes in this lesson — "Understanding Text" and "Language AI" — the throughline is that once text is numbers, a huge range of tasks become the same underlying operation: comparing numbers, or predicting the next number in a sequence. Sentiment analysis compares a review's numbers against patterns learned from millions of labeled positive/negative examples. Spam detection does the same comparison against patterns learned from labeled spam/not-spam email. Search engines convert your query into numbers and find documents whose numbers are close to it, which is how they handle typos and rephrasing without exact keyword matches. Autocomplete and chatbots are both, mechanically, doing the same thing repeated many times: given the numbers for everything typed so far, predict the most likely next token, convert it back to text, and repeat.

It's worth sitting with why this single idea — text becomes numbers, then a model finds patterns in the numbers — scales to so many seemingly different products. A spam filter, a translation app, and a chatbot look nothing alike from the outside, but underneath, all three share the same two steps: turn text into numeric representations, then compare or predict using patterns learned from vast amounts of prior text. That's genuinely the throughline connecting a decade-old spam filter to a brand-new chatbot, and naming it explicitly is what turns this lesson from "here are five cool AI examples" into "here is one mechanism that explains all five."

Materials & Prep

• One device per student (or per small group) with a web browser and an internet connection, at aiq.ph. No account or login is required — the lesson runs anonymously, on-device.
• If devices are limited, this works fine projected to the whole class — most of the activity below is designed as a guided walkthrough you narrate rather than something each student must click through individually.
• No worksheets or extra software are required. A whiteboard is optional and only used in a couple of the age-specific extension activities described in each script.
• Expect roughly 10–15 minutes for the in-app lesson (hook, three learn scenes, practice round, quiz), plus whatever time you add for discussion and the extension activity in each age script.

Common Misconceptions

Pick your grade's script