Which of these are valid reasons NOT to fine-tune?

Attempt it

Quick reference

TL;DR

Skip fine-tuning when prompting or RAG already suffices, when knowledge changes often, when data is scarce, when you lack an eval harness, or when the base is already strong enough.

Memory aid

Sign in for the mnemonic that makes this stick. See Pro pricing.

Easy to grasp

Fine-tuning is like sending an employee to an expensive multi-week training course. It permanently rewires how they work. You only do that when cheaper options have failed. If a sticky note on their desk fixes the problem, you write the note instead of booking the course. If the facts they need change every day, a note works but the course goes out of date instantly. If you have only three examples to train on, the course teaches the wrong habits. And if you cannot test whether the course actually helped, you have no way to know if you wasted the money. So before booking, you ask: would a note, a folder of references, or the employee's existing skills already do the job?

Key concepts

Evaluation harness Retrieval-Augmented Generation Prompt engineering

Quick scan · 2–4 min

Everything important, quickly.

4 min: escalation ladder framing + redundancy disqualifiers + missing-prerequisite disqualifiers + wrong-tool disqualifiers + the volume trap + eval harness as precondition.

Side-by-side

Situation	Reach for instead	Why not fine-tune
Knowledge updates daily	RAG over a live index	Weights go stale the moment data changes
Fewer than ~500 clean examples	Few-shot prompting	Training overfits instead of generalising
Prompt already clears the golden bar	Keep the prompt	Marginal lift, real regression risk
Need strict JSON output	Structured-output or constrained decoding	Format is decoding, not a weight edit
Need database or tool access	Tool-calling and orchestration	Access is infrastructure, not weights
High request volume	Maybe distillation for cost	Volume is not a quality gap

Real-world examples

Real products, models, and research that use this idea.

OpenAI's own fine-tuning guide tells teams to exhaust prompt engineering and retrieval before fine-tuning, treating it as a later-stage optimisation.
Teams enforcing strict JSON on GPT-5.5 or Claude Opus 4.7 use native structured-output modes and libraries like Outlines rather than fine-tuning for schema adherence.
Perplexity keeps fast-changing web knowledge in a live RAG index rather than baking it into model weights that would go stale within hours.
Distillation stacks fine-tune a small Llama 4 student on a larger teacher's outputs purely to cut per-call inference cost at high request volume.
RAGAS and LangSmith eval harnesses are stood up first so teams can measure whether a fine-tune actually beat the prompt-only baseline.

Interviewer follow-ups

What an interviewer would ask next. Try answering before peeking at the approach.

QWhy does high request volume motivate distillation but not plain fine-tuning?

Sign in or go Pro to see the approach for this follow-up.

QHow few examples is too few, and what actually goes wrong below that threshold?

Sign in or go Pro to see the approach for this follow-up.

QWhy is the absence of an eval harness a hard blocker rather than a nice to have?

Sign in or go Pro to see the approach for this follow-up.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

Sign in for 5 unlocks/day or go Pro for unlimited revision sheets. See Pro pricing.

References

Primary sources. Skim if you want the original framing.