Chunking
3 秒看懂
Chunking（分塊）是將長文件切分成適配語言模型上下文視窗的“小段”的關鍵預處理步驟。它決定了模型看到的上下文邊界，直接影響大語言模型（LLM）的生成質量、檢索增強生成（RAG）的召回精度，以及訓練資料的有效利用率。
3 分鐘產業解釋
在大型模型產業中，Chunking 是連線原始非結構化資料與模型推論/訓練的核心資料工程環節。當一份 50 頁的 PDF 需要輸入僅支援 4096 token 上下文的模型，或需用向量資料庫索引一部技術手冊時，直接整本輸入不可行——必須先切成塊（chunk）。
塊的大小、重疊度、切割邏輯（固定字元、按句子、按段落、語義感知），直接決定了資訊密度與下游效果，具體關乎三個核心維度：
- RAG 系統的 Grounding 效果：塊過大時檢索噪聲高，易混入無關內容浪費上下文視窗；塊過小時關鍵資訊被割裂，答案缺乏所需背景。
- 模型微調的成本與質量：訓練樣本多按 chunk 組織。分塊不合理會導致指令或知識被截斷，模型學到碎片化模式，損害微調效果。
- 推論延遲與成本：每次請求拼接的塊數越多，組裝後的 prompt 越長，計算開銷與 API 費用同步上升。在 2023–2024 年大型模型 API 普遍按 token 計費的背景下，分塊策略直接關聯運營成本。
產業級 Chunking 已從早期簡單的 split("\n")，演進為結合文件結構、深層語義甚至輕量模型的智慧分塊管道，成為 LLMOps（大型模型運維）中不可繞過的工程基石。
技術原理
Chunking 的核心是將連續文本對映為一組規整片段，並可附帶重疊區域以保持跨塊連續性。以下拆解其內在機制與關鍵演算法變體。
基本流程與數學模型
給定文件全文 D = [w_1, w_2, ..., w_N]，w_i 為 token 或字元，分塊器定義三類關鍵引數：
- 塊大小（chunk_size）
C：每個塊包含的 token 或字元上限。 - 重疊大小（overlap）
O：相鄰塊共享的 token 數，通常O < C。 - 分割函式（split_function）：決定切割點的核心規則。
固定長度分塊直接生成塊序列：
B_1 = [w_1, ..., w_C]，B_2 = [w_{C-O+1}, ..., w_{2C-O}]，…，最後一塊取剩餘部分或填充。
若採用遞迴分割，演算法會在 [w_{i}, w_{i+C}] 區間內尋找優先順序最高的自然分隔符位置作為實際切割點，儘可能保留句子或段落邊界。
語義分塊機制
語義分塊是近年興起的高階方法，利用嵌入模型計算相鄰文本段的語義相似度，在話題切換處進行切割。其本質是序列邊界檢測問題：
- 將文件拆分為基礎單元（句子或小段），為每個單元生成嵌入向量。
- 計算相鄰單元向量的餘弦相似度。
- 當相似度低於預設閾值時標記為“語義斷裂點”，在此處切割。
- 最終各塊的 token 數如超出下游模型上限，需進行二次長度規整切割。
此方法無需預設塊長，但計算成本顯著上升，且效果高度依賴嵌入模型對目標領域語義的表達能力。截至 2025 年中，尚無統一的“最佳相似度閾值”標準，公開引數多在 0.3–0.6 之間浮動。
分塊與注意力機制的互動
在 RAG 場景中，檢索到的 k 個塊被拼接為最終 prompt。若各塊來自文件不同位置且缺乏順序標記，模型可能接收到“碎片化上下文”，造成理解偏差。工程上常用的緩解手段包括：在塊間插入分隔符（如 [SEP] 標籤）、在每塊前附加文件標題路徑作為後設資料、或通過摘要鏈（summary chain）預先生成塊間關係描述。這些操作已超出狹義 Chunking 範疇，屬於上下文建置策略的一部分。
模型內部的分塊計算
大規模語言模型的推論與訓練也依賴分塊思想，主要涉及：
- 分塊預填充（Chunked Prefill）：在推論時將超長 prompt 分為若干 chunk 順序編碼，KV cache 逐塊累積，可有效平滑視訊記憶體佔用峰值。vLLM（版本 ≥0.2.0）和 SGLang 均內建此排程策略。
- 稀疏注意力 / 滑動視窗：在注意力計算中，限制每個 token 僅關注前後固定大小的視窗，如 Mistral-7B（2023 年釋出）使用的 Sliding Window Attention，視窗大小通常設為 4096 token。
- Ring Attention：在多裝置分散式推論中，將序列切塊並在裝置間以環形通訊傳遞塊狀 KV 快取，實現長上下文擴充套件。
關鍵引數
產業實踐中，Chunking 效果高度依賴引數選擇，以下為關鍵指標及其工程含義。
| 引數 | 典型取值範圍與說明 | 權衡關係 |
|---|---|---|
| 塊大小 (Chunk Size) | 通常 128–2048 token。RAG 場景中 512–1024 常用；程式碼等結構化場景可能達 2048。應匹配下游嵌入模型的輸入上限（如 text-embedding-ada-002 上限 8191 token，text-embedding-3-small 上限 8191 token，均為 2024 年現有模型指標）以及檢索後拼接的 prompt 總長約束。 | 塊越大，單塊資訊完整但檢索粒度粗、噪聲多；塊越小，定位精準但易丟失上下文。 |
| 重疊率 (Overlap Ratio) | 重疊大小/塊大小，常見 10%–20%。語義分塊方案有時設 overlap=0。 | 重疊過高增加儲存與計算冗餘，尤其在向量索引中重複嵌入會放大成本；過低則可能在邊界處割裂關鍵資訊。 |
| 最大塊數限制 | 檢索階段通常取 top_k=3–10 個塊拼入 prompt，具體受模型上下文視窗約束。 | 直接影響答案資訊覆蓋度，需結合下游任務調整。 |
| 分隔符優先順序表 | 遞迴分割常見優先順序：“\n\n” → “\n” → ”。” → ” ” → ""。多語言場景需定製，如中文優先在句號、段落標記處切割。 | 優先順序設計不當會導致頻繁在無效位置切割，降低語義一致性。 |
| 語義相似度閾值 | 僅針對語義分塊，相鄰句向量餘弦相似度低於閾值則切割。公開資料未見統一標準，常見為 0.4–0.6。 | 閾值越高，塊越多越小，話題切換敏感；閾值越低，塊越大但可能混入多主題。 |
注：上述取值範圍來自社群公開實踐總結，非單一權威標準。
技術路線
主流方案對比
當前 Chunking 技術路線可分為五大類，在實現複雜度、語義保持度與計算成本間形成遞進關係。
| 方法 | 實現原理 | 優點 | 缺點 | 典型適用場景 | 語義一致性評等 |
|---|---|---|---|---|---|
| 固定長度分塊 | 按 token/字元數直接切分，通常配合 overlap。 | 實現簡單、速度快、塊數可預測。 | 粗暴打斷句子，可能破壞關鍵資訊。 | 快速原型、文本分類預處理。 | 低 |
| 遞迴字元分割 | 預設分隔符優先順序，在各視窗內尋找最優切割點。以 LangChain 的 RecursiveCharacterTextSplitter 為典型。 | 兼顧長度限制與自然邊界，工程成熟。 | 依賴預設分隔符表，對無結構文本效果下降。 | 通用 RAG，是當前開源社群事實標準。 | 中 |
| 文件結構感知分塊 | 先解析文件為結構樹（Markdown 標題、PDF 章節等），按邏輯小節切分並保留層級路徑。 | 語義完整、可攜帶文件導航資訊。 | 依賴文件格式質量，解析成本高，對格式混亂的 PDF/HTML 魯棒性差。 | 技術手冊、電子書、結構化知識庫。 | 高 |
| 語義分塊 | 基於嵌入相似度或小模型判斷話題邊界。 | 話題邊界自然、資訊密度高。 | 計算成本顯著增加，受嵌入模型質量影響，長度控制不精確。 | 客服對話、新聞、高精度 RAG。 | 很高 |
| 模型動態分塊（Agentic Chunking） | 呼叫 LLM 自主判斷切割點，可與文件理解聯動。 | 最靈活，可融合任務需求動態調整。 | 成本極高、延遲大、結果非確定性。 | 超高質量要求的實驗場景。 | 最高 |
注：上表基於社群實踐公開資訊進行定性對比，未引用特定廠商獨佔資料。
路線選擇決策架構
產業落地時，需在以下維度權衡：
- 若文件格式規範（如 Markdown 技術文件），優先選擇結構感知分塊，以最低額外成本獲取高語義一致性。
- 若文件來源混雜、格式不一（如網頁抓取），遞迴分割是穩健基線。
- 若檢索精度為第一優先順序且算力預算充足，可引入語義分塊，並在驗證集上調參。
- 若面向多語言或跨領域場景，需評估分隔符優先順序表與嵌入模型的適配性，公共基準測試（如 BEIR 等檢索評估集，截至 2024 年）可輔助決策。
上游
Chunking 的上游產業由三類供給組成，其質量直接限定分塊效果的上限。
- 文件解析與提取：將 PDF、HTML、Word、PPT、影像（OCR）等格式轉為可切分的文本流。代表工具包括 Unstructured（開源專案及同名公司）、Apache Tika、PyMuPDF 等。PDF 的段落識別、表格/圖片與正文混排的處理是主要痛點；Unstructured 在 2023–2024 年公開的融資檔案中揭露，文件解析環節可佔非結構化資料處理流水線 40%–50% 的工作量（引述行業定性描述，非精確財務數字）。
- 分詞器（Tokenizer）：決定
chunk_size的計量單位。不同模型的 tokenizer 對同一文本生成的 token 數差異可達 30% 以上（如 GPT 系列與 Llama 系列的中文分詞效率不同）。Chunking 策略在設計時必須對齊目標模型的 tokenizer，否則實際送入模型的塊長可能與預期偏差顯著。 - 嵌入模型（Embedding Model）：面向語義分塊時，需與輕量、對句子語義敏感的嵌入模型配合。常用選擇包括 OpenAI text-embedding-3-small、BGE-small 等開源模型。其推論速度與成本是整個分塊管線的瓶頸之一。
下游
分塊的輸出直接服務於以下產業環節：
- 向量資料庫與索引：Pinecone、Weaviate、Chroma、Milvus 等接收分塊後的文本並生成向量索引。查詢時，檢索到的塊集合即構成 prompt 的事實來源。塊大小直接影響索引儲存成本、召回精度與檢索延遲：以 2024 年某向量資料庫廠商公開基準為例，10 萬份文件在 512 token 塊與 1024 token 塊兩種方案下，儲存向量數可相差約 40%–45%。
- LLM 推論服務：vLLM、TensorRT-LLM、SGLang 等推論引擎管理分塊後的上下文組裝。分塊預填充（chunked prefill）已成為高吞吐推論的關鍵排程特性，其效率直接影響併發使用者數。
- 模型微調工具鏈：Hugging Face Trainer、OpenAI Fine-tuning API、各雲端廠商微調服務均需將訓練語料組織為固定長度序列，分塊質量影響訓練樣本的語義完整性。
- 知識庫與 Copilot 平台：Notion AI、企業 Copilot、釘釘/飛書智慧助手等面向終端使用者的產品，其問答質量與 Chunking 策略深度繫結。行業調研指出（Metaari 2024 年企業 AI 應用報告，間接引用），RAG 類應用約 30% 的初期調優時間消耗在分塊與檢索策略的迭代上，公開資料未見精確統計。
受益公司
Chunking 作為基礎技術環節，受益方分佈於產業鏈各層：
- RAG 架構廠商（LangChain、LlamaIndex）：其內建的 TextSplitter 模組已成為事實標準組件，架構滲透率提升直接放大其生態影響力。均為私有未上市公司，公開財務資料未見。
- 非結構化資料處理公司（Unstructured）：定位為 PDF/HTML 解析與智慧分塊 API 供應商，2023–2024 年完成多輪融資（公開資訊：2023 年 B 輪 2500 萬美元，2024 年 C 輪 4000 萬美元，Crunchbase 資料，具體估值未揭露），企業客戶是其主要營收來源，變現路徑清晰。
- 向量資料庫廠商（Pinecone、Weaviate、Chroma 等）：Chunking 功能嵌入其資料攝取管道，作為 RAG 整體方案的一環，最佳化分塊策略可提升其作為託管服務的競爭力。Pinecone 2023 年完成 1 億美元 B 輪融資（估值為 7.5 億美元，公開報道），Weaviate 2024 年估值未公開更新。
- 雲端服務商（AWS、Azure、Google Cloud）：在各自的 AI 託管服務（如 Amazon Bedrock Knowledge Base、Azure AI Search、Google Vertex AI Search）中內嵌文件切片功能，作為知識庫建立的標準步驟。
- 大型模型推論引擎團隊（vLLM 社群、SGLang）：其分塊預填充技術是實現高吞吐長文本推論的關鍵賣點，雖以開源為主，但相關服務商（如 Anyscale、各 GPU 雲端）間接受益。
注：上述公開融資數字來自 Crunchbase 及主流科技媒體報道，未交叉驗證公司官方財報。
市場規模
Chunking 作為 LLMOps 工具鏈的組成部分，不構成獨立核算市場，其市場價值隱含在 RAG、向量資料庫及非結構化資料預處理等細分領域內。
- RAG 工具與平台市場：據 Grand View Research 2024 年行業報告，全球 RAG 相關工具市場 2023 年規模約 2.3 億美元，預計 2030 年達 17.5 億美元，CAGR 33.2%。分塊作為 RAG 的核心預處理環節，其技術價值佔比難以拆分。
- 向量資料庫市場：據 MarketsandMarkets 2024 年報告，全球向量資料庫市場 2024 年約 16 億美元，預計 2029 年達 46 億美元，CAGR 23.8%。分塊策略直接影響向量儲存成本與檢索效率，構成該市場的輔助價值層。
- 非結構化資料處理：無統一市場口徑，但文件解析與預處理在 2024 年企業 AI 建設中屬於廣泛認可的剛性投入項，公開資料未見具體規模估算。
免責宣告：以上市場資料引自第三方研究機構預測，屬前瞻性估計，實際增長或存在偏差。
玩家對比
| 玩家/方案 | 核心分塊能力 | 差異化特徵 | 商業模式 | 融資/估值（截至 2025 年中公開資訊） |
|---|---|---|---|---|
| LangChain | RecursiveCharacterTextSplitter；支援多種分割器組合 | 開源架構，社群生態最強；分塊策略可插拔 | 開源 + LangSmith 付費監控平台 | 母公司 LangChain Inc，2024 年 A 輪 2500 萬美元（Crunchbase），估值未公開 |
| LlamaIndex | 多種分塊器，含 SentenceSplitter、SemanticSplitter 等 | 專注資料索引層，與向量庫整合緊密 | 開源 + LlamaCloud 託管服務 | 2024 年種子輪 850 萬美元（TechCrunch），估值未公開 |
| Unstructured | 高質量文件解析後自動分塊，支援 20+ 格式 | 從解析到分塊的一站式 API；企業級穩定度 | SaaS API + 私有化部署 | 2024 年 C 輪 4000 萬美元，累計約 7000 萬美元（公開報道） |
| 雲端廠商內建方案 | AWS Bedrock/Azure AI Search 自動分塊 | 與雲端生態鎖定，無額外整合成本 | 隨雲端服務計費 | 不獨立核算 |
| vLLM / SGLang（推論層） | chunked prefill 排程策略 | 解決推論效能而非檢索質量 | 開源，由雲端 GPU 服務商間接受益 | 社群專案，無公司實體 |
注：融資及估值資料來自公開報道，未審計，僅供參考。
風險
- 上游解析質量波動風險：分塊高度依賴文件解析環節，若 PDF 中表格、多欄排版或 OCR 質量差，解析結果混亂將導致後續分塊完全失效。該風險在掃描版 PDF、財報、學術論文等場景尤為顯著，目前尚不存在普適的解決方案。
- 引數泛化困境：chunk_size 與 overlap 等引數高度依賴下游任務與文件型別。在某一語料上調優的分塊策略遷移至新領域（如從技術文件遷移到客服對話）可能顯著退化，當前缺乏自動化引數尋優的通用工具。
- 多語言與程式碼混合場景覆蓋不足：主流分塊方案對中文、日文、阿拉伯語等不以空格分詞的語言支援較弱，對程式碼/文本混排的文件（如 Jupyter Notebook）也缺乏成熟實踐。社群方案多以英文為中心。
- 成本與效果的平衡難題：語義分塊與 Agentic Chunking 雖然效果優異，但需為每篇文件呼叫嵌入模型或 LLM，處理百萬級文件庫時的 API 費用與延遲成為實際落地瓶頸。公開資料未見成熟的大規模成本最佳化方案。
- 標準化缺失：行業內尚無公認的分塊效果評估基準，不同方案的效果對比多依賴各自內部評測集，橫向可比性弱，使用者選型成本高。
誤讀糾偏
1. “Chunking 就是儘量切小，塊越多檢索越準”
誤。 塊越小，單塊資訊量越少，檢索到的塊可能缺乏充分上下文，導致模型給出不完整甚至錯誤的答案。極端情況下塊僅含單個詞，檢索雖“精準”但毫無意義。理想目標是最小完整語義單元——在上下文自足與精確定位間取得平衡。
2. “重疊總是有益的，多加一點沒壞處”
誤。 重疊增加索引儲存量與檢索冗餘。若檢索後未做重排序（re-rank），高度重疊的多個塊可能佔滿 context window，排出其他有價值資訊。部分基於句子精確分割的方案無需重疊即可保證邊界連貫，重疊並非普適必需品。
3. “長上下文模型普及後，分塊將被淘汰”
誤。 即使模型支援 128K 或 1M token，RAG 仍需分塊來定位相關段落。直接輸入整本書回答簡單問題會稀釋注意力，並大幅增加推論延遲與成本。來自 Google DeepMind 及學術界的多項 2024 年評估（如“Lost in the Middle”現象研究）表明，模型對長上下文中間位置的資訊召回率仍顯著下降。分塊是為了“按需供給”相關上下文，長上下文則是保障組合後理解的完整性，兩者互補而非替代。
4. “語義分塊一定比規則分塊好”
誤。 語義分塊在話題切換檢測上有優勢，但受限於嵌入模型質量、計算成本高和長度不可控。在格式清晰的結構化文件（如按標題層級組織的技術手冊）中，基於標題的規則分塊往往能以極低成本達到同等甚至更優的檢索效果。方法選擇應遵循“用適合成本的方案解決對應複雜度的問題”原則。
最新事件
截至 2025 年中，以下為近期值得關注的行業動態（來源為公開發布資訊）。
- LangChain 推出 LangSmith 分塊效果評估模組（2024 年 Q4）：LangChain 在付費平台 LangSmith 中增加了對分塊結果的視覺化評估工具，允許使用者在檢索資料集上對比不同分塊策略的召回率，標誌著分塊調優從“憑感覺”向“可量化”過渡。
- LlamaIndex 釋出 Semantic Splitter 增強版（2025 年 Q1）：整合 BGE-small 等輕量嵌入模型實現本地語義分塊，降低對昂貴 API 的依賴，並開源了基準測試程式碼。
- Unstructured 宣佈企業級多模態分塊支援（2025 年 Q2）：在其 SaaS API 中新增對 PDF 內嵌表格與圖片的 chunk 級關聯功能，初步解決表格資料在分塊後被孤立的問題。
- vLLM 社群推進字首快取與分塊預填充聯動最佳化（2024–2025 年持續）：在 vLLM v0.3.0 版本中進一步優化了 chunked prefill 與 automatic prefix caching 的協同，實測在部分長文件場景中使推論吞吐提升 15%–25%（社群公開基準，非獨立審計）。
- 關於“Long Context vs. RAG”的學術辯論持續升溫：2024 年多篇論文（如 “RAG vs. Long Context” 系列，作者群來自多家機構）在不同任務上對比兩種範式，結論傾向為：兩者結合（長上下文包裹 RAG 檢索塊）在多數複雜任務中優於純長上下文或純 RAG，間接強化了 Chunking 的長期價值。
追蹤指標
產業研究者與工程團隊可關注以下指標以持續評估 Chunking 領域的發展：
- 公開基準中的檢索命中率：BEIR、MTEB 等檢索基準中，各 RAG 架構在不同分塊策略下的 Recall@k 與 NDCG@k。建議追蹤 LlamaIndex 或 LangChain 社群定期釋出的 RAG 評估報告。
- 頂尖推論架構的 chunked prefill 效能資料：vLLM 和 SGLang 文件中釋出的 Time to First Token（TTFT）與吞吐量基準，尤其關注長 prompt（>16K token）場景下的實測資料。
- 文件解析與分塊公司的融資節奏：Unstructured 等代表公司的融資輪次與金額，反映資本對非結構化資料預處理賽道的熱度。
- 長上下文模型與 RAG 的效能比較研究：追蹤 ACL、NeurIPS 等頂會及 arXiv 上對比長上下文與 RAG 的最新論文結論，判斷 Chunking 需求的長期趨勢。
- 向量資料庫廠商的分塊最佳實踐更新：Pinecone、Weaviate 官方文件中關於 chunk_size 推薦的更新，尤其是針對新嵌入模型（如 text-embedding-3 系列，2024 年釋出）的最佳實踐引數。
信源
本頁面技術事實主要依據以下公開資料（截止 2025 年中）：
- LangChain 官方文件：“Text Splitters”章節
- LlamaIndex 官方文件及部落格：“Chunking Strategies Guide”
- Greg Kamradt, “Evaluating Chunking Strategies for RAG”（公開技術評測文章，多版本更新）
- vLLM 官方文件：“Chunked Prefill”與“Automatic Prefix Caching”技術說明
- Mistral AI 技術報告中對 Sliding Window Attention 的描述（2023 年）
- Pinecone 官方指南：“Chunking Strategies for RAG”
- MarketsandMarkets, “Vector Database Market Report”（2024 年）
- Grand View Research, “Retrieval Augmented Generation Market Report”（2024 年）
- Crunchbase：Unstructured、LangChain、LlamaIndex 融資記錄（2023–2024 年）
- arXiv 論文：“Lost in the Middle: How Language Models Use Long Contexts”（Liu et al., 2023）及後續對比研究
免責宣告：本頁面內容僅供技術學習與產業研究參考，不構成任何投資建議、產品選擇建議或對未來行情的預測。所有市場資料來自第三方公開報告，僅反映釋出時的預測，未保證準確性。