Chunk Size（分塊大小）
3 秒看懂
Chunk Size 是將長文本/長序列切割成可管理小塊時，每一塊的大小（通常以 token 數或字元數計量）。 它不是某個特定硬體規格，而是一個橫跨 RAG 檢索、LLM 推論排程、資料管線的”旋鈕引數”——調大調小直接影響檢索精度、視訊記憶體佔用和推論吞吐。
3 分鐘產業解釋
為什麼一個”切割引數”值得產業級關注？
在當前大型模型落地的實際工程中，幾乎所有系統都需要把超長輸入切分成若干”chunk”來處理：
| 場景 | 被切分的物件 | Chunk Size 指什麼 | 產業痛點 |
|---|---|---|---|
| RAG 檢索增強生成 | 文件/網頁/PDF | 每個文本塊的 token 數 | 切太大→檢索不準；切太小→語義斷裂，召回碎片化 |
| LLM 推論（Prefill 階段） | 長 prompt | 單次送入 attention 的 token 數 | 太大→單請求霸佔 GPU，阻塞其他請求；太小→頻繁啟動 kernel，overhead 高 |
| 分散式訓練 | 微批次資料 | 單個 micro-batch 的 token 數 | 影響流水線氣泡率、梯度累積步數 |
| 向量資料庫寫入 | embedding 批次 | 單批寫入行數 | 影響寫入吞吐和索引建置效率 |
一句話：Chunk Size 是大型模型系統工程中”分而治之”策略的核心旋鈕，不同場景下最優值差異巨大，且往往需要與模型上下文視窗、硬體視訊記憶體、檢索演算法聯合調優。
15 分鐘專家深入
一、RAG 場景中的 Chunk Size——最核心戰場
RAG（Retrieval-Augmented Generation）是當前企業級 AI 應用的主戰場。其基本流程：
原始文件 → 切分(Chunking) → 向量化(Embedding) → 存入向量資料庫 → 檢索 → 拼入 prompt → LLM 生成Chunk Size 是這個管線中最上游、影響最深遠的超引數。
1.1 典型取值範圍
| Chunk Size（tokens） | 適用場景 | 優勢 | 劣勢 |
|---|---|---|---|
| 128–256 | 細粒度 FAQ、程式碼片段檢索 | 召回精準，噪聲少 | 語境斷裂嚴重，需多 chunk 拼接 |
| 256–512 | 通用知識庫問答（工程主流區間） | 精度與上下文的平衡點 | 仍可能丟失跨段落關聯 |
| 512–1024 | 長文件摘要、合同分析 | 保留更多上下文 | 檢索粒度粗，可能召回無關內容 |
| >1024 | 特定長文任務 | 極端上下文保留 | embedding 模型截斷風險；向量空間語義稀釋 |
⚠️ 關鍵依賴：Chunk Size 的有效上限受 embedding 模型的最大輸入長度約束。例如，若 embedding 模型最大輸入為 512 tokens，則 chunk 超過此值會被截斷，語義資訊丟失。常見 embedding 模型如 OpenAI text-embedding-3 系列、BGE 系列的最大輸入長度各異，需逐一確認 [廠商文件]。
1.2 切分策略不只是”固定視窗”
| 策略 | 描述 | 優缺點 |
|---|---|---|
| 固定大小（Fixed-size） | 每 N 個 token 切一刀 | 簡單，但可能在句子/段落中間截斷 |
| 遞迴字元切分（Recursive Character） | 先按段落→句子→字元遞迴切 | LangChain 預設策略，語義保持較好 |
| 語義切分（Semantic Chunking） | 計算相鄰句子 embedding 餘弦相似度，拐點處切 | 效果好但計算開銷大 [Andrew Ng 討論] |
| 文件結構切分 | 按 Markdown 標題 / HTML 標籤 / PDF 段落 | 保留結構語義，依賴文件格式質量 |
| 重疊視窗（Overlap） | 相鄰 chunk 有 10%–20% token 重疊 | 緩解邊界語義丟失，但增加索引儲存量 |
Overlap（重疊量） 通常是 Chunk Size 的 10%–20%，與 Chunk Size 聯合調優。
1.3 Chunk Size 與檢索質量的關係
直覺上：
- Chunk 越小 → 每個向量的語義越聚焦 → 精確匹配（exact match）能力越強 → 但”需要跨 chunk 理解”的問題會失敗
- Chunk 越大 → 每個向量的語義越稀釋 → 可能檢索到”包含答案但噪聲很大”的塊 → LLM 需要更強的”大海撈針”能力
實際最佳實踐往往是多粒度索引（multi-granularity indexing）：同時索引 256-token 和 1024-token 的 chunk，檢索時融合排序。這在工程上增加了 2–3 倍的向量儲存和 embedding 計算成本 [行業工程實踐估算]。
二、LLM 推論中的 Chunk Size（Prefill Chunking）
在 LLM serving（vLLM、TensorRT-LLM、SGLang 等）中，“chunk”概念出現在 prefill 階段的排程策略中：
2.1 Prefill vs Decode 的矛盾
- Prefill（處理 prompt）：計算密集型，GPU 算力利用率高
- Decode（逐 token 生成）：訪存密集型，GPU 算力利用率低
如果一個超長 prompt 的 prefill 一次完成，會長時間獨佔 GPU，導致同一 GPU 上的其他 decode 請求被阻塞（延遲飆升）。
2.2 Chunked Prefill 策略
核心思想：將長 prompt 的 prefill 分成多個 chunk，每個 chunk 與 decode 請求交替排程。
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Prefill │ │ Decode │ │ Prefill │ │ Decode │
│ Chunk 1 │ │ (batch) │ │ Chunk 2 │ │ (batch) │
└─────────┘ └─────────┘ └─────────┘Chunk Size 在此的含義：單次 prefill 處理的 token 數。
- 常見配置：512–2048 tokens/chunk [SGLang/DeepSeek 工程實踐]
- 太小：kernel launch overhead 增大，throughput 下降
- 太大：其他請求等待時間過長，P99 延遲惡化
這一策略在 DeepSeek 系列模型的 serving 論文以及 SGLang 的實現中有較詳細討論 [廠商技術部落格]。
2.3 與 KV Cache 的關係
每處理一個 chunk，就產生對應位置的 KV Cache。Chunk Size 影響：
- 視訊記憶體峰值：單 chunk 越大，attention 矩陣的峰值視訊記憶體越高（尤其在沒有 FlashAttention 的情況下）
- KV Cache 分配粒度：PagedAttention（vLLM）以 block 為單位分配 KV Cache，block size 與 chunk size 需協調
三、分散式訓練中的 Chunk / Micro-batch Size
在 Pipeline Parallelism 中：
- 全域性 batch 被切分成多個 micro-batch
- 每個 micro-batch 的 token 數可理解為訓練場景的”chunk size”
- 梯度累積步數 = 全域性 batch / micro-batch 數
Micro-batch 越小 → 流水線氣泡比例越高（計算/通訊 ratio 下降）；越大 → 視訊記憶體佔用越高。
典型配置（以 Megatron-LM 為代表架構）：micro-batch size 通常為 1–8 個 sequence，每個 sequence 長度常見 2048–8192 tokens [Megatron-LM 文件/論文]。
技術原理（最深一層）
Chunk Size 如何影響 Attention 計算
Transformer 的 self-attention 計算複雜度為 O(n²·d)，其中 n 為序列長度，d 為 head dimension。
┌──────────────────────────────────────────────────┐
│ Self-Attention 計算流程 │
│ │
│ Q, K, V = X · Wq, X · Wk, X · Wv │
│ │
│ Attention(Q,K,V) = softmax(QK^T / √d_k) · V │
│ │
│ QK^T 矩陣: [n × n]，視訊記憶體佔用 O(n²) │
│ │
│ 當 chunk_size = n: │
│ - 若 n 小(如 256): QK^T ≈ 64K 元素，可控 │
│ - 若 n 大(如 8192): QK^T ≈ 64M 元素，視訊記憶體壓力大 │
│ │
│ FlashAttention 的 tiling 策略: │
│ 將 Q/K/V 按 block(通常 128 tokens)切塊計算 │
│ → 與上層"chunk size"形成兩級分塊層次 │
└──────────────────────────────────────────────────┘關鍵洞察：FlashAttention 內部也有”chunk”（tiled block），其 block size（通常 64–128 tokens）與上層 chunk size 是不同層次的分塊：
- 上層 chunk size：排程/系統層面的序列切分
- FlashAttention block size：硬體/運算元層面的計算切分
兩者獨立調優，但共同決定端到端的視訊記憶體與延遲特徵。
Embedding 模型的 Chunk 處理
當 chunk 送入 embedding 模型時：
Chunk (e.g., 512 tokens)
↓
Tokenizer → Token IDs [512]
↓
Transformer Encoder (or similar)
↓
Pooling (CLS / Mean / Last Token)
↓
Embedding Vector (e.g., 1536-dim for OpenAI text-embedding-3-small)若 chunk 長度 > embedding 模型 max_position_embeddings，超出部分被截斷，語義丟失。這是 chunk size 的硬上限約束。
技術演進史
| 時期 | Chunk Size 主要語境 | 典型值 | 驅動因素 |
|---|---|---|---|
| 2020–2021 | 幾乎不討論；NLP 處理以 512 token 上限為主 | 512（模型硬限制） | BERT max_length = 512；GPT-3 context = 2048 |
| 2022 | RAG 概念興起，LangChain 推廣固定切分 | 1000–2000 字元（約 300–600 tokens） | ChatGPT 催化 RAG 工程化 |
| 2023 | RAG 工程化爆發，chunk 調優成為顯學 | 256–512 tokens 成為主流 | 社群實驗發現小 chunk 召回更準；embedding 模型進步 |
| 2023 Q4–2024 | Chunked Prefill 在 serving 層面興起 | Prefill chunk: 512–2048 tokens | 長 context（128K+）模型普及；SGLang/vLLM 最佳化 |
| 2024–2025 | 多粒度索引、Late Chunking、Contextual Retrieval | 混合粒度 | Anthropic 提出 Contextual Retrieval；Jina AI 提出 Late Chunking（先編碼再切分） |
重要趨勢：
-
Late Chunking（2024，Jina AI 提出）：先將完整文件送入長上下文 embedding 模型得到 token-level 表示，再在表示空間上切分池化。這從根本上改變了”先切再編碼”的傳統範式，使得 chunk 邊界的語義斷裂問題大幅緩解。
-
Anthropic Contextual Retrieval（2024）：在每個 chunk 前拼接一段由 LLM 生成的上下文摘要，再做 embedding。本質上是用計算換 chunk 邊界資訊損失，可在不改變 chunk size 的前提下提升檢索質量。
技術路線對比
Chunk Size 選取策略對比
| 維度 | 固定小 Chunk (≤256) | 固定中 Chunk (256–512) | 固定大 Chunk (512–1024) | 多粒度索引 | Late Chunking |
|---|---|---|---|---|---|
| 檢索精度 | ★★★★★ | ★★★★ | ★★★ | ★★★★★ | ★★★★★ |
| 上下文完整性 | ★★ | ★★★ | ★★★★ | ★★★★ | ★★★★★ |
| 索引儲存 | 小 | 中 | 大 | 大（2–3×） | 中 |
| Embedding 計算 | 低 | 中 | 高 | 高（2–3×） | 極高（長上下文模型） |
| 工程複雜度 | 低 | 低 | 低 | 中 | 高 |
| 適用場景 | FAQ、程式碼 | 通用 RAG | 長文摘要 | 生產級 RAG | 高質量 RAG（預算充足） |
Prefill Chunk Size 對比（推論 serving）
| Prefill Chunk Size | GPU 利用率 | 其他請求延遲影響 | 適用場景 |
|---|---|---|---|
| 小（≤512 tokens） | 較低（kernel overhead） | 低（友好） | 低延遲互動場景 |
| 中（512–2048） | 較高 | 中 | 通用 serving 主流 |
| 大（>2048） | 高 | 高（阻塞他人） | 離線批處理、吞吐優先 |
上下游
上游依賴
| 上游環節 | 與 Chunk Size 的關係 |
|---|---|
| Tokenizer | Chunk Size 的計量單位是 token，tokenizer 的分詞粒度直接決定實際文本長度對應關係 |
| Embedding 模型 | 最大輸入長度是 chunk size 的硬上限 |
| LLM Context Window | 檢索到的 chunks 總量不能超過 LLM 的可用 context（需預留生成空間） |
| 向量資料庫 | 單條向量的 payload 大小、索引型別（HNSW/IVF）影響 chunk 後設資料儲存 |
| GPU 視訊記憶體 | Prefill chunk size 受 KV Cache 視訊記憶體預算約束 |
下游影響
| 下游環節 | 影響 |
|---|---|
| 檢索質量（Recall@K, MRR） | 直接決定 |
| LLM 生成質量 | 間接決定（通過檢索結果質量） |
| Serving 延遲（TTFT, TPS） | Prefill chunk size 直接影響 |
| 基礎設施成本 | 索引儲存、embedding 計算、GPU 佔用均受影響 |
關鍵指標
| 指標 | 含義 | 典型範圍 | 與 Chunk Size 的關係 |
|---|---|---|---|
| Recall@K | Top-K 檢索結果中包含正確答案的比例 | 0.7–0.95（優質 RAG） | 核心最佳化目標，chunk size 直接影響 |
| MRR（Mean Reciprocal Rank） | 正確答案在檢索結果中的排名倒數均值 | 0.5–0.9 | chunk size 影響排序質量 |
| TTFT（Time to First Token） | 使用者發出請求到首個生成 token 的延遲 | 0.5–5s | Prefill chunk size 影響 |
| KV Cache 視訊記憶體佔用 | 單請求佔用的 KV Cache 大小 | 與 sequence length × layer × hidden dim 成正比 | Chunk 過大→單次 prefill 視訊記憶體峰值高 |
| Embedding 吞吐 | 每秒可處理的 token 數 | 取決於模型和硬體 | Chunk 越大→單次推論吞吐越高（到某閾值前） |
| 索引膨脹比 | 有 overlap 的 chunk 總 token 數 / 原始文件 token 數 | 1.1–1.3（典型 overlap 10%–20%） | Overlap 直接增加 |
供需與市場資料
RAG 市場規模
RAG 已成為企業 AI 落地的主流架構。相關市場資料：
- 全球向量資料庫市場：預計 2025 年達到數十億美元規模 [行業報告估算，具體數字因來源差異較大]
- 企業 AI 應用中採用 RAG 架構的比例：估計 60%–80% 的企業 LLM 應用使用某種形式的檢索增強 [Gartner/行業調研估算]
- Chunk 最佳化工具/平台：LangChain、LlamaIndex 等架構內建 chunk 策略調參能力；新興工具如 Unstructured.io 專注文件智慧切分
Chunk Size 調優的隱性成本
| 成本項 | 描述 | 量級估算 |
|---|---|---|
| 工程人力 | 調參、AB 測試、評估 | 每個專案 2–4 周 [行業經驗估算] |
| Embedding 計算 | 多粒度索引需多次 embedding | 2–3× 單粒度成本 [估算] |
| 向量儲存 | 更多 chunk → 更多向量 | 與 chunk 數線性相關 |
| 檢索延遲 | 更多候選向量 → 檢索稍慢 | 通常可忽略（向量 DB 最佳化後） |
代表公司與資本對映
| 公司/專案 | 與 Chunk Size 的關聯 | 備註 |
|---|---|---|
| LangChain | 提供 RecursiveCharacterTextSplitter 等多種 chunking 策略 | RAG 工程的事實標準架構 |
| LlamaIndex | 提供 SentenceWindowNodeParser、SemanticSplitterNodeParser 等高階 chunking | 專注 RAG 的資料架構 |
| Jina AI | 提出 Late Chunking；釋出長上下文 embedding 模型 | 重新定義 chunking 範式 |
| Anthropic | 提出 Contextual Retrieval | 用 LLM 增強 chunk 語義 |
| Unstructured.io | 專注文件解析與智慧切分 | 非結構化資料處理基礎設施 |
| Weaviate / Pinecone / Milvus | 向量資料庫，chunk 儲存與檢索 | 受益於 RAG 普及 |
| vLLM / SGLang | 實現 Chunked Prefill 推論排程 | 推論 serving 層面的 chunk 最佳化 |
| NVIDIA (TensorRT-LLM) | 推論引擎中實現 chunked context / inflight batching | 硬體+軟體棧整合 |
投資邏輯
核心觀點
Chunk Size 本身不是一個可投資的”概念”，但它所處的位置揭示了幾個投資主題：
-
RAG 工程化工具鏈：Chunking 是 RAG 管線中最”髒”的環節（需要大量人工調優），這意味著自動化 chunking 最佳化工具存在產品化空間。關注 LangChain/LlamaIndex 的商業化進展，以及新興的 RAG-as-a-Service 平台。
-
Embedding 模型進化：Late Chunking 等技術降低對 chunk 策略的敏感度，長上下文 embedding 模型成為關鍵。關注 Jina、Cohere 等 embedding 專業廠商。
-
推論 serving 效率：Chunked Prefill 提升長 prompt 場景的 serving 效率，直接關係到推論服務的經濟性。關注 vLLM、SGLang 生態及其商業化實體。
-
向量資料庫：多粒度索引策略增加向量儲存需求，利好向量資料庫廠商（Weaviate、Pinecone、Milvus/Zilliz 等）。
-
隱性壁壘：企業積累的 chunk 策略調優經驗（針對其特定文件型別）構成資料飛輪壁壘——好的 chunk 策略 → 更好的檢索 → 更好的 LLM 輸出 → 更多使用者反饋 → 更好的調優。這種飛輪在垂直領域（法律、醫療、金融）尤其顯著。
風險點
- 長上下文模型可能削弱 RAG 需求：如果模型 context window 足夠大（如 >1M tokens）且推論成本足夠低，“全部塞進 prompt”可能成為簡單替代方案。但短期內（2025），長上下文的推論成本仍然過高，RAG 仍是主流。
- Chunk Size 調優的”鍊金術”屬性：目前缺乏系統性理論，大量依賴經驗調參，可能被更好的自動化方法取代。
常見誤讀糾偏
❌ 誤讀 1：“Chunk Size 越小檢索越準，所以應該儘量切小”
糾偏：Chunk Size 過小會導致語義斷裂。例如，一個完整的因果推論（“因為A，所以B”）被切到兩個 chunk 中，檢索到任何一個 chunk 都無法完整回答問題。最優 chunk size 是語義完整性與檢索粒度的平衡點，不存在”越小越好”的簡單規律。實際工程中，256–512 tokens 是經過大量實驗驗證的”甜區”，但需要結合具體文件型別和任務驗證。
❌ 誤讀 2：“Chunk Size 是 RAG 專屬概念”
糾偏：Chunk Size/Chunking 在 AI 系統中至少出現在三個層面——RAG 文件切分、LLM 推論 Prefill 排程（Chunked Prefill）、分散式訓練的 micro-batch 切分。三者的”chunk”含義和最佳化目標完全不同。混淆三者會導致在討論中產生歧義。
❌ 誤讀 3：“選好 Chunk Size 就能解決 RAG 檢索質量問題”
糾偏：Chunk Size 只是 RAG 質量的影響因素之一。其他關鍵因素包括：
- Embedding 模型質量（通常比 chunk size 影響更大）
- 檢索演算法（BM25 vs 語義檢索 vs 混合檢索）
- Reranking 策略（二階段檢索的 reranker 質量）
- Query 改寫與擴充套件
- 文件預處理質量（OCR、表格解析等）
在很多實際案例中，切換 embedding 模型或加入 reranker 帶來的提升遠大於調 chunk size。
❌ 誤讀 4：“所有文件應該用統一的 Chunk Size”
糾偏：不同型別文件的最優 chunk size 不同。FAQ 適合短 chunk，技術手冊適合按章節切分，法律合同適合按條款切分。生產級 RAG 系統通常需要按文件型別/來源分別配置 chunk 策略。
學習路徑
入門（2–4 小時）
- LangChain 文件 — Text Splitters 章節：瞭解固定切分、遞迴切分的基本 API
- LlamaIndex 文件 — Node Parser 章節：瞭解語義切分、視窗切分等高階策略
- 動手實驗：用同一份 PDF，分別以 256/512/1024 tokens 切分，對比檢索結果質量
進階（1–2 天）
- Anthropic “Contextual Retrieval” 博文（2024）：理解 chunk 邊界資訊損失的系統性解決方案
- Jina AI “Late Chunking” 博文（2024）：理解從”先切再編碼”到”先編碼再切”的範式轉換
- vLLM/SGLang 文件 — Chunked Prefill 章節：理解推論 serving 層面的 chunk 概念
- “RAG 應用實戰”類教程：在真實資料集上做 chunk size 的 grid search 實驗
專家（持續）
- 閱讀原始論文：
- FlashAttention 系列（理解 tiling block 與上層 chunk 的層次關係）
- LongRoPE / YaRN 等位置編碼論文（理解 context window 如何影響 chunk 策略選擇）
- 關注 SGLang / vLLM 的 GitHub issues 和 PR：工程前沿的 chunk 排程最佳化討論
- Benchmark 自建：在自己的業務資料上建立 chunk 策略的自動化評估 pipeline
一句話總結
Chunk Size 是大型模型系統中”分而治之”策略的核心旋鈕——在 RAG 中它決定檢索粒度，在推論中它決定排程效率，在訓練中它決定資源利用——沒有萬能值，只有與文件型別、模型能力、硬體約束聯合最佳化後的”區域性最優解”。
延伸閱讀與來源
| 資源 | 型別 | 連結/出處 |
|---|---|---|
| LangChain Text Splitters | 架構文件 | [LangChain 官方文件] |
| LlamaIndex Node Parsers | 架構文件 | [LlamaIndex 官方文件] |
| “Contextual Retrieval” | 博文 | [Anthropic 官方部落格, 2024] |
| “Late Chunking” | 博文/論文 | [Jina AI, 2024] |
| SGLang Chunked Prefill | 技術文件 | [SGLang GitHub/docs] |
| vLLM PagedAttention & Chunked Prefill | 技術文件 | [vLLM GitHub/docs] |
| FlashAttention-2 | 論文 | Dao et al., 2023 |
| Megatron-LM | 論文/程式碼 | Shoeybi et al., NVIDIA |
| ”Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” | 原始 RAG 論文 | Lewis et al., 2020 |
⚠️ 資料說明：本文中的定量資料，若標註 [估算] 則為基於行業經驗的合理推斷；若標註 [廠商文件] 則建議讀者查閱對應廠商最新文件獲取精確數字。本文件撰寫時網路檢索未成功返回結果（HTTP 403），部分資料依據領域通識，建議交叉驗證。