The adaptation menu

'Fine-tuning' is a menu, not a dish. Four techniques cover the practical territory, and they're less alternatives than stages — most real adaptation pipelines use two or three in sequence:

• Supervised fine-tuning (SFT) — show the model thousands of (input → ideal output) pairs; training nudges its weights toward producing outputs like yours. The workhorse: it's how format, style, and task skill get installed. Everything rides on the dataset (Module 2 exists for a reason), and the classic failure is imitation without understanding — the model learns your outputs' shape faster than their logic, which is why eval design matters more here than anywhere.
• LoRA (and friends) — how SFT is actually run. Full fine-tuning updates billions of weights and needs serious hardware; LoRA trains small low-rank adapter matrices alongside frozen base weights — well under 1% of the parameters for typical ranks, a fraction of the memory, nearly all of the quality for task adaptation. The one dimension worth grounding now: rank = the size of the adapter's bottleneck dimension — higher rank = more trainable parameters = more capacity and more overfitting risk. Practical consequences: consumer-GPU or cheap-cloud training, adapters are megabytes you can swap per-task on one base model, and 'which rank?' becomes one of exactly three hyperparameters you'll actually touch (Module 3). Unless you have datacenter-scale reasons, LoRA is fine-tuning for you.
• Preference tuning (DPO and family) — SFT teaches 'produce outputs like these'; preference tuning teaches 'between these two outputs, produce ones like the better.' Fed with (prompt, chosen, rejected) triples, it polishes what SFT can't quite specify: tone calibration, verbosity control, judgment calls where 'good' is easier to recognize than to demonstrate. DPO made this practical without RLHF's reinforcement-learning machinery — Module 4 covers both the concept and the pitfalls (length bias will find you).
• Distillation — the economics play. A large teacher model generates high-quality outputs for your task; a small student is SFT'd on them. Not a new technique — it's SFT with a strategy about where the data comes from — but it deserves its own name because it's the pattern with the clearest business case, and Module 5 runs it end to end.

The standard pipeline (and this course's arc)

Real adaptation projects converge on: baseline with best prompt → build/generate dataset → SFT (via LoRA) → measure → preference pass if a quality gap has a preference shape → measure → ship behind the same eval gate as any change. That's also this course's module order, on one running project: Harbor Lane's email triage (category / urgency / extraction, the triage schema you know from earlier courses, extended here with finer-grained categories like refund_request), currently run by a frontier model with excellent quality and a real bill. Teacher: the frontier model. Student: an 8B open model. Target: match the teacher within an agreed tolerance on the eval set, at a twentieth of the cost. Every module moves that project one stage.