What is Large Language Model?

The plain definition

A large language model is a very large transformer trained on a simple objective: given a sequence of text, predict what comes next. Repeat that over trillions of tokens and hundreds of billions of parameters, and capabilities emerge that nobody explicitly programmed — translation, summarisation, code generation, and a workable imitation of reasoning.

The training runs in stages. Pretraining on a broad corpus produces a raw next-token predictor that is knowledgeable and hard to steer. Instruction tuning on demonstration data teaches it to follow requests. Preference optimisation — RLHF or DPO — aligns its outputs with human judgement about what a good answer looks like. Only after all three does it behave like an assistant.

What follows from the architecture

Several widely misunderstood behaviours are direct consequences of how the model works. It has no persistent memory: everything it appears to remember lives inside the context window of the current request, which is why conversation history must be resent on every call.

It has no ability to verify. The model produces the most plausible continuation, and plausible-sounding falsehoods score well on that objective. This is what hallucination is — not a bug to be patched but the objective function working as designed. Mitigation means grounding the model in retrieved sources (see RAG) or constraining its outputs, never simply asking it to be accurate.

It has a knowledge cutoff, because its weights were frozen at the end of training. And it is stochastic: the same prompt can produce different outputs, which matters enormously when you are trying to build a testable system on top of one.

Choosing and using one in production

The default instinct — reach for the largest available model — is usually wrong economically. Inference cost scales with model size and runs on every request forever. Most narrow production tasks (classification, extraction, routing, structured rewriting) are handled by a small model at a fraction of the price, often after light fine-tuning.

The discipline that separates working systems from demos is evaluation. Build a held-out set of real inputs with known good outputs, and score every prompt or model change against it. Without that, you are tuning on vibes, and quality regressions ship silently. Because outputs are stochastic and free-form, evaluation usually combines exact checks where possible, rule-based assertions, and model-graded scoring on a rubric.

Also budget for the failure modes that have no analogue in ordinary software: prompt injection through untrusted input, sensitive data leaking into logs or provider training sets, and cost blowouts when a retry loop meets a long context.