When to adapt (and when you're about to waste a quarter)

This course begins with its most valuable lesson: most teams that think they need fine-tuning don't. They need better prompts (a Prompt Engineering problem), better retrieval (a Building RAG problem), or a bigger model for the hard step. Fine-tuning done for the wrong reason costs a quarter of engineering time and produces a model that's worse than the prompt it replaced — while quietly freezing your system to a snapshot of your data. So: the framework first, the enthusiasm after.

The one sentence that sorts everything

Fine-tuning teaches a model how to behave; retrieval teaches it what's true. Adaptation reshapes behavior: output format, style and voice, task-specific skill, domain vocabulary fluency. It is the wrong tool for facts: knowledge baked in by training goes stale the day your docs change, can't cite sources, and can't be deleted when a customer invokes their rights. Return policies, product specs, account data — retrieval, always. The teams that get this backwards fine-tune on their knowledge base, watch it hallucinate confident hybrids of old and new policy, and conclude fine-tuning doesn't work. It works; it was aimed at the wrong target.

The three honest cases for adaptation

• Cost/latency at volume (the big one). A frontier model does your task superbly at $X per thousand calls; a small model fine-tuned on the frontier model's outputs does it nearly as well at X/20 and a fifth of the latency. When volume is high and the task is narrow, distillation (Module 5) is the strongest business case in this course — and it's the running project: Harbor Lane's triage runs 50k classifications a month on a frontier model; you'll make an 8B model match it.
• Behavior that prompts can't hold. Some behaviors resist prompting at any prompt length: rigid output schemas under adversarial input, a precise brand voice across thousands of generations, consistent handling of a domain's jargon and edge conventions. If your eval shows the behavior degrading no matter how the prompt grows — and you can show the eval — adaptation is the honest next step.
• The capability gap in small models. You need on-device, air-gapped, or data-residency-constrained deployment; the models that fit don't do your task well enough raw. Fine-tuning is how a 3-8B model punches above its weight on one narrow task — never in general.

The prompting ceiling: prove it before you tune

The gate this course enforces: before any adaptation, you must demonstrate the prompting ceiling — a real eval set (you built these in RAG; they're mandatory equipment here), your best-effort prompt (few-shot, structured, iterated — genuine best effort, not a strawman), and the measured gap between that score and your requirement. No measured gap, no fine-tune. This gate has a second function: the eval set and strong prompt you build to prove the ceiling are reused as your fine-tune's baseline and your teacher's harness. Nothing is wasted — which is exactly why the gate is safe to enforce.