Free lesson · AI Engineering

What Are Large Language Models?

Easy10 min readaillmrag

What Are Large Language Models?

The Bug That Was a Belief

In my first year at Meta, an engineer on a partner team filed what he was convinced was a model bug. His feature asked the model for the release year of an internal tool, and the model confidently answered 2019. The correct answer was 2021. His bug report said, and I am quoting from memory because the phrasing stuck with me: "The model's database has the wrong value for this fact. Where do we file corrections?"

There is no database. There is no fact. There is no "value" stored anywhere that anyone could correct. The question was not wrong because he misunderstood our infrastructure - it was wrong because he misunderstood what a language model is. And I want to be careful not to be condescending about this, because his mental model - the LLM as a very large lookup table of facts - is the default mental model almost every engineer walks in with. It is also the source of a whole family of production bugs, wasted architectural effort, and doomed feature designs.

Module 1 taught you to use the model while treating it as a black box. That was deliberate - you can drive a car before you understand combustion. But you cannot diagnose a car without it, and you cannot make good architectural decisions about a component whose nature you have wrong. This module opens the box. This first topic replaces the lookup-table mental model with the correct one, and then walks through what that correct model predicts - because, satisfyingly, nearly every behaviour you observed in Module 1 falls straight out of it.

The One-Sentence Truth

Here is what a large language model is, in one sentence you should be able to recite by the end of this course:

A large language model is a function that takes a sequence of tokens and returns a probability distribution over what the next token could be.

That is the entire contract. Everything else - the chat interface, the apparent knowledge, the reasoning, the personality, the helpfulness - is either scaffolding built around this function or behaviour that emerges from applying it repeatedly.

Let me unpack each piece, because every word is load-bearing.

A function. Deterministic mathematics, in fact: the same input sequence produces the same output distribution every time (the non-determinism you observed in Module 1 enters at the sampling step afterward, plus some floating-point noise - topic 2.4 covers this precisely). The model is not an entity that "decides" things in any agentive sense. It is a very large mathematical function.

A sequence of tokens. Not words, not sentences, not meaning - tokens, the sub-word units you will dissect in the next topic. The model's entire universe of input is an ordered list of token IDs.

A probability distribution. Not an answer - a distribution over roughly 100,000 possible next tokens, exactly the table you worked with in topic 1.2 when tuning temperature. The model never says "the answer is Paris." It says "given everything so far, Paris carries 92% of the probability mass, located carries 3%..." and something downstream samples from that.

The next token. One. Singular. The model has no plan for the sentence, no outline of the paragraph, no destination for the argument. It predicts one next token, that token gets appended, and the function runs again on the extended sequence. Every eloquent multi-paragraph response you have ever received was produced one myopic step at a time.

Physically, "the model" is a file - or rather a set of files - containing billions of numbers called parameters or weights. Llama 3.1 405B is 405 billion numbers. Those numbers were set during training (topic 2.5) and are frozen at inference time. When you make an API call, your tokens flow through arithmetic involving those frozen numbers, and a distribution comes out the other end. Nothing is looked up. Nothing is retrieved. Nothing is updated. It is, in the most literal sense, just math on a very large scale.

Where the "Knowledge" Lives

So how did the model answer 2019 at all? If there is no database, where did a plausible release year come from?

During training, the model processed trillions of tokens of text and adjusted its parameters to get better at one task: predicting the next token across all of it. To predict well across that much text, the parameters were forced to encode statistical regularities - of grammar, of style, of code syntax, and yes, of facts. The sequence "The Eiffel Tower is located in" is followed by " Paris" so overwhelmingly often in training data that the model's parameters encode that regularity strongly. Ask, and the distribution puts massive probability on " Paris." It looks like knowledge. Functionally, for well-attested facts, it behaves like knowledge.

But it is compression, not storage. Facts that appear rarely in training data are encoded weakly or blurrily. Facts that appear in conflicting versions are encoded ambiguously. Facts from after training ended are not encoded at all - that is your knowledge cutoff, and it is not a policy choice, it is arithmetic: the parameters were frozen on a date, and nothing after that date touched them.

This is why the engineer's bug report was unanswerable. The internal tool's release year appeared maybe a handful of times in training data - perhaps never, perhaps in a misdated document. The model was not wrong about a fact; it produced the most probable continuation given weak, blurry statistical traces. The distribution had no strong peak, and sampling landed somewhere plausible-shaped.

Important: Hallucination is not a malfunction - it is the mechanism working as designed on inputs it encodes weakly. The model must always produce a distribution; "producing a distribution" and "knowing the answer" are the same operation from its side. A confident fabrication and a confident correct answer are generated by the identical process. The difference lives in the training data, not in the model's behaviour at inference time. This single insight explains why hallucination cannot be fully "fixed" by prompting, why it worsens as questions get more obscure, and why the industry's real answers are architectural - grounding the model in retrieved documents (the RAG modules) and validating its outputs (the evaluation module) rather than trusting its internal encoding.

There is a live philosophical debate about whether this statistical compression constitutes "understanding." You will see it argued heatedly in both directions by serious people. My position, as an engineer: the debate is fascinating and operationally irrelevant. What matters for the systems you build is the behavioural contract - brilliant pattern completion with no reliability guarantee on facts - and that contract is the same whichever side of the philosophy you take.

What the Correct Mental Model Predicts

Here is the test of a good mental model: it should predict the behaviours you have already observed, rather than leaving each one as a separate mystery to memorise. Run the checklist against Module 1.

Statelessness (topic 1.5). The model is a function over an input sequence. A function has no memory between invocations - of course you must resend the history. "Conversation" was always your construction, not the model's experience.

Sequential generation and output-bound latency (topic 1.1). One token per function application, each conditioned on all previous output. Of course a 700-token answer takes hundreds of sequential steps and latency scales with output length.

Non-determinism (topic 1.2). The function's output is a distribution, and something must sample from it. Of course identical prompts diverge - and of course temperature, which reshapes the distribution before sampling, controls how much.

Prompt sensitivity. The function's only input is the token sequence. Change the sequence - even the phrasing, even the ordering - and you have changed the input to the function, so the output distribution changes. There is no "underlying question" the model perceives behind your wording; the wording is the question.

Confident wrongness. Covered above. The generation process for right and wrong answers is identical.

No arithmetic reliability. The model predicts what digit-tokens plausibly follow - it does not execute addition. Small, common calculations are well-attested patterns and usually come out right; large or unusual ones are weakly attested and fail. This is why production systems hand math to tools (Module 7) instead of trusting generation.

One table to consolidate - the wrong mental models I see most often, and what each one costs:

Every row of that table is a production incident I have personally reviewed. The right mental model - next-token distribution over statistical regularities - prevents all six.

What LLMs Are Genuinely Good At

I have spent this topic tearing down inflated mental models, so let me spend a section on the other direction, because under-estimating these systems is its own engineering error - and frankly, the deflationary "it's just autocomplete" framing is as misleading as the database framing.

The astonishing empirical discovery of the last few years - and it was a discovery, not a design - is how much capability emerges from next-token prediction at sufficient scale. To predict the next token in a mathematics proof, the model's parameters must encode something functionally like mathematical structure. To predict the next token in a Python file, something functionally like program semantics. To predict dialogue, something functionally like a model of speakers with differing knowledge and goals. Researchers found that as models scaled, capabilities appeared that nobody explicitly built: translation, summarisation, analogy, code generation, multi-step problem decomposition.

For the working engineer, the reliable strengths cluster into a usable list:

Transformation - the deepest strength. Text in, text out, with the shape changed: summarise, translate, rewrite, reformat, extract (your topic 1.3 pipeline lives here). When both the input and the ground truth are in the context window, the model is not relying on its blurry parametric memory at all - it is pattern-completing over material directly in front of it, which is where it is most reliable. This asymmetry - strong over the context, unreliable from memory - is arguably the most important engineering fact in this entire course, and it is the entire justification for RAG.

Generation within constraints - drafts, variations, boilerplate, tests, documentation. Fluent, fast, and cheap where a human would be slow and expensive, in exactly the places where a human will review the output.

Judgement at scale - classification, routing, moderation, scoring. Tasks where each individual decision is easy for a person but the volume is impossible. A well-prompted small model at temperature 0 is a remarkably good, remarkably cheap classifier.

Interface - translating between messy human language and structured systems. Natural language to SQL, to API calls, to filters. This strength is the foundation of the tool-use and agent modules.

Notice what is not on the list: authoritative factual recall, arithmetic, guaranteed correctness of any kind. The craft of AI Engineering - genuinely, the one-line job description - is architecting systems so the model does the things on this list, while retrieval, tools, and validation handle the things that are not.

graph TD
    A[Token sequence in] --> B[Frozen parameters<br/>billions of numbers<br/>statistical regularities from training]
    B --> C[Probability distribution<br/>over ~100K next tokens]
    C --> D[Sampling<br/>temperature, top-p - topic 1.2]
    D --> E[One token out]
    E -->|append and repeat| A
    B -.->|weakly encoded facts| F[Hallucination risk]
    B -.->|strongly encoded patterns| G[Fluent capability]

This diagram shows the core loop of a large language model. A token sequence enters the model, which consists of billions of frozen parameters encoding statistical regularities from training. The model outputs a probability distribution over roughly one hundred thousand possible next tokens. A sampling step, controlled by temperature and top-p as covered in topic 1.2, selects one token, which is appended to the sequence and the loop repeats. Dotted lines show that weakly encoded facts in the parameters produce hallucination risk, while strongly encoded patterns produce fluent capability - from the same mechanism.

Interview: A deceptively simple interview opener: "Explain what an LLM is to a backend engineer joining your team." Weak answers recite "transformer trained on internet text." Strong answers give the functional contract - next-token distribution, knowledge as compressed statistics, hallucination as the mechanism rather than a bug - and then derive one or two production consequences from it (grounding requirements, tool use for arithmetic). Interviewers ask this because your mental model of the component predicts every architectural decision you will make with it. It is the same reason this topic exists.

Exercise: Break Your Own Mental Model

Exercise: Use your Module 1 client to observe the mechanism directly:

1. Ask a well-attested fact ("capital of France") and an obscure one (release year of a niche library) five times each at temperature 0.8. Compare answer stability across runs. You are watching distribution sharpness - strong encoding versus weak encoding - with your own eyes.
2. Ask the model to multiply two 4-digit numbers. Verify by hand. Then give it the same numbers and ask it to write Python that multiplies them. Reflect on which request played to the list of genuine strengths.
3. Ask the same factual question in three phrasings - direct, embedded in a story, phrased as a false premise ("Why was X released in 2019?"). Watch the false premise reshape the distribution toward agreement. You have just demonstrated why leading questions are a prompt-engineering hazard, two modules early.
4. Challenge: find a question where the model answers confidently and wrongly. Then supply the correct information in the prompt and ask again. You have just performed manual RAG - and proven the context-versus-memory asymmetry that Module 6 industrialises.

What You Should Take From This Lesson

An LLM is a frozen mathematical function from a token sequence to a probability distribution over the next token - nothing more, and astonishingly, nothing less. Its knowledge is statistical compression of training data, not storage: strong for well-attested patterns, blurry for rare ones, absent after the cutoff, and produced by the identical mechanism whether right or wrong - which is why hallucination is a property, not a bug, and why the fixes are architectural. The model is most reliable transforming what is in its context and least reliable recalling from its parameters; nearly everything you build in this course exploits that asymmetry. And every behaviour you engineered around in Module 1 - statelessness, sequential latency, non-determinism, prompt sensitivity - was this mental model, announcing itself before you had the vocabulary.

Next: the tokens themselves. You have been paying by the token, budgeting by the token, and truncating by the token for a full module without knowing what one actually is - and the answer explains a set of model behaviours so strange that engineers routinely mistake them for bugs, including why frontier models famously struggle to count the letters in "strawberry."

Back to AI Engineering