How are models trained?

The learning loop

Training begins with a parameterized function: a network whose behaviour depends on many adjustable numbers called weights. A batch of examples passes through the network to produce predictions. A loss function measures the mismatch between those predictions and the training target.

Backpropagation applies the chain rule to compute gradients: local sensitivities describing how a small change in each parameter would change the loss. An optimizer uses those gradients to update the parameters. Repeating this loop over many batches changes the network from its initial random behaviour into a fitted model.

flowchart LR
  E[Training examples] --> F[Forward pass]
  F --> L[Loss]
  L --> B[Backpropagation]
  B --> G[Parameter gradients]
  G --> O[Optimizer update]
  O --> F

Backpropagation computes gradients; it does not update weights by itself. The optimizer owns the update rule, learning rate, momentum, weight decay, and other state.

Training a language model

For an autoregressive language model, training examples are token sequences. At many positions, the model predicts the next token and receives loss when it assigns insufficient probability to the observed continuation. Large-scale training applies this objective across extensive datasets and distributed hardware.

Later stages may refine the base model using supervised demonstrations, preference data, reinforcement learning, tool-use examples, or safety-focused datasets. Those stages change behaviour, but they do not turn the model into the whole product. Retrieval, permissions, memory, and application state still live outside the weights.

Fitting is not generalization

Low training loss proves that the model fit the observed training objective. It does not prove that the model will work on new users, languages, time periods, rare cases, adversarial inputs, or a specific product workflow.

Validation and held-out test data estimate how behaviour transfers beyond the examples used for updates. The split must protect evaluation evidence from training and repeated tuning. Once a team repeatedly optimizes against a test set, that set becomes development data in practice.

Training does not prove generalization

Training is not a database import. Source sentences are not normally stored as directly addressable records. The learned parameters encode distributed statistical regularities, and the model may reproduce some training material, combine patterns, or generate unsupported claims.

Training is also not the same as prompting. A prompt changes the current context without changing weights. Fine-tuning changes weights. Retrieval supplies external evidence at request time. These mechanisms have different costs, risks, and test strategies.

Validate data, optimization, and release artifacts

Test the training pipeline before trusting model quality:

• verify example and label alignment, tokenization, masking, and data splits;
• overfit a tiny clean sample to prove the implementation can learn at all;
• inspect loss, gradient norms, update magnitudes, and numerical stability;
• compare against a simple baseline and a known-capable configuration;
• evaluate on held-out cases and named slices;
• record the dataset, code, seed, model configuration, and checkpoint identity;
• test memorization, contamination, privacy, and distribution-shift risks.

A successful training run produces a candidate model. Release still requires evidence that the complete deployed system is useful, safe enough for its scope, observable, and recoverable.