Kapa 构建的 AI 助手能够基于涵盖技术文档、API 手册、PDF 及论坛帖子等庞大知识库回答复杂问题。开发者通过其检索 API 为智能体（Agent）提供产品上下文，该检索层也支撑着端到端的助手服务。

尽管 2026 年业界仍在争论智能体是否仍需检索增强生成（RAG），但在处理庞大且复杂的知识库时，RAG 仍是不可替代的方案。Kapa 的检索架构遵循通用逻辑：检索器（Retriever）查找相关文档片段，生成器（Generator，即大语言模型）基于片段撰写答案。

Kapa 在此两者之间引入了第三个步骤：一个小型且廉价的 LLM 同时阅读问题和所有检索片段，在昂贵的主模型介入前剔除无用内容。该机制丢弃了约 68% 的上下文，保留了约 96% 的召回率，并将单次查询成本降低了三分之一（扣除小模型成本后）。

被忽略的片段依然产生费用

检索过程类似漏斗：从数十万文档中筛选出数百候选项，经重排序器（Reranker）排序后，前 15 个左右片段进入生成器。尽管生成器能忽略噪声，但仍需为读取的所有片段付费。在 Kapa 助手中，检索片段占查询成本的约三分之二，超过答案、对话历史及系统提示词的成本总和。每减少一个片段，查询成本约降低 4%。

在智能体场景中，工具调用输出会汇入同一上下文，导致上下文迅速膨胀。精准检索能为其他信息腾出空间，减少无效堆积。关键在于权衡：剪枝器必须在压缩比与召回率之间取得平衡，若丢弃关键片段，虽节省成本却会导致答案错误。

传统优化方案为何失效

此前，团队尝试直接利用重排序分数截断片段（如保留分数高于 0.7 的内容），但该方案存在两大缺陷：

首先，重排序分数是相对排序而非绝对度量，不同查询间未校准，固定阈值无法通用。唯一支持的截断方式是位置截断（Top-N），但这可能误删关键答案。

其次，相关性并非片段的固有属性。主流重排序器基于点式交叉编码器（Pointwise Cross-Encoders），单独评估 " 查询 - 片段 " 对，无法结合其他片段考量。例如，某片段单独看无关，但与另一片段结合却是答案的关键部分。点式评分无法识别这种集合相关性。

团队还尝试了 " 锚点文档 " 方法，通过植入已知相关性的合成片段使评分绝对化。但该方法仅解决校准问题，未修正评分逻辑，仍会将间接相关片段排在低分位，导致几乎无片段被剪除。

基于列表式 LLM 的剪枝方案

最终方案是在重排序器和生成器之间增加一次列表式（Listwise）LLM 调用。该模型接收问题和所有片段，依据提示词中的五级量表对每个片段评分，保留达到阈值的片段。

该设计解决了前述缺陷：各级别有明确文字定义，固定阈值可行；模型同时查看问题和所有片段，能评估整体集合，合理处理部分相关性和间接相关性。

关键参数包括：

模型选择：选用最快且最便宜的小型快速模型，其成本由节省的费用覆盖。

阈值：调节压缩率和召回率的主要旋钮。

keep-top-k：强制保留排名前几的重排序片段，防止最强片段因评分失误被误删。

团队还对比了 " 预算选择法 " 和 " 直接询问 LLM" 两种简单设计，最终确认评分法表现最优。

实验结果与性能权衡

在标记好的真实问题集和生产环境对话回放测试中，所有 LLM 策略均大幅优于简单的 Top-N 截断基线。若保持 98% 召回率，截断法仅能实现约 7% 的压缩率，而 LLM 策略可达 30% 以上，相关性评分法甚至接近 50%。

Kapa 选择了偏向激进的配置：保留约 96% 的召回率，丢弃约 68% 的片段。这意味着每 25 个问题中有 1 个可能丢失必要片段，但单次查询账单下降约 34%。

在延迟方面，剪枝器运行在关键路径上，选定配置每次查询耗时约 0.7 秒。使用低推理强度的小型模型是将额外延迟控制在一秒以内的关键。虽然生成阶段因输入令牌减少而略微加速，但不足以抵消剪枝器调用开销。因此，这是以少量固定延迟换取显著成本压缩的权衡。对于智能体内部的多步调用场景，这一轻量级调用的影响微乎其微。

应用场景

该功能首先面向在检索服务之上构建智能体的客户推出。智能体携带多种工具，每次调用均占用上下文，剪枝功能减少三分之二的文档搜索结果，为其他操作腾出空间。此外，智能体具备再次搜索能力，轻微召回率损失风险可控。

目前，剪枝功能已在 Kapa 产品智能体 SDK 的知识库搜索中默认开启，并在检索 API 和 MCP 服务器中作为可选功能提供。

【星途科讯 图文丨踢三脚 首发于 ZAKER 科技，转载请注明出处】