Fine-Tuning vs. RAG: What a Clinic Tool Actually Needs (Usually Neither First)

Ask five engineers whether to fine-tune or use RAG and you will get a debate. Ask what problem you are solving and the debate usually dissolves, because the two are not competitors. They change different parts of the system, they fix different failures, and the most common failure is one that neither fixes best.

What each one actually changes

Fine-tuning changes the model. You continue its training on your own examples until new behavior is baked into its weights: your tone, your format, your judgment calls on a narrow task. The knowledge and habits become part of the model itself, which is exactly its strength and exactly its cost.

RAG changes what happens before the model answers. The model stays stock; the system retrieves the relevant passages from your documents at answer time and answers from what it found, citations included. We walked through the mechanics in how an answer engine works over your documents: the facts live outside the model, looked up fresh per question.

And a third lever, the one without a fan club: change what the model is shown. Before any training run and before any vector database, most answer quality is decided by what makes it into the context window: the right policy passage, this customer’s actual state, your definitions. That lever costs hours, not weeks.

The decision, as a fork

Three ways to teach it your practice

The model does not know your protocols, your note structure, or your patients. Where do you put that knowledge?

Fine-tune the model

Bakes behavior into weights. Needs thousands of examples, and gets re-billed every model generation.

RAG

Facts looked up fresh at answer time, with citations. Infrastructure you keep through every model swap.

Better context first

Fix what the model sees per question. Hours to try, and it usually was the actual problem.

The reason the order matters is failure diagnosis. When an assistant gives a bad answer, the cause is almost always one of three things, in descending frequency: it was not shown the right information (context), the information it retrieved was wrong or stale (retrieval), or it had the right information and still expressed it wrong (the model). Teams that jump straight to fine-tuning are paying for a fix to the rarest failure while the common one goes untouched.

The bill nobody mentions in the debate

Two costs separate these paths more than any benchmark. The first is maintenance shape. RAG and context engineering are infrastructure: when a better model ships, you point them at it and re-run your evals, usually same-day. A fine-tuned model is a snapshot: it is a version of one base model, and when that generation is deprecated or outclassed, the tuning work gets redone on the new one. It is a subscription you pay in engineering time.

The second is coupling. Tuned weights live with one provider, in one format, deepening exactly the kind of vendor lock-in that a thin retrieval layer avoids. That is not a reason to never tune. It is a reason to make tuning the last resort that evals justify, not the first move that enthusiasm does.

Fine-tuning teaches the model. RAG briefs it. Context engineering decides what lands on its desk. Most bad answers are a desk problem.

What to do Monday

Take ten real questions your AI feature gets wrong. For each, look at what the model was actually shown and ask: could a competent human have answered correctly from only this? Where the answer is no, you have a context or retrieval problem, and no training run will save you. Where the answer is yes and the output is still wrong in the same way every time, you have found the rare, legitimate fine-tuning case, and now you have the eval set to prove whether it worked.

---

Still not sure which door your clinic tool needs? Book a free consult and we will run this diagnosis on your actual failing cases together, and scope the cheapest path to answers a clinician can trust.