Large Language Models

Large language models (LLMs) are neural networks trained on large text datasets to learn patterns in language. This entry focuses on autoregressive models, which generate text one token at a time from a probability distribution conditioned on preceding tokens.[1]

Last updated 20260908 · Previous version, archived 20260908

Visual introduction · LLM system design learning tree

1. First principles and definitions

A language model assigns probabilities to sequences of tokens, the discrete units used to represent text. An autoregressive model factors a sequence probability into successive next-token probabilities:[1]

$$P(x_1,\ldots,x_n)=\prod_{t=1}^{n} P(x_t\mid x_1,\ldots,x_{t-1})$$

The model's learned parameters encode patterns acquired during training. Its context contains the input available for generation. An application's documents, databases, and tool permissions are managed outside those parameters. Retrieval-augmented generation combines a model with an external source of information.[1, 6]

2. Training and post-training

Pretraining fits model parameters to a large dataset. For autoregressive language models, a common objective is predicting the next token. GPT-3 is a published example of this approach.[1]

Supervised fine-tuning can then train the model on demonstrations of desired responses. Further training may use human preferences or reinforcement learning. InstructGPT used demonstrations, rankings of model outputs, a learned reward model, and reinforcement learning. This is one training recipe.[2]

Inference uses the trained model to produce outputs. Supplying instructions or retrieved text changes the context for that generation; ordinary inference leaves model parameters unchanged.[1, 6]

3. Tokens, architecture, and generation

Tokenization

A tokenizer converts text into token IDs. Subword methods can split a word into smaller pieces; byte-level methods also represent text through bytes or groups of bytes. Token counts depend on the tokenizer and input language, so a fixed words-per-token ratio is only an estimate.[3]

Embeddings

A model maps token IDs to learned vectors called embeddings. In a Transformer, attention and other layers transform these vectors using information from permitted positions in the sequence.[4]

Retrieval embeddings represent queries or passages for vector search. Their training objective and use differ from the token embeddings inside a generator. Dense Passage Retrieval, for example, trained separate question and passage encoders and scored their vectors with a dot product.[5]

Next-token generation

The model computes scores for possible next tokens. A softmax converts scores to a probability distribution. Greedy decoding selects the highest-probability token; sampling draws a token from a distribution, which decoding settings may modify. The selected token is appended and generation repeats until a stopping condition is met.[4, 7]

A plausible continuation can contain false or unsupported claims. Missing information does not make hallucination inevitable: a model may also abstain or request context. TruthfulQA found substantial errors in the models and questions it tested; its scores are a dated evaluation, not a universal error rate.[8]

4. Context, retrieval, and tools

Context engineering concerns the instructions, examples, conversation history, and external information supplied to a model. A context window limits how much tokenized material a model can process in a call. Capacity alone does not establish reliable use of that material.

Lost in the Middle tested multi-document question answering and synthetic key-value retrieval. In the evaluated models, performance often fell when relevant information appeared in the middle of the input. The findings concern those models, tasks, and positions; they do not establish that every increase in context length reduces accuracy.[9]

Retrieval-augmented generation (RAG) retrieves external material for use during generation. Lewis et al. combined a retriever with a generator on knowledge-intensive tasks. Retrieval quality and source quality remain part of the application's evaluation.[6]

An illustrative application might retain recent turns, store session records, and retrieve selected documents. A prompt might separate the task, supporting material, constraints, and output format. These are design choices; neither defines a required memory hierarchy or guarantees reliable behavior.

The memory and prompt examples are illustrative designs by the author.

Tools let application code perform actions requested by a model, such as a database lookup. The host must enforce authorization and validate arguments before executing a request.[10]

5. Capabilities and model selection

Model size alone does not determine usefulness. In InstructGPT's evaluation, human raters preferred outputs from a fine-tuned 1.3-billion-parameter model to those from the original 175-billion-parameter GPT-3. The result concerns the evaluated prompt distribution and preference criteria.[2]

Illustrative selection checklist by the author:

Task quality measured on representative examples and important failure cases.
Measured response latency and total cost, including retries, retrieval, and hosting.
Deployment options, data handling constraints, and required tool interfaces.
Context capacity and performance with the expected inputs.

6. Evaluation and limitations

Evaluation should match the task. Exact-match scoring is useful when a fixed answer or label is required. Structured outputs can be checked against a schema; generated code can be compiled and tested. Open-ended responses require criteria that allow valid alternative wording.[11]

A model judge can score responses against a rubric, but its judgments need validation against human assessments. Zheng et al. documented position, verbosity, and self-enhancement biases, as well as reasoning limits, in the judges they tested.[12]

A task-specific evaluation set can include unsupported factual claims, incomplete retrieval, malformed tool requests, and adversarial inputs. Benchmark results should retain the model version, task definition, scoring method, and test conditions needed to interpret them.[10, 11]

7. Security and failure modes

Prompt injection

Prompt injection attempts to steer model behavior through malicious instructions, including instructions embedded in retrieved material. Separating instructions from data and using filters may help, but these do not establish a security boundary. Application code must restrict access, validate outputs, and test adversarial inputs.[10]

Excessive agency

Broad tool permissions increase the consequences of a model error or injection. Enforce least privilege in the host, authorize each action against the user's permissions, and require human approval for sensitive operations. A model-generated statement that an action is allowed is insufficient authorization.[10]

Data poisoning

Attackers may alter training data or retrieved documents to influence outputs. Source provenance, controlled ingestion, and data review help address this risk. A cryptographic hash can detect changes against a trusted digest; it does not establish that the original content is true or safe.[13, 15]

8. Production considerations

The gateway, fallback, and response-cache guidance below is application-design synthesis by the author. These patterns are optional.

Gateways

An LLM gateway can centralize credentials, request routing, and observability. Provider differences still require compatibility checks for supported tools, input limits, and response formats.

Fallback

A model router can send requests to an alternative service after an error. Fallback can also fail or change output quality. Test compatibility, data handling rules, retry limits, and partial failures before relying on it for availability.

Caching

A response cache reuses a saved answer. Its key and invalidation policy must account for relevant instructions, user access, source versions, and generation settings. Semantic caching also risks reusing an answer for a meaningfully different request; any similarity threshold requires task-specific validation.

Prefix caching reuses computation for a shared input prefix while generating a new response. It is distinct from reusing a stored answer. Neither approach removes all lookup, network, or generation latency.[14]