什麼是 RAG 檢索增強生成?企業把 LLM 推上生產線的預設架構解析

RAG(Retrieval-Augmented Generation,檢索增強生成)是一種讓大型語言模型在回答前,先從企業自己的知識庫檢索相關資料、再據此生成答案的架構。一句話說清楚:它不是把知識塞進模型的腦子裡,而是在模型開口前,先遞給它一份「參考資料」。這也是為什麼今天多數企業要把 LLM 推上生產線時,RAG 幾乎成了預設選項。

先講一個我們常遇到的場景。某家製造業客戶想做一個內部問答機器人,讓工程師能用自然語言查零件規格與歷史工單。第一版直接接 GPT,結果它把三年前就停產的料號講得頭頭是道,連交期都「編」了出來。不是模型笨,是它根本不知道這家公司的資料長什麼樣。它只能從訓練時看過的公開網路內容裡「猜」一個最像的答案。RAG 要解決的,正是這件事。

什麼是 RAG 檢索增強生成:三個步驟拆給你看

RAG 的運作可以拆成三步,順序很重要:檢索、增強、生成。

檢索(Retrieval):當使用者問「A 產線去年 Q3 的良率異常怎麼處理的」,系統不會直接把問題丟給 LLM,而是先把這句問題轉成一組向量,拿去企業的向量資料庫裡比對,撈出語意最相近的幾段文件——可能是幾份工單、一份會議記錄、一段 SOP。

增強(Augmentation):把撈到的這幾段原文,連同使用者的問題,一起組成一段新的 prompt。等於在問模型之前,先在題目下面附上「以下是相關資料,請根據這些回答」。

生成(Generation):LLM 這時才登場。它讀的是「問題+你剛塞給它的公司真實資料」,再生成答案。因為答案有出處,你甚至能要它標註引用了哪份文件。

三步走完,那個會亂編料號的機器人,變成一個會說「根據 2024 年 8 月的工單 #4471,建議⋯⋯」的機器人。差別不在模型換了,在於它手上有了正確的資料。

一張圖看懂企業 RAG 架構

使用者提問
   │
   ▼
[查詢向量化] ──► [向量資料庫檢索] ──► 撈回 Top-K 相關片段
   │                    ▲
   │                    │
   │            [文件切塊 + Embedding]  ← 內部文件 / PDF / 資料庫
   │                    (離線建索引,定期更新)
   ▼
[組裝 Prompt:問題 + 檢索片段]
   │
   ▼
[LLM 生成答案] ──► [附引用來源] ──► 回傳使用者

這張圖裡藏著兩條時間線,很多人會漏掉。右邊那條是離線的:先把公司文件切塊、算 embedding、灌進向量庫,這件事平常就在跑,文件更新它也要跟著更新。左邊那條才是使用者按下 Enter 後即時發生的。把這兩條分開看,你就會理解為什麼 RAG 專案真正的工程量,常常不在模型調用,而在資料的清洗、切塊策略與索引維護。

RAG 和其他做法差在哪

企業要讓 LLM「懂自己的事」,常見有三條路,取捨如下:

多數企業知識系統的知識是「活」的——政策改了、產品換代、法規更新。這種場景下,微調的成本會把你拖垮,而 RAG 只要更新向量庫就好,還能給出引用來源,對金融、醫療這類需要可稽核的產業幾乎是剛需。

RAG 不是萬靈丹,踩過的雷得說清楚

我們得誠實:RAG 上線後最常見的失敗,不是模型答錯,是「檢索根本沒撈到對的東西」。文件切太大,一塊塞進去半篇不相關;切太小,又把一個完整段落拆得語意破碎。有個客戶的 FAQ 命中率一開始只有六成,我們沒動模型,光是重做切塊策略、加上關鍵字與向量的混合檢索,命中率就拉到九成以上。

還有一種雷是「檢索到了,但模型不老實」。明明資料裡沒有,它還是硬答。這時要靠 prompt 約束它「資料不足就說不知道」,再加上引用驗證。這些都不是寫幾行程式就好,是要有人盯著真實使用資料,一輪一輪調。

RAG 的架構好畫,難的是讓它在你公司的資料、你同事的問法下真的可用。我們在 Tenten 做企業知識系統時,通常不從模型選型開始,而是先蹲點看你的文件長什麼樣、人到底怎麼問,把檢索這一段調到準,再談生成。Demo 裡答得漂亮不算,得是現場的人願意天天用它查東西,才算真的上線了。