AI 功能上线后成本失控的几个常见原因

AI 功能的成本在试点阶段几乎看不出来，因为用量小。推广到全员或对外开放之后，账单往往数倍于预估，而原因通常不是单价，是几处设计上的放大。

四个典型来源

1. 召回材料过长：每次问答都把十几段材料全塞进去，其中多数与问题无关。输入侧用量是企业场景的成本主项；
2. 重复提问没有缓存：同样的问题每天被不同的人问几十遍，每次都重新调用；
3. 失败重试放大：解析失败、超时重试，一次用户请求实际发生了三次调用，而监控上只记了一次；
4. 对话历史无限累积：多轮对话把全部历史每轮重发，到第十轮时输入长度已经是第一轮的几倍。

对应的几道闸

召回侧设上限并按相关度排序，只取前几段；相关度低于阈值的直接不传，宁可让模型回答材料不足。这一项通常能砍掉相当比例的输入量，而对答案质量影响有限 —— 不相关的材料本来就帮不上忙。

缓存按「问题语义 + 知识库版本」做键。知识库没变、问题相同的，直接返回上次结果。注意一定要带版本，否则内容更新后仍返回旧答案。

重试要有上限并计入用量统计。更重要的是把重试原因记下来 —— 如果大部分重试源于输出格式解析失败，那应当去改提示词而不是加大重试次数。

多轮对话采用滚动窗口加摘要：保留最近几轮原文，更早的压缩成一段摘要。完整重发全部历史，在长对话里是最容易被忽略的成本来源。

按用户和场景分别计量

只有总账单，出问题时无法定位。应当按功能模块、按用户或部门分别记录调用量与消耗，这样能看出是某个场景异常、还是少数用户在高频使用。多数情况下成本集中在少数几个入口上，而找到它们比全面优化有效得多。

预算告警与降级

• 设置日级与月级的用量阈值，接近时告警而不是等账单出来；
• 超限后的行为要预先定义：降级到小模型、排队、还是暂停并提示用户稍后再试。不定义的话，超限时的表现由代码默认行为决定；
• 对外开放的入口要单独限流，按用户、按 IP 设上限，避免被批量调用；
• 把成本纳入上线检查项，而不是只检查功能是否可用。

这些机制在AI 智能体解决方案与企业知识库解决方案的实施阶段应当一并确定，上线后再补通常意味着已经付过一次学费。