劣質分塊毒害RAG回答：分塊品質除錯指南

每一次RAG除錯最終都會到達同一個地方：你檢查檢索到的分塊，然後意識到問題不在檢索，不在LLM，也不在提示詞。分塊本身就是垃圾。分塊管線忠實地將你的文件分割成了碎片，而這些碎片是不連貫的、不完整的或具有誤導性的。

分塊就是RAG中「垃圾進，垃圾出」的環節。如果分塊品質差，下游的一切都會變差——嵌入編碼了錯誤的語義，檢索回傳了錯誤的上下文，LLM生成了錯誤的答案。再多的提示詞工程或重排序都無法修復根本性的分塊缺陷。

本文彙整了最常見的分塊故障，展示了劣質分塊的真實樣貌，並為每種故障提供了實用的修復方法。

劣質分塊模式1：句中斷裂

表現形式：

分塊A以此結束：「本保單的最高賠付限額為」

分塊B以此開始：「每次事故500,000美元，免賠額為2,500美元，適用於2026年1月1日之後提出的所有索賠。」

原因分析： 固定大小分塊（每N個token切分一次）不具備句子邊界感知能力。當一個句子跨越分塊邊界時，兩個分塊都變得單獨無意義。分塊A說明了賠付限額但沒有數字。分塊B提供了數字但缺少它所指代的上下文。

下游損害： 如果使用者問「最高賠付額是多少？」，檢索可能找到分塊A（它包含「賠付」和「最高」這些詞）但找不到分塊B。LLM要麼捏造一個數字，要麼說找不到相關資訊——儘管答案確實存在於語料庫中。

修復方法： 使用句子感知分塊。分塊演算法應當尊重句子邊界，確保每個分塊都在完整句子處開始和結束。在分塊之間添加10-15%的重疊，使邊界句子同時出現在兩個相鄰分塊中。

劣質分塊模式2：孤立上下文

表現形式：

分塊：「利率為4.5%。對於超過閾值的帳戶，將額外收取1.2%的附加費。例外情況列於附錄C。」

缺失的內容： 什麼利率？什麼閾值？什麼類型的帳戶？這個分塊語法上是完整的，但語義上是孤立的——它包含了具體細節，卻缺少使這些細節可以被理解的框架上下文。

原因分析： 分塊策略按章節或標題分割，但該章節本身是一個子章節，需要依賴父章節才能獲得上下文。來自「第3.2.1節：費率表」的分塊，如果不知道第3.2節講的是「商業貸款產品」、第3節講的是「企業銀行業務」，就毫無意義。

下游損害： LLM收到這個分塊後必須猜測「利率」和「閾值」指的是什麼。它要麼猜錯（幻覺），要麼用模糊的答案搪塞。無論哪種情況，使用者都得到了無用的回答。

修復方法： 在每個分塊前添加層級上下文。如果一個分塊來自第3.2.1節，分塊文字應當以「企業銀行業務 - 商業貸款產品 - 費率表：」開頭，然後才是分塊內容。這為LLM提供了解讀具體細節所需的框架。一些團隊將此稱為「上下文分塊」或「麵包屑分塊」。

劣質分塊模式3：表格碎片化

表現形式：

分塊A：「| 方案 | 月費 | 儲存空間 |」

分塊B：「| --- | --- | --- | | 免費版 | $0 | 5 GB | | Builder | $34.50 | 50 GB |」

分塊C：「| Agency | $149 | 200 GB | | Agency Pro | $349 | 500 GB |」

原因分析： 表格是固定大小分塊的最壞場景。表頭列落在一個分塊中，前幾列資料在另一個分塊中，剩餘列在第三個分塊中。每個分塊單獨來看都沒有用處——表頭沒有資料，資料沒有表頭，而且一個表格被分成兩個分塊，完全看不出它們屬於同一個表格。

下游損害： 使用者問「Agency方案要多少錢？」，檢索回傳分塊C，其中包含答案但沒有欄位標題。LLM看到「$149」和「200 GB」，但如果沒有表頭列就無法判斷哪個數字是價格、哪個是儲存限額。

修復方法： 在解析過程中偵測表格，並將每個表格作為原子單元處理。如果表格超過分塊大小限制，在每個分塊頂部重複表頭列。如果你的文件包含單個分塊放不下的大表格，在分塊之前將複雜表格轉換為結構化文字（鍵值對或散文描述）。

劣質分塊模式4：重疊冗餘

表現形式：

分塊A（token 0-500）：「我們的隱私政策確保個人資料按照GDPR要求進行處理。資料主體有權存取...」

分塊B（token 400-900）：「...有權存取、更正和刪除其個人資料。資料主體有權存取其資料並隨時請求更正。我們的隱私政策確保個人資料按照...」

原因分析： 過度的分塊重疊（40-50%或更多）導致大量文字在相鄰分塊之間重複。重疊設定得過於激進，可能是為了解決句中斷裂的問題。

下游損害： 檢索回傳多個包含幾乎相同資訊的分塊，浪費了上下文視窗空間。LLM可能在回答中自我重複，或者更糟糕的是，將冗餘的提及視為佐證並表達出超出合理範圍的信心。

修復方法： 將重疊保持在分塊大小的10-20%之間。重疊的目的是保留邊界上下文，而不是複製整個段落。如果你使用的重疊超過25%，你很可能是在彌補分塊粒度問題——應該修正粒度而不是增加更多重疊。

劣質分塊模式5：中繼資料-內容混雜

表現形式：

分塊：「最後更新：2024-03-15 | 作者：J. Smith | 部門：法務 | 版本：3.2 | 狀態：已核准 | 審核日期：2025-03-15 | 第7節中的賠償條款要求承包商維持不低於...」

原因分析： 文件解析器提取頁面上的所有內容，包括中繼資料標頭、文件屬性和管理資訊。分塊管線不區分文件中繼資料和文件內容。

下游損害： 中繼資料token佔據了分塊空間卻不貢獻語義價值。嵌入將中繼資料雜訊與實際內容一起編碼，降低了嵌入的表徵品質。檢索可能匹配到中繼資料術語（「作者：J. Smith」）而不是內容相關性。

修復方法： 在解析過程中將中繼資料提取與內容提取分離。將中繼資料作為結構化欄位儲存在分塊的中繼資料中（在向量儲存中可過濾），而不是嵌入到分塊文字中。如果中繼資料對檢索有用，將其作為單獨的中繼資料欄位添加，而不是作為嵌入文字的一部分。

劣質分塊模式6：多主題分塊

表現形式：

分塊：「員工每個日曆年有權享受20天帶薪休假。未使用的PTO不結轉。另外，公司節日聚會將於12月15日在市中心萬豪酒店舉行。請在12月1日前回覆確認出席。此外，IT部門提醒全體員工每90天必須進行一次密碼輪換。」

原因分析： 來源文件（員工通訊、會議記錄、Slack匯出）按順序包含多個不相關的主題。固定大小分塊將它們歸入一個分塊，僅僅因為它們在文字中恰好相鄰。

下游損害： 這個分塊的嵌入是三個不相關主題的平均值——PTO政策、聚會後勤和IT安全。對於這三個主題中任何一個的特定查詢，它都不會是好的匹配結果。關於PTO政策的查詢可能檢索不到這個分塊，因為嵌入被聚會和密碼內容稀釋了。

修復方法： 對非結構化或多主題文件使用主題感知分塊。主題分割演算法可以偵測文件內的主題邊界並相應地分割分塊。對於結構化文件，按章節標題進行分塊。對於非結構化文字（會議記錄、聊天記錄），考慮在分塊之前使用LLM插入主題邊界。

如何稽核你的分塊

在除錯檢索之前，先除錯你的分塊。以下是一個實用的稽核流程：

第1步：隨機抽樣。 從你的向量儲存中隨機抽取50個分塊。像一個從未見過來源文件的人一樣閱讀每一個。你能理解每個分塊講的是什麼嗎？它包含一個完整的想法嗎？

第2步：測試邊界分塊。 找到在句中開始或結束的分塊。計算它們的數量。如果超過10%的分塊存在斷裂的邊界，你的分塊策略需要修訂。

第3步：檢查孤立分塊。 識別引用了「上述」、「如前所述」、「本節」或類似相對引用但引用對象不存在於分塊中的分塊。這些是孤立的分塊，會讓LLM困惑。

第4步：測量冗餘度。 比較相鄰分塊。如果超過30%的內容重疊，你的重疊設定過於激進。

第5步：檢查表格和列表。 找到包含不完整表格（沒有表頭的資料）或不完整列表（沒有列表介紹的條目）的分塊。這些需要原子化分塊。

第6步：查找中繼資料混雜。 找到超過20%文字是文件中繼資料而非內容的分塊。這些需要解析器層面的修復。

建構更好的分塊管線

劣質分塊的根本原因幾乎總是一個選擇了一次就再也沒有回顧過的分塊策略。團隊從LangChain教學中選擇「遞迴字元文字分割器，1000個token，200重疊」，部署上線，然後從不查看它實際產生的分塊。

分塊不是一個設定參數。它是一個資料品質決策，直接決定了你的RAG管線回答品質的上限。沒有任何下游技術——重排序、提示詞工程、更大的上下文視窗——能夠彌補不包含連貫完整資訊的分塊。

Ertas Data Suite包含一個專用的RAG Chunker節點，讓你可以設定分塊策略，在畫布上直觀檢查輸出分塊，並在分塊到達嵌入階段之前迭代調整參數。當你能看到你的分塊——真正地逐個閱讀它們——你就能在垃圾進入向量儲存之前發現它。當分塊只是埋在Python腳本中的一個函式呼叫時，沒有人會去看輸出。

審視你的分塊。閱讀它們。如果它們對你來說沒有意義，對LLM來說也不會有意義。