大型語言模型的知識被鎖在訓練那一刻,之後發生的事、公司內部的文件、私人資料庫裡的紀錄,模型一概不知,只能用參數裡殘留的統計規律去「腦補」答案。檢索增強生成(Retrieval-Augmented Generation,RAG)就是為了解決這個落差而生的架構:在模型生成答案之前,先從外部知識庫抓出真正相關的資料,把它塞進提示詞,讓模型有憑有據地作答。
RAG 不是要取代模型的推理能力,而是把「記憶」這件事外包給可以隨時更新、可以查證來源的資料庫。這篇文章把 RAG 拆成四個環節講清楚:為什麼需要它、向量嵌入與向量資料庫怎麼運作、文件切塊與檢索流程的眉角,以及進階技巧如何進一步壓低幻覺。
📖 學(核心)
為什麼需要 RAG:模型的知識邊界與幻覺問題
語言模型的訓練資料有明確的時間截止點,超過這個時間點的事件、新發布的產品、剛更新的公司政策,模型一律答不出來,或更糟——它會用看似合理的語氣編造答案,這就是「幻覺」(hallucination)。幻覺的根源不是模型「說謊」,而是它的生成機制本質上是在做機率最大化的詞語接龍,當訓練資料裡沒有對應的事實,它仍然會產生語法通順、邏輯自洽的句子,只是內容是編的。
另一個限制是「私有資料」問題。企業內部的合約、客服紀錄、產品手冊、個人的筆記庫,這些內容從來不在公開訓練語料裡,模型天生不知道。若想讓模型回答「我們公司 Q2 的退貨政策是什麼」,唯一可靠的做法是把政策文件即時餵給它看,而不是指望它「記得」。
RAG 的核心思路很簡單:把「知識」和「推理」拆開處理。知識存放在外部、可更新、可追溯來源的資料庫裡;模型只負責讀懂使用者的問題、讀懂檢索回來的資料,再組織成通順的答案。這樣做的好處是知識庫更新不需要重新訓練模型,回答也能附上引用來源,方便使用者查證,大幅降低「模型胡說八道卻講得很有自信」的風險。
向量嵌入與向量資料庫:讓機器讀懂「意思」而非「字面」
要讓機器從一堆文件裡找出「跟這個問題意思相近」的段落,靠關鍵字比對是不夠的,因為使用者的提問用詞常常跟文件原文不一樣。向量嵌入(embedding)解決的正是這個問題:透過一個嵌入模型,把一段文字轉換成一組高維度的浮點數向量,語意相近的文字,轉換出來的向量在空間中的距離也會相近。例如「如何延長筆電電池壽命」和「怎麼讓筆電電池用比較久」字面完全不同,但嵌入後的向量會落在相近的位置。
有了向量,接下來要解決的是「怎麼快速找出最相近的向量」。當知識庫只有幾百筆資料,逐一計算餘弦相似度(cosine similarity)還能接受;但當資料量來到百萬筆以上,線性掃描的成本就變得不可行。這正是向量資料庫(vector database)存在的理由,像 Pinecone、Milvus、Qdrant、Weaviate 或開源的 FAISS,它們用 HNSW(Hierarchical Navigable Small World)、IVF、PQ 等近似最近鄰(ANN)演算法建立索引,把原本 O(n) 的搜尋壓縮到近似 O(log n) 的等級,用些微的精確度換取數量級的速度提升,讓大規模檢索能在毫秒等級完成。
選擇嵌入模型時要注意向量維度、支援語言(中文語料建議挑有針對多語言或中文微調的模型)、以及與下游檢索任務的契合度,不同嵌入模型之間的向量空間並不通用,一旦選定就不宜中途更換,否則整個知識庫得重新嵌入索引。
文件切塊與檢索流程:細節決定 RAG 系統的上限
原始文件通常很長,不能整篇塞進嵌入模型或提示詞,必須先「切塊」(chunking)。切塊策略直接決定檢索品質的天花板:塊切得太大,單一片段包含太多不相關資訊,稀釋了語意的精確度;切得太小,又容易丟失前後文脈絡,例如一段財報只寫「營收成長 3%」,卻沒說是哪家公司、哪一季。業界實務上,多數生產環境落在每塊 300 到 500 個 token 左右,並保留 10% 到 20% 的重疊(overlap),讓相鄰片段不會在關鍵句子處硬生生斷開;比起單純按字數切,依照文件結構(標題、段落、條列)做遞迴式切分通常效果更好。
檢索流程本身分成四個階段:先「索引」——把文件切塊、嵌入、存進向量資料庫;使用者提問時先做「檢索」——把問題也轉成向量,在資料庫裡找出最相近的前 k 個片段;接著「增強」——把這些片段連同原始問題組合成新的提示詞;最後才是「生成」——模型根據這個增強過的提示詞產生答案。
值得注意的是,行業分析指出 RAG 系統失敗時,問題出在檢索階段的比例高達七成以上,生成階段的問題反而是少數。這代表投入資源優化切塊策略、嵌入模型選擇、檢索召回率,往往比一味換更強的生成模型更有效益。Anthropic 提出的「上下文檢索」(Contextual Retrieval)技術,是在切塊階段用模型為每個片段生成一段簡短的上下文說明再嵌入,實測能將檢索失敗率降低超過六成,說明切塊與索引品質才是 RAG 真正的勝負點。
降低幻覺與進階技巧:hybrid search 與 re-ranking
即使有了 RAG,幻覺並不會完全消失,只是被大幅壓低。要進一步降低幻覺風險,第一層防線是確保檢索回來的內容夠準確且夠相關,如果檢索結果本身就是雜訊,再強的生成模型也會被誤導,產生「基於錯誤資料的幻覺」。第二層防線是在提示詞設計上,明確要求模型只根據提供的資料作答,遇到資料不足時要誠實說「不知道」,而不是硬湊答案,同時要求附上引用來源,方便人工核對。
單純的向量檢索(dense retrieval)偏重語意相似度,但對精確的關鍵字、專有名詞、型號、代碼等內容反而不夠敏感,這時候混合檢索(hybrid search)就派上用場:同時使用向量檢索與傳統的關鍵字檢索(如 BM25),再把兩種分數用加權或 RRF(Reciprocal Rank Fusion)等方式融合排序,兼顧語意理解與精確比對兩種能力。LangChain 的 EnsembleRetriever 就是實作這種混合檢索的常見工具。
第二階段的優化是重排序(re-ranking):先用速度快的檢索器從龐大的資料庫中撈出幾十到幾百筆候選片段,再用一個更精細、運算成本較高的重排序模型(cross-encoder)重新為每個候選片段跟問題的相關性打分,取最終排名最前面的幾筆送進提示詞。Pinecone 與 Databricks 的研究都指出,加入重排序步驟能讓檢索品質提升一成五到接近五成,是投入產出比很高的優化手段。
RAG 系統也有其實務限制:向量資料庫的建置與維運需要額外的基礎設施成本;文件更新頻繁時,重新嵌入與索引會產生延遲;跨語言或跨領域的嵌入品質參差不齊;提示詞塞入過多檢索片段會擠壓上下文視窗、增加成本,也可能引入不相關雜訊。這些都是導入 RAG 前必須評估的權衡,而非裝上就一勞永逸的萬靈丹。
🧠 記
- RAG 把「知識」外包給外部資料庫,模型只負責理解與生成,知識庫更新不必重新訓練模型
- 向量嵌入讓語意相近的文字在向量空間中距離也相近,是語意檢索的基礎
- 向量資料庫用 HNSW、IVF 等近似最近鄰演算法,在百萬級資料中做到毫秒級檢索
- 切塊策略是 RAG 品質的天花板,常見做法是 300-500 token 一塊、保留一到兩成重疊
- 檢索流程分索引、檢索、增強、生成四階段,RAG 失敗七成以上出在檢索階段而非生成階段
- 混合檢索(向量 + 關鍵字 BM25)彌補純語意檢索對專有名詞不敏感的缺陷
- 重排序(re-ranking)用 cross-encoder 對候選片段二次精選,能顯著提升最終檢索品質
✍️ 實踐
- 挑一份自己的長文件(筆記、報告、規格書),手動切成 300-500 字的區塊,標記每塊的來源標題,體會切塊時「保留脈絡」的難度
- 用免費的嵌入 API(如 OpenAI text-embedding 或開源模型)把切好的區塊轉成向量,存進本地的 FAISS 或 Chroma 做一次最小可行的向量檢索實驗
- 設計三個容易觸發幻覺的問題(答案不在知識庫裡),測試系統是否會誠實回答「找不到相關資料」而不是硬掰
- 試著在提示詞裡加入「請只根據提供的資料回答,並標註引用出處」這類指令,比較加入前後的答案品質差異
- 找一個包含專有名詞或型號的檢索案例,比較純向量檢索與加入關鍵字比對的混合檢索,結果排序有何不同
🔗 延伸學習
- Contextual Retrieval in AI Systems(Anthropic 官方工程部落格)
- Build a RAG agent with LangChain(LangChain 官方文件)
- Retrieval-Augmented Generation(Pinecone Learn)
- Rerankers and Two-Stage Retrieval(Pinecone Learn)
💬 問 AI
請幫我設計一個最小可行的 RAG 系統架構,情境是:我有一批中文的內部文件(約 200 份 PDF/Markdown 混合),想讓聊天機器人根據這些文件回答員工問題。請針對以下幾點給我具體建議:
1. 嵌入模型該選哪一個(需支援中文),以及理由
2. 切塊大小與重疊比例的建議,並說明依據
3. 是否需要導入混合檢索(向量+關鍵字)與重排序,什麼情況下值得加
4. 如何設計提示詞,讓模型在資料不足時誠實承認不知道、並附上引用來源
請用條列方式回答,並指出常見的踩坑點。