Sunday Latte: How a Language Model Learns

The Unfinished Sentence

The baker put the bread in the ...

Even before the sentence is finished, you probably expect the word oven. Pantry might still be possible. Fridge would be surprising. Telescope would be very surprising indeed.

A language model begins without your expectations. Its numerical settings do not yet contain a useful map of which words tend to follow which other words. During training, it is shown enormous amounts of text with one recurring task: given what came before, assign probabilities to what comes next.

The real continuation then provides an error signal. If the model gave oven a high probability, the error is relatively small. If it preferred telescope, the error is larger. A training algorithm uses that signal to adjust the model's internal numbers. Then it does the task again, at another position, with another piece of text. This happens across vast collections of language, in many batches, through many small updates.

That modest procedure sits underneath systems that can explain a court ruling, draft software, compare scientific papers, or keep a conversation going. The result can feel so far removed from the training task that two misleading stories become tempting. One says the model is only copying phrases. The other says it must have learned exactly as a person does.

Neither story is good enough. Today, we will follow the actual path from one prediction to a trained assistant. We will see what changes inside the model, what does not, and why the word learning is accurate only when we use it carefully.

What Learning Means Here

For this episode, learning has a narrow engineering meaning: a lasting change to a model's parameters that improves some training objective.

Parameters are the numerical values that shape how signals move through the model. A modern language model has a great many of them. Together, they determine which patterns the model can represent and which continuation it will consider likely in a given situation. Training changes those parameters. An ordinary conversation usually does not.

That distinction matters because three different processes are often called learning. First, pretraining changes the model's parameters by exposing it to large and varied collections of text. Second, post-training changes the model further so that it follows instructions, responds helpfully, and behaves in ways its developer wants. Third, a prompt can make the model use a new fact or imitate an example during the current request. The third process can look like rapid learning, but the underlying parameters normally remain unchanged.

We are also looking at one particular family: autoregressive language models, the kind commonly used to generate text. Autoregressive means that the model produces a sequence one token at a time, with each new token conditioned on the tokens already present. Other language models use other objectives. There are systems trained to reconstruct hidden words, for example. Those matter, but they are outside today's path.

And a token is not necessarily a word. It may be a whole common word, part of an unusual word, punctuation, or another unit selected by the model's tokenizer. So next-token prediction is not simply a vocabulary quiz. It is a repeated attempt to predict the next unit in every kind of structure the training data contains: prose, dialogue, lists, equations, software, and much more.

One Prediction, One Error Signal

Return to the unfinished sentence. The words already present are divided into tokens and converted into numerical representations. Those representations pass through the model. At the end, the model produces a score for every token it might place next. The scores become probabilities: perhaps oven receives sixty per cent, pantry fifteen per cent, fridge five per cent, and many unlikely alternatives divide the remainder.

During pretraining, the system already knows which token really came next in the source text. It compares the model's probability for that observed token with the result it wanted. A confident correct prediction produces a low loss. A confident wrong prediction produces a high one. The formal calculation is commonly called cross-entropy loss, but the important point is simpler: the loss turns the quality of the prediction into a number that training can reduce.

This does not happen only at the final blank. A sequence supplies many training positions. After seeing the baker, the model predicts what could follow. After seeing the baker put, it predicts again. The process can calculate errors across many positions and many sequences in a batch before making an update.

Notice what the target does and does not say. It says which token appeared in the training text. It does not certify that the sentence is true, kind, unbiased, legal, or wise. If the source contains a false claim, predicting that false claim accurately still reduces the pretraining loss. If it contains fictional dialogue, the model is rewarded for continuing the fiction. If it contains a programming mistake, that mistake is part of the observed sequence too.

This is a central reason language models can be both remarkably capable and confidently wrong. To predict well across many kinds of text, the model benefits from learning grammar, style, facts, patterns of argument, and relationships among concepts. But the training objective itself asks what text is likely here, not what statement deserves belief. Truth can help prediction without becoming the definition of success.

How the Error Reaches the Weights

A loss is only a measurement. Training also needs to know how the model should change.

Backpropagation supplies that information. Working backwards through the computation that produced the prediction, it calculates how a tiny change in each parameter would affect the loss. The resulting collection of directions is called a gradient. An optimizer uses that gradient to make an update intended to lower the loss on future predictions.

The update is normally small and distributed. Many parameters move together. One sentence does not become one new database row, and nobody points to a particular number and tells it to store the fact that bread goes into an oven. The useful representation emerges from the interaction of many updates produced by many examples.

That also means an individual example does not act alone. Training usually gathers examples into batches. Their contributions are combined, and the optimizer chooses one step based on that aggregate signal. Later batches can reinforce, refine, or partially counter what earlier batches encouraged. The order of the data, the learning rate, the optimizer, and many other engineering choices affect this process.

Here is the whole step in compact form. Text enters as tokens. The model predicts probability distributions for following tokens. The observed tokens produce a loss. Backpropagation calculates gradients. The optimizer adjusts the parameters. Then a new batch begins.

Repeat that loop enough times across enough varied material and the model becomes better at more than completing familiar phrases. It must handle dependencies across a sentence, maintain structures across paragraphs, distinguish styles, track relationships, and apply patterns in combinations it may not have seen exactly before. This is why saying that it merely retrieves the nearest stored sentence is wrong. Yet saying that it stores clean, inspectable concepts is wrong too. What has changed is a large numerical system whose behaviour reflects the regularities training rewarded.

From One Step to Pretraining

The unfinished sentence gave us one easy pattern. Real pretraining ranges across radically different material. A legal judgment rewards attention to definitions and qualifications. Dialogue rewards turn-taking and social cues. Source code rewards exact syntax and dependencies. A scientific paper rewards connections among methods, evidence, and claims. The same prediction objective encounters all of them.

Variety is useful because a pattern seen in many settings is more valuable than a phrase tied to one page. The model may encounter the same relationship expressed formally, casually, in a question, and in an example. Training can then shape representations that support useful generalization rather than only exact recall.

But the composition of the corpus matters. Repeated documents can cause a model to encounter the same passage far more often than intended. Low-quality material can reinforce errors. Material that later appears in an evaluation can make a benchmark look easier than it really is. Research on deduplicating training data has found that removing repeated material can reduce verbatim memorization and achieve equal or better accuracy with fewer training steps.

Memorization does still occur. Under some conditions, a model can reproduce distinctive training passages word for word. That is important for privacy, copyright, and evaluation. It is not a complete account of ordinary model behaviour. A model can also answer new questions, combine patterns, and operate on text that was never present as one stored passage.

So two simple descriptions both fail. The corpus is not a clean library that remains searchable inside the weights. And the training data does not disappear into a vague cloud without leaving recoverable traces. The parameters encode distributed statistical structure, including some factual associations, and sometimes exact sequences. Access to that structure is uneven. The model may produce a fact correctly in one phrasing and miss it in another. It does not automatically know where the information came from, and it cannot supply provenance merely because an association influenced its answer.

Why Size, Data, and Compute Travel Together

Training becomes more capable not through one ingredient, but through a relationship among model capacity, data, and computation.

A larger model has more capacity to represent complicated patterns. More training data provides more examples from which those patterns can be learned. More computation allows the training process to make use of the model and the data. Starve any one of the three and the others can be wasted.

Early scaling-law research found strikingly regular reductions in language-model loss as model size, dataset size, and training compute increased across the regimes being studied. That helped developers estimate how performance might change before paying for an enormous training run. It did not establish that every capability improves smoothly, that every dataset is equally useful, or that scaling can continue without limit.

Later work made an especially important correction to a common instinct. If a fixed compute budget is spent mostly on making the model larger, while the model sees too little data, the result can be undertrained. A somewhat smaller model trained on substantially more tokens may use the same compute more effectively. The lesson is not that smaller is always better. It is that parameter count cannot be judged in isolation.

Quality complicates the picture again. A billion repeated or misleading tokens are not equivalent to a billion carefully selected, diverse ones. Data filtering, deduplication, language balance, and the mixture of domains all shape the resulting behaviour. A model can be strong in English and weaker in another language partly because the quantity, quality, or diversity of its training material differed.

Scaling laws are therefore useful maps of measured territory, not promises about every destination. They explain why modern training is planned as a joint allocation problem. How much model can be trained well, on how much suitable data, with the computation available? The answer influences both the overall capability and the uneven places where a model still struggles.

Why a Base Model Is Not Yet an Assistant

At the end of pretraining, a model can be an impressive continuer of text without being a dependable conversational assistant. Ask it a question and it may answer, extend the question, imitate a forum thread, or continue in some other plausible way. Pretraining taught it to model text, not to treat every user message as an instruction that deserves a useful response.

Post-training reshapes that behaviour. One method supplies demonstrations: prompts paired with responses that exemplify the desired kind of answer. Training on those pairs makes instruction following more likely. Another method gathers human preferences between possible responses. Those judgments can then guide optimization through reinforcement learning from human feedback, direct preference optimization, or another technique. Current developers combine methods in different ways; there is no single universal recipe.

It is tempting to summarize this as pretraining teaches knowledge and post-training teaches manners. That is memorable and incomplete. Post-training can influence whether a model attempts a task at all, how it reasons through it, which information it emphasizes, how it handles uncertainty, and whether it uses tools. It can improve some capabilities and weaken others. It can also encourage an answer to sound confident without ensuring that the answer is true.

The same caution applies to the word feedback. During ordinary pretraining, the next observed token supplies the target automatically. During post-training, feedback may come from curated examples, human comparisons, automated checks, model-generated critiques, task outcomes, or mixtures of these. The exact recipe matters.

What remains constant is that successful post-training changes parameters. It is part of the lasting model, unlike a reminder typed into one conversation. It can turn a capable base model into something much closer to the assistant people recognize. But it cannot erase the limits of the data and objectives beneath it, and it does not guarantee truthfulness. It changes which behaviours training rewards.

Weights, Context, and Retrieval

Suppose you tell an assistant about a new company that did not exist when its model was trained. You provide a short description and ask for an analysis. The model may use the information immediately and well. Did it learn the company?

In the lasting, parameter-changing sense we defined earlier, normally no. Your description is part of the current context: the material supplied for this computation. It can shape every token of the answer without altering the trained weights. Start a fresh request without that description, and the information may be absent.

Examples work the same way. You can show the model two well-formed entries and ask it to produce a third. Its response may adapt sharply to the pattern. This is often called in-context learning. The behaviour changes within the request, but there need not be a gradient, an optimizer step, or a permanent update.

Retrieval adds another route. A surrounding system searches an external collection, selects passages that appear relevant, and places them into the context. The model can then answer using a document that was never part of its training data. This is powerful because the external collection can be updated and can preserve sources. It is also fallible. The search may retrieve the wrong passage, the relevant document may be missing, or the model may misread what it receives.

We can now separate three sources of an answer. The weights reflect patterns established during pretraining and post-training. The current context contains the conversation, instructions, examples, and any text supplied directly. Retrieval selects external material and adds it to that context. Only the first category necessarily represents lasting learning by the model itself.

The boundaries can be more complicated in systems designed for online updating, and products may store memories outside the model for later conversations. But the distinction remains useful. When an answer changes, ask what changed. Were the weights updated? Was different information placed in the request? Or did a search system fetch a different source? These mechanisms can produce similar visible behaviour while having very different reliability, cost, and privacy implications.

What Learning Does, and Does Not, Mean

We can now finish the sentence we started.

The baker put the bread in the oven. The continuation feels obvious because human experience and language make it familiar. For an autoregressive language model, that expectation is the result of training. Across many sequences, prediction errors produced gradients; optimizers used those gradients to adjust parameters; repeated updates made useful structures and relationships easier to represent. The model learned in the engineering sense: its lasting internal settings changed in ways that improved its performance.

That statement is substantial. It is also limited. It does not mean that one parameter contains oven, that the training corpus survives as an orderly database, or that the model checks each continuation against reality. It does not mean a new fact in today's prompt will still be present tomorrow. And it does not tell us whether the system understands bread, heat, or purpose as a person does.

The opposite dismissal goes too far as well. Calling the model merely autocomplete hides the scale and structure of what successful prediction requires. Generalizing across unfamiliar text, following an instruction, or combining several supplied facts is real behaviour that deserves a precise explanation. We gain nothing by inflating it into a human mind, and nothing by pretending it is a telephone keypad guessing the next word.

So keep one diagnostic question for the next time an artificial intelligence system surprises you: where did this behaviour come from?

It may come from patterns formed during pretraining. It may come from post-training that rewarded a particular kind of response. It may come from instructions and examples in the current conversation. Or it may come from a document retrieved moments ago.

Those routes can meet in the same answer, but they are not the same process. Knowing which one you are looking at is the beginning of understanding what the system has learned, what it is only holding for now, and where its next mistake may come from.