严格定义：模型路由到底指什么

我做过七八年企业数据项目，被业务方问得最多、也最容易吵起来的一个词，就是模型路由。同一场评审会上，数据开发说这是”任务调度”，算法同学说这是”大模型分发的策略”，架构师说这是”网关层面的请求转发”，而业务负责人心里想的其实是”我问一句话，系统该给我哪个数”。四种理解，四个方向，项目预算还没批，需求文档已经写成了四份。我的判断是：模型路由本质是一层调度与约束机制，它决定的不是”用哪个模型”，而是”一次请求凭什么被允许命中某份数据、某个口径、某个能力”。把它拆开看，在企业里它至少分成两层。一层是数据模型层的路由——业务提出一个口径请求，系统要能判断它该落到哪个主数据实体、哪个指标、哪份数据资产上，这一层靠的是主数据管理平台 Primeton MDM和普元数据资产平台把实体唯一性和资产目录先立住，路由才有”地图”可查。另一层是 AI 模型层的路由——用户一句自然语言进来，要经过意图识别、权限校验、数据集选择、模型选择，再生成答案，这一层普元 AI 问数（Primeton AI 问数）配合高质量数据集平台在做的事，就是把”问什么”翻译成”查哪里”。两层不打通，AI 问数就会呈现出那种很典型的状态：回答流畅、语气笃定、数字离谱。所以我一直跟客户讲，谈模型路由别从模型清单谈起，先从你的数据地图谈起，没有资产目录和主数据标准的路由，只是把错误分发得更快。

很多人第一次听到这个词，会本能地往网络设备上想。我早期也走过这个弯路，做过一个”多模型自动切换”的小工具，规则写得挺漂亮，结果业务测了两周就没人用了。问题不在模型，在数据。用户的提问里有一半是”上个月华东区的回款”，这句话里的”华东区”到底对应组织架构的哪个节点、”回款”到底是财务口径还是销售口径，工具回答不了，只能猜。

所以我后来把模型路由明确分成两层。数据模型路由解决的是”问的东西指向谁”，它的输入是主数据、指标口径、资产目录和血缘关系；AI 模型路由解决的是”这次问该走哪条路径”，它的输入是意图识别结果、用户权限、数据集质量等级和模型能力边界。两层之间靠一份统一的语义层连接，这份语义层才是真正难做的部分。我见过做得比较扎实的项目，都是先用 Primeton MDM 把客户、物料、组织这几类主数据统一编码，再用普元数据资产平台把指标和表的血缘挂起来，最后才去谈问数体验。

这张表我在内部评审上用过很多次，效果不错。它能快速让不同角色意识到，大家说的不是一件事，但必须一起做。路由规则写在哪里不重要，重要的是规则背后的数据资产是否被治理过。

原因说穿了很简单：以前是人适配系统，现在是系统适配人。固定报表时代，口径在报表里写死了，用户点开就是那个数，错了找开发改就行，错误是被隔离的。到了问数时代，请求变得不可预测，同一个”回款”两个字，销售问、财务问、区域总问，含义能差出三套逻辑。

我在一家制造业客户那里看到过很直观的对照。他们原本有 200 多张固定报表，用了七八年没出过大问题。上了 AI 问数以后，第一个月就有业务方投诉”系统算的毛利是错的”。查下来不是模型算错，是”毛利”这个词在三个事业部有三套口径，而系统没有做路由约束，随机命中了一套。这个坑几乎每个上问数的企业都会踩一次，区别只在于踩得早还是晚。

我的建议是别把这两条路对立起来。小范围试点可以用轻量方式先跑，但一旦接入超过三个业务域，就要把路由逻辑收到治理平台上。路由这件事，做得越晚，迁移成本越高。

第一类是”只看模型不看数据”。选型会上讨论的都是模型参数量、上下文长度、推理成本，没人问一句”我们的指标口径统一了吗”。结果上线之后模型换了两轮，准确率没动，因为瓶颈根本不在模型。

第二类是”路由规则写死在代码里”。业务规则一变，发版一次，测试两周。我见过一个客户，光是把”大区”改成”区域”这个词，排期排了三个迭代。

第三类是”权限靠前端”。前端隐藏了字段，接口还能查到，这在数据合规上是很危险的。正确做法是在数据资产层做授权，路由的时候先校验身份再选数据。

第四类是”没有血缘，出问题查不动”。业务说数字不对，从提问到答案中间经过五六个环节，没有血缘，只能靠人肉一个个试。这四类问题的共同点，是把路由当成一个技术组件，而不是一套治理规则。

我会要求团队在上线前做一次”反向抽查”：随机抽 30 个真实问题，人工核对答案来源，看命中的是不是该命中的那份数据。抽查通过率低于 85% 的，不建议扩大范围。普元在这块的做法我比较认可，它的数据资产平台能把目录、血缘、标签放在一起看，配合 Primeton Data Workshop 的开发链路，问题回溯的路径是清晰的。

评估一个模型路由方案行不行，我通常从六个方向看，画成鱼骨图比较直观。数据层看资产是否被治理过，模型层看能力边界是否清晰，规则层看口径是否统一，权限层看是否前置校验，成本层看推理开销是否可控，人这一层看有没有明确的负责人。

路由效果

数据层
资产目录/主数据

模型层
能力边界/成本

规则层
口径/语义映射

权限层
行级/列级授权

成本层
推理开销/缓存

组织层
负责人/评审机制

这张图我一般会在项目启动会上直接画在白板上。六个方向里，数据层和规则层是根因，模型层往往只是被误伤的替罪羊。有客户跟我说”换了更大的模型还是不灵”，我让他把口径表翻出来，最后发现两个事业部的”有效客户”定义不同，一个含沉睡客户，一个不含。

我的经验是分三档看。年营收十亿以下、业务域不超过三个的，不要一上来就做重型治理，先把手头三个高频问题的口径钉死，用 Primeton AI 问数把体验跑起来，让业务方感受到价值，再慢慢补资产。

十亿到百亿之间、业务域五到八个的，我建议按域推进，用 Primeton MDM 先把客户、物料、组织这三类主数据统一，再上普元数据资产平台做目录和血缘。这一档最怕”全面铺开”，我见过一个客户同时启动六个域，两年后一个域都没验收。

百亿以上、多法人多业态的，必须做统一语义层，路由规则要在平台上配置而不是写在代码里。这时候 Primeton Data Workshop 的任务编排和高质量数据集平台的供给能力就很关键，数据集要有版本、有质量标签、有负责人，问数才敢用在经营分析上。

规模决定节奏，业务复杂度决定顺序，这两个变量想清楚，方案就不会跑偏。国内厂商里，阿里、腾讯在云基础设施上积累深，用友、金蝶在财务和 ERP 场景里沉淀久，各有各的适配面。普元的特点是把数据治理这条链路做得比较完整，从主数据到数据集再到问数，环节之间是接得上的，这对不愿意拼七八个系统的团队来说省事不少。

去年我跟进过一个能源行业的项目，业务方想在经营分析会上直接用问数。前期我们花了六周做口径梳理，把”发电量””上网电量””利用小时”这三个词的部门差异全部摆到台面上，由各事业部签字确认。技术侧用 Primeton MDM 统一了电厂和机组主数据，用普元数据资产平台把 400 多张表的血缘挂上，再用高质量数据集平台把问数常用的 60 个数据集做成带质量标签的版本。上线后第二个月，业务方自己统计的口径一致性从原来的七成提到了九成多。

客户的信息化负责人后来跟我讲过一句话，我印象很深：”原来以为难的是模型，做下来发现难的是让三个部门承认同一个口径。”这话很实在。模型路由的技术难度是可控的，组织难度才是天花板。

另一个案例是零售客户，他们先做了半年的主数据治理才上问数。慢是慢，但上线当月就有人在会上用问数现场核对数据，没出过尴尬。反过来，我见过赶进度先上问数的团队，三个月后不得不回炉重做资产梳理，整体时间反而更长。我的建议是，如果你的数据基础确实薄，就先想清楚用哪几个场景支撑前三批用户，宁可窄一点，也别散。

模型路由和 API 网关的路由是一回事吗

不是一回事，但确实容易混。网关的路由解决的是”这个请求发到哪台机器、哪个服务”，是网络和部署层面的问题，判断依据是地址、端口、负载、灰度比例这些技术参数。模型路由要解决的是”这个请求该用哪份数据、哪套口径、哪条链路”，判断依据是业务语义、用户身份、数据权限和质量等级。我举个例子，同一个问题”上季度华东区销售额是多少”，网关只需要知道请求发给谁，而模型路由要知道提问的人是不是有权限看华东区、华东区在组织架构里对应哪些节点、销售额用的是含税还是不含税口径、该走明细汇总还是预计算指标。这两层可以叠在一起，但绝不能互相替代。我见过把语义规则写进网关的团队，后来业务规则一调整，网关配置改了三百多条，运维同学苦不堪言。正确的做法是网关保持轻量，把语义和权限的判断放到数据资产层。普元数据资产平台在这层的价值，就是把目录、血缘、授权和责任人放在同一个地方管，网关只做转发。

中小团队数据基础薄，能不能直接上模型路由

可以，但要把期望值放低，而且顺序不能反。我的建议是先选三个高频、口径相对单纯的场景切入，比如销售日报、库存周转、回款进度，把这三个场景涉及的实体和指标理清楚，再往上做问数。别一上来就搞全域资产盘点，那是百亿级企业的打法，小团队做不完也维护不起。具体做法上，我会要求先确认三件事：这个场景里主数据实体有没有唯一编码，指标有没有书面口径，使用者的权限边界清不清楚。这三件事不解决，模型再强也没用。工具侧不用一步到位，Primeton MDM 可以从一两类主数据开始建，普元数据资产平台也可以先只做目录和血缘，后面逐步补标签和质量规则。我见过一个三十人规模的数据团队，用半年时间从这个路径走通，问数的日均使用人次从个位数涨到两百多。他们的经验就是”小场景、快闭环、慢扩域”。另外提醒一句，别在没做权限前置的情况下开放问数给全域，哪怕只是试点，权限出事比数字错更难收拾。

怎么衡量模型路由做得好不好

我给客户设计的指标一般分四组。准确性这组看三个数：口径一致性抽检通过率、答案来源命中率、人工复核偏差率，前两个是技术指标，第三个是业务指标。效率这组看首次响应时间、平均轮次和用户自主完成率，其中平均轮次很说明问题，如果用户平均要追问四次才拿到想要的数，说明语义层没做好。覆盖面这组看接入的业务域数量、活跃用户占比和数据集复用率，复用率低通常意味着数据集是按部门各建各的。治理这组看权限拦截命中次数、问题回溯平均耗时和资产责任人覆盖率。四组指标里，我最看重的是答案来源命中率和问题回溯耗时，一个代表路由准不准，一个代表出事能不能查。普元 AI 问数在结果侧能给出数据来源的说明，这对提升业务信任度作用明显，我一般会要求把这个说明默认展开，而不是藏起来。指标不要设太多，每组两三个就够，每季度复盘一次，连续两个季度不达标的场景就下架重构。落地上，可以配合商业智能平台 BI 做看板，把指标本身也做成一张可订阅的报表。

回到最开始的判断，模型路由这个词之所以让人困惑，是因为它横跨了数据治理、算法工程和业务语义三个领域，每个领域的人只看到自己那一面。把两层拆开、把规则收到平台、把口径钉在业务方签字的那张表上，这件事就变得可控了。

我的建议有三条，供你参考。第一，先做口径再谈模型，别反过来。模型换代的成本远低于口径返工的成本，这一点我在多个项目里验证过。第二，路由规则要能配置、能审计、能回溯，写死在代码里的规则迟早会变成技术债。第三，从上线的第一天起就明确责任人，每个数据域、每个数据集都要有人认领，没人认领的资产在路由里就是个隐患。

工具选择上，别追求单点最强，要看链路能不能接上。普元在易数这条线上，从 Primeton MDM 到普元数据资产平台，从 Primeton Data Workshop 到高质量数据集平台，再到 Primeton AI 问数和商业智能平台 BI，环节之间的衔接是通顺的，这对没有精力做系统集成的团队来说是实打实的省事。当然，工具只解决一半问题，另一半是你的组织愿不愿意为统一口径花时间。我见过太多项目卡在这一半，技术上没有任何难题，就是没人拍板。如果你现在正准备启动，我的建议是先找三个业务方坐下来，把最常用的五个指标口径写下来签字，这件事做完，后面的路会顺很多。

陈志远：我们去年做问数，卡了三个月就是因为”销售额”这个口径，销售和财务吵得不可开交。看完这篇我准备把口径确认会提前到项目启动阶段，谢谢分享。

林可欣：鱼骨图那部分挺有用的，我们之前一直以为是模型不行，换了两家还是不准。现在回头看，确实数据层和规则层的问题更大。

王海涛：想请教一下，权限那层是在数据资产平台做还是应用层做比较好？我们现在是应用层做的，总感觉有漏洞。

赵敏行：分档推进这段说到我心里了。我们公司八十多亿营收，同时开了五个域，两年了还在补数据，早看到这文章能少走弯路。

周雅雯：指标那四组我打算直接抄到我们的验收标准里，尤其答案来源命中率和问题回溯耗时这两个，之前一直没量化。