Three different techniques all promise to make a model "know" more than it did out of the box, and it's genuinely common to reach for the wrong one - or to bolt on RAG when a bigger context window would've been simpler, or to fine-tune when what you actually needed was better retrieval. Each solves a different problem, and knowing which one you have is most of the decision.
What each technique actually changes
RAG doesn't change the model at all - it changes what's in the prompt. At query time, relevant documents are retrieved and inserted into the context window alongside the question, so the model reasons over information it was never trained on.
Fine-tuning changes the model's weights through additional training on your own examples. It doesn't add knowledge so much as it adjusts behavior - tone, format, task-specific patterns - and any "knowledge" it picks up is baked in at training time and frozen until you fine-tune again.
Long context is just using a model with a large enough context window to paste the relevant material directly into the prompt, with no retrieval step at all - if the whole knowledge base fits, you skip the pipeline entirely.
Same destination, three very different mechanisms for getting outside knowledge into the model's reasoning.
When RAG is the right call
Reach for RAG when the knowledge is large, changes often, or needs to be attributable - a support knowledge base updated weekly, a document set too big to fit in any context window, or an answer that needs to cite its source. RAG's core strength is that updating the knowledge base is just re-indexing documents, not retraining anything.
When fine-tuning is the right call
Fine-tuning earns its cost when the problem is behavioral, not informational - you need consistent output formatting, a particular tone, or a narrow task pattern repeated thousands of times (like structured data extraction in a specific schema). It's a poor fit for "the model needs to know our latest pricing," because that's a knowledge problem, and fine-tuned knowledge goes stale the moment the underlying facts change.
When long context is enough on its own
If the entire relevant knowledge base is small enough to fit in a single context window - a handful of documents, a codebase under a certain size - pasting it all in directly can outperform RAG, because there's no retrieval step that might miss something relevant. The tradeoff is cost and latency: re-sending the same large context on every request is far more expensive per query than retrieving a handful of relevant chunks, and it doesn't scale as the knowledge base grows past what fits in the window.
Where they combine
These aren't mutually exclusive. A common production pattern is RAG for the knowledge (retrieving relevant chunks) combined with a lightly fine-tuned model for output format and tone, or RAG with a long-context model used to reduce how aggressively you need to chunk - larger context windows mean you can retrieve fewer, larger chunks and lose less surrounding context per retrieval.