Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
必须按 token。问题数量没意义，同样一次请求，带 2 条历史和带 30 条历史成本差很多。
还要分输入和输出。很多 API 输入、输出单价不同，输出通常更贵。
我们的系统每次带全量聊天历史，还有检索到的 8 个 chunk。
那成本高很正常。你们把上下文当免费内存用了。
我们之前也是。用户问“再短一点”，系统又把前面长答案带进去，等于为自己的废话付费。
成本控制不是只限流。要做上下文预算：历史最多多少、检索片段最多多少、输出上限多少。
输出上限会不会影响答案质量？
会，所以按场景设。客服短答 400 token 够，合同分析可能要 2000。别全局一个数字。
还要做异常监控。某个提示词改动后 token 翻倍，要能发现。
评测集里也该记录 token 吗？
该。每条样例记录输入、输出、延迟、费用、是否通过。否则“效果更好”可能只是花钱更多。
那模型选择也要算成本通过率？
对。不是单条最强，是单位成本解决多少真实问题。
这句可以写进评审：每 1000 次有效回答成本，而不是每 1000 次调用成本。
你好！看起来您对这段对话很感兴趣，但您还没有一个账号。
厌倦了每次访问都刷到同样的帖子？您注册账号后，您每次返回时都能精准定位到您上次浏览的位置，并可选择接收新回复通知（通过邮件或推送通知）。您还能收藏书签、为帖子顶，向社区成员表达您的欣赏。
有了你的建议，这篇帖子会更精彩哦 💗
