A large language model is the thing behind ChatGPT and Claude. It can write, summarise, translate, code, and reason about almost anything — yet at its core it does something almost laughably simple: it predicts the next word. This course explains how something so simple becomes something so capable, exactly how it grows out of the transformer you just learned, and how a raw LLM turns into a real product people actually use.
- Understand how "predict the next word" leads to writing, translating, and reasoning
- See exactly how an LLM is the transformer architecture, not a different thing built on top of it
- Know what a token actually is, and why models sometimes fumble simple things like counting letters
- Follow the three training stages that turn raw text into a helpful assistant
- Get a feel for why models come in different sizes, and what that trades off
- Know the key dials — context window, temperature — and what they do
- Understand why LLMs hallucinate, so you can use them wisely
- See how a raw LLM becomes a real application — search, RAG, tools — with real examples
Predicting the next word — the whole game
Give an LLM the words "The capital of France is" and it predicts the most likely next word: "Paris." Give it "Once upon a" and it predicts "time." That is the entire core skill — guess what comes next.
Now here is the leap. To predict the next word well across all of human writing, the model is forced to learn an astonishing amount: grammar, facts, reasoning steps, the style of a legal letter versus a poem, even how a half-finished joke usually ends. You cannot reliably finish "To make a good argument, you should first…" without having absorbed how arguments work. The simple task secretly demands deep knowledge.
- An LLM's one skill is predicting the next token
- Doing this well across all writing forces it to learn grammar, facts, and reasoning
- It generates text one token at a time, feeding its own output back in to keep going
This is the transformer, not a different thing
Here's the connection worth making explicit, because it's easy to treat "LLM" and "transformer" as two separate topics when they aren't. An LLM is the architecture from Attention & Transformers — specifically, the decoder-only shape: one long stack of transformer blocks (multi-head self-attention, add & normalise, feed-forward, add & normalise, repeated dozens of times), using causal attention so each position can only look backward at what's already been generated.
That one architectural choice — causal, backward-only attention — is why an LLM writes one token at a time, left to right, and can't peek ahead at its own future answer. It isn't a product decision or a UI limitation. It's baked into the maths: when the model is generating token 50, tokens 51 onward simply don't exist yet for it to attend to.
- An LLM is a decoder-only transformer — the same building blocks from the last course, stacked deep
- Causal attention is why generation happens one token at a time, left to right
- "Large language model" = decoder-only transformer + next-token prediction + enormous scale
- Which specific architectural choice forces an LLM to generate text left to right, one token at a time?
- In one sentence, what turns "a transformer" into "a large language model"?
Tokens — the real unit everything runs on
Before any of this can happen, text has to be converted into something a model can actually compute with. That unit is the token, and understanding it explains a surprising number of an LLM's quirks.
7 tokens
Common short words often get their own token — mostly one token per word here, seven tokens for seven "units."
Notice what's happening: common words often get their own token, but rarer or longer words get chopped into fragments the model has seen thousands of times across other words too — which is efficient, but has a real consequence. The model never actually sees the individual letters s-t-r-a-w-b-e-r-r-y in order; it sees a handful of chunks. Asking it to count letters inside a word is asking it to reconstruct spelling from pieces that don't line up cleanly with letters — genuinely awkward for it, not a silly failure.
- Text is split into tokens — chunks somewhere between characters and words, learned from data
- Common words often get one token; rarer words split into smaller, reused fragments
- The model works on tokens, not letters — which is why letter-counting inside words can trip it up
- Tokens are the actual unit of cost and of the context window, not words
How an LLM is made: three stages
A raw next-word predictor is knowledgeable but unruly — it will happily continue offensive text or ramble. Turning it into a helpful assistant takes three stages:
Pre-training — read almost everything
The model reads a vast amount of text (books, websites, code) and learns to predict the next token. This is where it absorbs language and world knowledge. It is hugely expensive and done once. The result is powerful but raw.
Fine-tuning — learn to follow instructions
The model is then trained on examples of good answers to instructions — questions paired with helpful, well-structured responses. This teaches it to behave like an assistant rather than just autocompleting text.
Human feedback (RLHF) — learn to be helpful and safe
Finally, humans rate the model's answers, and it is nudged toward the responses people prefer — more helpful, honest, and harmless. This is the reinforcement learning you met in the ML course, applied to politeness and usefulness.
- Pre-training: read everything, learn language and knowledge (expensive, once)
- Fine-tuning: learn to follow instructions like an assistant
- RLHF: human ratings shape it toward helpful, honest, harmless answers
- How can "predict the next word" lead to a model that can reason through a problem?
- What does each of the three training stages contribute — in one phrase each?
Not all LLMs are the same size
"Large" is doing real work in the name — but "large" isn't one fixed size. Models are built at very different scales for very different jobs, and the size you reach for changes what you're trading off.
Mid-size
Roughly tens of billions of parameters
Runs on
A single capable server with a few GPUs, or a hosted API tier.
Good for
Most production chat and writing assistants, straightforward coding help, summarisation — the sweet spot for a huge share of real applications.
What it costs, roughly
A meaningful but manageable per-request cost — the tier most bootstrapped products actually launch on.
Exact parameter counts for the newest frontier models are rarely published — these are illustrative tiers, not a precise spec sheet. The trade-off shape is what matters: bigger tends to mean smarter and slower and pricier, all three at once.
The pattern to internalise: bigger generally means better reasoning and broader knowledge, but also higher cost and slower answers — all three move together, not independently. A huge share of real production systems deliberately reach for a smaller model for routine requests and only call up to a bigger one for the requests that genuinely need the extra reasoning — a pattern you'll see again, more formally, later in this track.
- LLMs span a real range of sizes, from phone-sized to data-centre-sized
- Bigger tends to mean smarter, slower, and pricier — together, not separately
- Many real systems mix sizes: cheap and fast for routine work, big and slow only when needed
The dials: context window and temperature
Two settings shape how an LLM behaves, and knowing them makes you far more effective.
The context window is how much text the model can "hold in mind" at once — your prompt plus its answer, measured in tokens (Chapter 3). Think of it as the model's desk space. Everything outside the window is invisible to it. If a conversation gets very long, the earliest parts may fall off the desk. This is why feeding the model the right information matters — a whole course later in this track (Context Engineering) is about exactly that.
Temperature controls creativity versus reliability. Low temperature makes the model pick the most likely next word every time — focused, predictable, repeatable (good for facts and code). High temperature lets it take chances — more varied and creative, but riskier (good for brainstorming, bad for a tax calculation).
- The context window is the model's working memory, measured in tokens — only what fits is "seen"
- Long conversations can push early content out of the window
- Temperature trades reliability (low) for creativity (high)
Why LLMs hallucinate — and what to do
LLMs sometimes state false things with total confidence. This is called hallucination, and understanding why it happens is the key to using these tools safely.
Remember: the model predicts plausible next tokens, not true ones. It has no separate "fact-checker" inside. If a fluent, confident-sounding sentence is the most likely continuation, it produces it — whether or not it is correct. It is built to sound right, and usually that overlaps with being right, but not always.
- LLMs predict plausible text, not verified truth — there is no built-in fact-checker
- They are reliable for language and reasoning, unreliable for specific facts
- The fix is to supply real facts, not trust memory alone — which is exactly the subject of the next chapter
- Why does an LLM sometimes sound confident while being wrong?
- For a factual question, would you use low or high temperature — and would you trust the model's memory or give it sources?
From a raw LLM to a real application
Everything so far describes one LLM call in isolation. Almost nothing you actually use is that simple. Here's how a raw LLM becomes a real product, across a spread of genuinely different domains.
Healthcare
"Has this drug interacted badly with anything like it before?"
Why the LLM can't do this alone
A raw LLM's training data goes stale the day training finishes, and it can't tell you which specific patient record or paper it's drawing from — unacceptable when the answer needs to be checked.
What actually gets stacked on top
- 1.LLM (language + reasoning)
- 2.Embeddings + semantic search (find the right studies)
- 3.RAG (answer grounded in real, citable sources)
Every domain here reaches for the same handful of layers, in roughly the same order — search for the right facts, ground the answer in them, and only add tools once the model actually needs to *do* something, not just say something.
Notice the pattern repeating with small variations: embeddings (turning text into meaning-coordinates so "similar meaning" can be found by maths — see Embeddings in Depth) power semantic search, which finds the right facts from a huge pile of documents by meaning rather than exact keyword match. RAG — Retrieval-Augmented Generation — is the pattern of handing those retrieved facts to the LLM as part of its prompt, so the answer is grounded in real, checkable sources instead of the model's possibly-stale memory (directly fixing the hallucination problem from the last chapter). And tools let the model go beyond describing an action to actually taking one — issuing a refund, running a test, checking real-time stock.
This is exactly where the rest of this track, and the Applied AI track alongside it, picks up in real depth — RAG, tool use, agents, and memory each get their own dedicated course from here.
- A raw LLM call is rarely the whole product — most real applications stack layers on top
- Embeddings + semantic search: find the right facts by meaning, not exact keywords
- RAG: ground the model's answer in those real facts instead of its own memory
- Tools: let the model actually do something, not just describe what should happen
- Different domains reach for different subsets of this ladder — rarely all of it at once
- For the customer-support example, why is RAG alone not enough — what else does it need, and why?
- Pick a domain not covered above and sketch which layers its main AI use case would realistically need.