Overview

Fine-tuning changes the model's learned weights toward a training distribution's form, style, and task behaviour, which shows up reliably as consistent output shape. It does not append verifiable facts the way retrieval does -- any fact baked into weights is frozen at training time and cannot cite itself, so using it to install knowledge is both unreliable (memorized facts blur or hallucinate) and expensive (stale the moment training ends).

Fine-tuning a model specifically to teach it new facts. It fails because facts baked into weights are frozen the moment training completes -- the model is stale immediately, cannot cite a source, and any subsequent fact change requires retraining, while retrieval solves the same problem freshly, cheaply, and with citations.

Because a substantial share of quality gaps close with better instructions, few-shot examples, and enforced structure -- at zero training cost and with instant iteration. Skipping straight to fine-tuning without measuring prompting's own ceiling risks paying training cost for a gap a prompt change would have closed for free.

Retrieval. It supplies current, citable, updatable facts without ever touching the model's weights, whereas fine-tuning on facts produces a model stale from the moment training ends and unable to cite where an answer came from.

Narrowing the task to a smaller, more specific version of what is being asked is frequently enough to bring an unadapted base model's performance up to an acceptable level, at zero training cost. Checking scoping first avoids paying an adaptation's cost to solve a problem that was really "the task was too broad," not "the model needs new weights."

A measured gap; that prompting, retrieval, and scoping have each been genuinely attempted and still fall short; that the gap is behaviour-shaped, not knowledge-shaped; that the needed data is actually obtainable; and that evaluation is possible before any training work starts.

A consistent output format instructions cannot reliably enforce; a domain register or style with no compact textual description; proprietary task behaviour that cannot be described in a prompt; latency or cost reduction via a smaller adapted model; and tool-use patterns the base model handles poorly.

Data labour (collecting, authoring, and auditing the dataset), training compute, evaluation, and -- easy to forget -- the standing maintenance obligation: the model must be re-adapted whenever its base changes, a recurring cost, not a one-time one.

Produce the target output given the input, by training directly on paired instruction/response examples -- the model learns to reproduce the mapping demonstrated in the dataset.

That outcome quality is determined by the dataset far more than by any training hyperparameter -- teams that spend their effort tuning learning rate and epochs while under-investing in dataset curation are optimizing the wrong lever.

Noisy examples teach the model a blurred, inconsistent version of the target behaviour, and more noisy volume just reinforces that blur faster. A small, consistent, on-distribution set gives the model a clean, learnable signal with nothing to average against.

Two conflicting examples in a dataset do not raise any error during training -- the loss just settles on an averaged, inconsistent behaviour. The only way to catch it is to look, either with an explicit consistency audit before training or by noticing the model's own inconsistent behaviour at eval time, after the cost is already spent.

Production traffic (reflects real usage but is biased toward whatever traffic already happens most), expert authoring (high quality but expensive per example), and synthetic generation (fast and cheap but bounded by the generating model's own errors).

It is bounded by the teacher model's own correctness -- any error the teacher makes propagates silently into the generated dataset, and the student trained on that data inherits the same error with no warning sign.

Memorization masquerading as improvement. Without a genuinely held-out split, a reported quality gain could just mean the model memorized its own training data rather than generalized -- the split is what makes "did this help" a falsifiable question.

A leaked case means the model may have memorized the exact answer rather than generalized to it -- that inflated single case's pass makes the aggregate pass rate untrustworthy as a signal, since you can no longer tell how much of the improvement is real generalization versus memorized answer-matching.

Updating every parameter in the model. It is the most powerful and most expensive option, and -- because nothing is held frozen -- the most prone to degrading capability the fine-tune was never meant to touch.

It trains a small set of added parameters while freezing the base model entirely, capturing most of a full fine-tune's benefit at a fraction of the compute and artefact size, with far less collateral damage to capability outside the training distribution -- for nearly every application case, this trade is the right one.

Trainable low-rank matrices injected into the model's layers; the base model's own weights are left completely untouched -- only the small added matrices are ever updated during training.

Rank bounds how much behaviour change the adapter can express -- a capacity knob. Raising it can capture more complex behaviour, but it also grows the adapter's size and its overfitting risk on a small dataset, so rank should be chosen from a measured sweep, never defaulted.

Adapters are small, versionable, swappable, and independently serveable against a shared base -- several task-specific behaviours can be hot-swapped in and out of one loaded base model, something a full fine-tune's own separate whole-model checkpoints cannot do this cheaply.

A target-task eval alone only checks the capability the fine-tune was meant to change -- it says nothing about capability outside that scope. Forgetting only becomes visible once a dedicated regression suite, covering untouched capability, is run and its score is compared against the base.

Training loss is computed only on training data, so it keeps improving as the model increasingly memorizes that exact data -- it has no visibility into held-out performance, which can peak early and then decline while loss keeps looking better and better.

Learning rate, epoch count, and adapter rank dominate; most other configuration knobs are noise relative to dataset quality -- sweeping the wrong knobs while the dataset itself is noisy will not recover the result a clean dataset would have given for free.

A measured, paired comparison against the unadapted base model -- on the target task AND on a regression suite covering untouched capability -- never a single retrospective claim or two isolated pass-rate numbers reported in isolation.

The fine-tune's own target task. A regression suite is built entirely from capabilities the fine-tune was never meant to change -- that is what makes catastrophic forgetting (co-22) detectable rather than merely assumed absent.

Reproduce a larger teacher model's behaviour, pursued for latency and cost reduction -- never for a capability gain the base model itself could not already provide.

The student is trained to reproduce the teacher's own outputs, so it inherits the teacher's errors along with its correct answers, and its ceiling is bounded by however good the teacher actually is on its own measured, held-out eval -- not by an assumed or quoted-from-elsewhere figure.

Loading, swapping, and routing between adapters against the serving stack, with real memory and routing implications -- several adapters sharing one loaded base changes the deployment's own memory footprint and requires a mechanism for finding and attaching the right adapter to the right request.

The adapter is pinned to the exact base-model version it was trained against. When the deployed base is upgraded past that pin, the SAME adapter becomes incompatible and must be re-adapted -- this is a recurring, owned cost, not a one-time training expense.

Before training begins, not after. Verifying afterward means a licence or rights problem is discovered only once the cost of curation and training has already been sunk -- and per this course's own capstone, the same check applies again to any REPLACEMENT candidate considered at retirement time, not only at the original training decision.

Adapters age against better alternatives the same way any production artefact does -- a better base model or a retrieval solution can eventually beat a fine-tuned adapter on both quality and cost. Planning for that outcome, and retiring the adapter once evidenced, is the discipline this course asks for, not an admission that the original adaptation was a mistake.

This is the knowledge-injection mistake (co-02) -- fees are facts, not behaviour, and baking them into weights freezes them the moment training ends. The fix is retrieval (co-04): serve the fee schedule from a live, updatable source instead of training it into the model, so a quarterly fee change never requires a retrain.

The decision procedure (co-06) was skipped -- specifically, prompting (co-03) was never genuinely attempted and measured. A "always end with a one-line summary" instruction is exactly the kind of format requirement enforced instructions and structured output handle at zero training cost; jumping to fine-tuning without measuring the prompting alternative first violates the gate's own ordering.

The dataset likely fails a consistency audit (co-12) -- conflicting macros teach the model contradictory versions of the same behaviour, and the model will learn an averaged, inconsistent result that no single macro author intended. Size (4,000 examples) does not fix this; the fix is an explicit consistency audit BEFORE training, not more volume (co-10, co-11).

This is data leakage (co-16) -- twelve of fifteen eval cases were memorized during training rather than genuinely generalized to, so the 99% score is not trustworthy evidence of anything. The fix is to rebuild a genuinely disjoint eval set (co-15), re-run the comparison against the base, and treat the original 99% figure as void, not as a starting point to adjust from.

Two compounding issues: an oversized rank on a small dataset overfits (co-20), and training loss -- computed only on training data -- never revealed it (co-23). The fix is to run a rank sweep against held-out validation (not training loss) and choose the rank where the marginal validation gain flattens, rather than defaulting to the largest available option.

A regression suite covering capabilities the fine-tune was never meant to touch (co-26), run alongside the target-task eval, would have caught this as catastrophic forgetting (co-22) before shipping. A single target-task eval, however good its own result, cannot see damage outside its own scope -- co-25's mandate is both signals together, never one alone.

Distillation is a cost and latency optimization, never a quality technique (co-27) -- the student is trained to reproduce the teacher's own behaviour and inherits its errors, so it can approach but never exceed the teacher's measured ceiling (co-28). The team's disappointment reflects a wrong expectation, not a failed technique; the correct comparison is latency and cost saved against a small, accepted quality cost, not a quality win.

Train a small adapter for the tone difference and hot-swap it in against the SAME shared base (co-21, co-29) -- adapters are small, composable, and independently serveable, so this one customer's tone need not require a whole separate model deployment. A full standalone deployment is far more expensive to run and maintain for a behaviour difference this narrow.

Because the answer to that one question determines which of two entirely different, non-overlapping toolkits applies -- retrieval for knowledge gaps, adaptation for behaviour gaps -- and getting it wrong wastes real cost in the wrong direction. Fine-tuning a knowledge gap produces a stale model that cannot cite sources; trying to "retrieve" a behaviour gap (a tone, a format) does not even make sense, since there is no document to retrieve. Every other step in the decision gate assumes this classification was made correctly first.

Because for nearly every application-engineering case, the adapter captures most of the benefit at a fraction of the cost, with far less collateral damage to untouched capability -- the asymmetry in risk and cost is large enough that starting from "adapter, unless proven insufficient" catches the common case correctly, while starting from "full fine-tune, unless proven unnecessary" pays the larger cost and risk by default on cases that never needed it.

Co-15 is the structural discipline -- splits must be genuinely disjoint, or nothing downstream is trustworthy. Co-23 is what happens even WITH a correct split, if you only watch the wrong signal: training loss keeps improving by construction as the model memorizes its own training data, so a correct split is necessary but not sufficient -- you also have to actually WATCH the held-out split's own score, not just trust that loss going down means things are getting better.

Because a target-task comparison, however statistically rigorous, only ever measures the capability the fine-tune was meant to change -- it has no visibility into capability outside that scope by construction. A statistically significant target-task win can coexist with severe catastrophic forgetting (co-22) that the target-task eval was never designed to catch; only a dedicated regression suite, covering deliberately untouched capability, closes that blind spot.

Distillation replaces a large model with a smaller one trained to reproduce it, optimizing specifically for latency and cost at an accepted, bounded quality cost -- the student's ceiling is set by the teacher. Retiring an adapter (co-32) replaces an adapted model with something that beats it on BOTH quality and cost -- a genuinely better base model or a retrieval solution -- there is no accepted quality trade in that direction; retirement only happens once a strictly better alternative is measured, not merely available.

Co-08 is about budgeting a fine-tune's TOTAL cost correctly at decision time -- data, compute, eval, and maintenance, all named up front. Co-30 is about what happens AFTER shipping: the adapter is pinned to a specific base version, and every future base upgrade re-opens a compatibility question that has to be checked, not assumed. Separating them matters because co-08's mistake is a one-time budgeting error made at the start, while co-30's mistake is an ongoing operational blind spot that resurfaces every time the platform team ships a new base model, long after the original budget was approved.