很多 AI 应用上线后都会遇到同一个现实：
请求量上去后，推理成本和响应时延一起上去。
如果所有请求都走大模型，再好的产品增长也会被成本吞掉。更稳的策略是：SLM + RAG + 路由。
架构图：基于复杂度的成本感知路由
时序图：一次请求如何选择 SLM 或 LLM
核心思路
- 先做检索，把上下文压缩到“足够解决问题”的证据集合。
- 再做复杂度打分，简单问题走 SLM，复杂问题才升级到 LLM。
- 对每次请求记录成本和时延，持续优化阈值。
这套方案为什么有效
1. 把“大模型调用”从默认路径改成升级路径
默认 SLM 可覆盖大量标准问答和流程类任务，LLM 只处理真正复杂场景。
2. 检索先行能显著降低推理负担
高质量 RAG 让模型不必“从零推理”，减少 token 消耗和幻觉概率。
3. 路由可持续迭代
通过在线指标，你可以动态调整“简单/复杂”阈值，而不是一开始拍脑袋。
可落地的阈值设计（示例）
- query length > 500 且多意图：优先 LLM。
- 命中强结构化 FAQ：优先 SLM。
- 证据召回不足：触发 LLM + 追问。
监控看板建议
| 指标 | 含义 |
|---|---|
| SLM 路由命中率 | 有多少请求可被低成本模型承接 |
| LLM 升级率 | 复杂请求占比是否异常波动 |
| Cost per Request | 每次请求真实成本 |
| P95 延迟 | 关键体验指标 |
| 人工兜底率 | 自动链路是否可靠 |
常见误区
- 一上来就做复杂路由策略，导致系统难以调试。
- 不做检索质量治理，只盯模型切换。
- 没有统一指标口径，优化效果不可比较。
结语
SLM + RAG 不是“降配方案”，而是工程化提效方案。
真正成熟的团队，不会把所有请求都交给最贵模型，而是把“模型选择”变成可度量、可优化的系统能力。