跟 AI 廠商開過會的人，大概都聽過 RAG 這個詞，而且對方講得好像你應該懂。其實它的概念不難。RAG（Retrieval-Augmented Generation，檢索增強生成）是一種讓語言模型在回答之前，先從指定的資料中找出相關內容，再根據這些內容產生答案的做法。可以把它想成開書考試：模型不靠記憶硬答，而是先翻到相關的那幾頁再作答。這篇用不寫程式的人也能懂的方式，說明它怎麼運作、能解決什麼、不能解決什麼，以及評估廠商提案時該問哪些問題。
重點摘要
- RAG 是讓 AI 回答前先檢索指定資料、再依據檢索結果生成答案的技術，常用於企業知識庫與客服。
- 相較於微調模型，RAG 更新資料只要換文件，能附上出處，成本也低，是多數企業讓 AI 使用內部資料的首選做法。
- RAG 答不準時，問題多半出在「沒找到對的段落」，而不是模型不夠聰明。
- 資料量不大時不一定需要 RAG，把全部文件直接放進提示詞可能更簡單也更準。
為什麼需要 RAG？語言模型本身有什麼限制？
因為模型不知道你公司的事，也不知道訓練完成之後才發生的事。語言模型的知識來自訓練資料，那裡面不會有你的產品規格、內部規章與上週更新的價目表。直接問它，它要不是回答不知道，就是用聽起來很合理的方式編一個答案，後者就是大家說的「幻覺」。
RAG 這個名稱來自 2020 年 Patrick Lewis 等人發表的論文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，核心想法是把模型本身的語言能力與一個可以隨時查詢的外部資料庫結合起來。模型負責理解問題與組織語言，事實則由檢索到的資料提供。這個分工讓 AI 可以回答它從沒被訓練過的內容，而且答案有憑有據。
RAG 是怎麼運作的？
分成事前的「建索引」與使用時的「檢索加回答」兩段。前者只在資料新增或更新時做，後者在每次提問時發生。
RAG 的六個步驟
- 整理文件：把 PDF、Word、網頁等資料轉成乾淨的文字。
- 切分：把長文件切成一段一段，每段大約是一個主題。
- 建立索引：把每一段轉換成一組代表語意的數字（稱為向量），存進可以搜尋的資料庫。到這裡是事前準備。
- 檢索：使用者提問時，系統把問題也轉成向量，找出語意最接近的幾個段落。
- 組合：把找到的段落與使用者的問題一起放進給模型的提示詞裡。
- 生成：模型根據這些段落寫出答案，並標示引用自哪份文件。
整個過程中，模型本身沒有被改動，它每次都是現場看資料、現場回答。所以文件一更新、重建索引之後，答案立刻跟著改變，不需要重新訓練任何東西。
RAG 跟微調（Fine-tuning）差在哪裡？
RAG 是給模型參考資料，微調是改變模型本身。很多人以為要讓 AI 懂公司的事就得「訓練自己的模型」，實際上這兩種方法解決的是不同問題。微調擅長的是調整風格與格式，例如讓模型學會用你們品牌的語氣寫文案、固定輸出某種報告格式；它不擅長記住大量會變動的事實。
| 比較面向 | RAG | 微調 | 直接放進提示詞 |
|---|---|---|---|
| 做法 | 回答前先檢索相關段落 | 用範例資料再訓練模型 | 每次把全部資料交給模型 |
| 資料更新 | 換文件、重建索引即可 | 要重新訓練 | 改檔案即可 |
| 能否附出處 | 可以 | 不行 | 可以 |
| 適合的資料量 | 大量文件 | 與資料量無直接關係 | 少量文件 |
| 權限控管 | 可在檢索時依身分過濾 | 很難，學進去就分不開 | 依放入的內容而定 |
| 最適合 | 知識庫問答、客服、內部查詢 | 固定語氣、固定格式、專門分類 | 單一手冊、小型常見問答 |
對企業來說，權限那一列常常是決定性的。微調會把資料「融」進模型，之後沒有辦法讓業務看得到、工讀生看不到；RAG 則可以在檢索那一步就依提問者的身分過濾。只要你的需求是「讓 AI 根據公司資料回答問題」，起點幾乎都是 RAG，而不是微調。
RAG 答不準，通常是哪裡出問題？
多半是檢索那一步沒找到對的段落。模型只能根據拿到的資料作答，拿到錯的或不完整的段落，再強的模型也答不好。常見的狀況有三種：正確答案所在的段落根本沒被找出來；找出來了，但段落被切得太碎，少了前後文所以意思不完整；或者同時找到新舊兩個版本，模型把它們混在一起。
所以當廠商說「我們用的是最新最強的模型」時，那不是重點。該問的是：答錯的時候，你們怎麼查是檢索的問題還是生成的問題？有沒有辦法看到每一次回答引用了哪幾段？能回答這兩題的廠商，才是真的做過上線系統的。
有哪些做法可以提升 RAG 的準確度？
從資料切分、檢索方式與結果排序三個地方下手。切分方面，原則是讓每一段獨立讀也看得懂，保留它所屬的文件名稱與章節標題。一段寫著「本方案每月費用為 990 元」的文字，如果不知道是哪個方案，被檢索到也沒有用。
檢索方面，只靠語意搜尋會漏掉需要精確比對的東西，例如產品型號、錯誤代碼、人名。實務上會把語意搜尋與傳統的關鍵字搜尋併用，再用一個重排序的步驟，從找回來的候選段落中挑出最相關的幾段交給模型。Anthropic 在 Contextual Retrieval 的技術文章 裡公布過自家的測試：替每個段落補上所屬文件的脈絡說明、併用兩種搜尋並加上重排序之後，檢索失敗率從 5.7% 降到 1.9%。這是該公司在特定資料集上的結果，換到你的資料不會是同樣的數字，但方向是一致的：改善檢索帶來的進步，通常大於換一個更貴的模型。
什麼情況下不需要 RAG？
資料量小的時候。現在的模型一次能讀進去的內容已經很長，同一篇 Anthropic 的文章就建議，如果知識庫小於約 20 萬個 token（大約 500 頁的資料量），可以直接把整個知識庫放進提示詞裡，不必建檢索系統。這樣做沒有「找錯段落」的問題，架構也簡單得多。
所以如果你的需求是讓 AI 根據一本產品手冊、一份員工守則或幾十則常見問答來回答，先試最簡單的做法。等到文件多到放不下、每次提問的費用與速度開始成為問題，或是需要依身分控管誰能查到什麼，再導入 RAG。我們看過一些提案，為了五十頁的文件規劃了整套向量資料庫，這是把簡單的問題做複雜了。
RAG 有哪些做不到的事？
它擅長「查得到的問題」，不擅長「要看完全部才能回答的問題」。問「退貨期限是幾天」，答案在某一段裡，RAG 很拿手。問「去年所有客訴裡最常見的三個原因是什麼」，答案分散在幾千筆紀錄中，檢索只會抓回其中幾筆，模型看到的是片段，結論自然不可靠。這類彙總與統計的問題，應該交給資料庫查詢或報表工具。
另外兩個限制也要先有心理準備。文件裡沒寫的東西，RAG 變不出來，所以它無法取代把知識寫下來這件事。文件本身寫錯或過期，RAG 會忠實地把錯的答案講得很流暢。資料治理做得好不好，直接決定了成果，具體的整理方法與權限設計在 企業 AI 知識庫怎麼建 有完整的步驟。
常見錯誤：只看展示就決定上線
展示會上問五個問題、五個都答對，於是決定採用。上線兩週後，同事回報一堆答錯的案例，大家開始不信任它。問題出在展示用的題目通常是挑過的，而真實使用者的問法千奇百怪，有錯字、有簡稱、有一次問三件事的。
比較可靠的做法是在動工之前，先請實際會使用的同事提供五十到一百個真實問題，並由熟悉業務的人寫下正確答案與出處，做成一份測試題組。之後每一次調整切分方式、更換模型或更新文件，都用同一份題組跑一遍，看答對率是進步還是退步。這份題組的製作成本不高，卻是整個專案裡最能保護你的東西。如果你是第一次評估 AI 專案，建議先看過 中小企業導入 AI 從哪裡開始，確認現在是不是做 RAG 的時機。
常見問題
用了 RAG 之後，AI 還會有幻覺嗎？
會減少，但不會完全消失。當檢索到的資料不足或互相矛盾時，模型仍可能自行補上內容。實務上會要求模型只根據提供的段落作答、查不到就明說，並在回答中附上出處讓使用者可以查證。
向量資料庫是什麼？做 RAG 一定要用嗎？
向量資料庫是專門儲存與搜尋語意向量的資料庫，能快速找出意思相近的段落。它是 RAG 常見的元件，但不是唯一選擇，許多常用的關聯式資料庫與搜尋引擎也已支援向量搜尋。文件量不大時，選擇團隊已經熟悉的工具通常比導入新資料庫更實際。
RAG 跟在 ChatGPT 上傳檔案提問有什麼不同？
原理相近，差別在規模與控制權。上傳檔案適合個人處理少量文件；企業自建的 RAG 可以涵蓋大量且持續更新的資料、依員工身分控管可見範圍、串接內部系統，並保留完整的問答紀錄供稽核與改善。