PLAY AI 筆記什麼是 RAG？為什麼它比「把資料餵給模型訓練」更常被選用
模型不知道你公司內部的事，這很正常——它的訓練資料裡本來就沒有。RAG 的解法不是讓它「學會」，而是在它回答之前先去查一次。
本篇內容
先講結論
RAG 的全名是 Retrieval-Augmented Generation，中文常翻成「檢索增強生成」。名字很長，但它做的事可以用一句話講完：在模型回答之前，先去一個外部資料庫把相關的段落撈出來，連同你的問題一起交給模型。
所以模型並沒有變聰明，也沒有「學會」任何新東西。它只是在回答的當下，手邊多了幾段參考資料。這跟你考試前臨時翻書、而不是把整本書背起來，是同一件事。
它實際上做了什麼
拆開來看，一次 RAG 問答通常會經過四個步驟。真正新增的不是生成，而是回答前面的「找資料」：
- 把你的問題轉成向量（embedding），用一串數字代表這句話在語意空間的位置。
- 拿這個向量去向量索引找語意最接近的資料片段，通常只取回少量候選。
- 把候選段落、必要的來源資訊與原始問題組成新的提示內容。
- 模型根據眼前這些內容回答；如果系統有保留來源，也能把引用一起顯示。
「語意接近」和傳統關鍵字搜尋不完全一樣。問「請假規定」有機會找到寫著「特休申請流程」的段落；但反過來，如果資料庫根本沒有真正答案，檢索器仍可能挑出最接近的幾段。這也是為什麼 RAG 的品質不能只看模型本身。
真正難的其實是檢索品質
一個 RAG 系統常見的失敗，看起來像模型答錯，實際上問題可能早在資料切段與召回階段就發生了。文件切太碎，段落失去上下文；切太大，又會把太多無關資訊一起塞進 prompt。
RAG 常見的四個品質槓桿
| 環節 | 在做什麼 | 常見失敗 |
|---|---|---|
| Chunking | 把長文件切成可檢索片段 | 切太碎失去上下文；太大則噪音增加 |
| Embedding | 把問題與文件轉成可比較的向量 | 模型不適合語言或領域時召回變差 |
| Retrieval | 先找出一批候選片段 | 只看相似度可能把看似相關但無答案的段落撈回 |
| Reranking | 把候選重新排序後再交給模型 | 沒有重排時，真正關鍵段落可能排太後面 |
跟微調差在哪
這是最常被混在一起的兩個東西。「想讓 AI 懂我的資料」有三條路可以走，它們解決的其實不是同一個問題：
三種做法的取捨
| RAG | 微調 Fine-tuning | 直接放進 Context | |
|---|---|---|---|
| 資料更新 | 更新索引即可反映新資料 | 通常需要重新準備或訓練 | 下次提問重新附上 |
| 主要用途 | 查動態知識與內部資料 | 調整行為、語氣與特定任務模式 | 一次性讀取有限文件 |
| 來源追溯 | 可以保留檢索片段與來源 | 知識已融入權重，難直接指出來源 | 可以直接對應原文件 |
| 複雜度 | 要維護資料管線與索引 | 要維護訓練資料與模型版本 | 最簡單，但長文件會吃上下文 |
實務上不是「RAG 或微調只能選一個」。有些系統會用微調讓模型固定輸出格式，再用 RAG 提供最新知識。判斷重點是先問：你要改的是模型的行為，還是每一題可取得的資料。
什麼時候不該用
RAG 很常被講成萬用解，但如果資料量不大、文件很少變動，而且每次任務都只是讀同一份有限內容，直接把文件放進上下文通常更簡單。
- 資料只有一兩份而且大小可控：先用長上下文，不必急著多一套索引服務。
- 答案需要完整理解全文脈絡：只取回幾個片段可能破壞整體關係。
- 原始資料品質很差：先清資料。把垃圾建立成向量索引，只會更快找到垃圾。
回到你真正會遇到的選擇
如果你只是想讓 AI 幫忙讀一份 PDF 然後問幾個問題，先直接把檔案放進對話；如果資料多到每次都塞不完，而且內容還會一直更新，RAG 才開始有明顯價值。
真正成熟的 RAG 不是「接一個向量資料庫」就結束，而是一條可量測的內容管線：資料何時更新、切段方式是否合理、召回命中率如何、回答能不能回到來源。把這些環節拆開，你才知道錯的是哪裡。