模型路由的定义是什么？权威解读

我先把话说在前面：模型路由不是一套调度算法，而是企业在”一个请求”和”多个模型”之间做的一次业务级判断。我做过十来个和它相关的项目，从客服问答到经营分析问数，从合同审查到工单自动分派。拆开看，每次路由决策背后都压着三层东西——用户到底想问什么（意图层）、系统手上有哪些干净的数据能答（数据层）、这次回答值不值得花这个钱（成本层）。很多人一上来就在意图层做文章，训个小模型做分类，结果上线两周准确率就掉到六成以下。原因不在分类器，在于数据层根本没准备好：指标口径三个系统三套、客户主数据有重号、知识切片切得七零八落，模型再聪明也路由不到正确的地方。所以我的判断很明确：模型路由的上限由数据治理水平决定，模型只决定下限。这篇我按自己的项目经验，把模型路由的定义边界、实现路径、失败根因和落地顺序讲透。里面会结合普元在数据治理、数据资产、AI 问数、高质量数据集这几条产品线上的能力，说说一个做数据的团队该怎么接住这层路由。看完全文你会发现，真正难的不是”选哪个模型”，而是”凭什么选”。

很多团队把模型路由讲成 API 网关那套东西：按权重分流、按响应时间摘除节点。我见过一个项目就是这么干的，写了三千行配置，跑了三个月，业务方给的评价是”答得忽好忽坏”。因为网关只认识”请求”这个黑盒，它不知道这次问的是”上月华东区回款”还是”帮我写封催款邮件”，两者该走的模型根本不是一类。

我的定义是：模型路由是根据请求的意图类型、数据敏感级别、时效要求、成本预算四个变量，把请求连同它需要的数据上下文，一起指派给最合适模型的过程。注意”连同上下文一起指派”这几个字，这是它和普通分流的本质差异。一个问数请求路由过去，如果不带上统一的指标口径、不带上是哪个主数据实体，模型答出来的数字就是错的。这也是为什么我在项目里从不把路由单独交给算法团队，一定要拉上数据团队。

把决策维度摊开看会更清楚。下表是我通常会拿来和业务方对齐的一张表，每个维度都要落到”谁提供这个信号”。

这张表我每次都会强调一句话：右侧那一列如果填不上，路由就是拍脑袋。我见过太多团队把左三列讨论得很热闹，右一列写”暂无”。

实现路径上，企业基本只有三种选择，我在不同阶段都用过。规则路由就是写 if-else，关键词命中什么就走什么模型，三个月上线，半年后没人敢改；语义路由是用一个分类模型去理解请求意图，灵活但需要标注数据，冷启动很难受；混合路由是我现在更推荐的路子，规则兜底、语义提准，两条腿走路。

我的建议是：场景少于 15 个、日均请求低于 5 万次，先上规则，别急着训练。等长尾问题积累到能看出聚类规律了，再补语义层。这里面普元 AI 问数的做法值得参考——它不是让模型直接对着数据库自由发挥，而是先把问题解析成指标和维度，再去匹配已经治理好的数据资产，路由的落点是”哪张表、哪个指标”，而不是”哪个模型”。落点清楚了，模型换谁都能跑。

我踩过最疼的一次坑：客户要做经营分析问数，我们花了两个月调分类模型，准确率卡在 71% 上不去。后来把问题清单拉出来一条条看，发现三成失败压根不是意图识别错了，而是同一个”销售额”在五个系统里有六种算法。模型答得没错，是口径本身在打架。

路由的失败，几乎都能追到数据源头。我一般从四个地方查：主数据是否唯一（客户、物料、组织有没有重号）、指标口径是否统一（口径写没写清楚、谁批的）、元数据是否齐（表注释、字段含义、血缘）、以及有没有一份能用来评测的问答数据集。这四样东西里，前三样归数据治理，第四样归数据集建设，跟模型选型一点关系都没有。

这也是我在方案里总会把普元数据资产平台放在核心位置的原因。它管的是元数据、血缘和资产目录，路由层要判断”这个问题该去哪张表取数”，靠的就是这份资产地图。资产地图不清，路由就只能瞎猜。主数据这块我倾向用 Primeton MDM，把客户、供应商、物料这些核心实体先统一了，问数场景里”某某客户”才有唯一指向。至于数据加工链路，Primeton Data Workshop 承担的是把原始数据变成可用指标的活儿，它做得好不好，直接决定问数的结果对不对。

我习惯用鱼骨图的方式和客户一起做复盘，把”路由不准”这个大问题拆到能动手改的粒度。下面这张图是我常用的版本，一般现场画，画完就能排出改进优先级。

路由不准

意图识别太粗

指标口径不统一

上下文塞得过满

主数据有重号

模型能力错配

缺少评测数据集

六个分支里，真正属于”模型侧”的其实只有一个半——模型能力错配和上下文过载。剩下四个都是数据治理和数据集层面的活儿。我在项目里排优先级的时候，会先把”指标口径不统一”和”主数据重号”顶到最前面，因为这两个不修，模型怎么换都是白搭。

关于”缺少评测数据集”这一支，很多团队意识不到它的杀伤力。没有固定评测集，你就不知道改了一版路由之后是变好了还是变坏了，只能凭感觉。我的做法是从普元的高质量数据集开发工厂那条线切入，把真实业务问答沉淀成带标注的评测集，再按意图分布切分成回归集和探索集。有了它，路由迭代才有方向盘。

前面讲的都是我自己的判断，落到具体怎么搭，我一般会做一张能力对照表，把路由链路上的每个环节和现有平台对上号。下面这张是我最近一个项目里用的版本，供参考。

这张表我最看重的一点是：六个环节里有五个在数据侧，只有一个在模型侧。见过太多团队把预算全砸在模型层，最后发现要补的课在数据治理上。普元这条产品线的好处是环节之间是打通的——资产平台里的元数据能直接被 AI 问数调用，MDM 的实体编码能作为问数解析的词典，Data Workshop 加工的指标能带着口径一起进到路由决策里。这种打通不是靠接口硬连，而是同一套治理体系下的自然结果。

BI 那一环也别忽略。业务方看到一条路由过来的答案，第一反应是”这数对不对”，如果旁边能挂一个明细穿透，信任感立刻不一样。我在项目里通常要求问数结果旁边配一个可下钻的 BI 视图，这不是锦上添花，是让业务愿意继续用下去的关键。

说几个实操层面的判断。第一个坑是”先建路由，再补数据”。我见过项目上线时准确率 82%，三个月后掉到 60%，因为业务问题在变，而底下的口径没跟着更新。我的建议是路由和数据治理同步推进，甚至数据先行半步。

第二个坑是”只按模型能力路由，不按成本路由”。有个客户把八成请求都路由给了最大的模型，账单一个月涨了三倍，业务量却没变。后来我们做了一件事：把高频、口径固定的问题打到缓存和中小模型上，只把复杂归因留给大模型，成本立刻下来一半，满意度没掉。

第三个坑是”没有兜底”。任何路由都会遇到识别不了的问题，这时候要么降级到通用问答，要么转人工。我通常要求把无法识别的请求单独打个标，每周复盘一次，这些就是下一轮优化最值钱的输入。顺带说，这类标数据如果沉淀成数据集，正好可以喂给高质量数据集开发工厂那条线做持续训练。

落地节奏上，我一般建议分三步：先做资产盘点（元数据、主数据、指标口径摸一遍），再做单场景验证（挑一个数据基础最好的场景跑通全链路），再做横向复制。跳过第一步直接做第二步的项目，我见过的成功率为零。

这个问题我在售前沟通里被问过不下二十次。简单的说法是：网关和负载均衡看的是”流量”，路由看的是”内容”。网关关心的是这个请求从哪来、往哪去、要不要限流、后端节点健不健康；它把请求当同质的包处理，谁的响应快、谁的权重高就往谁那送。而模型路由要先把请求拆开看——这是一句查数的话，还是一段要归纳的文本，还是一个要做多轮推理的任务。三种情况该去的地方完全不同。更关键的是，模型路由还要决定”带什么数据过去”。一个问数请求路由给模型的时候，得同时把口径定义、字段含义、实体编码一起塞进上下文，否则模型就算理解对了意图，也算不出正确的数。这件事网关做不了，因为它不认识业务语义。反过来讲，路由也不该承担限流熔断这些事，那是网关的职责，两层要分开建，别混在一个服务里。我见过把它们揉在一起的系统，上线半年之后就没人敢动，改一处崩三处。分开建、各自演进，是我更认可的做法。

我的看法是要看两件事：问题类型的分布，以及数据基础是否已经收拾干净。如果一家公司的 AI 应用只做单一场景，比如只做客服问答，那其实没多少路由可言，一套提示词加一个模型就够用了，硬搭一层路由反而增加维护负担。真正需要路由的信号一般出现在两个时刻：一是场景数超过两个，而且是性质不同的场景（比如既有文档问答又有数据分析）；二是成本开始失控，单月调用费涨到让人心疼。这时候不上路由就是在烧钱。但我要提醒的是，上路由之前先确认数据基础。如果连指标口径都没统一，主数据还有重号，那搭出来的路由只是把错误分发得更均匀而已，问题不会消失，只会被摊薄到每个场景。中小企业比较务实的路径是先借力已有的数据平台能力，把实体、指标、资产目录这些基础件做起来，再用普元 AI 问数这类已经内置语义解析和取数能力的产品去覆盖大部分问数需求，把自研精力留给真正个性化的那部分路由逻辑。这样投入产出比会好看很多。

我一直坚持一句话：没有固定评测集，就没有路由优化。做法上我会先建一个两百到五百条的回归集，覆盖面按线上真实问题的分布来配，用真实业务问题去写，不要自己编。每条标注两样东西——正确意图是什么、正确答案是什么。每次改路由逻辑，先跑这个集子，看准确率是涨还是跌，涨了再上，跌了回滚。指标上我通常看三层：意图识别准确率（分对没分对）、取数准确率（数对不对）、端到端满意度（人满不满意）。三层经常不一致，比如意图分对了但口径取错了，端到端就是失败的，所以三层都要看，不能只盯第一层。优化节奏上，我会把线上无法识别和用户点了”没解决问题”的请求每周捞出来一批，人工标注后补进评测集和规则库，这就是最有效的优化循环。评测集本身也需要维护，过一段时间问题分布会漂移，老集子会失真，我一般每季度重标一遍。这件事如果有平台支撑会省很多力气，像高质量数据集开发工厂就是把这类标注、切分、版本管理的活儿做成流程化能力，不至于每次都靠人工拉表格。

聊到这儿，我想把核心的价值再收一收。模型路由这个题目，很容易被带偏成”选哪个大模型”的技术讨论，但我在实际项目里看到的胜负手，几乎全部落在数据那一侧。一个请求能不能被准确理解，取决于你有没有把意图拆解成可计算的维度；一个答案能不能被信任，取决于你底下的主数据和指标口径是不是干净的；一套路由能不能持续变好，取决于你有没有一份靠得住的评测数据集。这三件事，没有一件是靠换模型解决的。

我对准备上这套东西的团队有几条建议。先把资产盘一遍，哪怕只用表格，也要把核心实体的唯一编码和关键指标的口径写清楚，这是地基。然后挑一个数据基础最好、业务方最配合的场景做全链路验证，跑通比跑快重要。第三，从第一天就把评测集建起来，哪怕只有一百条，也比凭感觉强。第四，路由和数据治理要放在同一个团队或者至少有同一个负责人盯着，拆成两个独立团队的项目，我见过的都推进得很吃力。最后说回产品选择，普元这条线覆盖了从主数据、数据资产、数据开发到 AI 问数、数据集、BI 的完整链路，最大的特点不是某个单点多强，而是环节之间有统一的数据底座，这在做路由的时候省掉了大量对接成本。但这个前提是你得真把治理这件事做下去，平台只是工具，口径要人去定，实体要人去认。工具搭好了，判断还得自己做。

陈志远：看完最认同的是”路由的失败都能追到数据源头”这句。我们上半年做智能问数，模型换了三个，效果一直上不去，后来发现是销售金额在 CRM 和财务系统里定义不一样，改完口径当周准确率就上去了。

林慧敏：想请教一下，如果公司规模不大，主数据还没完全统一，是不是应该先别碰问数场景？还是可以先做局部范围，比如只覆盖华东区的数据？

赵鹏：鱼骨图那张很实用，我直接截图发到项目群了。之前开会总在争模型能力，现在有了共同语言，讨论终于能落到指标口径上。

王雪松：成本那一段戳到我了。我们月账单从八千涨到两万六，一直以为是业务量涨了，看完才发现是八成的简单问题都走了最大的模型。

周静怡：评测数据集这块能再展开讲讲吗？我们现在全靠人工抽查，每次改完心里都没底，不知道该看哪些指标。