为什么分块问题尚未解决：原生 RAG 流水线如何在长文档上产生幻觉

大多数 RAG 教程都将分块（chunking）视为一个注脚：将你的文档切分为 512 个 token 的块，对它们进行嵌入（embed），存储在向量数据库中，然后继续研究有趣的部分。这在演示示例（如维基百科文章、干净的 markdown 文档、短 PDF）中表现良好。但在生产环境中，它会分崩离析。

最近一项将 RAG 应用于临床决策支持的研究发现，在 30 个临床问题中，固定大小的基准方案仅实现了 13% 的完全准确率。在同一语料库上采用自适应分块方法：完全准确率为 50% (p=0.001)。文档是相同的。LLM 是相同的。只有分块方式改变了。这种差距不是微调问题，也不是提示词工程问题。它是大多数团队在切分文档方式上的结构性失败。

令人不安的事实是，分块是承重级的基础设施，而几乎每个框架的默认设置对于复杂的实际文档来说都是错误的。

语义分块悖论

对朴素固定大小切分的直觉修正方案是语义分块：嵌入每个句子，检测相似度下降，并在主题过渡处设置分块边界。这听起来是一个明显的升级——尊重语义边界的分块应该能实现更好的检索并生成更好的答案。

FloTorch 2026 基准测试在 50 篇学术论文（共 90.5 万个 token）上测试了这一点。语义分块实现了 91.9% 的检索召回率——位居榜首。端到端答案准确率：54%。而采用 512 个 token 的递归切分（这种结构上更简单的方法）实现了 69% 的端到端准确率。

解释在于语义分块过度碎片化了。基于相似度的边界检测倾向于产生非常小的分块——FloTorch 的研究发现每个分块平均只有 43 个 token。一个 43 个 token 的分块检索起来具有手术级的精准度：它能找到你正在寻找的那句确切的话。但 43 个 token 很少包含足够 LLM 生成正确答案的上下文。你从错误的段落中检索到了正确的句子，但它已经剥离了使其具有意义的上下文论证。

高检索召回率与低生成准确率并存，这就是语义分块悖论。它暴露了 RAG 评估中的核心衡量问题：团队优化的是检索指标（NDCG、recall@k），并发布了在真正重要的指标（用户是否得到了正确的答案？）上表现不佳的系统。

固定大小分块的真实失败模式

固定大小分块的失败方式则不同。它不是过度碎片化，而是随意切分。在生产环境中经常出现的三个具体的失败模式：

指代关系断裂。 一份法律文件在第 1.2 节中定义了“本公司”。文档的其余部分交替使用“它”、“该公司”和“该实体”。一个从第 7 节开始的 512 token 分块包含“该实体不应……”，但不包含指代对象。嵌入模型将“该实体”与用户关于公司义务的查询匹配。LLM 要么捏造所指的公司，要么给出一个空洞的答案。

定义与规则分离。 税收法规文档、API 规范和法律合同通常只定义一次术语，然后反复引用。固定大小的分块将定义与其应用语境分离开来。一个调用已定义术语的查询会检索到应用该术语的分块，但没有定义——LLM 必须猜测或幻觉出该定义。

边界污染。 切分边界处的边缘分块会无意中将前一个章节的最后几句与下一个章节的开头几句结合在一起。这两个章节单独来看在主题上是连贯的；但边界分块内部是矛盾的。检索时，它会将混乱直接注入到上下文窗口中。

LlamaIndex 对一份财务 10-K 报表的分块大小评估发现，忠实度（无幻觉）在 1024 token 的分块时达到顶峰。较小的 128 token 分块幻觉率明显更高——这不是因为模型变差了，而是因为检索到的片段缺失了回答正确所需的上下文。

哪里是所有分块策略的瓶颈

表格、代码和结构化数据是目前所有分块策略失败最严重的地方——而这也是大多数生产文档的所在地。

表格。 标准文本切分器将表格内容视为散文。分布在两个分块中的财务表格意味着标题行在分块 N 中，而数据行在分块 N+1 中。这两个分块本身都没有意义。NVIDIA 的 2024 年基准测试显示，页面级分块在 FinanceBench 上表现最好，正是因为 PDF 页面往往能保持表格的完整性——它们并非有意而是偶然地保持了表格的原子性。

代码块。 递归切分器会在函数体中间切断，将文档字符串与函数签名分离，或将类定义与方法实现分离开来。检索到的分块在语法上是无效的，或者在语义上具有误导性。一个被要求解释函数的代理得到的是没有签名和返回类型的循环体。

多栏 PDF 和扫描文档。 对于复杂的布局，PDF 文本提取是有损的。在多栏文档中，阅读顺序会被打乱。表格变成杂乱无章的散文。在已经损坏的提取文本上进行分块会放大这种错误。

正确的缓解措施需要将分块视为内容类型感知的：针对代码采用基于 AST 的切分（尊重函数和类的边界），专门的表格提取（无论大小，将每个表格视为一个原子单元），以及针对混合布局 PDF 的页面级或章节级分块。大多数框架默认都不提供这些功能。

延迟分块（Late Chunking）究竟修复了什么

延迟分块（Late Chunking, 2024）颠倒了标准流水线的顺序。它不再是先分块再嵌入，而是让整个文档先通过 Transformer 的注意力层，然后在对应分块边界的 token 跨度上进行均值池化（mean pooling）。每个块的嵌入都以所有周围上下文为条件。

BeIR 数据集上的基准测试结果是真实的：NFCorpus（平均文档长度为 1,590 个字符）在检索准确率上显示出 28% 的相对提升（nDCG@10 从 23.46% 提升至 29.98%）。与文档长度的相关性是关键发现——收益随文档长度而增加。短文档没有收益。接近模型上下文窗口的长文档收益最大。

延迟分块无法解决的问题：它无法解决由于分块过小导致的生成失败，它对表格或代码没有帮助，且依赖于模型。2025 年的一项研究发现，在相同的 NFCorpus 基准测试中，使用某种嵌入模型（Stella-V5）的延迟分块与早期分块产生的结果几乎相同，而使用 BGE-M3 的延迟分块效果明显差于标准分块。延迟分块是针对兼容模型的长文档文本检索的一种有用技术，而非通用解决方案。

此外还有成本：延迟分块需要让完整文档运行在嵌入模型的注意力机制中，这意味着内存消耗随文档长度而非分块长度而增加。在长文档语料库上，入库时间和内存压力会大幅增加。

文档层级结构解决的是另一个问题

分层索引——同时在多个粒度（文档 → 章节 → 段落 → 句子）上进行索引——解决了与单层分块不同的另一类失败。

它针对的失败模式是：分析性查询需要综合各章节的信息，而精确的事实性查询则需要尽可能小的片段。单一的固定分块大小无法同时满足这两者。像“这五年的预测中，利率假设分别是什么？”这样的查询需要具有足够上下文的章节级分块来提供完整覆盖。而像“2023 年的利率是多少？”这样的查询则需要段落级分块以保证精度。

分层索引根据查询类型将查询路由到适当的粒度级别，并使用父文档检索（parent-document retrieval）：找到匹配的小块，然后将父级章节返回给 LLM 进行生成。这在保留检索精度的同时提供了生成所需的上下文。

运维开销是客观存在的：你需要维护多个索引级别，按比例增加存储空间，并需要一个路由层来确定查询哪个级别。对于具有强层级结构的文档（法律文件、技术规范、医学指南），准确率的提升足以覆盖其成本。对于扁平的对话数据，这属于不必要的复杂性。

隐藏问题的评估差距

分块失败在生产环境中持续存在的原因是，大多数团队在开发期间衡量了错误的指标。

检索指标（recall@k, NDCG, MRR）衡量的是正确的文档块是否出现在 top-k 结果中。它们并不衡量这些分块是否包含生成正确答案所需的充足上下文。Chroma Research 对 472 个查询和 5 个语料库的评估发现，仅分块策略的选择就能产生高达 9% 的召回率差异——但其召回率最高的策略（通过 GPT-4o 进行的 LLM 引导分块）仅实现了 3.9% 的 token 级 IoU 精度。这是在灾难性的低精度下的高召回率。

正确的评估栈：

• 忠实度（Faithfulness）（RAGAS 术语）：答案中的断言是否基于检索到的上下文？这能直接捕捉到由分块失败引入的幻觉。
• 上下文精度（Context precision）：检索到的块是否真的与查询相关，还是仅仅在主题上邻近？
• Token 级 IoU：检索到的块与标准答案跨度在 token 级别上是否有重叠，而不仅仅是在文档级别？
• 端到端准确率：最终答案是否与参考答案匹配，而不仅仅是检索到的块？

仅针对开发语料库运行检索指标，是团队如何交付一个基准测试召回率 90% 以上、而现实世界答案准确率仅 50% 系统的方法。当评估包含来自实际生产语料库中代表性文档类型的生成指标时，这一差距才会缩小。

生产环境中真正有效的方案

不存在通用的最优分块大小。研究文献对此已达成共识：512 token 适用于收益报告，1024 token 更适合金融问答，页面级别适用于混合布局的 PDF。正确的答案取决于文档结构、查询分布和嵌入模型。

在大多数生产工作负载中适用的稳健默认方案：

• 以 512 token 进行递归拆分并保留 10-25% 的重叠，其胜出并非因为聪明，而是因为结构上的安全性。它在 FloTorch 基准测试中的端到端准确率超过了语义分块，入库成本为零，且生成的索引大小可预测。
• 将表格和代码视为原子单元。 绝不要从中途拆分。在入库时检测内容类型并路由到专门的解析器。
• 对章节使用父文档检索。 以小分块粒度检索以保证精度；在生成前扩展到父章节以获取上下文。
• 使用生成指标进行评估，而不仅仅是检索指标。 在代表实际文档语料库的保留开发集上，评估忠实度和答案准确率。在选择分块策略之前进行测试，而不是在索引了 50 万份文档之后。

《重构上下文》（Reconstructing Context）论文中 2025 年的结论是准确的，值得重申：延迟分块和上下文检索都不能从根本上解决 RAG 系统中的上下文保留问题。两者都在计算成本和检索质量之间涉及显著的权衡。

分块并不是框架中 TextSplitter 里已经封装好的、已解决的问题。它是一项主动的设计决策，决定了你的 RAG 系统是给出准确答案，还是给出听起来自信的错误答案。这一选择值得像模式设计（schema design）或 API 契约定义一样投入工程严谨性——而不是因为教程没提到要修改它，就保留一个默认参数。