RAG 聊天机器人看起来只是一次问答，但真实成本通常来自检索片段、系统提示词、历史对话和模型输出的叠加。如果只按用户问题长度估算，很容易低估上线后的月度账单。
先拆分一次请求
一次典型 RAG 请求通常包含系统提示词、用户问题、检索到的文档片段、最近几轮对话历史和模型生成的回答。其中用户问题往往最短，真正占成本的是文档片段和历史上下文。
建立月度估算公式
可以先用保守公式估算：
月成本 = 单次请求成本 × 每日请求量 × 30单次请求成本再拆成：
输入成本 = 未缓存输入 token × 输入单价 + 缓存命中 token × 缓存读取单价
输出成本 = 输出 token × 输出单价如果你的知识库问答每次带入 6,000 token 检索内容，输出 800 token，成本会明显高于普通短问答。
估算检索片段长度
RAG 成本最容易失控的地方是 top-k 设置。一次返回 3 段和 8 段文档，模型效果可能只提升一点，但输入 token 会翻倍。
建议上线前记录三组数据：平均检索片段数、平均片段长度和无答案比例。这些数据比单纯看页面访问量更接近真实账单。你也可以把这些字段放进 Token 预算模板，作为 RAG 场景的独立预算行。
缓存能省多少
RAG 场景里，系统提示词、工具说明和部分固定模板适合缓存。用户问题和检索内容通常变化较大，不一定能稳定命中缓存。
如果供应商支持 prompt caching，可以把固定部分和动态检索内容分开估算。固定部分按缓存读取价计算，动态部分仍按普通输入价计算；缓存假设可以结合 提示词缓存能省多少？ 进一步校准。
选择模型时看输出成本
RAG 回答往往比分类、摘要更长。即使输入价格较低，如果模型倾向生成很长答案，输出成本也会抬高总费用。
上线前可以用 50 到 100 条真实问题测试平均输出长度，再把这个数字填入成本计算器，而不是用理想值。模型候选阶段建议同时查看 文本模型 和 模型价格表，避免只按单个供应商估算。
上线前检查清单
- 是否限制了最大检索片段数
- 是否设置了最大回答长度
- 是否区分免费用户和付费用户的上下文长度
- 是否记录无答案请求比例
- 是否把固定提示词纳入缓存估算
RAG 成本控制的关键不是只选便宜模型，而是减少每次请求带入的无效上下文。