Why base models aren't assistants

01 · Concept

Concept

Send the sentence “Write three reasons to test backups” to the Qwen3.8-27B checkpoint the Qwen Team published on 14 August 2026 under Apache 2.0, and you get three reasons — preceded, by default, by a separate thinking segment, because thinking mode is this model’s default behaviour. Send the same sentence to a pretrained checkpoint that has never been post-trained, and the sentence is simply text. The likeliest continuation might be a fourth bullet from somebody else’s blog post, a rewritten headline, a snarky “and two reasons not to”, or a paragraph explaining why the question matters. Same arithmetic, same 64 layers, same 5120-dimensional residual stream, same vocabulary of 248,320 tokens. Radically different product.

The difference is not knowledge. It is which of many plausible continuations the model selects. 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. Written out over a whole response,

and the trouble is that many different sequences $y$ can carry comparable probability mass under the same prompt $x$. The corpus contains answers, questions, arguments, fiction, source code, spam, unsafe instructions, corrections, and unfinished fragments. Predicting that mixture well is a different job from behaving like a reliable assistant.

Work the example through explicitly. Take the prompt above and enumerate four continuations a strong base model might rank highly. First, the three reasons themselves — this is what the user wants. Second, a fifth line reading “Write three reasons to test restores, too”, because prompts of this shape appear in lists of prompts. Third, a critique: “This question assumes backups are already running.” Fourth, a document header, because imperative sentences frequently sit under one. Now ask what in the training objective distinguishes the first from the other three. Nothing does. All four are things that follow such a sentence somewhere in written text, and the model was scored only on how well it predicted the text that actually followed. The user’s expectation — treat the imperative as an instruction directed at you, and execute it — lives entirely outside next-token prediction. This is behavioural underspecification: the capability is present, the selection rule is not.

Here is the classic wrong turn. Many people conclude that the base model simply does not know how to write three reasons, and that post-training teaches it. Test that claim and it collapses. Prefix the same base model with two worked examples in the same format and it produces a competent third — the knowledge and the format were both already there, elicited by context instead of by weights. What post-training changed was not competence but the default: which behaviour wins when the context contains no demonstration at all. Getting this backwards leads teams to throw capability data at a behaviour problem, and to be surprised when a bigger SFT set makes the model no more obedient.

Post-training narrows the distribution of acceptable behaviour. Supervised fine-tuning shows prompts paired with desirable responses (lesson 6.2). Preference optimization compares responses and raises the relative probability of the better one (lessons 6.4 through 6.7). Reinforcement learning against checkable outcomes rewards solutions that actually work (lesson 6.8). The result is usually called an instruct or assistant model. Internally it is still predicting tokens; its weights simply make assistant-shaped continuations far more likely inside the conversational format used during training.

Qwen3.8-27B makes the layering unusually easy to see, because the vendor ships two distinct operating modes in one set of weights. Thinking mode is the default. Among the model card’s full recommended settings, it uses temperature 1.0, top_p 0.95, and top_k 20; instruct mode uses 0.7, 0.80, and 20. Min-p, presence penalty, and repetition penalty complete both configurations, as lesson 7.4 details. A caller who wants the direct answer without the reasoning segment sets enable_thinking to False on the request. None of that is a property of the transformer; all of it is post-training plus a serving convention.

Formatting deserves respect. Chat models receive structured roles — system, user, assistant — encoded through a chat template. Those markers are ordinary tokens, not privileged permissions. The model has to learn that system content outranks user content, that user text may contain quoted or hostile instructions, and that the assistant turn is where the answer belongs. Feeding a post-trained checkpoint a template different from the one it was trained under degrades behaviour even when the prose looks identical.

One honest limit specific to this specimen: Qwen3.8-27B has no accompanying technical report. We can observe and cite what the model card documents — the modes, the presets, the switch, the reported benchmark scores — and we can measure the checkpoint ourselves. We cannot say what data or procedure produced the behaviour, and this course will not pretend otherwise.

Alignment is not obedience, either. A useful assistant balances instruction following against truthfulness, safety, privacy, and honest uncertainty, and those goals collide: a request can be clear but unsafe, a factual answer unknown, a concise reply dangerously incomplete. No scalar called “helpfulness” resolves every case. Nor is the result permanent — behaviour still shifts with phrasing, long contexts, distribution shift, decoding settings, and conflicting instructions. Alignment is an engineering process spanning training, evaluation, system design, access control, and monitoring, not a certificate stapled to a checkpoint.

The central distinction is one question becoming two. Pretraining asks: what text is likely here? Assistant post-training adds: among the plausible continuations, which behaviour should this system choose for the person in front of it right now?