文章摘要
Kapa.ai在RAG系统中增加了一个小型LLM作为中间步骤，在检索器和生成器之间过滤掉约68%的不相关上下文，同时保持96%的召回率，使每次查询成本降低三分之一。
文章总结
Kapa.ai 开发了一款 AI 助手，用于回答大型产品知识库中的复杂问题，涵盖技术文档、API 参考、PDF、论坛和支持线程等。其检索系统包含检索器和生成器两个核心部分：检索器从知识库中提取相关文档片段，生成器（即 LLM）则基于这些片段撰写答案。然而，检索器为了最大化召回率，通常会提供大量片段，其中许多对回答问题并非必要，但生成器仍需为这些无关片段付费，这导致查询成本中约三分之二来自检索到的片段。
为解决这一问题，Kapa.ai 在检索器和生成器之间引入了一个新的步骤：使用一个小型、低成本的 LLM 作为“修剪器”。该修剪器同时读取问题和所有检索到的片段，并丢弃那些生成答案时不需要的片段。具体来说，修剪器根据一个五级评分标准对每个片段进行评分：5 分（必需）、4 分（贡献）、3 分（支持）、2 分（边缘）、1 分（无关）。只有评分达到或超过设定阈值的片段才会保留。这种方法解决了传统重排序的缺陷，因为重排序分数是相对的，且无法评估片段之间的组合价值，而修剪器通过同时查看所有片段，能够判断哪些片段共同构成完整的答案。
在实验中，修剪器丢弃了约 68% 的上下文，同时保留了约 96% 的召回率，并将每次查询的成本降低了约 34%（扣除修剪器自身的成本）。修剪器的运行时间约为 0.7 秒，虽然增加了少量延迟，但生成器的响应速度略有提升，不过不足以完全抵消修剪器的开销。Kapa.ai 首先在代理场景中部署了修剪器，因为代理通常需要处理多个工具调用，减少上下文可以为其他任务腾出空间，且代理在发现信息缺失时可以重新搜索。目前，修剪功能在其产品代理 SDK 的知识库搜索中默认启用，并在检索 API 和 MCP 服务器中作为可选功能提供。
评论总结
根据评论内容，总结如下：
主要观点与论据：
对“RAG”术语的质疑：评论2认为“RAG”一词被滥用，应更精确地称为“语义检索”或“向量检索”，类比为“将直接燃油喷射称为燃料空气混合系统”。（引用："Am I wrong to be somewhat peeved by the use of 'RAG' in these contexts?"；"this is akin to saying 'fuel air mixture system' when referring to direct fuel injection"）
对修剪策略的批评：评论4指出基于相关性的修剪可能遗漏关键信息，尤其是罕见但重要的内容（如禁忌症、例外情况），建议按结构而非分数修剪。（引用："The risk in relevance-based pruning is the same one summarization has: it's tuned to drop whatever's rare"；"What's worked better for me is pruning by structure instead of by score"）
对小型LLM的信任问题：评论6认为小型LLM在处理复杂信息时可能成为瓶颈。（引用："i wouldn't trust the small llm there"；"it will be an intellectual bottleneck"）
对文章原创性的怀疑：评论1认为该话题是旧概念循环炒作，受社交媒体机器人推动，并质疑作者意图。（引用："Cliche topic - from a few years ago"；"Pruning RAG Context is trying to recycle the old stuff"）
对方法的肯定：评论3认可使用评分表让LLM对文本块进行Likert评分的方法。（引用："They used a rubric to have the LLM grade the chunks on a Likert scale"；"I think this is a good way to coax numbers out of an LLM"）
对能源效率的关注：评论5强调上下文处理对能源和时间的敏感性。（引用："Context is so incredibly energy and processing time sensitive"）
平衡性总结：评论呈现了正反两方观点。支持方认为修剪方法（如评分表）有效，且能节省能源；反对方则质疑术语准确性、修剪策略的可靠性、小型LLM的能力，并认为话题缺乏新意。整体上，批评声音更为突出，尤其关注修剪可能丢失关键信息的问题。