用查询感知压缩降低 Bedrock RAG 成本
AWS Bedrock 提出查询感知压缩方案，用小模型过滤检索片段，降低主模型输入 token 与幻觉风险。
在 Amazon Bedrock 上运行检索增强生成（RAG）应用时，输入 token 往往是整体成本中不可忽视的一部分。AWS 机器学习团队近日介绍了一种「查询感知压缩」（query-aware compression）方案，通过在检索后、主模型生成前引入小模型过滤步骤，在保持答案质量的前提下显著降低输入 token 数量，并附带削减幻觉风险的好处。
核心思路：小模型先压缩，大模型再作答
传统 RAG 流程倾向于追求高召回率，从向量索引中取回 top-k 个文档片段（通常 5–20 个），全部拼接到 prompt 中交给主模型生成答案。这一做法能让构建者放心地把信息交给主模型，但当片段数与单片段长度叠加时，单次查询的输入 token 容易攀升到数千个。
查询感知压缩的解决思路是在主模型调用前，先用一个成本更低的小模型（博文中使用 Claude Haiku）读取所有检索片段与用户查询，只输出与问题直接相关的原文片段。随后，主模型（Claude Sonnet）只在压缩后的上下文上生成最终答案。由于小模型单 token 价格远低于主模型，过滤动作带来的输入缩减即可转化为显著的成本节省。
实现架构
该模式运行在 AWS Lambda 函数内，与 Bedrock 上的检索器（包括 Bedrock Knowledge Bases，背后由 Amazon OpenSearch Serverless 提供支持）兼容，整体流程可概括为：
- 用户提交查询，应用向检索器发起请求；
- 检索器返回 top-k 个完整文档片段；
- Lambda 函数将查询与全部片段通过 Converse API 发送给压缩模型；
- 压缩模型输出与查询相关的精简片段；
- Lambda 函数将查询与压缩上下文再次通过 Converse API 交给主模型生成答案。
相比标准 RAG 流程，这只多出一次「压缩调用」，对整体架构的侵入较小。
成本与延迟权衡
节省幅度取决于两个变量：小模型与主模型之间的价格比，以及压缩比 c。博文中给出简化成本公式：原始检索片段为 R 个 token、压缩比为 c 时，主模型的输入 token 数从 R 降至 R/c；整体成本为压缩步骤开销与主模型节省之差。需要注意的是，这一模式会增加一次额外模型调用，对延迟敏感型应用需在成本与响应速度之间做权衡。
与现有 Bedrock 能力叠加
查询感知压缩可与 Bedrock 已有的多项能力组合，进一步放大节省效果：
- Prompt Caching：缓存重复的 prompt 部分；
- Intelligent Prompt Routing：在多个模型之间按需路由；
- Rerank API：对初检结果重新排序以提升相关性。
通过多层叠加，开发者可以在不显著影响答案质量的前提下，压缩 RAG 端到端的运营成本。该模式兼容同一模型家族内任意「小/大」模型组合，构建者可根据自身业务对延迟、成本与质量的偏好灵活选型。