Day 04 留下了一個很明確的問題：大型語言模型（Large Language Model, LLM）可以把文字整理得很流暢，卻不能保證規則、數值、版本與引用一定正確。

檢索增強生成（Retrieval-Augmented Generation, RAG）就是為了解決其中一部分問題而加入的系統設計。它不要求 LLM 只靠訓練時記住的內容回答，而是先從指定的外部知識庫找出相關資料，再把問題與資料一起交給模型整理。

最白話的差別是：

直接問模型，是請它根據輸入與內部記憶回答；RAG 則是在回答前，多做一次「去哪裡找、找到了什麼、能不能用這些資料支持回答」的流程。

假設我們輸入一段呼吸困難的教學案例。只靠 LLM 時，模型可能根據過去學到的常見模式作答；使用 RAG 時，系統會先到指定制度與版本的規則庫搜尋相關段落，再要求模型根據取回內容整理候選依據。

這不代表加入 RAG 後，回答就一定正確。系統仍可能找錯文件、漏掉關鍵規則，或在拿到正確證據後曲解內容。RAG 改變的是「模型回答時可以使用哪些外部資料」，不是替整個系統發出正確保證。

下圖用概念方式呈現「先找再答」。左側送出查詢，中間的知識庫挑出帶有來源線索的證據卡，右側模型整理查詢與證據，最後仍由人員檢視回答和來源。

上圖用概念方式呈現 RAG 的責任分工：系統先尋找外部證據，再由模型整理回答，最後仍保留人員覆核。這不是正式的臨床操作介面。

讀完這篇，你會知道什麼？

讀完 Day 05 後，你應該能夠：

1. 用自己的話說明 RAG 比直接詢問 LLM 多了哪些步驟。
2. 分辨文件切塊、向量、索引與前 k 筆檢索的角色。
3. 解釋離線索引與線上回答為什麼是兩個不同階段。
4. 分辨檢索失敗與生成失敗。
5. 說明為什麼每個規則片段都要保存制度、版本、來源與規則識別碼。
6. 解釋為什麼 RAG 可以改善可追溯性，卻不會自動保證醫療答案正確。

這篇會用到的名詞

這篇會建立後續多種 RAG 架構共用的詞彙。先看快速索引，再到正文逐步理解每一個步驟。

RAG 不是把整個資料庫塞進提示詞

知識庫（Knowledge Base）是系統被允許搜尋的外部資料集合。在本系列中，它預計保存的是可合法使用的急診檢傷規則、章節、來源網址與版本資訊，而不是未經篩選的整個網路。

RAG 也不是把所有文件一次複製進模型的提示詞。這樣做會遇到三個問題：

• 文件可能長到超過模型一次能閱讀的範圍。
• 大量不相關內容會干擾真正需要的規則。
• 文件更新後，很難知道本次回答實際用了哪個版本。

因此，RAG 會先把文件整理成可以搜尋的索引。收到問題時，系統只取回一小組相關候選，再把這些候選交給模型。

Lewis 等人在 2020 年提出的 RAG 架構，將生成模型的參數內記憶與可另外查詢的外部文件索引結合。原始設計使用維基百科的密集向量索引作為外部記憶，也把知識更新與答案來源追查列為重要問題。Lewis 等人：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

參數內記憶可以理解成模型在訓練後保留於參數中的模式；外部記憶則是模型回答時另外查到的文件。RAG 的價值之一，是不用等待模型重新訓練，就能更換外部文件並重新建立索引。

但請注意：更換原始文件不等於索引已自動更新。 文件解析、切塊與向量化流程仍要重新執行，並記錄新索引的版本。

一個基本系統，其實有兩段流程

很多 RAG 介紹只畫出「問題 → 搜尋 → 模型 → 回答」，容易讓初學者以為文件在每次提問時才臨時整理。

實際上，一個基本系統可以拆成：

• 離線索引階段：事先把來源文件整理成可搜尋資料。
• 線上回答階段：收到問題後，使用既有索引檢索並生成回答。

這裡的離線（Offline）不是指電腦沒有連網，而是指工作不需要等到使用者提問才開始；線上（Online）則表示每次收到查詢時即時執行。

下圖請先沿上半部由左到右閱讀，再看下半部。紫色箭頭表示線上檢索會讀取離線階段已建立的索引。

上圖的重點不是背下十一個方框，而是理解上下兩段的輸出關係：離線階段最後產生「可搜尋索引」，這個索引才是線上階段執行檢索時的輸入。

離線階段：先把規則文件變成可搜尋索引

離線流程可以分成五個步驟。

準備來源文件

第一步先決定哪些文件可以進入知識庫。每份文件至少需要知道：

• 來自哪一套制度。
• 是哪一個版本。
• 原始發布單位與網址。
• 發布或生效日期。
• 是否允許在本專案中使用與重新散布。

這一步先控制來源範圍，避免系統把不同制度、不同版本或未確認內容混在一起。

解析並保留文件結構

解析（Parsing）是從原始檔案讀出文字、標題、表格、頁碼與章節關係的過程。

如果只把所有文字連成一大段，表格欄位可能失去對應，標題也可能和內容分離。對規則文件而言，「這段文字屬於哪個章節」通常和文字本身同樣重要，因此解析結果不能只有純文字。

把長文件切成片段

文件切塊（Document Chunking）是把長文件分成較小、可獨立搜尋的片段；每個片段稱為區塊（Chunk）。

切塊不能只追求越短越好：

• 太長時，一個區塊可能同時混入多個不同條件，檢索結果不夠精確。
• 太短時，門檻與適用條件可能被切開，模型只看到一半規則。
• 跨頁表格如果切錯，列名、欄名與數值可能失去關係。

因此，後續 Day 17 會專門比較切塊方式。Day 05 只先建立原則：一個區塊應該保留足以理解該段規則的最小完整範圍。

把文字轉成向量

向量嵌入（Vector Embedding）是把文字轉成一串數值的表示方法，產生的數值串稱為向量（Vector）。這些數值構成向量空間（Vector Space），也就是用多個數值維度表示每段文字的位置。語意相近的文字，經過合適的向量模型處理後，通常會在這個空間中比較接近。

向量模型（Embedding Model）是執行這項轉換的模型。文件區塊與使用者問題必須使用相容的向量模型與版本，否則兩邊的數值不在同一套表示空間，無法合理比較。

Reimers 與 Gurevych 的句子向量研究示範了如何產生可用相似度比較的句子表示；密集段落檢索（Dense Passage Retrieval, DPR）的研究則示範以問題與文件的密集向量挑選候選段落。句子向量原始研究、DPR 原始研究

這裡的「密集」表示向量通常有許多非零數值，並利用整體語意表示進行比較。它和只比對特定字詞是否出現的方法不同，但不代表密集檢索一定勝過所有方法。Day 19 會再比較語意向量、關鍵字與兩者混合的檢索方式。

建立向量索引

向量索引（Vector Index）是保存向量並支援快速相似度搜尋的資料結構。

索引中的每筆資料不能只存向量。至少還要一起保存：

• 區塊原文。
• 區塊識別碼。
• 制度與版本。
• 原始文件網址。
• 章節或頁碼。
• 規則識別碼。

向量負責「找到候選」，原文與中繼資料則負責「讓人知道候選是什麼、來自哪裡」。

線上階段：收到問題後才開始檢索與生成

線上流程可以分成六個步驟。

保留原始問題與輸入欄位

系統先保存使用者原始查詢，以及經過驗證的結構化欄位。原始文字不能在沒有紀錄的情況下被改寫，否則日後無法確認檢索究竟使用了哪個問題。

產生查詢向量

系統使用與文件相容的向量模型，把問題轉成查詢向量（Query Vector）。文件向量是事先產生，查詢向量則是每次收到問題時產生。

搜尋前 k 筆候選

相似度搜尋（Similarity Search）是比較查詢向量與文件向量，找出最接近候選的過程。實作可以使用餘弦相似度（Cosine Similarity）或其他距離方法；餘弦相似度比較兩個向量方向有多接近。

前 k 筆（Top-k）表示依檢索分數取出前 k 個候選。k 是想取回的數量：如果 k = 3，系統就先選三個分數最高的片段。

下圖把高維向量壓成二維平面，只為了幫助理解。真實向量通常有更多維度，下圖中的位置也不是任何模型實際算出的距離。

上圖中的 R7 刻意設計成「文字相似但版本不同」。這表示檢索分數只能產生候選，仍要用中繼資料（Metadata）檢查制度、版本、對象與生效日期。

多取幾筆也不是無條件更好。k 太小可能漏掉必要證據；k 太大則可能塞入重複、過時或互相衝突的內容。模型一次能接收的輸入量稱為脈絡視窗（Context Window），候選太多還會占用有限空間。

組裝輸入脈絡

輸入脈絡（Context）是本次請求中連同問題一起交給 LLM 閱讀的內容。基本脈絡至少要分開放置：

1. 系統角色與安全限制。
2. 經過驗證的使用者輸入。
3. 取回的規則原文。
4. 每段規則的來源與版本。
5. 需要模型輸出的固定欄位。
6. 證據不足時的拒答方式。

這個步驟不能把模型補寫的內容混進「病患原始資料」，也不能移除證據的識別資訊。

讓模型依脈絡產生回答

提示詞（Prompt）是交給模型的工作指令。這裡的提示詞不是只寫「請根據資料回答」，而要清楚要求模型：

• 只使用提供的病患資料與證據。
• 把已知、未知與推論分開。
• 每個主要理由都要指出證據片段。
• 證據衝突或不足時停止判斷。
• 依固定欄位輸出，方便程式再次驗證。

結構化輸出（Structured Output）是按照預先定義欄位產生的結果，例如候選判斷、理由、使用的證據識別碼、缺失欄位與拒答原因。它比一整段自由文字更容易檢查，但欄位完整仍不等於內容一定正確。

附上來源，證據不足就拒答

證據錨定（Grounding）是讓回答受到外部證據限制，並能連回來源的做法。

系統輸出不應只顯示「使用了規則」。它還要讓讀者知道是哪一個片段、哪份文件、哪個版本，以及該段內容如何支持回答。若找不到足夠證據，正確輸出應該是回報缺少什麼，而不是要求模型用記憶補完。

找到正確資料，還不代表最後會說對

RAG 至少有兩個需要分開測試的部分：

• 檢索是否成功：候選中有沒有足以支持回答的正確證據。
• 生成是否成功：模型有沒有忠實使用證據，並正確回應問題。

如果只檢查最終答案，會漏掉一種很危險的情況：系統沒有找到支持答案的證據，模型卻靠參數內記憶或碰巧答對。這次輸出看似正確，下次遇到版本變更或少見案例時卻可能失效。

下圖把檢索和生成各分成成功與失敗，形成四種組合。

上圖是一張概念矩陣，用來分開檢查「有沒有找到證據」與「有沒有根據證據回答」。下面依序解讀四種組合。

找對，也說對

候選證據足以支持答案，模型回答也與證據一致。這是我們希望得到的可追溯成功，因為來源和版本都能回查。

找錯，卻表面答對

候選中沒有支持答案的證據，模型卻給出看似正確的答案。它可能依賴內部記憶、使用證據以外的知識，或只是碰巧命中。

這一格不能被標成「檢索成功」，也不能用來證明回答已經完成證據錨定。

找對，卻說錯

檢索已取得正確證據，模型卻忽略條件、曲解內容、混淆否定語氣，或加入證據沒有提供的資訊。這是生成層需要修正，不應先怪罪向量索引。

找錯，也說錯

檢索沒有找到必要證據，生成結果也不正確。這是端到端失敗，但仍要先看取回片段，才能判斷應該修正資料、切塊、向量模型、檢索設定或生成提示詞。

2024 年的可信任檢索增強問答研究也明確指出，RAG 是降低虛構內容風險的有希望方法，但一般 RAG 本身不提供回答一定正確的保證。Li 等人：TRAQ—Trustworthy Retrieval Augmented Question Answering

因此，找到正確證據是產生可追溯正確回答的必要條件之一，但不是充分條件。 找到之後，還要驗證模型是否真的依照證據回答。

醫療規則片段要保存哪些來源資訊？

中繼資料（Metadata）是用來描述文件區塊的附加欄位。它不一定會全部顯示在回答中，卻是過濾、追查與重建索引的重要基礎。

本系列預計為每個規則區塊保存下列欄位：

規則識別碼不一定是原始文件已提供的編碼。如果是本專案自行建立，就必須明確標示為內部識別碼，不能偽裝成官方條文編號。

怎麼知道每一層真的做對？

驗證 RAG 時，不要只準備一份「問題與答案」清單。至少要分成三層測試。

先測檢索

為每個測試問題標記預期應出現的來源區塊，再檢查前 k 筆候選有沒有包含它。成功時應看到正確制度、正確版本與可支持回答的段落。

如果沒找到，就先檢查文件是否進入索引、切塊是否破壞語意、向量模型是否一致，以及版本過濾是否誤刪。

再測生成

固定提供一組已確認的正確證據，單獨測試模型能否忠實整理。這樣可以把生成錯誤和檢索錯誤分開。

成功時，回答中的主要理由應能對應證據，未知欄位不應被補完，證據不足時也應按照設計拒答。

最後測端到端

端到端（End-to-End）測試是從原始問題開始，完整執行檢索、脈絡組裝、生成與引用檢查。它最接近使用流程，卻不能取代前兩層測試，因為只看最後答案很難定位錯誤來源。

每次測試至少要保存：資料版本、索引版本、向量模型、取回片段、檢索分數、提示詞版本、生成模型與最終輸出。

RAG 仍然不能替我們完成哪些事？

RAG 能把外部資料帶進回答流程，但仍不能自動完成下列工作：

• 不能判斷知識庫中的來源本身是否正確或合法。
• 不能保證切塊後仍保留所有例外與表格關係。
• 不能保證向量最接近的片段就是適用規則。
• 不能保證 LLM 一定忠實使用取回證據。
• 不能自動修正缺失病患資料或單位錯誤。
• 不能取代 Day 04 的確定性數值規則與拒答設計。
• 不能取代臨床人員依現場完整資訊做出的專業判斷。

微調（Fine-Tuning）是使用特定資料繼續訓練模型、調整模型參數的方法；RAG 則是在回答時取得外部資料。兩者可以搭配，但不是同一件事。把新文件放進知識庫不會自動改變模型參數，微調模型也不會自動建立可追溯的文件索引。

在醫療情境中，本系列仍把輸出定位為臨床決策支援（Clinical Decision Support, CDS）候選。美國食品藥物管理局（U.S. Food and Drug Administration, FDA）的臨床決策支援軟體指引強調，醫療專業人員應能獨立檢視建議基礎，而不是主要依賴系統。FDA：Clinical Decision Support Software Guidance

這項美國指引在本文只作為「讓使用者看得見建議基礎」的設計參考，不用來判定台灣產品的法規分類。

幾個容易誤解的地方

「RAG 就是資料庫加聊天機器人」

中間還有來源管理、文件解析、切塊、向量化、索引、候選過濾、脈絡組裝、引用核對與拒答。任何一層出錯都可能影響最後結果。

「向量距離最近，就是正確規則」

距離只反映向量模型學到的相似程度。制度、版本、年齡、主訴與例外條件仍要另外檢查。

「把 k 設得越大，越不會漏資料」

較大的 k 可能提高找到相關片段的機會，也會帶入更多噪音、重複與衝突內容。k 是需要透過檢索實驗選擇的參數，不是越大越好。

「回答有引用，就代表引用支持答案」

引用可能存在，內容卻與結論無關。系統仍要檢查每個主要主張是否能在對應片段中找到支持。

「最終答案正確，整套 RAG 就成功」

模型可能在檢索失敗時依內部記憶答對。可追溯成功必須同時確認找到正確證據，以及回答忠實使用證據。

「更新規則文件後，下一次回答就會使用新版」

必須重新解析、切塊、向量化並建立新索引，再確認線上服務切換到正確索引版本。只替換原始檔案並不夠。

今天走到了哪裡？

Day 05 建立了 RAG 的六個基本觀念：

1. RAG 是先檢索外部證據，再讓 LLM 根據證據生成回答。
2. 離線階段負責把文件解析、切塊、向量化並建立索引。
3. 線上階段負責把問題向量化、檢索前 k 筆、組裝脈絡並生成回答。
4. 向量相近只代表語意候選，仍要核對制度、版本與適用條件。
5. 檢索成功和生成成功是兩件事，必須分層評估。
6. 每個規則區塊都要保存來源、中繼資料與穩定識別碼。

你可以用下面六個問題自行檢查：

1. RAG 比直接詢問 LLM 多了哪個核心步驟？
2. 離線索引的輸出如何成為線上檢索的輸入？
3. 文件切得太長或太短，分別可能造成什麼問題？
4. 前 k 筆為什麼只是候選，不是答案？
5. 「找錯但答對」為什麼不能算可追溯成功？
6. 如果規則更新，需要重新執行哪些離線步驟？

本日小結

RAG 的核心不是讓模型知道更多，而是建立一條可以檢查的路徑：問題進來後，系統到指定知識庫找出候選證據，再把問題、證據與輸出要求一起交給模型。

這條路徑把部分知識從模型參數移到可更新、可查詢的外部索引，也讓來源與版本有機會被保存。但它同時加入新的失敗點：文件可能處理錯、檢索可能找錯、脈絡可能組裝錯，模型也可能拿到正確證據卻說錯。

因此，RAG 不是「防止模型虛構內容」的單一開關，而是一組需要分層設計與驗證的資料流程。

下一篇預告

Day 06 會比較三種 RAG 架構：基本單層檢索、依規則結構逐層縮小範圍的階層式檢索，以及先用安全條件擴大候選集合的門控架構。

下一篇不只畫三張流程圖，也會用同一筆查詢走過三條路徑，確認它們究竟在「何時縮小候選」與「何時保留高風險規則」上有什麼差別。

參考資料

• Lewis 等人：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Karpukhin 等人：Dense Passage Retrieval for Open-Domain Question Answering
• Reimers 與 Gurevych：Sentence-BERT—Sentence Embeddings using Siamese BERT-Networks
• Li 等人：TRAQ—Trustworthy Retrieval Augmented Question Answering via Conformal Prediction
• FDA：Clinical Decision Support Software Guidance