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)及后续对比研究
免责声明:本页面内容仅供技术学习与产业研究参考,不构成任何投资建议、产品选择建议或对未来行情的预测。所有市场数据来自第三方公开报告,仅反映发布时的预测,未保证准确性。