RAG 分塊策略：分塊大小、重疊和邊界偵測如何影響檢索品質

大多數建構 RAG 管線的團隊將時間花在最佳化嵌入模型、向量資料庫和提示範本上。他們將分塊視為一個細節——將文件分成片段、產生嵌入、繼續前進。這是一個錯誤。分塊是影響檢索品質最大的單一變數，做錯了會串聯影響每一個下游步驟。

糟糕的 RAG 分塊策略會產生過於通用而無法匹配特定查詢的嵌入，或者過於碎片化而無法攜帶有用上下文的嵌入。檢索器回傳不相關的段落。生成器產生幻覺或模稜兩可。使用者失去信任。修復方案很少是更好的模型——而是更好的分塊。

為什麼分塊比你想像的更重要

當使用者查詢 RAG 系統時，檢索器搜尋與查詢語義最相似的分塊。如果你的分塊每個有 4,000 個 token，嵌入代表的是該區塊中所有內容的平均值。具體細節被稀釋了。關於特定合規條款的問題回傳一個包含三頁不相關政策語言的分塊，模型不得不在其中尋找被埋藏的相關句子。

如果你的分塊每個有 50 個 token，你會得到相反的問題。嵌入擷取的是沒有周圍上下文的句子片段。檢索器可能找到正確的片段，但生成器無法從一個被切成兩半的句子中產生連貫的答案。

最好的企業文件 RAG 分塊工具讓你可以控制三個變數：分塊大小、重疊百分比和邊界偵測方法。這三個設定相互影響，正確的組合取決於你的文件類型。

固定大小分塊 vs. 語義分塊

最簡單的方法是固定大小分塊：無論內容結構如何，將每個文件分成 N 個 token 的區塊。這種方法快速、可預測且易於實作。但對於大多數企業用例來說，這也是錯誤的預設選擇。

固定大小分塊完全忽略文件結構。一個 512 token 的視窗可能會將表格一分為二，在句子中間切斷段落，或者將一個章節的結尾與一個不相關章節的開頭合併。結果產生的嵌入是嘈雜的，檢索品質也會受到影響。

語義分塊尊重文件中的自然邊界。它不是在固定的 token 計數處分割，而是在句子邊界、段落分隔或章節標題處分割。分塊大小各不相同，但每個分塊代表一個連貫的語義單元。嵌入更加乾淨，檢索更加精確。

為 RAG 檢索分塊 PDF 的最佳方式幾乎總是帶有最大大小約束的語義分塊。你設定一個上限——比如 512 個 token——分塊器在低於該限制的最近自然邊界處分割。這給你帶來了固定大小分塊的一致性和語義分塊的連貫性。

邊界偵測方法

並非所有邊界都是相同的。正確的邊界偵測方法取決於你的文件結構。

句子邊界在句子結束標點處分割。這是非結構化文字最安全的預設選擇——文章、電子郵件、支援工單、法律文書。每個分塊包含完整的句子，因此嵌入擷取完整的思想。缺點是句子層級的分塊可能非常小，特別是在句子較短的文件中。

段落邊界在雙換行符或顯式段落標記處分割。這適用於格式良好的文件——報告、合約、政策手冊。每個分塊擷取一個完整的想法或論點。段落層級的分塊往往更大、更自包含，這提高了生成器的效能，但代價是檢索精確度略有降低。

章節邊界在標題處分割（HTML 或 Markdown 中的 H1、H2、H3，或 PDF 中偵測到的章節標題）。這是最積極的邊界偵測，最適合高度結構化的文件——技術文件、合規框架、產品手冊。每個分塊對應到文件的一個邏輯章節，這使得檢索結果更容易追溯到其來源。

在實務中，你需要分層邊界偵測：首先嘗試章節邊界，如果章節太大則退回到段落邊界，最後作為兜底退回到句子邊界。這種方法在混合文件類型中產生最一致有用的分塊。

重疊：被忽視的設定

分塊重疊是相鄰分塊之間共享的 token 百分比。如果你有 512 token 的分塊和 10% 的重疊，每個分塊與下一個分塊共享大約 51 個 token。這些共享的 token 出現在兩個嵌入中。

為什麼這很重要？沒有重疊，跨越分塊邊界的資訊就會遺失。一個從 token 510 開始到 token 530 結束的句子被分割到兩個分塊中，兩個分塊都沒有擷取完整的含義。重疊確保跨越邊界的內容至少在一個分塊中以完整形式出現。

代價是儲存和運算。更高的重疊意味著每個文件有更多的分塊，這意味著更多的嵌入需要儲存和更多的候選項需要搜尋。對於大多數企業部署，最佳點在 10% 到 20% 的重疊之間。低於 10%，你會失去太多邊界上下文。高於 20%，你儲存的冗餘資訊收益遞減。

零重疊僅在你的邊界偵測足夠可靠、沒有有意義的內容跨越邊界時才適用——通常是在結構良好的文件上進行章節層級的分塊。

按文件類型的實用設定

下表彙總了常見企業文件類型的建議初始配置。這些是起點——你應該用自己的檢索基準來驗證。

衡量分塊品質

在不衡量影響的情況下配置分塊設定就是猜測。你需要一個回饋循環：變更設定、重新分塊、重新產生嵌入，並在一組測試查詢上評估檢索品質。

重要的指標是檢索精確度（檢索到的分塊中有多少百分比實際相關）、檢索召回率（相關分塊中有多少百分比被檢索到）和答案品質（生成器是否從檢索到的分塊中產生了正確、完整的答案）。

一個常見的失敗模式是僅最佳化精確度。你可以透過使分塊極其大來獲得完美的精確度——每個分塊包含答案，因為每個分塊包含一切。但這浪費了上下文視窗並降低了生成器效能。目標是仍然攜帶足夠上下文讓生成器產生好答案的最小分塊。

Ertas 如何處理分塊

Ertas 的 RAG Chunker 節點讓你直接控制分塊大小、重疊百分比和邊界偵測方法——句子、段落或章節。你可以按管線配置這些設定，這意味著你可以在同一個工作流程中對不同文件類型使用不同的分塊策略。

視覺化管線在每個階段顯示元素計數，因此你可以立即看到將分塊大小從 512 變更為 256 個 token 如何使文件數量翻倍。這種可見性使得在提交配置之前實驗設定並了解其影響變得切實可行。

分塊之後，Quality Scorer 節點透過檢查截斷的句子、過短或過長的分塊以及內容連貫性來驗證分塊品質。這在早期捕獲配置錯誤——在不良分塊傳播到嵌入和索引之前。

入門指南

如果你正在建構 RAG 管線但還沒有花時間在分塊策略上，從這裡開始：

1. 識別你的主要文件類型及其結構特徵。
2. 選擇與你的文件結構匹配的邊界偵測方法。
3. 將分塊大小設定為 512 個 token 作為基線，並根據檢索基準進行調整。
4. 從 15% 的重疊開始，僅在儲存成本是一個問題時才減少。
5. 在代表性查詢集上衡量檢索精確度和召回率。
6. 迭代設定直到檢索品質達到你的閾值。

最佳的 RAG 分塊策略不是一個通用配置——而是一個將分塊設定與文件特徵匹配並用真實查詢驗證的系統化過程。投入這個過程的團隊始終優於將分塊視為事後考量的團隊。