被切分边界拦腰截断的关键句，以及随之消失的答案

你的 RAG 流水线将文档切分为 512 个 token 的片段，并带有 50 个 token 的重叠。这是一个标准的行业默认设置。在你的语料库中，有这样一句话——“除非订单来自欧盟地区（在这种情况下监管窗口为 14 天），否则退款将在 5 个工作日内处理”——它恰好跨越了分块边界。分块 N 包含前半部分。分块 N+1 包含后半部分。

用户提问“欧盟退款需要多长时间”。检索系统给分块 N 打分最高，因为查询嵌入与第一段碎片中的“欧盟地区”对齐。而包含唯一实际答案的分块 N+1 排名太低，无法同时被检索到。智能体回答“5 个工作日”，并自信地引用了分块 N。客户人在法兰克福。答案是错误的。流水线完全按照设计运行。

这种故障模式不会出现在你的分块质量评估中。分块是格式良好的。语料库是格式良好的。嵌入模型是格式良好的。分块之间的边界——你在自己文档中划下的那些线——才是答案所在。

分块器是为上下文窗口而建，而非为了意义

每个流行 RAG 框架自带的默认分块器都是围绕一个约束设计的：嵌入模型的上下文窗口。512 个 token 是编码器能容纳的上限。带有重叠的递归 token 切分既能干净地适应这个上限，又能在索引时保持低廉的计算成本。

这种设计完全没有考虑到语篇逻辑。token 切分器不知道“除非订单来自欧盟地区”是一个从句，其含义取决于它修饰的主句。它不知道合同中带编号的例外情况一旦与它所限定的规则分离，就会失去功能。它也不知道没有表头的表格行是一行没人能理解的数字。切分器只知道 token 和换行符。文档的语篇结构对它来说是不可见的。

增加 50 个 token 的重叠是为了捕捉边界溢出，但重叠是根据典型句子长度校准的。长复合句——那些带有例外、限定条件、前提和豁免条款的句子——经常会超过重叠窗口。而在法律、监管、财务和政策文档中，起到支撑作用的句子几乎总是长句。重叠是为了保护中位数长度的句子。它保护不了那个关键的句子。

2026 年 1 月一项使用 SPLADE 检索对重叠进行的系统分析发现，总体而言，重叠没有提供可衡量的召回率提升，只是增加了索引成本。总量数据隐藏了重叠起关键作用的情况和重叠纯属摆设的情况。它没有区分二者，你的评估套件可能也没有。

为什么分块质量评估会错过这类失败

当运行分块质量评估时，通常会评判两件事：是否检索到了正确的分块，以及该分块是否包含回答问题的句子。在上述被切分的案例中，这两个问题的答案都是“是”。分块 N 被检索到了。分块 N 包含关于欧盟退款的句子。评估通过了。但用户并不满意。

实际的失败在于检索返回了句子的错误一半，而评估没有任何“答案跨越边界”的概念。Top-k 召回率是在分块级别衡量的。金标准答案被锚定在一个分块上。流水线返回了那个分块。评分器记录了一次命中。没有人问过分块的文本本身是否足够——或者模型是否需要读取上方或下方的分块才能真正回答。

这是已知 RAG 病理学——上下文充分性 (context sufficiency) ——在分块领域的对应物。最近的研究表明，即使检索在 Top-k 指标上“成功”，一半以上的复杂检索查询仍缺乏生成正确答案所需的充分上下文。边界切分是导致上下文不足的一个特定原因。检索调用返回了包含问题关键词的分块。该分块不包含问题的答案。生成器随后编造了剩余部分。

具有覆盖意识的评估必须直接测试这一点。获取你的真实语料库。识别那些跨越分块边界的句子。构建专门针对这些句子的查询。将金标准答案跨越边界时的检索召回率作为一个独立指标，与你的总体召回率分开衡量。这两个数字会产生分歧。这个差距就是你一直在交付的故障模式。

真正缩小差距的方法

加载中…