A chatbot fine-tuned on internal documents answers questions about rates, policies, or product terms with confident, fluent, out-of-date facts. The answers were correct on launch day. A month later customers are quoted last quarter's numbers, and every content update triggers a request for "another training run" that takes days and GPU budget nobody planned.
A team decided the bot must "know our documents" and reached for fine-tuning because it sounded like the serious, professional option. Weeks went into dataset building and training runs. The failure surfaces on the first document update: rate circulars, policy PDFs, price lists — anything that changes on a schedule. Common wherever fine-tuning is chosen for status rather than by a decision table. Linked module: 3.10 (Fine-tuning + decision framework).
The failure type was misread. Questions like "what is this week's gold-loan rate" fail on missing or fresh FACTS, and facts baked into weights go stale the moment the source changes — the model cannot know it is out of date, so it answers with stale confidence. Fine-tuning changes behaviour (format, tone, discipline); it is a poor and expensive way to store knowledge. The confirming test takes one minute: ask whether the answer to this question changes over time without the model changing. If yes, the knowledge belongs outside the weights, where retrieval can fetch the current version. The 3.10 decision table asks exactly this before any GPU hour is spent.
Stop the training cycle. Put the documents behind the RAG pipeline from module 3.5: chunk, embed, retrieve, and answer with citations from the retrieved text. A content update now means saving a file and re-indexing — minutes, not days, and no GPU. Keep the eval set the team built; rerun it against the RAG version so the switch is justified with numbers, not opinion. If a genuine behaviour problem remains after the switch (the bot breaks the required answer format), that residue — and only that residue — is a fine-tuning candidate.
Run every "we should fine-tune" request through the decision table first, in writing: fresh facts → RAG; one-off task → prompt; format, tone, or behaviour that survives good prompting → fine-tune, and only with an eval showing the best prompt plateaued. Ask the staleness question in every design review: "what happens when this document changes?" Budget rule: no training run is approved without a written answer to why RAG and prompting were rejected.
Q: "Your product manager wants to fine-tune a model on the company wiki so the assistant knows everything. How do you respond?" Strong answer: name the knowledge-vs-behaviour split, explain that weights go stale while retrieval stays current, propose RAG for the wiki with fine-tuning reserved for persistent format or tone failures, and describe the eval evidence you would demand before any training run. Bonus: mention that the strongest production pattern combines both — behaviour in the weights, facts in the retriever.