How Language Models Work: Training, Inference, Tokens and Context

A friend asks, "If it just predicts the next word, how does it write a working function?" It is a fair question, and the honest answer is that nobody finds it entirely obvious. But you do not need the full theory to use these tools well. You need a small set of accurate ideas that predict how the tool will behave.

That is what this article gives you. Each idea comes with a practical consequence, so you can use it on Monday.

• What "predicting the next token" means, and why it can produce useful work.
• What tokens are, with a small program that shows the idea.
• The difference between training and inference.
• How instruction-following and "reasoning" modes are added on top.
• What the context window is, and why it explains most "forgetting".
• Seven practical consequences for how you work.

Think of your phone keyboard suggesting the next word. If you type "see you", it might suggest "soon". It learned from lots of text that "soon" often follows. A language model does something similar, at a vastly larger scale and with far more context.

Given a piece of text, the model produces a probability for every possible next piece. "The capital of France is" produces a very high probability for " Paris". "My favourite colour is" produces a spread of probabilities across many colours. The system then chooses one, appends it to the text, and repeats. A long answer is just this loop run many times, each step looking at everything so far, including the words it just produced.

Three consequences already follow:

1. It builds answers one piece at a time, left to right. It does not draft the whole answer in its head and then write it down in the way a person might. This is one reason that early mistakes can carry forward.
2. There is usually some randomness in the choice. If the model always picked the single most likely piece, answers would be repetitive. Many systems pick from among the likely options. That is why asking the same question twice can give different wording, or sometimes different content.
3. It is optimised to be plausible. Training rewards text that looks like good text. Plausible and true overlap a lot, because most written text is about true things, but they are not the same.

Models do not read letters or whole words. They read tokens, which are chunks of text from a fixed list the model was built with. Common words are often one token. Rare words, names, numbers and code are often split into several.

The program below is a toy tokenizer. It uses a tiny made-up list of pieces and always takes the longest piece that fits. Real tokenizers have tens of thousands of pieces learned from data, so their exact splits differ. The point is only to show that tokens are not words.

# File: toy_tokenizer.py# A toy tokenizer: greedy longest-match against a tiny made-up vocabulary.# Real tokenizers learn tens of thousands of pieces from data. This only shows the idea.VOCAB = ["un", "believ", "able", "token", "ize", "r", "s", " the", " cat", " sat",         " on", " mat", ".", " ", "a", "b", "c", "d", "e", "f", "g", "h", "i", "j",         "k", "l", "m", "n", "o", "p", "q", "t", "u", "v", "w", "x", "y", "z"]def tokenize(text):    pieces = []    i = 0    while i < len(text):        match = None        for piece in sorted(VOCAB, key=len, reverse=True):            if text.startswith(piece, i):                match = piece                break        if match is None:            match = text[i]  # unknown character becomes its own piece        pieces.append(match)        i += len(match)    return piecesfor sentence in ["unbelievable", "tokenizers", " the cat sat on the mat."]:    tokens = tokenize(sentence)    print(f"{sentence!r} -> {len(tokens)} tokens: {tokens}")

'unbelievable' -> 3 tokens: ['un', 'believ', 'able']'tokenizers' -> 4 tokens: ['token', 'ize', 'r', 's']' the cat sat on the mat.' -> 7 tokens: [' the', ' cat', ' sat', ' on', ' the', ' mat', '.']

Notice that one long word became three tokens, and that a short common sentence became seven. Two more things follow from how tokens work:

• Limits and costs are counted in tokens, not words. Providers often quote rough rules of thumb for how many tokens an English word takes, and these vary by model and language. Text in some other languages, and also code and long numbers, can use noticeably more tokens for the same meaning. If a tool tells you a limit, look at its own token counter rather than guessing.
• Models can be clumsy with letter-level tasks. If a model reads "strawberry" as two or three chunks, questions like "how many r's are in it?" ask it about something it cannot directly see. Counting letters, reversing words and exact character limits are classic weak spots. For those, use a tool that counts, such as a spreadsheet or a short script.

These two words appear constantly, and they mean different things.

The practical points:

• When you chat, you are not teaching the model in real time. Within one conversation it appears to "learn" something you said, but that is only because your words are now in its context. Start a fresh conversation and, unless the product has a memory feature, it knows nothing of it.
• Some products may use conversations to improve future models. This is a product policy question, not something about how models work. Policies differ and change, so check each product's current data settings, which later articles revisit.
• Training data has a cutoff. The model's built-in knowledge stops at some point. It does not know about later events unless the product gives it a search tool or you paste the information in. Models are not always aware of their own cutoff and can speak confidently about things that changed.

A model trained only to continue text is not yet a good assistant. Ask it a question and it might continue with more questions, because that is a plausible continuation of a list of questions. Companies add further stages, described here at a high level and without product-specific claims:

1. Pretraining. The broad stage on huge amounts of text, which produces general language ability and a large store of knowledge.
2. Instruction tuning. The model is further trained on examples of requests paired with good responses, so it learns to follow instructions and answer in conversation.
3. Preference tuning. Human reviewers, and sometimes other models, compare candidate answers, and the model is nudged towards the ones judged more helpful and safer. You will often see this called reinforcement learning from human feedback (RLHF) or related names.
4. Safety and policy layers. Rules and filters in the model and in the product that discourage harmful outputs.

One effect to remember: because preference tuning rewards answers that people rate well, models can lean towards pleasing, agreeable, confident answers. This is why an assistant may agree with a wrong claim in your question, or sound sure when it is not. Later articles teach you to counter it, for example by asking for the strongest objections to its own answer.

Many products now offer models or modes that spend extra computation working through a problem in intermediate steps before giving a final answer. They often do better on multi-step problems such as maths, planning and difficult code. Two cautions:

• Providers' own guidance notes that such models can respond differently to prompts than standard ones. For example, OpenAI's prompt documentation says general models tend to benefit from very precise instructions, while reasoning models do better with higher-level goals and room to work out the details. Prompting advice is therefore not universal, so check what your tool's documentation recommends.
• The visible "reasoning" is a useful clue but not proof. A model can produce a tidy chain of steps that reaches a wrong answer. Check the result, not the confidence of the steps.

The context window is the amount of text, counted in tokens, that the model can take into account in one go. It includes your current message, the earlier parts of the conversation that the product sends again, any pasted documents or uploaded files, and instructions the product adds behind the scenes. It also includes the answer being generated.

The most important sentence in this article may be this one: the model does not remember your conversation; the product re-sends it each turn. Each reply is produced fresh, reading the recent conversation as one long input. That explains many behaviours:

• When a very long conversation drifts or forgets early instructions, the early text may have been dropped, shortened or simply overshadowed.
• When you start a new chat, the model has none of the previous context, because it is not in the window.
• When you paste a long document, you are using up context, which leaves less room for conversation.

Two different kinds of knowledge are in play, and mixing them up is a common source of errors:

The best working habit follows directly: for anything where facts matter, supply the facts. This idea is called grounding, and Give AI the Right Context: Source Material and Long Documents builds a whole workflow around it.

Bigger windows let you paste whole reports. But researchers have found that models do not use long inputs evenly. A widely cited study, "Lost in the Middle", found that performance on tasks involving relevant information in a long input was often best when that information was at the beginning or end, and worse when it was in the middle. Newer models may improve on this, so treat it as a caution rather than a law. The practical response is simple: keep the context focused, put your key instructions where they are hard to miss (often at the end, repeated briefly), and ask the model to quote the passages it used, so you can check that it found the right ones.

1. Never rely on built-in knowledge for facts that matter. Provide sources, or use a tool that retrieves them, and check.
2. Expect variation. If an answer matters, ask twice, or ask it to explain its reasoning, and compare.
3. State the date for time-sensitive questions, and do not assume the model knows what is current.
4. Use tools for counting, arithmetic and exact text operations. Spreadsheets and scripts do not guess.
5. Restate key instructions in long conversations, or start a fresh chat with a short summary of what matters.
6. Keep prompts focused. Irrelevant text uses up context and can distract the model.
7. Be careful what you put in context. Anything you paste is processed by the product. Module 7 covers privacy.

• Assuming the model "knows" a document you have not given it. If it is not in the context, the model may produce a plausible guess about it.
• Believing the model "learned" from your correction. It used the correction in the current context. It will not carry it into other chats.
• Treating a long chat as reliable memory. The longer it runs, the more likely something important is lost or ignored.
• Treating the word "reasoning" as a guarantee. It is a method that often helps, not a proof of correctness.
• Asking letter-counting and exact-length questions, then being surprised by the answer.

• Next: Why AI Sounds Right and Still Gets Things Wrong uses this mental model to explain hallucinations and what to do about them.
• For the practical side of context, go to Give AI the Right Context: Source Material and Long Documents.
• For a shorter overview with the same ideas, see How Do AI Chatbots Like ChatGPT and Claude Actually Work?.