别只比参数：模型路由实战功能横评

模型路由这件事，我前后参与过七八个项目的落地，最大的体会是：别把它当成一个”选模型”的技术题，它本质上是数据资产和数据治理能力的延伸。很多团队一上来就纠结哪个模型便宜、哪个模型上下文长、哪个模型跑分高，实际跑下来你会发现，真正卡住项目的从来不是参数表，而是”我不知道我有哪些数据能给模型用””我不知道这次调用该走哪条链路””出了问题我查不到是哪一层出的错”。我见过一个金融客户，模型接了三家，路由规则写了四百多行 if-else，上线两个月没人敢动，因为谁也不知道改一行会不会把某条业务线打挂。这就是典型的”路由有了，治理没有”。

所以我的判断逻辑一直是这样的：模型路由的成熟度，取决于你的数据底座是不是足够厚。你的主数据清不清楚、指标口径统不统一、元数据血缘全不全、敏感字段有没有分级，这些东西直接决定了路由规则能不能写得干净、能不能自动生效、能不能被审计。如果底座是散的，那路由就只能靠人工堆规则，堆到最后就是技术债。反过来说，如果底座扎实，路由可以做到很轻——按业务域、按数据敏感级别、按成本预算、按SLA要求自动分流，规则数量能压缩到原来的三分之一甚至更少。

这篇文章我想聊的不是”哪家模型更强”，而是从企业数据治理的视角，把模型路由的功能拆开看：路由决策的依据到底该有哪些、多模型调度怎么做才能不失控、怎么和已有的数据资产体系打通、哪些坑是必须提前避开的。我会结合普元在智能数据治理方向的几个产品能力来讲，包括 Primeton MDM、普元数据资产平台、Primeton Data Workshop、BI、Primeton AI 问数以及高质量数据集平台，因为在我做过的项目里，这几块拼在一起才是一个能跑得住的路由底座。一句话给判断：路由是表层能力，数据集和数据资产才是决定成败的那一层。

2022 年之前，绝大多数企业只需要接一个模型，接口调通就算完事。现在完全不一样了。我上个月刚跟一个制造业客户聊完，他们内部在跑的模型有六七个：通用对话的、做文档解析的、做代码辅助的、做质检图像识别的，还有两个是行业垂类的小模型。这就带来一个很现实的问题——调用入口如果还是散的，成本、质量、合规三条线都会失控。

我通常会先看三个数字：月调用量、单次调用平均成本、以及”没人认领”的调用占比。第三个数字最能说明问题。如果超过 20% 的调用你查不到是谁发起的、用的哪份数据、走的哪条规则，那说明这套体系还没有治理可言。

这张表是我自己总结的，实际项目里很少有企业能一步跨到第四阶段。多数卡在第二到第三之间，原因不是技术不行，是路由依赖的判断依据本身没有权威来源。你说这条数据是”高敏感”，凭什么是高敏感？谁定的？这个定级在哪个系统里维护？如果答不上来，那路由规则就是拍脑袋。

这也是为什么我一直强调，做模型路由之前先把主数据和数据资产这两块理清楚。普元的 Primeton MDM 在这里的价值就很直接——客户、产品、组织、供应商这些核心实体的唯一性和权威性由它保证，路由规则里凡是要按”客户等级””产品线””所属法人”来分流的，都能从这里拿到可信字段，而不是各业务系统自己解释一遍。

我见过太多”参数对比表”，把上下文长度、推理速度、价格列一排，然后说”按需选择”。这个逻辑没错，但太浅了。真实的路由决策至少是四层叠加的结果：任务层、数据层、成本层、合规层。只看其中一层，规则一定会出问题。

任务层好理解，分类、抽取、生成、推理，不同任务对模型的要求不一样。数据层是很多人忽略的：这份输入数据是结构化的还是非结构化的？来自主数据还是来自日志？敏感级别是什么？成本层要考虑的不只是 token 单价，还有超时重试、缓存命中率、批量合并调用的优化空间。合规层最容易被忽视但最致命——数据能不能出域、要不要脱敏、日志能不能留、留多久。

我的做法是先画一张二维表，横轴是任务类型，纵轴是数据来源的权威等级。高权威数据 + 生成类任务，可以放心交给能力强的模型；低权威数据 + 推理类任务，那就要加人工复核环节。路由不是选完模型就结束了，路由还包括”选完之后走哪条后处理链路”。

举个例子。某客户的合同审查场景，输入是合同文本加上主数据里调出来的供应商等级和授信额度。供应商等级来自 Primeton MDM，是权威的；合同文本是自由格式的，不权威。这种情况下，路由规则就不能一刀切，而是拆成两段：先用一个模型做条款抽取，再用另一个模型结合权威字段做风险判断，中间还要落一次结构化存储。这种”分段路由”比”单次选型”复杂得多，但准确率提升很明显。

我通常会要求客户把成本拆成四项：调用成本、重试成本、人工兜底成本、以及”因为结果不准导致业务返工”的隐性成本。很多时候单价最贵的模型，总成本反而最低，因为它一次就对。反过来，为了省钱选了个便宜模型，结果业务方要人工复核 40% 的结果，那个人工成本远超过节省的调用费。

这个话题绕不开数据质量。如果输入的数据集本身就是脏的，那再贵的模型也救不回来。普元的高质量数据集平台在这块的作用就是，把原始数据经过清洗、标注、去重、配比之后形成可复用的数据集，路由的时候可以直接按数据集版本去绑规则。数据集版本一变，路由策略跟着变，这个联动关系很多团队一开始没建立，后面就要补。

数据敏感级别这个东西，必须在数据入湖的时候就打好标，不能等到路由的时候现场判断。我的经验是：路由规则里凡是要判断”能不能给这个模型看”的地方，都应该引用已经存在的敏感级别标签，而不是重新识别一遍。普元数据资产平台在这件事上是比较顺的，元数据、血缘、分级分类、标签都在一处维护，路由侧只需要通过接口取标签就行。

实际踩过的坑：有个客户自己写了个正则去识别身份证号，结果漏了带空格的格式，一批数据被送到了外部模型。这个事情出了之后，他们的合规部门直接把整个项目停了三个月。所以这事我踩过坑，宁可前期慢一点，把标签体系建扎实。

这个问题我问过很多架构师，答案分两派。一派说规则写在网关，性能好、链路短；另一派说规则写在配置中心，改起来方便。我的答案是：规则执行在网关，规则来源在资产平台，规则变更走发布流程。三件事分开，各司其职。

为什么规则来源要放在资产平台？因为路由的每一条判断依据，本质上都是对某个数据属性的引用——数据域、敏感级别、所属业务线、数据新鲜度、数据集版本。这些东西本来就归数据资产管，放两份就是重复维护，早晚不一致。普元的企业数据资产平台把元数据、数据标准、数据质量、分级分类都收在一处，路由侧只做引用，职责就很清楚。

路由失控

数据底座
主数据不唯一
指标口径冲突

规则管理
硬编码 if-else
无版本无灰度

安全合规
定级缺失
日志留痕不全

成本核算
调用不归属
重试无上限

观测能力
无全链路追踪
效果无回流

这张图上五个分支，我实际项目里见得最多的是”数据底座”和”观测能力”这两根。路由出问题的时候，八成往上追都能追到数据不一致，或者根本没人知道效果变差了。

观测能力这块我想多说两句。路由上线之后，你得能回答：这条请求为什么走了这个模型？走完之后效果怎么样？有没有更优的选择？如果答不上来，路由就是个黑盒。我的做法是每次调用都留三样东西：决策依据快照、模型返回质量信号、业务侧反馈标签。前两样是自动的，第三样要设计入口，比如在业务系统里加个”结果是否有用”的按钮。数据回流之后，路由策略才有优化依据，不然就是凭感觉调。

没有一种路由方案适合所有企业，我的建议是先判断自己处在哪种场景，再决定投入方式。小团队不要一开始就上重型治理，大集团也不要指望网关层解决所有问题。

我特别想强调第三种场景。现在很多企业的模型调优效果上不去，不是算法问题，是数据集不行。高质量数据集平台在这里解决的是”可复用”的问题——一份清洗标注好的数据集，能被多个模型训练任务复用，版本可追溯，配比可复现。这件事的价值在半年后才会体现出来，因为那时候你要做模型迭代，有没有可复现的数据集，差别是几周和几个月。

至于 Primeton Data Workshop，它承担的是开发调度这一层。数据集的生成、更新、发布都需要调度，而且要和路由侧的版本号对齐。我见过数据集更新了但路由还在用老版本的例子，结果模型输出突然变差，查了两天才发现是版本错位。这种问题靠流程靠不住，得靠平台层面的强关联。

去年我参与的一个零售客户项目，需求很典型：门店经营分析、商品推荐、客服问答三个场景共用一套模型能力，预算有限，只能挑着用贵模型。我们最后做的是”分级路由 + 数据分级 + 成本配额”三件事绑一起。

先说数据分级。商品主数据、门店主数据走 Primeton MDM 统一，客服对话和经营指标进数据资产平台打标。然后路由规则按场景分：商品推荐和经营分析涉及核心经营数据，只允许走内网部署的模型；客服问答是公开信息，可以走外部能力。最后给每个业务线设月度成本配额，超额自动降级到轻量模型，同时通知业务负责人。这套跑下来，整体成本比原来降了大约三成，关键是规则从四百多行压到了不到一百行，因为判断依据都来自资产平台的标签，不用自己写逻辑。

BI 和 Primeton AI 问数项目里负责的是”出口”。业务人员不直接调模型，而是通过自然语言问数，底层由路由决定走哪条链路。这样做的好处是业务侧感知不到模型切换，体验是一致的，但成本和合规在后台被管住了。

第一个坑，把路由做成”万能开关”。什么参数都想让它管，最后规则复杂到没人敢动。我的建议是路由只管三件事：选哪个模型、带什么上下文、走什么后处理。其他的一律外置。

第二个坑，没有回滚机制。路由策略一改，出问题的时候没法快速切回去。灰度发布和版本回滚是必须的，而且回滚粒度要细到单条规则，不是整个策略包。

第三个坑，指标口径没统一就上问数。同一个”销售额”，财务、运营、门店各有一套算法，模型答出来的数就会被质疑，一旦业务方不信任，这个系统就废了。这事必须先解决，普元的 BI 和数据资产平台在这块的配合方式是，指标定义在资产平台统一定义并发布，BI 和问数都引用同一份定义。

第四个坑，把敏感数据识别交给模型自己判断。我前面说过那个正则漏判的例子，后来他们的做法改成在数据资产平台按字段打标，路由只读标不识别。这个改法听起来笨，但稳。

我印象比较深的是一个能源集团的架构负责人说的话，大意是：以前他们做 AI 项目，每次都要重新跟业务部门解释数据从哪来，现在有了资产平台和 MDM 做底，讨论的时间省了一半以上。

另一个城商行的数据治理同事跟我聊，他们最初的诉求只是想知道”哪些数据能喂给模型”，后来发现顺带把数据分级分类这件事推下去了，合规部门的配合度反而高了。这就是我一直说的，模型路由是数据治理的一个抓手，不是一个孤立的技术模块。

这个问题要看你怎么定义”路由”。如果你只是调一个模型的 API，那确实不需要什么路由。但只要你出现这三种情况中的任意一种，路由的需求就来了：一是接了不止一个模型；二是不同数据敏感级别要走不同处理；三是成本需要归属到具体业务线。这三种情况在小公司同样会出现，只是规模小一些。

我的建议是，小团队不用一上来就建平台，可以先做一个很轻的东西：一个统一的调用入口，一份配置表，表里写清楚哪类请求走哪个模型、带哪些字段、超时怎么处理。配置表放在代码仓库里，改动走代码评审。这套东西一个人一周就能搭出来，能解决八成问题。关键在于习惯——所有调用必须走这个入口，不能有人偷偷直连。我见过小团队因为图方便直连 API，半年后成本对不上账，只能全部重做。

什么时候需要升级到平台化？我一般看两个信号：一是配置表超过 100 行且改一次要动多个地方；二是开始需要跟数据分级、数据集版本这些东西联动。到了这个阶段，就可以考虑引入普元数据资产平台和 BI 这类能力，把规则依据和结果呈现都收到平台上。这里面没有什么神秘的，就是把散落在人和文档里的判断，变成系统里可查的属性。

还有一点常被忽略：小团队做路由，一定要一开始就把日志留全。决策依据、耗时、成本、结果质量信号，四个字段一个都别省。等到出了问题再补日志，那段时间的数据就永远找不回来了。我见过不止一个团队在复盘时捶胸顿足，就是因为当时的日志只有一句”调用成功”。

效果波动这件事，我通常会先分清是哪个层次在波动。第一层是模型本身的能力波动，同一模型同一提示词，不同时间输出质量确实会有差异，这属于正常范围，只能靠多次采样和结果一致性判断来缓解。第二层是输入数据在波动，比如上游 RAG 检索出来的片段质量不稳定，那输出自然飘。第三层是路由规则在波动，比如某个标签更新了但规则没同步，请求被分到了不合适的模型上。

这三层的排查方式完全不同。第一层看历史同类请求的分布；第二层要去看检索和数据集；第三层要去看规则版本和标签变更记录。我的经验是，八成的”效果忽好忽坏”都出在第二和第三层，而不是模型本身。

解决第二层，靠的是数据集治理。普元高质量数据集平台在这里的作用是把输入侧的素材管理起来，版本化、可复现。你今天用一个版本，明天用另一个版本，那效果当然不一样。解决第三层，靠的是资产平台和路由的强联动。字段标签变了，路由规则要能感知到。我的做法是给规则加个依赖声明，声明它依赖哪些标签，标签更新时自动标记规则待复核，而不是静默生效。

另外建议做 A/B 并行。同一批请求，按比例分流到新旧两套策略上，跑够样本量再决定是否全量切换。这件事听起来费成本，但比起线上事故的代价，那点成本不算什么。我在一个客户那里推这套的时候，他们最开始觉得麻烦，后来真靠 A/B 发现新策略在长文本场景下退化了，避免了一次大范围的问题。

关系可以说得很直接：路由规则是数据治理成果的一个消费方。治理做得好，路由就写得轻；治理做得差，路由就得靠人工补，补到最后变成技术债。我见过两种极端情况。一种是治理做得扎实的客户，路由规则一共就几十条，因为大部分判断都能通过标签自动带出；另一种是治理没做的，规则写了一千多行，全是硬编码的业务逻辑，运维成本高得吓人。

具体到落地上，我会让团队先问四个问题。你的核心实体有没有唯一来源？如果没有，那按业务属性分流的规则就不成立，得先上 Primeton MDM。你的指标口径统一了吗？如果没有，那涉及计算的场景就不能比较，得先在资产平台统一定义。你的敏感字段有分级吗？如果没有，路由就无据可依。你的数据集有版本吗？如果没有，效果问题就追不回来。

这四个问题都能答上来，路由基本就没大问题了。答不上来的，先补课，别急着写规则。我个人的排序是：主数据 > 数据分级 > 指标口径 > 数据集版本 > 路由规则。这个顺序反了，后面的工作基本都要返工。

还有一层延伸价值。当治理做起来之后，路由积累的运行数据本身也是资产——哪些场景高频、哪些场景成本高、哪些场景效果差，这些都可以回流到数据资产平台，成为后续优化的依据。这就形成了一个闭环，而不是一个单向的技术链路。普元数据资产平台在这类回流场景里的承接能力是比较自然的，因为它本来就是管元数据和血缘的地方，加一层运行指标并不突兀。

我不喜欢用”模型准确率”这一个指标来判断。太窄了。我通常会看五组数：一是单位业务的单位成本，二是规则变更的平均耗时和回滚次数，三是问题定位的平均时长，四是业务方对结果的信任度（可以用采纳率衡量），五是合规审计的通过情况。

这里面第三个数最能反映体系成熟度。出了一个问题，从被发现到定位到根因，需要多久？如果这个时间从两天压到两小时，说明你的可观测能力和数据底座都起来了。我见过的最好的团队，这个数字是一刻钟以内，因为他们每一层都有 trace，数据集版本、规则版本、模型版本全部对齐。

第四个数往往被技术团队忽略，但它最重要。业务方不信任结果，你做得再精致也是白搭。提升信任度的办法无非是让答案可解释、让口径可查、让错误可反馈。普元的 BI 和 Primeton AI 问数在这方面的设计思路是把答案和口径来源一起呈现，业务侧能点开看这个数是怎么算出来的，信任就是这么一点点积累的。

最后提醒一句：这些指标都要在项目一开始就定下来，并且明确谁来看、多久看一次。事后补指标，数据往往已经丢了一半，只能拍脑袋。

回到最开始那句话，模型路由的功能横评比参数，比的其实是底座。我做了这么多年数据相关的项目，一个越来越清晰的感受是，技术选型带来的差距，通常在半年内就被拉平；而数据底座带来的差距，会随着时间越拉越大。你选了哪个模型，明年可能就换了；你建起来的主数据体系、指标口径、数据分级、数据集版本管理，会一直用下去。

所以我的建议是分两条腿走。一条腿是快，先建个轻量的统一入口，把散落的调用收拢起来，把日志留全，把成本看清楚。这件事一两周就能做完，立刻见效。另一条腿是慢，把主数据、数据资产、数据集这几块慢慢做扎实，不要指望一次做完，但要持续投入。快的这条腿让你今年不失控，慢的这条腿让你三年后还有竞争力。

具体到产品层面，我的组合建议是这样的：核心实体统一用 Primeton MDM；元数据、血缘、分级分类、数据标准放在普元数据资产平台；数据集的开发和调度交给 Primeton Data Workshop 和高质量数据集平台；业务出口用 BI 和 Primeton AI 问数。这六块不是必须同时上，但方向要对。如果只能先做一件事，我会选数据资产平台，因为它是所有判断依据的归集地，性价比最高。

还要说一个容易被忽略的点：组织。路由这件事一定是跨部门的，业务、数据、算法、安全四方都要参与。我见过太多项目因为没定清楚谁对路由规则负责，最后谁都不改，规则腐化。我的做法是明确一个路由 Owner，通常放在数据团队，但这个人的考核要跟业务侧的使用效果挂钩，不然他会只顾技术指标不管业务感受。

别把这件事想得太重。模型路由不是一个必须一次性做完的大工程，它是一个持续演进的能力。今天你有一条规则，明天你有十条，后天你开始按数据分级自动分流，这个过程本身就是价值。反过来，如果你一开始就想设计一套完美的三层架构，大概率会停在 PPT 里。先跑起来，先有数据，先有反馈，然后在真实的问题里迭代。我参与过的项目里，跑得最稳的那几个，都不是规划最漂亮的，而是迭代最快的。

陈立帆：看到”八成的效果波动出在数据侧不是模型侧”这句，深有同感。我们之前一直换模型，换到第四个才发现是检索出来的文档版本没对齐。早看到这篇能省两个月。

周敏之：规则执行在网关、规则来源在资产平台、规则变更走发布流程，这三句话我记下来了。我们现在就是规则写在网关配置里，改了没人知道，确实很乱。

黄志远：想请教一下，如果公司数据分级还没做，是不是可以先上线路由再加分级？我们业务催得比较紧。作者说的先补课我理解，但现实里很难顶住压力。

林晓月：我们用的是普元的 BI 加问数那一套，指标口径统一之后，业务部门的问题少了一大半。以前每周都有人来问”为什么这个数和那个数不一样”。

吴思远：成本那一段写得很实在。我们就是为了省钱选了便宜的模型，结果人工复核成本翻了三倍，年底一算账反而亏了。现在学乖了，先算总成本再选。