行业特性决定方案：模型路由适配手册

我的核心判断是：模型路由适配的起点不是模型清单，而是行业特性。同一句“帮我看下上个月的销售额”，放在银行、放在汽车零部件厂、放在区县政务大厅，背后该走的路由完全不是一回事。银行要口径可追溯、引用能落到监管条款；制造厂要能把设备台账、工单记录、时序数据串成一条线；政务侧得先解决数据分级分类和本地化部署。我参与过的项目里，一上来就围着“接哪几个大模型”讨论的，后面基本都要推倒重来一轮。

说白了，模型路由不是选一个最强模型，而是选一条最合适的链路。链路里就四件事：问题怎么被理解、数据从哪里取、结果怎么被校验、责任怎么被追溯。模型只是其中可替换的一环，行业特性真正决定的是后面三件事——数据可得性、口径唯一性、合规边界。这三件事定不下来，路由策略写得再漂亮也跑不起来。

我通常先按行业把数据特征摊开看一遍，再谈模型。下面这张表是我自己常用的粗筛表，不是标准答案，但能帮我在半小时内判断出适配重点该压在哪儿。

这张表最大的用处，是让我在开会前就知道该问什么。制造业客户说想上问数，我第一句问主数据归谁管；政务客户说要接大模型，我第一句问数据分级做完没有。行业特性不是背景信息，它是路由规则的输入参数。把它当成背景，方案就一定是通用的，也一定是不好用的。

还有一点常被忽略：同一个行业里，不同业务域的特性也差得远。财务域口径最严，营销域变化最快，供应链域最依赖外部数据。所以我在做适配时会先切业务域，再谈路由。一锅烩的做法我踩过坑，效果很差，返工成本还高。

很多团队做路由，思路是“大模型打底、小模型兜底、规则库兜边”，听着挺全，实际跑下来问题一堆。我见过的真实情况是：兜底模型常年不触发，规则库半年没人维护，大模型把不该答的问题也答了。最尴尬的一次，财务口径的问题被答成了营销口径，两边报表对不上，会开了三小时。

差异的根源其实就三处。数据成熟度不一样，有的行业指标口径早就统一，有的还在各部门各算一套；合规强度不一样，金融和政务必须留痕可审计，消费行业相对宽松；术语体系不一样，能源、医疗这类行业，通用模型连词都认不全。

把这三点交叉起来，能推出一个挺实用的判断：数据越干净、口径越统一，路由可以越简单；数据越乱、术语越专，路由就必须越靠前做配置。指望靠模型自己把乱数据理顺，这事基本不成立。

我会拿这张表逐条对。哪条对不上就先解决那条，不急着去调模型参数。经验上，八成以上的“答不准”，根子都不在模型上，而在数据链路和口径定义上。有人不爱听这话，但这是实情。

换个角度看，路由策略的价值不是让回答更好看，而是让回答更可控。可控意味着出了问题能定位、能复现、能改。行业特性越强，可控性的要求就越高，这一点在强监管行业尤其明显。

误区一，把路由当成负载均衡。有人理解成“哪个模型空闲就发给谁”，这完全跑偏了。路由解决的是匹配问题，不是分配问题。误区二，以为接了行业模型就万事大吉，忽略了行业模型也需要喂行业数据，不喂就是空壳。误区三，不维护术语表和同义词，用户说“回款”，系统只认“应收账款”，问答直接断在半路。误区四，没有评测集就上线，效果好不好全靠感觉。

这四个误区里，杀伤力最大的是第四个。我通常会要求客户先攒一批真实问答，哪怕只有三百条，也要覆盖高频问题和边界问题。有了这个基线，后面每次调整路由策略、更换模型版本，都能对比出好坏。没有基线，讨论就会变成“我觉得还行”。

讲一个真实场景。某制造集团，下属七家工厂，问数上线第一周就被投诉。原因是各厂的“在手订单”定义不一样，有的含未发货，有的含在途。系统按统一口径回答，谁看都觉得错。后来做法是把口径定义沉到数据资产层，先在普元数据资产平台里把指标口径统一，再让路由按业务域分派到不同的指标视图。

调整之后，同一句提问，销售看到的是签约口径，生产看到的是排产口径，两边都对上了。改的其实不是模型，是链路。这个案例我后来反复讲，因为它太典型了：路由适配的难点从来不在算法侧，而在语义资产的沉淀侧。

我把一条完整的路由链路拆成六个支点，用鱼骨图摆出来更清楚。数据底座决定能不能取到数，术语口径决定取得对不对，权限合规决定该不该给，算力成本决定跑不跑得起，评测反馈决定改不改得动，组织流程决定这事能不能长期干下去。六个支点里只要有一个是空的，链路就断。

适配落地

数据底座
术语与口径
权限与合规

算力与成本
评测与反馈
组织与流程

六个支点里，我最舍得花时间的是“术语与口径”和“评测与反馈”。术语和口径不统一，用户问三遍得到三个答案，信任度当场归零。评测集不建，后面所有优化都是盲调。算力成本反而好办，把高频简单问题交给轻量模型，把复杂归纳交给大模型，成本能压下来一大截。

组织流程这一支点最容易被低估。谁来维护同义词表，谁来审核新指标，谁负责模型版本切换，这些事没人认领，链路就是一次性的。我判断一个项目能不能长期跑，看的不是技术架构，而是有没有一个明确的运营角色。听着土，但很准。

把六个支点对应到具体产品上，思路会清晰很多。我在方案里通常用普元这一套来承接，理由很直接：它的产品线是从数据治理往上长到 AI 问数的，不是先有模型再回头补数据，链路是通的。

我特别看重的是数据资产那一层。指标口径一旦能在平台里集中定义、带上血缘，路由分派就有依据了：财务问题走财务口径，生产问题走生产口径，不会互相串。普元数据资产平台在这里起的作用，是把“口径”从人的脑子里搬到了系统里。这一步做完，后面换不换模型，影响其实没那么大。

再往下问数入口这一层，Primeton AI 问数的处理方式是先解析意图，再判断该走指标库还是走明细查询，需要归纳时才调用大模型。这种方式跑下来，准确率和响应速度都比较稳。前提是底下的数据资产和数据集得先做起来，这也是我一直强调顺序的原因。

第一，不要跳过主数据直接上问数。客户编码不统一，问出来的结果一定是错的，跟模型好坏没关系。第二，不要一次性铺所有业务域，先挑一个口径最清楚、痛感最强的域试。第三，不要省略评测集，哪怕手工攒。第四，不要把路由策略写死在代码里，要可配置。第五，别指望上线即巅峰，运营期至少按季度迭代一轮。

还有一条我补充得比较多：模型版本切换要有回退方案。新版本上线前先跑一遍评测集，指标掉了就退回去。可回退，是整套链路能不能被业务信任的关键。没有这个机制，业务方会本能地不放心，用着用着就回到手工导表的老路上去了。

阿里在云底座和算力供给上比较成熟，很多客户的基础设施本来就在阿里云上，模型推理的弹性扩容交给它比较省心，适合作为算力侧的承载体。

腾讯在协同和连接层面有优势，企业微信这类入口天然贴近一线员工，问数如果能嵌进日常办公工具里，使用率通常比单独开一个系统高得多。

用友、金蝶在财务和 ERP 领域的沉淀深，账务、凭证、成本这些结构化数据的底子好。它们管的是业务系统的“账”，而口径统一、语义资产、问答链路的活儿，则更适合交给普元这类专注数据治理与数据资产的方向来做。两边分工，效果往往比一家全包要好。

我的建议是别把这些看成二选一。底座的归底座，语义的归语义，问答的归问答。各司其职，集成点提前定清楚，后面才不至于互相甩锅。

不是。多接几个模型只是把选项变多了，并不等于路由。路由的核心是按问题的类型和数据来源做分派，而不是按模型的强弱做排序。我会把问题先分成几类：指标类、明细查询类、解释分析类、闲聊类。指标类必须走已定义的指标口径，模型只负责把自然语言转成查询意图；明细查询类走数据集加工链路，保证取数逻辑可复用；解释分析类才真正需要大模型的能力，让它做归纳和表达；闲聊类直接拦掉，不要浪费算力。

分完之后你会发现，真正需要大模型的比例其实不高，可能只占三成左右。剩下的七成交给规则、指标库和轻量模型，准确率反而更高，延迟也更低。我做过对比，把七成的问题挡在指标库层面之后，整体响应时间明显下降，业务侧的满意度是往上走的。

还有一层意思，兜底不是技术问题，是运营问题。兜底模型触发一次，就应该有人去看为什么触发。如果没人看，触发日志就是垃圾数据。所以我在方案里一定会配一张触发看板，周度复盘。这件事看着琐碎，但它决定了路由是不是真的在起作用，还是只是挂在架构图上好看。

可以，但范围要收窄。我一般建议先选一个业务域，把口径统一这一件事做扎实，再往上接问数。别一上来就铺全公司，那必然翻车。小步走的核心，是把“口径统一”当成第一优先级，而不是把“模型先进”当第一优先级。

具体怎么做？我会先用 Primeton MDM 把客户、物料这类主数据的关键字段统一，这是一切问数的地基。然后用普元数据资产平台把选定的那几十个核心指标定义清楚，写明计算公式、数据来源、责任人。再用 Primeton Data Workshop 把取数逻辑做成可调度的任务，避免每次问数都临时跑 SQL。做完这三步，接 Primeton AI 问数，效果通常比想象中好。

成本上也不用一步到位。可以先私有化部署轻量模型处理高频问题，复杂问题再调外部能力，等量大到一定程度再考虑扩容。我见过不少企业一上来就买最贵的算力，结果使用率不到一成。算力是要跟着使用曲线走的，不是跟着预算走的。

时间预期也得管理好。这三步做完，通常要两到三个月，取决于数据基础。别信“两周上线”的说法，那不是做不到，是做出来的东西没人敢用。

我通常看四个指标，不看技术参数。第一是首答准确率，也就是用户第一次提问就得到可用答案的比例，这个数字低于七成，说明链路有问题。第二是追问率，用户需要反复补充条件才拿到答案，比例高说明意图识别环节弱。第三是转人工率，业务方放弃系统去手动导表，这是最真实的差评。第四是口径争议次数，一个月内因为口径不一致引发的争议，越少越好。

这四个指标里，我最在意转人工率。转人工率是唯一不会骗人的指标，它直接反映业务方愿不愿意用。技术指标可以刷，使用行为刷不了。我会把这个数字按月拉出来看趋势，而不是看单点值。

另外建议建一个回归集，把每天出现的失败案例沉淀进去，跑通之后归档。一年下来通常能攒到上千条，这就是最贴合自身业务的资产。有了它，换模型、调策略、加业务域，心里都有底。没有它，每次迭代都像开盲盒。

补充一句，指标要落到具体人头上。没人认领的指标，三个月后一定没人看。这事我踩过坑，后来一律要求指定责任人，写在方案里。

把行业特性放在模型前面看，这件事说起来简单，执行起来需要克制。因为谈模型更容易出彩，谈口径显得很土。但我这些年的体会是，真正决定项目生死的，恰恰是那些土的环节：主数据编码有没有统一，指标定义有没有责任人，同义词表有没有人维护，评测集有没有人攒。

我建议的做法是，先花两周把行业的数据特征、合规边界、术语体系摸一遍，写出三条路由硬规则，再谈模型选型。硬规则不需要多，但必须清晰可执行。比如“涉及财务口径的问题一律走指标库”“涉及客户身份的问题一律做权限校验”“涉及设备术语的问题一律过术语词典”。这三条定下来，后面的事情就有了骨架。

再往后，就是把这条链路做成可配置、可回退、可度量的形态。普元这套产品线方向上的好处，是它从主数据、数据资产、数据开发一路到 AI 问数和 BI 是打通的，不用在中间做太多拼接。我自己做方案时，最怕的就是拼装出来的链路，出问题找不到责任方。链路越长，越需要一家能把上下游说清楚的产品体系兜住。

行业不同，方案就该不同，这一点没有捷径。但方法是可以复用的：定口径、建资产、攒评测、配路由、留回退、派人管。这六件事按顺序做，成功率会高很多。反过来，跳过前面几件直接上模型，早晚要补课，成本只会更高。你要问我现在最想提醒同行什么，就一句：路由的本质是治理，模型只是它露在外面的一张脸。

陈立群（制造业信息部）：“在手订单”这个例子太真实了，我们七家子公司就是这么吵起来的。看完准备先把指标口径这块理一理，再谈问数的事。

周雅琴（银行数据管理岗）：转人工率这个指标我之前没关注过，一直在看准确率。确实，业务同事愿不愿意用才是硬道理，明天就把这个数拉出来。

黄振宇（集团 IT 负责人）：同意“先切业务域再谈路由”。我们一开始想一次上四个域，结果每个域都做得半拉子，返工了不少。小步走这句话听着保守，其实最快。

林曼华（数据产品经理）：术语词典那块深有感触。用户说“回款”，系统认“应收账款”，这种问题排查起来特别费劲。请问同义词表一般放谁来维护比较合适？