RAG分塊策略基準測試：固定大小 vs 語意 vs 文件感知

分塊是任何RAG管道中影響力最大的決策。做對了，檢索精度提升15到30個百分點。做錯了，再多的提示工程或模型升級都無法彌補。

然而，大多數團隊選擇分塊策略時依據的是部落格文章或所選框架的預設設定，而非經驗資料。本文提供了這些資料。我們在標準化的企業文件語料庫上對五種分塊策略進行了基準測試，並測量了真正重要的指標：檢索精度、延遲、token效率和跨文件類型的穩健性。

五種策略

在展示數據之前，先簡要介紹每種方法。

固定大小分塊將文件分割為預定token數量的塊（通常256-512 tokens），可選重疊。這是最簡單的方法，也是大多數RAG框架的預設設定。每個塊的大小相同，與內容結構無關。

遞迴字元分割使用分隔符階層結構——段落分隔、然後句子邊界、然後單詞邊界——在保持目標塊大小的同時在自然斷點處分割文件。LangChain推廣了這種方法，它仍然是生產系統中最常部署的策略。

語意分塊使用嵌入模型偵測文件內的主題邊界。相鄰句子根據其嵌入的餘弦相似度進行分組，當相似度降至閾值以下時開始新的塊。這產生與連貫主題對應的可變大小塊。

文件感知分塊利用文件結構——標題、章節、表格、清單——來定義塊邊界。一個帶標題的章節成為一個塊。表格保持完整而非在列中間分割。這需要一個理解文件版面而非僅處理原始文字的解析器。

滑動視窗以固定間隔建立重疊塊，每個塊與其相鄰塊共享一定百分比的token（通常20-50%重疊）。這確保沒有資訊落在邊界上，代價是增加索引大小和token使用量。

測試方法

我們從四種企業文件類型建構了基準測試語料庫：

• 合約（50份文件）：多方協議，包含巢狀條款、定義術語和交叉引用
• 技術手冊（50份文件）：結構化文件，包含標題、程式碼區塊、表格和編號程序
• 財務報告（50份文件）：年度報告，包含敘事性章節、資料表、腳註和圖表
• 支援工單（50份文件）：非結構化文字，包含短訊息、時間戳記和混合格式

對於每種文件類型，我們建立了100個基準真值問答對，其中答案存在於特定段落中。檢索精度用Recall@5衡量——正確段落出現在前5個檢索塊中的查詢百分比。

嵌入模型： OpenAI text-embedding-3-large（3072維） 向量儲存： Qdrant with HNSW索引 目標塊大小： 512 tokens（適用時） 重疊： 固定大小和滑動視窗策略使用20%

所有策略在相同硬體（32核CPU、64GB RAM）上使用相同的嵌入模型和向量儲存配置進行測試。

基準測試結果

結果講述了一個清晰的故事。文件感知分塊實現了最高的檢索精度（86.7%），同時也是token效率最高的。語意分塊在精度上接近（83.2%），但由於索引期間基於嵌入的邊界偵測，延遲顯著更高。固定大小分塊儘管是最常見的預設設定，但在檢索精度上排名最後。

按文件類型的結果

彙總數字掩蓋了不同文件類型之間的重要差異。

文件感知分塊在結構化文件（合約、手冊、報告）上佔主導地位，這些文件的標題和章節邊界承載語意含義。然而，它在支援工單上表現不如其他方法——這類非結構化、短文字沒有可靠的文件結構可以利用。對於非結構化內容，語意分塊是最強的選擇。

這是關鍵洞察：最佳分塊策略取決於您的文件組合。主要處理結構化企業文件（合約、報告、手冊）的團隊應預設使用文件感知分塊。處理非結構化或混合格式內容的團隊更受益於語意分塊。

延遲分解

上表中的延遲衡量的是查詢時檢索延遲，而非索引時間。索引延遲差異更為顯著：

語意分塊的索引時間是其他方案的4-5倍，因為它必須對每個句子進行嵌入以偵測主題邊界。對於頻繁重新索引或處理大量文件的管道，這一成本會不斷累積。文件感知分塊需要有能力的文件解析器，但避免了索引期間的嵌入開銷。

Token效率和成本影響

Token效率衡量檢索上下文時每次查詢消耗多少token。滑動視窗1.82倍的開銷意味著與固定大小分塊相比，嵌入和LLM上下文成本幾乎翻倍。

在企業規模（每天10,000次查詢）下，成本差異很有意義：

文件感知分塊不僅精度最高，而且大規模營運成本最低。滑動視窗——經常被推薦為「安全的預設選項」——成本最高，幾乎是文件感知分塊的2倍，而精度更低。

何時使用每種策略

固定大小（512 tokens）： 原型設計和快速迭代，簡單性比精度更重要時。對於部落格文章或wiki文章等同質的段落級內容可以接受。不建議用於生產環境的企業RAG。

遞迴字元： 當需要比固定大小更好的精度但不需要語意或文件感知解析的複雜性時，這是一個合理的預設選擇。適合剛開始使用RAG並希望在固定大小基礎上漸進改進的團隊。

語意： 最適合文件版面不提供有用訊號的非結構化內容——客戶電子郵件、聊天記錄、社群媒體、支援工單。索引延遲懲罰使其不太適合頻繁重新索引的高吞吐量管道。

文件感知： 結構化企業文件的明確贏家——合約、報告、手冊、政策、規範。需要理解文件結構（標題、表格、章節）的解析器，但精度和成本效益證明了這一投資的合理性。

滑動視窗： 僅當您不能容忍塊邊界處的任何資訊遺失並願意支付token開銷時才有用。考慮用於安全關鍵應用，其中遺漏段落的成本高於更高的營運費用。

實作注意事項

選擇策略只是挑戰的一部分。實作細節很重要：

塊大小選擇。 即使在同一策略中，塊大小也會顯著影響效能。我們的測試表明，對於大多數企業文件，256到768 tokens之間是最佳區間。小於200 tokens的塊會遺失上下文；大於1,000 tokens的塊會稀釋相關性。

中繼資料保留。 無論使用哪種策略，將中繼資料（文件標題、章節標題、頁碼）附加到每個塊上，在我們的測試中可將檢索改善8%到12%。這些中繼資料支援混合搜尋並為重排序提供上下文。

混合方法。 我們觀察到的最高效能生產系統將文件感知分塊用於結構化內容，並將語意分塊作為非結構化部分的後備方案。這需要管道上游有一個文件分類器，但在混合語料庫上實現了89-92%的Recall@5。

Ertas如何處理分塊

Ertas Data Suite包含一個RAG Chunker節點，在視覺化管道畫布中支援多種分塊策略。因為Ertas在分塊之前透過結構化解析節點（PDF Parser、Word Parser、Excel/CSV Parser）處理文件，文件結構——標題、表格、章節——已經被擷取且可用。

這使得文件感知分塊成為自然選擇。RAG Chunker節點接收來自上游節點的已解析、結構化輸出，並可以利用該結構來定義塊邊界。團隊還可以在分塊後串連Quality Scorer節點，在塊到達嵌入階段之前標記低品質塊。

對於處理混合文件類型的團隊，Ertas管道可以在同一畫布上將結構化和非結構化文件路由到不同的分塊配置，每個階段都有完整的可觀察性。

關鍵要點

文件感知分塊在結構化企業文件上實現了最高的檢索精度（86.7% Recall@5）和最佳的token效率。語意分塊是非結構化內容的最強選擇，但索引延遲懲罰顯著。固定大小分塊雖然簡單，但與文件感知方法相比，精度低了超過15個百分點。

分塊策略的選擇對RAG品質和營運成本都有直接的、可衡量的影響。建構企業RAG管道的團隊應該針對自己的文件語料庫進行基準測試，但資料表明，投資於文件感知解析和分塊很快就能收回成本——無論是在檢索精度還是減少token支出方面。