為什麼需要 RAG

TL;DR

• 公司私有資料 model 沒看過、太大塞不進 context、塞進去也會被稀釋
• RAG = 先「找出相關的幾段」再交給 model 回答——不是換 model，是換進 context 的東西
• 不是萬靈丹——找錯資料 model 會跟著被誤導

一個情境：公司內部 FAQ 機器人

老闆說：「我們公司有 800 頁的內部規範、產品手冊、HR 政策、法務 FAQ……寫一個 bot 讓員工問問題，少騷擾各部門。」

直覺寫法：

with open("company_docs.txt") as f:
    docs = f.read()  # 假設總共 10 萬 token

messages = [{
    "role": "user",
    "content": f"參考以下文件回答問題：\n\n{docs}\n\n問題：{user_question}"
}]

跑一次馬上發現三個問題：

1. 塞不下：context window 雖然大（200K），但 800 頁 PDF 抽完文字常常超過。一頁出版品 ~500–800 token，800 頁就 40 萬以上。
2. 每次都很貴：就算塞得下，每個 user query 都要重算 10 萬 token 的 input cost——一個簡單問題 USD 0.3 起跳。
3. 回答品質下降：Claude 在「整份 800 頁文件」裡找答案，比在「一段直接相關的 500 字」裡找答案，準確率更低——這叫 context dilution。

聊天介面的「我把 PDF 拖進去問」其實幫你做了一個迷你 RAG。產品要的是把這個過程接成自己的 pipeline。

三條看似可行的路

方案	怎麼做	為什麼不夠
全塞 prompt	每次把整份文件當 context	貴、慢、context dilution、長文件根本塞不下
Fine-tune	把文件「訓」進模型權重	知識更新慢（每次新政策都要 retrain）、貴、可能傷其他能力
RAG	先 retrieve 相關段落，只把那幾段塞進 context	知識可即時更新、cost 可控、答案可溯源

Fine-tune 在 LLM 時代最常被誤用：「我有公司資料、想讓 model 學會」幾乎都該用 RAG 而不是 fine-tune。Fine-tune 適合「教 model 一種風格 / 格式 / 行為」，不適合「教 model 一份會更新的知識庫」。

RAG 的核心比喻

RAG = 圖書館員 + 學者：

• 圖書館員（retrieval）：聽到問題後跑去書架抽出 3 本最相關的書，遞給學者
• 學者（model）：只看那 3 本，根據裡面的內容回答

學者本身的知識（pretraining）沒變，但手上的資料是「為這個問題 curated 過的」。Model 不用通讀 800 頁，只看 3 段最相關的。

這個比喻也說明 RAG 的弱點：圖書館員抽錯書，學者就會答錯。後面整個 section 都在處理「怎麼抽得準」這件事。

RAG 的好處

• scale：底層文件多到 GB 級也沒事，每次 query 還是只塞 3–5 段
• 可更新：新文件加進來重新 index 就好，不用碰 model
• 便宜：input token 降一個數量級，output 也更精準（不會被無關內容干擾）
• 可溯源：你知道 model 拿哪幾段去回答——後面 citations 會把這件事做得更扎實

RAG 的代價

不是免費的，引入 RAG 等於多接一個子系統：

• preprocessing：文件要切 chunk、生 embedding、存 vector DB
• retrieval quality：抽錯就 garbage in / garbage out，要會量測 recall / precision
• infra：多一個 vector DB（pgvector / Qdrant / Pinecone 之類的）要維運
• chunking 策略要選對：切太小失去 context、切太大 embedding 不準（下一篇講）

什麼情境用 RAG，什麼情境別用

情境	RAG	全塞 prompt
整份文件 5K token、問題涵蓋全文	反而麻煩	直接塞
多份文件 / 文件會更新 / 很大	標準場景	不可行
每次問題只看其中一小段	標準場景	浪費錢
需要文件層級的精確引用	配合 citations	也可以但較弱
一次性 prototype	過度工程	直接塞

rule of thumb：文件總量 < 50K token，又不會每天更新，先全塞 + prompt caching；超過、會更新、或要溯源——上 RAG。

接下來

下一篇進到 RAG 的兩塊基石——embeddings（怎麼把文字變成可以比對相似度的向量）跟 chunking（怎麼把長文切成「適合 retrieve 的」單位）。這兩件事決定圖書館員抽得準不準。