Fine-Tuning vs. RAG vs. Better Prompting: An Honest Decision Framework
“Should we fine-tune?” gets asked constantly, and it’s usually the wrong first question — not because fine-tuning is bad, but because the three tools people mean by it (fine-tuning, RAG, better prompting) fix genuinely different problems, and picking based on hype instead of diagnosis is the most expensive mistake in applied LLM work: fine-tuning specifically has a real setup cost in data and time that the other two don’t.
The diagnostic question for each
Is the model missing knowledge it needs? That’s a retrieval problem. The model doesn’t need to become different — it needs access to information it doesn’t have in its training data, which is exactly what RAG (retrieval-augmented generation, covered in its own strand of articles on this site) solves: fetch relevant context at query time and put it in the prompt.
# the model doesn't know your internal docs — give it access, don't retrain it into knowing
context = retrieve_relevant_chunks(query, your_document_index)
response = llm_call(f"Context: {context}\n\nQuestion: {query}")
Is the model capable of the task but doing it inconsistently or in the wrong format? That’s usually a prompting problem, and it’s worth genuinely exhausting before reaching for anything more expensive — better instructions, examples, or structured output constraints frequently fix what looks like a “the model isn’t good enough” problem:
# often "the model gets this wrong" is actually "the instructions are ambiguous"
vague_prompt = "Summarize this ticket."
better_prompt = (
"Summarize this support ticket in exactly 2 sentences: the customer's "
"problem, and what they're asking for. No greeting, no sign-off."
)
Does the model need to reliably produce a specific style, format, or behavior across thousands of examples, where prompting alone produces too much variance? That’s the actual fine-tuning case — not “the model doesn’t know something” (RAG’s job) and not “the model occasionally gets it wrong” (prompting’s job usually fixes that), but “the model is capable, has the knowledge, and still doesn’t reliably converge on what you need without seeing many examples of the exact desired behavior.”
Why fine-tuning is usually reached for too early
Fine-tuning has real, upfront costs the other two don’t: you need a genuinely good training dataset (hundreds to thousands of high-quality examples, not a handful), retraining every time you want to change behavior, and a way to evaluate whether the fine-tuned model actually improved on the thing you cared about instead of regressing on something you didn’t think to test. Compare that to a prompt change, which is testable in minutes with an eval harness and reversible instantly. The asymmetry in iteration speed alone should make prompting and RAG the default first attempts, with fine-tuning reserved for cases that survive both.
A concrete example of picking wrong
A team wants a customer-support bot to answer questions about their product using internal documentation, in the company’s specific tone, formatted as short bullet-point answers. The instinct is often “fine-tune it on our support tickets.” Walking through the diagnostic: the model doesn’t know the product docs — that’s RAG. The specific tone and bullet format is a prompting problem, testable and iterable in an afternoon. There’s no actual evidence yet that a well-prompted model with RAG can’t produce consistent enough output — fine-tuning was reached for before the cheaper options were tried and shown insufficient, not after.
The actual decision rule
Try prompting first, always — it’s the fastest to test and revert. Add RAG when the failure is specifically “the model doesn’t know this,” not “the model phrases it wrong.” Only reach for fine-tuning once you have concrete evidence — from real production failures, not a hunch — that a well-prompted model with the right context still can’t converge on the behavior you need across enough examples for consistency to matter. In practice, most teams that “need to fine-tune” haven’t actually exhausted the first two, and the honest first exercise is proving that they have before spending the time fine-tuning costs.