檢索增強生成（RAG）

RAG（Retrieval Augmented Generation）是一種讓大型語言模型能夠利用從未訓練過的最新資料、私有資料或領域專屬資料來回答問題的架構模式。在 AWS Certified AI Practitioner（AIF-C01）考試中，RAG 是測驗比例最高的生成式 AI 架構，因為它同時解決了基礎模型在生產環境中最大的兩項風險——知識凍結在訓練截止時間的問題，以及幻覺（hallucination）風險。RAG 不把新知識燒錄進模型權重（成本高、速度慢、容易失效），而是在查詢時即時檢索相關段落，並將它們注入提示詞，讓模型以可驗證的證據為基礎產生答案。在 AWS 上，RAG 有兩種實作方式：完全託管的 Amazon Bedrock Knowledge Bases，以及自行搭建的客製化管線（使用 Amazon OpenSearch Service、Amazon Aurora PostgreSQL with pgvector、Pinecone 或 Redis 作為向量儲存，搭配 Amazon Bedrock 提供基礎模型）。本學習指南帶領每位 AIF-C01 考生完整走過 RAG 的每個環節——資料攝入、切塊、嵌入、索引、檢索、增強、生成——並清楚點出 RAG、微調（fine-tuning）與混合方案之間的所有考試陷阱。

在典型的 AIF-C01 考試中，預計會遇到三到六題 RAG 相關題目。AIF-C01 考試指南在 Domain 3（基礎模型應用）與 Domain 4（負責任 AI 指引）中都明確點名 RAG，而且只要題目描述「公司有內部文件但模型從未看過」或「在不重新訓練的情況下減少幻覺」，RAG 幾乎都是最常見的正確答案。

什麼是 RAG（Retrieval Augmented Generation）？

RAG 是 Retrieval Augmented Generation 的縮寫。RAG 是一種生成式 AI 設計模式，在語言模型前面插入一個搜尋步驟，讓模型在回答之前能先閱讀具有權威性的原始資料。RAG 模式分兩個階段。在索引階段，原始文件從 Amazon S3（或 Confluence、SharePoint、Salesforce、網路爬蟲等）攝入，切分成切塊（chunk），透過嵌入模型（如 Amazon Titan Text Embeddings 或 Cohere Embed）轉換成向量嵌入，再儲存到向量資料庫（如 Amazon OpenSearch Serverless、Amazon Aurora pgvector、Pinecone 或 Redis）。在查詢階段，使用者的問題以相同的嵌入模型轉換成向量，透過向量相似度搜尋（可選擇混合 BM25 關鍵字搜尋）檢索出 top-k 個最相近的切塊，將這些切塊作為上下文注入提示詞，最後由 Amazon Bedrock 上的基礎模型生成附有來源引用的最終答案。

RAG 不是產品名稱，而是一種架構模式。AWS 提供兩種風格：Amazon Bedrock Knowledge Bases 將每個步驟隱藏在單一 API 後面；客製化 RAG 管線則讓你控制每個細節（切塊大小、檢索器、重排序器、混合搜尋權重、提示詞模板、生成模型）。

為什麼 RAG 在 AIF-C01 考試中如此重要

AIF-C01 考試指南在 Task Statement 3.2（「針對各種使用情境選擇適當的生成式 AI 模型與技術」）和 Task 4.2（「負責任 AI 實踐」——幻覺緩解）中列出 RAG。過去一年，生成式 AI 題目在 AWS 認證考試中增加了 35% 以上。每一份近期的 AIF-C01 題庫至少包含一道類似這樣的情境題：「模型必須使用基礎模型從未見過的內部文件來回答——最符合成本效益的做法是什麼？」預期答案幾乎總是 RAG 搭配 Amazon Bedrock Knowledge Bases，而不是微調、持續預訓練或從頭訓練。

白話文解釋 RAG（Retrieval Augmented Generation）

RAG 聽起來像是學術術語，但用日常語言重新描述後，整個模式就變得非常直觀。以下三個類比能讓你秒懂。

類比一——開書考試

封閉書考試就像使用一個普通的基礎模型。學生在備考期間（訓練）記住了什麼，考場上就只能用什麼。如果昨天才發布一個全新章節，學生對任何相關題目都會一問三不知，因為知識在訓練時就已凍結。更糟的是，一個不想在答案紙上留白的學生可能會自信滿滿地捏造答案——這正是語言模型幻覺的本質。

開書考試就是 RAG。學生帶著一本整理好的活頁夾（向量索引）走進考場。當題目出現時，學生不光靠記憶作答，而是先翻目錄找到與題目相符的兩三頁（top-k 檢索），然後才下筆，引用相關段落（以來源為依據的生成，附上引用）。

這是 AIF-C01 最重要的一個類比。RAG 把封閉書模式轉換成開書模式。基礎模型本身不變，改變的是考試時允許翻閱的活頁夾。

類比二——圖書館參考台

想像一位在圖書館參考台工作的研究員。研究員有豐富的通識知識，但對你公司的內部文件一無所知。

• 資料攝入與切塊是圖書館員把你的活頁夾拿去，一章一章影印並分別歸入資料夾。
• 嵌入是圖書館員把每個資料夾的主題翻譯成巨大地圖上的一個座標，讓主題相近的資料夾聚集在一起。
• 索引就是那張地圖本身——也就是向量資料庫，無論是 Amazon OpenSearch Serverless、Amazon Aurora pgvector、Pinecone 或 Redis。
• 檢索是研究員走向地圖，找到與問題最接近的區域，取出三個最近的資料夾（top-k）。
• 增強是研究員把那幾個資料夾攤開放在基礎模型面前。
• 生成是基礎模型閱讀資料夾後，撰寫出附有頁碼引用的答案。

在這個圖像中，微調是一件截然不同的事——等同於把研究員送回學校，要他把每個資料夾的內容逐字背誦下來。速度慢很多、費用高很多，而且如果明天資料夾的內容改變了，還要再次送去學校。RAG 只需要換一個資料夾放到地圖上就好。

類比三——熱炒店備料（廚房）

主廚（基礎模型）精通各種烹飪技巧。備料間（預訓練語料庫）有常備食材——鹽、麵粉、糖——但沒有松露、和牛，也沒有你們公司的獨門醬料。

• RAG 是二廚在每份訂單開始前跑去冷藏庫（向量儲存）取出這道菜需要的特殊食材，放到出菜口（提示詞上下文）。主廚只用出菜口上的食材烹調。
• 微調是重新訓練主廚的肌肉記憶，讓他反覆練習一千道相同的菜，直到動作成為本能。當你想要的是永久的風格改變時這樣做才有意義，但如果只是需要今天的特殊食材，這樣做就大材小用了。
• 沒有任何依據的普通基礎模型呼叫，就是主廚即興發揮——有時出色，有時憑空捏造不存在的食材（幻覺）。

如果考題說「答案必須引用確切的內部文件」或「公司每週更新定價目錄」，讓二廚去冷藏庫取料（RAG）每次都勝過把主廚送去廚藝學校（微調）。

核心運作原理——RAG 解決的問題與 RAG 架構模式

RAG 解決的兩個問題

基礎模型有兩個結構性限制，AIF-C01 考試非常喜歡測驗。

1. 知識凍結在訓練截止時間。 像 Anthropic Claude、Meta Llama 或 Amazon Titan 這樣的基礎模型，是在訓練截止日期之前的資料上訓練出來的。截止日期之後產生的任何內容，以及從未出現在公開網路上的私有資料，模型都看不到。就算再怎麼精心設計提示詞，也無法讓模型知道你 2026 年第三季的產品藍圖——如果那份藍圖不在它的訓練資料裡。
2. 幻覺風險。 當被問到無法回答的問題時，沒有依據的基礎模型可能產生流暢、自信，但完全捏造的答案。這是 AIF-C01 在負責任 AI 面向中最核心的議題。RAG 透過強迫模型以檢索到的段落為基礎來回答，並讓應用程式把這些段落引用回傳給使用者，從而緩解幻覺。

RAG 用同一個機制解決這兩個問題——在查詢時即時檢索具有權威性的段落，填入提示詞，讓模型在回答前先閱讀。

RAG 七步驟流程

背下這個序列——AIF-C01 的考題可能針對任何一個步驟。

1. 攝入（Ingest） — 從 Amazon S3、Confluence、Microsoft SharePoint、Salesforce、網路爬蟲或資料庫拉取原始文件。Amazon Bedrock Knowledge Bases 將這些都作為第一類資料來源支援。
2. 解析（Parse） — 從 PDF、DOCX、HTML、Markdown、CSV 中萃取文字（以及選擇性的版面配置）。Amazon Bedrock Knowledge Bases 可使用基於 FM 的解析器來處理含表格與圖表的複雜文件。
3. 切塊（Chunk） — 將長文件切分成可檢索的單元（固定大小、語意或階層式——見下一節）。
4. 嵌入（Embed） — 使用嵌入模型（如 Amazon Titan Text Embeddings v2、Cohere Embed，或 Amazon SageMaker 上的開源模型）將每個切塊轉換成密集向量。
5. 索引（Index） — 將向量（與來源元資料）儲存到向量資料庫：Amazon OpenSearch Serverless 向量集合、Amazon Aurora PostgreSQL pgvector、Amazon Neptune Analytics、Pinecone、Redis Enterprise Cloud 或 Amazon DocumentDB。
6. 檢索（Retrieve） — 在查詢時，用相同的嵌入模型將使用者問題嵌入，在向量儲存中搜尋 top-k 個最近鄰（餘弦或歐氏距離），選擇性地結合關鍵字搜尋（混合檢索），並選擇性地進行重排序。
7. 增強 + 生成（Augment + Generate） — 建構一個將檢索到的切塊作為上下文注入的提示詞模板，送至 Amazon Bedrock 上的基礎模型（Claude、Llama、Titan、Nova、Mistral），並回傳附有來源引用的生成答案。

攝入 → 切塊 → 嵌入 → 索引 → 檢索 → 增強 → 生成，這個管線就是 RAG 的標準架構模式。AIF-C01 上每一道 RAG 題都對應到這七個步驟中的某一個。

切塊策略——RAG 中最重要的調校旋鈕

切塊——將長文件切分成可檢索單元的步驟——是影響 RAG 品質最大的單一變數。切塊太小會失去上下文；切塊太大會浪費 token 並稀釋相關性。AIF-C01 不會要求你選擇特定的字元數，但會要求你辨認策略名稱。Amazon Bedrock Knowledge Bases 明確列出四種切塊策略。

固定大小切塊（Fixed-size chunking）

將每份文件切成 N 個 token 的切塊（例如 300 個 token，20 個 token 的重疊）。簡單、快速、結果可預測，是大多數 RAG 入門管線的預設方式。

• 優點：嵌入成本可預測，檢索延遲可預測。
• 缺點：會盲目地從句子和段落中間切斷，損害敘事型文件的檢索品質。
• 在 AWS 上：Amazon Bedrock Knowledge Bases 預設採用固定大小切塊，可設定最大 token 數與重疊量。

語意切塊（Semantic chunking）

透過嵌入模型偵測語意邊界來切分文件——若相鄰兩句的嵌入相似則保留在同一切塊，相似度下降時才切分。產生尊重主題轉換的可變長度切塊。

• 優點：每個切塊是一個完整的概念，提升檢索精確度。
• 缺點：攝入時的嵌入成本較高；索引速度較慢。
• 在 AWS 上：Amazon Bedrock Knowledge Bases 提供語意切塊作為第一類選項。

階層式切塊（Hierarchical chunking）

將文件切分成兩個層級——父切塊（長，高上下文）與子切塊（短，高精確度）。檢索器在子切塊上比對（精確），但將父切塊（更多上下文）回傳給生成器。又稱父子檢索（parent-child retrieval）。

• 優點：結合小切塊的精確度與大切塊的上下文豐富性；對技術手冊和合約特別有效。
• 缺點：需要更多儲存空間，檢索邏輯更複雜。
• 在 AWS 上：Amazon Bedrock Knowledge Bases 原生支援階層式切塊。

自訂切塊 / 不切塊（Custom / no chunking）

自帶切分器，或對已經很短的文件（如 FAQ 條目或 SKU 描述）直接跳過切塊步驟。

• 優點：完全掌控，對已有自然邊界的資料最為理想。
• 缺點：你需要自行維護管線程式碼。

檢索品質評估

RAG 品質 = 檢索品質 + 生成品質。糟糕的檢索意味著再好的基礎模型也只能產生雖有依據但不相關的答案。AIF-C01 要求你辨認核心指標。

檢索指標

• Recall@k — 在所有真正相關的段落中，有多少比例出現在 top-k 檢索結果裡。在不能遺漏任何證據的情境（法律、醫療、合規）中，高召回率至關重要。
• Precision@k — 在 k 個檢索到的段落中，有多少比例是相關的。當生成器的上下文視窗較小、每個 token 都很寶貴時，高精確度至關重要。
• Mean Reciprocal Rank（MRR） — 第一個相關結果排名的倒數之平均值。獎勵將最佳段落排在靠前位置。
• nDCG（normalized Discounted Cumulative Gain） — 以漸進式相關性獎勵排在靠前位置的相關段落。

生成指標

• 忠實度 / 依據性（Faithfulness / groundedness） — 答案中的每一個主張是否都能追溯到某個檢索段落。Amazon Bedrock 模型評估支援以 LLM-as-judge 方式進行依據性評分。
• 答案相關性（Answer relevance） — 答案是否真正回應了使用者的問題，而不是在複述檢索到的瑣碎資訊。
• 上下文相關性（Context relevance） — 檢索到的段落是否真的適合這個問題。

AWS 上的評估工具

• Amazon Bedrock Model Evaluation（Knowledge Base evaluation） — 以內建的依據性、相關性與正確性指標對 RAG 管線執行自動評估。
• Amazon SageMaker Clarify — 可延伸用於 RAG 輸出的公平性與偏見檢查。
• RAGAS（開源） — 廣泛使用的依據性、答案相關性、上下文精確度評估函式庫。

AWS RAG 堆疊選項一——Amazon Bedrock Knowledge Bases

Amazon Bedrock Knowledge Bases 是 AWS 上的完全託管 RAG 服務。只要情境說「以最少的維運開銷建立 RAG 應用程式」，它就是考試的預設答案。

Amazon Bedrock Knowledge Bases 為你處理的事項

• 資料來源連接器 — Amazon S3、網路爬蟲、Confluence、Microsoft SharePoint、Salesforce，以及 Amazon Kendra（可重複使用的索引）。
• 解析 — 純文字，加上針對含表格與圖表的複雜 PDF 的基於 FM 的解析器。
• 切塊 — 固定大小、語意、階層式、不切塊，或自訂 AWS Lambda 轉換器。
• 嵌入 — Amazon Titan Text Embeddings v2、Cohere Embed 多語言版，或 Amazon Bedrock 上其他支援的嵌入模型。
• 向量儲存 — 可選擇 Amazon OpenSearch Serverless（預設，完全託管）、Amazon Aurora PostgreSQL with pgvector、Amazon Neptune Analytics、Pinecone、Redis Enterprise Cloud 或 Amazon DocumentDB。
• 檢索 API — Retrieve 回傳原始段落；RetrieveAndGenerate 回傳附有引用的完整答案。
• Agents 整合 — Amazon Bedrock Agents 可將 Knowledge Bases 作為其中一個工具，用於多步驟推理。

RetrieveAndGenerate 呼叫的解剖

1. 呼叫者傳入一個自然語言查詢。
2. 查詢以攝入時使用的相同嵌入模型嵌入成向量。
3. 從所選向量儲存中檢索 top-k 個向量。
4. 選擇性的重排序器重新排列結果。
5. 檢索到的段落合併進提示詞模板。
6. Amazon Bedrock 上的基礎模型（Claude、Llama、Titan、Nova）生成答案。
7. 回應中同時包含文字與引用陣列（來源 URI、頁碼、片段）。

Amazon Bedrock Knowledge Bases 是正確答案的情境

• 團隊的 ML 或基礎設施能力有限。
• 資料存放在 Amazon S3 或支援的連接器中。
• 團隊希望開箱即用地取得引用。
• 延遲預算是「秒級，而非毫秒級」。
• 「依儲存與查詢量付費」的費用模型可接受。

AWS RAG 堆疊選項二——客製化 RAG 管線

當你需要 Amazon Bedrock Knowledge Bases 無法提供的控制能力——自訂重排序器、特殊切分器、低於 100 毫秒的檢索，或私有嵌入模型——就要自行建構客製化 RAG 管線。建構元件如下：

AWS 上的向量儲存

• Amazon OpenSearch Service（佈建版）搭配 k-NN 外掛 — HNSW 或 IVF 索引用於向量搜尋，單一查詢中即可混合 BM25，完全控制副本與分片數量。
• Amazon OpenSearch Serverless 向量搜尋集合 — 自動擴縮，依 OpenSearch Compute Unit 付費，是 Amazon Bedrock Knowledge Bases 預設使用的後端向量儲存。
• Amazon Aurora PostgreSQL with pgvector — 在關聯式資料庫中進行向量搜尋；當元資料已在 SQL 中時是絕佳選擇。
• Amazon Neptune Analytics — 向量加圖查詢；當實體關係很重要時選用。
• Amazon DocumentDB（搭配向量搜尋） — 在 JSON 文件旁邊進行向量搜尋。
• Amazon MemoryDB for Redis / Amazon ElastiCache for Redis — 毫秒以下的向量檢索，適用於延遲關鍵型使用情境。
• AWS Marketplace 上的 Pinecone — 完全託管的專業向量資料庫。
• Redis Enterprise Cloud on AWS — 適合已在使用 Redis 的團隊。

嵌入模型

• Amazon Titan Text Embeddings v2（Amazon Bedrock 上）— 256 / 512 / 1024 維嵌入，多語言，依 token 付費。
• Cohere Embed（Amazon Bedrock 上）— 強大的多語言嵌入能力。
• 開源嵌入模型（例如 BGE、E5）部署在 Amazon SageMaker 端點上——適合私有部署。

生成模型

Amazon Bedrock 上的任何基礎模型——Anthropic Claude、Meta Llama、Amazon Titan、Amazon Nova、Mistral AI、AI21 Jurassic、Cohere Command。客製化管線也允許使用 Amazon SageMaker 端點上的模型。

客製化管線參考架構

1. Amazon S3 儲存桶存放原始文件。
2. Amazon EventBridge 或 Amazon S3 事件在上傳時觸發 AWS Lambda 攝入器。
3. 攝入器解析、切塊，並呼叫 Amazon Bedrock 上的嵌入模型。
4. 向量寫入 Amazon OpenSearch Service（或 Amazon Aurora pgvector、Pinecone、Redis）。
5. Amazon API Gateway 加 AWS Lambda 服務查詢路徑。
6. Lambda 嵌入查詢、從 OpenSearch 檢索 top-k、選擇性地以 Cohere Rerank 或交叉編碼器模型重排序、建構提示詞，並呼叫 Amazon Bedrock 生成答案。
7. 答案與引用回傳給客戶端。

並排比較——Amazon Bedrock Knowledge Bases vs 客製化 RAG 管線

RAG vs 微調 vs 混合——決策框架

這是 AIF-C01 中僅次於 RAG 模式本身、測驗比例第二高的主題。背下這個決策框架。

RAG 優於微調的情境

符合以下任一條件時選擇 RAG：

• 知識變動頻繁——每週的定價表、每日的庫存、新聞文章。RAG 只需重新索引即可納入新文件；微調需要重新執行一次訓練。
• 答案必須引用原始文件。RAG 原生回傳引用；微調後的模型模糊了來源歸因。
• 領域語料庫規模太大，無法以合理成本全部燒錄進模型權重。
• 可解釋性或合規要求必須展示每個答案是由哪個段落驅動的。
• 緩解幻覺是首要目標。
• 團隊 ML 專業能力有限，無法負擔反覆的訓練週期。

微調優於 RAG 的情境

符合以下任一條件時選擇微調（或持續預訓練）：

• 任務是風格、格式或行為的改變——永遠以 JSON 回答、永遠使用品牌語氣、永遠遵循思維鏈結構。風格最好學進模型權重，而不是每次呼叫都作為上下文注入。
• 模型需要學習一種非常深層的新詞彙或術語，讓檢索上下文無法消除歧義。
• 延遲要求極端苛刻，無法承受額外的檢索來回加上更長的提示詞。
• 隱私或合規規定禁止在提示詞中傳送原始段落片段。
• 現有一個小型、穩定、標注完整的訓練資料集，且不會頻繁更動。

在 AWS 上，微調選項有：Amazon Bedrock 自訂模型（對支援的 FM 進行微調或持續預訓練，如 Amazon Titan、Anthropic Claude Haiku、Meta Llama、Cohere Command）以及 Amazon SageMaker JumpStart 微調。

混合方案勝出的情境

混合方案 = 微調基礎模型，同時搭配 RAG。以下情況使用此方案：

• 你希望模型以特定方式行動（微調後的風格或格式），同時又能從最新的私有資料中回答（RAG）。
• 範例：將客服機器人微調成永遠以特定語氣回答、不確定時永遠升級轉交，同時搭配 Knowledge Base 存取最新的產品手冊。
• 另一個範例：將醫療摘要模型微調以符合臨床病歷結構，並以 RAG 擴充最新的臨床指引。

混合方案是能力最強的模式，但也是成本最高、維運最複雜的。在 AIF-C01 考試中，純 RAG 通常是「最具成本效益」的答案；混合方案出現在情境明確結合「語氣 / 格式」與「最新資料」的題目中。

RAG 的提示詞模板設計

提示詞模板決定了檢索到的段落如何成為模型的輸入。一個生產環境的 RAG 提示詞包含四個區塊。

1. 系統指令 — 「你是一個只根據所提供的上下文來回答問題的助理。如果答案不在上下文中，請說你不知道。」
2. 檢索到的上下文 — k 個切塊，每個都標上 ID 以便引用可以參照。
3. 使用者問題 — 原始查詢，不做修改。
4. 輸出格式要求 — 「以 JSON 格式回傳，欄位為 answer 與 citations[]。」

好的 RAG 提示詞會明確禁止模型在檢索到的上下文沉默時使用自身記憶。這個單一指令是除了檢索本身之外最重要的幻覺緩解手段。Amazon Bedrock Knowledge Bases 透過 generationConfiguration.promptTemplate 欄位開放提示詞模板的調校，讓你無需離開托管服務即可調整。

關鍵數字與必背事實

• Amazon Titan Text Embeddings v2 維度 — 256、512 或 1024（可在呼叫時設定）。
• Amazon Bedrock Knowledge Bases 預設切塊 — 固定大小，約 300 個 token，20 個 token 的重疊。
• Top-k 的典型範圍 — 大多數問答型 RAG 為 3 到 10；摘要任務則更高。
• Amazon OpenSearch Serverless 最低 OCU — 索引 2 個 OCU，使用專屬集合時搜尋 2 個 OCU（即使閒置也持續計費）。
• Amazon Bedrock Knowledge Bases 向量儲存選項 — Amazon OpenSearch Serverless（預設）、Amazon Aurora pgvector、Amazon Neptune Analytics、Pinecone、Redis Enterprise Cloud、Amazon DocumentDB。
• Amazon Bedrock Knowledge Bases 資料來源連接器 — Amazon S3、網路爬蟲、Confluence、SharePoint、Salesforce、Amazon Kendra。
• Amazon Bedrock 資料保留 — 提示詞與回應不會用於訓練基礎模型。
• 引用支援 — Amazon Bedrock Knowledge Bases 的 RetrieveAndGenerate 預設回傳引用。
• 重排序器選項 — Cohere Rerank 在 Amazon Bedrock Knowledge Bases 中原生提供。
• RAG 緩解幻覺 — 但前提是提示詞明確指示模型在上下文中找不到答案時說「我不知道」。

AIF-C01 RAG 常見考試陷阱

• RAG vs 微調 — 知識 vs 行為。「從每週更新的私有文件中回答」→ RAG。「永遠以嚴格格式輸出 JSON」→ 微調。
• Knowledge Bases vs 客製化管線 — 維運開銷。「最少維運開銷，完全託管」→ Amazon Bedrock Knowledge Bases。「特殊重排序器且延遲低於 100 ms」→ Amazon OpenSearch Service 或 Redis 上的客製化管線。
• Amazon Kendra vs Amazon OpenSearch Serverless — 托管企業搜尋 vs 通用向量資料庫。「豐富的企業連接器、開箱即用的相關性」→ Amazon Kendra。「任意 1024 維嵌入加混合搜尋」→ Amazon OpenSearch Service。
• 切塊策略 — 若文件有巢狀章節，選階層式。若是敘事型文件，選語意。若是均質資料（日誌、短 SKU），選固定大小。
• 幻覺修復 — RAG 搭配引用與嚴格提示詞，而非微調。加上 Amazon Bedrock Guardrails 進行內容與主題過濾。
• 私有資料與合規 — Amazon Bedrock 不用你的提示詞或回應來訓練模型；RAG 讓你的資料保存在你自己帳號的向量儲存中。
• 費用模型 — RAG 隨檢索量與 token 用量擴縮計費，微調是一次性的大額訓練成本加上後續的托管費。
• 嵌入一致性 — 攝入與查詢必須使用相同的嵌入模型；更換嵌入模型會讓索引失效。
• Agents vs Knowledge Bases — Amazon Bedrock Agents 編排多步驟行動（呼叫 API、執行程式碼），並可將 Knowledge Base 作為其中一個工具使用。如果問題是「查詢文件並回答」，選 Knowledge Bases。如果是「訂機票並更新 CRM」，選 Agents。

RAG 的邊界——什麼不是 RAG

• RAG 不是聊天機器人框架。 Amazon Lex 或 Amazon Bedrock Agents 處理對話編排；RAG 是一種可以從兩者內部呼叫的檢索技術。
• RAG 不是一個模型。 RAG 是一種為任何基礎模型加上檢索步驟的模式。
• RAG 不是微調。 微調更新模型權重；RAG 保持權重不變，只改變提示詞。
• RAG 不等同於語意搜尋。 語意搜尋檢索段落後就停止；RAG 檢索段落之後，還要請基礎模型合成答案。
• RAG 不消除幻覺。 搭配嚴格的提示詞與引用可以大幅降低幻覺，但鬆散的提示詞模板仍然會讓模型信馬由韁。

練習題情境——AIF-C01 RAG 場景

情境 1：一家銀行想要一個內部助理，用最新版的員工手冊（每月更新）回答員工問題。團隊沒有 ML 工程師。正確選擇：Amazon Bedrock Knowledge Bases，以 Amazon S3 作為資料來源，Amazon OpenSearch Serverless 作為向量儲存。

情境 2：一家律師事務所需要引用合約確切段落的答案。正確做法：RAG 搭配引用，透過 RetrieveAndGenerate 回傳；不要進行微調。

情境 3：一家公司希望模型永遠以品牌語氣說話，並以 JSON 格式回覆。正確做法：使用 Amazon Bedrock 自訂模型對基礎模型進行微調；知識不變，改變的是行為。

情境 4：客服團隊想要品牌語氣，同時答案要依據每週更新的產品手冊。正確做法：混合方案——微調取得語氣，RAG 存取產品手冊。

情境 5：零售聊天機器人需要低於 50 毫秒的檢索延遲，以將 P99 保持在 300 ms 以下。正確選擇：客製化 RAG 管線，使用 Amazon MemoryDB for Redis 向量儲存，搭配 Amazon Bedrock 生成答案。

情境 6：一家新創公司在 Amazon S3 中有 1000 萬個產品 SKU 描述，想要語意搜尋加生成式推薦。正確做法：RAG 搭配 Amazon Bedrock Knowledge Bases；切塊方式 = 不切塊（每個 SKU 本身已是自然邊界）。

情境 7：一個醫療研究工具需要根據最新的臨床指引（每月更新）回答問題，並採用嚴格的格式模板。正確做法：混合方案——RAG 用於指引，微調用於格式模板。

情境 8：工程團隊反映 RAG 的答案流暢，但有時與檢索到的段落相矛盾。正確診斷：提示詞模板問題——加入嚴格指令「只根據所提供的上下文回答；否則說你不知道」，並考慮使用 Amazon Bedrock Guardrails。

情境 9：團隊反映檢索漏掉了明顯相關的段落。正確診斷：切塊或嵌入問題——嘗試語意或階層式切塊，增大 k，或切換為混合（向量加 BM25）檢索。

情境 10：合規長詢問傳送給 Amazon Bedrock 的提示詞是否會用於訓練基礎模型。正確答案：不會——Amazon Bedrock 不使用客戶的提示詞或回應來訓練基礎模型。

FAQ——AIF-C01 上的 RAG（Retrieval Augmented Generation）

1. 什麼是 RAG？為什麼 AIF-C01 考試要考它？

RAG（Retrieval Augmented Generation）是一種從外部知識來源檢索相關段落，並將其注入基礎模型提示詞，讓模型能以它從未訓練過的最新資料、私有資料或領域專屬資訊回答問題的架構模式。AIF-C01 大量測驗 RAG，因為它解決了基礎模型的兩個結構性限制——知識凍結在訓練截止時間，以及幻覺風險——而且 AWS 圍繞它推出了旗艦服務（Amazon Bedrock Knowledge Bases）。每次考試預計有三到六題 RAG 相關題目。

2. 我應該在什麼時候選 RAG 而非微調？

當知識變動頻繁、需要引用、緩解幻覺是主要目標，或團隊缺乏 ML 專業能力時，選 RAG。當任務是在穩定資料集上改變風格、格式或行為，當延遲要求極度苛刻，或當隱私規定禁止在提示詞中傳送原始段落片段時，選微調。當兩者都需要時，選混合方案——微調取得語氣或格式，搭配 RAG 取得最新資料。一行規則：RAG 改變模型知道什麼，微調改變模型如何表現。

3. Amazon Bedrock Knowledge Bases 和客製化 RAG 管線有什麼差別？

Amazon Bedrock Knowledge Bases 是完全託管的 RAG 服務——它透過單一 RetrieveAndGenerate API 處理從 Amazon S3 及其他連接器的攝入、解析、切塊（固定大小、語意、階層式）、以 Amazon Titan 或 Cohere 嵌入、在 Amazon OpenSearch Serverless 或 Aurora pgvector 或 Pinecone 或 Redis 中儲存、檢索，以及生成附引用的答案。客製化 RAG 管線在你需要特殊切分器、自訂重排序器、低於 100 毫秒的延遲，或私有嵌入模型時，以 AWS Lambda、Amazon OpenSearch Service、Amazon SageMaker 端點或開源元件取代這些步驟。免維運的企業問答選 Knowledge Bases；有特殊需求時選客製化管線。

4. RAG 應該選哪種切塊策略？

以固定大小切塊（約 300 個 token，20 個 token 重疊）作為基準。當文件是敘事型（財報電話會議、研究文章）時，切換到語意切塊，讓切塊尊重主題轉換。當文件有巢狀章節（政策手冊、合約）時，切換到階層式切塊，讓檢索器在精確的子切塊上比對，但回傳更豐富的父切塊給生成器。對 FAQ 條目或產品 SKU 等天然短記錄使用不切塊方式。Amazon Bedrock Knowledge Bases 原生支援全部四種策略。

5. RAG 能消除幻覺嗎？

不能——RAG 大幅降低幻覺，但不能完全消除。有兩件事必須到位。第一，檢索器必須確實回傳相關段落（以 recall 和 precision@k 衡量）。第二，提示詞模板必須明確指示模型只根據所提供的上下文作答，並在段落沉默時說「我不知道」。如果沒有嚴格的提示詞，模型仍可能退回到它的預訓練記憶而產生無依據的答案。結合 Amazon Bedrock Guardrails 進行內容過濾與主題限制，以填補剩餘的缺口。

6. RAG 可以使用哪些 AWS 向量儲存？

Amazon Bedrock Knowledge Bases 支援 Amazon OpenSearch Serverless（預設）、Amazon Aurora PostgreSQL with pgvector、Amazon Neptune Analytics、Pinecone、Redis Enterprise Cloud 以及 Amazon DocumentDB。在客製化管線中，還可以加上 Amazon OpenSearch Service（佈建版）搭配 k-NN 外掛、Amazon MemoryDB for Redis 和 Amazon ElastiCache for Redis（毫秒以下的檢索延遲），或在 Amazon EKS 或 Amazon EC2 上執行的任何相容開源向量資料庫。想要托管預設方案選 Amazon OpenSearch Serverless，元資料已在 PostgreSQL 中時選 Aurora pgvector，延遲關鍵時選 Redis。

7. 我可以同時使用微調和 RAG 嗎？

可以——這就是混合方案。使用 Amazon Bedrock 自訂模型或 Amazon SageMaker JumpStart 對基礎模型進行微調，將風格、語氣、格式或領域詞彙燒錄進模型。然後透過 Amazon Bedrock Knowledge Bases 或客製化管線，讓微調後的模型仍能在查詢時提取最新事實。混合方案是能力最強的 RAG 模式，也是成本最高的——在 AIF-C01 考試中，純 RAG 通常是最具成本效益的答案，但結合「品牌語氣」或「嚴格輸出格式」與「資料頻繁更新」的情境通常指向混合方案。

8. 如何評估一個 RAG 系統？

分別評估檢索與生成。對於檢索，以標注測試集量測 recall@k、precision@k、MRR 和 nDCG。對於生成，量測依據性（每個主張都能追溯到某個段落）、答案相關性（答案回應了問題）和上下文相關性（檢索到的段落符合問題）。Amazon Bedrock 模型評估支援以內建指標進行 Knowledge Base 自動評估；開源的 RAGAS 也是另一個常見選擇。如果最終答案有誤，先診斷是檢索漏掉了段落（修正切塊、嵌入或混合搜尋權重），還是模型忽略了它（修正提示詞模板或更換基礎模型）。

延伸閱讀

• Amazon Bedrock Knowledge Bases 使用者指南——AWS 上的完全託管 RAG。https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html
• Amazon Bedrock Knowledge Bases——切塊與解析策略。https://docs.aws.amazon.com/bedrock/latest/userguide/kb-chunking-parsing.html
• Amazon Bedrock 使用者指南——基礎模型。https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html
• Amazon OpenSearch Serverless 向量搜尋集合。https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vector-search.html
• Amazon OpenSearch Service k-NN 外掛。https://docs.aws.amazon.com/opensearch-service/latest/developerguide/knn.html
• Amazon Aurora PostgreSQL pgvector。https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.VectorDB.html
• Amazon Titan Text Embeddings。https://docs.aws.amazon.com/bedrock/latest/userguide/titan-embedding-models.html
• Amazon Bedrock 自訂模型——微調與持續預訓練。https://docs.aws.amazon.com/bedrock/latest/userguide/custom-models.html
• Amazon Bedrock 模型評估。https://docs.aws.amazon.com/bedrock/latest/userguide/model-evaluation.html
• AWS Certified AI Practitioner 考試指南。https://d1.awsstatic.com/training-and-certification/docs-ai-practitioner/AWS-Certified-AI-Practitioner_Exam-Guide.pdf

總結

RAG（Retrieval Augmented Generation）是 AIF-C01 的核心架構模式，透過在查詢時即時檢索相關段落並注入提示詞，讓基礎模型能夠依據最新資料、私有資料或領域專屬資料作答。標準管線是攝入 → 解析 → 切塊 → 嵌入 → 索引，然後是檢索 → 增強 → 生成。切塊選擇（固定大小、語意、階層式、不切塊）是檢索品質最大的調校旋鈕；檢索品質以 recall@k、precision@k、MRR 和 nDCG 衡量，生成品質以依據性和答案相關性衡量。在 AWS 上，Amazon Bedrock Knowledge Bases 是處理每個步驟的完全託管 RAG 服務，支援 Amazon OpenSearch Serverless、Amazon Aurora pgvector、Amazon Neptune Analytics、Pinecone、Redis Enterprise Cloud 和 Amazon DocumentDB 作為向量儲存，並原生回傳引用；針對延遲關鍵型或特殊需求的情境，可在 Amazon OpenSearch Service、AWS Lambda 和 Amazon Bedrock 上建構客製化管線以取得精細控制。RAG vs 微調的規則很簡單——RAG 改變模型知道什麼，微調改變它如何表現，混合方案兩者兼備。掌握這些規則、熟悉 RAG 七步驟流程、記住托管 vs 客製化的取捨，你就準備好應對 AIF-C01 所有 RAG 考題了。