一、引言
為什麼同樣是做 RAG，有的效果拔羣，有的卻差強人意？分塊（Chunking）策略可能是那個被你忽略的關鍵環節。
什麼是Chunk？
AI中的分塊是指將大型文檔分割成稱為“chunk”的較小片段。這些片段可以是段落、句子、詞組或受token限制的片段，這使得模型能更輕鬆地僅搜索和檢索所需內容。這種分塊技術對於優化檢索增強生成（RAG）的性能至關重要。
為什麼在RAG中需要Chunk？
在RAG中，檢索到正確的信息是關鍵，但當知識庫非常龐大，可能包含數百萬字或文檔時，使用有效的RAG分塊技術對於從這類大型數據集中高效檢索相關信息，就變得至關重要了。舉個例子，你有一個服務QPS達到千萬級還要在30ms內返回結果，這時一定會搞一組本地緩存的集羣。把你的數據按規則初始化到緩存裏，就是對應的RAG的Chunk操作。
Chunk也是RAG ETL Pipeline中Transform環節的核心組件之一，可以比喻成我們切蛋糕，在切之前就已經想好要分幾塊了。讓我看看“切蛋糕🍰”有幾種手法。
二、主流RAG的分塊策略詳解
2.1.固定大小分塊策略
•核心思想： 根據預定義的字符數或 token 數將文本分成統一的塊。
•工作方式： 例如，固定每塊 500 tokens。引入 “重疊區”（Overlap）來緩解上下文斷裂問題。
•優點： 實現簡單，處理速度快，不依賴複雜模型。
•缺點： 可能破壞語義完整性（如拆分句子或段落），對結構差異大的文檔適應性差。
2.2.語義分塊策略
•核心思想： 根據文本的語義相似度而非物理結構進行分塊，確保每個 Chunk 內部主題高度相關。
•工作方式： 通常通過計算句子 Embedding 的餘弦相似度，當相似度低於某個閾值時進行分割。
•優點： 能創建邏輯上最連貫的 Chunk，對後續檢索和生成質量提升顯著。特別適用於處理主題跳躍較多的文檔。
•缺點： 計算成本高（需要調用 Embedding 模型），處理速度較慢。
2.3.基於遞歸分塊策略
•核心思想： 一種更智能的組合式策略，按優先級順序嘗試多種分隔符進行遞歸分割。
•工作方式： 例如，優先按段落分割，如果段落仍過大，再按句子分割，最後才按字符數強制分割。
•優點： 儘可能保留高級別的語義結構（段落 > 句子 > ...），適應性強，能處理多種類型文檔。
•缺點： 實現稍複雜，性能開銷高於純固定大小分塊。
2.4.基於文檔的分塊策略
•核心思想： 利用文檔本身的元數據和結構信息（如標題層級、表格、圖片説明、PDF 頁碼等）進行智能分割。
•工作方式： 例如，將一個一級標題下的所有內容（包括子標題和段落）作為一個大 Chunk，或者將每個表格單獨作為一個 Chunk。
•優點： 完美貼合特定類型文檔（如法律合同、學術論文、報告）的邏輯結構，信息組織性強。
•缺點： 依賴高質量的文檔解析和結構識別，通用性相對較弱。
2.5.智能體分塊策略
•核心思想： 這是一種更前沿的動態策略，根據 Agent 將要執行的具體任務或目標來決定如何分塊。
•工作方式： Agent 會先理解任務，然後自適應地從文檔中提取和組織最相關的信息塊。例如，任務是 “總結”，則可能提取關鍵論點；任務是 “回答特定問題”，則可能精準定位相關證據。
•優點： 靈活性和針對性極高，能最大化任務效果。
•缺點： 實現複雜，通常需要強大的規劃和推理能力，目前還不普及。
2.6.基於句子的分塊策略
•核心思想： 將文本分割成完整的句子，確保每個 Chunk 都包含一個或多個完整的思想。
•工作方式： 使用 NLP 工具（如 NLTK, SpaCy）識別句子邊界，然後可以將幾個連續的句子組合成一個 Chunk。
•優點： 保證了基本的語義單元完整，避免了 “半句話” 的問題。
•缺點： 句子長度差異仍可能導致 Chunk 大小不均；多個句子組合時，如何確定最佳組合仍需策略。
2.7.基於段落的分塊策略
•核心思想： 基於段落的分塊，通過提示符截取，將整個文本劃分成多個段落。這種方式同樣適合結構清晰的文檔。
•工作方式： 例如，保險條款、法律、論文、AB實驗報告等文檔。
•優點： 優點自然分段，語義完整。
•缺點： 缺點自然是段落長度不一，可能超token限制。
其他
除以上7種外，還有很多大神們總結的切塊方法論，如按照token、按照層級，按照excel sheet頁，按照pdf頁碼等。都是針對特定場景。下面我結合實戰和中文的切塊的方法論做一下總結。
三、分塊策略的選擇與實戰優化
3.1. 沒有“萬能”的分塊策略
現實中不存在一種“one-for-all” 的數據讀取和分塊方法，特別像是 PDF 和 Word 這類複雜格式的文檔。比較流行的方案是實用DeepDoc（OCR、TSR、DLR），所以實際中應根據業務，製作不同的模板。那麼評估Chunk的參數和指標有哪些呢？ 指標就是Precision和Recall，詳細看錶格 ：
| 參數 | 參考值 | 作用 |
|---|---|---|
| chunk\_size | 512-1024 | 1.切的越小chunks數越多，所以chunk\_size跟你的top-k值有關。在 Recall 差不多的情況下，可以選Precision 高的，比較有效率。 2.如果是能力強的大模型，Precision 低一點，也沒問題。 3.如果是能力弱的小模型，容易被噪聲影響，Precision 太低不好，因此切塊需要調小。 4.為什麼默認值是512？與主流預訓練語言模型的上下文窗口大小（如BERT的512）保持兼容。 |
| separator | /n | 分隔符 |
| overlap | 10%-15% | 通常重疊塊長度在10%-20%之間 |
Chunk參數與指標，我設計了兩套策略：512/10%和2500/25 （單位token）
| 通用策略（512/10%） | 最大上下文策略（2500/25） |
|---|---|
| chunk\_size：512個token，約450多個漢字是相對中等的切塊大小。這個大小足以容納完整的劇組或段落。大多情況可以在“準確率”與“上下文完整性”之間取的平衡 | chunk\_size：2500個token相當於2000多個漢字，屬於非常大的文本塊了。這個設定的背後邏輯是利用現在的大模型（GPT-5.1、gemini 3）的超大token。當任務是進行長篇文件的深度思考推理時，可以提供豐富的信息給到模型，從而獲得較高的Precision。 |
| overlap：10%是比較中庸設定，是業界普遍的建議，能緩解邊界切割問題。 | overlap：10個左右漢字，基本可以忽略了，超大文本塊被切割的機率相對較小。 |
3.2.Chunk策略的選擇
我的方法論：段落分塊（Paragraph Chunking），句子分塊（Semantic Chunking），遞歸分塊（Recursive Chunking），語義分塊（Semantic Chunking）。
現在的RAG框架基本都是基於段落或句子來分塊，也都都支持（\n。；！？）的遞歸分塊。那從運營用户角度出發，或者第一次切的時候，如何傻瓜式操作呢？RAGFlow交出了一份方案，看一下它的分塊核心算法
四、方法論總結
如何開始？可以從512 tokens 搭配 10-15%的重疊率開始。
如何優化？調試參數，多使用遞歸分塊和句子分塊，語義分塊還是不夠優秀。
如何測評？上號 chunking\_evaluation
有和方法論？ 上號 CRUD-RAG 論文指出對於創意生成和保持文章連貫性的任務，切分較大的塊表現會更佳。我們在
RAGas實驗也得到了相同的答案。
好了，以上是我們的實踐總結，希望能幫到大家。
