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 日志。输入、输出、模型、场景、用户、是否命中缓存。没有账本就没法优化。
输出 token 经常被忽视。模型啰嗦一次 1500 字，比检索多两段还贵。
我们给不同场景设回答长度。客服短答，内部分析长答，代码解释按需展开。
小模型路由很有效。分类、意图识别、标题生成别全上最贵模型。
但路由本身也有成本和错误。早期别 8 个模型乱飞，先找最大浪费点。
常见最大浪费是重复发送固定提示、无关历史、过多 RAG chunk、用户点“重新生成”全量重跑。
prompt caching 适合固定前缀稳定的场景。你每次动态拼一大段在前面，就吃不到好处。
RAG TopK 降低会不会影响准确率？
要测。很多系统 TopK=20 只是心理安慰，前 5 段已经够，后面全是噪声。
我们还做了“无答案短路”。检索分数太低，先澄清或说资料不足，不让模型长篇猜。
用户连续追问时，要不要复用上轮答案？
可以复用状态和证据摘要，不要机械塞完整上轮回答。上轮回答很长时尤其浪费。
我先加 token 日志和场景成本报表，再优化 RAG TopK、固定前缀和回答长度。
对，成本优化先找热区，不要凭感觉砍能力。
你好！看起来您对这段对话很感兴趣，但您还没有一个账号。
厌倦了每次访问都刷到同样的帖子？您注册账号后，您每次返回时都能精准定位到您上次浏览的位置，并可选择接收新回复通知（通过邮件或推送通知）。您还能收藏书签、为帖子顶，向社区成员表达您的欣赏。
有了你的建议，这篇帖子会更精彩哦 💗
