AWS 为其 Bedrock 服务增加了查询感知压缩（query-aware compression）功能，允许开发者在文档块到达语言模型之前对其进行修剪，剔除无关内容。通过减少传输到模型的 token 数量，该功能可以降低检索增强生成（RAG）流水线的计算费用。

为什么 RAG 流水线如此烧钱

RAG 系统首先从知识库中提取文本段落，然后将这些段落输入生成式模型以回答用户的问题。大多数实现方式会将检索到的每个数据块直接发送给模型，即使文本的大部分内容与查询毫无关系。每一个额外的单词都会变成一个 token，而模型处理的每个 token 都会增加底层 API 的费用。对于运行客服机器人或内部搜索工具的中小型企业来说，token 的支出可能会迅速超过模型调用本身的成本。

查询感知压缩的作用

新的 Bedrock 功能在检索和生成之间插入了一个过滤步骤：

  • 系统仍会针对查询检索相同的一组文档。
  • 在模型看到任何文本之前，一个轻量级处理器会根据具体问题对每个段落进行评估。
  • 只有被判定为相关的部分会被保留；其余所有内容都将被视为噪声丢弃。

你不需要新的索引、embedding 模型或微调后的语言模型。这种变化仅仅是重新配置流水线以调用压缩层。

业务影响

由于 token 费用随发送到模型的文本量增加而上升，移除无关片段可以逐项减少账单金额。那些随着使用规模扩大而面临 RAG 成本激增的企业将获得最大的收益。

后续关注点

  • 在自有数据上试点该功能：将标准 RAG 流程与包含查询感知压缩的流程进行对比测试。测量 token 数量、延迟和回答的相关性。
  • 供应商透明度：在评估第三方 RAG 平台时，询问他们在检索流水线中是否采用了压缩或过滤技术。如果供应商直接发送原始数据块，可能会产生更高的每月账单。

总结

对流水线进行微小的调整——在文本到达模型之前过滤掉无关内容——可以将隐藏的开支转变为可控的预算项目。对于已经在为基于 Bedrock 的 RAG 付费的组织来说，启用查询感知压缩是一项低成本的实验，但任何节省程度都将取决于你的具体数据。