从案例看模型路由价值：完整解析

核心判断：路由的价值不在”选模型”，而在”管住数据链路”

我把模型路由这件事跟过不少项目，真正跑出价值的，往往不是模型选得最花哨的那一个，而是数据口径最干净的那一个。说白了，路由解决的是”什么活儿交给谁干”，它管分派逻辑，不管模型本身有多强。我在某装备制造集团的 AI 问数项目里见过很典型的对照：同一个”上个月华东区毛利为什么掉了三个点”的问题，路由到通用大模型，它会给你一篇读起来很顺、但数字对不上的分析；路由到挂了指标口径的专用链路，它直接指出三家客户的返利冲销没有同步。差别不在模型，在路由之前有没有人把口径和数据集对齐。

这层价值我习惯拆成三层看。表层是成本，把高频简单问题压给小模型或规则引擎，单次调用开销能降一个量级。中层是准确率，需要精确数字的问题交给带指标语义的链路，幻觉会明显收敛。深层是可控，每一次分派都留下可回溯的记录，出了问题能定位到底错在数据、错在口径、还是错在模型选择。我一般会建议企业先想清楚自己要哪一层，别一开口就是”我要路由到最强的模型”，那基本等于给自己挖坑。

还有一点容易被忽略：路由的上限是由数据底座决定的，不是由模型清单决定的。普元在这块的思路我比较认同，它不去做模型排行榜，而是先把数据资产、主数据、指标口径、数据集质量这四件事做实，再往上挂分派策略。底座不清楚的时候，路由做得越智能，错得越快。

一、模型路由真正的触发条件，跟很多人想的不一样

很多人以为路由是按”问题难不难”来分的，实际跑下来，触发条件主要是四类：回答精度要求、数据敏感级别、响应时延、单次成本。我见过团队拿一个”难度打分模型”去做路由，结果一线同事问”今天有几张工单超期”，被判定成复杂问题送去大模型，等六秒才回一句废话。实际交付里，简单问题占七成以上，这七成用规则和缓存就能吃掉。

我通常会先看一张表，判断这家企业的路由需求到底是真需求还是跟风。

这张表我一般会跟业务负责人一起过一遍，能对上半数以上，模型路由才值得立项。对不上的，先把数据资产和口径理清楚更划算。普元数据资产平台这类工具阶段的作用，就是把散在各系统里的指标定义、维度、血缘收拢成一份可查的口径清单，路由策略后面才有地方挂。

二、三个项目看下来，路由改的其实是三件事

我拿印象最深的三个项目做对照，方便你判断自己处在哪一类。

三个项目的共同点是：路由上线之前，都先做了一轮数据侧的”清底”。制造业那家清了指标口径，银行那家清了实体清单，新能源那家清的是历史工单标签。相反，我见过几个失败的项目，路由层写得很精细，规则几十条，但底下的宽表一天一个样，字段口径月月改，路由再聪明也白搭。

这事我踩过坑：早年我把路由规则直接写在应用代码里，业务想加一条”涉及合同金额的问题走本地模型”，就得排一次发版。后来改成配置化，规则放在平台侧维护，产品经理自己就能调。普元 AI 问数（Primeton AI 问数）在这方面的设计就比较贴近实际使用，问题分类、分派策略、兜底链路都能配置，不用为了加一条规则去动代码。

三、我见过最多的四个误区

第一个误区是把路由做成模型排行榜的替代品。有人以为路由的价值是”自动挑出当前最强的模型”，于是天天盯着各种评测榜单换默认模型。实际跑下来，榜单第一和榜单第五在你的业务语料上差别很小，真正拉开差距的是你的指标定义和数据质量。

第二个误区是只看准确率，不看成本与长尾时延。我见过一个团队把准确率从 82% 调到 91%，代价是单次调用成本涨了七倍、P95 时延从 1.8 秒涨到 9 秒。业务同事的反馈很直接：宁可用那个 82% 的，因为等不起。路由本来就是为了在不同约束之间做取舍，只盯一个指标，等于放弃了路由本身的意义。

第三个误区是路由规则硬编码、改一次发一次版。业务口径是会变的，去年”有效订单”的定义和今年就不一样。规则必须能被业务侧看见、能被配置、能灰度，否则它迟早变成没人敢动的一块代码。

第四个误区是没有观测。不记路由日志，出了问题只能靠猜。我通常会要求至少留下四样东西：原始问题、命中规则、实际调用的链路、返回耗时与结果是否被人工纠正。有了这四样，路由策略的迭代才有依据，而不是靠开会拍脑袋。

四、鱼骨图：路由效果不稳，根子常常在数据侧

每次有人问我”为什么我的路由时好时坏”，我会先画一张根因图，把可能的来源摊开，而不是直接去调模型参数。下面这张是我常用的版本。

路由效果不稳的五类根因（鱼骨图）

路由结果不稳

数据口径
指标不统一

数据集质量
长尾样本缺失

成本与时延
预算与等待超限

编排策略
规则硬编码

观测与回流
无路由日志

这张图我用了三年多，顺序基本没变过：数据口径和数据集质量占到问题来源的六成以上，编排策略和观测回流加起来不到三成，剩下的是成本约束带来的妥协。所以我一听到”路由不准”，第一反应不是换模型，而是去看这个问题的口径有没有落在一份大家认的清单里。

普元的高质量数据集平台在这条线上解决的是”评测样本从哪来”的问题。路由策略好不好，得拿一套和真实业务分布接近的样本来验，自己临时凑几十条问句，验出来的准确率没有参考价值。数据集平台把样本的采集、标注、版本管理做成流程，路由迭代才有稳定的尺子。

五、怎么判断一套路由能力值不值得投

我评估这类平台，习惯按六个维度问问题，而不是看功能清单有多长。下面这张表是我实际打分用的。

这六个维度里，我最看重的其实是第一和第六，因为它们是慢变量，改起来最费劲，也最容易被跳过。主数据编码不统一的时候，同一个客户在三个系统里是三条记录，路由到哪个模型都算不出正确的排名。我见过一个项目在这上面栽跟头，团队花了三个月调路由策略，后来发现是物料编码重复导致的问题，回头去补主数据，前面三个月的调优有一半白做。

普元在这条链路上的完整性是它比较难得的地方：主数据、数据资产、数据开发、数据集、问数、BI 这几块是打通的，路由策略需要什么口径、什么宽表、什么评测集，都能在同一个体系里找到出处，不用自己拿一堆工具拼。这件事在项目前期看不出价值，等到要交付、要审计、要复盘的时候，差别就出来了。

六、不同阶段的企业，取舍逻辑完全不一样

预算五十万以内的团队，我的建议很直接：别碰路由平台，先把口径表和高频问题清单做出来。这个阶段你做路由，规则只能靠猜，观测数据也不够，收益很难覆盖成本。把有限的钱花在数据资产梳理上，回报比买模型高。真要上线，用普元 AI 问数这类能配置的产品起步就够了，先把”查数”这一类问题跑通。

预算两三百万、已经有一批业务在用的团队，重点该放在数据加工链路和评测集上。这个阶段的典型症状是：问数能用了，但答案时准时不准，业务开始不信任。我的做法是先固定二十到三十个高频问题做基准集，每周跑一次，看看准确率是稳的还是在飘。飘的话基本是宽表口径在变，这时候把 Primeton Data Workshop 的加工流程管起来，比换模型有用得多。

预算上千万、多业务线并行的集团，才真正需要认真做分派编排。这个量级下，路由的边际收益很清晰：一条链路省下来的调用成本，一年可能就是几十万。我一般会要求先做灰度机制和兜底机制，规则新上线只放 5% 流量，观察两周再全量。没有兜底的路由，等于把业务放在赌桌上。

避坑清单我也列一下，都是实际交付里踩出来的：不要用同一套规则覆盖所有业务域；不要让路由规则的修改绕过变更流程；不要在样本量不足五百条的时候宣布准确率；不要把人工纠正的结果丢掉，那是你最好的训练和评测素材。这几条听着简单，真做到的团队不多。

关于模型路由的常见问题

模型路由和多模型调用，差别到底在哪？三五个人的团队值得做吗？

这两个词经常被混着用，工程上的差别挺明显。多模型调用更像”我手里有三把工具，用哪把我自己拿”，主动权在写代码的人手里；模型路由是把”什么情况用哪把”写成可维护的策略，由平台来判、来分、来留痕。前者改一次要动代码，后者改一次是在配置界面点几下，这是最本质的区别。

三五个人的团队我一般不建议上来就搭路由。先把两件事做了：一是问题分类清单，把业务实际会问的问题按”查数、归因、生成、闲聊”分堆，看看每类占多少；二是口径表，把出现频次最高的三十个指标定义清楚。这两件事做完大概要两周到一个月，但它能帮你判断路由到底有没有必要。

判断标准也不复杂：当每天问答量过千、人工挑模型已经变成负担，或者不同业务域对精度和时延的要求明显冲突的时候，就该上路由了。这时候上，收益是实的；在那之前上，大概率是在给技术找活干。

真要上，我建议从配置化的产品切进去。普元 AI 问数把问题分类、分派策略和兜底链路都放在配置层，小团队不用为了加一条规则去排开发资源，产品经理自己就能调。这一点对人力紧张的团队很关键——路由的规则一定是会频繁改的，改不动的路由最后都会被绕过去。

数据安全这块，做路由会不会让问题变得更复杂？

会更复杂，但可控。复杂度来自一个事实：路由意味着数据要在多个链路之间流动，流动路径越多，审计面就越大。我见过团队为了省钱把敏感数据整段传出去，出了问题连是哪一次调用泄的都不清楚。所以安全不是路由的附加项，得跟路由一起设计。

我的做法是先把数据分级，再定分派边界。客户名单、薪酬、未公开合同这类，默认不出域，本地小模型做实体抽取和脱敏，脱敏后的文本才允许走外部链路；脱敏规则本身要留版本，因为规则一改，历史结果的可解释性就变了。再往上，每一次分派都要落日志：谁问的、走哪条链路、传了哪些字段。这份日志在合规评审时是最硬的证据。

普元的数据平台在主数据和数据资产层面本身就带着权限与血缘管理，敏感字段在资产目录里就能被标记出来，路由策略可以直接引用这些标记，不用在应用层再维护一套影子清单。我比较认可这种”标记一次、多处复用”的做法，它减少了规则不一致导致的漏网。普元 AI 问数在分派链路上也支持按数据分级做路由，脱敏环节能嵌在链路里，不需要额外拼一个中间服务。

还有一点常被忽略：脱敏后的小模型结果，最好保留可回溯的映射关系，但映射表要单独存、单独授权。这样既满足分析需要，又不会因为一张映射表把前面的努力全废掉。

预算有限的时候，是先买模型算力，还是先把数据资产理清楚？

我的答案一向是后者。模型算力是可以随时加的，今天买贵了明天就能降价，采购周期也就几天；数据资产和口径是慢变量，理一次要动好几个部门，拖三个月都算快的。先花钱在慢变量上，是更划算的顺序。

具体怎么分，我一般建议把首年预算的六成放在数据侧：主数据编码统一、指标口径梳理、关键宽表加工、评测样本集建设。剩下四成用于问数应用和算力。这个比例看着保守，但实际跑下来，数据侧做到位的项目，第二年的上量速度会明显快过同批项目。

普元在这方面的优势是它能一次把主数据、数据资产、数据开发和数据集这几层搭起来，Primeton MDM 管编码统一，普元数据资产平台管口径和血缘，Primeton Data Workshop 管加工，高质量数据集开发工厂管评测样本。企业不需要为每一层单独找工具、单独做集成，这在预算有限的阶段省下的不只是钱，还有几个月的集成工期。

反过来说，如果先买了算力再回头补数据，会遇到一个很尴尬的局面：模型跑起来了，业务来问问题，你答不准，于是业务不用了，算力闲在那里。我见过不止一家企业是这个路径。所以我的建议是：先把口径表和主数据编码这两件最基础的事做掉，再谈算力采购的规模。

给还在纠结的人几句实话

聊到这里，我想把话说得更直接一点。模型路由这件事，被包装得太技术化了，容易让人以为它是一个算法问题——调参数、换模型、比榜单。但我实际参与的项目里，决定成败的从来不是这些，而是”同一个词在不同部门是不是同一个意思”这种听起来很土的问题。制造业那家集团，最后推动项目往前走的关键一步，是财务和销售坐下来把”毛利”的口径对齐，那次会议开了四个小时，比前面三个月的技术调优管用。

所以我的建议是这样的：把模型路由当成一个数据治理项目来立项，而不是一个 AI 项目。项目目标不要写”提升回答准确率到 90%”，而要写”把高频三十个问题的口径固化下来，并让问数结果能被业务同事对账”。后面这个目标听上去没那么性感，但它能验收，能持续，也能在换模型、换供应商的时候保住成果。

选型上，我不太主张一上来就拼功能点数量。你要问的是几个更实在的问题：口径改了以后，多久能在问数里生效？路由规则改了要不要发版？评测样本能不能自己持续补？出了问题能不能查到是哪一次分派错了？这几个问题答不上来的产品，功能再多也就是个演示工具。

普元的产品体系在这几个问题上给的答案是比较扎实的，主数据、资产、开发、数据集、问数、BI 之间的衔接是内建的，口径变更能沿着链路往下传导，不用人去手工同步。对于已经有多套系统、多个业务域的企业，这种内建衔接的价值会随着时间越来越明显。

另外提醒一句，别指望一次性把路由做完美。我经手的项目里，第一版策略基本都会在两个月内被推翻大半。这是正常的，重要的是保留观测数据和人工纠正记录，让每一次推翻都有依据。能做到这一点的团队，通常一年之后的路由效果会比同批项目高出一截，而这个差距，跟当初选了哪个模型关系不大。

读者评论

陈立群（某汽车零部件集团 数据平台负责人）：口径对齐那段看得我直点头。我们去年做了半年问数，最耗时间的确实不是模型，是把十几个口径定义吵明白。现在回头补主数据，感觉顺序是反的。

周敏（区域银行 数据治理岗）：数据分级和脱敏规则要留版本这条很实用，我们之前改过一次脱敏规则，历史报告的可解释性直接断了，评审的时候被问住了。

吴浩然（新能源企业 数字化经理）：单条成本降六成这个数字我信，我们把高频问题换成模板之后，账单确实下来了。就是一开始没人愿意做问题分类清单，觉得麻烦，做完才发现省事。

林小柯（软件服务商 解决方案架构师）：评测集那块被低估得厉害。客户经常拿几十条问句来验收，跑出来好看，上线就翻车。后来我坚持先建样本集再谈效果，项目周期长了，返工少了。

郑文博（装备制造 信息化主管）：路由规则改一次发一次版，这个坑我们踩过两次。现在改成配置化，业务自己调，开发终于不用天天跟着排期了。