如果把 RAG 系统比作一道菜，Embedding 模型是火候，向量数据库是锅具，那 Chunk 切分就是刀工。刀工不对，再好的食材也出不来好菜。
一、为什么 Chunk 切分如此重要？
RAG 检索的文档切分是关乎检索质量的关键步骤，如何高效正确地切分，直接决定了能否检索到正确的答案。
切分之所以关键，原因有二：一方面，向量 Embedding 模型通常有输入长度限制，长文档必须切分才能处理；另一方面，即使模型支持长输入，把整篇文档作为一个向量也会导致语义被稀释——一篇万字长文的 Embedding 向量很难精准匹配一个具体的细节问题。
但切分又是一把双刃剑：切得太粗，语义不够聚焦；切得太细，上下文信息断裂。下面从简单到复杂，逐一介绍常见的切分策略。
二、基础切分方法
固定大小切块 + Overlap
这个方法最简单：设定一个固定的 token 数（比如 512 tokens），把文档按这个长度等分切割。同时加上一定比例的 overlap（重叠），让相邻 chunk 之间共享一部分内容，以减少语义断裂。
但缺点也很明显：非常容易把完整语义切割成两部分。一个句子可能上半句在 chunk A，下半句在 chunk B，导致两个 chunk 都丢失了完整含义。即使加上 overlap 也会有这个问题——overlap 一般只加 5%-10%，很难保证每次都刚好覆盖到语义边界。而且如果 overlap 加得太多，会造成存储和检索成本上升，重复内容还会干扰 LLM 的阅读和理解。
适用场景：对切分质量要求不高、追求实现速度的原型验证阶段。
按语义边界切割
按文本的自然结构边界切分。找出文中的自然语义边界——比如句子结束的位置、段落结束的位置——将每个语义完整的单元单独切成一块。
实现上一般需要借助 NLP 工具（如 spaCy、NLTK）来识别句子边界。对于段落分明的文档，还可以在句子边界的基础上优先在段落边界处切，效果更好，因为一个段落通常围绕一个主题展开，本身就是天然的语义单元。
适用场景：文章结构清晰、段落分明的文档，如技术文档、博客文章。
三、语义驱动切分
语义切分（Semantic Chunking）
用 Embedding 模型判断句子之间的语义相似度，在语义断崖处切分。
核心思路：
- 连续句子语义相似度高 → 归为同一个 Chunk
- 相邻句子语义相似度骤降 → 这里是分界点，应该切开
优点：真正按语义切分，不依赖文档格式和标点符号，即使文档结构混乱也能找到合理的切分点，效果在自动化方案中最好。
缺点：计算成本高——需要对每个句子做 Embedding 并计算相邻句子的相似度，速度慢。对于大规模文档，这一步的开销可能超过后续检索本身。
适用场景：文档结构不规范、但语义内容重要的场景，如抓取的网页、用户上传的杂散文本。
命题化切割（Proposition Chunking）
在切割前，调用 LLM 将原文改写为一个个独立的、自包含的"命题"，然后基于这些命题进行切分和存储。每个命题都包含完整上下文，无需依赖其他命题即可理解。
举个例子，原文是"它于 2023 年发布，采用全新架构，性能翻倍"，命题化后会变成：
- “X 产品于 2023 年发布。”
- “X 产品采用全新架构。”
- “X 产品的性能相比上一代翻倍。”
每个命题都自包含，不再出现"它"这类指代不明的词。
这种方式的质量最高，同时也是成本最高的——因为需要调用 LLM 来理解整篇文章，适合有极高质量要求的场景。
适用场景：对检索质量要求极高的企业级知识库、合规文档、精密问答系统。
四、结构化切分
基于结构切分
利用文档的固有结构进行切分，比如 Markdown 格式的标题层级、HTML 的标签、PDF 的目录等。
优点：效率高，可以利用文档结构快速定位切分点，不需要额外的模型计算。同时，标题等结构信息本身就是很好的语义信号——一个标题下的内容通常属于同一主题。
缺点：需要文档本身结构规范，杂乱的文档无法使用。而且不同格式的文档（Markdown、HTML、PDF、Word）需要不同的解析逻辑，维护成本较高。
适用场景：文档来源可控、格式统一的内部知识库。
递归切割
按文章层级逐级切分：每层尝试用一种分隔符切，如果该层切不了就退到下一层。
LangChain 的 RecursiveCharacterTextSplitter 就是这个思路：
- 先按
\n\n（双换行）切段落 - 段落太长的，再按
\n（单换行）切行 - 行还太长的，再按句子切
这种"先大后小、逐级细化"的策略，在不借助任何 NLP 工具的情况下，也能较好地兼顾语义完整性和 chunk 大小控制。而且它只依赖文本中的分隔符，处理速度很快。
适用场景：通用场景，也是目前 RAG 框架中最常用的默认方案。
五、检索增强切分
以上方法都是在"写入时"做文章，下面几种策略则在切分和检索的配合上做文章。
父子切割（Parent-Child Chunking）
所谓父子切割，就是先切一个大 chunk（父），再将大 chunk 切成几个小 chunk（子），并建立父子映射关系存储：
- 小 chunk 用于向量检索——粒度细，匹配更精准
- 检索命中后，返回对应的父 chunk 给 LLM——上下文更完整
虽然父子切割和递归切割都有"层级"的概念，但两者不是一回事。递归切割是一种切分策略，先找大的切割再找小的切割，本质存的还是一个 chunk。父子切割是将大小 chunk 一起存进去，配合检索策略——小粒度检索、大粒度返回。
适用场景：希望检索精准度高的同时，为 LLM 提供更充分上下文的场景。
句子窗口切割
句子窗口切割，也是在检索阶段做文章的策略。实际实现中，通常用滑动窗口（如窗口大小 200 tokens，步长 1 个句子）生成重叠的句子组，每个组作为一个 chunk 存储。
检索命中后，扩展窗口取前后句子形成完整上下文。这样即使命中了一个很窄的片段，最终返回给 LLM 的也是带完整前因后果的上下文，从而通过优化检索逻辑实现了语义的完整性。
适用场景：需要灵活控制上下文窗口大小的对话式问答。
六、Contextual Retrieval（上下文检索）
Contextual Retrieval 是 Anthropic 在 2024 年提出的一种 RAG 优化技术，核心思想是：在将文本块向量化之前，先为每个块生成一段上下文描述，把这段描述和原文拼接后再进行 Embedding，从而解决"孤立块语义缺失"的问题。
Anthropic 官方博客称这是"一种简单但强大的 RAG 改进方法"。
核心流程
原始 Chunk："它采用了最新的 A18 芯片，性能提升了 30%。"
↓ LLM 生成上下文
"[上下文]这段内容来自 X-Phone 手机的介绍文章，X-Phone 是该公司 2024 年发布的新产品。"
↓ 拼接
"[上下文]这段内容来自 X-Phone 手机的介绍文章... [原文]它采用了最新的 A18 芯片，性能提升了 30%。"
↓ 向量化存储这样，即使孤立块中出现了指代词"它"，向量空间中也能通过上下文前缀正确理解其指代内容。本质上，这是在 Embedding 之前用 LLM 给每个 chunk 打了一个"语义标签"，弥补了切分导致的上下文丢失。
成本与优化
为每个 Chunk 单独调用 LLM 生成上下文，成本较高。但可以利用 Prompt Cache 做优化：
- 整篇文档作为静态前缀，所有 Chunk 的请求共享这部分内容
- 实际只需额外付出每个 Chunk 自身内容的请求成本
前提条件：① LLM 支持 prompt cache 功能（如 Claude 3.5 Sonnet 及以上）；② 整篇文档能放入上下文窗口。如果文档超长，可以先用摘要模型压缩，再作为上下文前缀使用。
适用场景：对检索质量有高要求、且能接受额外 LLM 调用成本的企业级 RAG 系统。
七、切分策略对比
| 切分方法 | 核心思路 | 语义保留 | 成本 | 适用场景 |
|---|---|---|---|---|
| 固定大小 + Overlap | 按 token 数等分 | 差 | 极低 | 原型验证 |
| 语义边界切割 | 在句子/段落边界切 | 中等 | 低 | 结构清晰的文档 |
| 语义切分 | 相似度断崖处切 | 好 | 中 | 非结构化文本 |
| 基于结构切分 | 按标题/标签切 | 好 | 低 | 格式统一的文档 |
| 递归切割 | 逐级降级切分 | 中等 | 低 | 通用场景 |
| 父子切割 | 小粒度检索，大粒度返回 | 好 | 中 | 需要充分上下文的问答 |
| 句子窗口切割 | 滑动窗口 + 检索扩展 | 好 | 中 | 对话式问答 |
| 命题化切割 | LLM 改写为自包含命题 | 最好 | 高 | 高质量要求场景 |
| Contextual Retrieval | LLM 生成上下文前缀 | 最好 | 高 | 企业级 RAG 系统 |
总结
Chunk 切分没有银弹。选择哪种策略，取决于三个核心约束：
- 文档特征：结构是否规范？内容是叙述性还是罗列性的？
- 质量要求：对检索准确率的要求有多高？
- 成本预算：能承受多大的计算开销和 LLM 调用成本？
从实践角度来看，大多数项目可以从递归切割起步，在基准测试中发现不足后，再根据具体痛点逐步引入语义切分、父子切割，甚至是 Contextual Retrieval。先跑通，再优化，始终是 RAG 系统构建的务实原则。