Kapa 构建 AI 助手，可以根据大型产品知识库回答复杂问题。想象一下技术文档、API 参考、PDF、论坛、支持线程。开发人员使用我们的检索 API 为他们的代理提供产品的上下文，并且同样的检索层支持我们的端到端助手。尽管在2026年关于代理是否仍然需要 RAG 的争论，但在我们的领域，当知识库变得庞大和复杂时，没有什么能与之相比。我们的检索有多种形式，有些是代理式，有些是单次检索，但它们都有相同的结构：一个检索器，找到与问题相关的文档片段，一个生成器，即根据这些片段撰写答案的 LLM。该帖子的简短版本：我们在两者之间增加了第三步。一个小而廉价的 LLM 一次性读取问题和所有检索到的片段，并在昂贵的模型看到之前扔掉答案不需要的片段。它削减了约68%的上下文，保留了约96%的召回率，并在其自身成本的基础上将查询成本降低了三分之一。本文解释了我们是如何做到的。被忽略的片段仍然需要花费金钱。检索器就像一个漏斗。嵌入和关键词搜索将数十万个片段缩减为几百个候选项，重新排序器排列它们，前15个左右的片段到达生成器，这是链中最大和最昂贵的模型。即使如此，生成器读取的大部分内容对于问题而言并不是必需的。这是故意的：检索器旨在最大限度地提高召回率，并相信生成器会忽略噪音。但生成器会为每一个它忽略的片段收费。在我们的助手中，检索到的片段大约占查询成本的三分之二，多于答案、对话历史和系统提示的总和。每少一个片段就会将查询成本降低约4%。在代理中，每个工具调用都会将其输出倾注到相同的上下文中，因此上下文快速增长；更紧凑的检索结果为代理必须保存的其他所有信息腾出空间，并减少了腐烂的上下文。问题是召回。丢掉一个答案所需的片段，你就用几个分的代价换来了错误的答案。修剪者的效果正是取决于这个权衡：每失去一点召回率所获得的压缩。显而易见的解决方案并不能奏效。我们已经在返回前 K 之前进行重新排序，所以有时要求我们仅暴露重新排序分数，让调用者在其上进行裁剪：保持所有高于 0.7 的片段，丢弃其余的。这失败了两个原因，第二个原因塑造了我们所构建的一切。第一，重新排序分数是一个排序，而不是一个度量。它表示片段 A 在此查询中胜过片段 B，仅此而已。分数在不同查询之间没有经过校准，Cohere 也表示这一点，因此没有固定的截止值能够奏效。排名支撑的唯一截止值是位置上的，即 top-N，这将丢弃最后一个片段，无论它是噪音还是答案。第二点，即使完美校准也无法解决：相关性并不是单个片段的属性。大多数管道中的重新排序器是点对点交叉编码器。它们独立地给每个查询-片段对评分，从不与其他检索到的片段并排考虑。这里有一个匿名的生产示例：第二个片段从未提及审核日志，因此它被评分为噪音，但它是答案的一半，没有任何点对点评分可以看出来，因为该片段仅在与第一个片段的上下文中相关。片段也在它们之间拆分多部分问题，每个片段单独无用。真正的问题从来不是一个片段是否单独相关，而是它是否属于一个能够共同回答问题的集合。一个聪明的但以相同方式失败的修复方案。在放弃重新排序器之前，我们尝试了锚文档 (Sinhababu et al.)：通过将已知相关性的合成片段植入排序中（每个级别写一个，从必需到无关），使重新排序器的规模绝对化，然后丢弃每个排名低于最低级别锚定的真实片段。再加上已经运行的重新排序的 LLM 调用，实在是优雅。它并没有奏效，原因也是相同的。锚点修正了校准，但无法修正分数，并且重新排序器仍然将部分和间接相关的片段放在明显不相关的片段之下。为了保留它们，锚点必须坐得足够低，以至于几乎没有内容可以被修剪。这个失败提供了有用的结果：任何修剪都必须同时看到问题和所有片段，因为被评判的是集合。因此，我们让一个 LLM 评分这些片段。我们发布的功能是一个列表 LLM 调用置于重新排序器和生成器之间。它获取问题和所有片段，并根据其提示中写入的五个级别的规模对每个片段进行评分：LLM 分数级别含义 5 必需 该答案无法在没有此片段的情况下生成，无论它是直接回答还是其他片段依赖的定义或前提。 4 贡献 独立无法回答，但为完整答案提供连接其他片段所需的内容。 3 支持 主题相关且可能有用，但...