RAG 分块策略：分块大小、重叠和边界检测如何影响检索质量

大多数构建 RAG 管道的团队将时间花在优化嵌入模型、向量数据库和提示模板上。他们将分块视为一个细节——将文档分成片段、生成嵌入、继续前进。这是一个错误。分块是影响检索质量最大的单一变量，做错了会级联影响每一个下游步骤。

糟糕的 RAG 分块策略会产生过于通用而无法匹配特定查询的嵌入，或者过于碎片化而无法携带有用上下文的嵌入。检索器返回不相关的段落。生成器产生幻觉或模棱两可。用户失去信任。修复方案很少是更好的模型——而是更好的分块。

为什么分块比你想象的更重要

当用户查询 RAG 系统时，检索器搜索与查询语义最相似的分块。如果你的分块每个有 4,000 个 token，嵌入代表的是该块中所有内容的平均值。具体细节被稀释了。关于特定合规条款的问题返回一个包含三页不相关政策语言的分块，模型不得不在其中寻找被埋藏的相关句子。

如果你的分块每个有 50 个 token，你会得到相反的问题。嵌入捕获的是没有周围上下文的句子片段。检索器可能找到正确的片段，但生成器无法从一个被切成两半的句子中产生连贯的答案。

最好的企业文档 RAG 分块工具让你可以控制三个变量：分块大小、重叠百分比和边界检测方法。这三个设置相互影响，正确的组合取决于你的文档类型。

固定大小分块 vs. 语义分块

最简单的方法是固定大小分块：无论内容结构如何，将每个文档分成 N 个 token 的块。这种方法快速、可预测且易于实现。但对于大多数企业用例来说，这也是错误的默认选择。

固定大小分块完全忽略文档结构。一个 512 token 的窗口可能会将表格一分为二，在句子中间切断段落，或者将一个章节的结尾与一个不相关章节的开头合并。结果产生的嵌入是嘈杂的，检索质量也会受到影响。

语义分块尊重文档中的自然边界。它不是在固定的 token 计数处分割，而是在句子边界、段落分隔或章节标题处分割。分块大小各不相同，但每个分块代表一个连贯的语义单元。嵌入更加干净，检索更加精确。

为 RAG 检索分块 PDF 的最佳方式几乎总是带有最大大小约束的语义分块。你设置一个上限——比如 512 个 token——分块器在低于该限制的最近自然边界处分割。这给你带来了固定大小分块的一致性和语义分块的连贯性。

边界检测方法

并非所有边界都是相同的。正确的边界检测方法取决于你的文档结构。

句子边界在句子结束标点处分割。这是非结构化文本最安全的默认选择——文章、电子邮件、支持工单、法律文书。每个分块包含完整的句子，因此嵌入捕获完整的思想。缺点是句子级别的分块可能非常小，特别是在句子较短的文档中。

段落边界在双换行符或显式段落标记处分割。这适用于格式良好的文档——报告、合同、政策手册。每个分块捕获一个完整的想法或论点。段落级别的分块往往更大、更自包含，这提高了生成器的性能，但代价是检索精度略有降低。

章节边界在标题处分割（HTML 或 Markdown 中的 H1、H2、H3，或 PDF 中检测到的章节标题）。这是最激进的边界检测，最适合高度结构化的文档——技术文档、合规框架、产品手册。每个分块映射到文档的一个逻辑章节，这使得检索结果更容易追溯到其来源。

在实践中，你需要分层边界检测：首先尝试章节边界，如果章节太大则回退到段落边界，最后作为兜底回退到句子边界。这种方法在混合文档类型中产生最一致有用的分块。

重叠：被忽视的设置

分块重叠是相邻分块之间共享的 token 百分比。如果你有 512 token 的分块和 10% 的重叠，每个分块与下一个分块共享大约 51 个 token。这些共享的 token 出现在两个嵌入中。

为什么这很重要？没有重叠，跨越分块边界的信息就会丢失。一个从 token 510 开始到 token 530 结束的句子被分割到两个分块中，两个分块都没有捕获完整的含义。重叠确保跨越边界的内容至少在一个分块中以完整形式出现。

代价是存储和计算。更高的重叠意味着每个文档有更多的分块，这意味着更多的嵌入需要存储和更多的候选项需要搜索。对于大多数企业部署，最佳点在 10% 到 20% 的重叠之间。低于 10%，你会丢失太多边界上下文。高于 20%，你存储的冗余信息收益递减。

零重叠仅在你的边界检测足够可靠、没有有意义的内容跨越边界时才适用——通常是在结构良好的文档上进行章节级别的分块。

按文档类型的实用设置

下表总结了常见企业文档类型的推荐初始配置。这些是起点——你应该用自己的检索基准来验证。

衡量分块质量

在不衡量影响的情况下配置分块设置就是猜测。你需要一个反馈循环：更改设置、重新分块、重新生成嵌入，并在一组测试查询上评估检索质量。

重要的指标是检索精度（检索到的分块中有多少百分比实际相关）、检索召回率（相关分块中有多少百分比被检索到）和答案质量（生成器是否从检索到的分块中产生了正确、完整的答案）。

一个常见的失败模式是仅优化精度。你可以通过使分块极其大来获得完美的精度——每个分块包含答案，因为每个分块包含一切。但这浪费了上下文窗口并降低了生成器性能。目标是仍然携带足够上下文让生成器产生好答案的最小分块。

Ertas 如何处理分块

Ertas 的 RAG Chunker 节点让你直接控制分块大小、重叠百分比和边界检测方法——句子、段落或章节。你可以按管道配置这些设置，这意味着你可以在同一个工作流中对不同文档类型使用不同的分块策略。

可视化管道在每个阶段显示元素计数，因此你可以立即看到将分块大小从 512 更改为 256 个 token 如何使文档数量翻倍。这种可见性使得在提交配置之前实验设置并了解其影响变得切实可行。

分块之后，Quality Scorer 节点通过检查截断的句子、过短或过长的分块以及内容连贯性来验证分块质量。这在早期捕获配置错误——在不良分块传播到嵌入和索引之前。

入门指南

如果你正在构建 RAG 管道但还没有花时间在分块策略上，从这里开始：

1. 识别你的主要文档类型及其结构特征。
2. 选择与你的文档结构匹配的边界检测方法。
3. 将分块大小设置为 512 个 token 作为基线，并根据检索基准进行调整。
4. 从 15% 的重叠开始，仅在存储成本是一个问题时才减少。
5. 在代表性查询集上衡量检索精度和召回率。
6. 迭代设置直到检索质量达到你的阈值。

最佳的 RAG 分块策略不是一个通用配置——而是一个将分块设置与文档特征匹配并用真实查询验证的系统化过程。投入这个过程的团队始终优于将分块视为事后考虑的团队。