RAG 的最佳分块大小是多少？

没有通用答案，但一个不错的起点是 400 到 512 token，搭配 10% 到 20% 的重叠。然后根据查询类型调优：精确事实查找用 128 到 256 token，分析或摘要查询用 512 到 1024 token。与其迷信单一默认值，不如针对自己的问题对几种大小做基准测试。

分块应该有多少重叠？

分块大小的 10% 到 20%——500 token 的分块约 50 到 100 token。重叠可防止语义在边界处被截断；太少会在切分点碎片化上下文，太多则会膨胀索引并导致近乎重复的检索。NVIDIA 发现财务文档约 15% 最优。

semantic chunking 比 fixed-size 更好吗？

并非总是如此。Semantic chunking 按主题对句子分组，听起来更好，但基准测试表明，它相对 recursive 或 fixed-size chunking 的提升并不稳定，往往不足以证明额外嵌入计算的价值。Fixed 和 recursive chunking 仍是强大且低成本的基线——先从这里开始，只有当评估显示出真正提升时才转向 semantic。

什么是 late chunking，何时应该使用？

Late chunking 先用长上下文嵌入模型嵌入整篇文档，再将 token 嵌入汇聚成分块——因此每个分块的向量携带的是整篇文档的上下文，而不仅仅是自身文本。适用于具有长距离依赖关系的长文档，即某个段落只有结合前文上下文才说得通的情形。

contextual retrieval 真的能提升准确率吗？

是的，而且可量化。Anthropic 报告称，为每个分块前置一段 LLM 生成的上下文说明后，contextual 嵌入将 top-20 检索失败率降低 35%，与 contextual BM25 结合降低 49%，再加入重排序后降低 67%——在使用提示缓存时，每百万文档 token 约 $1.02。对于漏掉一个段落就代价高昂的高风险语料库，它最为值得。

什么是 parent-document（small-to-big）retrieval？

它将「如何匹配」与「返回什么」解耦。你为精确匹配索引较小的子分块，但当某个分块命中时，把更大的父级章节交给模型，使其获得周边上下文。这样你既能拿到小分块的召回率，又能拿到大分块的连贯性，两者互不牺牲。

我应该从哪种分块策略开始？

约 500 token、15% 重叠的 recursive chunking。它尊重自然边界、成本低，是大多数内容的强基线。对 PDF 和手册可加上 structure-aware 切分，答案需要更多上下文时用 parent-document retrieval，只有在代价确实值得时才使用 contextual retrieval。

← Resources

By Priya Shah — Senior Engineer, RAG + Knowledge · 2026-05-22 · TUTORIAL

RAG 分块策略：大小、重叠与实际效果

早在检索启动之前，分块就已经决定了 RAG 质量的上限。本指南对比了实践中主流的六种策略，给出具体的大小和重叠数值，并说明哪种策略适合哪类查询。

为什么分块决定 RAG 质量

分块是检索器真正获取的基本单元，因此分块边界决定了所有下游处理的上限。分块太小，每个嵌入的信号不足以被可靠地检索到；分块太大，相关段落的信号会被平均稀释，向量随之变淡，不再与查询匹配。一旦分块出错，任何重排序器或更大的模型都救不回召回率——正确的段落压根没有被检索出来。这正是为什么通常先要调优的是分块，而不是模型选择。

主导实践的六种策略

当前实践大致归为六种方法：

Fixed-size：带重叠的等长 token/字符片段。最古老、最便宜、可复现——而且是出奇强大的基线。
Recursive：按分隔符优先级（段落 → 行 → 句子）切分，在尊重边界的同时把分块控制在大小上限内。推荐的默认选项。
Semantic：依据嵌入相似度对句子分组，使每个分块只对应一个主题。相比 recursive 的提升并不稳定，且需要额外的嵌入计算。
Structure-aware：按文档结构（标题、章节、页面、Markdown）切分。最适合 PDF、手册和财务文档。
Late chunking：先用长上下文模型嵌入整篇文档，再将 token 嵌入汇聚成分块——使每个分块都携带全局上下文。
Contextual retrieval：在索引前，为每个分块前置一段由 LLM 生成的上下文说明。

先从 recursive 入手；当文档类型或查询类型确有需要时，再转向其他策略。

分块大小与重叠：具体数值

没有放之四海皆准的最佳大小，但有不错的起点。先从约 400–512 token、10–20% 重叠（500 token 的分块约 50–100 token）开始。然后让大小匹配查询类型：小分块（128–256 token）更适合精确的事实和关键词查找，较大分块（512–1024 token）更适合注重叙事连贯性的分析和摘要查询。

重叠可防止语义在边界处被截断——太少会让上下文碎片化，太多则会膨胀索引并导致检索重复。NVIDIA 的基准测试发现，财务文档约 15% 的重叠最优，而页面级分块在混合语料库中给出了最高、最一致的准确率，其中事实型查询在 256–512 token 达到峰值，分析型查询在 1024+ 达到峰值。

进阶：contextual retrieval 与 late chunking

两种较新的技术针对的是同一个问题——一个写着「revenue increased 15%」的分块，如果你说不清是哪家公司、哪个季度，就毫无用处。

Anthropic 的 Contextual Retrieval 会在嵌入和 BM25 索引之前，为每个分块前置一段由 LLM 生成的 50–100 token 上下文说明。相对 5.7% 的基线 top-20 失败率，contextual 嵌入将失败率降低 35%，再加入 contextual BM25 降低 49%，进一步加入重排序后降低 67%——在使用提示缓存时，每百万文档 token 约 $1.02。

Jina 的 late chunking 则反转了流程：先用长上下文模型（最多约 8,192 token）嵌入整篇文档，再将已上下文化的 token 嵌入汇聚成分块，使每个分块的嵌入本就携带跨块上下文。适用于具有长距离依赖关系的长文档。

父文档检索与元数据

有两项改进几乎在任何场景都见效。Parent-document（"small-to-big"）retrieval 将检索粒度与生成解耦：为精确匹配而索引较小的子分块（≈100–500 token），但返回给模型的是更大的父级章节（≈500–2,000 token），使其获得周边上下文。而元数据丰富化——为每个分块附加来源、章节标题、页码和时间戳——能改善过滤、支持引用，并独立于分块大小提升检索精度。

在 osFoundry 中选择与调优

快速决策指南：recursive 是安全的默认项；结构化文档用 structure-aware 或页面级；主题密集的文字用 semantic；配长上下文嵌入器的长文档用 late chunking；上下文丢失代价高昂的高风险语料库用 contextual retrieval；既要精度又要上下文时用 parent-document。

osFoundry 把这一切都视为配置，而非代码。Auto-chunking 提供合理的 recursive 默认设置，自定义 RAG pipeline 让你能按知识库分别调优大小、重叠和策略，重排序与 parent-document retrieval 都以 pipeline 阶段开关的形式提供。由于各阶段均可配置，你可以在保持其余环节不变的前提下，针对自己的查询分布——事实型还是分析型——对分块设置做 A/B 测试，这正是研究所推荐的可调参数工作流。

Frequently asked questions

RAG 的最佳分块大小是多少？: 没有通用答案，但一个不错的起点是 400 到 512 token，搭配 10% 到 20% 的重叠。然后根据查询类型调优：精确事实查找用 128 到 256 token，分析或摘要查询用 512 到 1024 token。与其迷信单一默认值，不如针对自己的问题对几种大小做基准测试。
分块应该有多少重叠？: 分块大小的 10% 到 20%——500 token 的分块约 50 到 100 token。重叠可防止语义在边界处被截断；太少会在切分点碎片化上下文，太多则会膨胀索引并导致近乎重复的检索。NVIDIA 发现财务文档约 15% 最优。
semantic chunking 比 fixed-size 更好吗？: 并非总是如此。Semantic chunking 按主题对句子分组，听起来更好，但基准测试表明，它相对 recursive 或 fixed-size chunking 的提升并不稳定，往往不足以证明额外嵌入计算的价值。Fixed 和 recursive chunking 仍是强大且低成本的基线——先从这里开始，只有当评估显示出真正提升时才转向 semantic。
什么是 late chunking，何时应该使用？: Late chunking 先用长上下文嵌入模型嵌入整篇文档，再将 token 嵌入汇聚成分块——因此每个分块的向量携带的是整篇文档的上下文，而不仅仅是自身文本。适用于具有长距离依赖关系的长文档，即某个段落只有结合前文上下文才说得通的情形。
contextual retrieval 真的能提升准确率吗？: 是的，而且可量化。Anthropic 报告称，为每个分块前置一段 LLM 生成的上下文说明后，contextual 嵌入将 top-20 检索失败率降低 35%，与 contextual BM25 结合降低 49%，再加入重排序后降低 67%——在使用提示缓存时，每百万文档 token 约 $1.02。对于漏掉一个段落就代价高昂的高风险语料库，它最为值得。
什么是 parent-document（small-to-big）retrieval？: 它将「如何匹配」与「返回什么」解耦。你为精确匹配索引较小的子分块，但当某个分块命中时，把更大的父级章节交给模型，使其获得周边上下文。这样你既能拿到小分块的召回率，又能拿到大分块的连贯性，两者互不牺牲。
我应该从哪种分块策略开始？: 约 500 token、15% 重叠的 recursive chunking。它尊重自然边界、成本低，是大多数内容的强基线。对 PDF 和手册可加上 structure-aware 切分，答案需要更多上下文时用 parent-document retrieval，只有在代价确实值得时才使用 contextual retrieval。