RAG 是什麼?讓 AI 回答「你家的事」的技術

很多老闆第一次認真玩 ChatGPT 或 Claude,都會問我們同一個問題:「它什麼都答得出來,為什麼問我們公司的退貨規則就開始胡說?」答案很簡單:模型的知識來自訓練資料,而你家的退貨規則、產品規格、內部 SOP,從來不在裡面。模型不知道的事,它不會說「我不知道」,它會編一個聽起來很像的答案給你。

RAG(Retrieval-Augmented Generation,檢索增強生成)就是解決這件事的主流技術。我們自己的 AI 產品線與客戶專案裡,九成需要「AI 回答公司內部問題」的場景,最後都是用 RAG 收尾。這篇用白話把它講清楚。

RAG 的原理:先查資料,再回答

把 RAG 想成一個很會讀重點的新人助理。你問他問題,他不是憑記憶亂答,而是先跑去翻你給他的資料夾,找出最相關的三五頁,讀完之後根據這些內容回答你,還能告訴你答案出自哪一份文件。

技術上拆成三步:

1. 建索引:把公司文件(SOP、產品手冊、FAQ、合約範本)切成小段落,轉成向量存進資料庫。向量可以理解成「語意的座標」,意思相近的段落座標就相近。
2. 檢索:使用者提問時,系統把問題也轉成向量,找出座標最接近的幾個段落。
3. 生成:把「問題 + 找到的段落」一起交給 LLM,要求它只根據這些內容回答。

關鍵在第三步:模型不再憑空發揮,而是照著你給的資料回答。答案有憑有據,還能附上出處,錯了也查得出來是哪份文件過期了。

RAG 解決什麼、不解決什麼

RAG 擅長的場景有明確的共同點:答案存在於文件裡,只是散落各處、沒人找得快。客服回覆常見問題、新人查 SOP、業務查產品規格與報價規則、內部法規與合約條款查詢,都是典型案例。我們的進銷存 SaaS 客服後台就掛了一層 RAG,讓值班同事先問系統再翻文件,查找時間差非常有感。

但 RAG 不是萬靈丹,有三件事它做不到:

• 文件裡沒寫的,它答不出來。垃圾進垃圾出,文件品質決定答案品質。這也是為什麼導入 RAG 的第一步往往不是寫程式,而是整理文件。
• 需要推理與計算的複雜問題。「幫我比較 A、B 方案十年總成本」這種題目,檢索只能找到片段,組裝與計算還是要靠模型能力與流程設計。
• 它不會讓模型「學會」你的領域。RAG 是開卷考試,不是重新受訓。如果你要的是改變模型的說話風格或深層領域直覺,那是另一條路,我們在微調還是 RAG那篇有完整比較。

導入前先想清楚的三件事

第一,文件現況體檢。你的 SOP 是最新的嗎?同一件事有沒有三份互相矛盾的文件?RAG 會忠實反映文件的混亂,不會幫你消毒。我們接過的案子裡,整理知識庫的工時常常超過寫程式的工時,這件事在企業知識庫 × AI裡有更完整的建置路徑。

第二,錯誤的代價。內部同仁查 SOP,答錯了有人工把關,風險低;直接面對客戶回答退款金額,答錯就是客訴。風險高的場景要加輸出驗證與人工升級路徑,不能裸奔上線。

第三,資料要去哪裡。文件送去做向量、問題送去給模型,中間經過哪些服務、留存多久,導入前就要問清楚。

RAG 不是讓 AI 變聰明的魔法,而是讓 AI 學會「先查再說」的紀律——而這恰好也是我們對員工的要求。

從一個小場景開始

我們給客戶的建議一向是:別一開始就想做「全公司什麼都能問」的超級大腦。挑一個文件相對齊全、問題高度重複的場景——通常是客服 FAQ 或新人常見問題——兩三週做出第一版,讓團隊實際用,從回答品質回頭修文件,再逐步擴大範圍。

如果你正在評估這件事,不確定自家的文件體質適不適合,歡迎透過AI 應用開發服務找我們聊聊。我們自己天天在用 RAG,能很快告訴你哪些期待是合理的、哪些是行銷話術。