你有沒有遇過模型把不存在的規定講得煞有介事，或是在你的問題裡硬掰出一個錯的答案？檢索增強生成（RAG）就是為了處理這類問題而生的做法。這篇把它的運作拆開來看，說明它為什麼能讓回答更可靠，以及它自己的限制在哪。
RAG 是什麼：先查資料，再生成答案
檢索增強生成（Retrieval-Augmented Generation，簡稱 RAG）是一種讓模型在回答前先查外部資料的做法。它把兩個原本分開的能力接在一起：一個負責從資料庫或文件裡找出相關內容，一個負責根據這些內容生成回答。
它的核心精神是幫大型語言模型補上一個缺口。模型腦中的知識來自訓練資料，訓練結束後就固定了，遇到訓練之後發生的事、或你公司內部的私有文件，它一概不知道。RAG 的做法是在回答前，先把相關的、最新的資料找出來放進提示裡，讓模型有依據地作答。
這個詞出自 2020 年的一篇論文，主要作者 Patrick Lewis 後來受訪時開玩笑說，如果早知道 RAG 會變得這麼普遍，當初會多想一個更好聽的名字。名稱不討喜，做法卻成了現在企業導入生成式 AI 的主流路徑之一。
為什麼模型需要外掛一份資料
大型語言模型本質上是類神經網路，靠訓練時看過的海量文字來預測下一個詞。它把知識壓縮在參數裡，這件事有兩個後果。
第一，知識有截止日。模型不知道訓練資料收集之後才發生的事，問它昨天的新聞，它只能猜。第二，模型沒有你企業內部的資料。產品規格、客服話術、內部規範這些東西從未進入公開訓練資料，模型自然無從得知。若硬要它回答，就容易出現「幻覺」：聽起來很肯定，實際上卻是編的。
RAG 就是把這兩塊缺口補上。它不改動模型本身的參數，而是在每次問答時，即時把正確的資料餵給它。等於讓同一個模型，隨時能接上不同的資料來源。
一次問答，背後跑了哪些步驟
RAG 的流程可以拆成幾個階段。文件進來時，系統會先把長文件切成較小的片段，再透過嵌入模型把每個片段轉成向量，存進向量資料庫。這一步決定了系統「查得到什麼」。
使用者的問題進來時，系統同樣把問題轉成向量，去資料庫裡比對最相近的片段，取回幾則最相關的內容。這一步決定「查到什麼」。
最後，系統把使用者問題和取回的片段一起放進提示，交給語言模型生成回答。這一步決定「答得順不順、有沒有根據」。三個階段的品質環環相扣，任何一環出問題，最終回答都會受影響。
它跟直接把長文塞給模型有何不同
最直覺的替代做法，是把整份文件直接貼進提示，讓模型自己讀。文件不長時，這招確實有效。但一旦文件量大到幾百頁，這條路就走不通。
原因是模型的脈絡視窗有上限。就算某些模型宣稱能處理上百萬個詞元，把整本手冊塞進去，不只成本高，模型還容易在長文中失焦，抓錯重點。RAG 的價值就在這裡：它只精準取出相關的幾段，用最少的內容回答當下的問題。
它同時解決了更新問題。文件內容改了，只要重新處理對應片段、更新資料庫即可，不需要重新訓練模型。對變動頻繁的知識庫來說，這種即時更新的能力是關鍵。
RAG 也不是萬靈丹，這些地方仍會出錯
RAG 最常見的失敗，是檢索階段沒抓到正確的片段。如果切片的顆粒太粗，關鍵資訊可能被稀釋；切得太細，又可能遺失上下文。使用者問法與文件用詞差異太大時，向量比對也可能失準，撈回一堆不相關的內容。
第二類問題出在生成的環節。就算片段正確，模型仍可能誤讀或過度延伸。系統設計上通常會要求模型「只根據提供的資料作答」，並在找不到依據時表明不知道，但這條規則不見得每次都遵守。
第三類是資料本身的品質。RAG 只是把資料找出來餵給模型，如果知識庫裡的文件過時、互相矛盾或本來就寫錯，模型照著生成，錯誤只會被包裝得更像真的。所以維護資料庫的品質，往往比調校模型更花心力。
哪些場景用 RAG 最划算
企業內部問答是最典型的一塊。把員工手冊、產品文件、客服紀錄整理成知識庫，讓模型先查再答，員工不必自己翻遍資料夾。這種場景需求穩定、資料私有，正是 RAG 發揮的地方。
法律與金融領域也常見這種做法。合約、法規、財報這類文件隨時會更新，而且要求回答必須有憑有據。RAG 能讓回覆附上引用的原始段落，方便人工核對，這比單靠模型的記憶可靠得多。
客服與技術支援同樣適合。把歷史工單與疑難排解指南接進系統，模型就能針對使用者當下的問題，給出對應的處理步驟，而不是回一段泛泛的說明。
想導入 RAG，先問自己三個問題
第一，你的資料放在哪裡、有沒有整理過？RAG 的效果上限，取決於知識庫的品質。如果文件散落各處、格式混亂，得先花力氣清理，否則再好的模型也撈不到正確內容。
第二，你需要多即時的回應？如果資料每天更新，就得確保重新處理的流程自動化，否則使用者查到的是舊版本。第三，你能接受多少錯誤？RAG 降低了幻覺，但沒有消除它。高風險的場景仍需要人工複核，並在設計上要求系統標明資料來源與更新時間。
搞懂這三點，再決定要不要導入、導入到什麼程度，會比先買工具再想用途務實得多。
