Skip to content

What is an LLM and how does it work?

An LLM (Large Language Model) is a neural network trained to estimate which token may come next in a sequence. During pretraining it observes large amounts of text and adjusts its parameters to reduce prediction error. It can then generate text, answer questions, summarize, translate or produce code because many tasks can be formulated as conditional sequence continuation.

The definition is simple. The resulting behaviour is not. A useful way to understand it is to separate four pieces: tokenization, representation, prediction and adaptation.

The 60-second answer

FROM TEXT TO PREDICTION
An LLM repeats the same cycle: represent the context, compute a distribution, and append one token
Tokenization defines the discrete units; embeddings turn them into vectors; the Transformer mixes contextual information; the output layer produces scores over the vocabulary.
SELECTa token is chosen or sampled
UPDATE CONTEXTthe token is appended and the cycle repeats
Important separationMemory, RAG, tools, and policies can surround the model, but they are not automatically part of its weights.

The model does not search for a stored sentence or query a database by default. It calculates a probability distribution over the vocabulary, chooses a continuation, and runs the process again with the updated context.

A product system can add memory, retrieval, tools or policies around the model. Those capabilities belong to the complete system, not necessarily to the LLM weights.

1. Text becomes tokens

The model does not work directly with words. A tokenizer splits text into units that may be complete words, fragments, punctuation or bytes. Each token receives an integer identifier.

TOKENIZATION · TEXT → DISCRETE UNITS
The model does not receive words: it receives a sequence of IDs defined by a specific tokenizer
Segmentation depends on the vocabulary and algorithm. The same text can use a different number of tokens under different tokenizers even when the visible characters are identical.
SAME TEXT · DIFFERENT VOCABULARIES A token boundary is not a universal property of a word
TOKENIZER Aillustrative segmentation
“neural architecture”
▁neural▁architecture
Two units if both pieces are well covered by the vocabulary.
TOKENIZER Billustrative segmentation
“neural architecture”
▁neural▁architecture
More units if the vocabulary must reconstruct the same string from smaller fragments.
Important: the segmentations in this diagram are pedagogical; they are not outputs from a specific tokenizer.
IT IS NOT “ONE WORD = ONE TOKEN” A word can be one piece, several subwords or a sequence of bytes.
IDs ARE NOT UNIVERSAL The integer only has meaning inside that tokenizer's vocabulary.
IT CHANGES THE BUDGET More tokens consume more context and can increase inference cost.
OPERATIONAL RULE When comparing models, context limits or costs, count tokens with the model's actual tokenizer; do not estimate from words or characters.

The exact segmentation depends on the vocabulary and algorithm. Methods such as Byte Pair Encoding and SentencePiece balance two goals: keeping the vocabulary manageable and representing rare words without turning every character into an independent unit.1

Tokenization matters because it affects:

  • cost, which is often measured in tokens;
  • effective context length;
  • representation of languages and code;
  • the ease of copying numbers, names or uncommon strings.

2. Tokens become representations

Each identifier is transformed into a learned vector called an embedding. The model also needs information about each token's position. Without it, a sequence would be only an unordered set.

The vectors pass through a stack of Transformer blocks. Two main operations occur inside each block:

  1. Attention: each position combines information from other relevant positions.
  2. Feed-forward network: transforms each position's representation nonlinearly.

Residual connections and normalization stabilize training. As blocks are repeated, representations stop encoding only token identity and begin to incorporate syntax, semantic relationships, references, document structure and other signals useful for prediction.2

CONTEXTUAL REPRESENTATION
The embedding identifies the token; Transformer layers build a state that depends on position and context
The same lexical unit starts from the same token embedding. Positional signals and attention make its final representation change with the words around it.
TOKEN IDENTITY “bank” → ebank Conceptual example: exact segmentation and token ID depend on the tokenizer.
CONTEXT A
The bank approved the loan
INPUT ebank + pt token embedding + positional signal
TRANSFORMER BLOCKS
attentionFFN× L layers
each layer mixes signals from the context it is allowed to attend to
CONTEXTUAL STATE ht(L) incorporates signals such as “approved” and “loan”
CONTEXT B
We sat on the bank by the river
INPUT ebank + pt same token embedding; potentially a different position
TRANSFORMER BLOCKS
attentionFFN× L layers
activations change when the context changes
CONTEXTUAL STATE ht(L) incorporates signals such as “sat” and “river”
Correct reading The token embedding is the starting point. The representation used by later layers is contextual and can differ at every occurrence.

The guide to the Transformer develops this architecture step by step.

3. The base objective is next-token prediction

For an autoregressive LLM, training optimizes the probability of the true token conditioned on the previous ones.

AUTOREGRESSIVE OBJECTIVE
The model does not predict a whole sentence: it scores the next token conditioned on the entire prefix
During training, the correct token is known and its log-loss is minimized. During generation there is no given answer: the distribution is turned into a choice, and that token becomes part of the next context.
CONTEXT
The capital of France is?
The Transformer produces a representation for the position that must continue the sequence.
DISTRIBUTION OVER THE VOCABULARY
Paris
more likely
Lyon
less likely
una
long tail
The bars are illustrative: they show relative ordering, not measured probabilities from a specific model.
TRAINING ℒ = − Σt log p(xt | x<t) If the true token receives low probability, the loss increases and the gradient updates the parameters.
GENERATION distribution → selection → new context → repeat Greedy decoding, temperature, top-p, and other rules change how the token is selected; they do not change the fact that the distribution is recomputed at every step.
ConsequenceOptimizing continuation probability is not the same as verifying truth. Factuality needs additional signals, data, or checks.

The model receives a sequence and must assign high probability to the real token that follows at each position. The gradient indicates how to modify millions or billions of parameters to make fewer errors on the next batch.

At scale, solving that task well requires learning deep regularities. To predict a plausible continuation, the model needs to capture grammar, style, relationships between concepts, coding conventions and part of the statistical structure of the world described in its data.

That does not turn probability into truth. The training objective rewards a continuation compatible with the context, not an externally verified statement.

4. Pretraining, instructions and preferences are different stages

A conversational product usually passes through several stages.

FROM BASE MODEL TO ASSISTANT
Pretraining, instruction tuning, and preference optimization use different learning signals
Later stages change how the model responds to a request. By themselves they do not turn a probable continuation into a verifiable source, nor do they replace memory, tools, or operational state.
DOES NOT GUARANTEEfactual provenanceA response can follow instructions and still be false.
DOES NOT ADD BY ITSELFup-to-date knowledgeExternal changes require context, retrieval, or new training.
DOES NOT REPLACEstate and authorizationReliable actions need contracts, permissions, and verification outside the text.
Correct interpretationThese stages form a behavior-adaptation chain; they are not three names for the same training process.

Pretraining

The model learns general patterns from large corpora. The result is a base model that completes text but does not necessarily follow instructions well.

Instruction tuning

The model is trained on instruction-response pairs so it learns to interpret requests and adopt useful response formats. This phase turns general continuation ability into assistant-like behaviour.

Preference optimization

Human comparisons, reward models or other signals are used to favour responses considered more useful, safe or aligned with the product. InstructGPT was an early demonstration that supervised fine-tuning plus preference learning could improve instruction following without changing the fundamental generative objective.5

These stages change observable behaviour. They do not guarantee that the model knows a source, stays coherent during a long operation or executes actions reliably.

Parameters, context and external knowledge

Three different mechanisms are often confused.

WHERE THE INFORMATION LIVES
Parameters, context, and external systems change at different times
They are not three names for “memory”. Separating them clarifies what can be current, what evidence enters this request, and which part of the system can read or modify state outside the model.
01PARAMETERS θ
training dataD
optimization∇L
learned weightsθ
CHANGEStraining / fine-tuning
CONTAINScompressed regularities
PROVENANCEdoes not recover an exact source by default
02REQUEST CONTEXT
instructions conversation included documents tool results
tokens visible now model attention
CHANGESevery interaction
CONTAINSexplicit evidence in this call
PROVENANCEcan be stored alongside the response
03RETRIEVAL / TOOLS
READ index · DB · API retrieve evidence
ACT runtime + contract validate and execute effect
CHANGESduring system execution
CONTAINSdata or state outside the model
PROVENANCEcan log source, call, and result
HOW THEY CONNECT IN A REAL SYSTEM
external sourcesdocs · DB · APIs
retrieval
contextx₁ … xₙ
conditions
LLMfθ(x)
proposed tool
runtimevalidate · authorize
effect
external stateread / write
RAGretrieves evidence; it does not retrain the weights on every query
CONTEXTconditions this inference; it is not persistent memory
TOOLSconnect the model to a runtime; effects happen outside the LLM

An LLM can answer from its parameters, reason over information included in context, or call a tool. Traceability is very different in each case.

When an answer must depend on current documentation, retrieval is often more verifiable than trusting whatever was compressed during training. When the system must change another system's state, it needs a tool with a contract, validation and idempotency.

Why scale helps

Performance does not depend only on parameter count. The amount and quality of data, training compute, architecture, context length and adaptation process also matter.

SCALE = BALANCE ACROSS N, D, AND C
More parameters help only when data and compute scale with them
Scaling laws describe empirical relationships between loss and three training resources. If one becomes limiting, increasing another enters diminishing returns.
01PARAMETERS N
N
model size
02DATA D
D
training tokens
03COMPUTE C
C
training budget
OBSERVED OBJECTIVE validation loss L ↓ when the other factors are not the bottleneck
EMPIRICAL POWER-LAW RELATIONSHIPS
modelL(N) ∝ N−αN
dataL(D) ∝ D−αD
computeL(C) ∝ C−αC
They are empirical fits within a training regime; they do not guarantee that every benchmark or capability improves along the same curve.
CHINCHILLA EXAMPLE · SAME TRAINING BUDGET Maximizing N is not enough
Gopher
PARAMETERS280B
DATA
COMPUTE=
Chinchilla
PARAMETERS70B
DATA
COMPUTE=
Hoffmann et al. trained Chinchilla with the same compute as Gopher, one quarter of the parameters, and 4× more data. The result showed that the budget can be used more effectively by balancing model size and training tokens.
BOTTLENECKscaling N without enough D can leave the model undertrained
SCOPEthese are empirical loss laws, not universal physical laws
COMPARISON“larger” is not enough: how the budget was allocated matters

Work on scaling laws showed predictable relationships between loss, model size, data and compute. Chinchilla added an important qualification: for a fixed training budget, increasing parameters without enough additional tokens can leave a model undertrained.34

That is why “larger” is not a sufficient explanation. A useful comparison needs to know the training regime and evaluation task.

What an LLM can do well

An LLM is particularly useful when the task allows linguistic variation and the result can be verified or corrected:

  • transform and summarize text;
  • extract information into a schema;
  • generate drafts and code;
  • classify from instructions and examples;
  • translate between representations;
  • coordinate tools through structured arguments;
  • reason over information present in the context.

The complete system improves when explicit constraints, examples, validators, retrieval and evaluation on real cases are added.

Limits that do not disappear with a better prompt

Plausible generation, not a guarantee of truth

The model can produce a fluent false statement. Verbal confidence is not a calibrated estimate of correctness.

Sensitivity to context

Small changes to instructions, ordering or examples can alter the result. In production, the prompt is part of the software and needs regression tests.

Incomplete or outdated knowledge

Parameters reflect training data and its cutoff. A model does not automatically know later changes or an organization's private documentation.

Non-monotonic reasoning

More reasoning tokens or more inference time can help, but can also introduce drift, overthinking or extra cost without improvement. The guide to reasoning in LLMs separates these strategies.

No reliable operational state by default

Conversation history is not a database. A long-running operation needs explicit state, identifiers, retries and idempotency outside the model.

How to evaluate an LLM for a real use case

Choosing the model at the top of one benchmark is not enough. A useful evaluation should measure:

  1. the real input distribution;
  2. the minimum acceptable quality;
  3. costly failure modes;
  4. latency to a usable output;
  5. total system cost;
  6. stability under paraphrases;
  7. correctness of tools and retrieved data.

The guide to evaluating AI models proposes a complete stack from static tests to product metrics.

Where to go deeper in 5sigmas

Frequently asked questions

Is an LLM a database?

No. Its parameters compress learned regularities, but they do not provide exact retrieval, transactional updates or guaranteed provenance. A system can connect the LLM to a database or index, but those are separate components.

Does an LLM understand language?

It depends on the definition of “understand.” Its representations capture enough syntactic and semantic relationships to solve complex tasks. That does not demonstrate subjective experience or guarantee a correct causal representation of the world.

Do all LLMs use Transformers?

Most general-purpose language models published in the modern era use Transformers or closely related hybrid architectures. Alternatives based on state-space models and other operations exist, but “LLM” describes scale and function rather than mandating one architecture.

What is the difference between an LLM and a chatbot?

The LLM is the generative model. The chatbot adds interface, instructions, memory, retrieval, tools, moderation, observability and product policies.

Primary sources