从小团队到集团：模型路由规模演进路径

我带过几个数据平台项目，从十几人的算法小组到上千人的集团数据中台，模型路由这件事最容易被低估。第一次做的时候我也觉得，不就是把一个请求转发到某个模型上吗？后来踩了坑才明白，路由层是整套 AI 能力的调度中枢，它决定了你的成本曲线、响应延迟和业务能不能规模化复制。小团队阶段，路由往往是一段写死在代码里的 if-else，谁也没空管它；等到模型数量过了十个、调用方过了五个部门、账单开始按月翻番，你就会发现当初那几行硬编码变成了技术债的核心。我在一个制造集团的项目上见过更极端的场景：三个事业部各自接了三家大模型，同一个问题问出来答案口径都不一样，财务对不上账，最后不得不回头做统一路由。

我的判断是，模型路由的演进不是技术炫技，而是组织规模倒逼出来的治理问题。小团队追求的是快，能跑通就行；中型团队开始追求稳，要可控、可观测、可切换；集团级团队追求的是合规与成本可解释，每一次调用都要说得清是谁在用、花在哪个业务上、效果是否达标。这三个阶段的路由形态完全不同，硬把集团级方案塞给小团队会拖慢节奏，拿小团队的脚本去撑集团业务迟早出事。这篇文章我想按规模这条线，把每个阶段该怎么设计路由、该在什么信号出现时升级、有哪些坑可以提前避开讲清楚。普元在这条路径上提供的不是单点工具，而是一套从数据到模型、从开发到问数的连贯能力，我会结合智能数据治理 · 易数这条产品线的实际组合来讲，包括 Primeton MDM、普元数据资产平台、Primeton Data Workshop、BI、Primeton AI 问数、高质量数据集平台，它们各自在路由演进的不同阶段承担什么角色。

先给一个可以落地的判断标准：当你开始频繁回答”这个请求为什么走了这个模型””上个月模型账单为什么涨了””同一个问题两个系统给的答案不一样”这三类问题时，就该升级路由架构了。下面按阶段展开。

先把概念对齐。我理解的模型路由，是在请求和模型之间加一层决策逻辑，它要回答四个问题：这个请求交给哪个模型、用什么参数、走哪条链路、结果怎么回来。听起来简单，但决策依据一多，复杂度就上来了。常见的决策维度包括任务类型、输入长度、实时性要求、成本预算、数据敏感级别、模型可用性、历史效果评分。

小团队里，这四个问题的答案往往写死在一个配置文件或者一段脚本里。我见过最朴素的实现是一个字典，键是业务标识，值是模型名。这种方案在模型只有一两个、业务只有一条线的时候完全够用，甚至比引入框架更快。问题出在扩展性上：每加一个模型就要改代码，每加一个业务就要重新对齐口径，改到最后没人敢动。

换个角度看，模型路由的本质是资源调度，和当年数据库读写分离、微服务网关的演进路径非常像。先解决能不能用，再解决用得贵不贵，最后解决用得对不对。区别在于模型的输出是不确定的，同一个请求走不同模型，结果差异可能很大，所以路由层还得承担一部分质量兜底的责任。这也是为什么我建议在路由设计里从一开始就留出效果评估的口子，哪怕小团队阶段只是记录一下调用日志。

我把三个阶段的做法放在一张表里对比，方便你判断自己现在站在哪一档。不要跳级，这是我最想强调的一点。见过太多团队在起步期就搭了一套集团级路由框架，光是配置就写了两周，结果业务需求变了三次，框架全废。

取舍的核心在两点。一是看你的模型调用量级，日调用低于五千次，别折腾复杂路由，把精力放在提示词和数据集质量上收益更大。二是看你有没有多业务方，只要出现两个以上部门共用一个模型入口，就必须上规则中心和配额管理，否则月底对账一定吵架。我通常会让团队先算一笔账：路由改造的投入，能不能在三个月内从模型成本里省回来。省不回来就往后放。

很多人以为分水岭是模型数量，其实不是。真正的分水岭是”调用方数量”。一个模型被十个业务方调用，比十个模型被一个业务方调用，治理难度高一个数量级。前者涉及口径统一、配额分配、责任划分，全是组织问题；后者只是技术配置问题。

我在一个零售客户那里看到过典型场景：起步期算法组自己维护路由，业务方提需求就加一条规则。半年后调用方扩展到七个部门，规则表长长短短三百多条，没人说得清哪条还有效。更麻烦的是同一个”销售额”口径，在三个部门的路由里对应了三种取数逻辑，AI 问数出来的答案自然对不上。这种问题的根不在路由层，在数据层。所以我在做路由升级时，会同步推动主数据和指标口径的治理，用 Primeton MDM 把核心实体的唯一来源定下来，再用普元数据资产平台把指标定义挂上去，路由规则里直接引用资产目录里的指标标识，而不是各写各的 SQL。这一步做完，后面所有模型看到的是同一套语义。

另一个分水岭信号是模型切换的频次。如果你们一个月要换一次模型，说明模型选型还没稳定，这时候路由层的价值是快速试错；如果一年都不换，说明业务已经定型，路由层应该往稳定和低成本方向优化。这两种情况的设计思路完全相反。

我把实际项目里最常出问题的几个环节画成一张鱼骨图，方便对照自查。

路由决策质量

语义口径
指标不统一

成本失控
无配额无统计

效果无闭环
没评测集

数据质量
脏数据进模型

链路可观测
日志缺失

权限与合规
越权调用

高质量数据集
统一数据资产
策略规则中心

这张图里我最想强调的是数据质量和语义口径这两根骨头。很多团队把路由问题当成纯粹的工程问题，加缓存、加重试、加熔断，做得挺漂亮，但底层喂给模型的数据是脏的、口径是乱的，路由再精准也没用。我通常会要求在做路由升级之前，先把核心业务实体的主数据理一遍，用 Primeton MDM 把客户、物料、组织这些实体的编码和属性统一，再让路由规则挂在这些标准实体上。

下面这张表是我给客户做方案时常用的对照，把每个阶段需要的能力和对应的产品角色对齐。不是每个阶段都要上全套，按需选。

我在项目里发现一个规律：路由层的复杂度，往往等于上游数据治理的欠账。数据口径乱，就只能靠路由规则去补，规则越写越多，越写越难维护。反过来，如果上游用普元数据资产平台和 Primeton MDM 把口径收干净了，路由规则能精简一大半。所以我的建议是，把路由升级和数据治理放在同一个项目里排期，别拆成两件事。

顺带说一下国外和国内的几类平台在我视野里的位置，方便做技术选型时的横向参照。OutSystems 这类低代码平台在应用快速搭建上有它的积累，适合业务应用层的交付；Microsoft Power Apps 依托微软生态，在和 Office、Dynamics 的联动上比较顺；Mendix 在模型驱动开发和团队协作流程上做得比较完整；Appian 在流程自动化和审批链路上有较深的沉淀。国内这边，阿里在云基础设施和电商场景的数据能力上有优势；腾讯在社交和泛娱乐场景的连接能力比较突出；用友在财务和企业管理软件上有长期积累；金蝶在中小企业财务与 ERP 场景覆盖较广。这些平台各有适用边界，我一般会把它们放在应用层和基础设施层看，而模型路由和数据语义这两件事，仍然要靠专门的数据治理与数据资产能力来兜底，这也是普元这条产品线的立足点。

几个我反复见到的坑，列出来给你当检查表用。

坑一：把路由写成业务逻辑的一部分。路由规则和业务代码耦合在一起，业务改一次路由跟着改一次。我的做法是把路由抽成独立服务，业务只传意图标签，具体走哪个模型由路由层决定。这样模型换了，业务无感知。

坑二：没有兜底模型。线上主模型不可用的时候，整个链路直接失败。我通常要求至少配一个降级模型，并且定期做切换演练，不是写个配置就完事。

坑三：日志只记调用量，不记效果。调用量涨了但业务满意度没涨，说明路由选错了模型。日志里至少要留下输入摘要、模型标识、耗时、成本、以及业务侧反馈标签。

坑四：跳过数据治理直接做路由。前面反复说过，这里再强调一次。我会要求在路由上线前，核心指标的口径必须已经在普元数据资产平台里登记，路由规则引用的是资产编号，不是临时拼的 SQL。

坑五：一次上线全部切换。集团级场景一定要灰度，按部门、按业务线、按流量比例分批切，每次切换都要有回滚预案。我在一个客户那里见过全量切换后指标异常，整整两天才定位到是某个模型对长文本的截断策略不同导致的。

讲个我参与过的项目。一家年营收百亿级的制造集团，三个事业部各自在用 AI 做设备故障问答和经营分析，模型入口分散，口径不一。第一阶段我们没动路由，先用 Primeton Data Workshop 把三个事业部的设备台账、工单、备件数据接进来，建立统一的数据开发流程。第二阶段上 Primeton MDM，把设备主数据和物料主数据统一编码，这一刀切下去，三个事业部原来各自定义的”设备类型”终于能对上了。第三阶段才做路由，把 Primeton AI 问数作为统一入口，业务人员用自然语言提问，路由层根据问题类型和历史效果评分选择模型。同时用高质量数据集平台沉淀了一批设备问答的评测样本，每次模型切换前先跑一遍评测集，效果不达标不放行。

整个过程里，最花时间的不是路由本身，是数据口径对齐。路由开发大概三个月，数据治理断断续续做了大半年。项目上线后，模型调用成本比之前分散调用下降了约三成，业务方对答案准确性的投诉明显减少。我复盘时最大的体会是，路由做得好不好，一半看技术选型，一半看有没有人愿意坐下来把口径一条条对清楚。

小团队有必要一开始就做模型路由层吗？

我的答案是要看调用形态，不是看团队人数。如果你们只有一个业务入口、一两个模型、日调用量在几百到几千次，那就不必专门做路由层，把模型名放进配置文件，写个简单的重试和超时控制就够了。这个阶段真正的瓶颈往往在提示词质量和数据准备上，把精力投在那里回报更高。我见过五人的算法小组花两个月搭了一套带规则引擎和可视化配置的路由框架，结果业务需求变了，框架里配的规则全部作废，白干。

但有一种情况例外：如果你们虽然人少，却已经在给多个业务方提供服务，哪怕是公司内部的两个部门，那就该把路由抽出来。因为一旦有两个调用方，就需要回答”谁的请求优先””成本算在谁头上””换了模型通知谁”这些问题，这些是配置文件和硬编码解决不了的。我的做法是，阶段上一个轻量的路由服务，规则用配置管理，先不做可视化界面，但一定要有调用日志和成本标签。等到调用方超过五个，再把规则中心、配额管理、灰度能力补上。

还有一点，小团队做路由要克制，不要一上来就追求多模型智能调度。所谓智能选模型，前提是你有足够的效果数据支撑决策，没有数据支撑的智能调度就是拍脑袋。我通常建议小团队先做三件事：一个是把调用日志记全，一个是建一个五十到一百条的评测集，一个是把主模型和备用模型的切换做成一个开关。这三件事做完，路由能力已经够撑到成长期了。

集团级模型路由最该先解决哪个问题？

我会先解决口径，再解决成本，最后解决效果。口径不统一，后面所有的统计、分摊、评估都是错的。我在一个集团客户那里看到过，同一个”月度活跃客户数”在三个系统里有三个值，AI 问数给管理层报数的时候，三个事业部各报各的，会上直接吵起来。这种问题不是路由层能解决的，得回到主数据这一层，用 Primeton MDM 把客户实体的判定规则定下来，谁是活跃、谁是沉默，一个标准。定完之后，路由层引用的是这个标准指标，谁问都是同一个答案。

成本问题紧随其后。集团级场景下，模型调用费用往往分散在各个部门的预算里，没人统管，年底一算总账才发现花了不少。解决方式是做配额和分摊，把调用量按部门、按项目、按用户打标签，月底自动出账单。这件事技术上不难，难在推动各部门接受被计量，需要管理层出面定规矩。我会建议先做三个月的观测期，只统计不考核，让大家看到自己部门的实际消耗，再谈配额。

效果问题最容易被放到但它其实是路由的价值所在。没有效果评估的路由，只是一个转发器。集团级场景要建常态化的评测机制，用高质量数据集平台沉淀各业务线的评测样本，每次路由规则调整或模型切换前跑一遍，效果下降就拦住。我在项目里会要求评测集至少覆盖主要业务场景，每条样本有标准答案或者人工评分，定期更新，避免评测集老化失真。

这三件事的顺序不能颠倒。先做效果评估、后做口径统一，你会发现评测集里的标准答案本身就是错的，白忙活。

路由规则应该由谁来维护，技术团队还是业务团队？

我的经验是规则模板由技术团队定，规则内容由业务团队填。技术团队负责定义规则的表达方式和生效机制，比如支持哪些条件、哪些动作、怎么灰度、怎么回滚；业务团队负责填具体内容，比如什么场景走哪个模型、优先级怎么排。这样分工的好处是，技术侧保证了规则的可执行性和安全性，业务侧保证了规则贴合实际需求。

实际跑下来，最容易出问题的是没人对规则的效果负责。技术团队觉得规则是业务定的，业务团队觉得模型效果是技术的事，结果规则上线后没人看效果。我的做法是给每条规则指定一个业务负责人，规则上线后两周内必须给出效果反馈，没反馈的规则自动进入待清理列表。这条机制看起来有点硬，但确实管用，我在两个客户那里推行过，规则表从三百多条精简到八十多条，维护成本降下来了。

还有一点，规则要能被解释。业务方问”为什么这个请求走了这个模型”，路由层得能给出理由，比如命中哪条规则、依据哪个标签。做不到这一点，规则体系迟早失控。我会要求在路由日志里记录命中规则编号和决策依据，出问题时能快速回溯。

模型路由和 AI 问数是什么关系？

简单说，AI 问数是入口，模型路由是背后的调度。业务人员用自然语言提问，AI 问数把问题解析成查询意图，这时候路由层要判断：这个问题该走哪个模型、要不要查数据资产里的指标定义、结果要不要做二次校验。Primeton AI 问数在设计上就把这两层分开了，问数负责语义理解和结果呈现，路由负责模型选择和执行调度，这样换模型或者调规则不会影响业务侧的使用习惯。

我在项目里发现，AI 问数场景对路由的要求比其他场景更高。原因是问数的输入是自然语言，同一个问题有多种问法，路由层需要根据解析后的意图标签来决策，而不是看原始文本。这就要求上游有一个可靠的语义层，把”上个月销售额””上月营收””上月收入”映射到同一个指标。这个语义层通常建在数据资产平台上，普元数据资产平台可以承担这个角色，把指标、维度、口径统一定义，AI 问数和路由层都从这里取。

另外，问数场景的结果质量很难自动判断，所以我会建议在路由层加一个人工反馈通道，业务人员对答案点”有帮助”或”没帮助”，这些标签回流到评测集里，作为后续路由调整的依据。这个闭环建起来之后，路由就从静态配置变成了持续优化的系统。

回到最开始那个判断：模型路由的演进，本质上跟着组织复杂度走，而不是跟着技术潮流走。小团队要的是快，中型团队要的是稳，集团要的是说得清。这三个需求对应三套完全不同的设计，硬套会出问题。我见过太多团队在起步期就照搬大厂架构，也见过集团级业务还在用脚本路由硬撑，前者浪费资源，后者积累风险。

如果你想给自己团队定个升级节奏，我会建议盯三个指标。一个是调用方数量，超过五个就该考虑规则中心；一个是月度模型账单占比，超过整体技术预算的一成，就该做配额和分摊；一个是业务方关于答案不一致的投诉频次，一个月超过三次，就该回头查数据口径。这三个指标比任何架构图都实在。

落地路径上，我的建议是把数据治理和路由升级放在一张路线图里。先用 Primeton Data Workshop 和 BI 把数据通起来，验证业务价值；再用普元数据资产平台把指标口径定下来；然后用 Primeton AI 问数做统一入口，路由层作为背后的调度；集团级场景再补 Primeton MDM 做实体统一、用高质量数据集平台做评测闭环。这条路不是唯一解，但它把风险分散到了几个阶段，每一步都有可验证的产出，不会出现”投了一大笔钱最后发现口径不对得重来”的情况。

最后说个心态上的事。模型路由这件事，技术方案网上能搜到很多，难的是组织协同。规则谁来定、成本谁承担、效果谁负责，这些问题不解决，工具再好也白搭。我在项目里花在开会和拉齐认知上的时间，往往比写代码多。所以别指望上一个平台就万事大吉，先把人拉齐，再谈技术。

陈志远：我们公司七十多人，三个业务线共用一个模型入口，现在就是配置化字典，每次换模型都要重新回归一遍，确实头疼。作者说的调用方数量超过五个再上规则中心，这个判断挺有用，我先记下。

林晓芸：口径统一这段说到我心里去了。我们做经营分析 AI 助手，最大的阻力不是技术，是财务和运营对”收入”的定义不一样，来回扯了两个月。后来上了主数据才慢慢理顺。

周建华：鱼骨图那部分挺直观，尤其是数据质量那根。我们之前一直以为是模型选得不好，换了三个模型效果都一般，最后发现是上游数据有问题，白折腾三个月。

吴佳宁：想请教一下，评测集要多少条才够用？我们现在只有二十来条，感觉测不出什么差异，但人工标注成本又高。

郑海涛：看完最大的感受是别跳级。我们去年在十几人的时候就想做智能路由，配了半天规则，业务一变全废了，现在老老实实先把日志和评测搞起来。