💡 先搞懂問題
虛構的「晴空食品」想在官網放一個客服助理，回答退換貨、配送時間、會員點數這類問題。工程師先直接把顧客的問題丟給 Amazon Bedrock 上的基礎模型（foundation model），結果第一天就出狀況：顧客問「冷凍水餃退冰了可以退貨嗎？」，模型很有自信地回答「網購商品都享有 7 天鑑賞期，可以退貨」，但晴空食品的規定是冷凍商品不適用鑑賞期，要在到貨 24 小時內拍照回報才能換貨。模型沒有說謊的意圖，它只是不知道這家公司的內部規定，就用一般常識補上，這種看似合理卻與事實不符的回答叫幻覺（hallucination）。
直覺的解法有兩個，但都有代價。把整本客服手冊每次都貼進提示（prompt）裡，手冊一長就超過模型的上下文長度，而且每次提問都要付整本手冊的 token 費用；拿手冊去微調（fine-tuning）模型，訓練要花時間與費用，手冊一改又要重新訓練，回答也無法指出根據哪一條規定。比較實際的做法是檢索增強生成（Retrieval-Augmented Generation, RAG）：每次有人提問，先從手冊裡找出最相關的幾段，只把這幾段和問題一起交給模型，請它根據這些內容回答並註明出處。Amazon Bedrock Knowledge Bases 就是把這整條流程做成受管功能的服務。
另一個問題在上線後才浮現：有人在對話框裡要求助理「忽略之前的指示」、有人問股票值不值得買、有人把自己的 Email 與手機號碼貼進來，模型的回答偶爾也會出現手冊裡沒有的內容。這些要在輸入與輸出兩端各加一道檢查，負責的是 Amazon Bedrock Guardrails。
生活比喻：開卷考的考生、圖書館員與監考老師
想像一場開卷考。考生很聰明、文筆流暢，但沒讀過這門課的講義；考場旁邊有一座圖書館，館員事先把每本講義拆成一張張索引卡，依「內容講的是什麼」分類排好。考生拿到題目，先請館員找資料，館員只遞來最相關的三、四張卡片，考生依卡片內容寫答案，並在答案後面註明「出自第幾張卡」。考場裡還有一位監考老師，發考卷前檢查題目有沒有被人塞紙條，收卷時再檢查答案裡有沒有寫到不該寫的東西、有沒有抄錯參考資料。
numberOfResults）；註明出自哪張卡是引用來源（citation）。整座圖書館加上館員，就是 Bedrock Knowledge Bases。監考老師是 Bedrock Guardrails：檢查題目是使用者輸入，檢查答案是模型輸出。
這個比喻有三個地方容易讓人誤解。第一，考生寫完考卷，多少會記得翻過的內容，模型不會：檢索到的段落只存在這一次的提示裡，用完就沒了，模型的權重完全沒變，下一個問題要重新檢索；這也是 RAG 和微調最大的差別。第二，館員遞錯卡片或找不到時，考生還是可能硬寫一個答案，RAG 也一樣：檢索不到正確段落時，模型可能用常識補上，再一次產生幻覺；切塊方式、嵌入模型與 top-k 都會影響館員找得準不準，Guardrails 的情境基礎檢查（contextual grounding check）則能在輸出端抓出「答案沒有根據參考資料」的情況。第三，監考老師也會漏看，換個說法的攻擊或誤判都可能發生，Guardrails 是降低風險的一層，不是保證，對外服務仍要搭配權限控管、監控與人工審查。
🎮 互動實驗室一：RAG 流程模擬器
下面是晴空食品的內部客服手冊（虛構，一份文件、六個段落）。選一個問題或自己輸入，選切塊策略、切塊大小與 top-k，按「執行 RAG」，畫面會依序顯示四個步驟：切塊、檢索、組成提示、回答。再按「不檢索直接問」看沒有 RAG 時會怎樣。注意：這裡的相似度是用「兩個字一組」的字詞重疊算出來的分數，只是示意，不是真的向量嵌入；回答也是預先寫好或從檢索片段擷取的示意，用來呈現「模型手上有哪些片段時會怎麼回答」。切塊大小在這裡以「字」計，實際的 Knowledge Bases 以 token 計。
切塊策略的名稱與行為（固定大小與重疊比例、階層式以子區塊檢索後換成父區塊、語意依句子邊界、不切塊時整份文件一個區塊）依 Amazon Bedrock 使用者指南「Knowledge Bases 的切塊」（查證時間 2026 年 10 月）。實際的相似度由嵌入模型產生的向量計算，同義詞、換句話說也找得到；本頁的字詞重疊做不到這點，所以自己輸入問題時，盡量用手冊裡出現過的詞。
🎮 互動實驗室二：Guardrails 政策模擬
左邊是一組 Guardrail 的六種政策，右邊是晴空食品客服助理收到的 6 則使用者輸入，以及模型產生的 3 則輸出。調整左邊任何一個設定，右邊會立刻重新判斷每一則是「通過」「已遮罩」「被擋」或「僅標記」，並列出是哪一條政策、為什麼。下方四個任務會即時檢查你的設定，試著全部達成。每則內容的偵測結果（信心等級、分數）是本頁預先標註的示意值，不是真的模型判斷。
1. 內容篩選 Content filters・強度：無／低／中／高
2. 拒絕主題 Denied topics
3. 文字過濾 Word filters
4. 敏感資訊過濾 Sensitive information filters
5. 情境基礎檢查 Contextual grounding check
6. 自動推理檢查 Automated Reasoning checks
政策類型與行為依 Amazon Bedrock 使用者指南「Guardrails」各章（查證時間 2026 年 10 月）：內容篩選的強度與信心等級對應、提示攻擊只套用在輸入、敏感資訊可封鎖或遮罩（以 {EMAIL} 這類標記取代）、情境基礎檢查的門檻是 0～0.99 且分數低於門檻就擋、自動推理檢查只回報不擋。封鎖時回覆的訊息由你在 Guardrail 上設定，本頁用固定的示意文字。
🛠️ 操作教學：建立知識庫、同步、測試，再套上 Guardrail
不用登入 AWS，也能先把流程走一遍：替知識庫取名、指定 IAM 服務角色、接上 S3 資料來源、選切塊策略、選嵌入模型與向量存放區（Amazon S3 Vectors 或 OpenSearch Serverless），建立後同步資料，在主控台測試回答，最後建立一個 Guardrail 並套用。左邊是簡化的主控台，右邊同步顯示等效的 AWS CLI、CloudFormation、CLI 用到的 JSON 檔，以及 Python（boto3）呼叫範例，黃色底的那幾行就是目前這一步對應的內容。可以故意填錯名稱、S3 位址或數字，看看驗證訊息；改名稱、區域、切塊策略或向量存放區，右邊會跟著變。
自己動手時要注意
權限分兩層。知識庫的服務角色是 Bedrock 在背景替你做事用的：信任政策只允許 bedrock.amazonaws.com，並用 aws:SourceAccount 與 aws:SourceArn 限定是你帳戶的知識庫；權限只給讀取那個 S3 位置、呼叫那一個嵌入模型、寫入那一個向量索引（OpenSearch Serverless 則是 aoss:APIAccessAll，另外還要在集合上設定資料存取政策）。操作的人或應用程式則需要 bedrock:CreateKnowledgeBase、bedrock:StartIngestionJob、bedrock:Retrieve、bedrock:RetrieveAndGenerate、bedrock:InvokeModel、bedrock:CreateGuardrail、bedrock:ApplyGuardrail 這類動作，以及 iam:PassRole 把服務角色交給 Bedrock。模型要在你使用的區域可用，部分模型要透過推論設定檔（inference profile）呼叫；可用模型、ID 與區域變動很快，以主控台的模型目錄為準。
費用方面，嵌入模型依 token 計費（同步時才會大量呼叫），生成模型依輸入與輸出 token 計費，Guardrails 依檢查的文字量計費，向量存放區另計：S3 Vectors 依實際上傳、儲存與查詢量計費，OpenSearch Serverless 依 OCU 計費，就算沒有查詢也會持續產生費用，練習完一定要刪。2025-07-15 之後建立的帳戶適用 Free Tier 新制，用量從註冊抵用金扣除，實際條件以 AWS Free Tier 頁面為準。練習完依下面的順序刪除（刪除資料來源時，若資料刪除政策是 DELETE，向量也會一起清掉）：
範例裡的帳戶 ID 一律是官方文件慣用的 111122223333，知識庫、資料來源與 Guardrail 的 ID 也都是示意。不要把存取金鑰寫進程式或截圖；Python 範例用的是執行環境既有的憑證（例如 IAM 角色或 IAM Identity Center 登入），不需要、也不應該在程式碼裡放金鑰。上傳到知識庫的文件會被模型拿來回答，含個資或機密的文件要先確認誰能查詢這個知識庫。
📘 原理補完
Knowledge Bases 的兩種型態與組成
Amazon Bedrock Knowledge Bases 現在有兩種建立方式。官方建議的 Managed Knowledge Base（2026-06-17 GA）由 AWS 代管向量存放、資料同步與檢索，內建 S3、SharePoint、Confluence、Google Drive、OneDrive、網頁爬蟲等連接器與文件層級權限，適合不想碰底層的團隊；另一種是搭配向量存放區的知識庫（customer-managed），由你決定切塊策略、嵌入模型與向量存放區，操作教學走的就是這一種。不管哪一種，執行階段的 API 都一樣：Retrieve 只回傳相關片段、分數與中繼資料，RetrieveAndGenerate 則接著呼叫模型、回傳答案與引用來源（citations）。
幾個和它相關的服務現況也要知道（查證時間 2026 年 10 月）：舊的 Amazon Bedrock Agents 已改稱 Agents Classic，2026-07-30 起不收新客戶，要讓 AI 代理查知識庫、呼叫工具，新設計改用 Amazon Bedrock AgentCore；企業搜尋服務 Amazon Kendra 已進入 maintenance，官方建議改用 Bedrock Managed Knowledge Base。考試大綱仍可能出現 Kendra，照考點理解即可，但不要當成新案的推薦選項。
向量存放區怎麼選
向量存放區負責「依語意相似度找最接近的向量」。選擇的取捨在延遲、查詢量、成本與既有技術棧。下表依本站節點與 Amazon Bedrock 使用者指南整理（查證時間 2026 年 10 月，數字會變動）：
| 選項 | 特色 | 適合 | 要注意 |
|---|---|---|---|
| Managed Knowledge Base | AWS 代管向量存放、同步與檢索，內建多種連接器與文件層級權限 | 想最快上線、不想管底層 | 可調整的細節較少 |
| Amazon S3 Vectors | 2025-12-02 GA；免叢集、依用量付費；每個索引最多 20 億個向量，頻繁查詢約 100 毫秒、不常查詢 1 秒內 | 向量量大、查詢頻率中低、重視成本 | 只支援浮點數嵌入；官方不建議搭配階層式切塊 |
| OpenSearch Serverless | 向量搜尋集合，支援關鍵字＋向量的混合搜尋，延遲低 | 查詢量高、要毫秒級回應或混合搜尋 | 依 OCU 計費，沒有查詢也有費用；要設加密、網路與資料存取政策 |
| Aurora PostgreSQL（pgvector） | 在關聯式資料庫裡存向量 | 已經在用 PostgreSQL、資料量中等 | 要自己管資料庫容量與索引 |
| Neptune Analytics | 圖形資料庫，支援 GraphRAG | 文件之間的關聯（人、產品、事件）很重要 | 建模較複雜 |
| 其他既有存放區 | OpenSearch 受管叢集、Pinecone、Redis Enterprise Cloud、MongoDB Atlas | 組織已經在用這些服務 | 帳號與憑證要放 Secrets Manager |
切塊策略：太碎、太大都有代價
切塊決定了「一張索引卡寫多少內容」。太小的區塊，比對很精準，但常把一句話切斷，或丟掉「這段在講哪一條規定」的上下文；太大的區塊，上下文完整，但同一塊裡混了好幾件事，相似度被稀釋，塞進提示也更貴。Knowledge Bases 提供五種做法，資料來源建立後就不能改：
| 策略 | 怎麼切 | 主要參數 | 適合 |
|---|---|---|---|
| 預設 | 約 300 tokens 一塊，盡量保留完整句子 | 無 | 先求有，一般文件 |
| 固定大小 FIXED_SIZE | 依 token 數切，相鄰區塊可重疊 | maxTokens（1～8,192）、overlapPercentage（1～99） | 格式一致、想精確控制大小 |
| 階層式 HIERARCHICAL | 先切大的父區塊，再切小的子區塊；用子區塊比對，取回時換成父區塊 | 父、子各自的 maxTokens，overlapTokens | 長篇手冊、法規，需要完整上下文 |
| 語意 SEMANTIC | 依句子之間的意思變化切，一塊盡量講一件事 | maxTokens、bufferSize（0～1）、breakpointPercentileThreshold（50～99） | 段落主題常跳動的文件；會呼叫基礎模型，有額外費用 |
| 不切塊 NONE | 每份文件就是一塊 | 無 | 已經事先切好的短文件 |
嵌入與相似度：向量在比的是「意思接不接近」
嵌入模型把一段文字轉成一串數字（例如 1,024 維的向量），意思相近的文字，向量在空間裡的方向也相近；檢索時把問題也轉成向量，用餘弦相似度（cosine）或歐氏距離找最近的幾個。這和實驗室一的字詞重疊不同：「退冰的水餃能退嗎」和「冷凍商品退換貨」幾乎沒有共同字詞，向量卻可能很接近。反過來，型號、訂單編號這種精確字串，向量搜尋不一定比關鍵字準，所以 OpenSearch 這類支援混合搜尋（hybrid search）的存放區常被用在有大量代碼的文件。實務上還有兩條限制：向量索引的維度必須和嵌入模型一致；換嵌入模型等於換了一套座標，整個索引要重建、資料要重新同步。
Guardrails 的六種政策
一個 Guardrail 是一組可重複使用的政策，同時檢查使用者輸入與模型輸出；同一個 Guardrail 可以套用到多個模型，也可以透過 ApplyGuardrail API 單獨檢查任何文字，連 Bedrock 以外的模型輸出都能拿來檢查。建立後是草稿（DRAFT），發布版本後再讓應用程式指定版本使用，修改政策不會影響已經在用的版本。官方列出的六種政策如下（查證時間 2026 年 10 月）：
| 政策 | 擋什麼 | 動作 | 套用在 | 要注意 |
|---|---|---|---|---|
| 內容篩選 | 仇恨、侮辱、性、暴力、不當行為，以及提示攻擊（越獄、提示注入） | 依強度（無／低／中／高）封鎖 | 輸入與輸出；提示攻擊只看輸入 | 中文內容需要 Standard 層級 |
| 拒絕主題 | 你定義的主題，例如投資建議 | 封鎖 | 輸入與輸出 | 用自然語言定義主題，可附範例句 |
| 文字過濾 | 自訂字詞與受管的不雅字詞清單 | 封鎖 | 輸入與輸出 | 完全比對字詞，換個說法就抓不到 |
| 敏感資訊過濾 | 內建 PII 類型（Email、電話、姓名……）與自訂正規表示式 | 封鎖、遮罩（如 {EMAIL}），或只偵測 | 輸入與輸出 | 內建類型沒有台灣身分證字號這類在地格式，要用正規表示式 |
| 情境基礎檢查 | 回答不符合參考來源（基礎），或沒回答到問題（相關性） | 分數低於門檻（0～0.99）就封鎖 | 模型輸出 | 需要參考來源與問題；適合摘要、問答、RAG |
| 自動推理檢查 | 回答和你從文件萃取出的邏輯規則矛盾 | 只回報（VALID、INVALID 等），不封鎖 | 模型輸出 | 目前只支援英文與部分區域，不防提示注入 |
RAG、提示工程與微調怎麼選
三者解決的問題不同，成本與複雜度也依序增加。提示工程（prompt engineering）改變的是指示與範例，適合調整語氣、格式與步驟；RAG 改變的是模型這一次手上的資料，適合「要依最新或私有資料回答、要附出處」；微調或持續預訓練改變的是模型權重，適合學會特定格式、專業用語或風格，資料更新時要重新訓練，也不會自動附出處。常見的順序是先試提示工程，不夠再加 RAG，最後才考慮微調；兩者也可以並用，例如微調讓模型熟悉業界用語，再用 RAG 提供最新規定。
遇到題目時的判斷步驟
- 模型不知道公司內部或最新資料、要附出處？選 RAG，也就是 Bedrock Knowledge Bases，不是微調。
- 不想管向量存放區與同步細節？選 Managed Knowledge Base；要自己控制切塊、嵌入與向量存放區，選搭配向量存放區的知識庫。
- 向量量大、查詢不頻繁、重視成本？向量存放區選 S3 Vectors；要低延遲、高查詢量或混合搜尋選 OpenSearch Serverless；已經在用 PostgreSQL 可選 Aurora pgvector；重視實體關聯選 Neptune Analytics（GraphRAG）。
- 只要片段、自己組提示？呼叫 Retrieve；要直接拿到答案與引用？呼叫 RetrieveAndGenerate。文件更新了？重新同步資料來源。
- 要擋有害內容、提示攻擊、特定主題、個資，或抓出沒有根據的回答？選 Guardrails 對應的政策；要讓 AI 多步驟呼叫工具完成任務，則是 AgentCore 的範圍。
容易考錯的地方
要讓模型知道公司資料就去微調：題目強調「資料常更新」「要附來源」「不想重新訓練」時，答案是 RAG。微調改的是權重，適合學格式與語氣。
RAG 會讓模型記住公司資料：不會。檢索到的片段只存在那一次的提示裡，模型權重不變；提示與回應也不會被拿去訓練基礎模型。
文件更新後自動生效：搭配向量存放區的知識庫要重新同步（StartIngestionJob），向量存放區裡的區塊才會換成新版。
top-k 越大越好：取回越多片段，提示越長、越貴，也可能把不相關的內容塞進去干擾回答；太小則可能漏掉關鍵段落。要搭配切塊大小一起調。
嵌入模型和生成模型是同一個：不是。嵌入模型（例如 Titan Text Embeddings V2）只把文字轉成向量，生成模型（例如 Amazon Nova）才產生回答；換嵌入模型要重建索引。
Guardrails 和 AWS WAF 擇一即可：WAF 擋的是 HTTP 層的攻擊與惡意來源，Guardrails 擋的是語意層的有害內容、提示攻擊與個資，兩者常一起用。
情境基礎檢查擋的是有害內容：它檢查的是回答「有沒有根據參考來源」「有沒有回答到問題」，是降低 RAG 幻覺的工具；有害內容要靠內容篩選。
自動推理檢查會把錯誤回答擋下來：它只回報 VALID、INVALID 等結果，不封鎖內容，要由應用程式決定怎麼處理；而且目前只支援英文與部分區域。
相關考試：Knowledge Bases 與 RAG 列在 AIF-C01、AIP-C01（RAG 與向量存放區也見於 MLA-C01、DEA-C01）；Guardrails 列在 AIF-C01、MLA-C01、AIP-C01（依 AWS 官方考試指南與本站節點，查證時間 2026 年 10 月）。AIF-C01 著重 RAG、微調、提示工程的選擇與負責任 AI；AIP-C01 會深入切塊、向量存放區、檢索品質與 Guardrails 設定。
✅ 自我檢測
6 題原創題，選完立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6