Fine-Tuning vs. RAG vs. Prompting
The question isn't which one is best. It's which problem each one actually solves.
Intermediate
| Problem | Right lever | Why |
|---|---|---|
| Model doesn't know a fact, or facts change often | RAG | Facts live outside the weights and can be updated by re-indexing, not retraining |
| Model knows the facts but answers in the wrong format/style/tone | Prompting first, fine-tuning if prompting can't hold it consistently at scale | Format and style are about steering generation, not injecting new knowledge |
| Model needs a narrow skill applied consistently across thousands of calls, and per-call prompt overhead to specify it is costly | Fine-tuning | Bakes the behavior into the weights once instead of re-explaining it every call |
| Model needs to take actions, not just answer | Neither — that's tool calling | Different problem: execution, not knowledge or style |
Prompting is nearly free to try and iterate on, so it should always be exhausted first. RAG is the next step up in cost/complexity and solves the single most common reason production LLM apps disappoint: the model doesn't have the specific, current, or private information the answer requires. Fine-tuning is the most expensive and slowest to iterate on, and — contrary to a common assumption — is a comparatively weak tool for injecting new factual knowledge reliably; it's much better suited to teaching consistent behavior (format, tone, a narrow classification task) than to teaching facts.
# a realistic production stack uses all three at once
system_prompt = "Answer only from the provided context. Cite sources." # prompting
retrieved_docs = rag_pipeline.retrieve(user_query) # RAG
model = "support-bot-ft-v3" # fine-tuned on the company's Q&A style/format
response = call_model(model, system_prompt, retrieved_docs, user_query)