如何为 RAG 做文档分块

分块（chunking）看起来只是个预处理细节。它却是决定检索增强生成（RAG）质量的两大因素之一，另一个是重排序。

原因很直接：文本块就是检索的单位。 如果一个问题的答案横跨两个文本块，那哪个块里都没有答案，再怎么优化 prompt 也救不回来。

核心矛盾

小文本块能产生精确的 embedding：一个向量只装一个集中的意思，相似度分数才有意义。但它会丢掉周围的上下文。一个文本块写着「不建议在生产环境使用」，却不知道它指什么，那就毫无用处。

大文本块保住了上下文，却把语义糊成一团。一个 2000 词的文本块覆盖六个主题，产出的 embedding 是六件事的平均，对每个相关查询都只能弱弱地匹配，没有一个匹配得强。它还会把上下文窗口浪费在无关文本上。

没有普遍正确的尺寸。但有一种思路是对的——别再按字符数来切。

先按结构拆

最常见的错误是不管内容是什么，每 1000 个字符切一刀。这一刀会落在句子中间、表格中间、函数中间。

文档本身就有有意义的边界，直接用。

Markdown 和 HTML 有标题。一个标题下的内容通常是一个完整的意思——作者在那里加标题就是这个原因。按标题拆，只有超出尺寸上限的章节才需要继续细分。

代码有函数、类和模块。把一个函数劈成两半，只会得到两个没用的文本块。语法感知的拆分能尊重这些边界。

PDF 是最难的一类。文本提取往往在分块开始之前就把结构毁掉了，一张被搅乱的表格产生的噪声，会一路流到后面每个环节。先把提取修好，再调文本块大小——这里冒出来的 RAG 问题比人们以为的多。

转录稿和聊天记录按发言人轮次或话题切换来拆，不按固定长度。

递归拆分是务实的兜底方案：先试段落边界，再试句子边界，最后试词，只有当文本块还是太大时才往下退一级。多数库都实现了它，当文档没有可用结构时，这是合理的默认做法。

重叠

把每个文本块的末尾一段放进下一个块的开头——常见做法是 10-20%。

这样能缓和边界带来的损伤。一句被拆开的句子，至少会在其中一个块里是完整的。这是对付最糟失效模式的廉价保险。

代价是存储，以及一些重复检索：两个重叠的块同时命中，说的内容几乎一样，却占了两份上下文。在拼 prompt 之前把重叠的邻近块去重，值得做。

把上下文补回来

既然小文本块会丢上下文，那就显式地把上下文补回去。几种做法，大致按投入从低到高排列：

在前面加上面包屑。 把文档标题和标题路径跟每个文本块一起存：Product Docs > Billing > Refunds: <chunk text>。实现起来很简单，却能明显改善检索效果，也让模型更容易理解自己收到了什么。

小块检索，大块发送。 用精确的小块做 embedding 和匹配，但把块所在的父章节发给模型。检索时拿到精确率，生成时拿到上下文。这比任何尺寸调优都更干净地化解了核心矛盾。

加一句生成的摘要。 建索引时用一个便宜的模型给每个文本块写一句上下文说明，跟块存在一起。有效，代价是多跑一遍索引。

存下邻近块链接。 保存指向相邻文本块的指针，需要时就能把一次命中扩展到它周围的内容。

元数据

建索引时大方地存：来源文档、章节路径、日期、作者、权限、URL、文档类型。

过滤要用它（只要当前版本的文档、只要这个用户有权看的），引用来源要用它，排查问题也要用它。事后补加意味着全部重新建索引，所以宁可存多。

实用的起点

对叙述性文本，一个合理的默认配置是：结构感知的拆分，每个文本块目标 500-1000 个 token，重叠 10-15%，前面加面包屑。

然后就照着测量结果调，而不是凭感觉调。真正重要的指标只有一个：拿一组有已知答案的真实问题，正确的文本块到底有没有出现在检索结果里？这一个数字就能告诉你，问题是不是出在分块上。如果正确的块根本检索不到，调 prompt 纯属白费力气。

同一个语料库里的不同内容类型，通常要用不同的策略。代码、文字型文档和客服工单的分块方式各不相同，硬用一套策略套住所有内容，是要牺牲质量的。

要点回顾

• 文本块是检索的单位——答案一旦横跨边界，就再也检索不到。
• 小文本块给出精确的 embedding，但会丢上下文；大文本块糊掉语义，还浪费上下文。
• 按结构拆（标题、函数、轮次），不要按固定字符数；递归拆分是好的兜底方案。
• 重叠 10-20% 缓和边界损伤，再去重掉重叠的命中结果。
• 小块检索、大块发送和前置面包屑，都能直接化解尺寸上的两难。
• 先测正确的文本块有没有被检索到，再动其他东西。

下一篇： 什么是向量数据库？