RAG or fine-tuning?
Two techniques, constantly confused. Three questions usually settles it.
This needs JavaScript. Every possible answer is shown below.
RAG
Your problem is facts, and facts that move. Fine-tuning bakes knowledge in at training time, so every update means retraining. Retrieval fetches at query time — update the document, the answer updates. You also get provenance: the passage that produced the answer is right there to show someone.
Watch out: Budget your effort for the retrieval half. Most disappointing RAG systems are retrieval failures wearing a generation costume — the right passage was never fetched. Evaluate retrieval on its own before you judge the answers.
Fine-tuning
You've earned it: prompting was tried and it's either inconsistent or you're paying for a wall of instructions on every call. That's exactly what fine-tuning fixes — consistent behaviour, baked in, shorter prompts, cheaper inference.
Watch out: Start with LoRA, not full fine-tuning. And build a held-out eval set before you train, or "it feels better" will be your only evidence the expensive thing worked.
Just put it in the prompt
It's small and it's stable. Context windows are large now. A vector database, a chunking strategy and a retrieval pipeline is a lot of machinery for something that fits in the prompt.
Watch out: Revisit when the material outgrows the window, or when you're re-sending the same preamble often enough that caching or retrieval would be cheaper.
Few-shot prompting first
Put three good examples in the prompt before you train anything. It's free, instant, and competitive with fine-tuning on a surprising share of tasks. Skipping this is the most common expensive mistake here.
Watch out: If it's still inconsistent after honest examples and a real eval set, come back — that's the signal fine-tuning is actually warranted.
Recommendations come from the same judgment as the “when not to use it” and “alternatives” sections on every concept page. Disagree with one? That is the point of showing the reasoning.