上下文检索

看看这个被单独检索出来的文本块：

哪个产品？哪次发布？哪个端点？这个文本块在它自己的文档里清清楚楚，孤立出来却几乎没用。

这就是分块的核心弱点：让检索变精确的切分，同时也摧毁了让文本有意义的上下文。上下文检索（contextual retrieval）就是把这份上下文补回去。

前置上下文

最直白的做法。在索引阶段，给每个文本块加上一句它所在位置的说明：

这行面包屑只花几个 token，却同时改变了两件事。embedding里现在带上了主题，于是这个文本块既能匹配关于速率限制的查询，也能匹配关于 v2.4 的查询。而拿到这个文本块的模型，也知道自己在读什么。

对结构化文档来说这几乎是免费的——标题路径本来就写在源文件里。这是分块流水线上性价比最高的一项改进，却常常被跳过。

生成的上下文

结构不存在或不够用时，就把上下文生成出来。

在索引阶段，把每个文本块连同它的源文档一起发给一个便宜模型：用一句话说明这个文本块在文档中的位置。 把结果前置到文本块前面。

这能解决面包屑解决不了的问题——消解代词、点明主语、说清讨论的是哪个版本或哪个实体。

代价是索引阶段每个文本块一次便宜的模型调用，只付一次。对一个有几万个文本块的语料库来说，这是一笔真实但有上限的开销，而且 prompt 缓存能帮上大忙，因为源文档会在它自己的所有文本块里重复出现。

这项技术在检索准确率上的已报告提升幅度相当大，对任何你会反复查询的语料库，索引成本都值回票价。

小块检索，大块投喂

这是应对同一组矛盾的另一种思路，而且往往最干净。

用小而精确的文本块做 embedding 和匹配。一旦命中，就把它所属的父级章节而不是它本身发给模型。

检索上拿到了精确度——小文本块的 embedding 更聚焦；生成上也拿到了上下文，因为模型看到的是完整章节。索引阶段零生成成本。

代价是上下文窗口的消耗：父级章节比文本块大，能塞进去的数量更少。章节大小适中时效果好，文档又长又平铺时效果差一些。

实现起来，不过是在每个文本块旁边存一个父级指针。

邻块扩展

更轻量的变体：存下相邻文本块的链接，命中后把紧邻的邻居一起带上。

比父级检索更省，而且能覆盖答案横跨边界这种常见情况。它没那么有原则——邻居可能与问题无关——但实现成本几乎为零。

和其他手段配合

这些技术和其他的检索改进可以叠加使用，各自解决不同的问题：

四项全用的流水线，效果远好于一项都不用的，而且这些改进基本互相独立。上下文检索和混合检索都在提高召回率；重排序提高的是精确率。

实操要点

先加面包屑。 几乎免费，而且它能确认你的问题到底是不是上下文丢失。

加进去的上下文要短。 一句话或一行面包屑。冗长的前言会稀释文本块自身的 embedding，反而违背初衷。

把上下文和文本块一起索引，让它参与 embedding 计算。只在生成时拼接，帮得到模型，对检索毫无贡献——而好处有一半在检索这边。

量一下检索命中率，一如既往：对答案已知的真实问题，正确的文本块有没有被捞出来？只有这个数字能告诉你上面这些工作到底有没有用。

要点回顾

• 分块会摧毁上下文；在文档里清清楚楚的文本块，孤立出来可能毫无意义。
• 前置面包屑（文档 > 章节 > 小节）——几乎免费，同时改善 embedding 和模型的理解。
• 生成的上下文——索引阶段每个文本块一句模型写的说明——解决代词和主语缺失。
• 小块检索、大块投喂，不花索引阶段的生成成本，就同时拿到精确度和上下文。
• 把补进去的上下文一起索引，让它影响检索，而不只是生成。

下一篇： GraphRAG