AI-103 Practice Question 26: Fine Tuning Versus RAG

The two problems need two different tools. Volatile, private knowledge belongs in retrieval, which sees an amendment the moment it is indexed. Consistent style, tone, register and output format are what fine-tuning is for: Microsoft lists "modifying style and tone" and "generating outputs in specific formats or schemas" among the canonical fine-tuning use cases, and calls out "reducing prompt engineering overhead" (few-shot examples that grow until they drive up token counts and latency) as the classic trigger. Baking the examples into the weights removes them from every request.

- A is wrong because it fine-tunes on the wrong half. Training on the precedent library freezes clause text into weights that go stale at the next amendment, while the expensive few-shot block stays in the prompt. - B is wrong for the same reason, made worse: Microsoft explicitly warns that fine-tuning "may need to be repeated whenever the data is updated," and a weekly retrain-and-redeploy cycle to chase a document set is the cost that retrieval exists to avoid. - D is wrong because a bigger context window makes the per-request cost worse, not better, and stuffing an entire amended library into every prompt neither guarantees the right clause is attended to nor fixes the format drift.

Reference: Microsoft Foundry fine-tuning considerations