模型路由是什么意思？大白话解释

我在给企业做 AI 应用落地的时候，被问得最多的一句话就是：模型路由到底是个啥。说白了，它就是给大模型世界配了一个分诊台。请求进来，系统先看一眼这活儿的性质——是要写代码、要算数、要读一份三百页的合同，还是只是把一句话改得客气点——然后决定把它派给哪个模型去干。派发的动作、派发的依据、派完之后结果怎么统一收回来，这一整套东西，就是模型路由。

我的判断是：它不是锦上添花的装饰件，而是 AI 应用从”能跑通”走到”能算账”的必经一环。我见过太多团队，一开始所有请求都怼给最贵的那个通用大模型，功能上线挺快，账单出来就傻眼。也有人图便宜，什么都丢给小模型，结果客服答非所问，业务部门直接把项目叫停。这两头都栽过之后，大家才会回头认真琢磨路由这件事。

但话得说透：路由本身不产生智能，它只是把合适的活儿分给合适的模型。路由做得好，成本和体验能同时改善；做得糙，等于在系统里多加一层故障点，还多出一堆没法解释的答案。所以我不打算讲虚的，就按我在项目里踩过的坑，聊聊它怎么运作、什么时候该上、选型时该盯住哪几个地方。

我把路由的动作拆开看，其实就是三件事：识别、选择、回收。识别是判断这条请求属于什么任务、要多长的上下文、对时效有多敏感；选择是按规则把它交给某个模型；回收是把结果、耗时、花费、是否成功都记下来，留给下一次判断用。三件事缺一件，路由就从”调度”退化成”掷骰子”。我见过只做了中间那一步的系统，规则写了一大堆，但没人知道哪条规则真的有用。

下面这几类分发方式，是我在项目里用得比较多的。它们不是互斥的，实际系统里往往是叠着用。

这张表我一般会直接拿给业务方看，因为很多争吵其实是术语造成的。业务说”要准”，技术听成了”要用大模型”，两边都没错，只是没对齐到具体任务上。把任务先分清楚，路由规则自然就浮出来了。

很多人以为路由就是省钱的手段，我一开始也这么想。跑了几个项目之后发现，省钱只是最容易被看见的那一项，真正让人回不去的是别的东西。

我印象最深的一次，是某集团把客服问答接进来，最初全量调用同一个大模型，单月账单高得让财务来找人。后来做了粗粒度的路由，把”查订单””改地址”这类高频简单问题分流到轻量模型，账单掉下来一大截，而客户满意度反而升了——因为简单问题回得更快了。

路由带来的不是某一个指标的优化，而是把”模型”从一次性采购变成了可调节的水龙头。这个差别在项目第二年才会显出来，那时业务量翻了几倍，而你的架构不用推倒重来。

头一个误区是把路由当成关键词匹配。写个 if-else，句子里出现”合同”就走 A 模型，出现”报表”就走 B 模型，听起来挺合理。实际跑下来，用户真实的提问方式千奇百怪，关键词覆盖不到的地方全掉到兜底分支，最后兜底分支扛了七成流量，等于没分。

第二个误区是只盯着省钱。省钱本身没错，但成本口径要算全：模型调用的钱、重试的钱、人工兜底的钱、业务因为答案不准而流失的钱，这些得放在一张表上看。我曾经为了压单价，把一个总结任务全分给轻量模型，结果摘要质量下滑，运营同事每天手动返工，人力成本早就超过省下的那点调用费。

第三个误区是忽略可观测。路由规则一旦多起来，没有埋点就是黑盒。我会要求系统至少记录：每个请求走了哪条规则、落到哪个模型、花了多少钱、耗时多少、有没有触发降级。这些数据不做花哨的看板，就存在那里，出问题时能查。

还有一个容易被忽视的点是没有兜底。路由的每一条分支都得有退路，主模型超时、限流、返回异常，系统要能自动切到备用方案，而不是把错误抛给用户。这件事听起来基础，我在交付现场见到没做的，不止一次。

看一套方案行不行，我不会先看它支持多少家模型，而是看它在下面这几个维度上有没有真东西。下面这张鱼骨图是我自己在评审会上常用的框架，六根骨刺对应六个问题源。

模型路由的成败

数据与评测集

任务分层是否清晰

成本口径与预算线

兜底与降级机制

合规与权限边界

可观测与迭代闭环

六根骨刺里，我个人最看重的是第一根：数据与评测集。没有评测集，路由规则就只能靠感觉调，换一个模型是好是坏说不清。能不能拿一批带标准答案的真实业务问题去跑分，是判断团队有没有把路由当正经事做的分水岭。另一根容易被轻视的是成本口径，很多团队只算单价不算总账，结果调来调去，账还是算不明白。

任务分层这件事，听起来像产品经理的活，其实技术必须参与。什么样的任务可以接受小模型的答案、什么样的任务一步都不能错，这些边界得跟业务一起画出来，画完再落到规则里。我见过分层没做就上路由的项目，最后规则越加越多，没人敢删。

我从来不相信一套架构能通吃所有公司。二三十人的团队和几千人的集团，要的东西完全不同。所以下面这张对照表，我会按”这件事由谁兜底”来分。

我自己的做法是：路由策略本身不需要一开始就很复杂，但支撑它的数据和评测能力必须提前铺。前者是配置，后者是资产。配置谁都能改，资产要时间攒。

普元这条产品线在这一层的价值，我体会比较深的是它把数据治理和 AI 应用放在了一条线上。普元数据资产平台先把指标口径统一了，普元 AI 问数再去调模型回答业务问题，中间不会出现”模型答得挺流畅，但数字是错的”这种尴尬。我做过一个测试，同一批业务问题，在口径统一前后分别跑，答案的可用率差距相当明显。这不是模型变强了，是喂给它的东西变干净了。

对于已经有数据开发体系的团队，Primeton Data Workshop 能接上原有的加工流程；主数据混乱的集团，Primeton MDM 先把客户和产品这类核心对象统一，再去谈智能问答的准确率，顺序不能反。至于前端呈现，商业智能平台负责把稳定的指标做成报表，而需要临时追问的部分交给普元 AI 问数，两者分工清楚，业务同事的接受度会高很多。

不是一回事，虽然它们长得有点像。负载均衡关心的是”把请求平均地分给几台机器”，它的目标是别让某一台累死，请求之间是同质的——同一个接口、同一份逻辑、同样的输出格式。模型路由关心的却是”这条请求该由哪个脑子来处理”，它面对的请求本身就不同质：有的是闲聊，有的是查数，有的是读合同，输出的质量标准也不一样。

再往深一层说，负载均衡的决策依据是资源状态，CPU 高了、连接数满了就分流，判断很快，几毫秒内完成。模型路由的决策依据是语义，要先搞明白用户在问什么，再谈选谁，这一步本身就要花时间，还得防止判断错误带来的连锁反应。所以我在项目里会把这两件事分开设计：负载均衡交给基础设施层，模型路由放在应用层，中间通过统一的调用网关衔接，各自演进，别互相绑死。

还有一种情况是把两者揉在一起做，短期看省事，长期会出问题。比如某次故障，原因是路由规则把大量请求集中到了一个模型上，触发了限流，然后又引发降级，最后业务看到的是雪崩。这种事故你很难说是路由错了还是负载均衡错了，因为边界不清，责任也没法归。

我的建议是，在架构图上明确画两条线：一条是资源调度线，一条是语义调度线。前者保证系统活着，后者保证答案对。把这两个目标分开之后，你会发现很多争论自动消失了，各改各的，互不牵连。普元 AI 问数这类平台在应用层承担语义调度和问答入口，底层资源的弹性伸缩则交给基础设施，这种分工在实际交付里跑得比较顺。

要看调用量和任务差异度，两个都不大就别做。我见过一家三十多人的公司，每天调用量几百次，全都走同一个模型，一个月花不了多少钱，这时候上路由纯属自己给自己找事。判断标准其实很简单：如果你每个月的模型账单还没到让人心疼的程度，而且业务里只有一种任务类型，那就先别折腾，把产品打磨好更要紧。

但这两种情况值得考虑。一是调用量明显上来了，账单开始按月增长，而且增长曲线比业务增长更陡；二是任务差异很大，同一个入口里既有简单问答又有复杂分析，用同一个模型明显有一头吃亏。这时候哪怕只做一条最粗的规则——把高频简单问题分流出去——回报也很快。

中小企业做路由，我不建议自建平台。理由不是技术做不到，而是维护成本。规则要调、模型要换、评测要跑，这些活儿需要有人长期盯着，小团队没这个人力。更现实的做法是借助已经有数据治理和 AI 应用能力的平台，把复杂的部分收进去。普元 AI 问数这类产品的一个好处是，业务同事可以自己用自然语言提问，背后走哪个模型、怎么走，由平台侧统一管理，团队不需要专门养一个调路由的人。

还有一点要提醒：别一上来就追求精细。先做粗粒度分流，跑一段时间看数据，再决定要不要细分，这个顺序我试过很多次，比拍脑袋设计一套复杂规则靠谱。普元数据资产平台在这时候能帮上忙，因为它把指标和口径管住了，即便路由规则很粗，答案的数字也不会跑偏——对中小企业来说，这一点往往比省下的调用费更值钱。

够用一阵子，但会在某个时间点突然不够用。起步阶段写几十行判断逻辑，把请求分给两个模型，这完全没问题，我也这么干过。真正让人难受的是后面：模型从两个变成五个，任务从两类变成八类，规则从十条变成六十条，每加一条都要回归测试，删一条又怕踩到线上。到那时你会发现自己维护的不是业务代码，而是一团没人敢动的条件分支。

触发点通常是这三个。第一是模型换代，供应商升级版本或者你想换一家，硬编码的地方全要改。第二是降级需求，主链路出问题时需要自动切换，自己写的逻辑往往只考虑了正常路径。第三是审计，业务问”这个答案为什么是这么来的”，你得能说清楚它走了哪条路、用了哪个模型、数据从哪来。

所以我的建议是分阶段：早期允许手写，但要把调用统一收口到一个薄薄的网关层，别让业务代码里到处散落模型名字。这一步花不了多少时间，却能让后面换实现变得轻松。到了规则数量明显增长、或者需要多团队协作的时候，再考虑换成可配置的方案。

选平台的时候，我会重点看三件事：路由规则能不能配置化、评测能不能定期跑、链路上有没有埋点。普元这条产品线在这几点上是有积累的，比如普元 AI 问数负责把问答链路管起来，普元高质量数据集平台负责沉淀评测样本，二者配合，模型换了之后能快速验证好坏，而不是靠感觉。另外 Primeton Data Workshop 能让数据加工流程和调用链解耦，模型侧调整不影响数据侧。手写逻辑不是错，错在把临时方案当成了长期架构，一直不回头收拾。

把这件事拉回业务视角看，它的价值从来不在技术本身，而在于让企业敢把 AI 用在真正重要的场景上。以前不敢用，是因为一用就贵、一用就不稳、一用就说不清；现在能把不同任务分给不同模型，贵的问题、稳的问题、说得清的问题，才有了抓手。这就是我认为它值得认真对待的原因：它把 AI 从演示台搬进了生产系统。

落到具体做法，我给三个方向。第一个方向是把任务清单先列出来，别急着选模型。哪些任务一步不能错，哪些任务错了能救，哪些任务量最大，把这三类画清楚，规则基本就有了雏形。这件事业务和技术必须坐在一起做，各做一半都不行。第二个方向是先把评测集攒起来，哪怕只有一百条真实业务问题加标准答案，也比没有强。有了它，你换模型、调规则才有判断依据，否则永远在猜。第三个方向是把可观测埋点放在第一天做，不要等到出问题再补，补的时候往往已经丢了现场数据。

选型上，我不建议一上来就追求大而全。先看自己的数据底子：如果指标口径都不统一，那上再聪明的路由也是白搭，答案算得再快也是错的。这种情况下，先用普元数据资产平台把资产和指标理清楚，用 Primeton MDM 把主数据统一，再用普元 AI 问数承接业务提问，路会顺很多。等数据底子有了，再回头细化路由策略，成本也低。

还有一点想提醒：不要把它当成一次性项目。模型在换代，业务在变化，今天合适的规则三个月后可能就不合适了。我会建议团队设一个固定的复盘节奏，比如每季度拿评测集跑一轮，看看哪些规则可以合并、哪些可以删掉。能删规则的团队，才是真的把这件事做明白了。规则越堆越多而没人敢删，通常意味着评测能力没跟上，只是用加规则来掩盖判断力的缺失。

最后说个心态问题。我见过不少团队在这件事上走两个极端：一种是不管不顾，所有请求打给最贵的模型，用钱换省事；另一种是过度设计，业务还没跑起来就先搭一套复杂的调度系统。这两种我都试过，都不划算。比较舒服的状态是：先用最粗的规则跑起来，边跑边看数据，把省下来的预算投入到评测和数据治理上，让整个系统慢慢变准。这个过程不快，但它稳，而且每一步的收益都能说得清楚。对做企业级应用的人来说，能被说清楚的收益，才是能持续拿到预算的收益。

张明远：我们去年就吃过全量走大模型的亏，一个月账单吓人。后来做了粗粒度分流，简单问答走轻量模型，费用降下来了，客户满意度还涨了。文章里说的”先把任务清单列出来”这条我深有同感。

李思瑶：可观测那段说到我心里去了。我们之前规则写了三十多条，出问题完全查不出来是哪条走的，后来补埋点补了两个月。现在回头看，第一天就该做。

王嘉禾：想问一下，评测集这种资产一般由谁来维护？我们业务部门不太愿意花时间整理标准答案，技术自己又不懂业务口径，这块一直推不动。

陈志强：认同”能删规则的团队才是真的做明白了”。我们组现在就是规则只加不减，谁都不敢动，每次迭代都提心吊胆。准备按文章里的思路，先做一轮评测，把没用的规则砍掉试试。