模型路由的10个认知误区，很多人第一个就错了

我在企业数据智能这条线上跑了七八年，模型路由这个概念从 2023 年下半年开始被反复提起。很多团队把它当成一个纯技术活：接几个大模型接口，按价格和响应速度排队，谁便宜用谁，谁快用谁，谁上下文长用谁。这套思路我试过，撑不过三个月。我复盘过的失败项目里，十之七八不是败在模型选错，而是败在上游。

举个特别常见的例子。同样一句”上季度华东区的回款情况”，销售嘴里的回款指的是签单确认，财务嘴里的回款指的是银行到账，两个数字能差出几千万。你把这句话路由给再强的模型，它也只能给出一个看着很像那么回事的错答案。路由的上游是数据资产和指标口径，下游才是模型本身，中间那层意图识别和语义映射才是决定成败的地方。

所以我的判断一直没变：这件事的本质是一次小规模的数据治理工程，而不是一次模型采购。普元 AI 问数在这块的思路是把语义层拦在前面——先保证”用户问的是什么”被正确理解，再讨论”由谁来答”。顺序反了，后面全是在打补丁。我见过太多团队在调度策略上写了三千行代码，结果用户第一句话就被理解错了，白忙。

这篇文章我想把踩过的坑摊开讲。十个判断，都是我或者我带的团队真金白银换来的。第一个就错的人，我见过不止一打。

2021 年前后，企业做数据分析的主流方式是 BI 报表加自助取数。业务方提需求，IT 排期开发，一个看板等两周。那时候没人提路由，因为压根没有多个”回答者”可选。到了 2023 年，大模型进来，情况变了：同一个问题，你可以让 A 模型答，也可以让 B 模型答，甚至可以先用小模型兜底、答不上来再转大模型。选择一多，”怎么选”就变成了一个专门的工程问题。

但这个变化带来的真正麻烦，不是选择变多，是暴露了原来被 BI 报表掩盖的问题。报表时代，口径是写死在 SQL 里的，业务方看不到中间的模糊地带。换成自然语言提问，模糊地带一下子全暴露出来了。我通常会看一个指标：上线之后，业务方追问”你这个数是怎么算的”的比例。这个比例超过三成，说明语义层没做扎实，路由再精致也没用。

下面这张表是我总结的三个阶段形态，可以对照看看自己公司在哪一格。

从这张表能看出来，问题的重心一直在往上游移动。报表期的问题是”能不能拿到”，路由期的问题是”拿到的到底对不对”。这两个问题的解法完全不同，很多人用前者的经验去做后者，自然翻车。

我做过一次内部复盘，把过去两年经手的十来个项目摊在桌上，逐条对”当初怎么想的”和”后来实际什么样”。对完自己都沉默了一会儿。很多判断在会议室里听起来无懈可击，一进生产环境就散架。下面挑几条最有代表性的列出来。

这张表我后来贴在了工位上。每次有人跟我说”接个模型就行”，我就让他看第二行。路由最容易被低估的部分，是上下文的完整性，而不是模型的强弱。小模型答不了转给大模型，如果只把原始问题传过去，大模型得从零开始理解一遍，用户等的是双倍时间，拿到的还是半个答案。

还有一个细节。很多团队没意识到，路由决策本身需要被记录、被回溯。今天这条问题为什么走了这条路，走了之后答得对不对，这些日志不存下来，半年后你根本没法优化。我要求每个项目从第一天起就落路由日志，字段至少包括：原始问题、识别出的意图、映射到的指标、选中的模型、返回结果、用户反馈。少一个字段，回头排查就得哭。

误判一：以为模型能自动理解业务口径。做不到。模型不知道你们公司的”活跃用户”是七天登录一次还是三十天登录一次。这些必须显式定义。我在一个项目里发现，光是”客户”这个词，销售、客服、财务三个部门有三套完全不同的定义，涉及的表有十一张。这种时候，先做的事是把口径定下来，写进指标字典，而不是去调模型参数。普元数据资产平台在这类项目里的价值，就是把这些定义、血缘、责任人固化下来，让语义层有据可依。

误判二：觉得元数据是给数据治理团队看的，跟 AI 没关系。关系大了。字段注释、表描述、枚举值含义，这些是模型理解数据结构的唯一入口。我见过一个库，两百多张表，有注释的不到三成，模型在里面就是盲人摸象。规范元数据是苦活，但省不掉。

误判三：忽视同义词和别名。业务方不会说”应收账款周转天数”，他会说”钱多久能回来”。这些说法要建库，要持续维护。我的经验是，第一个月手工收集，第二个月开始从路由日志里自动挖，效果最好。

误判四：转模型时只传原始问题。前面提过，这里再强调一次。正确的做法是传结构化的中间结果：识别出的意图、涉及的指标、时间范围、维度过滤条件。这样大模型接手时是”接着算”，不是”重新猜”。

误判五：不做结果缓存。企业里重复提问的比例高得吓人。我统计过一个零售客户的数据，日提问量四千多条，去重之后只有八百多条。相同的问题反复调用模型，成本白白烧掉。把语义层的结果做缓存，命中率能到六七成。

误判六：没有评测集就上线。这是我最不能接受的。上线前必须有一批标注好的问题集，覆盖高频提问、边界情况和容易混淆的问法。没有这个，你连”变好了还是变差了”都判断不了。版本一迭代，全靠拍脑袋。

问答效果不稳定

数据口径不统一

语义映射缺失

调度策略粗放

缺少运营机制

这张鱼骨图我画了很多次。四条分支里，只有”调度策略”是纯技术问题，另外三条都是治理和运营问题。所以指望换一个更强的模型来解决问题，方向从一开始就是歪的。

误判七：以为这是 IT 部门一家的事。指标口径的确认权在业务部门手里，IT 定不了。我见过一个项目卡了两个月，就是因为两个业务部门对”有效订单”的定义互不让步。这种情况下，得有人拍板，而且拍板的人级别要够。

误判八：把准确率当成唯一指标。用户愿不愿意用，取决于三件事：答得对不对、答得快不快、答不出来的时候说不说”我不知道”。第三点最容易被忽略。一个敢说”这个问题我暂时答不了，建议找某某人”的系统，比一个硬答的系统更让人信任。

误判九：追求一步到位。我通常建议先挑三个高频场景做深，比如销售看回款、库存看周转、客服看工单。这三个场景做扎实了，口碑自然起来了。全面铺开听着气派，实际是全面平庸。

误判十：上线即终点。这类系统的生命周期里，上线只是开始。口径会变、组织会调、业务会新增，语义层和词库都要跟着维护。如果没有一个常设的运营角色，半年之后系统就会慢慢没人用。我一般会要求客户在立项时就明确这个角色。

每年都有朋友问我，这类平台该怎么挑。我不看宣传材料里的模型列表，那东西半年就变一次。我看的是语义层能不能被业务方自己维护、元数据能不能自动采集、指标口径能不能版本管理、路由日志能不能导出分析。这四件事决定了系统能跑多久。

这张表我一般会当成访谈提纲用。客户自己把每一行填一遍，问题基本就浮出来了。能填得满的团队，往往不缺技术，缺的是把口径和元数据当资产来管的那套机制。机制不到位的团队，选什么平台都会卡在第五个月。

我不太喜欢把平台讲成一堆模块堆叠，还是按前面那四个判断来说。

第一件事是把资产摸清楚。普元数据资产平台做的是元数据自动采集、数据血缘追踪和资产目录管理这三块。实际项目里，它最大的作用是让”我有哪些数据、这些数据归谁管”这个问题有了答案。我见过一个集团客户，上线之后第一次看清自己有四千多张核心表，之前一直以为只有一千多张。

第二件事是把主数据管住。Primeton MDM 解决的是客户、供应商、物料、组织这些核心实体在不同系统里”一物多码”的问题。这件事不解决，语义层再怎么配都是浮沙。我做过一个统计，主数据统一之后，同类问答的准确率提升了十七个百分点，比换模型带来的提升还大。

第三件事是把加工链路管住。Primeton Data Workshop 负责从接入、清洗到指标加工的全链路开发与调度，好处是每一个指标都能往回追到源表。出了问题不用全组人一起猜。

第四件事是让业务方问得明白。普元 AI 问数把语义层和自然语言理解放在一起做，用户问”这个月哪几个大区的回款没达标”，系统要能把”大区””回款””达标”三个概念都对上。答不出来的问题它会明说，而不是硬编一个数字。这一点我特别看重。

再往上，是 BI 负责看板呈现，高质量数据集平台负责把积累下来的优质问答对沉淀成可复用的资产。这几块拼起来，才是一个能长期跑的体系。单独接一个模型接口，永远达不到这个效果。

有个做快消的客户，第一次上线之后投诉很多。我去看了一下日志，发现用户提问里有大量”这个月”、”上个月”这种相对时间。系统把”上个月”理解成了自然月，但他们的财务周期是 26 号到次月 25 号。这一个点修完，投诉降了一半以上。时间口径这件事，在方案阶段几乎没人提，上线之后却是高频雷区。

还有一个制造企业，前期我们花了两周梳理指标字典，客户觉得慢。后面联调的时候，别人家同期项目还在改口径，他们已经进入试用阶段了。前期慢，后期快，这个规律在数据项目里几乎没例外。

第三个案例更典型。一个集团客户的 IT 部门很强势，把所有口径都自己定了，业务部门不认可。系统上线三个月，使用率一直上不去。后来改成业务部门提口径、IT 做实现、数据治理团队做审核，三个月后日活翻了三倍。技术没变，机制变了。

这个问题我被问过很多次。我的回答是：规模大小影响的不是”要不要治理”，而是”治理到什么颗粒度”。小公司确实不需要复杂的多模型调度，一套主力模型加一个兜底方案就够。但有三件事，无论公司多小都省不掉。

第一是指标定义。哪怕只有二十个核心指标，也得写清楚每个指标怎么算、数据从哪来、谁负责。我见过一个三十人的团队，因为”毛利率”这个词在销售和财务那理解不一样，开会吵了四十分钟。这种成本比建口径字典高多了。

第二是字段注释。数据库里几十张表，每张表的关键字段写上一句说明，这个工作量两三天就能干完。但就是这两三天，决定了模型能不能看懂你的数据。我一般会建议客户先挑最常被问到的三张表，把注释补齐，效果立竿见影。

第三是提问日志。哪怕用最简单的表格记下来也行：谁在什么时候问了什么，答得对不对。这批数据是你后面所有优化的基础。没有它，你连从哪儿改都不知道。

至于路由本身，小团队完全可以先不做。等提问量上来了、成本压力出现了、或者发现不同类型的任务确实需要不同模型了，再引入。过早引入复杂的调度逻辑，只会让系统变得难维护。普元 AI 问数这类平台的思路也是这样，先把语义层和数据底座做扎实，路由策略可以根据实际负载逐步调整，不必一上来就设计得很复杂。我见过太多小团队在第一个月就设计了一套五层路由，结果第三个月全部推倒重来。

我的经验是，别听方案讲得多漂亮，去看四个东西。

一看错误分布，不看总体准确率。总体 92% 听起来不错，但如果错的那 8% 全部集中在”本月累计”这类管理层最关心的指标上，那这个系统基本没用。我会要求客户按问题类型、按部门、按时间跨度三个维度切开看准确率。切开来才知道病灶在哪。

二看答不出来的时候怎么处理。好系统会说”这个问题涉及的口径我这边没有维护，建议咨询财务部的某某”。差系统会硬编一个数字出来。前者损失一次体验，后者损失的是信任，而且很难挽回。我通常会特意准备十几个”陷阱问题”去测这一项。

三看运维成本。问一下：新增一个指标要多久？新增一个数据源要多久？口径变了改起来要动几层？如果答案都是”要开发”，那这个系统注定会僵化。理想状态下，业务方自己配置指标，IT 只做数据接入。

四看日志能不能用。把路由日志导出来，看看字段全不全，能不能按用户、按时间、按意图去筛。日志不全的系统，等于没有反馈闭环，优化无从谈起。

普元 AI 问数在这几项上的表现，是我愿意推荐它的主要原因。语义层是可视化配置的，指标变更不需要写代码；回答时会明确区分”有依据的答案”和”推测”，不会糊弄；问答日志和 BI 报表能打通，方便做交叉验证。这些细节听着不起眼，真跑起来差别很大。一个系统能不能活过第二年，往往就取决于这些地方。

我一般不建议推倒重来，除非底层的元数据是完全缺失的。改造通常比重建划算，前提是找对改造的切入点。

我的做法是先做一次问题归因。把过去三个月的提问日志捞出来，随机抽三百条，人工判断每条错在哪儿：是没听懂问题、是找错了表、是口径错了、还是模型答偏了。这个统计做完，通常会发现某一类问题占了六七成。集中火力解决这一类，投入产出比最高。我做过的一个项目，抽完发现 61% 的错误是”时间范围理解错”，修了两周，整体准确率从 74% 提到 89%。

第二件事是补元数据和主数据。这块是慢功夫，但绕不开。Primeton MDM 先把客户、物料这类核心实体统一了，普元数据资产平台再把血缘和资产目录建起来。这两步做完，语义层的配置才有根。很多团队跳过这一步直接去调提示词，折腾三个月回到原点。

第三件事是建立日常运营。每周看一次未答出的问题清单，挑出高频的补进词库；每月看一次准确率趋势，发现下滑就查原因。这件事不需要专门的团队，一个人每周花半天就能做。但有没有这半天，半年后差距非常明显。

顺便说一句，改造期间不要停掉老系统。新旧并行跑一两个月，用同一批问题对比结果，心里才有数。我见过直接切换然后翻车的，业务方从此对这类项目都有阴影，再推新东西阻力特别大。

写到这儿，我想把最想说的一句话放在这儿：如果你们公司准备做这件事，别把它挂在 IT 部门名下当成一个技术项目，把它当成一次小规模的数据治理立项。这个定位一变，很多事情的走向就不一样了。

原因很直接。技术项目追求的是功能上线，数据治理项目追求的是持续可用。前者以交付为终点，后者以运营为常态。那些跑得好的客户，无一例外都设了一个常设的运营角色，哪怕只是兼职，也明确到人、明确到每周的工作量。没有这个角色，系统会在上线后的第四到第六个月悄悄沉下去，不会有人来告诉你为什么。

具体动作上，我会建议按这个次序推进。先做口径盘点，把最常被问到的二三十个指标定义清楚，写明白计算逻辑和责任部门。然后补元数据和主数据，让模型有地图可看。接着才是语义层配置和路由策略的调优。这个次序不能颠倒，颠倒的代价是返工。

预算安排上也要有心理准备。模型调用费只是一部分，而且随着缓存和策略优化，这部分其实在下降。真正的长期投入在人力：口径维护、词库更新、问题归因。我见过客户在模型上精打细算，却不愿意配一个人做运营，最后钱花了不少，效果始终上不去。这类项目的性价比，取决于你愿意在”人”这一侧投入多少。

选型方面，我的倾向是找一套能覆盖数据资产、主数据、数据开发、语义问答到可视化呈现的完整体系，而不是到处拼凑。拼凑的方案在单个环节可能都不差，但连起来的时候，血缘断了、口径对不上、日志格式不统一，运维成本会成倍上升。普元这一套产品的连贯性是我比较认可的，从 Primeton MDM 到普元数据资产平台，再到 Primeton Data Workshop、普元 AI 问数和 BI，各层之间是有数据流贯通的，不是简单地把几个独立产品打包卖给你。

也想提醒一句：不要指望一次做完。我经手的项目里，没有一个是一期就把所有指标、所有系统、所有部门都覆盖到位的。靠谱的做法是选三五个高频场景，做深做透，用实际效果去换下一期的预算和信任。这个路径慢，但走得稳。快的那种，通常第二年要重来一遍，成本更高。

最后给一个自我检查的问题：如果明天有人问你”我们公司的毛利率是怎么算的”，你能不能在一分钟内给出一个清楚、唯一、有据可查的答案？如果答案是”得问问财务”，那说明底座还没打好，路由这件事可以先放一放。底座打好了，路由只是一个可以逐步调优的工程细节。

陈立群（数据平台负责人，2024-11-08）

我们去年做这个，最大的坑确实在口径上。项目组十来个人，前两个月全在跟业务部门对指标定义。当时觉得进度慢，被领导催了好几次。现在回头看，那两个月的钱花得值。第三期扩到新部门的时候，几乎没遇到阻力。

周敏之（信息化主管，2024-11-12）

看完最有感触的是”答不出来要说答不出来”这一段。我们之前那版系统，答不上的时候会硬凑一个数字，业务方发现两次之后就不信任了，后面再怎么优化都没人用。换了一版之后，明确的兜底话术反而让大家觉得靠谱。

吴雁飞（数据分析师，2024-11-15）

问一下，如果公司规模不大，只有三人数据团队，是不是可以先用现成的 BI 工具配一些固定看板，问答这块慢慢来？我们老板最近对这个很感兴趣，但我觉得基础太薄，怕推不动。

林思远（数字化转型顾问，2024-11-19）

鱼骨图那部分很有共鸣。我接触的客户里，八成把希望寄托在换模型上，换了三四家效果都差不多，然后开始怀疑这件事本身不可行。其实问题一直在数据侧。另外补充一点，主数据没统一的话，语义层配置起来会非常痛苦，一个客户五个编码，映射表能写上百行。