What's changed: In-scope coverage: added an AI/ML support in-scope services block to Ch3 §3 (Amazon SageMaker AI/Amazon Personalize/Amazon Augmented AI = A2I)
3.2RAG and Fine-tuning
Understand two main ways to adapt a foundation model to your needs—RAG (retrieval-augmented generation) and fine-tuning—and when to use each.
To adapt a general foundation model to your knowledge/needs, the two main approaches are RAG and fine-tuning. Choose by purpose.
3.2.1Two approaches
- RAG: at query time, retrieve your data and add relevant context to the prompt; the model itself is unchanged. Good for fresh/private facts and reducing hallucination via citations.
- Fine-tuning: further-train the model on your labeled data to internalize behavior/style/domain knowledge; higher effort, cost, and data-prep burden.
The essential difference is where the knowledge lives. RAG keeps knowledge outside the model (retrieved documents), consulted on each answer—so updating documents instantly reflects fresh info, and you can cite sources. Fine-tuning bakes knowledge/behavior into the model (weights)—good for deep adaptation to a style, format, or specialized task, but new facts require retraining and cost. For AIF-C01: "fresh facts/citations matter → RAG; deep behavioral adaptation → fine-tuning," and the order "try RAG first; fine-tune if it falls short." They can also be combined.
| Aspect | RAG | Fine-tuning |
|---|---|---|
| Where knowledge lives | Outside (retrieved docs) | Inside (weights) |
| The model itself | Unchanged | Changed by training |
| Fresh info | Reflected by updating docs | Requires retraining |
| Best for | Fresh/internal facts, citations | Style/format/domain adaptation |
| Effort/cost | Relatively low | High |
Scenario: an internal help desk. Since policies/manuals change often, ground answers with RAG over the latest documents (with citations, reducing hallucination). To always match a company format and polite tone, fine-tune to internalize that style. Practically: run with RAG first, and add fine-tuning if style consistency becomes the issue.
Watch the mix-ups: (1) RAG leaves the model unchanged (consult external knowledge) / fine-tuning changes it (bake into weights). (2) "Reflect fresh info" favors RAG (fine-tuning needs retraining). (3) For both, responsibility for data bias and output correctness stays with the customer. (4) RAG differs from prompt engineering (previous section).
Q. Can RAG and fine-tuning combine? Yes—fine-tune for style, RAG for fresh facts. Q. Which reduces hallucination? Mainly RAG (provides grounding documents and citations). Q. How to do RAG on AWS? Use Amazon Bedrock Knowledge Bases, etc. (previous chapter).
Common: reference fresh/internal facts = RAG (model unchanged, external knowledge) vs change behavior/style = fine-tuning (further training, baked into weights). RAG also reduces hallucination. Order: "RAG first, fine-tune if needed."
3.2.2Section summary
- RAG = knowledge outside the model, consulted via retrieval (model unchanged; strong on fresh info/citations)
- Fine-tuning = bake knowledge/behavior into the weights (deep adaptation, more effort)
- Order: "RAG first, fine-tune if needed"; can be combined
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which fits referencing fresh internal docs to improve accuracy without changing the model itself?
Q2. Which fits further-training the model on your labeled data to change its behavior/style?
Q3. Which is an appropriate benefit of RAG?