A chatbot changes its answer after you correct it. That can happen while every learned weight stays the same. Your correction changes the information available for the next response; it does not, by itself, demonstrate a training update.
Follow the kind of change each process makes:
| Process | What happens | What is carried forward |
|---|---|---|
| Pretraining | Parameters are learned from a broad collection of examples | A trained starting model |
| Fine-tuning | An existing model receives further training | Adapted parameters, sometimes in an adapter |
| Inference | The trained model processes inputs and produces an output | An answer or other generated result |
Fine-tuning belongs inside training. It is not an alternative to inference when a customer asks a question: a fine-tuned model still has to run to answer it.
Follow the weights through the training loop
A neural network contains numerical parameters that control its calculations. Many are called weights. Training changes trainable parameters using examples and an objective that measures how well predictions match their targets.
For a text-generating model trained on next-token prediction, the passage supplies the targets. Suppose the training text contains “The repair took two hours.” At the position before “hours,” the model assigns probabilities to possible continuations. The training system can compare that distribution with the token actually present in the passage. Tokens are pieces of text, which need not coincide with whole words.
A loss function measures the mismatch. Backpropagation calculates gradients: information about how changes in parameters would affect that loss. An optimizer uses the gradients to update the trainable parameters. Google’s explanation of backpropagation separates the forward calculation from this backward calculation and update.
Merely making a prediction is therefore insufficient to call something training. The update is the decisive step. If the system computes probabilities and selects text without applying a parameter update, it has used the model rather than trained it.
Pretraining supplies a starting point
Hugging Face’s account of Transformer training distinguishes broad pretraining from subsequent adaptation. Starting from scratch means learning from initially untrained weights. A large collection of examples helps establish reusable language patterns and capabilities.
For next-token pretraining, the target can be derived from the text itself. This is self-supervised learning: a human does not have to write a separate answer label for every position in every passage. That does not remove human choices about which data to include or what objective to optimize.
Nor does successful prediction certify truth. A system can learn how plausible explanations are written and still produce an incorrect explanation. Evaluate the answer’s evidence separately from the smoothness of its wording.
Imagine a fictional appliance company using a pretrained model. It receives a foundation capable of handling language, not a technician who automatically knows the company’s current products, procedures, and warranty decisions. Those are distinct requirements.
Fine-tuning changes how that foundation behaves
Fine-tuning continues training from an existing model. In supervised instruction tuning, examples can pair requests with desired responses. The Jurafsky and Martin textbook chapter on post-training explains how this shapes instruction-following behaviour using further gradient-based updates.
For our fictional company, a training example might pair a customer’s symptom report with a careful troubleshooting response. Another could show how to ask a necessary follow-up question. The examples influence future behaviour through trainable parameters; they are not simply attached to every customer conversation as reference notes.
Quality needs a separate test. If you evaluate only on examples already used for training, a convincing score may tell you little about unfamiliar cases. The Transformers fine-tuning guide demonstrates a training/evaluation split and evaluation during training. For a support assistant, useful held-out cases would include incomplete symptom reports and requests that should be escalated.
The decision is concrete: can the adapted model handle a new case correctly, including admitting when it lacks the necessary information? Learning the phrasing of the training responses is not enough.
LoRA changes fewer trainable parameters
Full fine-tuning can update the model’s original weights. LoRA, or low-rank adaptation, freezes pretrained weights and learns smaller matrices that modify selected calculations. The original LoRA paper describes how those updates can reduce the number of trainable parameters and memory requirements.
A small LoRA file still depends on its base model. It is a compact customization, not a standalone miniature replacement for all the base model’s capabilities. During use, its learned modifications affect the calculation even though the original weights stayed frozen during adaptation.
This also refines the question “Did the weights change?” For a parameter-efficient method, ask whether any trainable model parameters were updated, including an adapter. Focusing only on the original weight file can hide a real training process.
Context changes an answer without retraining
Now a customer tells the fictional assistant that the machine will not switch on. The assistant generates a response. The customer then clarifies that the power light works, but the water stays cold. The next answer can change because the input now describes a different problem.
The correction is part of the context used for inference. Examples inside a prompt can likewise guide the response without changing parameters. The textbook’s discussion of prompting and post-training treats these as different mechanisms.
If a service later uses collected conversations in another training run, that is a separate process. A better answer immediately after a correction does not reveal whether that later process exists. The visible exchange only establishes that the assistant responded to new information.
Retrieval adds evidence; fine-tuning adds adaptation
Suppose the company updates its returns policy. Rather than trying to encode every policy revision through training, an application can retrieve the relevant document and supply it with the customer’s question. This is retrieval-augmented generation, or RAG.
The original RAG research combines a pretrained generator with retrieved passages. In our example, the model receives the current policy as context. A useful evaluation would check whether the retrieval found the correct document and whether the answer faithfully used it. Fine-tuning and retrieval can coexist: one shapes response behaviour; the other supplies information for this request.
Inference still spends computation
For ordinary text generation, the system first processes the input, then produces tokens in sequence. NVIDIA’s inference explanation calls these phases prefill and decoding. Caching attention-related calculations can avoid repeated work, but the cache consumes memory and grows with sequence length.
A long document and a long generated answer therefore create different kinds of work. Skipping training updates does not make answering free. Cost depends on the model, workload, hardware, and serving system; the terminology alone does not give a price.
For a closer look at this stage, read how an inference engine generates tokens. Whenever an assistant appears to improve, ask what changed: trainable parameters, supplied context, retrieved information, or the generated wording. That question turns a vague claim of “learning” into a mechanism you can investigate.
