Why base models aren't assistants

1

Concept

A base language model is trained on a deceptively simple objective: given the preceding tokens, assign high probability to the token that actually came next in its training text. That objective can produce broad knowledge, fluent syntax, in-context learning, and surprisingly flexible problem solving. It does not define a conversation contract. The training corpus contains answers, questions, arguments, fiction, source code, spam, unsafe instructions, corrections, and unfinished fragments. Predicting that mixture well is different from behaving like a reliable assistant.

Suppose the prompt ends with “Write three reasons to test backups.” In the corpus, plausible continuations include the requested list, a critique of the prompt, a transcript in which someone refuses, or another paragraph explaining why the question matters. Pretraining rewards probability assigned across patterns resembling all of these. The user, however, expects one specific role: interpret the imperative as an instruction and complete it. That expectation is external to next-token prediction.

This is the behavioral underspecification problem. The model may possess a capability without reliably selecting it. It can know how to summarize yet continue the source document; know that evidence is uncertain yet imitate a confident article; or know safe alternatives yet reproduce a dangerous procedure because that is a coherent continuation. Capability and policy are related, but they are not identical.

Post-training narrows the distribution of acceptable behavior. Supervised fine-tuning shows examples of prompts paired with desirable responses. Preference optimization compares responses and increases the relative probability of the preferred style or content. Safety training supplies adversarial cases and refusal boundaries. The result is often called an instruct or assistant model. It still predicts tokens internally, but its weights now make assistant-like continuations much more likely in the conversational format used during training.

Formatting matters. Chat models receive structured roles such as system, user, and assistant, encoded through a chat template. Those markers are tokens, not magical permissions. A model must learn that system content has higher instructional priority, that user text may contain quoted or hostile instructions, and that assistant content is where the answer belongs. Changing the template from the one used in post-training can degrade behavior even when the underlying prose looks similar.

Alignment is not synonymous with obedience. A useful assistant must balance instruction following with truthfulness, safety, privacy, and explicit uncertainty. These goals can conflict. A request may be clear but unsafe; a factual answer may be unknown; a concise response may omit an important caveat. There is no single scalar called “helpfulness” that resolves every case without judgment. Training data and evaluation rubrics encode choices about those trade-offs.

Alignment also does not make behavior permanent. Models remain sensitive to prompt wording, long contexts, distribution shift, decoding settings, and conflicts among instructions. A model that refuses one phrasing may answer a paraphrase. A model that follows a simple hierarchy may fail when malicious text is embedded in retrieved documents. Therefore alignment is an engineering process combining training, evaluation, system design, access control, and monitoring—not a certificate attached to a checkpoint.

The central distinction is simple: pretraining asks, “What text is likely here?” Assistant post-training adds, “Among plausible continuations, which behavior should this system choose for the person and situation in front of it?” Modern assistants are built because the first question creates capability, while the second shapes how that capability is used.