The request lands the same way in almost every evaluation call: can we train the model on our knowledge base? It is a reasonable ask with a misleading verb. Fine-tuning and RAG are both described as “teaching the model your data,” and they do not do the same thing.
The longer comparison lives at RAG vs fine-tuning. This post is the support-shaped version: what sticks after the pricing page changes, the refund window shrinks, and someone asks for a source.
What each one actually changes
Fine-tuning continues training on examples so the model behaves differently — tighter format, different tone, a specialised classification habit. The weights move. Facts that happen to appear in the training set are not a reliable store; they blur, drift, and cannot point at a URL.
RAG leaves the model alone. At question time it retrieves passages from your current content, puts them in context, and asks for an answer constrained to that material. Publish a page, re-index, and the answer can change the same afternoon. The passages become the citation.
Why support is a retrieval problem
- Policies change faster than training cycles.
- Customers need to verify claims — citations are not optional for refunds and billing.
- Most “wrong” answers come from missing or conflicting docs, not from a model that needs more gradient steps.
- You already have a publishing workflow; retrieval plugs into it.
If your pain is “it doesn’t know our return window,” that is not a fine-tune ticket. It is an index, a crawl, or a page. If your pain is “it sounds like a generic assistant,” start with instructions and persona — fine-tuning is a later tool, not the first.
When fine-tuning is the right tool
Behaviour problems: a rigid output schema for ticket routing, a classification head that must be stable, or a voice that prompt instructions cannot hold under pressure. Those are weight-level habits. They are also rare as the first problem on a marketing-site widget, where the queue is “what’s your shipping cost?” not “emit JSON schema v3.”
You can combine them — fine-tune for behaviour, retrieve for facts — but most teams should earn that complexity. Retrieval alone is enough for grounded support on public content, and it is the only half that produces a checkable source.
A decision test you can run in an afternoon
- Change one factual sentence on a staging page (a fee, a window, an hour).
- Re-index. Ask the question. If the answer cannot update without a training job, you do not have a facts architecture.
- Ask for a citation and open it. If the approach structurally cannot cite, it cannot survive a disputed refund.
- Ask something absent from the corpus. Prefer a clear refusal over a fluent blend of training priors.
| Need | Prefer | Why |
|---|---|---|
| Current policy facts | RAG | Updates with publish + index |
| Clickable source | RAG | Passages map to URLs |
| Stable tone / format | Prompt, then fine-tune | Behaviour, not knowledge |
| Private account actions | Neither alone | Needs systems + a human path |
What not to buy as a substitute
A vendor demo that “learned your site” in a fine-tune sense may still invent on gaps and cannot show its working. A retrieval system with optional refusal is still only as good as the corpus. Neither replaces writing the page — see hallucination is usually a content problem.
Skip competitor price tables; they rot. Compare the test above on every shortlist candidate, including us. The decision that sticks is the one you can re-run after next quarter’s policy edit.
The shortest version
- Fine-tuning shapes behaviour; RAG supplies facts at question time.
- Support tickets are mostly facts — currency and citations decide.
- Use fine-tuning when prompts cannot hold format or voice, not to “load the PDF.”
- Prove the choice with a same-day content edit and a citation check.
