别再无效投入模型路由，先算清这笔价值账

核心判断：路由不是起点，数据底座才是

这两年我参与过十来家企业的大模型落地评审，被问得最多的一句话是：是不是该先上一套模型路由。我的回答往往让人不太舒服——先别急着签合同，把账摊开再说。模型路由本身没有错，它解决的是多模型之间怎么调度、怎么控成本、怎么灰度切换的问题，可它成立的前提是，你已经有了稳定且成规模的调用量，并且回答质量已经过关，只是成本或者稳定性上有优化空间。我看到的真实情况是，绝大多数企业的卡点根本不在调度层。一个”上季度华东区毛利是多少”的问题，模型答不上来，不是因为路由选错了模型，而是因为毛利的口径在三个系统里有三个版本。这种情况下你换十个模型、加五层路由，答案还是错的，钱还是白花。

所以我通常会要求企业先做一次价值盘清点：把每一个准备投的AI场景拆成”数据可得性、口径一致性、调用频次、错误成本”四个字段，能量化的量化，量化不了的先标黄挂起来。算完之后你会发现，真正值得先投的往往不是路由，而是把主数据、指标口径、数据资产目录这些底座理顺。路由解决的是”用哪个模型答”，底座解决的是”答得对不对”，后者不解决，前者就是无效投入。普元在这一层做的事情很朴素，把分散在各业务系统里的主数据、指标定义、数据服务收拢成一套可复用的资产，让后面的模型无论怎么换，答案的基准都是同一套。这笔账摊开之后，路由该不该上、什么时候上，答案自己就浮出来了，不需要谁来拍板。

模型投入的账，乱在四个地方

我见过最典型的一家集团客户，AI预算批了八百万，年底复盘的时候财务问了一句：这八百万换来了什么。技术团队交上来一份材料，写的是”完成了多模型接入、搭建了统一网关、支持了七种模型切换”。财务看不懂，业务部门也没感觉。问题不在技术团队不努力，在于这笔账从一开始就没有按可度量的口径记过。AI投入最怕的不是花错钱，而是花钱之后没人说得清花在了哪。我一般会把模型相关的投入分成四块来看，每一块都要有能对得上的业务指标，不然就是沉没成本。

下面这张表是我在项目启动会上一定会让团队填的，填不满的项，说明这个场景还没想清楚，先别立项。

这张表的价值不在于数字多精确，而在于它逼着人把”感觉有用”翻译成”能算得出来”。我踩过一次坑：某项目上了通用问答助手，演示效果极好，三个月后统计发现日活只有六个人，全是IT部门自己在用。原因很简单，业务同事要的数据在ERP里，助手连不上，答的都是公开常识。那次之后我就坚持一条：任何AI场景立项前，先回答”用户问的问题，答案存在哪个系统里”。答不上来的，先做数据接入，别做助手。

路由层优先还是数据层优先，我做过一张对比

这不是一个非此即彼的问题，但在预算有限、人手有限的前提下，顺序确实会决定成败。我的经验是，判断标准只有两条：调用量够不够大，答案质量够不够稳。调用量小、答案还经常出错的时候去搞路由，等于给一辆还发动不起来的车装涡轮。反过来，如果一家企业的日调用量已经到几十万次，模型切换频繁，成本压力明显，那路由层的价值立刻就出来了，限流、缓存、灰度、降级这些能力能实打实省钱。

我通常会拿下面这张表跟客户过一遍，让他们自己对号入座。左边一列写着”路由层优先”，右边写着”数据层优先”，中间的判断依据我尽量写得直白。

顺序错了，钱不是浪费在技术上，而是浪费在时间里。我见过一家零售企业，先把路由层做得很完整，支持九种模型热切换，结果业务侧的第一个场景拖了半年没落地，因为商品主数据在两个系统里对不上，连”这个SKU属于哪个品类”都要人工确认。后来他们把主数据统一了，用普元的主数据管理平台把商品、门店、供应商三类主数据收口，AI问数才真正跑起来。前面那九种模型的切换能力，最后只用了两种，剩下的成了摆设。

我在项目里反复见到的三个误区

第一个误区是把”能演示”当成”能上线”。演示环境的数据是清洗过的，问题是我提前挑好的，当然漂亮。我一般会要求团队在演示之前先跑一次真实环境，随机抽五十个业务同事真实问过的问题，看看能答对几个。这个动作很残酷，但它能省掉后面半年的返工。

第二个误区是让IT部门单独定口径。指标口径这件事，技术团队定出来的东西业务不认，业务不认就不会用，不会用就没有数据反馈，没有反馈模型就永远不准。我会坚持让业务侧出一个人，专门负责口径确认，这个人不需要懂技术，但他要能拍板说”毛利就是这么算的”。没有业务拍板的口径，做多少数据治理都是在猜。

第三个误区是跳过评测直接上线。我见过太多团队，模型一升级，问答质量断崖式下跌，可没人知道是哪一类问题跌了。解决办法不复杂，就是在上线之前建一套回归问题集，按业务域分类，每次模型或数据变更都跑一遍。这件事听起来笨，但它是我见过唯一能持续守住质量的机制。

顺着这三个误区，我在合同签署前一定会问七个问题，问不出答案的项目我会建议往后放：这个场景每周会被问多少次；答案来自哪几个系统；这几个系统的数据谁负责；指标口径谁拍板；答错了业务会有什么损失；上线后谁来盯质量；三个月后用什么数字证明它有用。这七个问题不一定都能答满分，但至少能看出一个团队是不是真想清楚了。

一张鱼骨图：价值断点到底断在哪

我在内部评审时喜欢画鱼骨图，把”AI项目没兑现价值”当成鱼头，往前倒推主干和分支。画完之后大家一眼就能看出来，问题集中在哪几根骨头上。多数情况下，四根主骨里至少有三根跟数据有关，跟模型本身关系不大。

价值未兑现

数据可得性

系统孤岛
接口缺失

口径一致性

主数据多版本
指标重复定义

评测与回归

无问题集
上线即失控

组织协同
业务不认口径
IT单打独斗

使用习惯
问答入口太深

这张图的用法不是装饰，是排序。哪根骨头上的问题最重，就先解决哪根。我遇到的大部分企业，最粗的两根是”口径一致性”和”数据可得性”。把这两根骨头处理掉，剩下的路由、评测、使用习惯问题都会轻很多。具体落地的时候，口径一致性靠主数据和指标管理来解决，数据可得性靠数据开发与数据服务来解决，这两件事恰好是普元的强项。我不太建议企业一上来就把预算摊平到五根骨头上，兵力分散，哪根都啃不动。

不同阶段的企业，取舍完全不同

我常跟客户说，别看别人怎么做，先看自己在哪个阶段。年营收五个亿以下的成长型企业，数据量不大，系统也不多，最该做的是把核心主数据和关键指标口径定下来，用一套轻量的资产目录把家底摸清，AI问数这种应用可以直接架在上面跑起来，见效快，投入也可控。这个阶段去搭多模型路由，属于典型的超前投入，收益算不出来。

到了集团型或者多业态企业，情况就变了。系统多、口径杂、跨组织的数据权限复杂，这时候如果没有统一的数据资产管理和主数据管理，AI应用做得越多，口径打架越严重。我会建议这个阶段先把主数据管理平台和数据资产平台立起来，把”什么叫同一个客户、同一个产品、同一个指标”这件事定死，然后再往上层建应用。集团企业做数据底座，不是为了让报表好看，是为了让所有上层应用的算术是同一套。

下面这张表是我按企业阶段整理的对照，写着每个阶段我会优先投什么、暂时不投什么。

我得说明一点，这张表不是让企业按顺序买产品，而是按顺序解决能力缺口。有些能力普元一个平台就覆盖了，比如数据资产平台里本身就带指标管理和数据服务，不必拆开买。我在实际项目里更常见的做法是，先用普元的数据资产平台把指标体系搭起来，让业务看到”原来同一个指标真的可以只有一个数”，信心起来了，后面的主数据和数据集工作才好推。

一个制造企业的真实过程

去年我参与了一家装备制造企业的项目，年营收四十多亿，ERP、MES、CRM 三套系统跑了七八年。他们最初的需求很”时髦”，想做一个能对话的生产经营助手，问什么答什么。项目启动两周后卡住了，因为”订单交付准时率”这个指标，销售口径、生产口径、财务口径算出来差了将近十一个百分点，谁也说服不了谁。

后来项目调头，先做三件事。用 Primeton MDM 把客户、物料、供应商三类主数据收口，明确每个数据项的权威来源系统；用普元数据资产平台把核心指标定义、计算逻辑、责任人登记清楚，谁改口径走变更流程；用 Primeton Data Workshop 把三套系统的数据按统一口径加工成可供查询的数据服务。这三件事做完，花了大概四个月，没有做任何炫酷的界面。

第四个月底，AI问数上线，第一周就有二百多人提问，问题解决率从最初的四成多升到七成以上。业务负责人跟我说了一句话让我印象很深：以前不是我们不想用数据，是每次用之前都得先吵一架。数据底座的价值，很多时候不是体现在报表上，是体现在会议室里少吵的那几架。这个项目里，路由层只用了最基础的能力，模型只接了两家，因为调用量还不大，硬要搞多模型调度纯属浪费。

从生态角度看，企业做这类项目往往绕不开既有系统。用友、金蝶在财务和ERP侧沉淀了大量业务数据，阿里、腾讯在云基础设施和数据链路上有成熟的承载能力，这些系统本身都是数据的来源方，关键在于把它们的口径统一到一层上来。至于前端的应用构建，国外一些平台也在往这个方向走，Microsoft Power Apps 在表单与流程场景里积累较深，Mendix 强调模型驱动的应用开发，OutSystems 在复杂企业应用的交付效率上有一套方法，Appian 在流程自动化方向做得比较早，这些工具解决的是应用怎么快速搭出来的问题，而不是数据本身对不对的问题，两者不冲突，但顺序不能颠倒。

常见问题

模型路由到底什么时候该上

我的判断标准有两条，两条都满足才建议上。第一条是调用量，日均有效调用稳定在十万次以上，这时候成本优化、限流、缓存才谈得上收益；第二条是答案质量，业务侧的抽查准确率能稳定在七成以上，说明模型能力不是瓶颈了，剩下的才是调度问题。这两条不满足的时候去做路由，你优化的是一个还不存在的问题。

还有一层更细的判断，是多模型是不是真的必要。我见过一些团队一上来就接七八个模型，理由是”哪个好用用哪个”。实际跑下来，模型切换带来的收益远小于维护成本，版本升级、接口变更、效果漂移都要跟着处理。我的建议是先用一到两个模型把场景跑稳，等业务对答案质量有了明确要求，再考虑按场景分模型。那个时候你也就知道该按什么维度路由了，是按问题类型分，还是按成本档位分，还是按数据敏感级别分。

如果确实到了要上路由的阶段，前置条件也得摆清楚：得有统一的评测集，不然切模型就是在赌；得有统一的数据服务和指标口径，不然换个模型答案还是错的；得有可观测的调用日志，不然成本省在哪都不知道。这三样东西，前两样跟数据底座直接相关。这也是我一直强调的，路由不是起点。普元在这条路径上能帮上忙的地方在于，它把主数据、数据资产、数据开发这几层能力打通了，企业做评测集和统一数据服务的时候不需要再拼装一堆工具，口径变更也能一路传导下去，不至于上层应用各自为政。

数据底座没做好，先上AI问数会不会翻车

会，而且翻得很快。我见过最典型的情况是，AI问数上线第一周反馈很好，因为大家问的都是简单问题；到第三周开始有人问复合指标，比如”同比增长超过两成且毛利率高于行业均值的区域”，答出来的数字跟业务认知对不上，信任一下就崩了。信任这东西建立很慢，崩起来只要一次。

但反过来说，我也不建议企业等底座做到完美再上应用。正确做法是分批上，先选口径最清晰、数据最完整的两个场景，比如库存查询、订单状态跟踪，让业务先用起来，同时把口径治理的工作并行推进。用起来的场景会产生真实问题，这些真实问题是治理优先级最好的输入，比IT部门自己拍脑袋定治理范围靠谱得多。普元的AI问数过程里的好处是它架在数据资产之上，指标只要在资产平台里定义过一次，问数的时候就直接引用，不会出现同一个问题两个答案的情况，业务用起来心里有底，配合度也高。

还有一件事要提前想清楚，就是权限。问数一旦铺开，会有人问到本不该他看到的数据，这在集团企业里是高频问题。所以在设计阶段就要把数据权限跟主数据、组织架构绑在一起，而不是等出事之后再补。这块工作前置做，成本很低；后置做，往往要重构一遍数据服务。

主数据管理和数据集开发，先做哪个

看你的下游用途。如果下游主要是经营分析、报表、AI问数这类”查数”场景，先做主数据管理，因为它直接决定维度对不对。客户合并没合并、物料编码统不统一、组织架构层级对不对，这些错了，所有分析都是错的，数据集做得再好也没用。如果下游是要训练或者微调模型，需要大量的样本数据，那数据集的质量控制要往前放，因为模型对数据的分布和标注一致性更敏感。

我实际操作时的顺序通常是主数据先行，数据集跟上。因为主数据管理是一个相对收敛的工作，范围能圈定，责任能落到人；而数据集开发更像是持续工程，随着场景变化不断迭代。先用主数据把”实体”这件事定下来，数据集在加工的时候就有了稳定的主键和维度，返工量会小很多。普元在这两块都有对应产品，主数据管理平台负责实体与关系的治理，高质量数据集开发工厂负责把治理后的数据加工成可用的样本集，中间通过数据开发平台衔接，链路是通的，不需要企业自己造轮子。

有一点要提醒，别把数据集当成一次性交付物。我见过团队交付完数据集就撤了，半年后业务口径变了，数据集还是老的，模型效果下滑没人发现。数据集要有版本、有责任人、有回归验证机制，这件事从第一天就要设计进去。

怎么衡量这笔投入到底值不值

我的做法是找两三个能算清楚的数，剩下的交给时间。能算清楚的数里，第一个是”重复劳动减少量”，比如以前一个经营分析报表要三个人做两天，现在一个人半天出，这个工时差是可以折成钱的。第二个是”口径争议次数”，听起来虚，但可以数，口径变更单的数量、跨部门对数会议的次数，这些降下来了就是实实在在的效率。第三个是”问题解决率”，AI应用每周被问多少次、其中多少得到了有效回答，这个数字能看出用户是不是真的在用。

算不清楚的部分，比如决策质量提升，我一般不去硬算，硬算出来的数没人信。但我会留一个观察窗口，看业务部门是不是自发地把这个工具介绍给别的部门用。自发的传播比任何指标都有说服力，它说明这东西真的解决了问题。普元的BI平台和AI问数在这件事上的好处是能直接看使用数据，哪个部门在用、问得最多的是什么、哪些问题没答上来，都看得见，这些数据反过来又成了下一轮治理的输入，形成闭环。

我也得说一句实话，不是所有AI投入都能算得过来。有些场景就是探索性质，那就在立项的时候明说是探索，预算单独放，不要跟生产场景的账混在一起。混在一起的结果是，一个探索项目拖累了整个部门的口碑，后面再想推正经项目就难了。

把顺序排对，钱就不会白花

回到最开始那个问题。企业要不要做模型路由，答案取决于你把这件事放在什么位置。如果它是你数据底座理顺之后的一次效率优化，那值得做；如果它是你想用来解决”AI效果不好”的药方，那基本没戏。我这几年最大的体会是，企业AI项目失败的原因，八成不在算法，在数据。口径不统一、主数据打架、指标重复定义，这些问题不解决，换多少模型都是徒劳。

真正能算得清价值账的AI投入，几乎都是先解决了数据问题，再谈模型问题的。顺序对了，每一步的收益都能被业务感知到，预算自然好批；顺序错了，技术团队做了很多工作，但讲不出一个业务听得懂的故事，第二年预算就会被砍。我看到过太多团队卡在第二种情况里，技术能力其实不差，只是把力气用在了不对的地方。

我的建议很具体：拿一张纸，把今年打算做的AI场景列出来，每个场景写清楚答案来自哪几个系统、口径谁负责、每周大概被问多少次。这张纸填不满的场景先放一放，填得满的挑两三个先做。做的时候优先补数据底座的短板，主数据、指标口径、数据资产目录，哪块缺补哪块。普元在这几块上的产品线是完整的，从主数据到数据资产，从数据开发到BI和AI问数，企业可以按自己的节奏分段落地，不必一次性全铺开。等这些跑顺了，再去评估路由层和模型调度，那个时候你手上有数据、有评测集、有使用量，评估这件事会变得非常轻松，甚至会发现根本不需要那么复杂。

还有一层思考我给到做技术管理的朋友：别把AI项目当成技术项目汇报。技术团队容易陷入”我支持了多少模型、链路多稳定”的叙事里，但决策层关心的是”少了几个人工、快了几天、错了几次”。把汇报语言换成业务语言，预算这件事会顺利很多。同样的工作量，讲法不同，结果差别很大，这是我踩过坑之后才明白的。

读者评论

陈立航：我们去年就是先上了路由，接了五个模型，结果业务侧一个场景都没跑通，年底复盘挺尴尬的。看完这篇有点扎心，但确实是这么回事。今年准备先把商品主数据理一理。

周敏：口径这块太真实了。我们财务和销售算的毛利差了好几个点，每次开会都在吵这个，吵了一年也没定下来。想问问主数据平台落地的时候，业务部门配合度怎么解决。

李国栋：做数据开发十年了，最怕听到”先做个demo看看”。demo的数据是干净的，线上的数据是脏的，这个道理讲过很多次，但业务方还是喜欢看demo。作者说的先跑五十个真实问题这个做法我准备借用一下。

许静文：评测集那段说到我了。我们模型一升级效果就飘，一直查不出原因，后来发现是没人做回归。今年上半年补了这个问题集，确实稳多了，虽然过程很枯燥。

赵鹏：比较认同把顺序排对这件事。我们是集团型企业，之前各个子公司自己做AI应用，口径完全对不上，集团层面根本没法汇总。后来统一走数据资产平台，指标定义收口之后才好转。