AI 底层逻辑 / 经典论文
Model Routing / Semantic Cache：Frugal AI 与成本质量路由
核心思想:
350 行ai-foundations/papers/28-model-routing-semantic-cache-frugal-ai.md
Model Routing / Semantic Cache / Frugal AI 解读
面向对象: AI PM / AI Architect / Platform PM / FinOps / EvalOps。 核心问题: 企业 AI 为什么不能所有请求都打最强模型？如何用模型路由、语义缓存和级联策略同时管理质量、成本、延迟和风险？ 学习目标: 理解 FrugalGPT、RouteLLM、semantic cache、model cascade 的底层思路，并把它们转成 AI 平台的 routing policy、SLO 和产品策略。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| FrugalGPT | https://arxiv.org/abs/2305.05176 | 理解 LLM cascade 如何在成本和质量之间做优化 |
| RouteLLM | https://github.com/lm-sys/RouteLLM | 理解根据请求难度路由到强/弱模型 |
| RouteLLM Paper | https://arxiv.org/abs/2406.18665 | 理解 model router 的训练和评估方法 |
| GPTCache | https://github.com/zilliztech/GPTCache | 理解语义缓存、相似查询复用和成本降低 |
| LMSYS Chatbot Arena | https://chat.lmsys.org/ | 理解模型质量比较和路由评估的背景 |
核心思想:
AI 平台不应该只问“哪个模型最好”，而应问“这个请求在这个风险等级、SLO 和成本约束下，应该由哪个能力路径处理”。
1. 这类研究解决什么问题
企业 AI 上线后会遇到四个现实约束:
| 约束 | 表现 |
|---|---|
| 成本 | 所有请求打大模型，单位经济无法成立 |
| 延迟 | 客服、搜索、工单、代码辅助对响应时间敏感 |
| 质量 | 小模型便宜但复杂任务失败率高 |
| 风险 | 高风险任务不能只由便宜模型自动完成 |
单一模型策略太粗:
所有请求 -> 最大模型 -> 高成本 / 高延迟 / 不区分风险
所有请求 -> 小模型 -> 低成本 / 质量不稳 / 高风险不可接受
更成熟的 AI 平台会使用:
Request
-> classify task / risk / difficulty / tenant / SLO
-> cache lookup
-> route to small model / large model / specialized model / RAG / human
-> evaluate output confidence / risk
-> escalate, retry, or finalize
2. FrugalGPT: Cascade 的产品含义
FrugalGPT 的核心思路是:
先用便宜模型处理简单请求；当质量信号不足时，再升级到更强模型。
Input
-> Model A cheap
-> quality check
-> pass: return
-> fail: Model B stronger
-> quality check
-> pass: return
-> fail: Model C / human
这不是简单的降本，而是把模型调用变成一个可控决策过程。
Cascade 设计问题
| 决策 | 说明 |
|---|---|
| first model | 用哪个便宜模型先试 |
| confidence signal | 用什么判断是否足够好 |
| escalation rule | 什么时候升级到强模型 |
| stop rule | 什么时候拒答或人工处理 |
| cost budget | 每类请求最大允许成本 |
| latency budget | 升级是否仍满足体验 |
3. RouteLLM: 路由不是 if-else
RouteLLM 关注的问题是:
如何学习一个 router，让简单请求走便宜模型，复杂请求走强模型，在质量接近强模型的同时降低成本。
路由依据可以包括:
- 请求长度。
- 任务类型。
- 语义复杂度。
- 历史模型表现。
- 用户等级。
- 风险等级。
- 是否需要工具。
- 是否有明确 gold source。
Router 输出
| Output | 含义 |
|---|---|
small_model | 低风险、简单、格式稳定 |
large_model | 复杂推理、长上下文、高质量生成 |
specialist_model | 分类、抽取、rerank、embedding |
rag_path | 需要当前知识和引用 |
human_review | 高风险或不确定性过高 |
AI PM 要注意:
Router 本身也是产品能力，需要评测、监控、灰度和回滚。
4. Semantic Cache: 缓存的不只是字符串
传统缓存:
exact query match -> return cached answer
语义缓存:
new query -> embedding -> similar cached query -> similarity threshold
-> reuse answer / reuse retrieved context / skip model call
适合:
- FAQ。
- 政策解释。
- 固定流程说明。
- 内部知识问答。
- 高频客服问题。
不适合直接复用:
- 客户个性化信息。
- 金额、日期、状态敏感查询。
- 权限差异明显的问题。
- 政策快速变化的问题。
- 高风险建议。
5. Semantic Cache 的治理边界
| 风险 | 例子 | 控制 |
|---|---|---|
| stale answer | 政策更新后仍返回旧答案 | cache TTL + source version binding |
| permission leakage | A 用户缓存命中 B 用户可见答案 | permission-aware cache key |
| semantic false positive | 相似但业务条件不同 | threshold + rerank + field constraints |
| personalization error | 忽略用户账户状态 | no-cache fields |
| audit gap | 不知道答案来自缓存 | trace cache_hit=true |
高风险场景中，缓存最好复用 retrieval/context，而不是直接复用最终答案。
6. Routing Policy Matrix
| Task type | Risk | Default path | Escalation |
|---|---|---|---|
| FAQ 改写 | low | small model + semantic cache | large model if low confidence |
| 政策问答 | medium | RAG + medium model | large model if conflicting sources |
| AML narrative | high | RAG + large model + HITL | human if missing evidence |
| 信贷解释 | high | rules + RAG + large model | compliance review |
| 支付争议建议 | high | workflow + policy engine | human approval before customer-facing |
| 内部 SQL/BI 问答 | medium/high | semantic layer + SQL guardrails | data owner review for sensitive metrics |
模型路由应把业务风险放在成本之前。
7. 架构视图: AI Routing Control Plane
Request
-> Identity / Tenant / Permission
-> Task Classifier
-> Risk Classifier
-> Cache Lookup
-> Context Strategy Router
-> no retrieval
-> RAG
-> long context
-> tool workflow
-> Model Router
-> small / large / specialist / fallback
-> Output Validator
-> Eval Signal
-> Trace + Cost Ledger
关键组件
| Component | 责任 |
|---|---|
| task classifier | 判断任务类型和复杂度 |
| risk classifier | 决定自动化边界 |
| cache service | exact / semantic / context cache |
| model router | 决定模型路径 |
| policy engine | 覆盖合规和权限规则 |
| cost ledger | 记录单位成本和预算 |
| quality monitor | 监控成功率、升级率、失败类型 |
| fallback handler | 降级、排队、人工、拒答 |
8. Product Metrics
| Metric | 含义 |
|---|---|
| cost per successful task | 每个成功任务的模型成本 |
| first-token latency | 首 token 延迟 |
| end-to-end latency | 用户实际等待时间 |
| cache hit rate | 缓存命中率 |
| safe cache hit rate | 缓存命中且未导致错误的比例 |
| escalation rate | 从小模型升级到大模型/HITL 的比例 |
| avoided large-model calls | 节省的大模型调用 |
| route accuracy | router 选择是否符合 gold path |
| quality delta vs strongest model | 路由策略相对最强模型的质量损失 |
| unsafe cost optimization rate | 因降本导致风险门禁失败的比例 |
最后一项应被当作 stop metric。
9. Eval 设计
路由 eval 不只看最终答案，也要看路径是否正确。
| Eval layer | 样本 |
|---|---|
| task classification | FAQ / policy / case action / data query |
| risk classification | low / medium / high / critical |
| cache eligibility | 可缓存 / 不可缓存 / 只能缓存 context |
| model route | small / large / specialist / human |
| fallback behavior | 重试 / 升级 / 拒答 / 人工 |
| cost-quality frontier | 成本下降时质量损失 |
Golden Route 样例
| Query | Gold route | Reason |
|---|---|---|
| “如何修改登录密码？” | cache + small model | 低风险 FAQ |
| “这笔交易是否可以 chargeback？” | workflow + RAG + human review | 涉及规则和客户影响 |
| “解释最新 KYC 地址证明要求” | RAG + medium/large model | 需要当前政策来源 |
| “这个客户是否应被拒贷？” | no auto decision + human | 高风险决策 |
10. 金融零售案例
10.1 Retail Customer Service Copilot
路由策略:
- 高频 FAQ: semantic cache + small model。
- 账户状态查询: read-only tool + medium model。
- 费用减免承诺: 不自动承诺，转人工或生成草稿。
- 投资/信贷建议: 边界说明 + 合规升级。
10.2 AML Alert Copilot
路由策略:
- typology 分类: specialist classifier。
- 证据聚合: tool + RAG。
- narrative 草稿: large model。
- disposition 建议: human review。
- 高风险 alert: 禁止缓存最终建议，只缓存非敏感模板。
10.3 AI Platform PM
平台 backlog:
| Capability | Why |
|---|---|
| routing policy editor | PM/architect 可配置 task/risk/model 路径 |
| semantic cache dashboard | 监控命中、节省、错误和 stale |
| model comparison harness | 评估 cost-quality frontier |
| route trace viewer | 复盘为什么走某模型 |
| fallback simulator | 测试降级和供应商故障 |
11. Build vs Buy 决策
| 选项 | 适合 | 风险 |
|---|---|---|
| vendor gateway routing | 快速接入多模型 | 路由逻辑黑盒、证据不足 |
| 自建 lightweight router | 任务类型明确 | 维护 eval 和监控成本 |
| 研究型 learned router | 流量大、成本压力高 | 训练数据和漂移治理复杂 |
| semantic cache only | FAQ 和知识问答占比高 | 权限和 stale 控制是重点 |
| no routing | 初期低流量 | 成本和延迟不可持续 |
高级判断:
流量不足时不要过早复杂化；进入规模化后，没有 routing/caching 的 AI 平台会很难管理单位经济。
12. 作品集输出
| Artifact | 内容 |
|---|---|
| AI Routing Policy | task/risk/SLO/cost 到模型路径 |
| Semantic Cache ADR | 哪些内容可缓存、TTL、权限、版本、trace |
| Cost-Quality Frontier Report | 小/大/路由策略的成本质量对比 |
| Golden Route Eval Set | 100 条请求和期望路径 |
| FinOps Dashboard Spec | 成本、命中率、升级率、质量损失 |
| Fallback Runbook | 模型不可用、成本异常、质量下降时怎么处理 |
13. 面试表达
30 秒版本
模型路由的目标不是一味省钱，而是在任务类型、风险、SLO 和成本之间做动态决策。简单低风险请求可以走缓存或小模型，高风险复杂任务必须升级到强模型、RAG 或人工复核。
2 分钟版本
FrugalGPT 和 RouteLLM 的共同启发是: 企业 AI 应该把模型调用设计成 routing control plane，而不是固定模型选择。请求先经过任务分类、风险分类、权限检查和缓存判断，再决定 small model、large model、specialist model、RAG 或 human review。语义缓存可以显著降低高频知识问答成本，但必须绑定 source version、permission、TTL 和 trace。衡量路由不能只看 cost saving，还要看 route accuracy、quality delta、unsafe optimization rate 和 incident。
CTO 深挖
我会把 router 当成可发布组件: 有 routing policy、golden route eval、shadow traffic、灰度、成本账本、trace viewer 和 rollback。模型升级或供应商变更时，router eval 必须回归，否则成本优化可能变成质量和风险退化。
14. 复习问题
- FrugalGPT 的 cascade 思路和单模型策略有什么差异？
- RouteLLM 为什么要学习路由，而不只是手写规则？
- Semantic cache 为什么必须做权限和版本治理？
- 哪些任务绝对不应该直接缓存最终答案？
- 路由 eval 为什么要看“路径是否正确”？
- 如何设计 cost-quality frontier report？
- 在金融零售 AI 平台中，哪些场景应优先引入 model routing？