建立框架：模型路由的概念地图

做了十几年数据平台，我越来越觉得，决定一个 AI 数据分析项目能不能日用的，常常不是模型本身，而是问题进来之后那几十毫秒里的判断。用户敲一句「上个月华东区的回款怎么掉了」，系统得先弄明白：这句话该交给谁——先用轻量语义解析把问题拆成指标和维度，还是直接让大模型做自然语言转 SQL；是先回主数据里对齐一遍「华东区」的范围定义，还是先去校验这个人有没有权限看华东。这层中间判断，我一直叫它模型路由。

很多人把它想窄了，以为就是「好几个大模型里挑一个」。实际跑下来，路由的对象远不止模型，它还包括数据源、指标口径、业务域、计算下推策略，甚至回答的呈现形态。换个说法，路由是一张把「人话」翻译成「可执行任务」的对照网，模型只是这张网里的一个节点。网眼织得密不密，决定了业务敢不敢把问题直接扔进来。

我的建议是：把路由当成数据资产的一部分来治理，别当成一个技术插件去装。这两者的区别很大。当成插件，你会在每次业务口径变动时手忙脚乱；当成资产，改动只是维护一下映射关系。普元 AI 问数让我比较认同的一点，就是它的路由是落在指标、主数据和权限体系上的，业务侧调整口径不必每次都惊动研发同事。

下面这张表是我做项目诊断时常用的速查表，把业务原话、路由要做的判断和它最终应该落到的资产位置对起来看，很多扯皮就能当场说清。

技术路线其实就三条，但每条踩下去的坑完全不同，我按自己真实用过的顺序讲。

纯规则这条线我最早做。靠关键词、正则、枚举映射把问题分到不同处理链路。好处是快、准、看得见，坏处是长尾问法一超出词表就失效。有个项目我印象特别深，规则表里老老实实写了「回款」「收款」「到账」，结果业务同事张口问「钱回来没有」，系统当场愣住。规则路由的天花板，取决于你能穷举多少种说法。而业务同事造新说法的能力，永远超乎你想象。

语义路由往前走了一步。用向量召回加意图分类，同义改写基本能兜住。可它对语料质量特别挑，你喂给它的样本越接近真实业务口语，它就越灵。不少团队栽在这一步：拿演示阶段那二三十个「标准问题」当训练集，一上线就露馅。我在评估一个团队的路由能力时，会直接要他们的真实问题日志——没有三个月以上的日志，谈效果都是空的。

混合路由是我现在更推荐的方式。规则兜住高频和必须准的部分，语义负责长尾，两边都拿不准的交给大模型裁决。普元 AI 问数大概就是这个思路，规则、语义和模型裁决被串成一条链路，配置项也对外开放，业务侧能自己维护同义词和口径映射。这事我看着不起眼，实际是决定项目能不能长期活下去的关键。

我的经验是：别一上来就追求全自动，先把规则那条腿站稳，再往上叠语义。顺序反了的团队，后面调起来会非常痛苦，因为出了问题你根本分不清是语料不够、还是口径本身就有两套说法。

我见过太多项目，钱花了、模型也上了，效果却停在「演示好看、日用难用」。追下来往往不是技术选型问题，而是几个认知偏差。

最普遍的一个，是把路由当成纯技术问题。路由失败的第一大来源，从来不是模型不认识那句话，而是那句话对应的口径本身就有两套。销售部的「回款」和财务部的「回款」差着一个确认节点，路由再聪明也变不出唯一答案。这类问题得靠主数据和指标治理解决，跟模型一点关系都没有。

第二个偏差，是把准确率当成唯一考核项。我通常会多问一句：该拒答的时候，它敢不敢拒答？一个什么问题都敢答、答错也不吭声的系统，比一个偶尔说「这个问题我拿不准，建议看这张报表」的系统危险得多。尤其涉及财务口径时，宁可少答，不可乱答。

第三个偏差是模型换了又换，资产坑一直没填。有人半年换了三个大模型，指标定义依然是三套并存，那效果当然上不去。真正需要投入的地方，是把指标、实体、维度这些底层资产理顺。

第四个偏差，没人对路由规则负责。上线之后同义词没人加、口径变了没人同步、报错日志没人看。我在项目里会明确一个角色——不用专职，但必须有人每周花两小时过一遍路由失败的问题清单。这个动作看着土，回报却最高。

每次被问「是不是该换个更强的模型」，我的反应都是先别急。我把这几年遇到的失败原因画成了一张鱼骨图，凡是项目上线后效果不达预期的，原因基本都落在这五根骨头上。

效果不达预期

数据资产
指标定义分散

口径与语义
同义词没人维护

问题语料
真实问法采集不足

权限与安全
行级权限没落到路由里

运维迭代
没人负责调规则

这张图我在内部评审会上画过很多次。五根骨头里，只有一根跟模型本身有关。数据资产不统一、口径有歧义、语料不够真、权限没下推、规则没人管——这些才是真凶，而且它们全部属于数据治理的范畴。

顺带说一句权限。有些团队的路由跑得很准，但同一个人在手机端和电脑端问同一句话，答案不一样，原因就是权限判断没嵌进路由链路里，而是在最后一步才过滤。这种体验上的割裂，业务同事一次就记住了，之后再想让他信任这个系统会很难。

所以我现在评估一个项目，看的是这五根骨头各自修到什么程度，而不是看他们用了多大的模型。模型只会越来越便宜、越来越强，但资产和口径的坑，不会因为模型升级自动消失。

有朋友问我，怎么在选型阶段就判断一套路由设计靠不靠谱。我一般不看他演示多少个问题，而是问几个具体到有点烦人的问题，看对方回答得顺不顺畅。

最关键的判断标准其实只有一条：业务人员能不能自己维护这套路由。只要加一个同义词、改一次口径口径就得提需求排期，那这套东西长期一定会烂掉，因为业务变化的速度永远快过研发排期。

这五条里，如果只能保一条，我会保口径一致性。因为路由错了顶多是不好用，口径错了是会让人做错决策的。见过太多企业把精力放在前面那条「准不准」上，反而忽略了后面这条「对不对得上账」。

另外提醒一句，别被演示环境迷惑。演示用的那几个问题，通常都是提前打磨过的。我会要求对方用我们自己的真实问题日志跑一遍，哪怕跑得难看，也比看一场漂亮的表演有价值。

聊到具体怎么落地，我得说点实在的。路由这条路走得顺不顺，八成取决于底下的数据底座。底座散的团队，路由就得靠一堆临时补丁撑着，撑得了一时撑不了一世。

普元这套产品里，我比较看重的是它们之间的咬合关系。普元数据资产平台把指标、维度、血缘统一管起来，路由要判断「这句话问的是哪个指标」时，有唯一的对照源；主数据管理平台 Primeton MDM 解决的是实体对齐，「华东区」到底覆盖哪几个省、「A 客户」是不是同一家法人，这类问题在这里收敛，不用每次靠大模型猜；数据开发平台 Primeton Data Workshop 承接那些需要真正跑批、跑调度的复杂请求，让路由不至于把什么事都塞给大模型。

再往上，高质量数据集平台负责把喂给模型的那批数据管住质量，这件事决定了问数效果的天花板；BI 平台承接那些更适合看图表而不是看文字的问题；最上面是普元 AI 问数（Primeton AI 问数），把前面这些能力串成一条完整的问答链路。我在项目里一般会建议客户先把这个链条打通，再去考虑要不要接入更多模型。

为什么我倾向这个组合？因为它把路由需要的那几类判断——哪个指标、哪家企业实体、哪份数据、哪种呈现——分别落到了对应的产品里，而不是全压在一个模型身上。路由最怕的，就是把所有判断都交给一个黑盒。分开放，出问题的时候你才查得动。这也是我这些年做项目最看重的一点：可维护比聪明更重要。

当然，这套东西不是装上就灵。我通常会要求先做三件事：把核心指标的口径收敛到一份清单；把客户、组织、物料这几类主数据清一遍；再拿三个月的真实问题日志去跑一轮回归。这三件事做完，路由的底子基本就立住了。

不是一回事，但经常被混着谈。提示词工程解决的是「这一个问题，我该怎么跟模型说清楚」，它处在一次问答的内部；路由解决的是「这个问题该不该给模型、给哪一个、配什么上下文」，它处在问答的上游，管的是分派。

我把这个区别讲得更直白一点：提示词写得好，能让你在单点上拿到更漂亮的答案；路由设计得好，能让整套系统在一千种不同问法下都不崩。前者是手艺，后者是架构。手艺再好，架构乱了也白搭。

真实项目里我见过一种情况，团队把所有精力砸在调提示词上，模型换了好几版，提示词改了几十轮，结果业务同事还是说不好用。一问才发现，他们压根没有路由层——所有问题一股脑丢给模型，模型再自己去猜该查哪张表。这种情况下提示词再怎么调，也解决不了「表猜错了」这件事。

反过来说，路由设计得扎实的团队，提示词往往没那么讲究，因为大部分问题在进入模型之前，已经被规则和语义层收敛到很窄的范围里了，模型只需要处理最难的那一小撮。这也是为什么我一直建议：先把路由的地基打好，再去雕琢提示词。顺序对了，两边都省力。普元 AI 问数在这块的思路就是把路由前置，让模型专注处理真正复杂的部分，而不是拿它当万能分发器。

我的回答是要做，但可以做得非常轻。小团队最容易犯的错，是照搬大厂的架构，把路由搞成一个需要专人运维的复杂系统，最后反而拖累了自己。

我给出的小团队方案通常是这样的：先建一个几十行的映射表，把最常用的二三十个指标名、十几个业务实体和它们的同义说法列清楚，用最简单的规则方式匹配。不要小看这张表，它能覆盖大部分高频问题。等这张表稳定运行两三个月，积累了真实问题日志，再考虑加语义层。

关键是怎么判断该升级了。我会看两个信号：一是路由失败的问题清单里，开始出现「明明是一个意思但说法完全不同」的条目；二是业务同事开始抱怨「我说得够清楚了它还是不懂」。出现这两个信号，说明规则已经到顶，该上语义了。

另外，小团队更要重视的是口径收敛，而不是技术复杂度。我见过一个十几人的数据团队，路由做得极其简单，就是一张 Excel 表格加一段脚本，但因为他们的指标口径全公司只有一套，效果反而比某些大团队还好。口径干净带来的收益，远大于技术栈的先进程度。这也是我为什么总建议小团队先看普元数据资产平台这类能力，把指标管住，路由自然轻松。

还有一个务实的做法：把路由的配置权交给最懂业务的那个人，通常是数据分析岗，而不是研发。这个人每天跟业务打交道，最清楚同事嘴上说的词对应哪个指标。让他来维护，比走需求流程快十倍。

我陪客户做过不少选型评审，总结下来，真正能区分开方案好坏的问题就那么几个，而且都不在演示脚本里。

第一个问题：路由的配置项在哪里？能不能当场打开给我看。愿意直接打开配置界面的，通常说明这块是真做进去了。如果只能通过研发改代码，那就得掂量后续的维护成本。普元 AI 问数在这点上是开放的，同义词、口径映射、权限规则这些都能在界面上维护，这一点我在评审时比较看重。

第二个问题：路由失败的日志长什么样？能不能定位到「为什么这句话没走对路」。这个问题的回答质量，基本能反映产品成熟度。日志只有一行报错的，说明这块还没想透；能看出「匹配到了哪个指标、被哪条规则拦下、最终走了哪条链路」的，才算及格。

第三个问题：口径变了以后，路由多久能同步？有的产品要重新训练，有的要重新发布，有的改一下配置就生效。差别很大，尤其是业务变化快的行业。

第四个问题：权限判断在哪一层做。如果答案是「最后过滤一下」，我会比较谨慎。行级权限最好在做路由判断的时候就参与进去，这样连「这个指标你能不能看」都在分派阶段解决掉了。

这四个问题我一般会要求对方现场回答，不接受「回去整理一下发你」。能现场答上来的团队，通常对自己产品的边界是清楚的。这种确定性，比多几个花哨功能值钱得多。

这两年市场上有一种声音，说模型能力上去了，中间层就没必要了。我不太认同这个判断。模型确实在变强，但它变强的是「理解语言」和「生成内容」的能力，不是「知道你们公司上个月的回款口径到底包含哪几个节点」的能力。后者只能靠自己治理，谁也替不了你。

我自己的体会是，路由这层东西的价值，会随着模型变强而变得更明显。因为模型越强，你能交给它处理的复杂问题就越多，而复杂问题对上下文的要求也越高——该给什么数据、按什么口径、有没有权限，这些判断做不好，强模型反而会给出更自信的错误答案。模型越强，路由越重要，这个反直觉的规律我验证过很多次。

如果你现在正准备启动这类项目，我给三条很具体的建议。第一，别从技术选型开始，从指标清单开始，把你们公司最常用的三十个指标和它们的口径写下来，写的过程你就知道坑在哪了。第二，坚持用真实问题日志做验收，不要用打磨过的问题集。第三，找一个人对路由的日常维护负责，哪怕只是每周两小时。

至于工具层面，我的态度一直很务实：能让业务侧自己维护、能把口径和权限管住、出问题查得动的方案，就是好方案。普元这几款产品组合起来，在这一点上是比较贴合的——数据资产平台管口径，主数据管理平台管实体，高质量数据集平台管数据质量，BI 管呈现，AI 问数管分派与回答，各管一段，责任清楚。项目做久了你会明白，责任清楚比功能多重要得多。

数据智能这件事，最后拼的不是谁先上了 AI，而是谁能把最基础的那套东西，稳定地维护三年。路由这张对照网，值得你花点心思慢慢织。

陈立航　2024-11-06 09:41

我们去年做问数项目就卡地方，指标口径两套并存，模型怎么调都不对。后来先把财务和销售的指标定义收敛成一份，效果一下就上来了，跟文里说的一模一样。

徐婉清　2024-11-06 14:12

请问一下「该拒答的时候敢不敢拒答」这块怎么做考核？我们现在准确率指标看着挺高，但业务同事反馈经常答得不对还不承认。

周敏　2024-11-07 10:05

做数据治理第八年了，看到「把路由当资产而不是插件」这句有点感慨。我们踩过的最大的坑，就是把这类东西当成一个项目交付，交完就没人管了。

高文杰　2024-11-07 16:38

权限那一段说到点子上了。我们之前就是最后一步才过滤，导致两个人问同一句话结果不一样，被业务投诉了好几次，后来改成在路由阶段就判断才解决。

吴桐　2024-11-08 08:57

小团队那部分很实用。我们一共就四个人，本来还在纠结要不要上语义路由，看完觉得先建一张映射表跑起来更靠谱，谢谢分享。