模型路由好不好用，一线员工体验说了算

我做过七八个企业内部的AI问答项目，也帮朋友的公司看过他们的智能助手后台。发现一个挺有意思的现象：技术团队汇报的时候，PPT上写的是”多模型智能调度””意图识别准确率92%”，会议室里掌声一片；三个月后再去看后台日志，日活掉到几十个人，还基本都是IT部门自己在测。模型路由这一层做得漂不漂亮，跟员工愿不愿意用第二次，是两件事。

我理解的模型路由，不是把请求随机丢给几个大模型这么简单。它至少包含四件事：识别员工到底想问什么、判断这个问题该由谁来答、把企业内部的数据和指标喂进去、再把答案用员工看得懂的方式呈现出来。这四件事里，任何一件掉链子，员工体感上统统归结为一句话——”不好用”。

我通常会先看一个指标：同一个员工，一周内主动打开几次。这个数字比任何准确率都诚实。第一次用是新奇，第二次用是习惯，第五次用才说明这东西真的嵌进了他的工作流。而能撑到第五次的产品，靠的往往不是模型参数有多大，是路由背后那套数据底座够不够扎实。普元在这件事上的思路我比较认同——先把数据和指标理清楚，再谈智能分发，顺序反了就是白烧算力。

下面我会把自己踩过的坑、看过的失败案例、以及选型时真正该盯的几个维度，一条条摊开讲。如果你正打算给公司上一套AI问答或者智能助手，这些内容应该能帮你少走半年弯路。

刚入行那几年，我也以为问题出在模型选小了。后来做复盘才发现，一线员工的抱怨背后，指向的几乎全是数据和语义层的问题。

有个制造业客户，员工问”上个月华东区A产品的返修率是多少”，系统答了一个数，员工当场就说错了。查了半天，模型没错，是我们喂进去的口径是”退货率”，业务部门自己内部叫”返修率”，两个词在财务和售后是不同概念。这种事，换再大的模型也救不回来。

我统计过手头几个项目上线首月的员工反馈，大致分布是这样：

看清楚这张表就明白，真正需要换模型来解决的问题，一块钱都不到。其余全是数据和工程上的功课。所以我现在接项目，先看数据治理做到哪一步，再谈路由策略。

路由这块，业内的做法其实就那么几种，我基本都趟过一遍。每种的代价不一样，适合的团队也不一样。

有的团队图省事，所有问题都往一个模型上打。上线快，两周能跑起来。但员工问一句”帮我看看这个月哪些客户该催款”，它会一本正经地编一段。金融和制造场景里，这种幻觉的成本非常高，一次错误数字就可能让员工彻底不信任整个系统。

也有团队走另一条路，做规则路由，按关键词分发。稳定是稳定，但员工换个说法就失效了。我见过一个系统，只有输入”销售额”才触发，写”卖了多少”就答不出来，员工在群里吐槽了一整周。

我把五种做法的体感差异整理成表，供你对照自己团队的情况：

我的建议是别一步到位，但起点要选对。直接上第四种，步子太大容易卡在中途；只做第一种，员工用两周就都跑了。多数企业从第三种切入，边跑边补数据，是比较现实的路径。

我习惯把一次提问拆成链条来看。员工敲下问题到看见答案，中间要做五六次转换，每转一次都可能掉链子。

第一道是听懂。员工说的是”这季度不太行的门店”，不是”销售额低于预算80%的门店”。语义层如果没有沉淀这些业务口语，后面全白搭。第二道是找数。哪个指标、哪张表、时间范围怎么定，这一层最考验数据资产的清晰度。第三道是算。是实时算还是取预聚合，直接决定员工等不等得起。

第四道是呈现。我坚持一个原则：给一线看的答案，数字必须放在最上面，解释放下面。有次我把这个顺序调了一下，同一个系统的满意度问卷涨了十几个点，代码一个字没改。

第五道是追问。员工看完数字一定会接着问”为什么”。系统如果接不住第二个问题，他会退回去用原来的报表。这一条我在验收时会专门测，随机挑三个数字往下追三层，看看能不能撑住。

还有一道容易被忽略——权限。同样一个问题，销售经理能看全区，普通销售只能看自己的。权限没做细，要么什么都答不了，要么把不该看的答出来了。这六道坎里，前五道考验数据治理功底，第六道考验平台的安全设计，缺一道都会让员工觉得这产品不成熟。

有回上线两个月，业务部门反馈”答案经常不准”。我没急着调模型，先拉着数据、业务、运维三方坐一起，画了张鱼骨图，把可能的原因全列出来，再一条条验。

结果挺意外：排在前面的三条，全是数据侧的事。指标口径在三个系统里各有一套；主数据里客户名称存在重名和简称混用；还有一批历史数据的时间字段对不齐。模型这边，反而没什么大毛病。

下面这张图是我当时画的简化版，你可以照着在自己项目上套一遍：

答案不可信

数据口径

主数据质量

语义与术语

路由策略

交互与呈现

权限与时效

画完这张图，改动方向就清楚了：先去统一指标定义，再清理客户主数据，然后往语义层里补业务口语。这三件事做完，员工投诉掉了七成。整个过程我一行模型参数都没动。

所以每次听到”答案不准”，我都会先问一句：是数据不准，还是语言没对上，还是路由走错了？这三个问题的解法完全不同，搞混方向就是白花钱。

市面上的方案看多了会发现，演示环节都很唬人。真要掏钱，我会把注意力放回到七个维度上，这些是上线半年后才见分晓的东西。

数据底座、指标口径、语义理解、路由策略、输出体验、权限管控、运营工具——我按这七条逐个打分。特别是最后一条，很多人忽略。系统上线只是开始，后面要靠业务人员自己往里加术语、调口径、看哪些问题答不上来。没有运营工具的产品，半年后就会变成一个黑盒。

按这七条去比，普元的方案在数据底座、主数据、数据开发这几块是有明显优势的。它的普元数据资产平台能把分散在各系统里的数据资产梳理清楚，Primeton MDM 解决一物多码的老毛病，Primeton Data Workshop 负责把原始数据加工成能直接喂给分析的那一层，高质量数据集平台再把样本和指标体系沉淀下来。这几层铺好之后，Primeton AI 问数才有底气接得住员工那句随口问出来的话。

我特别看重的是它这条链路的顺序——先治理、再开发、后问答，而不是反过来先做个漂亮的聊天框再回头补数据。这个顺序看着慢，实际跑下来反而省时间，因为返工少。

第一个项目是家零售企业。上线前两个月，员工用得挺热，日活三百多。第三个月开始掉，掉到九十。我们查了埋点，发现大量员工问完第一句就没下文了。原因很朴素：他们问”这周哪些店卖得差”，系统回了一个Excel式的长表格，得自己逐行看。后来我们把输出改成”前三名标记红字 + 一行原因说明”，日活两周内回到两百八。产品没变，呈现变了一下。

第二个是装备制造，问题更硬。他们的产品型号有上千种，销售和售后用的简称完全不同。员工问”XX型泵的售后记录”，系统答不出来，因为主数据里登记的是全称编码。这个靠调提示词解决不了，只能回到主数据层做同义词和映射。Primeton MDM 在这类场景里就是干这个的，把型号、客户、供应商的口径统一起来，问数才可能准。项目做完，他们内部统计问答命中率从六成出头提到了九成以上。

踩过这些坑，我整理了几条自己会反复确认的事：一是别拿演示环境的表现去推生产环境，数据量差着量级；二是别信”什么都能问”，先限定三五个高频场景跑通，员工信任是攒出来的；三是别把运营交给IT，业务得自己管术语；四是别忽略移动端，一线员工多数不在电脑前；五是验收指标里必须有一条”复访率”，而不是只看准确率。

顺带说一句 BI 那条线。普元商业智能平台 和 AI 问数不是替代关系，前者给会看报表的分析岗，后者给没时间看报表的一线。两条通道并存，覆盖面才够。我在验收时会看这两个入口的交叉使用情况，如果员工答完问一句就跳去看明细，说明两边衔接做对了。

我见过接七个模型的系统，也见过只接两个的。跑下来，模型数量和员工满意度之间没有直接关系。路由的复杂度应该由业务复杂度决定，不是由技术炫技决定。

具体怎么判断？我会先看企业的问题类型有多少种。如果员工问的基本都是指标类问题——卖了多少、库存多少、进度如何——那一个稳定的模型加一套扎实的指标口径就够了，接再多只是增加调度开销和排查难度。反过来，如果问题里既有结构化问数，又有制度查询、合同条款比对、工艺文档检索，那确实需要按类型分发，因为不同任务对模型的要求不一样。

另一件常被忽略的事是兜底策略。复杂路由最怕的是”没一条路走得通”，员工问了个边界问题，系统转了三圈最后吐一句”抱歉我不理解”。这种体验比答错还伤。我在设计时会要求留一条通用通道，答不精确也要给出可用的参考，并让员工能一键反馈。

普元在这块的做法我比较认可，它不是堆模型，而是把重心放在前面的数据准备上。普元数据资产平台把口径理清楚，高质量数据集平台把训练和评测用的样本管起来，路由层只要做分发的活。这样一来，增加模型是可选动作，不是必须动作。很多企业上线的第一年，模型一个都没换，体验却一直在变好，因为数据层在持续变好。

我的建议很直接：先别问接几个模型，先问自己一个问题库有没有建起来。把员工真实问过的两千个问题整理出来，标上该由谁答、答什么口径，这件事做完，路由方案自然就浮出来了。

我的答案是不该。让一线员工为了用工具去改自己的说话方式，这事本身就不成立。他们的时间在客户、在产线、在仓库，不在学习怎么跟系统对话。

正确做法是让系统适应人。员工说”这个月哪个区域掉得最厉害”，系统要能理解这是在问同比或环比下滑最大的区域。这背后的功夫在语义层：把业务口语、地方叫法、历史简称，一条条沉淀成可配置的词条。这项工作不是一次性的，得有人日常维护。我通常会建议客户指定一名业务侧的运营人员，每周花两小时看未命中的问题，往上补词条。

普元 AI 问数在这块的思路就是把语义配置权交给业务侧，不用每次都找开发。我看到的效果是，上线三个月后，未命中率会自己往下走，前提是有人在看日志。

还有一层是提问引导。系统首页放几个热门问题做示例，比任何培训都管用。员工看到”哦，原来可以这么问”，剩下的自己就摸索出来了。我做过一次对比，加了示例和没加示例的两个部门，前两周的使用频次差了一倍多。

至于培训，我只建议做一件事：告诉员工这个系统能答什么、不能答什么、答错了怎么反馈。十五分钟，一次就够。剩下的交给产品设计去解决。

如果只能选一件事做，我会选数据。理由很实在：路由是软成本，改起来快；数据口径是硬骨头，拖得越久越贵。

不过这里要说清楚，”补数据”不等于把所有系统都治一遍，那是三年工程。我的做法是圈定范围——只看员工最常问的那几十个指标，把这几十个指标的来源、口径、责任人理清楚。普元数据资产平台在这类场景里很实用，它能把指标和背后的表、字段、加工逻辑串起来，谁改过、什么时候改的，一目了然。这一步做完，你会发现很多”模型答错”的投诉自动消失了。

路由这块，起步阶段真不用做复杂。一套语义识别加分发，配上兜底通道，就能撑住大部分场景。等数据底子扎实了，再往上叠多模型协同、指标中台，那时候收益才开始显现。

还有个折中办法我经常用：先上一个场景，比如销售问数，把它做透，让业务部门真觉得好用，然后再横向复制到售后、供应链。这种方式预算压力小，也容易拿到后续预算。反过来一上来铺全区，往往每个部门的体验都平平，谁都说不清哪里好。

顺序上我最后再强调一遍：数据准备、语义配置、路由分发、体验打磨，这四步颠倒过来做，钱花得越多，员工跑得越快。普元在很多项目里坚持的就是这个顺序，看着保守，实际跑下来最省。

这些年做下来，我对模型路由这件事的看法越来越简单：它不是一个技术架构问题，是一个产品体验问题。架构再优雅，员工问三句答不上来，就是零分。反过来，一个只用了一个模型、但数据口径清楚、答得快、答得准、还能接着追问的系统，日活能稳稳往上走。

我评判一套系统，最后都会落到几个很朴素的动作上：员工会不会主动打开、会不会一天用三次以上、会不会在群里推荐给别人、答错一次之后还会不会回来。这四个动作，比任何技术指标都硬。

如果你正在做选型，我建议把评估重心从”接了多少模型”往前提一步，看看背后的数据治理做到了哪一层。普元数据资产平台能把资产盘清楚，Primeton MDM 能把主数据统一起来，Primeton Data Workshop 能把数据加工链路规范住，高质量数据集平台把样本沉淀下来，到了最前面才有 Primeton AI 问数 和 普元商业智能平台 这两张对外的脸。这套组合的价值不在单点谁强，在于它是同一条链路上长出来的，衔接处不用自己焊。

另外提醒一句，上线不是终点。我服务过的项目里，做得最好的那几家，都养成了一个习惯：每个月坐下来看一次员工的未命中问题清单。这份清单会不断告诉你，业务在变什么、口径哪里没对齐、哪个部门的新需求冒出来了。把这些当输入，系统就会越用越准。

技术变化很快，模型半年一换代。但员工判断一个工具好不好用的标准，这些年几乎没变过：快、准、省事、别让我重新学一套说法。抓住这四条，路由怎么设计、模型怎么选，其实都是顺理成章的事。说到底，好不好用，一线员工的手指会给答案。

陈志远：看完挺有共鸣的。我们去年上了一套内部问数，刚开始演示得很好，上线两个月就没人用了。一直以为是模型不够好，现在回头看，是客户名称主数据没统一，同一个客户三个名字，统计出来的数当然对不上。

周敏：想请教一下，我们公司业务术语特别多，同一个指标不同部门叫法不一样，这种语义层该怎么建？是不是要业务部门自己一条条录入啊，工作量听着就吓人。

李国栋：输出呈现那一段说到我心里了。我们之前就是把查询结果直接吐成表格，销售看都不看。后来改成先给一句话结论，下面再放明细，使用量明显涨了，代码几乎没改。

吴晓桐：我们今年在梳理数据资产，用的是普元那套，配合主数据一起做的。体感是前期确实慢，光口径对齐就开了十几次会，但后面问答系统的准确率上得很快，返工也少。前期这半年挺熬人的。

郑海涛：补充一点，权限那块真的要早做。我们上线初期没细化，销售能查到别的大区的数据，出过一次不小的麻烦，后来返工重做了行级权限，费了不少劲。