AWS 给企业用 AI 算账：让便宜小模型先过滤文档，省钱但不省事

这是什么

AWS 这周在官方博客抛出一个数字：企业 RAG 系统每次提问平均要召回 5–20 段素材全部塞给主模型（Claude Sonnet），输入 token（计费单位）越多，单次问答越贵——RAG 账单的隐形大头往往不是模型推理，而是这些「喂进去的字数」。

RAG（Retrieval Augmented Generation，检索增强生成）就是企业把 AI 接进自家知识库最常见的工程做法。AWS 给出的解法叫「query-aware compression」（按查询感知的压缩）：在检索完成、主模型回答之间，插一个便宜的小模型（Claude Haiku），先当「质检员」把无关段落删掉，再交给主模型接手。

行业怎么看

我们注意到，技术上不新鲜——「用便宜模型预处理」是 LLM 工程里的经典级联思路（不同档位模型分工协作）。AWS 真正的价值是把包装做轻：代码以 Lambda 函数（按调用次数计费的轻量计算）形式给出，能直接挂在 Bedrock 知识库、重排序接口、prompt 缓存上叠加使用。

不过编辑部里有不同声音。反对意见两点：第一，这是战术修补，不是结构改良——RAG 成本压力的根源是「上下文窗口越开越大」和「模型越来越贵」，小模型过滤只是把一部分成本挪到另一个前置环节；第二，对中小团队来说，多引入一个模型意味着调试命中率、维护两套 API 权限，工程复杂度上去了，省下的 token 钱未必覆盖得过来。

另外，AWS 博客只给「显著降低 input token」的定性结论，没披露横向对比数字和不同业务场景下的稳定性数据——这本身就是一个信号：他们更想让你动手试，而不是承诺结果。

对普通人的影响

对企业 IT：如果你正在评估或已经上线 RAG 应用，这是少数几个「今天就能动手」的成本优化点，但前提是团队里有能维护两套模型的人，纯业务方驱动很难落地。

对个人职场：暂时与你无关。除非你在数据或 AI 工程岗位，否则「RAG token 成本」不会出现在你的 KPI 里；但知道这个机制，能让你跟 IT 沟通时听懂他们在心疼什么预算。

对消费市场：消费级 AI 产品（ChatGPT、文心一言等）暂不受影响——成本由厂商消化。但企业级 AI 助手若大规模铺开，更便宜的 RAG 会让公司更愿意把 AI 嵌入客服、培训、合规这类内部流程，长期看会改变你日常工作界面里「和谁对话」的对象。