Matteo Bortoletto、Janis Fluri · Kapa · 阅读原文
原始来源：Matteo Bortoletto、Janis Fluri · Kapa
发现渠道：Hacker News · AI
知识问答常先检索一批候选片段，再用 reranker 重新排序，选少量内容交给生成模型。Kapa 的新分析把“没找到”和“找到后被丢掉”分开：在公司知识问题上，逐段跟踪完整正确答案所必需的 gold chunks，观察它们在哪一步消失。
作者在所分析的流水线中使用查询分解、候选检索和 Voyage 重排，最后保留前15段。结果是，已经被检索找到的必要片段中，约34%没进入最终上下文。这个分母是已找到的必要片段，不是全部问题；它也不表示只换重排器就能恢复34%的回答成功率。文章把这理解为筛选越来越值得投入，而搜索本身仍会遗漏材料。
增加保留数可以改善召回，但不能无限堆进去。相关却过时的版本说明、相似产品的文档，可能使回答选错依据；公司知识还散落在工单、论坛和发布说明中，同一概念未必用同一组词。因而代码检索中好用的 grep，不能不加条件地替代所有知识检索。
Kapa 倾向让检索 Agent 维护并修剪工作上下文，而非只追加内容。它引用的 SID 路线更强调召回：没有取回来的文档，后续模型再强也救不回来。这两种关注可同时成立，真正的设计问题是在哪一层承担筛选，以及错误筛选是否还可撤销。文章与相关基准均由产品团队提供，本轮没有找到同配置的独立复测。
可信度 65 · 重要性 86 · 新颖度 75
技术与主题
Agent 系统 · 评测与基准 · 检索与知识 · RAG · Reranking · Context Selection
编辑评读
这项分析提供了一个比“换更强 embedding”更具体的排查入口：给必要证据保留经过各阶段的记录。若候选池已有答案，继续改善第一轮搜索未必有效；若材料根本没找到，扩大上下文也无济于事。不要只看最终回答分数，应先知道证据在哪个交接点丢失，再决定投入查询改写、排序还是上下文管理。
筛选目标也应与任务相连。单文档事实题需要压低噪声，跨版本排障则可能需要同时保留冲突说明及日期。可在固定问题上比较不同保留数，记录必要证据覆盖、错误版本引用和回答质量，并允许 Agent 返回被暂时排除的候选。这是编辑建议，尚未测试；Kapa 的一条生产路径不能证明整个检索行业已经完成瓶颈迁移。
需要留意
- 34%是已召回必要片段中的后续丢失比例；公司案例及自建基准，非全行业或独立复测结论。