What changes during training?

A model has numerical parameters that influence how inputs are transformed into outputs. During training, an optimization procedure adjusts trainable parameters in response to an objective and data. For a language model, one objective can involve predicting text from preceding context. Other stages can train different behaviors or preferences. The exact process varies by model and training stage.

The result is not simply a folder of sentences waiting to be retrieved. Learned parameters encode patterns that can support generalization, while some details may also be memorized. That combination helps explain why a model can produce a new formulation without being able to identify a reliable source for every statement. Training changes the machinery generating the output; it does not attach an evidence trail to every possible future claim.

What happens during inference?

Inference is the use of a trained model to compute an output from input. In many language models, a prompt is processed and text is generated sequentially as tokens. The architecture and generation settings affect this process. A completed answer may require many calculations even when no model parameters are updated.

The surrounding product can make inference more elaborate. It may search for documents, run code, call another model, or repeat a step after receiving feedback. Some systems allocate additional computation to a difficult task. Training versus inference is therefore not equivalent to learning versus doing something trivial. A fixed set of weights can support a complex sequence of operations through context and external tools.

The observable answer alone rarely reveals the entire sequence. A product can present one response while performing several operations behind it. To understand a capability claim, it helps to know whether the result comes from the model alone or from a larger system that retrieves information and checks intermediate results.

Why examples in a prompt can change the answer

Suppose a user supplies three examples of a desired formatting convention and asks for a fourth item in the same style. The examples can influence generation because they are part of the input context. That does not require a training run or a lasting change to the model's parameters.

Research on few-shot language-model behavior helped demonstrate this distinction between providing task examples at inference time and updating weights. The examples can be useful, but the result still depends on the model, task, wording, and available context. Following a pattern in one conversation does not establish that the behavior will persist in an unrelated conversation.

An everyday analogy is being given a reference sheet while completing a task. The sheet changes what information is available for the task without being identical to the process that originally developed the underlying skill. The analogy has limits, particularly because a model is not a person, but it separates access to current information from parameter updates.

Context, saved memory, and training are separate

Context is the information available to the model for a particular computation. A product may retain conversation history, summarize earlier exchanges, or retrieve stored information into that context. A memory feature can therefore affect a later answer without directly modifying the base model.

Whether a service stores data or later uses it for training is a separate question governed by that service's design and settings. The fact that a model references an earlier message does not establish one policy or the other. Nor does a model saying it has remembered something prove that a persistent record was created. Those questions require product-specific evidence rather than inference from conversational language.

What additional training adds

Fine-tuning performs further training, often to adapt behavior to a task or domain. Some methods update many parameters; others train a smaller set of additional parameters. LoRA is one example of parameter-efficient adaptation. The method changes how a model is adapted, not the basic need to evaluate whether the adaptation helps.

An adapted model could become better at a particular output format while retaining factual weaknesses. It could also improve one task and worsen another. A useful evaluation compares the intended behavior and relevant failure cases before and after the change. Merely knowing that training occurred does not tell a user whether a particular answer is accurate or appropriate.

What the distinction explains, and what it does not

Training and inference help explain why new input can change an answer immediately, why updating a model is different from updating a document collection, and why a stored preference need not be part of the model weights. These distinctions also clarify where a failure might originate: the learned behavior, the supplied context, or the software connecting them.

They do not establish whether the system understands a topic in a human sense, whether its output is original, or whether a particular factual claim is supported. Those are separate questions. The practical benefit is a more precise account of what happened when information entered the system and which component would need to change to improve the result.