你問 ChatGPT 一個關於公司內部 HR 政策的問題,它一本正經地胡說八道。或者你問 Claude 上個月才發佈的某個套件的 bug,它引用了根本不存在的 API。模型不是在「說謊」,只是它的權重裡沒有這些資訊。RAG 就是目前最常見的解法。
一句話講完核心概念
RAG 的全名是 Retrieval-Augmented Generation(檢索增強生成)。它不依賴 LLM 訓練時記住的內容,而是在收到問題的當下做兩件事:第一,從外部知識庫(通常是向量資料庫,有時是關鍵字索引或 SQL)檢索最相關的文字片段;第二,把這些片段塞進 prompt 再讓模型回答。模型根據檢索到的內容回答,而不是憑記憶。
所以一個典型的 RAG prompt 長得像這樣:「以下是公司內部文件的 5 段內容,請只根據這些資訊回答使用者的問題:……」。聰明的地方不在生成,而在「怎麼從上百萬段文字中挑出對的那 5 段」。
RAG 解決的三個痛點
LLM 有三個眾所周知的限制,RAG 正好對症下藥。
知識截止日。 GPT-4o、Claude Sonnet、Gemini 都有訓練截止日期,之後發生的事、還有它們從未看過的你公司內部文件,通通是盲區。RAG 在推論時注入新鮮或私有資料,你不必每次 Confluence 改一頁就重新訓練模型。
幻覺(hallucination)。 模型不知道答案時傾向生成看起來合理但內容是錯的東西。把檢索到的段落餵進去,可以大幅降低(但無法消除)幻覺,因為模型有具體文字可以參照。更好的是可以附引用——「這個答案來自員工手冊第 14 頁」——讓整個系統可被稽核。
Context window 的成本。 就算 Gemini 有 2M token、Claude 有 200K,你也不可能把整個 50GB 的文件庫塞進每一個 prompt。RAG 只挑出真正相關的片段,例如取 8 段、每段 500 token,總共 4K token 的脈絡,比全部塞進去快得多也便宜得多。
RAG 系統實際上怎麼建
一個正式上線的 RAG pipeline 有兩個階段,跑在不同時間。
索引階段(離線,文件變動時跑一次):
- 從 Notion、Google Drive、GitHub、PDF、資料庫等來源載入文件。
- 把文件切塊(chunking)。按固定 500 token 切是粗暴做法;按段落、章節、Markdown 標題做語意切塊通常檢索效果更好。
- 用 embedding 模型把每一塊轉成向量,例如 OpenAI 的
text-embedding-3-small、Cohere 的embed-v3,或開源的bge-m3。 - 把向量存進向量資料庫——Pinecone、Weaviate、Qdrant、pgvector,或原型階段用 Chroma。
查詢階段(線上,每個請求都跑):
- 用同一個 embedding 模型把使用者問題轉成向量。
- 做相似度搜尋(cosine 或 dot product),取 top-k 段。
- 可選但強烈建議:用 cross-encoder 做 rerank,例如 Cohere Rerank 或
bge-reranker。這一步比大多數人以為的更重要。 - 把檢索到的段落 + 問題組成 prompt,送給 LLM。
- 回傳答案,最好附上指回原文的引用。
整套東西用 LangChain 或 LlamaIndex 大概 200 行 Python 就能跑起來。難的不是程式碼,是針對你自己的資料調 chunk 大小、檢索品質和 prompt 結構。
真實產品裡的 RAG 長什麼樣
Cursor 和 GitHub Copilot 對你的 codebase 做 RAG:你問「我們在哪裡處理 Stripe webhook?」,它不是在你的 repo 上 fine-tune,而是檢索相關檔案。Perplexity 對即時網頁做 RAG——這基本上就是它整個產品。Notion AI 的問答功能在你的 workspace 上做檢索。ChatGPT 的「附知識的 Custom GPT」就是一個託管的 RAG 服務,Claude Projects 也是同一個概念:上傳檔案、問問題、背後檢索。
企業內部最常見的 RAG 場景:客服機器人查 help center、內部知識助手查 Confluence/SharePoint、法務查合約、開發助手查私有程式碼。
什麼時候不適合用 RAG
RAG 不是萬靈丹。AI 顧問業有個壞習慣是把它賣給所有人。
內容塞得進 context 就別用 RAG。 如果你的知識庫只有一份 30 頁 PDF,直接貼進 prompt。Gemini 1.5 Pro 或開了 prompt caching 的 Claude 處理長 context 又快又便宜,還省掉整層基礎設施。只有當文件量遠超過 prompt 容量時,RAG 才有意義。
你想改的是「行為」而不是「知識」就別用 RAG。 想讓模型用你的品牌語氣寫作、輸出特定格式、學會新任務?那是 fine-tuning 的工作。RAG 加事實,fine-tuning 加技能。
數學、推理、彙總問題別用 RAG。 「我們 10,000 張客服 ticket 裡有多少提到出貨延遲?」這不是檢索問題,是分析問題,該用 SQL 或結構化 pipeline。RAG 只會撈段落,不會算數。
資料高度結構化時要小心。 如果你的「知識」其實是商品目錄、庫存、CRM,直接查資料庫在準確度和延遲上通常都贏向量搜尋。混合架構(function calling → SQL)往往比純 RAG 好用。
沒人會跟你講的坑
Demo 看起來很神,上線後一團糟。真正的失敗模式:
- 瓶頸在檢索不在生成。 對的段落沒進到 top-k,模型再聰明也答不對。多數「RAG 不準」的抱怨,根本原因是檢索召回率只有 40%。
- Chunking 會破壞脈絡。 一段寫著「這個做法很危險」的文字,如果不知道在講哪個做法就毫無意義。好的切塊要保留足夠上下文,常見做法是重疊視窗或 parent-document retrieval。
- Embedding 有盲點。 它擅長處理同義改寫,但對罕見專有名詞、縮寫、數字常常翻車。混合搜尋(BM25 + 向量)幾乎都贏純向量。
- 索引會過期。 文件改了,索引要跟著更新。聽起來很基本,直到你的 pipeline 默默壞掉三個禮拜才被發現。
- 評測很難做。 「答案有沒有用對來源?」遠比「答案聽起來合不合理?」難量化。Ragas、TruLens、LangSmith 可以幫忙,但你還是需要一份人工標注的評測集。
延伸閱讀
接下來值得追的概念:embeddings(文字怎麼變成向量)、向量資料庫、chunking 策略、hybrid search 與 reranking、fine-tuning vs RAG(各自適用場景)、長 context window(小型語料的替代方案),以及 agentic RAG(模型自己決定要不要檢索、要檢索什麼)。
最快的學法是先做一個玩具版:100 份文件、Chroma、OpenAI embedding、50 行程式碼。然後故意丟刁鑽問題去打它,看檢索在哪裡爆掉——一個下午學到的東西,比看十篇教學還多。