减少 RAG 系统中 LLM 调用次数最推荐的方向是实施语义缓存（Semantic Cache）和模型路由（Model Routing）。这适合查询重复率高或问题难度分层的场景，主要风险边界是缓存命中可能导致过时信息回复，小模型路由可能误判复杂问题。

快速处理思路

如果不具备深度开发条件，优先检查 RAG 框架是否支持内置缓存功能。LangChain 和 LlamaIndex 等主流框架均提供语义缓存组件，可直接配置启用。对于路由策略，若无法部署额外模型，可先通过关键词规则过滤高频简单问题。

为什么会这样

LLM 调用成本与请求次数及 Token 消耗线性相关，减少不必要的调用是直接降低成本的最有效手段。RAG 流程中，检索到的内容可能不足以回答问题，或者用户问题完全相同，此时直接调用大模型属于资源浪费。语义缓存通过向量相似度匹配历史问答，模型路由通过小模型预判问题难度，两者都能在大模型介入前拦截请求。

分步处理

步骤 1：启用语义缓存
在 RAG 链路最前端加入缓存层。配置向量存储存储历史 Query 和 Answer 的嵌入向量。设置相似度阈值，例如当新查询与历史查询相似度超过 0.95 时，直接返回缓存答案。注意需记录缓存命中率。

步骤 2：部署模型路由
引入一个低成本的小型模型（如 7B 参数以下或专用分类模型）作为网关。让小模型先判断问题是否需要检索或复杂推理。对于问候、简单事实类问题，由小模型直接回答或规则匹配，不触发大模型调用。

步骤 3：优化检索与 Prompt
检查检索环节，避免多次重试调用。优化 Prompt 长度，减少输入 Token 消耗。如果检索内容相关性低，设置阈值直接返回“未找到相关信息”，避免大模型基于噪声生成。

怎么验证是否生效

查看应用日志或监控面板，统计单位时间内的 LLM API 调用次数（Call Count）和 Token 消耗量。对比优化前后的数据，确认调用次数下降。同时抽样检查缓存命中的回答和小模型回答，确保用户满意度没有显著下降。

常见坑

语义缓存可能返回过期的业务数据，需设置缓存有效期或手动清除机制。模型路由若小模型能力不足，会将复杂问题误判为简单问题，导致回答质量下降。检索阈值设置过严会导致频繁调用大模型进行“确认”，反而增加成本。

常见问题

语义缓存会影响回答准确性吗？

会，如果底层知识库更新而缓存未清除，缓存命中的回答可能过时。建议为缓存设置较短的 TTL 或在知识库更新时失效缓存。

小模型路由值得投入吗？

适合问题难度差异大的场景。如果绝大多数问题都需要复杂推理，小模型路由的收益有限，反而增加链路复杂度。

如何监控 LLM 调用成本？

通过 LLM 提供商的控制台查看 Token 用量，或在代码中封装 API 调用层，记录每次请求的输入输出 Token 数并累加计算。