账单上的四类钱
推理调用、检索与向量存储、平台与网关、以及人力与运营。前两类随用量走，后两类常被当成固定投入。为什么要把四类分开：只看调用费会漏掉检索与人力，优化时也容易挑错对象。
上下文是最大变量
系统提示、工具定义、检索片段与多轮历史都会进入每次请求。做法是统计平均输入长度并排序，先砍低价值片段与过期历史；边界是砍完要跑评测，确认召回与准确性没有明显下降。
失败与重试的隐形成本
超时、限流与格式错误都会触发重试，一次失败可能产生两到三次计费。怎么查：按请求链路看失败率与重试次数，把重试放大系数算出来；系数超过一定水平时，先修稳定性比谈折扣更有效。
优化顺序别跳过第一步
先削调用次数（去重、合并、缓存），再削单次长度（提示压缩、历史摘要），最后才谈单价与模型替换。为什么按这个顺序：反了会怎样：单价降了但调用次数涨回来，总账没变，团队还多了维护成本。
适用与不适用
适合谁
- 月度 AI 支出已可观测、可归因的企业
- 客服、内容与研发等多场景并用的组织
- 有平台团队能改动调用链路的公司或部门
不适合谁
- 调用量很小、账单占比可忽略的团队或试点
- 无法改动业务系统调用方式的场景与产品
典型场景
一家保险公司的理赔助手每月账单持续上涨。团队按请求链路拆开，发现三分之一的调用来自页面重复提交，另有大量请求带入了整份条款。先做前端去重与条款切片，再把历史摘要压缩，账单随即回落。
可执行步骤
- 按场景与调用链拆开账单，标出花费最高的前三个场景与触发原因
- 统计平均输入长度与检索片段占比，找出可削减的部分并排序，形成清单
- 查各链路的失败率与重试次数，算出重试放大系数与主因，尤其看超时与限流
- 先做去重、合并与缓存，再改提示词与历史摘要策略，逐步上线
- 每次改动后跑同一组评测，确认质量与召回未明显下降再放量，观察一周
常见坑
- 只谈模型单价，不查调用次数与重试，单价降了两成，账单反而更高，团队还很困惑。
- 把整份制度文档塞进提示，输入长度翻倍，回答却没有更好，成本全花在冗余内容上。
- 砍提示词不做评测，答案开始漏项，业务方不再信任系统，最后改回去，来回折腾，信任很难恢复。
- 缓存策略没设过期，旧答案被反复复用，错误在几周后才被发现，追溯起来非常困难。
自检与验收清单
- 账单是否按场景与调用链拆分到可归因
- 平均输入长度是否有基线并可对比，是否按月更新
- 重试放大系数是否算过，异常是否有人跟
- 每次优化是否都跑过同一组评测集，结果是否留档
- 改动是否留有可一键回滚的开关，谁能一键回滚
常见问题
上下文压缩会不会影响准确性
会有影响，取决于压缩方式。抽取式摘要比自由改写更稳，关键条款与数字应保留原文。建议先用一组带标准答案的样本对比压缩前后，准确率下降在可接受范围内再上线，并保留回滚。
重试是技术问题还是成本问题
两者都是。技术上重试是容错手段，成本上每次重试都计费。合理做法是限制重试次数、加退避与熔断，并把重试率纳入稳定性指标；只压成本不修稳定性，重试还会回来。
优化到什么程度算够
看边际收益。通常先做去重与缓存，收益明显且风险低；继续压缩与降级时，收益递减而评测成本上升。建议设定阶段性目标，达到后转入监控，而不是无限优化。