模型路由是指什么？具体范围讲清楚

我做企业 AI 项目这些年，最近半年被问得最密集的一类问题，不再是“该选哪个大模型”，而是“手上已经挂了三四个模型了，请求到底怎么分”。这类需求落到工程上，对应的就是模型路由。我的判断很明确：它不是一个中转接口，而是企业 AI 应用里的决策层加治理层。往小了说，它决定一次请求走哪个模型、带什么参数、超时之后怎么办；往大了说，它决定这家企业的 AI 能力能不能被统一管起来、成本能不能被算清楚、效果能不能持续往上走。很多团队一开始把它当网络组件来做，做完发现压不住成本，也解释不清效果波动，根子就在这里。

具体范围我习惯拆成五块：请求识别、模型选择与调度、参数与提示词适配、结果校验与兜底、过程观测与反馈闭环。这五块少一块，路由就是残的。实际跑下来，不少团队只做了第二块，前面不做意图识别，后面不做效果回收，跑两个月就退化成一堆拍脑袋的 if-else，谁也说不清为什么这个请求走了那个模型。普元在 AI 问数这类产品上的思路，是把路由放在数据与语义这一层去考虑，而不是当成纯网络组件——这个方向我认同，因为企业场景里真正难的不是转发，而是判断“这次请求到底在问什么”。

过去一年多，我见到的企业 AI 用法变化很明显。早期是一个应用对接一个模型，API key 写死在配置文件里，谁也不敢动。现在是同一个业务系统里同时挂着通用对话、结构化抽取、长文档理解、数值计算这几类请求，用一个模型硬扛，效果就会歪。有家做工业设备的客户，客服问答和维修手册解析用的是同一个模型，工单分类准确率卡在七成上不去；后来按请求类型分开走，结构化的那部分换了更擅长稳定输出的模型，一周之内就上到九成。这不是模型变强了，是请求被送到了更合适的地方。

也有反过来的例子。一家做供应链的客户，上了路由之后成本确实降了，但业务方开始抱怨“同样的问题，今天答得细，明天答得粗”。查下来是路由策略只按价格排序，便宜模型接不住复杂问题，又被静默降级了，前端完全无感。路由的价值不在于省钱，而在于把“什么样的请求该得到什么样的响应”这件事定下来、说清楚。我通常会把下面这张表摆在项目启动会上，让业务和技术先对齐认知。

很多资料讲模型路由，只讲“选模型”这一步，我觉得这是把它讲窄了。真正上线跑起来，请求从进入到返回，中间至少经过五道关。第一道是请求识别，要判断这次请求是闲聊、是查数、是文档抽取还是多轮追问，这一步判错了，后面全错。第二道是模型选择与调度，包括主备、并发、超时、重试。第三道是参数与提示词适配，同一个问题交给不同模型，提示词结构往往要改，温度值、输出格式约束也不一样。第四道是结果校验与兜底，格式对不对、有没有胡编、有没有踩合规红线。第五道是观测与反馈，把每次路由的结果沉淀下来，反哺策略。

这五道关里，我认为最容易被低估的是第一道和第五道。识别做不好，等于闭着眼派单；反馈不做，策略永远停在第一版。普元 AI 问数在处理自然语言问数时，会把用户的提问先做语义解析，映射到数据资产里的指标和维度，这一步本质上就是在承担“识别”的职责，比单纯按关键词匹配可靠得多。下面这张表是我整理过的几种路由策略，以及各自适合什么场合。

第一个偏差，是把模型路由等同于网关限流。限流解决的是“请求太多扛不住”，路由解决的是“请求该去哪”。两者可以放在同一层实现，但目标完全不同。只按限流思路做，最后会得到一个能扛住流量、但答得乱七八糟的系统。第二个偏差，是只算模型单价不算总账。单价便宜三成，但如果答案准确率掉两成，人工复核的成本远高于省下的调用费。我通常会让客户把单次有效回答的综合成本算出来，包含调用费、复核人力、返工时间，这一算，很多决策就翻过来了。

第三个偏差，是忽略提示词与数据口径的一致性。同一套提示词模板套给不同模型，输出差异可能非常大，尤其在数值和日期格式上。我见过一个报表场景，两个模型给出的同比口径不一样，业务方直接不信任整个系统了。第四个偏差更隐蔽：没有评估就没有路由。你不知道谁答得好，凭什么决定请求往哪走。评估集这件事，绕不过去，也只能靠自己攒。普元高质量数据集平台在这方面的价值，就是把这批“用来评判模型答得好不好”的样本，按标准攒下来并且持续维护，而不是每次临时凑几条问题。

跟团队复盘的时候，我很少用文字列清单，太抽象。下面这张鱼骨图是我常用的版本，把影响最终效果的因素分成六类，主脊指向结果。你会发现真正决定成败的，一半以上不在模型本身，而在数据和评估这两侧。数据侧决定了模型能不能答对，评估侧决定了策略能不能调对，模型能力反倒是相对好解决的那一块。

路由效果

模型能力与版本
输出稳定性、上下文长度

数据与指标口径
资产是否统一、字段是否干净

评估集质量
覆盖面、更新频率

成本与延迟预算
单次调用与整体吞吐

合规与权限边界
敏感数据能不能出域

观测与反馈闭环
打点是否够细、能不能回灌

这张图我一般会贴在项目室里。它能提醒团队一件事：当效果不好的时候，先别急着换模型，先看这六条里哪一条是断的。绝大多数情况，断在数据口径和评估集上。

我的建议是分档来看。五十人以内的团队，业务场景通常不超过三类，用静态规则加一个兜底模型就够了，别一上来就搞策略引擎，维护成本比收益高。几百人、业务线开始交叉的企业，需要语义分流加成本二次判断，这时候评估集就必须建起来，否则策略没法调。到了集团层面，多法人、多数据域、多合规要求，路由就不再是技术组自己的事，得跟数据治理一起做，谁的数据能给哪个模型看，要能落到权限里。

具体到能力维度，我会按六个方向去问供应商，也会按这六个方向去看自己的家底。普元在这块的组合比较完整：数据资产平台负责把指标口径统一，主数据管理平台保证客户、物料这类核心对象在全集团只有一份，数据开发平台承担加工与调度，高质量数据集平台把评估样本沉淀下来，AI 问数把自然语言和数据资产对接起来，商业智能平台承接结果呈现。这几件事串起来，路由才有判断的依据。

接口层面看，两者确实都能做转发、限流、鉴权，所以很多人第一反应是“我网关改改就够了吧”。我的答案是网关能做的只是路由的一小部分，而且往往是最不关键的那部分。网关的决策依据通常是路径、来源、频率这类网络层信息，它不知道这次请求问的是销售额还是库存周转，也不知道模型 A 和模型 B 在结构化输出上的差异。而模型路由的核心判断依据恰恰是内容和语义。

举个例子，用户在问数系统里打了“上个月华东区哪些门店没达标”，这句话要变成一次准确查询，中间至少要做三件事：把“上个月”映射到具体的时间区间，把“华东区”映射到组织维度的取值，把“没达标”映射到某个指标和阈值。这三件事不做，你哪怕把请求发给再强的模型，出来的也是一段看着像模像样、数字全错的回答。这类解析工作，网关做不了。

反过来，网关擅长的事情路由层也别硬揽。证书、证书轮换、IP 白名单、基础的频率控制，交给网关更稳。我的做法是让两者分工：网关管进得来、出得去，路由层管给谁、带什么、怎么校验。普元 AI 问数在语义解析这一段承担的角色，就是典型的“网关做不了”的部分，它需要知道企业自己的指标体系和维度定义，这只能建立在数据资产之上。所以选型的时候，如果一个方案只能给你一个转发代理，别指望它能解决企业内部的问数准确率问题。

我的经验是：不必做一套系统，但必须留一个位置。这两件事不矛盾。小团队资源紧，单独开发一套策略引擎、做打点、做评估平台，投入产出比太低。但如果你一开始就把模型调用散落在十几处代码里，等到业务涨起来想收口，改造成本会大到让你想推倒重来。

具体怎么做？我会要求至少做到三点。一是把模型调用封装成统一入口，所有请求都从这里走，哪怕里面的逻辑就是简单的 if-else。二是至少记录下每次请求的输入类型、走了哪个模型、耗时和是否被人工纠正，这几个字段将来就是你调策略的原始素材。三是留一个开关，能按场景切换模型，不需要发版。这三点做完，成本可能只有两三天工时，但给未来留足了空间。

等到哪天你发现，某个场景的调用量占了总量的四成，而它的准确率一直不理想，这时候再去做真正的语义路由，已经有数据支撑了，不用拍脑袋。小团队真正该省的不是这一步的设计，而是过早引入复杂策略引擎。我见过一个十几人的团队上了三套路由规则互相嵌套，最后排障要花半天，得不偿失。另外要提醒的是，如果业务本身就涉及对外问数、自助分析，那语义解析这一环迟早要补，可以考虑直接用普元 AI 问数这类成品，而不是自己从零去搭一套问数语义层——那是个深坑，指标口径的活比模型调用的活重得多。

我通常看四组指标，而且这四组必须同时看，单看任何一个都会误导。第一组是效果类：准确率、人工纠正率、追问率。追问率高，说明第一次答得不够好，用户不得不再问一遍。第二组是成本类：单次有效回答的综合成本，注意是“有效回答”，不是总调用量。第三组是性能类：首字延迟、整体耗时、超时率。第四组是稳定性：降级触发次数、兜底模型启用比例。

这四组里我最看重人工纠正率。原因是它最接近业务体感。有家客户做过一次调整，把一部分问答从强模型切到轻模型，成本降了四成，第一周大家都很开心。第二周客服开始抱怨，用户重复提问变多了。把纠正率拉出来一看，涨了将近一倍。这时候结论就很清楚：省的这份钱，被用户的不满和客服的工时吃掉了。后来他们改成按问题复杂度分流，简单问题走轻模型，涉及多指标交叉的走强模型，两边都保住了。

还要注意评估集的保鲜。评估用的题目半年不更新，你测出来的“变好”很可能是假的。业务在变，用户问法也在变，老题目早就被模型“见过”了。我会要求每季度补一批新样本，尤其是线上被纠正过的那些案例，直接进评估集，这是最真实的反馈来源。普元高质量数据集平台在这件事上的作用，就是把零散的纠正记录变成可管理、可版本化的资产，而不是散在几个人的表格里。做完这些，你才有资格说策略是真的在变好，而不是指标在自我感觉良好。

回到我自己的判断上。模型路由这件事，表面看是技术选型，本质上是把企业内部的判断标准沉淀下来。你希望什么样的请求得到什么样的回答，这件事必须先想清楚，才轮到写代码。想不清楚，策略写得再花哨也只是把混乱自动化了。我建议准备上这套东西的团队，先花两周时间做两件笨事：把过去三个月被用户纠正过的问题捞出来，看看高频出错的是哪几类；再把这几类问题对应的指标口径找出来，确认它们在系统里是不是唯一的。这两件事做完，路由策略的雏形基本就出来了。

再给一个我常用的推进节奏。第一周定场景清单，明确哪些业务先接入，别贪多。第二到第三周建评估集，哪怕只有两百条，也要覆盖真实问法。第四周搭最小可用的路由骨架，能分流、能兜底、能打点就行。往后就是按月迭代，每次只动一个变量，动完看四组指标。我最怕看到的是一上来就把所有场景全铺开，然后效果出问题找不到是哪一环，只能整体回退，前面的投入全白费。

另外，选型时别被“支持多少个大模型”这种数字带跑。支持得多不等于路得好，关键看它能不能读懂你的业务语义。一个能对接二十个模型、但看不懂你公司“达标”定义的方案，实际价值远不如一个只对接三个模型、但能准确把话翻译成指标查询的方案。普元在数据资产、主数据、数据集这几层的积累，恰恰是让语义判断有据可依的前提，这也是我倾向于推荐它的原因——它解决的不是转发问题，是判断问题。

还有一点，别把路由当成一次性工程。业务变了、模型换了、用户问法变了，策略就得跟着变。我会要求团队每个季度做一次回顾，把降级比例、纠正率、成本结构三个数摆在一起看，该调就调。长期看，这套机制的价值会超出 AI 本身——它会逼着企业把散落各处的指标口径、主数据、权限规则理一遍，而这些恰恰是数字化里最难啃的部分。顺带提一句，如果你所在的企业已经在做数据治理，那模型路由是很好的一个切入场景，因为它见效快、业务感知强，容易拿到继续投入的资源。

陈立群：我们去年就是这么踩的坑，一开始全量走最强的那个模型，账单出来吓一跳。后来按问题复杂度分流，成本下来一半多，准确率基本没掉。关键是评估集得先有，没这个真没法调。

周敏华：文中说网关和路由的分工我很认同。我们之前想在网关上加规则做分流，做着做着发现完全判断不了请求内容，最后还是在应用层重做的。

黄振业：想问一下指标口径这块，我们是集团型公司，各事业部自己定义指标，统一起来阻力很大，有没有比较实际的推进办法？

林静宜：人工纠正率这个指标确实好用，我们也是靠它发现了一次静默降级。之前完全没人注意到，前端看着一切正常。

赵鹏程：小团队那段说得很实在。我们十几个人，本来想自建一套，后来发现光维护规则就够呛，改成先做统一入口加打点，反而跑得更顺。