M05.14｜RAG 進階：Chunking 優化、增量更新與混合搜尋
RAG 不是把文件丟進去就好——切得好不好、搜得準不準，決定 AI 答得對不對
本講學習重點
RAG 的優勢（vs Fine-tuning）： 1. 成本低：不需要 GPU 訓練，只需要建立向量索引 2. 即時性：新文件加入後立即可搜，不需要重新訓練 3. 可追溯：每個回答都能附上來源文件，可驗證、可審計 Chunking 策略比較： - 固定長度切分：簡單（每 500 字切一段），但可能在句子中間切斷 - 語義切分：用 NLP 偵測主題邊界，在段落/章節交界處切分。品質最好但成本最高 - 遞迴切分：先試著在段落邊界切 → 太長則在句子邊界切 → 還是太長在固定長度切 - 比喻：把教科書切成筆記卡 — 切太大找不到重點，切太小失去上下文 Chunk size 選擇： - 太大（>1000 tokens）：包含太多不相關內容，稀釋了重點 - 太小（<100 tokens）：失去上下文，AI 看到片段無法理解意思 - 建議：200-500 tokens，搭配 50-100 tokens 的 overlap（重疊） Embedding 模型選擇： - 通用模型：OpenAI text-embedding-3、Cohere embed、BGE - 領域特化：法律、醫療等專業領域可用微調後的 Embedding 模型 - 多語言：選擇支援中文的 Embedding（如 BGE-M3、multilingual-e5） 混合搜尋 (Hybrid Search)： - 向量搜尋擅長語義相似（「如何提升效能」能匹配「加速程式執行」） - 關鍵字搜尋（BM25）擅長精確匹配（搜「ISO 27001」就是要找這個詞） - 混合搜尋：兩者結合，取各自的優勢 - 權重通常：向量 0.7 + 關鍵字 0.3（可根據場景調整） 增量更新： - 問題：傳統做法每次文件更新都重建整個向量索引，耗時且浪費 - 解法：只對新增/修改的文件做 Embedding 並加入索引，刪除的文件從索引移除 - 技術：文件指紋（hash）追蹤哪些文件已變更 Re-ranking（重排序）： - 第一階段：向量搜尋快速找出 top 50-100 候選 - 第二階段：用更精確的 Cross-encoder 模型對候選重新排序 - 效果：大幅提升最終 top 5-10 結果的精確度 - 比喻：先用 Google 搜出 100 個結果，再請專家挑出最相關的 5 個 RAG 品質排查（iPAS 考古題重點）： - 品質波動時的排查順序：先查檢索 → 再查生成 - 檢查檢索：搜尋結果和問題相關嗎？Chunk 切得合理嗎？ - 檢查生成：給了正確資料後 AI 回答正確嗎？ - 原則：garbage in → garbage out，檢索品質是 RAG 的第一瓶頸
🎙️ Podcast（中文）
一句話搞懂
RAG 的關鍵不只是「讓 AI 能查資料」，更在於「怎麼切文件」（Chunking）、「怎麼搜得準」（混合搜尋 + Re-ranking）、以及「怎麼維護索引」（增量更新）——這三個環節的品質，直接決定 AI 回答的正確率。
白話解說
快速複習：RAG 為什麼重要
RAG（Retrieval-Augmented Generation，檢索增強生成）的核心概念在前面的課程中已經介紹過：AI 在回答問題之前，先從你的資料庫中搜尋相關資訊，把搜到的資訊和問題一起送給 LLM，讓 LLM 基於真實資料回答，而不是全靠記憶力。
為什麼 RAG 在 2025-2026 年成為企業 AI 應用的主流架構？因為它完美解決了三個痛點：
第一，成本低。Fine-tuning（微調）需要 GPU 算力訓練模型，動輒數萬到數十萬元。RAG 只需要把文件做 Embedding（向量化）存入向量資料庫，成本是 Fine-tuning 的百分之一。
第二，即時性。Fine-tuning 後的模型是「凍結」的——新資料要再次訓練才能學會。RAG 的資料庫可以隨時更新——今天發布的新規定，今天就能被 AI 查到並引用。
第三，可追溯。RAG 的每個回答都能附上「我是從哪份文件的哪個段落找到這個資訊的」，使用者可以點開原始文件驗證。這在法律、醫療、金融等需要問責的領域至關重要。Fine-tuning 的模型是黑箱——它回答了一個數字，你不知道它是從哪裡學的。
這三個優勢讓 RAG 在大多數企業場景中都比 Fine-tuning 更實用。但 RAG 的效果好不好，取決於三個環節：切（Chunking）→ 搜（Retrieval）→ 答（Generation）。今天我們深入探討前兩個環節的進階技巧。
Chunking 策略：切文件是一門藝術
RAG 的第一步是把大量文件「切」成小塊（Chunk），然後對每個小塊做 Embedding 存入向量資料庫。切的策略直接影響搜尋品質。
比喻：想像你要準備考試，把教科書切成筆記卡。切太大（一整章放一張卡）——搜尋時找到這張卡，裡面有 10 頁內容，你要從中找到真正相關的那兩段話，太不精確了。切太小（每句話一張卡）——搜到一張卡上面寫著「因此可以得出結論」，但脫離了前後文，你完全不知道它在說什麼。好的切法是切在段落或主題的邊界，每張卡包含一個完整的概念。
三種主流的 Chunking 策略：
固定長度切分。最簡單：每 500 個字（或 token）切一段。優點是實作極簡、速度快。缺點是它不管內容——可能在句子中間切斷（「台積電在 2025 年的營收達到」/「了 2.8 兆元新高」，一個完整的事實被切成兩半）。適合格式統一、段落結構清晰的文件（如 FAQ 列表）。
語義切分。用 NLP 技術偵測文本的主題變化，在主題切換的地方切分。比如用 Embedding 計算相鄰段落的相似度，當相似度突然下降時，代表話題轉換了，就在那裡切。優點是每個 Chunk 都包含一個完整的語義單元，品質最好。缺點是計算成本高——需要先對整份文件做 Embedding 計算，切分速度比固定長度慢得多。
遞迴切分（也叫 hierarchical splitting）。這是目前最常被推薦的策略，LangChain 等主流框架的預設做法。它的邏輯是：先嘗試在大的邊界切（章節標題），如果 Chunk 還是太大，就在次級邊界切（段落），如果還太大，在句子邊界切，最後才用固定長度兜底。這保證了盡可能在自然邊界切分，又不會產生過大的 Chunk。
Chunk Size 的選擇：業界的經驗法則是 200-500 tokens，搭配 50-100 tokens 的 overlap（相鄰 Chunk 之間有重疊的部分）。Overlap 的目的是避免「資訊恰好在切割邊界上」的情況——如果一個事實被切在兩個 Chunk 的交界處，overlap 確保至少有一個 Chunk 包含完整的事實。
Embedding 模型：把文字變成「位置」
Chunk 切好之後，需要把每個 Chunk 轉換成向量（一串數字），存入向量資料庫。這個轉換過程叫做 Embedding。
Embedding 模型的品質直接影響搜尋品質。好的 Embedding 模型能把語義相近的文字映射到向量空間中接近的位置——「如何提升系統效能」和「加速程式執行的方法」應該在向量空間中很近，即使它們的用字完全不同。
通用 Embedding 模型：OpenAI 的 text-embedding-3、Cohere 的 embed-v3、開源的 BGE 系列。這些在大多數場景下效果都不錯。
中文支援：如果你的資料主要是中文，選擇多語言 Embedding 模型很重要。BGE-M3（BAAI）和 multilingual-e5 是目前中文表現最好的開源選項。用只懂英文的 Embedding 處理中文資料，搜尋品質會大幅下降。
領域特化：在法律、醫療等專業領域，通用 Embedding 可能不認識專有名詞（如法律條號、藥品名稱），導致搜尋品質不佳。可以用領域文件對 Embedding 模型做微調，讓它更懂你的專業術語。
混合搜尋：兩種搜尋的最佳結合
向量搜尋有一個經常被忽略的弱點：它擅長「語義相似」，但不擅長「精確匹配」。
比如使用者搜尋「ISO 27001 條文 6.1.2 的要求」，他要的就是這個特定條號的內容。向量搜尋可能會回傳一堆「和資訊安全管理相關的內容」，因為它理解了語義（資訊安全），但沒有精確匹配到「ISO 27001」和「6.1.2」這些特定標識符。
反過來，傳統的關鍵字搜尋（如 BM25 演算法）擅長精確匹配——搜「ISO 27001」就是找包含這幾個字的文件。但它不懂語義——搜「如何保護公司資料安全」找不到一篇標題是「企業資訊防護最佳實踐」的文章，因為用字完全不同。
混合搜尋（Hybrid Search）：同時用向量搜尋和關鍵字搜尋，然後合併結果。通常的權重分配是向量 0.7 + 關鍵字 0.3（可根據場景調整——如果你的使用者經常用精確術語搜尋，可以提高關鍵字的權重）。
主流的向量資料庫（Weaviate、Qdrant、Milvus、Pinecone）都已原生支援混合搜尋，不需要自己實作合併邏輯。Elasticsearch 也從 8.x 版本開始支援向量搜尋，可以把它當作混合搜尋引擎使用。
增量更新：不用每次都重建整個索引
iPAS 考古題曾考過一個經典場景：某公司的 RAG 系統「每次更新文件都需要完整重建索引，花費數小時」，問解決方案是什麼？
答案是增量更新。核心概念很直觀：只對「新增或修改的文件」做 Embedding 並加入索引，「已刪除的文件」從索引移除，「沒有變動的文件」不需要動。
實作方式：為每份文件計算一個指紋（hash），記錄在資料庫中。每次更新時，比對新舊 hash：hash 不同的代表文件已修改，需要重新 Embedding；新出現的 hash 代表新文件，需要 Embedding 後加入；消失的 hash 代表文件已刪除，從索引中移除。
這把更新時間從「整個資料庫的 Embedding 時間」降低到「只有變動部分的 Embedding 時間」，在文件量大（數萬到數十萬份）的企業場景中，差異可以是從數小時降到數分鐘。
Re-ranking：搜尋後的「二次面試」
向量搜尋的速度快（毫秒級回傳結果），但精確度有限。Re-ranking 是一個兩階段的搜尋策略：
第一階段（召回）：向量搜尋快速找出 top 50-100 個候選 Chunk。這一步追求的是「不要漏掉相關的」（高召回率），精確度可以差一點。
第二階段（精排）：用一個更精確但更慢的 Cross-encoder 模型，對這 50-100 個候選重新打分排序，取 top 5-10 作為最終結果。Cross-encoder 會把「查詢」和「候選 Chunk」一起輸入模型做比較，能更準確地判斷相關度。
比喻：公司招聘時，HR 先從 100 份履歷中快速篩出 20 份（第一階段），然後用人主管仔細面試這 20 人（第二階段），最終錄取 3 人。第一階段要快、不要漏人；第二階段要準、選最適合的。
常用的 Re-ranking 模型：Cohere Rerank、BGE-Reranker、FlashRank（輕量開源方案）。加入 Re-ranking 通常能讓最終結果的精確度提升 10-20%，尤其在資料量大、Chunk 數量多的場景中效果更明顯。
RAG 品質排查：先查搜尋，再查生成
當你的 RAG 系統回答品質不穩定時，應該怎麼排查？iPAS 考古題中明確考過這個概念：先檢查檢索品質，再檢查生成品質。
邏輯很簡單：如果搜尋端就沒找到正確的資訊，生成端再強也沒用——garbage in, garbage out。
排查步驟：
第一步，檢查檢索結果。把使用者的問題拿去搜尋，看回來的 top 5 Chunk 是否真的包含回答問題所需的資訊。如果不包含，問題在搜尋端：可能是 Chunk 切得不好、Embedding 品質差、或搜尋策略需要調整。
第二步，如果搜尋結果是正確的，但 AI 的回答仍然不對，那問題在生成端：可能是 Prompt 設計不好（沒有告訴 AI「根據以下資料回答」）、上下文太長導致 AI 遺漏關鍵資訊、或模型本身的能力不足。
第三步，如果搜尋和生成都沒問題，但使用者仍然不滿意，可能是 Chunk 的顆粒度問題——搜到的是大概正確的段落，但使用者需要的是更精確的句子級資訊。這時需要調整 Chunk size 或加入 Re-ranking。
應用場景
| 技術 | 適用場景 | 效果 |
|---|---|---|
| 語義切分 | 長篇報告、法律文件（段落結構重要） | Chunk 品質最高，搜尋精確度 +15% |
| 遞迴切分 | 通用場景（結構不明確的混合文件） | 平衡品質和速度，最常被推薦 |
| 混合搜尋 | 技術文件（含大量專有名詞和編號） | 比純向量搜尋精確度 +10-20% |
| 增量更新 | 大型知識庫（數萬份文件，頻繁更新） | 更新時間從數小時降到數分鐘 |
| Re-ranking | 高精度需求場景（法律、醫療、金融） | top-5 精確度 +10-20% |
| 中文 Embedding | 中文為主的資料庫 | 比英文 Embedding 處理中文品質 +30% |
常見誤區
誤區一：RAG 解決了所有幻覺問題
RAG 大幅減少了幻覺（因為 AI 有了真實資料可以參考），但沒有完全消除。幻覺仍然可能發生在三種情況：(1) 搜尋沒找到相關資料，AI 退而求其次用自己的「記憶」回答（仍可能編造）；(2) 搜到的資料有多個矛盾的來源，AI 選擇了錯誤的那個；(3) AI 正確找到了資料，但在整合和改述時引入了微妙的錯誤（如數字寫錯、因果關係搞反）。因此，即使有 RAG，對於高風險決策仍需人工審核 AI 的回答。
誤區二：Chunk size 越小越好
直覺上，越小的 Chunk 搜尋精確度越高——因為每個 Chunk 只包含一個非常具體的資訊點。但太小的 Chunk（少於 100 tokens）會失去上下文：「因此，合約自動終止」這句話在沒有前文的情況下毫無意義——什麼合約？什麼條件下？自動終止後會怎樣？AI 看到這個 Chunk 也無法給出有意義的回答。最佳 Chunk size 是在「夠小以便精確搜尋」和「夠大以保持上下文」之間找到平衡，通常是 200-500 tokens。
誤區三：只要用向量搜尋就夠了
純向量搜尋在「語義理解」上很強，但在「精確匹配」上有盲點。當使用者搜尋特定的編號（「ISO 27001」）、人名（「張三」）、日期（「2025-12-31」）、或技術術語時，向量搜尋可能會回傳語義相關但不包含這些精確詞彙的結果。混合搜尋（向量 + 關鍵字）能同時照顧語義和精確匹配，這就是為什麼幾乎所有生產級的 RAG 系統都採用混合搜尋而非純向量搜尋。
小練習
練習一：Chunking 策略選擇
你需要為以下三種文件建立 RAG 系統，請為每種文件選擇最適合的 Chunking 策略，並說明理由：
- (A) 公司的 FAQ 頁面（500 組問答，每組問答約 50-200 字）
- (B) 一份 200 頁的法律合約
- (C) 一個混合了技術文件、會議記錄和電子郵件的知識庫
點擊查看參考答案
練習一：Chunking 策略選擇
- **(A) FAQ 頁面 → 固定長度切分（或直接以每組 Q&A 為一個 Chunk）**。FAQ 的結構天然就是「一問一答」，每組問答就是一個完整的語義單元。最好的做法是直接把每組 Q&A 作為一個 Chunk，不需要額外切分。如果某些答案特別長，再用固定長度切分即可。 - **(B) 法律合約 → 語義切分**。法律文件的段落結構非常重要——每個條款、每個子條款都有獨立的法律含義，切錯位置可能把一個條款的條件和結論拆到不同的 Chunk 中，導致搜尋時只找到結論、找不到條件，造成嚴重的理解偏差。語義切分能在條款邊界處切割，保持每個法律條文的完整性。 - **(C) 混合知識庫 → 遞迴切分**。文件類型混雜、格式不統一，沒有單一的切分策略能適用所有文件。遞迴切分的自適應特性——先嘗試大邊界（章節），再嘗試中邊界（段落），最後用固定長度兜底——能在不同格式的文件上都產出合理的 Chunk。搭配 200-500 tokens 的 Chunk size 和 100 tokens 的 overlap。練習二：RAG 品質排查
一家公司的 RAG 客服系統最近出現了以下問題。請判斷每個問題最可能的根因是在「切分」「搜尋」還是「生成」環節，並提出改善建議：
- (A) 客戶問「退貨需要幾天？」，AI 回答了退貨流程但沒提到天數
- (B) 客戶問「iPhone 15 的保固政策」，AI 回答的是 iPhone 14 的保固
- (C) 客戶問「你們的營業時間是幾點到幾點？」，AI 回答「根據我們的資料，營業時間為週一至週五 9:00-18:00」，但公司最近改成了 8:30-17:30