在 RAG 系统中，大模型（如 GPT-4、Claude 等）负责最终的回答生成，而每一次调用都伴随着按 Token 计费的成本。当问答量成规模后，这笔费用会成为系统运营中最现实的支出。因此，在保证回答质量的前提下，有效控制调用成本是工程实施中不可回避的课题。实践中，主要通过 Token 控制、缓存命中 和 小模型兜底 三条路径来优化。
1. Token 控制：花得精准，而非花得多
LLM 的计费同时覆盖输入（检索到的上下文 + 提示词）和输出（生成的回答），二者均按 Token 数计费。因此在设计提示和检索策略时，需要时刻有意识地“压缩”不必要的消耗。
实用做法：
- 精简检索返回的上下文：默认可能返回 top-5 甚至 top-10 个 chunk，每个 chunk 可能有 500 Token，一次性输入就占用了 2500～5000 Token。实际上很多问题用 top-3 甚至单一高质量片段就能回答。通过优化检索精度、提高相似度阈值、对 chunk 去重后再送入模型，可以显著减少输入长度。
- 压缩提示词并裁剪无关信息：在将检索内容填入提示模板前，可以剔除明显无关的元数据、空行、重复标题，甚至对片段做轻量级摘要（用更短的文字概括后替换原片段），用更少的 Token 传达相同信息。
- 限制输出长度：通过
max_tokens参数显式限制回答长度，或在提示中要求“用不超过 200 字回答”。对于简单询问统计数字、确认是否等场景，一句话答案即可，无需长篇展开。 - 使用更高效的 tokenizer 及格式：在条件允许时，优先选择 token 效率更高的模型（同等语义内容消耗 Token 更少）。同时避免在提示中使用低效的换行、多余标点，这些看似微小的细节在百万次调用后会累积出可观成本。
一步到位的实践：构建问答系统时，可以先不做过度压缩，但必须在日志中记录每次调用的输入输出 Token 数，以此分析哪些场景消耗过高，再对症裁剪。
2. 缓存命中：同样的轮子不再造两次
在实际应用中，用户的问题往往有很强的重复性，特别是在特定业务场景下（如“如何重置密码”“退货流程是什么”）。如果每次遇到相同或高度相似的问题都重新检索并调用大模型生成，既是计算浪费，也是成本浪费。
解决方案是引入语义缓存（Semantic Cache）：
- 将用户问题向量化，在专门的缓存库（如 Redis + 向量检索扩展）中查找历史相似问题。
- 当新问题的向量与某已缓存问题的相似度超过设定阈值（例如 0.95）时，直接返回缓存的答案，无需执行完整的 RAG 流程，也无需调用 LLM。
- 缓存条目可携带过期时间（如推送新政策后主动刷新），确保答案不过时。
缓存带来的直接收益：
- 对于高频重复场景，缓存命中率可达 30%～60%，相应比例的 LLM 调用和 Token 消耗被直接省去。
- 响应速度显著提升（跳过检索和生成，毫秒级返回），用户体验更好。
- 搭配语义缓存时的真实考虑：需要根据业务容忍度设定相似度阈值，并建立缓存失效机制（如知识库更新后清除相关缓存），避免返回旧答案。
3. 小模型兜底：杀鸡焉用牛刀
并非所有到达 RAG 系统的问题都需要最强的模型来回答。许多问题其实非常简单——比如“A 产品的价格是多少”“售后电话是多少”，检索到的文档片段本身就是一句明确的话，几乎不需要复杂推理或组织。此时调用大模型实属浪费。
分级响应机制可以有效降低成本：
- 引入轻量模型作为第一级处理：先用一个小型模型（如参数量 7B 左右的开源模型，甚至更小的指令模型）对检索到的片段做回答可行性判断，或者直接生成答案。如果置信度足够（比如片段中包含直接明确的数字、确定性表述），就直接输出小模型的回答，不再调用大模型。
- 复杂问题再转交大模型：对于需要总结多点信息、进行简单推理或跨片段整合的问题，小模型可能难以胜任（可通过设置一个简单的兜底判断：比如检索到的多个片段彼此矛盾、用户提问表述模糊等），这时才调用能力更强的大模型。
- 更精细的做法是估算任务复杂度：根据用户问题的长度、检索结果的数量和离散程度等因素，动态决定是否升迁到大模型。这可以进一步节省大模型调用次数。
真实案例参考： 某电商平台的客服 RAG 系统，对于查询订单状态、退换货地址这类有固定模板、答案可直接从检索片段中提取的问题，全部由小模型（甚至直接由规则脚本）回复；只有遇到投诉申诉、复杂政策解释等场景，才转移至大模型处理。这样大模型的调用量降低了 40% 以上，而用户无明显感知差异。
组合使用，效果更佳
这三种策略并非互斥，可以协同配合：
- 首先检查语义缓存，命中则直接返回，零成本。
- 未命中时，由小模型尝试回答，若答案可靠，则返回并写入缓存（供后续复用）。
- 小模型无法处理时，才调用大模型，并在生成后同样写入缓存。
通过这种组合，整体大模型调用成本可降低 50%～70%，同时保持高质量的回答体验。
最终，大模型调用成本控制的本质是 “只为真正需要的计算付费”。通过精确的 Token 管理、合理的复用机制和适当的模型降级，可以在不损害核心能力的前提下，让 RAG 系统在大规模运行时具备良好的成本经济性。