RAG 文档分块策略完全指南

一、为什么分块是 RAG 的”第一道坎”

聊 RAG ，大家习惯性盯着两个东西：检索算法够不够准、生成模型够不够强。但真正跑过生产环境的人都知道一个尴尬的事实——RAG 里最容易被低估、又最能搞坏整个系统的，是文档分块。

分块这一步太不起眼了。就是把长文档切一切嘛，能有多难？结果就是，太多人用默认参数一刀切，然后对着检索不到、答案跑偏、上下文爆炸的问题抓耳挠腮。

说白了，你检索出来的东西质量再高，如果块本身切得有问题，后面几百万的向量检索优化都不好使。分块是地基。地基歪了，楼怎么盖都不稳。

二、分块为什么这么要命

几句话就能讲清楚。

第一，长文档整段嵌入会稀释信息。一个两万字的 PDF 塞进一个向量里，任你嵌入模型多强，”第三章第七节那个关键结论”跟”免责声明第三段”在向量空间里分不开——它们长在同一篇文档里，上下文是乱的。

第二， LLM 不是无底洞。每个模型都有上下文窗口上限，你塞进去的文档块太大，要么直接溢出被截断，要么勉强塞进去挤占了后面真正相关的内容。

第三，普通用户不会精准提问。你用”第三章第七节”去检索自己切好的块当然很方便，但用户问的是”那个关于…的结论是什么”——分块不对，语义就搭不上。

这就引出了最核心的问题：你到底按什么规则切？

三、固定大小分块

这是最直接的做法。给每个块定义一个固定的 token 数（比如 256 或 512 ），把文档从头到尾均匀切开。

优点：实现简单、可控、容易调试。对结构规整的长文档——比如纯叙述性的研究报告——效果通常不差。

缺点也很明显。句子和段落被强行切断。”作者认为…”在一个块的结尾，下一个块开头是”…因此该结论不成立”。语义单元碎了。检索的时候你拉回来的是半句话，大模型被迫脑补，幻觉可能从这儿就开始了。

怎么缓解？不少方案加一个”重叠窗口”：块与块之间共享一部分内容。比如块大小 256 token ，窗口重叠 50 token——这样第 N 块的末尾会同时出现在第 N+1 块的开头，被切断的信息至少有个过渡。

但这种补救本质上还是笨办法，对于结构复杂的文档还是不够用。

四、基于句子的语义分块

比固定大小聪明一些的做法是，按句子边界切。先做分句——找出每个句子的起止位置——然后以句子为单位，累积 token 数，达到阈值时才切一刀。

好处：不再把一句话拦腰截断。每个块里都是完整的句子，检索拉回的片段读起来通顺，生成质量自然会好一些。

难处：不同语言的句子结构不一样。中文还好，英文里缩写（ Mr.、 U.S.）和标点混在一起，分句规则要做很多特判。而且”按句子分”不等于解决所有语义问题——一段话的几个句子可能讲不同的事，被硬塞进同一个块里。

五、基于语义的结构化分块

这是更进一级的思路：让分块器理解文档的结构。

给你一个 Markdown 文档，一级标题（#）就是一个天然的分割边界。先把文档切成几个大段，每个大段下面按二级标题再切，直到每个块的 token 数在合理范围内。对 PDF 文档可以做更复杂的处理——提取章节标题、识别表格和列表、保留代码块完整性。

这种方式的优点是语义对齐度高，检索出来的块大概率是完整的逻辑单元，不是碎片。

六、递归分块

递归分块不预设单一的切分标准。它会维护一套”分隔符层级”——通常优先级是段落符 → 句号 → 问号/感叹号 → 逗号 → 单个词。先试图用最高优先级的分隔符切，如果切出来的块仍然太大，就降级，尝试下一级分隔符。直到所有块都在 token 预算内。

优势：在不同类型文档之间迁移时不用频繁手工调参，兼容性很强。

代价：复杂度和计算开销都比固定分块高。

七、到底哪种策略最好

没有银弹。我得说清楚这一点。

如果你在做一个快速原型，先上固定大小分块（带重叠窗口），把整个 RAG 管线跑通，观察效果。如果检索结果明显破碎——比如生成出来的内容前后矛盾、引用原文时断章取义——那多半是分块的锅，需要考虑语义分块。

如果你的文档结构化程度高——内部的技术手册、 Markdown 格式的接口文档——基于标题的分块方案比什么高级算法都直接有效。反之，你的文档库格式混乱，有的 PDF 缺标题、有的网页嵌套多层表格——那递归分块的兼容性优势就体现出来了。

最优解是混合的。对结构化的文档走语义分块，对无结构或弱结构的文档用递归分块兜底，同时在索引构建阶段保留元数据（文档类型、章节编号、标题层级），检索时做二次过滤。分块策略本身就应该被当作一个可配置的组件，而不是开箱即用的默认开关。

八、分块这件事，调参比选模型更重要

一个容易被忽略的事实：调整分块大小对最终效果的影响，很多时候比换嵌入模型还大。

同样用 text-embedding-3-large ，块大小从 256 调到 512 再调到 1024 ，能在同一个问答基准上产生显著的准确率波动——而且不同文档类型的最佳值不一样。法律文档需要更细的粒度以捕捉精确的条款语义，技术报告则需要更大的上下文窗口来保留推导逻辑。没有放之四海皆准的最优值，但有一个适用的调参原则。

所以别迷信”最好的分块器”。没有。只有最适合你文档类型、提问方式和生成任务的分块策略。

总结

分块是 RAG 系统里最容易被人跳过、也最容易拖后腿的环节。它不需要多漂亮的算法包装，但需要的是对文档结构、 LLM 行为和向量检索三者交互逻辑的深度理解。一个对的分块策略，胜过十层检索优化。