What is a large language model?

A large language model, or LLM, is a neural network trained on substantial amounts of language data to learn patterns it can use to process and generate text. Many conversational LLMs generate a response by repeatedly predicting the next token: a small unit of text, rather than necessarily a whole word.[1]

The model supplies the language capability. The product around it supplies things such as the chat interface, file handling, search and connections to other software. Those differences matter when you ask an AI assistant a question. An answer drawn from learned patterns, an answer based on your document and an answer supported by a fresh search are different kinds of evidence.

What “large,” “language” and “model” mean

Language includes more than everyday prose. Training material can contain code, tables and other text structures. Some systems also process images or audio. This article focuses on the language-generation mechanism; a multimodal system can include additional components and training objectives.

Model means a mathematical system with learned parameters. Parameters are numbers adjusted during training. Together, they influence how the network transforms an input into a prediction. They are not a tidy collection of individually addressable facts, with one parameter for every date or definition.

Large describes scale, rather than a universal threshold that makes a model useful. Parameter counts are one measure; the training data, architecture and training procedure also matter. A size label alone is a poor way to choose a tool for a particular task.

Think about a support team choosing between two systems. The larger one might produce elegant replies, while the other follows the team's required format more reliably. The relevant question is which system handles the team's actual cases with acceptable review effort. A specification cannot answer that on its own.

How a model learns before you use it

There are two separate processes to understand: training, which changes learned parameters, and inference, which uses a trained model to produce an output.

Pretraining builds broad capabilities

In a common generative setup, training presents text and asks the model to predict what follows. Its predictions are compared with the training sequence, and an optimization procedure adjusts parameters to reduce prediction error. Repeated across many examples, this builds representations that support language tasks. Other language-model families use different prediction objectives.[2]

The task does not require a person to write a separate answer key for every passage. The text supplies prediction targets. That is why language models can learn from material that was not originally written as a collection of questions and answers.

This still leaves important decisions for the developer: what data to collect, what to exclude, how to handle repetition and what to evaluate. “Trained on the internet” is too vague to tell you what a particular model has seen. Do not infer a complete training inventory from the fact that it recognizes a topic.

Post-training shapes how it responds

A base model's ability to continue text is different from reliably following a request. Developers can apply further training using demonstrations, preferences or other feedback to shape behavior. The exact methods vary.

OpenAI’s InstructGPT research, for example, combined supervised demonstrations with rankings of outputs and reinforcement learning from human feedback. Its findings illustrate why instruction-following depends on more than scale.[3]

“Making language models bigger does not inherently make them better at following a user's intent.”

— Ouyang and colleagues, Training language models to follow instructions with human feedback (2022).[3]

That paper concerns a particular training approach and evaluation. It is evidence for the distinction between size and behavior, not a ranking of today's assistants.

Inference uses what was learned

When you send an ordinary prompt, the deployed model uses its learned parameters to process the supplied context and generate an output. A correction in the conversation can influence the next response because the correction becomes part of that context. It does not, by itself, retrain the model.[4]

A product may separately store preferences or use conversations in a later training process under its own policies. Those are different mechanisms. “It remembered my preference” and “its weights changed while we chatted” should not be treated as equivalent claims.

AI Chronicle

How an LLM turns a prompt into text

For a typical autoregressive text model, generation proceeds through a sequence of calculations. The visible answer can appear all at once or stream into the interface, but the underlying process builds a continuation in small units.

Text becomes tokens

A tokenizer maps text to units the model can process. Depending on the tokenizer, a token may correspond to a word, part of a word, punctuation or another text fragment. The model operates on numerical representations of these units. A character count or word count is therefore not an exact token count.[1]

For an introductory example, imagine the unfinished sentence “The delivery will arrive on”. There are several plausible continuations. This example uses readable words to illustrate the decision; it is not a claim about a particular tokenizer's boundaries.

The model calculates a continuation

The model processes the available context and produces scores that can be converted into probabilities over possible next tokens. A decoding procedure selects a token. That token is appended to the context, and the process repeats until a stopping condition or output limit is reached.[2]

The continuation might develop into “Friday morning” or “the next business day,” depending on the input and the model. Neither phrase establishes the arrival date of a real package. To answer that question responsibly, the system would need relevant order information.

Generation can involve sampling, so the same request may produce different wording. Settings such as temperature influence sampling behavior. They do not independently check the truth of a statement. A more predictable answer can still be wrong.

Attention helps connect the context

Many LLMs use Transformer architectures. One central mechanism, attention, lets a layer combine information from token representations according to their relationships. Position information and other components also contribute; attention is not the entire network.[5]

Consider this original example: “The customer returned the jacket because it was too small.” Understanding the sentence involves connecting “it” with “the jacket,” rather than the customer. Attention is one mechanism used to build context-sensitive representations. This example is explanatory, not a measured visualization of a model's internal attention.

Do not assume every Transformer has the same layout. The original Transformer paper described an encoder–decoder system for translation. Many conversational generators use decoder-only architectures. The shared term does not make the implementations identical.[1][5]

Is it retrieving an answer or generating one?

Language generation can produce a familiar fact, a synthesis, a useful draft or an unsupported claim. The visible wording does not tell you which happened.

A bare model does not automatically search a live website whenever a question sounds factual. A connected product can perform a search or retrieve documents and pass the results into the model's context. The model then generates an answer using that supplied material. This separation between retrieval and generation is the basis of retrieval-augmented generation.[6]

For a reader, the useful distinction is where the supporting information came from:

This is an editorial checking framework, not a guarantee attached to any one product. If an answer mentions a website, open the website. A source name written in a generated paragraph is not proof that the system retrieved or read it.

Model, assistant and agent: three different layers

The model is a component. An assistant is a product or application built around one or more models. An agent is a system in which the model can direct parts of a sequence of actions toward a goal, usually through tools.[7]

An assistant can offer tool use without turning every interaction into an autonomous workflow. An agent can use several models. A product can change the model used for a request. These labels describe different aspects of a system.

This is why comparing only model names can miss the experience you will actually get. File processing, retrieval, permissions and the interface can all affect the outcome. Our AI agents explainer covers the action layer in more detail.

The same distinction applies to deployment. Access to model weights, the license governing them and a hosted assistant are separate questions. The open versus closed models guide examines those choices.

A worked example: the answer needs the policy

Suppose a small ecommerce business wants a draft reply to a return request. This fictional policy excerpt is the only evidence supplied:

Returns: Items can be returned within 30 days of delivery.
Condition: Items must be unworn and have their original tags.
Return shipping: The customer pays unless the item is defective.

The customer asks: “Can I return my jacket? It arrived 20 days ago.”

An unrestricted request to “write a friendly reply” leaves room for the system to invent details or overlook a condition. A more useful brief identifies the evidence and the missing information:

Draft a reply using only the policy excerpt and customer message.
State the time limit and conditions.
Do not approve the return: the item's condition is unknown.
Do not invent a free-shipping policy.
Ask for the information needed to decide eligibility.

A suitable draft would say that the request appears to fall within the 30-day window, explain the unworn-and-tags condition, ask about the item's condition, and state the shipping rule accurately. That is an editorial acceptance criterion, not a captured response from a tested product.

The prompt helps by making the relevant material and boundaries explicit. It does not ensure compliance. The reviewer still checks that the draft preserves every condition and makes no unsupported promise.

Now change the task to “Has the return already been approved?” The policy excerpt cannot answer it. The system needs an order or returns record. Change it again to “Approve the return,” and the task requires a permitted action and an approval rule. Better prose cannot supply missing records or grant authority.

AI Chronicle

What language models still get wrong

Plausible wording can hide a false claim

The training and generation processes described above do not make every output true. NIST's generative AI risk profile identifies confidently presented false information as a distinct risk, including fabricated citations or explanations.[8]

“The production of confidently stated but erroneous or false content”

— NIST's definition of confabulation, excerpted from its Generative AI Profile (2024).[8]

The delivery-date example shows the problem: a continuation can be linguistically appropriate while saying nothing reliable about an actual shipment. The practical response is to check consequential claims against evidence. The hallucinations explainer will examine why unsupported answers occur and which checks fit different tasks.

Available context is not guaranteed recall

A context window limits how much input and generated material a model can handle in a request, with accounting that depends on the implementation. Fitting a document within that limit does not establish that every detail will be used correctly.

The Lost in the Middle study found that information position affected performance on the models and tasks it tested. That research should not be converted into a universal error rate for current models. It demonstrates a reason to evaluate document work, rather than assume input capacity equals reliable recall.[9]

If a contract summary omits an exception, “the whole contract was uploaded” is not a sufficient quality check. Ask which passages support the summary and compare the result with them. Our context-window guide separates capacity from effective use.

Learned patterns can include memorized material

It is also too strong to say that a model never reproduces training text. Research on GPT-2 demonstrated extraction of verbatim training examples under particular attack conditions. This establishes that memorization can occur; it does not describe every model's behavior on every prompt.[10]

Avoid both shortcuts: treating the model as a searchable copy of its training set, and assuming that generation can never reproduce existing material. Neither is a dependable basis for judging an output.

How to judge an LLM for your own task

Start with a task that has a checkable result. Model size, fluent writing and a long technical specification do not substitute for that check.

For the fictional return-policy task, a small evaluation could include four cases: within the time limit with unknown condition, outside the limit, a defective item, and a request for an exception the policy does not authorize. Give each case an explicit expected boundary. Inspect omissions and invented promises as well as tone.

Keep the input, relevant settings and surrounding tools consistent when comparing systems. Record the model or product identifier where it is available, the date, and the evidence used to judge the answer. Repeat cases if consistency matters. This is a proposed evaluation method; no comparative results are claimed here.

Reasoning-oriented models can add further inference-time work, but the relevant question remains whether the final result meets the task's criteria. An elaborate explanation is not independent proof. The reasoning-models guide covers that distinction.

If your task is document rewriting, judge fidelity to the document. If it is research, judge source support and omissions. If it is an action, judge permissions and the resulting state. Choose the evaluation around the outcome you need.

Questions readers commonly ask

Does my prompt train the model?

Ordinary prompting does not update learned parameters. It provides runtime context. A provider's separate storage or future training practices depend on its product and policies; check those before supplying sensitive material.[4]

Is an LLM the same thing as ChatGPT, Claude or Gemini?

Those names can refer to product families or model families, depending on the context. Distinguish the deployed model from the application you are using. A review should identify both, along with the plan and capabilities relevant to the task.

Can an LLM access today's information?

A system can supply current information through search, retrieval or another tool. The model's training alone does not establish live access. Look for the actual source and its date, then check whether it supports the claim.

Should I use the model with the most parameters?

Parameter count alone does not decide task quality. Evaluate the actual system on representative inputs and include the work required to correct its output. The better choice is the one that meets your criteria in the workflow you can sustain.

The next step

You now have three useful questions for any assistant: What model is generating this? What information is it using? What can the surrounding system do?

Use those questions as you move to the Claude, ChatGPT and Gemini comparison. That article will compare assistants on documented tasks. This explainer supplies the foundation for understanding the differences.

Sources and evidence note

This explainer uses technical documentation, original research and NIST's risk profile. Older papers explain specific mechanisms or demonstrate limitations under their stated conditions; they are not presented as current product rankings. The return policy, prompt, acceptance criteria and task-checking framework are original illustrative material. No hands-on product test or performance improvement is claimed.