Supervised Fine-Tuning (SFT): What It Can and Cannot Change

Supervised fine-tuning is the process of continuing to train an already-pretrained language model on a curated dataset of labeled input-target pairs, so that its outputs come to resemble the targets. The loss is the same next-token cross-entropy the model was pretrained with (01-05), computed over the target tokens conditioned on the input, and the gradient updates flow through the model's weights via ordinary backpropagation (01-06). What makes it "supervised" is that a human — or a process a human trusted — wrote the target. What makes it "fine" tuning is that it starts from a good model and nudges it, using a learning rate small enough to shift behaviour without dismantling capability.

In its most common form, the pairs are instructions and responses, and the stage is called instruction tuning. But SFT is broader than that. A classification fine-tune where the target is a single label token, a structured-extraction fine-tune where the target is a JSON object, a style-transfer fine-tune where the target is the same content in a house voice — all of these are SFT. The unifying property is that every example carries a written answer the model is asked to imitate.

Three consequences follow directly from "imitate the written target," and they explain essentially everything SFT can and cannot do:

1. SFT is imitation learning, so it excels at anything that is a consistent pattern across examples. Format, length, tone, ordering, hedging language, refusal phrasing, the decision to ask a clarifying question — these repeat across a training set and so are learnable from a few thousand demonstrations.
2. SFT has no notion of truth. The loss rewards producing tokens that match the target. It cannot distinguish "this target is correct" from "this target is confidently wrong," because both are just token sequences. Label noise (08-02) therefore trains error with full force.
3. SFT has no notion of provenance. After training, the model produces the token; it cannot tell you which training example the token came from, and neither can you. There is no citation, no audit trail, and no deletion operation.

Those three properties are the whole argument of this lesson.

L1 — The intuition: a thousand worked answers, not a rulebook

Prompting hands the model a rule at inference time: "answer in three bullets." SFT hands the model a thousand answers that happen to be in three bullets, and lets it infer the rule. The difference matters in both directions. The prompt is instant, free, reversible, and consumes context on every single request. The fine-tune is slow, costly, sticky, and consumes no context at all — the behaviour is baked in, so the prompt can be short and the tokens saved on every request.

The intuition for why behaviour transfers better than facts: across a thousand examples, "three bullets" appears a thousand times and any individual fact appears once. Gradient descent is a frequency machine. It learns what is repeated.

L2 — The mechanics: dataset, template, masking, epochs, and the failure surface

Dataset construction is the majority of the work and the majority of the risk. A usable SFT record has an input, an optional context, and a target that is genuinely the response you want — not an approximation, not a response with a preamble you would strip in post-processing, not a response written by a different model whose habits you are about to inherit. The reason to be strict is that the model imitates everything in the target, including artifacts you did not intend. Train on targets that all begin "Sure! Here's the summary:" and you have trained a model that says "Sure! Here's the summary:".

Template rendering converts each record into the single token sequence the model actually sees. The chat template — the model family's convention for marking system, user, and assistant turns — must match the one your serving stack will use. A mismatch here is invisible in the training metrics and fully visible in production behaviour, and it is one of the most common practical defects in fine-tuning work.

Loss masking determines which token positions contribute to the loss. Masking the input and computing loss only over the target is the standard choice for instruction tuning, because the goal is to learn the response, not to learn to reproduce the request. If you do not mask, a meaningful fraction of your gradient budget is spent teaching the model to generate prompts.

Hyperparameters are where a fine-tune is over- or under-cooked. The two that dominate outcomes are learning rate and number of epochs. Too high a learning rate or too many epochs on a small dataset and the model memorises the training set, loses general ability, and starts producing training examples verbatim in response to unrelated prompts. Too low and nothing changes. Reading the loss curves that distinguish these cases is 12-03; the underlying overfitting concept and the validation split that detects it are 01-07.

The failure surface, ordered by how often it bites:

L3 — Why format transfers and facts do not

Consider a model's weights as a store of statistical regularities over token sequences (01-02). SFT with a small dataset performs a small number of gradient steps at a small learning rate. The question is which regularities can be installed by that budget.

A format regularity is high-frequency and low-dimensional. "Assistant turns in this dataset begin with a heading, contain exactly three bullets, and end without a closing pleasantry" is a single pattern reinforced by every example in the set. Every gradient step points in the same direction on it. The signal is strong, redundant, and cheap to encode.

A factual regularity is low-frequency and high-dimensional. "Part number XR-4491 supersedes XR-4480 as of the 2023 revision" appears in one example, or maybe three. The gradient contribution is tiny relative to the format signal, and the model has no mechanism that flags it as something to store precisely rather than approximately. What often results is partial absorption: the model learns that XR-44-something relates to a supersession, and generates a plausible neighbouring number. That is the worst possible outcome, because it is wrong in a way that reads as right.

There is a further asymmetry that makes fact-installation-by-SFT strategically bad even where it technically works:

The right-hand two columns are the argument. Even at equal accuracy, retrieval wins on verifiability, updatability, deletability, and cost. 07-09 is the pipeline; 07-10 is how you attribute a bad answer to a stage.

Four pairs, four different mistakes. This is the highest-value table on the page.

SFT vs RAG

The single most useful reduction: RAG is right whenever the facts change, citations are needed, or one user's data must be deletable. Any one of those three clauses in a scenario settles the question. Candidate reports for this exam converge on a related heuristic — when one option proposes building a RAG solution it is frequently the keyed answer — with the counter-cases being no corpus, a genuine style or format requirement, and a hard latency floor. 07-12 covers when RAG is the wrong tool so the heuristic is not applied blindly.

SFT vs prompting

The decision rule that matters: never fine-tune before prompting has demonstrably plateaued on a real eval set. Many fine-tuning projects are solving a prompt-engineering problem expensively. 05-02 is prompt structure and 05-04 is how to version and test prompts so "we tried prompting" means something measurable. The exception where SFT wins cleanly on economics is high-volume, narrow behaviour: if a twelve-hundred-token system prompt is being paid for on every one of a million daily requests, folding it into the weights is a real cost argument, and 12-09 supplies the per-token arithmetic.

SFT vs continued pretraining

The test is one question: does your data have a target response? If yes, SFT. If it is a folder of documents, continued pretraining. 11-01 has the full stage map.

SFT vs alignment (RLHF / DPO)

The ordering here is examinable and strict: SFT → reward model from human preference labels → policy optimisation. 11-06 is the mechanism and 11-07 is the reward model and its pathologies. The reason SFT must come first is practical: policy optimisation explores around a starting policy, and a starting policy that does not follow instructions gives the reward model nothing worth ranking.

A support-automation team has a deployed assistant over their product documentation. They collect a month of complaints and want to know whether the fine-tune they have budgeted will help. The counts below are a constructed scenario, not measured data.

The complaint log, categorised:

Total logged complaints                              420

A. "Answer is too long / wrong format"               128   (30%)
B. "Answer cites no source, I can't verify it"        96   (23%)
C. "Answer is factually wrong about a current price"  84   (20%)
D. "Answer used a competitor's terminology"           58   (14%)
E. "Answer should have refused (legal advice)"        34   ( 8%)
F. "Answer misunderstood a multi-step question"       20   ( 5%)

Step 1 — classify each category by mechanism.

Step 2 — sum the addressable share.

SFT-addressable   (A + D + E)      = 128 + 58 + 34 = 220  → 52.4%
RAG-addressable   (B + C)          =  96 + 84      = 180  → 42.9%
Capability-bound  (F)              =                  20  →  4.8%

Step 3 — read the result honestly. A perfect fine-tune caps out at roughly 52% of the complaint volume, and that is the optimistic bound assuming every behavioural target is achievable. Nearly 43% of complaints are architectural and no fine-tune touches them. Meanwhile category A — the largest single bucket — should be attacked with a prompt change first, which costs an afternoon.

Step 4 — sequence the work by cost per point of improvement.

1. Prompt change targeting format/length (Cat A)   ~1 day     up to 30% of complaints
2. Add citation rendering to RAG output (Cat B)    ~3 days    up to 23%
3. Point retrieval at the live pricing source (C)  ~1 week    up to 20%
4. SFT on terminology + refusals (D, E)            ~4 weeks   up to 22%
5. Re-baseline on a stronger model (F)             ~1 week    up to  5%

The fine-tune is fourth on the list, not first, and the two cheapest items address more than half the volume. This ordering is the customisation ladder doing its job. Note that step 4 only becomes coherent because steps 1–3 removed the confounds: if you fine-tune first, you cannot tell whether an improvement came from the weights or from noise, and the categories mix.

Step 5 — decide what "success" means before running. The eval set must contain slices for each category, and the general-ability slice must be in there too, so a 22-point gain on terminology does not hide a regression elsewhere. 01-08 is the construction method and 09-01 is scaling it.

The last row is the one to treat as a hard gate rather than advice. A fine-tune without a pre-existing baseline is an experiment with no control, and the failure it hides most often is catastrophic forgetting, which improves the metric you are watching while destroying one you are not.

The NCA-GENL blueprint places machine-learning fundamentals, model selection, and reading research to track emerging LLM techniques in the Core Machine Learning and AI Knowledge domain — 30% of the exam, the largest block. It separately asks the associate to assist in deployment and evaluation of model scalability, performance, and reliability, and to build LLM use cases such as RAG, chatbots, and summarisers. SFT sits at the junction of all of those: it is the customisation stage an associate is most likely to be asked to help run, and the one whose misapplication most reliably wastes a team's quarter.

Because the exam is multiple-choice and general-level rather than deep-technical, it tests boundaries, not procedures. You will not be asked for a learning-rate schedule. You will be asked, in prose, whether the described situation calls for fine-tuning.

Question phrasings to expect:

• "A team's chatbot answers correctly but in an inconsistent format. What is the most appropriate approach?" — behaviour; prompting then SFT.
• "An organisation's internal policies are updated monthly and answers must reference the policy document. Which approach best meets this need?" — RAG; the words "updated monthly" and "reference the document" both fire.
• "Which of the following does supervised fine-tuning NOT reliably provide?" — up-to-date facts, citations, deletion.
• "Place the alignment pipeline stages in order." — SFT, reward model, policy optimisation.
• "A model produces fluent domain text but fabricates part numbers after fine-tuning on domain data. What best explains this?" — fluency improved faster than factual accuracy; facts land brittlely.
• "What is the primary advantage of fine-tuning over including instructions in every prompt?" — no per-request context cost and higher consistency on the trained behaviour.

Distractor families:

One calibration note that pays off across the whole exam: when an option proposes the cheapest sufficient rung of the ladder and another proposes the most powerful technique, the cheapest sufficient rung is usually keyed. The blueprint's own framing of the associate role — contributing under senior supervision — favours proportionate practice over maximal machinery.

Partially, unreliably, and at a cost profile that makes it the wrong tool even when it works. A fact stated once in a training set of a few thousand examples contributes a vanishing share of the total gradient signal, so what the model absorbs is often an approximation of the fact rather than the fact — a part number that is nearly right, a date in the right year, a policy that is directionally correct and specifically wrong. Because the surrounding language got more fluent at the same time, these errors present as authoritative, which is worse than a visible failure.

Even where absorption succeeds, four properties remain broken. You cannot verify what landed, because there is no mapping from output token to training example. You cannot update it, because the next revision requires another training run. You cannot delete it, because weights have no delete. And you cannot cite it, because the model does not know where it came from. Retrieval gives you all four for free, which is why the rule holds regardless of how good the fine-tune is: facts belong in a retrievable store, behaviour belongs in the weights.

The practical corollary for exam scenarios: the presence of the word "facts," "knowledge base," "documentation," "current," "latest," "cite," or "delete" anywhere in the stem is evidence for retrieval. The presence of "format," "tone," "style," "voice," "always respond with," or "refuse" is evidence for fine-tuning.

Neither, and the reason is that they operate on different objects. SFT modifies the function; RAG modifies the argument. A model with perfect house style and no retrieval will be stylish and wrong about anything recent. A perfect retrieval system attached to a model with the wrong voice will be accurate and off-brand. They compose cleanly, and the composition is the normal production architecture: retrieval supplies grounded, citable context, and a light behavioural fine-tune (usually a LoRA adapter, 11-05) enforces the format and tone the product requires.

Where they genuinely trade off is cost and latency. RAG adds a retrieval hop and inflates the prompt on every single call, which shows up as both latency (12-10) and per-token spend (12-09). SFT front-loads a one-time cost and then charges nothing extra at inference; it can even reduce per-call cost by removing a long instruction prefix. So the economically interesting split is: put changing knowledge in retrieval because you cannot afford to retrain for it, and put stable behaviour in weights because you cannot afford to re-send it a million times a day.

Far less than people expect for behaviour and far more than people hope for anything resembling knowledge, and the honest answer is that it depends on how narrow the target behaviour is. The useful framing is not a number but a ratio: the narrower and more consistent the behaviour, the fewer examples it takes. Teaching one output format across one task type is a small-data problem. Teaching twenty task types with different formats each is twenty small-data problems sharing a budget, and it will need roughly twenty times the data to reach the same consistency per task.

Three practical rules that survive contact with reality:

1. Consistency beats volume. A few hundred examples that agree perfectly on format will install that format better than several thousand that disagree, because disagreement is noise the model averages over.
2. Diversity of input, uniformity of target. You want wide coverage of the inputs the model will actually see and tight consistency in how the target is shaped. The opposite — narrow inputs, varied targets — is the worst combination and produces a model that is both brittle and inconsistent.
3. Scale the eval set with the training set. If you cannot detect a change, you cannot claim one. 09-09 covers why small eval sets cannot distinguish a real gain from noise, and it applies with full force here.

If your honest answer to "how many good examples do you have?" is under a few hundred and the task is broad, the correct move is few-shot prompting (05-01), which uses the same examples with no training run at all and lets you iterate the same day.

Not by itself, and it can make hallucination harder to detect. Fine-tuning on domain data raises the fluency and confidence of domain output, which means fabricated content now arrives dressed in the correct register. Reviewers who were catching errors because they sounded off will stop catching them.

The mechanisms that actually reduce hallucination are grounding, citation, constrained decoding, guardrails, and human review — the mitigation ladder in 09-12. What fine-tuning can contribute is the behaviour of grounding: a model fine-tuned on examples where the correct response is "the provided context does not contain this information" becomes much more willing to say so. That is a real and valuable use of SFT, and note what it is — a behavioural change, an abstention habit, entirely consistent with the rule. It is teaching the model when to decline, not what is true.

• SFT changes behaviour reliably: format, length, tone, register, task framing, refusal and abstention habits. These are high-frequency patterns across a training set, which is exactly what gradient descent on a few thousand examples can install.
• SFT changes knowledge brittlely. Facts are low-frequency signal, absorb unevenly, and produce confident near-misses. Worse, they arrive unverifiable, un-updatable, undeletable, and uncitable.
• RAG is right whenever facts change, citations are needed, or one user's data must be deletable. Any one of those three clauses in a scenario is decisive.
• Do not fine-tune before prompting has demonstrably plateaued on an eval set that existed beforehand. Many fine-tuning projects are expensive prompt engineering.
• The four confusables fail in different directions: SFT vs RAG (behaviour vs knowledge), SFT vs prompting (weights vs context, cost vs speed), SFT vs continued pretraining (labeled pairs vs raw corpus), SFT vs alignment (demonstration vs preference, and the order is fixed).
• The order of the alignment pipeline is strict: SFT first, then a reward model trained from human preference labels, then policy optimisation.
• Fine-tuning does not reduce hallucination; it can mask it by making fabrication fluent. What SFT can install is the habit of abstaining, which is a behaviour.
• The high-volume cost argument is the strongest non-behavioural reason to fine-tune: folding a long system prompt into weights removes tokens you would otherwise pay for on every request.
• No eval set, no fine-tune. Without a pre-existing baseline you cannot separate a gain from a regression, and the regression you will miss is the one in the next lesson.

Everything above assumed you could tell whether the fine-tune helped. There is a specific failure that defeats that assumption in the most uncomfortable way possible: the metric you are optimising improves, the run looks like a success, and a capability you were not watching has been destroyed. It is called catastrophic forgetting, and the only thing that catches it is an evaluation run that existed before you touched the weights. Next: 11-03 shows how forgetting happens, what it looks like in the numbers, and why the eval harness has to predate the training job.