What a Language Model Is

"Anyone speaking a language possesses, implicitly, an enormous knowledge of the statistics of the language." — Claude Shannon, Prediction and Entropy of Printed English (1951)

Ten volumes ago this Library started with a question about machines: what is a computer, and how does a pattern of voltages become a program? Everything since has been an answer to that question at increasing scale — instructions became languages, languages became frameworks, frameworks became services, services became systems that stay up while the world hammers on them. You learned to store data and query it, to design an API, to ship a container, to prove your work with tests. Every one of those chapters shared an assumption so deep it never needed stating: that a computer does exactly what you tell it, and that the engineer's job is to know precisely what to tell it.

This volume is about a machine that breaks that assumption. Not because it is magic, and not because it is unpredictable in some mystical sense, but because the thing you are programming is no longer a set of instructions. It is a statistical model of language, and you steer it with words rather than with syntax. The skills transfer — you will find that everything you learned about latency budgets, error handling, caching, observability and testing matters more here, not less — but the object at the centre is genuinely new, and most engineers meet it with either too much awe or too much dismissal. Both are expensive mistakes.

So we are going to start where every good engineering education starts: by opening the box. Not the whole box — there is real mathematics inside a large language model, and you do not need it to build excellent products, any more than you need semiconductor physics to write a web server. But you need an accurate mental model, and "accurate" is the operative word. Almost everything that goes wrong in an AI feature — the runaway costs, the hallucinated invoice numbers, the assistant that forgets who the user is, the demo that dazzles in a meeting and collapses in production — traces back to an engineer holding a wrong model of what this thing is. Get the model right and the failures become predictable, which is to say preventable.

Here is the whole of it, stated plainly, and if you retain nothing else from this chapter retain this: a language model is a stateless function from a sequence of tokens to a probability distribution over the next token. That is not a simplification for beginners. That is what it is. Everything else in this volume — prompting, retrieval, agents, memory, evaluation, cost control — is an engineering response to the consequences of that one sentence. The rest of this chapter earns it, clause by clause, and by the end you will be able to derive most of the volume's later concerns yourself, from first principles, the way you can derive the need for an index once you understand a table scan.

The function at the centre

Forget everything you have read about artificial intelligence for a moment and consider a much smaller problem, one you could solve this afternoon.

You have a large amount of text. You want to write a function that, given the beginning of a sentence, tells you what is likely to come next. Not what must come next — language does not work that way — but a ranked set of possibilities with numbers attached. Given the cat sat on the, your function should think mat is plausible, floor is plausible, refrigerator is unlikely but grammatical, and and is unlikely because the phrase wants a noun.

That is the entire task. It has a name in the literature — language modelling — and it is genuinely all a large language model does. The scale is enormous and the internals are sophisticated, but the interface is exactly that: text in, ranked next-token possibilities out.

The cheapest possible version is a counting exercise, and building it is worth ten pages of explanation. Take a corpus, count which word follows which, and normalise the counts into probabilities.

Run that and look carefully at what came back. After sat, the model is completely certain the next token is on — it never saw anything else. After the, it spreads its belief across six possibilities, with cat and dog leading because they appeared most often. After elephant it has nothing at all, because the word never occurred.

This is a language model. A terrible one, but not a different kind of thing from the one you will call over HTTPS in the next chapter. Both take a context and return a distribution. The differences are quantitative and architectural rather than categorical: the real one was trained on a substantial fraction of the written internet rather than six sentences; it conditions on thousands of previous tokens rather than one; and its internals learn structure rather than merely tabulating counts. But the shape of the interface is identical, and the shape is what you program against.

Why counting is not enough, and what replaced it

The counting model fails for a reason worth understanding precisely, because the reason explains the architecture that replaced it.

Extend the idea. Instead of conditioning on one previous word, condition on two, or five, or fifty — an n-gram model. Longer context should mean better prediction, and up to a point it does. But the table explodes. With a vocabulary of 50,000 tokens, a two-token context needs 2.5 billion rows; a three-token context needs 125 trillion. Worse, almost all of those rows would be empty. Most five-word sequences that will ever be written have never been written before. The model has no row for them, so it has nothing to say — exactly as our toy had nothing to say about elephant. Counting cannot generalise. It can only recall.

What was needed was a model that treats similar contexts similarly — that having learned about the cat sat on the, knows something about a dog rested on a without having to have seen it. That requires representing tokens not as opaque table keys but as points in a space where nearness means relatedness, and it requires learning a function over that space rather than a lookup table. Chapter 3 is entirely about that space. For now, hold the idea: the model does not store sequences, it learns a compressed function that generates plausible sequences, and compression is precisely what forces generalisation. A table that memorises has no pressure to find structure. A function with a fixed budget of parameters, asked to predict a trillion tokens, has no choice but to discover that nouns exist, that verbs agree with subjects, that Lagos is a city, that code inside a for loop is usually indented, and that a question mark tends to be followed by an answer.

That last point deserves emphasis, because it is where the apparent intelligence comes from and it is the most commonly misunderstood thing about these systems. Nobody programmed grammar into the model. Nobody wrote a rule saying that a try needs a catch. Those regularities were the cheapest way to reduce prediction error across an enormous corpus, so the optimiser found them. Push that far enough — enough data, enough parameters, enough compute — and the regularities the model must discover in order to keep predicting well start to include things that look uncomfortably like reasoning. To predict the next token in a mathematical proof, it helps to track the argument. To predict the next line of a function, it helps to model what the function is for. The model was never asked to reason. Reasoning, in a limited and unreliable form, turned out to be a useful compression strategy.

Attention, at the level an engineer needs

The architecture that made this work is the transformer, and you can hold a genuinely useful picture of it without touching a matrix.

The problem with processing a sequence is deciding what matters. In the sentence "the invoice that Adaeze sent last Tuesday, which the finance team rejected twice, is still unpaid", the word unpaid needs to connect to invoice — eleven tokens back, across two subordinate clauses. Earlier architectures processed sequences step by step, carrying a running summary forward, and information decayed with distance. Long-range connections were exactly what they were worst at.

Attention inverts the arrangement. Every token gets to look at every other token in the context simultaneously and decide, for itself, how much each one matters to it. unpaid looks across the sentence and attends strongly to invoice, weakly to Tuesday, barely at all to which. There is no decay with distance, because there is no travel — the connection is direct. Stack that operation a few dozen times, and each layer can build relationships on top of the relationships the layer below discovered.

Two consequences of this design will follow you through the entire volume, so note them now:

Cost grows with the square of the sequence length. If every token attends to every other token, n tokens require roughly n² comparisons. Double the context, quadruple the work. This is why context windows are finite, why long prompts cost more than their token count alone suggests, and why the industry pours so much effort into making attention cheaper. Chapter 2 turns this into money.

Everything is computed in parallel. Because tokens do not need to be processed in order, training parallelises across enormous machines — which is what made models this large possible at all. Note the asymmetry, though: training parallelises beautifully, but generation cannot. Each new token depends on the one before it, so text comes out one token at a time, sequentially. That asymmetry is why a model can be trained in weeks on thousands of GPUs and still make you wait while it types.

Generation: the loop that looks like thought

We now have the pieces to explain what happens when you send a prompt and watch prose appear.

The model produces a distribution over the next token. Something picks one. That token is appended to the sequence. The whole, now one token longer, is fed back in. Repeat until a stopping condition. That is generation, in full.

Look at that loop and notice what it tells you. The model does not plan a sentence and then write it. It does not know, when it emits its first token, how the sentence will end. Each token is chosen with the whole preceding text as context and no view of what comes after. That fluent paragraph was assembled one step at a time by a process with no outline — which is both the source of its flexibility and the reason it can write three confident sentences into a claim it cannot support and simply keep going.

Notice too where the decision actually happens. The model returns a distribution; it does not return a token. The choosing is done by a separate, simple, entirely conventional piece of code called the sampler, and the sampler is yours to control. This is the most underrated fact in applied AI: a significant fraction of what people attribute to "the model's personality" is a sampling parameter.

The distribution, and the knob that shapes it

Raw model outputs are unnormalised scores called logits — one per vocabulary entry, any real number. Turning them into probabilities uses softmax, which exponentiates and normalises. Softmax takes one parameter that matters enormously to you: temperature, which divides the logits before exponentiating.

Read the numbers those tests assert. At temperature 0.2 the model is over 95% committed to mat and gives refrigerator less than one chance in ten thousand. At temperature 8 the distribution has flattened so far that refrigerator — a token the model scored negatively — gets better than a one-in-ten shot. Same model, same context, same logits. One divisor.

This is why "temperature 0 for extraction, higher for creative writing" is standard advice, and it is also why that advice is slightly wrong in an important way. Temperature does not make the model more or less creative. It makes the sampler more or less willing to pick tokens the model thought were worse. Sometimes what you get is a fresh turn of phrase. Sometimes what you get is a fabricated citation. The knob does not know the difference, and neither does the model.

Greedy, temperature, and top-p

With a distribution in hand there are several sane ways to choose. Building all three settles the concepts permanently.

The last test in that block is the important one philosophically. With a fixed seed, sampling is perfectly reproducible — the randomness is a choice, not a property of the model. The model's forward pass is deterministic arithmetic. Nondeterminism enters at the sampler, and in a hosted API you do not own the sampler, which is why the same prompt can return different text on two consecutive calls even at temperature 0 (floating-point non-associativity in batched GPU work supplies the rest). Vol 10 taught you to hate flaky tests. You are now building on a component that is flaky by construction, and Part VI of this volume exists because of it.

Notice also the elegance of top-p compared with temperature. Temperature reshapes the entire distribution, including giving nonsense a chance. Top-p leaves the good tokens' relative odds alone and simply deletes the tail — and it adapts: when the model is confident, the nucleus is one token and generation is effectively greedy; when the model is genuinely torn, the nucleus widens. That adaptivity is why top-p is usually the better default.

Stateless: the fact that shapes everything

We come to the clause that most engineers hear, nod at, and then design as though they had not heard.

The model holds nothing between calls. No session. No conversation. No memory of you. Each request is a pure function evaluation: tokens in, distribution out, nothing retained. The ChatGPT-style experience of a continuing conversation is a complete illusion, maintained by a very ordinary piece of application code that stores the messages and re-sends all of them on every turn.

That fake model is a caricature in its internals and exactly right in its contract. The real one behaves the same way: whatever is in the array exists, whatever is not does not.

Sit with the consequences, because you can now derive most of this volume:

• The conversation must be stored and re-sent by your code, which means memory is an application concern, not a model feature. Part V's chapter on memory is a design problem, not an API call.
• Re-sending everything means cost grows with conversation length, and turn N carries roughly 2N−1 messages. That is Chapter 2, and it is where budgets die.
• The context window is finite, so a long enough conversation must eventually drop something, and choosing what to drop is a product decision with correctness consequences.
• If the model only knows what is in the prompt, then to make it know your company's refund policy you must put the policy in the prompt — and finding the right policy to insert, out of ten thousand documents, is retrieval. That is the whole of RAG, and Part IV follows from this sentence.
• If the model cannot act, only emit text, then giving it the ability to act means letting it emit a request to act which your code executes and feeds back. That is tool calling, and Part V follows from this sentence.

None of that had to be memorised. It follows.

Base, instruction-tuned, and chat models

One puzzle remains. A next-token predictor trained on internet text should, when given "How do I reset my password?", plausibly continue with more questions — that is what an FAQ page looks like. Yet the model you call answers the question. Why?

Because the thing you call has been through additional training after pre-training. A base model is the raw next-token predictor: give it a question and it may well continue with another question, or with the rest of the web page it thinks it is in the middle of. It is a text completer, and working with one directly is a strange experience.

An instruction-tuned model has then been trained on many examples of instructions paired with good responses, which shifts its idea of "what usually follows" so that what usually follows an instruction is compliance. A chat model adds a structured conversation format — the system / user / assistant roles you will meet in Chapter 6 — so that turns are delimited and a persistent instruction channel exists. Layered on top is alignment training, which pushes the model toward being helpful and away from harm.

Two things follow. First, the assistant persona is trained behaviour, not an intrinsic property — which is why prompt injection works at all, and why Part VII has a chapter on it. Second, that roles have meaning to the model is a learned convention rather than a hard boundary, and every security control you build on top of it needs to be designed with that in mind.

What it is, and what it is not

Because the interface is language, people project the wrong metaphors onto it. Naming the wrong ones precisely is the fastest route to good judgement.

It is not a database. A database returns what was stored, or an error. A model returns the most plausible continuation, always, whether or not the answer is in there. There is no NOT FOUND. Facts are smeared across billions of weights, not filed in rows, and there is no query that distinguishes "recalled" from "confabulated".

It is not a search engine. Search retrieves documents that exist and can be checked. A model generates text that resembles what a document would say. When it produces a URL, that URL is a plausible-looking string, and the fact that plausible URLs are frequently real ones is a coincidence you cannot depend on.

It is not a calculator. Arithmetic is character prediction here. It has learned that 2 + 2 = is followed by 4 overwhelmingly often. For 4,891 × 372 it has no such regularity to lean on, and it will produce a number of about the right length and shape. Chapter 2 explains why digit tokenization makes this worse than you would expect. The engineering answer is never "prompt it harder" — it is to give it a calculator, which is Part V.

It is not deterministic in practice, even at temperature 0, and it is not a program: there is no source to read, no branch to step through, no stack trace. Debugging is empirical.

Set against that, be equally clear-eyed about where it is genuinely excellent, because dismissal is as costly as credulity. Language transformation — summarising, translating, changing register, reformatting — is where these models are extraordinary, because the source material is right there in the prompt and the task is a mapping rather than a recall. Structured extraction from messy input, classification against fuzzy criteria, drafting a first version of anything, and code generation with a human reviewing are all areas where a competent engineer with a model beats the same engineer without one, comfortably.

The pattern worth internalising: the model is strong when the information it needs is in front of it, and weak when it must supply the information itself. Almost every architectural decision in the rest of this volume is an attempt to move your problem from the second category into the first.

Common Mistakes

• Treating the model as a knowledge base. Asking "what is our refund policy?" and shipping the answer is asking a plausibility engine for a fact. The model will always answer, and its confidence carries no information about correctness. If a fact matters, put it in the prompt and cite the source you inserted — the pattern Part IV builds out in full.

• Assuming the model remembers. Engineers build a chat UI, send only the newest message, and cannot understand why the assistant is amnesiac. Others do send history and are then baffled when the model "forgets" something from forty turns ago — it was silently trimmed to fit the window. Memory is your code's job. Own it explicitly, log what you actually sent, and make truncation a visible decision rather than an accident.

• Blaming the model for the sampler. "The model keeps making things up" is often "we are running at temperature 1.2 because it was in the example we copied." Before you change models or rewrite prompts, look at your sampling parameters. For extraction, classification, and anything with a correct answer, start at temperature 0 and only raise it if you can articulate what you gain.

• Expecting determinism. Two identical calls can return different text, so a test asserting exact output equality against a live model is flaky by construction. Assert on structure, schema, and semantic properties instead — and build the eval discipline of Part VI rather than pretending unit-test habits transfer unchanged.

• Using it for arithmetic and other exact operations. Totals, tax, date differences, sorting a list precisely. It will produce something confident and shaped correctly. Give it a tool, or compute the value in your own code and hand it in.

• Confusing fluency with competence. These models write beautifully, and human beings are wired to read fluency as expertise. A well-written wrong answer is more dangerous than a badly-written one because it disarms the reader's scepticism. Design your interfaces to make verification easy — show the retrieved source, surface the confidence, keep the human in the loop where the stakes justify it.

• Reaching for fine-tuning as the first answer. "The model doesn't know our product" almost always means "we haven't put our product's documentation in the prompt", not "we need to retrain it." Chapter 4 gives the decision procedure; the default answer is prompting, then retrieval, and only then fine-tuning.

Interview Corner

Summary

• A language model is a stateless function from a sequence of tokens to a probability distribution over the next token. Every capability and every failure in this volume follows from that one sentence.
• Generation is a loop: predict a distribution, sample one token, append, repeat. The model does not plan ahead — it has no view of how a sentence will end when it emits the first token.
• Counting-based models cannot generalise because most sequences are unseen. Compression forces structure: a model with finite parameters predicting a trillion tokens must discover grammar, facts and patterns, and that discovery is where apparent reasoning comes from.
• Attention lets every token consult every other token directly, which is why long-range dependencies work — and why cost grows with the square of sequence length, making the context window finite and long prompts expensive.
• The model returns a distribution; your sampler chooses. Temperature reshapes the whole distribution, top-p deletes the tail adaptively, greedy always takes the favourite. Much of what people call model behaviour is a sampling parameter.
• Statelessness is the load-bearing fact. Memory, cost growth, context limits, RAG and tool use are all engineering responses to it, and you can derive each one from the fact alone.
• The assistant persona is trained behaviour layered on a base text-completer, not an intrinsic property — which is why prompt injection is possible and why role boundaries are a convention rather than a security control.
• The model is strong when the information it needs is in the prompt and weak when it must supply that information itself. Every architecture in this volume moves your problem toward the former.

In the next chapter, Tokens, Context & Cost, we open the word we have been using freely all along. A token is not a word and not a character but a subword unit produced by an algorithm we will build from scratch, and its details govern your context window, your latency, your invoice, and — uncomfortably — how much more it costs to serve a user writing in Yoruba than one writing in English. Statelessness was this chapter's punchline. Next it becomes the bill.