昨天談模型壓縮,把大模型蒸餾、量化到能落地部署;但無論你把模型訓練、對齊、壓縮得多好,它的知識都停在訓練截止那一刻,會對不知道的事一本正經地編造,更完全不認得你公司內部那份 PDF。檢索增強生成(Retrieval-Augmented Generation,RAG)就是補這個洞:在模型生成答案之前,先去一個外部知識庫把相關的真實文件撈出來,塞進 prompt,讓模型「看著資料回答」,而不是「憑記憶硬掰」。今天把 RAG 這條從嵌入、檢索、重排到生成的完整管線拆開來講清楚。
📖 學
為什麼需要 RAG:三個模型本身治不好的病
RAG 要解決的是大型語言模型三個結構性缺陷:知識截止、幻覺、以及對私有資料的無知。模型的參數是訓練當下對世界的一份靜態快照,截止日之後發生的事它一無所知;遇到不確定的問題,它傾向流暢地產生看似合理卻查無此事的內容,也就是幻覺;而你公司的合約、產品手冊、客服紀錄從來不在它的訓練資料裡,它自然答不出來。重新訓練或微調可以塞進一些知識,但成本高、更新慢,而且無法即時反映昨天才進來的新文件。RAG 換一條路:知識不放進參數,而是放在一個可以隨時增刪的外部資料庫,生成時即時檢索、即時餵給模型。這樣更新知識只要更新資料庫,不必動模型一根寒毛。
嵌入與語意檢索:讓機器用「意思」找資料
RAG 檢索的核心是嵌入向量(embeddings),它把一段文字轉成一串幾百到幾千維的數字,讓語意相近的文字在向量空間裡距離也相近。傳統關鍵字搜尋(如 BM25)找的是「字面相同」,你搜「如何退款」就找不到寫著「退貨流程與款項返還」的段落;而嵌入做的是「意思相近」,即使用詞完全不同,只要語意接近,向量距離就近。做法是先用一個嵌入模型(如 OpenAI 的 text-embedding-3、或開源的 e5、bge 系列)把知識庫每個文字片段都轉成向量存起來;查詢時把使用者問題也轉成向量,再算它和庫裡每個向量的相似度(常用餘弦相似度),取最接近的幾段。這種「用意思找資料」的能力,是 RAG 能撈到對的內容的前提。
向量資料庫與 ANN:上億筆向量怎麼秒查
當知識庫大到上百萬、上億筆向量時,逐一比對相似度會慢到不可用,這就是向量資料庫與近似最近鄰(Approximate Nearest Neighbor,ANN)登場的原因。精確算出查詢向量對每一筆的距離叫暴力搜尋,複雜度隨資料量線性上升;ANN 演算法(如 HNSW 分層小世界圖、IVF 倒排索引)則用「犧牲一點點準確度換取巨大速度」的策略,建立索引結構讓查詢只需比對一小部分候選,就能在毫秒級找到「幾乎最近」的結果。Pinecone、Weaviate、Qdrant、Milvus 這類向量資料庫把 ANN 索引、中繼資料過濾(metadata filtering)、擴充與持久化都封裝好,你只要丟向量進去、給查詢向量,它回傳 top-k 相似片段。中繼資料過濾也很關鍵:你可以要求「只在 2025 年後、且部門=法務的文件裡檢索」,兼顧語意與結構化條件。
Chunking:切塊切得好不好,幾乎決定成敗
文件切塊(chunking)是把長文件切成一段一段再做嵌入,而這一步的品質,往往比你選哪個嵌入模型影響更大。原因有二:嵌入模型有輸入長度上限,太長的文件塞不進去;而且一段話若混雜太多主題,它的向量會變成各主題的「平均」,語意模糊到誰都對不準。但切太碎又會切斷語意——把一個完整論述從中間剖開,檢索到的片段殘缺不全,模型看了也拼不出答案。實務上常用的策略包括:固定長度切塊(如每 500 token)、帶重疊(overlap)切塊(相鄰塊共享一段文字,避免邊界資訊斷裂)、以及依語意結構切塊(按段落、標題、Markdown 章節切,讓每塊是完整語意單位)。「chunk 越大越好」是迷思:太大會稀釋語意、拉高後續 context 成本;合理做法是依文件型態與問答粒度實測,常見落在 200 到 800 token,再配 10% 到 20% 重疊。
Reranking:檢索的第一關寬進,第二關嚴出
檢索後重排(reranking)是在向量檢索撈出候選之後,再用一個更精細的模型重新排序,把真正最相關的頂到最前面。為什麼需要兩階段?向量檢索為了快,用的是「查詢向量」和「文件向量」各自獨立算好再比距離(bi-encoder),速度快但精度有限,常會把「看起來像、其實不對」的片段也撈進來。Reranker 通常是 cross-encoder,把查詢和每個候選片段「一起」餵進模型深度比對,精度高但慢,所以不適合掃全庫——正好接在向量檢索後面,對它撈出的 20 到 50 個候選做精排,取最終 top-5。這個「向量檢索寬進、reranker 嚴出」的兩段式設計,是現代 RAG 拉高檢索品質最有效的一招,實測常能明顯改善答案準確度。
組 prompt 生成:把檢索到的內容接進答案
檢索到對的片段之後,最後一步是把它們組進 prompt 交給模型生成答案,而怎麼組,決定模型會不會乖乖依據資料回答。典型做法是設計一個 prompt 模板:系統指令告訴模型「只根據以下提供的資料回答,若資料中沒有答案就說不知道,不要編造」,接著填入檢索到的片段(通常附上來源標記),最後放使用者問題。這種在 prompt 裡臨時提供知識、讓模型當場學會的方式,就是脈絡內學習(in-context learning)。好的 prompt 設計還會要求模型引用來源(citation),讓答案可追溯、可查證,這也是 RAG 相較純生成的一大優勢:使用者能點回原始文件確認,不必盲信。
RAG vs 微調:什麼時候用哪個
RAG 和微調(fine-tuning)解決的是不同問題,不是二選一的對立,而是常常搭配使用。簡單的判準是:要補「知識」用 RAG,要改「行為或風格」用微調。當你的需求是讓模型掌握大量、會頻繁更新、且要能追溯來源的事實性知識(產品文件、法規、公司內規),RAG 是首選,因為更新資料庫即可、不需重訓、還能引用出處。當你的需求是讓模型學會某種固定的輸出格式、專業語氣、或特定任務的推理模式(例如永遠輸出特定 JSON、用某種專業口吻),微調更合適,因為那是把行為烙進參數。很多正式系統是兩者並用:微調塑造模型的「講話方式」,RAG 供給即時的「講話內容」。
失敗模式與評估:RAG 不是幻覺的免死金牌
RAG 能大幅緩解幻覺,但「有了 RAG 就不會幻覺」是危險的迷思,它有一整套自己的失敗模式。第一種是檢索不準:如果撈回來的片段根本不相關,模型拿著錯資料照樣自信地答錯,這叫「garbage in, garbage out」。第二種是 context 太長:塞太多片段進 prompt,模型會出現「迷失在中間」(lost in the middle)的現象,忽略掉夾在中段的關鍵資訊,而且拉高成本與延遲。第三種是 chunk 切壞:答案剛好被切在兩塊之間,哪一塊都不完整,檢索再準也拼不出答案。要抓這些問題必須做評估,業界常用 RAGAS 這類框架,它把 RAG 拆成幾個可量化指標:忠實度(faithfulness,答案是否確實有檢索內容支撐,直接衡量幻覺)、答案相關性(answer relevancy)、脈絡精確率(context precision)與脈絡召回率(context recall,衡量檢索這一環撈得準不準、全不全)。把檢索和生成分開評估,你才知道問題出在「撈錯」還是「答錯」,對症下藥。
🧠 記
- RAG 不把知識塞進模型參數,而是生成時去外部知識庫即時檢索、餵進 prompt,藉此緩解知識截止、幻覺與私有資料無知三大問題,且更新知識只需更新資料庫。
- 語意檢索靠嵌入向量:把文字轉成高維向量,語意相近則距離相近,能找到用詞不同但意思相符的片段;大規模時靠向量資料庫的 ANN 索引做毫秒級近似檢索。
- Chunking 品質常比嵌入模型更關鍵;「chunk 越大越好」是迷思,合理策略是依語意結構切、加重疊,常落在 200 到 800 token。
- Reranking 用兩段式設計:向量檢索快而寬地撈候選,再用 cross-encoder reranker 精排嚴選 top-k,是拉高檢索品質最有效的一招。
- RAG 補知識、微調改行為,兩者常搭配:微調塑造講話方式,RAG 供給即時內容。
- 「有 RAG 就不會幻覺」是迷思;檢索不準、context 太長(lost in the middle)、chunk 切壞都會壞事,要用 RAGAS 等指標(忠實度、脈絡精確/召回率)分開評估檢索與生成。
✍️ 實踐
用一個小知識庫搭一個最小 RAG,親手跑一遍就懂了。給自己 40 分鐘:
- 準備知識庫:找 5 到 10 份你手邊的文件(公司 wiki、產品 FAQ、幾篇筆記皆可),轉成純文字。
- 切塊:用固定長度切塊(每塊約 500 token、重疊 50 token)先跑最簡版;有餘力再改成按段落/標題切,對比檢索品質差異。
- 嵌入與入庫:用一個嵌入模型(OpenAI text-embedding-3-small 或開源 bge-small 皆可)把每塊轉成向量,存進一個向量庫(本機可用 Chroma 或 FAISS,免安裝雲端)。
- 檢索 + 組 prompt:把使用者問題嵌入,取 top-5 相似塊,套進模板「只根據以下資料回答,沒有就說不知道:{塊}\n\n問題:{query}」,交給 LLM 生成。
- 刻意製造失敗:問一個知識庫裡「沒有答案」的問題,看模型會不會誠實說不知道還是硬掰;再把 top-k 從 5 拉到 30,感受 context 變長後答案是否反而變差。
- 加一道 reranker:接一個 cross-encoder(如 bge-reranker)對 top-20 精排取 top-5,對比加不加 reranker 的答案差異。
跑完你會親身體會:同一份資料,切法不同、有沒有重排,答案品質天差地別。
🔗 延伸學習
- Retrieval-Augmented Generation (RAG) — Pinecone Learn:向量資料庫官方的 RAG 入門,把檢索與生成如何接起來講得很清楚。
- Chunking Strategies for LLM Applications — Pinecone:專講切塊策略與取捨,實務上最容易被忽略卻最影響成效的一環。
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks(Lewis et al., 2020)— arXiv:RAG 這個詞的原始論文,提出參數記憶+非參數(外部檢索)記憶結合的架構。
- Build a RAG app — LangChain 官方教學:從零用 LangChain 搭一個 RAG 應用的官方逐步教學,含載入、切塊、檢索、生成完整流程。
💬 問 AI
想真正搞懂 RAG,最好的方式是拿你自己的資料去問、去拆解每個環節的取捨。把下面提示詞丟給 AI,讓它當你的 RAG 架構顧問:
我想為「[描述你的知識庫,例如:一份 200 頁的產品手冊 + 客服對話紀錄]」
搭一套 RAG 系統,使用者會問的問題類型是「[例如:操作步驟、規格查詢]」。
請幫我:
1. 針對這種文件與問題,建議 chunking 策略(切塊大小、重疊、是否按結構切)並說明理由
2. 推薦嵌入模型與向量資料庫選型,說明取捨
3. 判斷我這個場景需不需要 reranking,為什麼
4. 給我一個「只依據檢索內容回答、沒有就說不知道、並標註來源」的 prompt 模板
5. 列出這個場景最可能出現的 3 種失敗模式,以及我該用哪些 RAGAS 指標去監控
最後請提醒我:哪些狀況下 RAG 其實不夠,應該改用或搭配微調。