知识问答常先检索一批候选片段，再用 reranker 重新排序，选少量内容交给生成模型。Kapa 的新分析把“没找到”和“找到后被丢掉”分开：在公司知识问题上，逐段跟踪完整正确答案所必需的 gold chunks，观察它们在哪一步消失。
作者在所分析的流水线中使用查询分解、候选检索和 Voyage 重排，最后保留前15段。结果是，已经被检索找到的必要片段中，约34%没进入最终上下文。这个分母是已找到的必要片段，不是全部问题；它也不表示只换重排器就能恢复34%的回答成功率。文章把这理解为筛选越来越值得投入，而搜索本身仍会遗漏材料。
增加保留数可以改善召回，但不能无限堆进去。相关却过时的版本说明、相似产品的文档，可能使回答选错依据；公司知识还散落在工单、论坛和发布说明中，同一概念未必用同一组词。因而代码检索中好用的 grep，不能不加条件地替代所有知识检索。
Kapa 倾向让检索 Agent 维护并修剪工作上下文，而非只追加内容。它引用的 SID 路线更强调召回：没有取回来的文档，后续模型再强也救不回来。这两种关注可同时成立，真正的设计问题是在哪一层承担筛选，以及错误筛选是否还可撤销。文章与相关基准均由产品团队提供，本轮没有找到同配置的独立复测。