2.5.2. Fine-Tuning vs. Prompt and Grounding Strategies
💡 First Principle: Fine-tuning is the last lever, not the first. Reach for it only after prompting and grounding have failed to deliver consistent behavior — and only for behavior/format consistency, never to inject facts (which is grounding's job, as established in Phase 1).
The decision ladder: try prompting (cheapest, instant), add grounding if facts are missing, and fine-tune only if you still need consistent style/format/structure that prompting can't reliably enforce or that's too expensive to specify every call. Fine-tuning trains on input→output examples to shift the model's defaults; it incurs training and hosting cost and locks you to a customized deployment.
⚠️ Exam Trap: This is the highest-value trap in the domain. "Fine-tune the model on our knowledge base so it knows our data" is wrong — fine-tuning teaches patterns, not facts, and can't include data created after training. The fact-recall job is grounding. Reserve fine-tuning for how the model responds, never what facts it knows.
Reflection Question: A team wants the model to (a) consistently output in their strict ticket-template format and (b) reflect policies that change monthly. Walk the decision ladder: which lever for each, and why is fine-tuning wrong for one of them?
