Appearance
Q75 · 模型路由应该怎么做？
一套客服应用每天收到很多问题。有些只是“订单 A123 现在是什么状态”，查订单接口并把结果解释清楚即可；有些是“耳机维修过两次、政策版本也变了，我现在能要求什么处理”，需要读多份证据、识别冲突并谨慎说明。若所有请求都交给同一个大模型，简单任务的成本与等待时间可能过高；若全部交给最快、最便宜的模型，复杂问题可能答错或漏掉条件。
模型路由是应用在每次任务或流程某一步开始前，根据任务需要、模型能力和业务约束，选择合适的模型与推理配置，并记录为何这样选。它也可以决定这一步根本不需要模型。路由不是让模型自己决定有没有退款权限；即使选了最强模型，订单归属、政策生效和资金写入也必须由可信业务系统检查。OpenAI：Model selection、OpenAI：Latency optimization
术语与文中变量
| 词或变量 | 直白解释 | 本题里怎么用 |
|---|---|---|
| 路由器 | 决定这一步调用哪条处理路径的程序或组件 | 给查单请求走直接接口，给复杂争议走更强模型 |
| 候选模型 | 经过团队验证、允许用于这类数据的模型集合 | 例如“快速模型”“更强模型”两类配置 |
| 能力约束 | 模型是否支持必需输入和功能 | 是否能处理图片、足够长的上下文、工具调用或结构化输出 |
| 任务难度 | 当前输入需要多少理解、推理和证据整合 | 单个订单状态 vs 多政策冲突分析 |
| 风险级别 | 答错带来的业务后果 | 错写退款资格比普通寒暄严重 |
| 上下文长度 | 本次要送入模型的对话、规则与证据所占输入量 | 长售后历史可能超过某候选模型可处理范围 |
| 兜底 / 升级 | 首选路径失败或信心不足时转给更合适的路径 | 规则分类不清时转强模型或人工 |
| 回退 | 模型服务故障时用经过验证的备用方案 | 只读解释可用备用模型；退款写操作不能盲目重跑 |
| 质量门槛 | 方案必须达到的正确性和安全要求 | 越权查询、无审批退款必须为零 |
| 单任务成本 | 完成一个合格任务的总消耗 | 包括路由判断、模型调用、重试、工具和人工 |
task_type | 应用识别出的任务类型 | order_status 或 complex_dispute |
needs_vision | 本次是否必须看图片 | 用户上传耳机损坏照片时可能为真 |
risk_level | 从业务规则得到的风险等级 | 退款执行高于普通订单查询 |
chosen_model | 路由最后选的模型配置 | 供调用、追踪和复测使用 |
A123 只是虚构订单号。文中的“快速模型”和“更强模型”是抽象候选，不指特定品牌或永久性能排名。模型的实际可用工具、上下文上限、价格和速度会随版本及服务变化，必须按上线时使用的官方规格和本系统评测确认。OpenAI：Model selection
把两类请求放在同一张图里看
图左有两张任务卡：查订单状态与复杂售后争议。中间的分拣台按所需能力和难度选择不同路线；两条路线最后都接受质量复核。图示没有画“模型决定是否批准退款”：业务权限另有独立关口，不能从“用了强模型”推断“可以执行高风险动作”。图也不是说查订单一定要调用快速模型；如果用户只要结构化订单状态，应用直接调用订单 API 和模板即可，连这次模型调用也可以省掉。
一个具体路由可以这样设计：
- 用户输入“查 A123 物流”。先由应用识别为
order_status，核实身份与订单归属，调用订单 API。如果页面只显示状态字段，直接用模板答；若用户希望自然语言解释，可交给已验证的快速模型表达，但事实仍来自 API。 - 用户输入“维修两次还是坏，旧政策说可退，新政策又说要检测”。识别为
complex_dispute，先检索现行与历史政策、维修单和订单事实；如果资料冲突或缺失，让更强模型整理争议点、引用来源，必要时交人工确认。不能凭模型语气肯定就认定旧政策适用。 - 用户说“替我直接退款”。这是动作请求，风险规则先把写工具锁住。选择什么模型只影响理解和说明；真正调用退款 API 仍需明确授权、政策校验、人工审批和幂等。
这样分层比“只看用户文字里有几个字、超过 100 字就用大模型”可靠。短句也可能复杂，例如“这个例外还算吗？”依赖很长的前文；长消息也可能只是贴了一段已知格式表单。路由判断要看任务类型、所需证据、可用能力和风险，而不是仅看字数。OpenAI：Model selection
一个稳妥的路由决策顺序
**第一关：这一步要不要模型？**规则明确的订单归属判断、日期比较、表单校验、金额计算和权限检查，用程序更便宜也更可预测。即使整个产品叫 Agent，其中很多节点也可以完全不用 LLM。OpenAI 的延迟优化文档同样建议不要默认每一步都调用模型。OpenAI：Latency optimization
第二关：先过滤能力不够的候选。若用户上传图片，只能从已验证支持视觉输入的候选里选；若流程依赖某种工具调用、结构化输出或特定数据地域，也先检查对应能力与合规限制。不要等模型调用失败后才发现不支持功能，更不能把图片随便交给一个没有授权的数据处理服务。候选模型的支持能力按实际所用版本与接口核对，不能只看模型家族名称。OpenAI Agents SDK：Models
**第三关：在满足能力的集合里按质量、延迟和成本选。**对大量简单任务先试较快较省的配置，对复杂推理或更长上下文试更强配置。但“更强”不是一张永久排行榜：某个模型在自己的客服术语、中文政策和工具格式上是否更好，要用同一组真实样本检验。路由器本身也有成本，如果先用一个昂贵模型判断难度，再调用另一个模型，可能得不偿失。可以先从确定性规则和少量可复现信号做起；含糊情况再加轻量分类器，并把分类器的错分率纳入整体评测。
**第四关：设置升级与停止条件。**快速模型返回结构化结果缺字段、引用不完整或证据冲突时，可升级到更强模型或人工。若工具返回“订单不存在”“无权限”，不应靠换一个模型重试同一越权请求。若强模型也没有现行政策证据，应答“暂无法核实”，而不是再无止境地换模型碰运气。每个任务限制升级次数、总耗时与费用。OpenAI：Evaluation best practices
若使用 LangChain 等框架，动态模型选择可以放在模型调用前的中间件；若用 OpenAI Agents SDK，不同 Agent 或同一次运行可配置不同模型与提供方。Google ADK 也有模型路由能力，但其特定 TypeScript RoutedLlm 页面明确标注为实验性，不能在选型表里把它说成所有语言、所有版本都稳定可用。框架提供接入点，真正的路由规则与评测口径仍由应用确定。LangChain v1 迁移指南：动态模型选择、OpenAI Agents SDK：Models、Google ADK：Model routing
路由不能只算每次调用多少钱
假设以下都是教学用的相对成本单位，不是任何真实 API 报价：每 100 个客服任务里，70 个简单，30 个复杂；“快速模型”单次花 1 单位，“更强模型”单次花 4 单位，路由判断平均每次 0.2 单位。若全走强模型，总成本是 100 × 4 = 400；如果所有简单题都能一次用快速模型完成，路由总成本是 70 × 1 + 30 × 4 + 100 × 0.2 = 210。看起来省了 190 单位。
但这个算式还缺几项现实支出：简单题被错分后补救的第二次模型调用、人工复核、工具费用和错误答案损失。若 70 个“简单题”里有 20 个实际失败，最后都升级为强模型，成本再加 20 × 4 = 80，只剩 110 单位差距；如果错答造成更大业务损失，就完全不能用“省钱”作为上线理由。因此应该算每个通过质量门槛的任务的成本，而不是每次模型请求的单价。也要同时看 p95 延迟、首答时间、用户满意度和高风险错误率。OpenAI：Cost optimization
这也解释了为什么“永远先试小模型，失败就升级”并非通用策略。若复杂任务本来就很明显，先试小模型只增加一轮等待、token 和错误风险；可以直接走更适合的候选。升级要基于能检测的失败信号，不能靠模型自己说“我很有信心”。
故障回退和安全边界
模型服务超时或不可用时，备用模型必须经过同一类任务的能力与质量评估。若备用模型不支持所需工具、视觉或结构化格式，不能“反正先用它答一下”。降级响应也可以是模板、稍后再试或转人工；有时明确说“暂无法核实”比让未验证模型猜测更合适。
要区分重跑只读生成与重跑带副作用的 Agent 流程。例如 A123 的查询结果生成失败，重新生成文本一般风险较低；如果上一轮已经向外部系统发出退款请求，只因模型响应中断就从头重跑整段 Agent，可能重复退款。应先查询业务动作状态，并使用同一幂等键与审批记录处理。路由器不应在工具调用已经产生外部写入后，随意切到另一模型重新执行整条轨迹。
模型路由还不能代替权限控制。路由到更强模型可能增加对资料的理解，但不会让用户自动获得别人的订单、不会让过期政策变成现行，也不会让未审核退款合法。敏感数据能否传给某个模型提供方，要先由数据策略决定候选集合；预算或速度不能越过这条限制。
上线前怎样验证路由有效
取同一批代表真实请求的样本，至少覆盖直接查单、长对话省略指代、复杂政策冲突、用户越权、模型工具格式不支持、模型超时、退款动作请求。先跑固定模型基线：简单方案全部走一个合格模型，记下正确率、可追溯性、延迟和成本；再跑路由方案，保持工具数据、提示词与模型版本一致，只改变路由策略。否则改善可能来自新政策数据，而不是路由本身。
评测时同时看三层：
| 层 | 问题 | 例子 |
|---|---|---|
| 路由判断 | 该问题是否被送到能完成它的路径？ | “这个例外还算吗”能否利用上文识别为复杂问题 |
| 任务结果 | 答案是否正确、证据是否充分、是否安全停止？ | 引用了当前 v3，未把旧 v2 当现行 |
| 系统代价 | 完成一个合格任务花多少时间和费用？ | 模型调用、升级、工具、人工加在一起 |
一个实际可用的发布规则是：先指定不能退让的硬门槛，例如跨用户订单泄露为零、未经审批退款为零、关键政策误判不得高于基线；再在达标方案里比较延迟与成本。灰度时记录 task_type、候选能力检查结果、chosen_model、升级原因、工具轨迹和最终质量标签。若路由规则改动，重跑固定回归集并监控线上错误；模型版本变化也应重新验证。OpenAI 官方同样强调在同一类输入上实验不同模型与推理设置，并用评测校验质量。OpenAI：Model selection、OpenAI：Evaluation best practices
面试时可以这样回答
我先把任务分层：能靠规则或工具直接完成的步骤不调用模型；需要模型时先按模态、上下文、工具、结构化输出和数据策略筛掉不合格候选。然后依据任务难度、风险与时延要求选择经过验证的快速或更强配置，低确定性或质量检查失败时有界升级或转人工。路由器本身要算进延迟和成本，比较的是“每个合格任务”的总消耗，而不是模型单价。上线前用同一批真实与失败样本对比固定模型基线，检查路由准确率、回答质量、安全硬门槛、p95 延迟和成本；灰度中记录模型选择与升级原因。模型路由只决定由谁理解或生成，不决定业务权限。涉及退款等写操作，执行前仍要由后端核验授权、审批和幂等。
如果追问“是不是全部先用小模型，答不好再换大模型”，答：不是。明显复杂或有硬能力要求的任务应直接选合适候选；否则先跑一次小模型可能更慢、更贵。若追问“模型说自己有 95% 把握可不可以当升级阈值”，答：不宜直接相信自报置信度，应在标注样本上校准可观测信号，例如结构化输出缺字段、证据冲突与独立校验失败。