Trace token prediction, context, sampling, and why fluent text can still be wrong.
You trace how the sentence 'The cat sat' is split into tokens and mapped to numbers, seeing why 'cat' and 'cats' may be different tokens and why token count ≠ word count.
How text is split into tokens and converted to numbers before a model can process it.
Why this matters: Every limit, cost, and behaviour of a language model — from pricing to context length to spelling mistakes — traces back to how tokenization works.
You type 'The cat sat' — but the model never reads those words. Computers only work with numbers, so every piece of text must be converted into numbers before anything can happen.
The conversion process is called . It chops your text into small chunks called , then swaps each token for a number from a fixed list called the .
A token is usually a word, part of a word, or a punctuation mark — not always a full word. The model only ever sees the numbers, never the letters.
Follow the sentence 'The cat sat' through every tokenization step so you can see exactly what the model receives.
Notice that 'cat' and 'cats' get different IDs — they are separate entries in the vocabulary. Adding an 's' changes the token, so the model treats them as distinct concepts.
Also notice: three words → three tokens here, but that's a coincidence. Token count and word count are not the same thing, as you'll see next.
Modern tokenizers use a method called sub-word splitting. Rare or long words get broken into smaller pieces, each with its own ID.
This is why token count ≠ word count. A 100-word paragraph might be 120–150 tokens. Models are priced and limited by token count, not word count.
The total number of tokens a model can handle at once is called its — think of it as the model's working memory. Exceed it and earlier tokens get cut off.
# A simplified tokenizer — splits on spaces and punctuation def simple_tokenize(text): tokens = text.lower().split() # split on whitespace return tokens sentence = "The cat sat" tokens = simple_tokenize(sentence) print(tokens)
text.lower().split()def simple_tokenize(text):This stage shows the first half of tokenization: splitting text into pieces. Real tokenizers are more sophisticated, but the idea is the same — break text into chunks before assigning numbers.
['the', 'cat', 'sat']
Three tokens — one per word here. Notice the text is lowercased, so 'The' becomes 'the'. Real tokenizers often preserve case and handle punctuation as separate tokens.
# A tiny vocabulary: token string → integer ID vocab = {"the": 464, "cat": 3797, "sat": 3332, "cats": 5691} def tokens_to_ids(tokens, vocab): return [vocab[t] for t in tokens] # look up each token token_ids = tokens_to_ids(tokens, vocab) print(token_ids) # tokens from Stage 1
vocab = {"the": 464, ...}[vocab[t] for t in tokens]Stage 2 adds the lookup step: each token string is swapped for its integer ID from the vocabulary. This is the number the model actually receives — letters are gone.
Notice 'cat' (3797) and 'cats' (5691) have different IDs, even though they differ by one letter. To the model they are completely separate entries.
print(token_ids) → [464, 3797, 3332]
If you change 'cat' to 'cats': tokens become ['the', 'cats', 'sat'], IDs become [464, 5691, 3332]. The middle number changes entirely — confirming that 'cat' and 'cats' are different tokens with different IDs.
You now have [464, 3797, 3332] — a list of integers the model can actually work with. But what does it do with them?
The model's job is to predict what token should come next. Given [464, 3797, 3332] ("the cat sat"), it scores every token in the vocabulary and picks the most likely one to follow.
This is called . It's the single operation that drives everything a language model does — answering questions, writing code, summarising documents.
Click a query word to see which tokens sit closest to it in meaning. Tokens that share meaning cluster together; unrelated ones sit far apart. This is how the model 'knows' that 'cat' and 'cats' are close but not identical.
Tokenization causes real, surprising problems. Here are three to watch for.
You follow a fully worked example — the prompt 'The sky is' — through one complete prediction step: the model assigns a probability to every token in its vocabulary, picks one, appends it, and loops.
Traces how a language model predicts one token at a time — scoring every word in its vocabulary, picking the most likely one, and looping until the output is complete.
Why this matters: Understanding the prediction loop explains why LLMs generate text word-by-word, why they can be wrong with high confidence, and what controls their output — the foundation for every practical decision you'll make when building with them.
Module 1 showed that raw text is first broken into — small pieces like words or word-parts — through a process called . Each token is mapped to a number, and the full list of pieces the model knows is its .
That numbered vocabulary is the starting point for everything in this module. Now the question is: once the model has those numbers, what does it actually do with them?
Your customer typed 'The sky is' and hit send. How does the model decide what word comes next? It doesn't look up a stored answer. Instead, it runs a step: score every word in its vocabulary, pick one, and add it to the prompt.
Each pass through this cycle is called the . The loop keeps running — appending one token at a time — until the model produces a stop token or hits a length limit.
Generation is a loop, not a single calculation. The model can only predict one token at a time. Each new token changes what comes next.
On each loop step, the model scores every token in its vocabulary. These raw scores are called — confidence points before conversion to percentages.
The logits convert into a . Every token gets a number between 0 and 1. All numbers add up to exactly 1.
For 'The sky is', tokens like 'blue', 'clear', and 'bright' get high probabilities. Tokens like 'elephant' or '7' get near-zero probabilities.
The model applies a rule to pick one token — for example, always choosing the highest-probability token (greedy decoding).
Follow one complete prediction loop using the prompt 'The sky is' — every step, in plain language.
Notice that step 5 feeds the output back in as new input. That's why generation is a loop: each token becomes part of the context for the next prediction.
# Pseudocode: one step of the decoding loop # prompt_tokens = [The, sky, is] def predict_next_token(prompt_tokens): logits = model.score(prompt_tokens) # raw score for every vocab token probs = softmax(logits) # convert to probabilities (sum = 1) # ??? — what goes here to pick the next token? prompt_tokens.append(next_token) # add it to the prompt return prompt_tokens # After one call: [The, sky, is, blue] # After two calls: [The, sky, is, blue, .]
model.score(prompt_tokens)softmax(logits)argmax(probs)prompt_tokens.append(next_token)This pseudocode shows one full step of the — score, convert, pick, append. One line is missing: the step that actually selects the next token from the probability distribution.
next_token = argmax(probs) — this picks the token with the highest probability (greedy decoding). The changed line is the crux: argmax scans the full probability distribution and returns the single token index with the largest value. Everything else — scoring, softmax, appending — was already shown in the worked example; supplying argmax is the step that closes the loop.
Each point is a token the model could predict next. Click a query to highlight the nearest (most likely) tokens. Tokens close together have similar probabilities for this prompt.
The loop has three common failure patterns worth knowing before you build anything on top of it.
One full prediction step: score the vocabulary, convert to probabilities, pick a token, append it, and loop.
But the model can't read an infinitely long prompt. It has a fixed-size reading window. It must decide which earlier tokens matter most when that window fills up.
The next module — Context Windows and Attention — shows how that window works. It explains how the model learns to focus on the right tokens (like 'Paris') even when they appeared far back in a long prompt.
You examine the context window as a fixed-size 'desk' and see how attention lets the model weigh 'Paris' heavily when predicting the capital of France, even if it appeared many tokens earlier.
Explains the context window as a fixed-size working space and attention as the mechanism that decides which tokens matter most for each prediction.
Why this matters: Understanding these two ideas tells you exactly why a model forgets old messages, why it can answer questions about distant facts, and why a bigger context window is not always the right fix.
Answer: those raw scores are called . The model converts them into a — a ranked list of how likely each next is — then picks one and loops.
That loop runs inside a strict boundary: the . This module covers what that boundary is, how the model prioritizes tokens inside it, and what happens when you exceed it.
Every time the model runs, it can only see a fixed number of at once — this limit is called the .
Think of it as a desk with a fixed surface area. Your prompt, the conversation history, and the model's own replies all share that space.
When the conversation grows too long, the oldest tokens fall off the desk — the model simply cannot see them anymore.
Different models have different desk sizes: some hold 4 000 tokens, others hold 128 000 or more. But every model has a hard ceiling.
Inside the context window, not every token matters equally for the next prediction.
The mechanism lets each token ask: 'which other tokens should I borrow information from?'
When predicting the capital of France, the model assigns high attention to 'France' — even if it appeared many tokens earlier — and low attention to unrelated words like 'the' or 'of'.
The result is a context-aware signal: the model knows 'Paris' is correct because it actively looked back at 'France', not from memorized rules.
Imagine the context window holds: 'What is the capital of France? The answer is ___'.
Here is what attention does, step by step:
This is why the model answers correctly even when 'France' appeared far back — attention reaches across the whole context, not just recent words.
Each point is a token in the sentence 'What is the capital of France? The answer is'. Click a query token to see which tokens it attends to most (closer = higher attention weight). Token positions are simplified for illustration.
A larger context window sounds like a pure win, but it comes with real costs.
The model sees this context window (10 tokens):
'The Eiffel Tower is located in the city of ___'
Question 1: Which two tokens will receive the highest attention scores when the model fills in the blank?
Question 2: The conversation has been going for 200 messages and this sentence is near the start. What risk does that create?
Next up: Module 4 explores how the model chooses one token from that probability list — comparing greedy, temperature, top-k, and top-p strategies using the same 'The sky is ___' example from Module 2.
These are the three most common ways context and attention go wrong — and what you would actually observe:
Using the same 'The sky is ___' probability list from Module 2, you compare all four decoding strategies side by side — greedy always picks the top token, temperature reshapes the list, top-k cuts it to k candidates, and top-p cuts by cumulative probability.
A comparison of the four main strategies — greedy, temperature, top-k, and top-p — for choosing the next token from the model's probability list.
Why this matters: The strategy you pick directly controls whether your model's output is consistent and factual or varied and creative, which is one of the first settings you'll tune in any real application.
Decision this forces: Which sampling strategy fits the task — deterministic (greedy / low temperature) for factual outputs, or stochastic (temperature / top-p) for creative ones?
Answer: lets the model weigh distant tokens differently — so 'Paris' can strongly influence the prediction of 'capital' even if many tokens separate them.
Module 3 showed you the model's reading ability — how it decides which past tokens matter. This module is about what happens after that reading: the model has a ranked list of candidate next tokens, and it must pick one. How it picks is the whole game.
That ranked list is called a — every token in the gets a score that says how likely it is next. The question this module answers: which token do you actually choose from that list?
After the model scores every token, a decoding strategy turns those scores into a single choice. There are four main strategies, and each makes a different tradeoff between predictability and variety.
All four start from the same — the raw scores the model produces. The strategy is applied on top; the model itself doesn't change.
is the simplest rule: look at the probability list, pick the top token, done. For 'The sky is ___', if 'blue' scores 0.60 it wins every single time — no randomness at all.
changes the shape of the probability list before any token is chosen. A temperature below 1.0 pushes probability toward the top token (more confident). A temperature above 1.0 spreads probability more evenly across tokens (more surprising).
Slide to see how temperature reshapes the probability list for 'The sky is ___'. At 0 the top token dominates; at 2 the list is nearly flat.
Both top-k and top-p trim the candidate list before sampling, so the model can't accidentally pick a very unlikely token. They just trim in different ways.
keeps a fixed number of candidates. Set k = 3 and only the three highest-scoring tokens are eligible — everything else is cut, regardless of their scores.
(also called nucleus sampling) keeps tokens until their combined probability reaches p. Set p = 0.90 and you keep adding tokens from the top down until the running total hits 90%. If the top token alone scores 0.91, only that one token survives. If the top five tokens are needed to reach 90%, all five survive.
Start with the probability list from Module 2 for the prompt 'The sky is ___':
Pick the highest score. 'blue' wins every time. Output is always 'The sky is blue.' — reliable, but never creative.
Rescale the list so it flattens: blue drops to ~0.35, clear ~0.25, vast ~0.22, endless ~0.18. Now 'vast' or 'endless' can win. Output might be 'The sky is vast.' — more varied.
Cut to the top 3: blue (0.60), clear (0.20), vast (0.12). Renormalize so they sum to 1.0. Sample from those three only. 'endless' and 'purple' can never be chosen, no matter what.
Add tokens from the top until the running total hits 0.90: blue (0.60) + clear (0.20) = 0.80, then vast (0.12) pushes it to 0.92 — stop. Eligible tokens: blue, clear, vast. 'endless' is cut. If 'blue' alone scored 0.95, only 'blue' would survive.
Each strategy has a characteristic failure. Knowing the symptom helps you diagnose and fix it fast.
| Option | Variety of output | Risk of incoherence | When to choose | Cost | Complexity |
|---|---|---|---|---|---|
| Greedy (T=0) | None — always picks the top token. | Very low — output is always the most probable sequence. | Factual Q&A, structured data extraction, or any task where the same input must always produce the same output. | Lowest — no sampling overhead. | Trivial — no parameters to tune. |
| Temperature (0.7–1.0) | Moderate — reshapes the full distribution. | Low at T≤1.0; rises sharply above 1.3. | Conversational chatbots, email drafts, or tasks that need slight variety while staying on-topic. | Minimal — same compute as greedy. | One parameter (temperature value) to tune. |
| Top-k (k = 20–50) | Good — samples from k candidates. | Medium — low-probability tokens within k can still win. | Creative writing where you want variety but need a hard cap on how 'weird' the output can get. | Minimal. | One parameter (k) to tune; doesn't adapt to distribution shape. |
| Top-p (p = 0.90–0.95) | High — candidate pool grows when model is uncertain. | Low at p≤0.95; rises as p approaches 1.0. | Creative tasks (stories, brainstorming, poetry) where you want variety that adapts to the model's confidence at each step. | Minimal. | One parameter (p) to tune; adapts automatically. |
You revisit the prediction loop from Module 2 and see that the model is rewarded for plausible continuations during training, not for factual accuracy — so a confident-sounding wrong answer can score higher than an uncertain correct one.
This module explains why a language model can produce fluent, confident-sounding text that is factually wrong — because it is trained to predict plausible continuations, not verified facts.
Why this matters: Understanding this gap helps you know when to trust a model's output and when to verify it, which is essential for anyone building with or evaluating AI-generated content.
In Module 4 you saw that reshapes the over vocabulary. Low temperature makes the top token nearly certain. High temperature spreads the odds.
Lowering temperature makes the model more decisive, not more accurate. It picks the token the training data made most plausible. But plausible and true are not the same. That gap is what this module explores.
During training, the model learns one thing: predict the next that fits the pattern. The reward is for plausible continuation, not factual verification.
This is the : minimise the gap between predicted and actual next token. No fact-checker sits between training text and model weights.
The model learns what text looks like when confident and correct. It can reproduce that look even when wrong. Fluent, authoritative prose is a learned style, not a truth signal.
Imagine asking: "Who wrote the 1987 paper on neural plasticity titled 'Adaptive Synaptic Weights'?"
The model has seen thousands of sentences like: "The seminal work by [Author] (1987) demonstrated…" That pattern is deeply plausible in training data.
So the loop fills in a name — say, "Dr. Elena Marsh" — because that fits academic text patterns. The model adds a journal, volume, and page range, all equally plausible-sounding.
The output reads like a real citation. The tone is certain. But the paper does not exist. The model had no stored fact, only a pattern to continue.
Slide through four real situations where fluency and accuracy diverge. Notice that the model's tone stays confident across all of them.
Fluency and accuracy diverge most dangerously in two situations. Knowing them helps you decide when to trust the model.
In both cases, the keeps running and producing fluent tokens. It has no built-in signal for 'I don't know this.' The model was trained to output plausible continuations, not uncertainty.
"The Eiffel Tower is located in Paris, France, and was completed in 1889."
"The landmark study by Dr. A. Reyes (2019) in the Journal of Cognitive Systems, vol. 14, pp. 233–251, first demonstrated this effect."
Output A covers a common, stable fact with massive training signal — fluency and accuracy almost certainly align.
Output B is the danger zone: a specific citation with a named author, journal, volume, and page range. Each of those details is a separate token chosen for plausibility, not verified against a database. The more precise it looks, the more tokens the model had to invent — and any one of them could be wrong.
These are the three ways the plausibility-vs-truth gap causes real problems.
The model is rewarded for plausible continuations, not true ones. Fluent, confident prose is no guarantee of accuracy.
What happens when the model is asked for something it has no training signal for? It doesn't stop. It keeps predicting the next plausible token, producing a fully grounded-sounding answer.
That specific failure has a name: . The next module traces a fabricated book citation through the prediction loop. You will see exactly where the model went off the rails and why it had no way to know.
You examine a concrete hallucinated output — a fabricated book citation — and trace it back to the prediction loop: the model had no stored fact to retrieve, so it generated a plausible-looking token sequence instead, with no internal alarm.
This module explains hallucination — when an LLM generates confident-sounding but factually wrong output — and shows why it is a built-in consequence of next-token prediction, not a fixable bug.
Why this matters: Understanding hallucination helps you decide when to trust LLM output, when to verify it, and which strategy (retrieval grounding, lower temperature, or human review) fits the risk level of your task.
Decision this forces: Does this output need external verification — and which mitigation strategy (retrieval grounding, lower temperature, human review) fits the risk level?
Answer: the model is rewarded for — whatever token fits the pattern of the training text, not whatever token is factually correct.
That gap — plausible but possibly wrong — is exactly what this module is about. The model has no internal alarm that fires when it doesn't know something. So what happens when it's asked for a fact it never reliably learned?
A is when a model produces text that sounds correct but is factually wrong or made up.
. It has no separate step to check if the output is true. When a fact was never reliably in the training data, the model still generates something that looks like a fact.
This is a structural property of . It is not a bug a future patch will fix.
High model means the output fits the training text pattern. It says nothing about whether the claim is true.
You ask an LLM (Large Language Model): "Can you give me a citation for a book about transformer architectures by Vaswani?"
The model replies:
That book does not exist. The ISBN is invented. The title is invented. But every part of the output looks exactly like a real citation.
The model has seen thousands of real citations in its training data. It learned the pattern of a citation: Author, Year, Title, Publisher, ISBN. generated tokens that fit that pattern perfectly.
There was no stored fact to retrieve — Vaswani's real 2017 paper is an academic paper, not a 2021 MIT Press book. But the model had no alarm to fire. It just kept picking the next most plausible token.
Each token in that citation — "MIT", "Press", "978" — had a high given the tokens before it. High probability means "fits the pattern", not "is true". That is the gap at work.
You used an LLM to draft a report and it produced this citation:
Here is the verification checklist — run through it before you publish:
The rule of thumb: the more specific a claim (a name, a number, a date), the more it needs an external check. Fluent formatting is not evidence of accuracy.
Slide from low-stakes to high-stakes outputs and see how the verification requirement changes. Risk level reflects the real-world cost of acting on a hallucinated answer.
These are the three failure patterns that catch people off guard:
Lowering (making the model less random) reduces creative variation but does not eliminate hallucination — the model can still pick the most probable wrong token.
| Option | Stops hallucination at the source | Works without extra infrastructure | When to choose | Cost | Complexity |
|---|---|---|---|---|---|
| Retrieval grounding | Yes — model is forced to quote retrieved text | No — needs a document store and retrieval pipeline | The answer depends on specific facts, documents, or data that must be accurate — e.g. legal text, product specs, medical guidelines. | Higher — extra compute and storage for the retrieval system. | Medium — requires a document store and a retrieval step before generation. |
| Lower temperature | No — reduces variance but not factual errors | Yes — just set temperature lower in your API call | You want more predictable, less creative outputs and the task is well-defined — e.g. structured data extraction or code generation. | Negligible — same model, same call. | Low — one parameter change. |
| Human review | Catches it after generation — not a prevention | Yes — no extra software needed | The output will be acted on in a high-stakes context — medical, legal, financial, or public-facing — and errors have real consequences. | High — human time per output. | Low technically, high operationally — requires a qualified reviewer in the loop. |
with no warning.
Core insight: a model's measures pattern fit, not truth. Fluent, well-formatted output is not evidence of accuracy.
You now have three tools to manage this. Use to reduce randomness for structured tasks. Use human review to catch what the model cannot.
Before you see the summary, try to reconstruct the chain from memory: what is the very first thing an LLM does with your text, what happens at each step of the loop, what controls how the next token is chosen, and why none of that guarantees a true answer?
Apply what you learned to How Large Language Models Work.