企业RAG最隐蔽的一笔账，不是向量检索，而是每个问题都把五到二十段长文塞给主模型。检索为了不漏证据往往宁可多取，回答模型却要为所有无关段落付费。AWS在8月21日给出一套查询感知压缩方案：在检索与回答之间插入一个小模型，只摘取与当前问题相关的原文片段，再让主模型完成最终回答。

不是少检索，而是少让昂贵模型阅读

这套架构没有改变向量库的召回策略。应用照常检索Top-K片段，也可以先调用重排器；随后由价格更低、速度更快的小模型同时读取问题与候选上下文，按要求抽取逐字证据。主模型最终只看到压缩后的片段。这样既保留高召回带来的安全余量，又把无关内容挡在昂贵回答调用之前。

AWS示例用Claude Haiku做压缩、Claude Sonnet做回答，并以Lambda封装中间步骤。方法并不绑定这两个模型，关键是小模型与主模型的价差、压缩率，以及两者对同一领域文本的理解一致性。它还可以叠加提示缓存、智能路由和重排，但每叠一层都要重新计算时延与收益，不能把节省比例简单相加。

36%的成本节省，换来了什么

在公开测试中，单独压缩把主模型输入token降至基线的12%，整体成本降到67%，端到端时延增加19%，综合质量为基线的97.5%。加入重排后，输入token进一步降到10%，成本降到64%，时延增幅收窄到12%，综合质量为97.6%。换算下来，分别是8.6倍和10.1倍的上下文缩减，以及33%和36%的成本节省。

更有意思的是无依据主张：基线回答中，至少包含一条未被证据支持内容的比例为51%；压缩后降到44%，重排加压缩后降到38%。原因并不神秘——主模型面对的噪声更少。但正确性、完整性和引用准确度仍有细微损失，压缩模型一旦漏掉关键限定词，主模型就没有机会恢复。

FDE应该先测四条曲线，而不是先抄架构

这类优化适合检索上下文经常超过约5000 token、问题相对窄、主模型输入价格较高，并且链路能容忍数百毫秒到约一秒额外等待的场景。客服知识库、内部运维助手、法务条款检索和财报问答都符合这一特征。若原始上下文本来很短，或者界面要求亚秒响应，多一次模型调用可能得不偿失。

FDE落地时至少要同时绘制成本、时延、证据召回和回答质量四条曲线。先从真实日志抽样，标注问题所需证据；再比较基线、压缩、重排加压缩三组结果，分别统计关键证据漏失率、引用准确率、无证据主张与P95时延。对于高风险问题，还应在压缩置信度不足时回退到完整上下文，而不是强行省token。

编辑判断：RAG优化进入“按证据付费”阶段

ATYUN认为，这项方法的价值在于把RAG成本问题从“换更便宜的模型”改写为“只让主模型阅读必要证据”。它不要求重建知识库，也不必牺牲召回率，工程改动集中在检索后处理层，因此适合已有RAG系统的小步试点。

但36%不是通用折扣。测试只覆盖一个语料、一个领域和一组查询分布，质量还依赖LLM评审；难题上的节省也低于典型问题。真正可上线的门槛，应是企业自己的黄金问题集、可接受的证据漏失上限，以及高峰期P95延迟。上线后还要按问题类型监控压缩率，防止某类长问答被过度裁剪。若节省来自遗漏证据，账面成本下降只是把费用转移给复核和客服。对于合同、医疗或财务问答，原始片段与压缩片段都应留在审计轨迹中，便于复盘每个答案为何出现，也便于法务与业务共同验收。压缩器的提示词和模型版本也应单独记录，因为它们改变了主模型实际能够看到的证据边界。在这些条件下仍能省钱，这道压缩层才是架构，不是演示。