TL;DR: A transformer turns tokens into numerical representations, mixes information between relevant positions through attention, and transforms those representations through repeated layers to predict the next token. Training changes learned weights. An ordinary inference request uses those weights; it changes the context and intermediate state, not the model's learned parameters.
Follow one token
Consider the fictional message: “The courier left the parcel at reception because it was closed.” What was closed? The sentence is ambiguous. A fluent continuation can choose an interpretation without discovering what actually happened. That is a product problem even when the mechanism works exactly as designed.
A common decoder-only language model tokenizes the input, looks up token embeddings and incorporates position information. Within a layer, attention combines information from permitted positions. A feed-forward network transforms each position's representation; residual connections and normalization help the layers work together. Repeated blocks produce contextual representations, and a final projection produces scores over possible next tokens. Decoding selects a token and repeats until a stop condition.
The diagram follows this common architecture. It is not a claim that every language model has the same internals.
Follow the flow, one stage at a time.
Illustrated sequence; animation speed does not represent processing time.Read diagram description
Tokenize the input, look up embeddings, add position information, compute causal attention, transform representations, repeat the layers, score next tokens and select the next token. Generation repeats with fixed learned weights; training is a separate process.
What attention computes
For each position, learned projections produce a query, keys and values. Comparing its query with available keys yields scores. Scaling, masking and normalization turn those scores into weights used to combine the values. Multiple heads can learn different combinations. In causal attention, a token cannot use later tokens from the sequence being predicted.
These attention weights are computed for this input. They are different from the model weights learned during training, including the projection matrices. Confusing the two leads to the mistaken claim that each chat message retrains the model.
The mechanism is described in Vaswani and colleagues' transformer paper. An attention pattern is not a source citation or proof of why an answer is true. For the courier sentence, retrieve the delivery record or ask a clarifying question; inspecting a colorful attention map cannot establish whether reception was open.
Which changes require training?
| Change | Learned parameters updated? | Product implication |
|---|---|---|
| Pre-training on a broad corpus | Yes | Builds general capabilities and associations; does not supply a live business record |
| Post-training with demonstrations or feedback | Yes, for the trained components | Changes behavior toward an objective; evaluate side effects |
| A user sends a correction in chat | No, in ordinary inference | The correction can affect this context without persisting into a new session |
| Retrieval supplies a current policy | No | Evidence changes without a model release; freshness still needs an ingestion contract |
| A runtime skill loads instructions | No | A procedure becomes available in context; execution permissions remain separate |
| Application memory retrieves a saved preference | No | Persistence comes from a store the application manages |
Post-training can include supervised fine-tuning, preference optimization and reinforcement learning. The training objective, data source and which parameters change are separate choices; post-training objectives explains them. A provider may separately use permitted interaction data in later training. That is a data-policy and training process, not a property of pressing Send.
Why this is not a database lookup
Weights encode distributed statistical relationships. They do not expose a trustworthy row with a record ID, last-updated time and access-control check. A model may recall an accurate fact, misremember it or produce a plausible invention. Neither confidence in the wording nor low sampling temperature turns that response into an authoritative account balance.
Use a database or permission-checked tool for the balance. Use the model to understand the request or explain the returned result. Keep calculations and authorization in code. The same separation applies when a model summarizes a retrieved policy: source availability helps, but the generated claims still need checking.
A small product diagnosis
In a fictional review of 40 incorrect delivery answers, 24 used yesterday's status, 10 misread a current record and six returned an invalid field. These buckets describe first observed failures, not independent causes of every downstream mistake.
Fix the status-fetch contract before buying a training run. Replay the ten interpretation failures with the correct record to compare instructions or models. Validate the six malformed responses at the boundary. A training proposal earns consideration only after the team identifies a repeatable behavior gap and reserves untouched cases to evaluate the repair.
Continue with sampling and generation, then rehearse the request path. For the cost consequence of those numerical operations, read GPU economics.