RAG 是什麼？檢索增強生成的流程、選擇與驗收方法

業務在群組裡問：「A 客戶上次那張報價單，用的是哪一版材料規格？」以前的做法是翻共用硬碟，或等資深同事有空回。直接問 ChatGPT 也沒用，它沒看過你們的報價單，只能說不知道，或者更糟，編一個看起來很像的答案。

RAG 做的事，是讓 AI 在回答前先去翻公司的文件：找到那張報價單和對應的規格表，把相關段落和問題一起交給模型，請它只根據這幾段回答，並標出答案出自哪份文件。

OpenAI 在說明怎麼提高模型準確度時，用考試打過一個比方：微調像上了好幾個月的課，把東西記在腦子裡；RAG 像開書考，把課本帶進考場，遇到題目再翻。公司內部的規格、價格、流程會一直改，這類知識適合開書考，而不是逼模型背下來。

RAG 在做什麼：先查資料，再回答

RAG 是 Retrieval-Augmented Generation 的縮寫，中文常譯為「檢索增強生成」。這個詞來自 Patrick Lewis 等人在 2020 年發表的論文，作者把模型訓練時學到的知識稱為參數記憶，把外部的文件索引稱為非參數記憶，讓模型生成答案時可以去查後者。論文當時就點出兩個問題：模型很難交代答案的出處，也很難更新自己知道的事。RAG 對這兩件事都有幫助。

AWS 的定義很直白：讓大型語言模型在產生回答前，先參考訓練資料以外的權威知識庫。對企業來說，這代表三個好處：

不用重新訓練模型就能用上公司的資料。價格表改了，更新文件和索引就好。
答案可以附出處。使用者能點回原文核對，這點對客服與業務特別重要。
資料來源由你控制。哪些文件能被查、誰能查，都在你的系統裡決定。

換回開頭的例子：模型本身不知道 A 客戶用哪一版規格，這件事只存在你們的報價單和規格表裡。RAG 補上的就是這一段「去查」的能力。

從提問到答案，RAG 走過哪幾步

各家平台的做法細節不同，但流程大致相同。以「A 客戶上次的報價單用哪一版材料規格」為例：

步驟	在做什麼	在報價單例子裡
1. 切段（chunking）	把文件切成小段，每段可以單獨被找到	報價單切成表頭、品項、備註；規格表按章節切
2. 建立索引	每段轉成可比對語意的向量，也保留關鍵字索引	「材料規格」「AL6061-T6」這類字串都查得到
3. 檢索	把問題轉成查詢，找出最相關的幾十段	找到 A 客戶的三張報價單、兩個版本的規格表
4. 重排（rerank）	對找到的段落再評分一次，只留最相關的幾段	留下最新一張報價單的備註欄與對應的規格表章節
5. 組成提示	問題、段落與作答規則一起交給模型	規則是「只依這些段落回答，找不到就說找不到」
6. 生成並附出處	模型依段落寫答案，標出每句來自哪份文件	「規格表第 3 版，出處：2026-08 報價單備註」

第二步的「語意比對」是 RAG 常被介紹的重點：問題用「交期」、文件寫「出貨日」，意思相近也找得到。可是料號、訂單編號、錯誤代碼這類字串，語意比對反而容易抓偏。Anthropic 說明檢索改進方法時就提到，像「Error code TS-999」這種精確字串，傳統的關鍵字比對（BM25）比向量檢索可靠。

所以 Google Cloud 的 RAG 說明提到關鍵字與語意檢索並用，Microsoft 的文件則直接建議用這種混合檢索（hybrid search）提高召回，再用重排模型把最相關的段落排到前面。

問題比較複雜時，有些平台會先讓模型把問題拆成幾個子查詢。Microsoft 的 Azure AI Search 把這種做法稱為 agentic retrieval：例如「2023 年後到職的遠端員工休假規定是什麼」，會拆成休假、遠端工作、到職日幾個查詢同時找，再把結果合起來。

最後一步的出處，決定答案能不能被核對。OpenAI 的檔案檢索工具會在回答裡附上引用的檔案；要求答案附出處，是之後能驗收的前提。

由左到右排開的書架、抽出的三本書、用紙條標出段落的書頁，以及夾著幾張空白索引標籤的答案紙 RAG 的流程像查資料寫報告：從書架挑書、翻到對的段落，寫答案時把出處夾在旁邊。

每一步最常出錯的地方

RAG 答錯時，很多人第一個反應是換一個更強的模型。實際上，錯誤常常發生在模型拿到資料之前。以下是我會先查的五個地方：

找錯段落

問題和文件用詞不同、問題太模糊，或文件裡有大量相似的段落，檢索就可能抓錯。查法是直接看這一題檢索回來的前幾段是什麼，先別急著看最後的答案。

找到舊版

規格表第 2 版和第 3 版都在資料夾裡，檢索找到哪一版，模型就照哪一版回答。這是資料端的問題，模型分不出哪一份是現行版本。

權限沒對齊

財務的報價底價只該給財務與業務主管看，但索引裡如果沒有記錄權限，任何人一問都可能被找出來。Microsoft 的做法是在檢索時依使用者身分過濾文件（document-level security trimming）。權限要在檢索這一層處理，靠提示詞叫模型「不要說出來」擋不住。

表格和掃描檔

表格被切段後，某一段可能只剩一列數字，看不出是哪個材質；掃描檔沒有經過 OCR，裡面的字根本沒進索引。Anthropic 舉過一個例子：某段寫著「公司營收比上一季成長 3%」，單獨被找出來時，看不出是哪家公司、哪一季。

答案沒附出處，或出處對不上

模型可能在段落之外補上自己的一般知識。沒有出處的答案無從核對；出處對不上的答案，比沒附出處更危險。

症狀	通常出在哪一步	先查什麼
答非所問	檢索、重排	這一題找回來的前五段是什麼
答出舊規格	資料、索引	資料夾裡是否同時放了新舊版本
有人看到不該看的內容	索引、檢索	索引有沒有帶權限，檢索時有沒有依身分過濾
明明有文件卻答「找不到」	切段、索引	檔案是否為掃描檔、有沒有被成功解析
答案看起來對，但出處對不上	生成	提示有沒有要求只依段落回答、逐句附出處

資料端要整理到什麼程度，我在企業知識庫要整理到什麼程度，AI agent 才用得上整理了一份只替第一個流程準備的清單，這裡就不重複。

RAG、長上下文、微調和 agent 怎麼選

RAG 只是其中一種做法。最常見的卡關，是分不清自己的問題該用哪一種。

長上下文：文件少就整份放進去

文件量不大時，直接把整份文件放進提示裡，連檢索都不用建。Anthropic 的建議是，知識庫小於 20 萬個 token（約 500 頁）時可以這樣做。Google 的 Gemini 文件也說，長上下文讓你可以一開始就把相關資料全部給模型；但同一次要找好幾個分散的資訊點時，準確度會下降，而且每次提問都要付整份文件的輸入費用，常用的內容可以搭配快取降低成本。

微調：處理的是行為

OpenAI 把最佳化分成兩條軸。模型缺的是它沒學過的知識，用 RAG 這類補充脈絡的方法；模型的問題是格式不穩、語氣不對、推理方式不一致，才用微調。兩者可以疊加。拿微調去教模型每個月都在改的價格表，我會認為方向錯了。

agent：查完還要進系統做事

需求不只是查答案，還要進系統做事，例如建立報價單草稿、改訂單狀態，才需要 agent。這時 RAG 常常是 agent 手上的一個工具，負責查資料；其他步驟由 agent 決定。兩者的差別可以看 AI agent 和聊天機器人、RPA、自動化流程差在哪。

四種做法放在一起看

你的需求	先試	理由
同事查規格、問政策，文件幾十頁以內	長上下文	不用建索引，整理好文件直接放進提示
文件上百份、會持續更新，要附出處	RAG	只拿相關段落，更新文件就更新答案
答案內容都對，但格式、語氣每次不一樣	先改提示，不夠再微調	問題在模型行為，補資料幫不上忙
查完資料還要去系統建單、改狀態	agent，RAG 當其中一個工具	需要多步驟操作與人工確認
要查的是數量、金額、庫存	直接查資料庫或表格	數字切段檢索容易失準，查系統比較穩

多數企業的第一個知識庫問答，用 RAG 或長上下文就能開始，不用一次就做成 agent。第一個流程怎麼挑，可以看哪些企業流程適合先交給 AI agent。

答案怎麼驗收：找對段落和答對問題分開記

OpenAI 在開頭提到的那份準確度指南裡，把 RAG 的失敗分成兩類：一類是檢索給錯了資料，或給了太多無關資料把重點淹沒；另一類是資料給對了，模型卻用錯。兩類的修法完全不同，所以驗收時要分開記。

我建議這樣做：

從真實紀錄挑 20 到 30 題。來源是客服信、業務群組、內部表單裡實際被問過的問題，不要自己想。
每題寫下標準答案，以及應該出現的文件段落。例如「A 客戶報價單用哪版規格」的標準答案是「第 3 版」，應命中的段落是 2026 年 8 月報價單的備註欄。
放幾題文件裡沒有答案的問題。正確行為是回答「找不到」，硬湊出一個答案就算錯。
每題記三欄：正確段落有沒有出現在檢索結果前五名、答案對不對、出處點回去是否真的寫著這件事。

記錄起來大概像這樣：

題目	應命中段落	檢索有找到	答案正確	問題在哪
A 客戶報價單用哪版規格	2026-08 報價單備註	有	對	—
6061 鋁材最小孔徑	規格表第 3 版 4.2 節	沒有，找到第 2 版	錯	資料：舊版未下架
B 客戶付款條件	合約附件二	有	錯，混入一般慣例	生成：未限制只依段落
明年度調價幅度	文件裡沒有	—	應答「找不到」	測試拒答行為

這張表的用處是讓你知道該修哪一段：第二題要整理資料，第三題要改提示。只看「答對幾題」，會把兩種問題混在一起修。文件改版後用同一組題目重跑，才看得出有沒有退步。更完整的驗收設計，可以看 AI agent 專案怎麼驗收。

網站被 AI 搜尋引用，也是同一套流程

RAG 不只出現在企業內部。Google Search Central 說明，它的生成式 AI 搜尋功能（AI Overviews、AI Mode）靠檢索增強生成（Google 也稱為 grounding），透過核心排名系統從 Search 索引找出相關網頁，再用 query fan-out 同時發出一組相關查詢補足子題。要成為這些回答裡的支援連結，頁面必須已被索引、而且符合在搜尋結果顯示摘要的資格。

例如有人問「6061 鋁件陽極處理後尺寸會變多少」，AI Mode 可能同時查膜厚、尺寸公差、材料特性幾個子題。你網站上的技術說明頁如果沒被索引，就不在它能挑的來源裡。

換句話說，網站內容要先被「檢索到」，才有機會被引用。AI 怎麼從候選來源組出推薦，可以看 AI 怎麼決定推薦哪個品牌；AI 搜尋和傳統搜尋在結果單位上的差別，則在 AI 搜尋和傳統搜尋差在哪裡。

我們能協助的部分

RAG 最花時間的通常是把散在各處的資料接起來，並讓權限跟著原本的規則走；選模型反而是比較快決定的部分。例如規格書在共用硬碟、報價在 ERP、客服紀錄在信箱，三個來源各有各的權限，要一個一個串接；AI 應用怎麼用標準方式接上這些系統，可以看 MCP 是什麼。

我們的企業 AI 營運方案從需求診斷開始，工程團隊到現場梳理資料現況與作業細節，接著進行系統串接、在真實業務中驗證上線，之後持續維護。資料異常或高風險的判斷，會設計成先交由專人確認再放行。

常見問題

有了 RAG，AI 就不會答錯了嗎？

會少一些，但還是會錯。Google Cloud 的說法是 RAG 有助於減輕生成式 AI 的幻覺，前提是檢索找對了段落，模型也照段落回答。會對客戶承諾的內容，例如交期、價格、品質判定，仍要保留人工確認，並要求答案附出處方便核對。

RAG 和微調可以一起用嗎？

可以。OpenAI 的說明是兩者可以疊加：RAG 補知識，微調穩定格式與行為。多數企業的第一個專案先把 RAG 做好就夠，等答案內容對了、只剩格式不穩時，再評估微調。

一定要自己架向量資料庫嗎？

不一定。OpenAI 的向量資料庫在檔案放進去時會自動切段、轉成向量並建立索引；Azure AI Search 也有自動切段與向量化的流程；Google Cloud 的 Agent Search（原 Vertex AI Search）則要在建立資料儲存庫時開啟切段功能。會選擇自己架，通常是因為資料不能離開公司環境，或需要更細的檢索調整。三種做法怎麼選，可以看向量資料庫是什麼。

文件改版之後，RAG 要重新訓練嗎？

不用重新訓練模型，要更新的是索引。把新版文件放進去、舊版移出，索引同步之後，下一次提問就會查到新內容。建議在文件改版流程裡加一步「確認索引已更新」，再用固定測試題抽查。

料號、訂單編號這種字串，RAG 找得到嗎？

要看檢索方式。只用語意比對時，精確字串容易抓偏；混合檢索同時比對關鍵字，找料號、編號會可靠很多。如果要查的是某張訂單的數量或狀態，讓系統直接查資料庫，通常比從文件段落裡找更準。

參考來源

以下依官方文件整理，功能以各家官方頁面當下為準。

RAG 是什麼？企業知識庫問答怎麼運作、什麼時候不夠用