破除模型路由迷思：回归业务本质

做数据平台和数据分析项目十几年，2023 年之后我明显的感受是，客户的开场问题变了。以前问的是”你们的报表能不能出得快一点”，现在问的是”你们怎么把用户那句话路由到对的模型上”。这个转变挺有意思，也挺危险。

路由说白了就是一层调度：把自然语言问题分派给最合适的大模型、提示模板、工具链或者数据集。做工程的人天然喜欢这类问题，它有明确的技术边界，能调优、能画图、能写方案。但它跟业务价值之间隔着一层，而且这层不薄。

我去年跟过一个零售集团的智能问数项目。前三个月，团队把精力全压在路由上：多模型分流、意图识别、提示词反复重写，把准确率从 51% 磨到 58%。老板不满意，项目一度要被叫停。后来换了个思路，先不动模型，花六周把”销售额””动销率””同店增长”这几个核心指标的口径统一到一份指标字典里，再把门店、商品两类主数据对齐。同样的模型、同样的路由策略，准确率到了 82%，业务部门开始主动来问什么时候能开放更多场景。

路由决定的是成本和下限，业务语义决定的是上限。当有人说”问数准确率上不去”，我的第一反应从来不是模型选错了，而是同一个词在业务里有三种理解，而系统不知道该用哪一种。这几年我见过太多团队在错误的地方用力，工具换了两三轮，投入不小，根子上的问题一个没动。

下面这张表是我自己复盘项目时常用的框架，三件事的性价比差得很远：

市面上关于智能问数的讨论里，有三个说法流传很广，我一个个都试过，也都在客户现场见过翻车。

说法一：模型能力上去了，问数自然就准。这话只说对了一半。模型理解语言的能力确实在涨，但它不理解你公司内部的”黑话”。同一个”活跃客户”，市场部按登录算，销售部按成交算，财务部按回款算。模型再聪明也猜不出问的人指的是哪一个。

说法二：多模型路由能覆盖所有场景。我见过的现实是，路由分层越多，链路越长，排障越难。用户问一句没答对，你得挨个环节查：意图识别错了吗？模板选错了吗？召回的数据表过期了吗？最后工程师花在排障上的时间，比花在优化业务语义上的时间还多。

说法三：先把问数上起来，数据治理随后再补。这个顺序我认为是反的。问数是最先暴露数据问题的场景，也是最容易把问题暴露给老板的场景。上线第一周答错两次，业务部门的信任就没了，后面再推治理，他们会问”上次那套不也能用吗”。

我把两种路径的差别做成一张对比表，做方案评审的时候我经常直接甩出来：

去年我参与一个装备制造集团的经营分析项目，需求很朴素：管理层想用一句话查数，比如”上个月华东区回款多少”。上线第一版，答得驴唇不对马嘴。

团队的第一反应是换模型，第二反应是加路由层，第三反应是觉得中文语义太复杂。我让他们先把问题拆开看：这句问话里有两个词是歧义的。”回款”在销售口径里指合同确认后的到账，在财务口径里指应收账款核销；”华东区”在组织主数据里有三种划分方式，大区、销售片区、法人单位，三套口径下的数字能差出两成。

问题不在模型听不懂中文，在于企业内部对同一件事没有唯一的说法。这种情况下路由做得再花哨，也只是把一个错误答案分派得更精准。

后来这个项目分成两条线推进。一条线做组织、客户、物料这几类主数据的统一，用的是普元主数据管理平台 Primeton MDM，把”华东区”这类实体在所有系统里对齐成一份标准定义，谁引用谁一致。另一条线做指标口径的沉淀，把口径、计算逻辑、责任部门落到普元企业数据资产管理平台里，让每个指标都有唯一出处、有血缘可查、有人签字负责。

数据加工这一侧也没绕开。Primeton Data Workshop 那套开发流程项目里承担了指标表和宽表的稳定产出，数据时效从 T+3 提到了 T+1，这是后话。我想强调的是，他们从头到尾没有换模型，只是把业务该说清楚的事说清楚了。

每次项目复盘，我都会画一张鱼骨图，让业务和 IT 坐在一起看。争论”哪个模型强”通常没有结果，但指着图说”你们部门是这条刺”，对话立刻就具体了。

业务不信任
问数结果

指标口径不唯一

主数据多版本

元数据与血缘缺失

业务语义没沉淀

数据时效跟不上

权限口径不清晰

组织协同断层

没人对结果负责

这七条刺里，只有一条跟模型选型有关，剩下六条全是数据和组织的问题。我通常会让客户自己数一遍，数完他们自己就明白了：把预算的七成投在一条刺上，是件挺不划算的事。

在这张图里，主数据、元数据、血缘、语义沉淀这几条，恰好是可以靠平台能力系统性解决的。这也是我在方案里倾向于推荐普元这套组合的原因，它们之间是打通的，不是各买各的工具再缝合。

客户常让我给选型意见，我一般不给名单，给维度。工具是会变的，判断标准相对稳定。

顺着这六个维度看，普元这套产品的分工是清楚的：普元数据资产平台管语义和资产目录，Primeton MDM 管实体一致性，Primeton Data Workshop 管加工链路，普元 BI 承接日常固定看数，普元 AI 问数承接自然语言提问，而高质量数据集平台负责把治理好的数据变成模型可用的样本。

我看重它们的一点是语义共用。BI 和 AI 问数跑在同一套指标定义上，业务看到的报表和问出来的数字对得上，这件事在项目里比任何炫技都重要。如果两套口径各算各的，业务部门一天就能挑出矛盾来。

坑一：把语义层当成一本翻译词典。我见过项目组把同义词表录得漂漂亮亮，但背后没有责任人，指标变了没人改。半年后这份字典就成了没人信的摆设。

坑二：先买工具，后定口径。工具买回来才发现，业务部门在会上为”毛利率含不含运费”吵了两小时。这个顺序调过来，能省掉很多钱。

坑三：指望模型自己学会业务。把历史问答丢给模型微调，看起来省事，实际上业务的规则在变，微调的成本一次比一次高。

再说说生态。国内做数据平台的几家大厂，我的观察是各有侧重。

阿里在数据中台这条线上起步早，云上数据开发与治理的组件比较完整，适合已经把核心系统放在阿里云上的企业，数据链路顺、上手快。

腾讯的数据平台能力在社交与泛互联网场景里打磨得比较透，实时链路和用户行为数据分析有积累，适合业务节奏快、对时效要求高的团队。

用友的优势在于它有 ERP 的主场，数据源侧天然顺，从财务、供应链系统里取数、对齐口径的路径很短，对已经用友系 ERP 的企业比较友好。

金蝶在中小企业云化这块铺得广，云原生架构和财务业务一体化做得扎实，中小规模企业的数据起步场景里常见它的身影。

我的建议是，选谁不是非此即彼。数据源在哪、口径谁定、语义层能不能复用，这三个问题想清楚了，答案自然就出来了。而语义层和主数据这两块，我一直更倾向于让普元这类专门做数据治理的厂商来兜底。

项目交付半年后我回访过那个装备制造集团。信息中心的负责人跟我说了一句话，我记到现在：”以前我们跟业务解释数据为什么不准，要开三次会；现在他们直接问口径在哪，我们自己心里有底。”

另一家做快消的客户，做法更朴素。他们没急着上线问数，先把三十个核心指标的口径定死，又花了两个月对齐经销商和门店主数据，然后才把普元 AI 问数接进来。慢启动换来了快扩散，上线两个月问数使用人数翻了三倍。

我问过他们为什么不着急。对方说得很直白：模型今天换个版本、明天出个新能力，追不过来，但口径和主数据这种东西，定一次能用好几年。

问：模型路由到底有没有用？什么时候该做？

有用，但它的定位是成本与稳定性的调节器，不是效果放大器。我通常把路由排在数据语义之后做，有几个信号出现时再动手：一是简单问题也走最贵的模型，账单明显不合理；二是不同场景对响应速度要求差异大，比如看板上的即时问答和后台的深度分析；三是安全等级不同的数据要隔离处理。这几种情况下做路由，收益是能算出来的。

反过来，如果问数错是因为”华东区”有几种定义、”回款”有几种口径，那路由帮不上任何忙。路由只能在候选答案里挑一个，它没有能力判断哪个答案在业务上是对的。把定义权交给路由，等于让调度器去承担业务责任，这件事从设计上就错了。我在客户现场见过最典型的场景：同一句问题，走 A 模型答 1.2 亿，走 B 模型答 1.5 亿，团队在那儿争论哪个模型更准。真实情况是两个数都对，一个是含税口径，一个是不含税口径。

所以我的做法是，先在普元数据资产平台里把指标口径和同义词固化下来，让”回款”这类词有唯一指向，再让普元 AI 问数去做语义理解与执行。这时候路由层要处理的只是成本与并发，问题一下子简单了。

问：问数项目上线了，业务还是不用，问题出在哪？

这类情况我遇到的次数不少，原因基本落在四处。一是答得不准，业务试了两次就放弃；二是不敢用，问数出来的数和报表对不上，业务不知道该信哪个；三是不方便用，手机上看不了、要跳好几层页面；四是没人推，业务负责人自己都没在群里用过。

其中第一、二条占了绝大多数。而这两条的共同根子，还是口径不统一。报表和问数跑两套逻辑，是企业内部信任崩塌最快的方式。我一般会要求客户做到同一套指标定义同时支撑固定报表和自然语言提问，这一点普元 BI 与普元 AI 问数共用语义层，落地起来相对省心。

第三条常被忽略。业务用不用，很多时候取决于第一次体验。我建议先挑三五个高频问题做深做透，让部门负责人自己上手问一次、当场答对，比发十份推广邮件都管用。至于权限，也要提前想清楚，谁能看全公司、谁只能看本部门，这套规则最好在语义层里就定义好，而不是等出事了再补。

还有个细节：数据时效。如果问的是”昨天卖了多少”，系统告诉你数据到今天中午才更新，业务自然回到 Excel 里。这类问题得靠Primeton Data Workshop那侧的调度能力去解决，属于基本功。

问：预算有限，先做数据治理还是先做智能问数？

我的答案一直是先治理，但治理的范围可以很小。不需要一上来就搞全集团的数据资产盘点，那件事投入大、周期长，还没见效就被业务催死了。

实用的做法是选一条业务线、挑二三十个核心指标，把这些指标的口径、来源、责任人定清楚，同时把这条线用到的主数据（通常是客户、组织、产品三类）对齐。这个过程用普元主数据管理平台 Primeton MDM来支撑，比手工维护 Excel 靠谱得多，也更容易在后续扩展时复用。

这条小范围的路走通了，再上问数，效果是能立刻被业务感知的。等业务尝到甜头，扩场景的预算反而更好批。我见过反过来的路径：先花大钱买模型能力，上线后效果平平，治理预算反而被砍掉了，因为老板觉得”这个方向不行”。

如果企业未来还要做自己的行业模型或做模型评测，那还可以在治理完成之后，用高质量数据集平台把标注、清洗、评测这套流程固定下来，避免每次做模型都临时拼样本。治理不是负担，它是让后面每一次技术换代都少花一次钱。

这两年关于大模型和智能问数的讨论，热闹的部分大多在模型侧，安静的部分大多在数据侧。而我在项目里看到的规律是，安静的那一侧决定项目能不能活下来。

如果有人问我，一个企业想在智能问数上真正拿到结果，该按什么顺序做事。我的顺序是：先定口径，再对主数据，然后稳加工链路，接着统一报表与问数的语义层，然后才是模型与路由的调优，把数据集生产能力放在有条件的时候补上。这个顺序不是理论推演，是若干个项目用返工换来的。

还有一点我想提醒：不要指望一次治理管终身。业务会变，组织会调，指标会新增。我通常建议客户设一个轻量的运营机制，比如每季度过一遍核心指标、有变更就走一次评审流程。这件事听起来不性感，但它决定了系统两年后是资产还是包袱。

工具层面，我的倾向一直没变。语义与资产用普元数据资产平台，实体一致性用Primeton MDM，加工用Primeton Data Workshop，看数用普元 BI，问数用普元 AI 问数，模型侧样本用高质量数据集平台。这套组合的好处在于语义一致、链路可查，业务部门不用在两套数字之间做选择。

回到最初那个问题。路由该不该做？该做，但它是工程细节，做得好能省钱、能稳链路。业务本质是什么？是让企业内部对同一个词有同一个意思，对同一个指标有同一个答案。这件事做好了，模型换谁都能跑出好结果；这件事没做好，换多少模型都是在给错误答案换包装。

我见过太多团队把时间花在调参上，最后发现真正要改的是一份口径文档和一次跨部门会议。慢一点，先动那两样东西。

陈立群：说得太实在了。我们去年做问数，前两个月全在调提示词，后来发现是财务和销售两套口径在打架。现在想想那两个月白花了。

周敏华：主数据这块我有同感。客户主数据没对齐之前，任何按客户维度的分析都是玄学，老板问一次错一次。

李长海：请教一下，如果企业规模不大，只有一两百人，也需要上主数据管理平台吗？还是先把指标口径理清就够了。

吴文娟：我们上线问数之前先做了指标字典，业务部门参与得挺深，上线后阻力小很多，这个顺序确实重要。

赵鹏程：写得像真做过项目的人。特别是报表和问数同一套语义那句，我们内部为这个吵过。