RAG 應用 Chunking 策略教學:文件分塊最佳實踐完整指南(2026)
為什麼 Chunking 策略比你想的重要多了
說真的,我剛開始做 RAG 的時候完全忽略了 Chunking 這件事。我以為只要把文件丟進去、加上好的 Embedding 模型,系統就會自動變聰明。結果第一個專案上線後,使用者一直反應「找不到正確答案」——後來才發現,問題根本不在 LLM,而在於文件被切得亂七八糟,語義全都斷掉了。
這個踩坑經歷讓我開始認真研究 RAG 應用 Chunking 策略,也就是所謂的文件分塊最佳實踐。事實證明,Chunking 策略可以讓 RAG 系統的召回率差到 40% 以上——這不是小事,這是生死問題。
2026 年 2 月,Vecta 發布了一份讓社群熱烈討論的 Benchmark 報告,數據顯示:遞迴字元分割(Recursive Character Splitting)在 512 token 設定下達到 69% 的準確率,反而比語義分塊(Semantic Chunking)的 54% 還高。這個結果顛覆了很多人的直覺,也說明了「更複雜不一定更好」這件事在 RAG 領域同樣成立。
Chunking 策略全景圖:從簡單到複雜
在進入實作之前,先幫大家整理目前主流的四種 Chunking 策略,以及各自的適用場景。
1. 固定大小分塊(Fixed-size Chunking)
最簡單粗暴的做法:就是按照固定的字元數或 token 數切割,不管語義。這種方法快、便宜,但效果最差。有一篇臨床醫療資訊的研究發現,固定大小分塊的準確率只有 13%,幾乎等於沒用。除非你的文件結構非常均一,否則不建議使用。
2. 遞迴字元分割(Recursive Character Splitting)
這是我目前在大多數專案的預設起點,也是 LangChain 內建的 RecursiveCharacterTextSplitter 所採用的方法。它會依照段落、句子、字詞等層級遞迴地切割,盡量保留語義完整性。
推薦設定:400–512 tokens,重疊(overlap)設 10–20%。這個範圍在大量 Benchmark 中表現最穩定,也是我親測後最放心的起點。
from langchain.text_splitter import RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=512,
chunk_overlap=51, # 約 10% overlap
length_function=len,
separators=["\n\n", "\n", "。", "!", "?", " ", ""]
)
docs = text_splitter.split_documents(raw_documents)
print(f"切出 {len(docs)} 個 chunk")
注意:如果你的文件是中文,記得在 separators 裡加上中文標點,否則切割效果會大打折扣。這個細節我踩過很多次坑。
3. 語義分塊(Semantic Chunking)
語義分塊會根據句子之間的語義相似度來決定切割點——相似度低的地方才切,確保每個 chunk 都是語義連貫的。這個方法在特定任務上表現非常好,實測召回率可達 91–92%。
但代價是:計算成本顯著更高,因為每個句子都需要跑一次 Embedding 才能判斷相似度。在 Vecta 的 2026 Benchmark 中,語義分塊的整體準確率反而輸給了遞迴分割(54% vs 69%),這說明高召回率不等於高準確率——如果你的任務需要精確答案,而不只是「找到相關段落」,遞迴分割可能更合適。
from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings
embeddings = OpenAIEmbeddings()
text_splitter = SemanticChunker(
embeddings,
breakpoint_threshold_type="percentile",
breakpoint_threshold_amount=95
)
docs = text_splitter.create_documents([raw_text])
4. Agentic Chunking(智能代理分塊)
這是目前最「重」的方案:讓 LLM 本身來判斷如何切割文件。它會理解文件的結構與語意,然後決定最合理的邊界。效果非常好,特別適合法律文件、合規手冊這類高價值、結構複雜的文件。
不過成本極高,每份文件都需要跑一次 LLM,不適合大量文件的場景。我通常只在客戶願意為高精度付費的專案才使用這個方案。
2026 實測數據:哪個策略最值得用?
光說不練沒意義,來看看數字。根據今年最新的研究與 Benchmark:
- 遞迴分割(512 token):整體準確率 69%(Vecta 2026 Benchmark)
- 語義分塊:整體準確率 54%,但特定任務召回率可達 91-92%
- 自適應分塊(Adaptive Chunking):臨床研究中準確率 87%,vs 固定大小的 13%
- 固定大小分塊:臨床研究中僅 13%
這些數字有一個重要結論:沒有萬能策略,得根據任務類型選擇。語義分塊在「找到相關內容」上更強,遞迴分割在「給出正確答案」上更穩。
Metadata 是被低估的利器
很多人只關注 Chunking 本身,卻忽略了 Metadata 的重要性。在我的實戰經驗中,把 Metadata 當作一等公民(first-class signal)處理,往往比換一個更複雜的分塊策略更有效。
什麼意思呢?就是在每個 chunk 上附加有意義的 Metadata,讓向量搜尋在 filtering 階段就能大幅縮小範圍:
from langchain.schema import Document
# 建立帶有豐富 Metadata 的 chunk
chunk = Document(
page_content="...文件內容...",
metadata={
"source": "annual_report_2025.pdf",
"page": 12,
"section": "財務摘要",
"doc_type": "financial",
"language": "zh-TW",
"created_at": "2025-03-01",
"chunk_index": 5,
"total_chunks": 48
}
)
有了這些 Metadata,你就可以在查詢時先 filter doc_type == "financial",再做向量搜尋,精準度會大幅提升。這個技巧在使用 LangChain 或 LlamaIndex 構建 RAG 框架時都適用,只是實作方式略有不同。
生產環境的混合策略
在真實的生產環境中,我幾乎從不只用單一策略。現在我的標準做法是:
- 先用遞迴分割作為基底:400-512 tokens,10% overlap,這是成本效益最高的起點
- 對特定文件類型套用語義分塊:例如學術論文、長篇報告,這類文件語義結構複雜,值得多花一點 Embedding 成本
- 高價值文件使用 Agentic Chunking:法律合約、合規手冊等,準確率要求最高的場景
- 所有 chunk 統一加上豐富的 Metadata:讓 filtering 在向量搜尋前就發揮作用
這種混合策略(Hybrid Approach)是目前業界的主流推薦,特別是在文件類型多樣的企業環境中。
常見踩坑總整理
最後分享幾個我自己踩過、或看別人踩過的坑:
- Chunk 太大:超過 1000 tokens 的 chunk 往往會讓向量搜尋「抓不到重點」,因為一個 chunk 裡混了太多主題
- Chunk 太小:低於 100 tokens 的 chunk 語境太少,LLM 在生成答案時缺乏足夠背景
- 沒有 Overlap:切割點剛好在關鍵句子的中間,資訊就這樣消失了。10-20% 的 overlap 幾乎是必要的
- 忽略中文斷句:預設的英文 separators 在中文文件上效果很差,一定要客製化
- 一開始就過度優化:先用遞迴分割跑通,再根據實際問題調整。別一開始就花大錢上語義分塊,結果發現問題根本不在 Chunking
與 RAG 框架的整合
選好 Chunking 策略之後,下一步是整合進你的 RAG 應用框架。如果你還在猶豫要用 LangChain 還是 LlamaIndex,可以參考這篇LangChain vs LlamaIndex 深度比較,兩個框架對各種 Chunking 策略的支援程度不同,值得在選型時一起考量。
如果你打算進一步把 RAG 跟 Agent 結合,實現更動態的文件查詢邏輯,也可以看看LangChain Agent 開發入門,裡面有介紹如何用 Tool Calling 讓 Agent 自己決定要查哪些文件。
總結:從簡單開始,再持續演化
整理一下核心結論:從遞迴字元分割(400-512 tokens,10-20% overlap)開始,加上豐富的 Metadata,測量你的召回率,再決定是否需要升級到語義分塊或 Agentic Chunking。
Chunking 不是一次性的決策,它應該隨著你的系統演化而持續調整。建立好測試集、量測 recall@k 和準確率,讓數據來告訴你下一步該怎麼走——這才是做好 RAG 應用的正確姿勢。
這篇文章是 RAG 應用開發實戰系列的一部分,後續我們還會深入討論向量資料庫選型、Reranking 策略等主題,歡迎持續關注。
繼續閱讀
LangChain vs LlamaIndex 完整比較:2026 年 RAG 框架到底該怎麼選?
在 RAG 應用開發中,LangChain 和 LlamaIndex 是最常被拿來比較的兩大框架。這篇文章從架構設計、效能數據到實戰經驗,幫你釐清到底該選哪一個。
相關文章
你可能也喜歡
探索其他領域的精選好文