Prompting vs RAG vs fine-tuning

You now know the machine well enough for the course's most practical lesson: the one that saves real money in real meetings. Every organisation flirting with AI eventually asks "how do we make it work for us — our documents, our tone, our tasks?" and the market will happily sell three very different answers. People who can't tell them apart buy the expensive one first. Here they are, in the order you should reach for them.

Dial one: prompting — change what it reads

The cheapest dial, and the one this course has been secretly teaching throughout: change the input, change the behaviour. Instructions, examples of the output you want, standing context in a project or system prompt (lesson 6's rulebook, rented out to you) — all of it works because the model re-reads its whole desk every turn (lesson 8) and is exquisitely steerable by what's on it. Want answers in your company's tone? Show it three examples. Want a strict report format? Paste the template. As of mid-2026 the frontier models are good enough that well-crafted context solves most customisation people assume needs something heavier — at roughly the cost of an afternoon's writing. Its honest limits: instructions consume desk space, and the model can drift from them in long sessions. Start here, always; be genuinely surprised if you need more.

Dial two: RAG — change what it can look up

When the gap is knowledge — your policies, your catalogue, your tickets, anything too big for the desk or changing too often to paste — you already know the answer from lesson 10: leave the model untouched, build the fetch step. Costs more than prompting (there's a search system to stand up and maintain), and its failures are retrieval failures. But knowledge stays fresh by updating documents, not models, and answers arrive with citations. The test that picks this dial: would the right document on the desk fix the answer? If yes, it's a RAG problem.

Dial three: fine-tuning — change the model itself

The heavy dial. Fine-tuning continues a model's training on your own examples — hundreds to thousands of input-output pairs — actually nudging the internal settings (the same mechanics as lesson 6's instruction tuning, pointed at your niche). Done well, it deeply ingrains a behaviour: your exact document format, your industry's dense jargon, a consistent classification policy — reflexes too intricate or too numerous to keep re-explaining on the desk.

And here is the sentence that pays for the lesson, because the confusion it targets costs companies real money: fine-tuning teaches behaviour, not facts. Tuning on your HR manual does not give the model a reliable copy of the leave policy — it gives a model that sounds fluent in your HR manual's style, hallucinating within it as confidently as ever (it's still a blur, lesson 5 — now a blur with your accent). Facts that must be right come from retrieval, where they can be fetched, cited, and updated. Teams that fine-tune for knowledge get the worst of both: training bills and hallucinations, now harder to spot because the tone is pitch-perfect. The test that picks this dial: is the problem how it behaves on the ten-thousandth repetition of a well-defined task — not what it knows?

The order is the answer

The three dials aren't rivals; they're an escalation path, and they stack (a tuned model with retrieval and a good prompt is a normal production system). But the order of attempts is settled practice, and it runs by cost of being wrong: prompting is reversible in minutes, RAG in weeks, fine-tuning is the one you re-do every time the base model improves. So: prompt until prompting visibly fails, retrieve when the missing piece is knowledge, tune when the missing piece is a reflex — and treat any pitch that starts at dial three with the suspicion it has earned. When you're ready to go hands-on, the Pro shelf covers each dial at full depth: Prompt Engineering, Building RAG Systems, and LLM Fine-Tuning.

Try this in your chatbot: describe a real workflow from your job and ask: "If I wanted an AI system to do this — what part is solvable with careful instructions, what part needs my documents available for lookup, and what part would genuinely require fine-tuning a model? Argue it." You've just had the build-strategy conversation most vendors hope you'll skip.