RAG 成本感知检索：在相关性、上下文长度和推理费用之间设预算

RAG 的成本由很多小步骤叠加：查询改写、embedding、关键词和向量检索、重排、上下文拼接、模型生成、缓存、重试和日志。只盯着最终模型 token，往往会错误地砍掉重排或引用验证，短期省钱，长期增加用户追问和人工支持成本。成本优化必须和回答质量、延迟及风险等级一起被管理。

首先为一次请求建立成本账本。记录每个阶段的模型调用、输入输出 token、向量查询数量、候选数、重排条数、缓存命中、延迟和最终路径。按租户、功能、查询类型和风险标签聚合，而不是只看全站平均值。这样才能发现某个新功能是因为长文档、失效缓存还是无限重试而变贵。

预算应随任务价值变化

低风险 FAQ 可以使用较小的候选数、较短上下文和强缓存；需要精确引用的技术排障可以允许更多检索和重排；涉及用户数据、财务或高风险操作时，优先保证权限、证据和人工确认，不应为了省钱跳过验证。将这些规则写成策略表，输入包括任务类别、用户套餐、时效要求、数据敏感度和当前资源压力。

例如在预算紧张时，系统可以先减少低价值查询的扩展检索、使用已有摘要或延迟后台生成，但不能让受权限保护的查询跳过过滤，也不能在没有证据时强行回答。成本回退必须保留安全不变量。

控制上下文的边际收益

增加 top-k 通常先提升召回，随后很快带来冗余、干扰和更长提示词。通过离线样本测量不同候选数、重排深度和上下文长度的质量曲线，找出边际收益开始变小的位置。线上根据查询意图选择预算，而不是所有问题固定取二十段。

缓存也要按语义和权限设计。公共、稳定的产品文档可以缓存检索结果；用户私有数据、实时指标和权限变化频繁的内容不能共用同一个键。缓存键应包含数据版本、租户、角色和查询规范化结果，命中后仍需检查有效期和授权。

用质量护栏约束降本实验

任何成本优化都要设定不允许下降的指标：安全拒答正确率、引用完整率、关键查询集准确率、零结果率和 P95 延迟。先影子运行新策略，比较成本和这些护栏；若节省来自错误地缩短上下文导致关键问题变差，自动停止灰度。不要等用户投诉后才发现优化只转移了成本。

还要区分按请求计费与按任务计费。一个多轮 Agent 可能在每轮都做检索，局部看不贵，累积却超出用户可接受上限。为 run 设置总预算和剩余预算，把它反馈给规划器：预算不足时优先总结已获证据或请求用户选择，而不是继续盲目搜索。

成本归因需要能落到负责人和变更

成本账本只有能解释归属才会促成改进。将每次请求关联到功能、租户、模型版本、检索策略版本和发布批次，才能在费用异常时回答“是哪次变更、哪类查询、哪个阶段增加了消耗”。不要把所有费用都放在一个 RAG 服务总账下，那会让团队只能猜测并相互推责。

为每个策略设置可见预算和异常检测：某租户的平均候选数突然升高、重试率超过阈值、缓存命中下降或某版本的输出 token 倍增时，先暂停灰度并保留诊断样本。成本异常也要与质量指标并排看，因为有些上升来自更完整的证据，而有些下降来自错误拒答。负责人应能在仪表盘上选择回滚、限流、调整预算或补充缓存，而不是只收到月底账单。

最后，把成本优化的结果回写到内容和产品决策。若某类问题反复触发昂贵检索，可能需要更好的结构化 API、预生成摘要或产品内引导；若某份文档导致大量重排，可能是文档结构而非模型参数的问题。把费用当作系统信号，RAG 才能在规模扩大后持续可控。

预算策略需要防止被提示词间接绕过

用户或模型可能通过“再多找一些”“必须给出十个来源”不断扩大检索范围。预算执行器应把请求级上限放在工具层，并将剩余配额作为只读事实返回给模型。达到上限后，只允许总结已有证据、要求用户缩小范围或创建经审批的异步任务，不能因为模型换了一种措辞就重新开始昂贵搜索。

测试时构造重复追问、循环工具调用和大文档请求，验证总预算、最大轮数和取消信号都生效。这样成本策略既保护平台，也让用户得到可解释的边界，而不是在请求执行很久后突然失败。

延伸阅读

• Token 成本优化
• LLM 成本归因
• RAG 延迟预算