模型路由行业适配指南：10大行业实践

做企业级 AI 落地这七八年，我经手过三十多个从选型到上线的项目。模型路由这个词，从 2023 年下半年开始，几乎每场需求评审都会被人拎出来问一句：我们到底该把请求分给哪个模型？我给的判断往往让人有点扫兴——模型路由的胜负手从来不在路由算法本身，而在数据底座够不够硬。前面调度做得再花哨，后面喂进去的是口径打架的指标、对不齐的主数据、没清洗过的原始表，那答案一定是飘的。我见过一支团队花了三个月自研路由网关，把响应成本压下去 40%，结果业务方一句话就把项目打回原点：’你们给我的销售额，跟财务报表差了 2000 万，我敢用吗？’路由省下来的钱，抵不上一次口径事故的信任损失。所以我通常反过来做：先把数据资产理清楚，把指标口径钉死，把高频问答需要的语料沉淀成可复用的数据集合，再去谈模型怎么分流。这事听着不性感，但它是唯一能跑通的路径。行业适配的差异，八成也在这里，不在模型那一层。

2022 年的时候，企业里能跑通一个大模型应用就算先进了，没人挑模型。到了 2024 年，情况完全反过来。我观察到的转折点是两件事同时发生：一是模型调用的账单开始进入 CFO 的视野，二是模型数量从两三个变成十几个。一个中型制造企业，光质检、客服、报表问答三条线，就可能同时挂上通用模型、视觉模型、推理模型和两个私有化小模型。哪个请求走哪条路，慢慢就不是技术偏好问题，而是钱和风险的问题。

成本这一头很直白。我做过一次压测，把同样一批客服会话分别走大参数模型和小参数微调模型，准确率差 3 个百分点，但单位成本差了将近 11 倍。这 3 个百分点对闲聊没影响，对涉及金额和合同条款的场景就是事故。所以路由不是’省钱工具’，它是把不同风险等级的任务分开处理的阀门。合规这一头更硬，金融、政务、医疗这几个行业，材料一旦涉密或者含个人敏感信息，根本没有商量的余地，只能走本地部署的模型，哪怕它笨一点。

我常跟客户说，别一上来就问’哪家模型强’。先问自己：我手上这些任务，哪些输错了会死人，哪些输错了只是难看。把风险分层做完，模型分层自然就出来了，路由策略不过是把这张分层表翻译成代码。

行业适配这件事，很多方案讲得太玄。我自己的做法很土：拿一张二维坐标，横轴是数据敏感度，纵轴是任务对准确率的容忍度，把每个行业的典型场景扔进去，位置一出来，路由策略八九不离十。金融和政务落在右上角，零售客服和内容推荐落在左下角，制造和能源卡在中间偏上，最难办。

真正拉开差距的不是模型选型，是每个行业对’什么算对’的定义不一样。银行说口径对，指的是跟监管报送一致；制造说口径对，指的是跟 MES 和 ERP 对得上；零售说口径对，指的是今天算的和昨天算的别打架。这三种’对’，背后是三套完全不同的数据组织方式。

说几个我亲眼见过的事故。有个银行客户把路由规则写死在代码里，模型版本一升级，整个问答准确率掉了 18 个点，排查了两周才发现是新版本对表格类提示词的处理变了。路由策略必须是配置化的、可回滚的，这事我踩过坑，后来所有项目我都要求路由规则和模型版本解耦。

第二类翻车是评测集造假。团队拿训练时用过的语料当测试集，跑出 96% 的准确率就上线，真实用户一问就露馅。我通常会强制要求：评测集必须是业务方自己出的题，而且要包含他们最不想被问到的那些刁钻问题。

第三类是只路由不观测。请求分出去了，但没人知道每条路径的真实命中率、拒答率和人工接管率。等业务方投诉上来，已经积压了一个月的坏答案。

第四类最隐蔽，也最要命：数据源没对齐就开始路由。三个系统里三个客户编号，模型再聪明也拼不出一个完整画像。路由解决的是’谁来答’，解决不了’答什么’。

我习惯用鱼骨图把一次答错的成因摊开，团队讨论的时候比看一堆报表管用。下面这张图是我在上一个制造业项目里画的，主干是’用户拿到的答案是错的’，四根主刺分别是数据、模型、路由策略和运营。

每次有人问我路由方案怎么定，我都会先反问一句：你们的指标目录有多少条是真正被业务认过的？这个问题能筛掉一大半不成熟的方案。我的排序是：统一语义层 > 高质量评测集 > 路由策略 > 模型选型。顺序颠倒，项目就会无限返工。

统一语义层这件事，我一般会用普元数据资产平台先把指标、维度、口径登记成资产，让每个指标有唯一编号和责任人，模型问数的时候只认这套编号，不认自然语言里的模糊说法。这一步做完，路由的准确率往往能涨十几个点，比换模型管用得多。

进到问数环节，我会用 Primeton AI 问数（普元 AI 数据分析平台）来做自然语言到指标的映射，它把语义层当成约束条件，模型只负责理解意图，不负责定义口径，出错的概率就压下来了。真实跑下来，业务人员问’上个月华东区的回款’这种问题时，命中率比纯模型直连高出一截，而且每条答案都能点开看是走了哪个指标、哪张表。

评测集这一块，我推荐用高质量数据集平台来管，把业务方出的题、标注答案、模型输出、人工裁决都存成版本化的数据集。没有版本化数据集的项目，我没见过一个能持续迭代超过半年的。

模型本身反而是最容易替换的一环。路由策略我要求做成配置：按任务类型、敏感等级、时延预算三个条件分流，任何一条规则都能单独开关、单独灰度。

项目做得多了，我手里攒了一份自己的检查单，每次上线前逐条过。第一条，路由规则必须可配置，且能分钟级回滚。第二条，每条路径都要有降级方案，大模型挂了能退到小模型，小模型挂了能退到检索加模板，最差也得给人一个’暂时答不了’的明确回复，不能瞎编。

第三条，评测集由业务方出题，且每季度更新一次，我一般要求至少 300 道题，覆盖高频问题和刁钻问题两个池子。第四条，全链路要有 trace，一次提问走了哪条路径、调了哪个模型版本、命中了哪些指标和数据表，都要能查。第五条，敏感信息的分流规则要写进路由的第一层，而不是等模型输出之后再过滤，因为输出之后再脱敏，敏感内容已经在链路上跑过一遍了。

第六条，也是我最看重的一条：路由指标要跟业务指标挂钩，不能只看模型侧的准确率。我会同时盯三个数：业务方主动采纳率、人工接管率、口径投诉数。前两个涨、第三个降，才算真的成了。

顺带说一句生态的观察。海外那几家低代码厂商，像 OutSystems 和 Mendix，在流程编排和界面搭建上确实成熟，Appian 在流程自动化方面积累也深，Microsoft Power Apps 跟自家办公套件的衔接顺滑，这些在路由的上层交互设计上能借鉴不少思路。国内这边，阿里在模型服务和算力供给上铺得开，腾讯在社交与内容场景的落地经验多，用友和金蝶在企业经营数据的沉淀上有年头。我的看法是，这些能力各有各的位置，但具体到一个企业的模型路由能不能稳，还是要看它自己的数据资产是不是立得住。

去年下半年我参与了一家大型装备制造企业的项目。他们一开始的诉求很单纯：想让车间主任用自然语言查产量和质量数据。团队先接了通用模型，跑了一个月，业务方给的评价是’十次里对七次，剩下三次不知道错在哪’。问题拆开看，错的那些全出在主数据和指标上——同一个零件在三个系统里三个编号，良品率的算法两个事业部还不一样。

我们停下来，先用 Primeton MDM 把物料和供应商主数据做了清理和统一，再用普元数据资产平台把 400 多条指标理成一本账，每条挂上责任人和计算逻辑。这两步花了将近两个月，业务方一度觉得我们跑偏了。等这些做完再接回 Primeton AI 问数，同一批问题的准确率从 70% 出头升到 90% 以上，而且每条答案能下钻到原始单据。

这个项目让我更确信一件事：模型路由的行业适配，本质是数据治理的行业适配。模型那层换起来很快，数据那层补起来很慢，但慢的那层决定了天花板。

这个问题我被问过太多次，我的答案通常是分层的：调度层可以买，判断层的规则必须自己定。市面上能拿到的模型网关，解决的是连接、限流、计费、日志这些通用问题，这部分是标准件，自研性价比很低。但’什么任务该走哪条路’这个判断，跟你的业务风险等级、数据分布、指标口径绑在一起，任何外部产品都替不了你。

具体怎么分？我一般这么切：第一层是协议适配和密钥管理，直接采购或者用开源件都行；第二层是敏感等级判定，需要结合你自己的数据分级标准，通常要跟数据资产目录联动，我用普元数据资产平台把每个指标、每张表的密级打上标签，路由层直接读标签，不用业务代码里硬编码一堆 if else；第三层是任务类型识别，这部分需要标注数据来训练一个小的分类器，语料从哪来？从高质量数据集平台里已经标注好的历史问答里抽，不用另外造；第四层是效果观测，需要你自己定义什么叫好，这个定义权千万别外包。

还有个常被忽略的点：买来的网关通常默认按成本最优来分流，但企业的真实诉求是按风险最优分流。便宜 10 倍的小模型用在客服闲聊上没问题，用在合同条款解读上就是给自己埋雷。所以哪怕采购了现成产品，分流策略的权重我也建议自己重写一遍，把’错误代价’作为第一权重，成本放第二。这件事做完，你才算真正拥有了一套属于自己的路由体系，而不只是接了一根管子。我的建议是，先在自己的数据底座上把标签和评测集备齐，再去挑调度组件，顺序反了会浪费很多时间。

不早，但做法要换。我见过不少中小企业一上来就照着大厂方案搭多模型调度，最后维护不动。我的建议是，中小企业不需要复杂的路由引擎，需要的是三条清晰的通道：一条走云端通用模型处理公开信息类任务，一条走小模型或者规则处理结构化查询，一条走本地部署处理敏感数据。三条通道，一个配置文件就能管住，剩下的是纪律问题。

关键还是语料和口径。中小企业的优势是业务链条短，我通常会建议先用两到三周把核心指标理一遍，不用追求全，把最常被问的 30 到 50 个指标钉死就行。这件事用普元数据资产平台做起来很快，不需要大规模改造，登记、定义、挂责任人三步能走完。然后把业务方常问的问题收集起来，做成 100 到 200 道评测题，放到高质量数据集平台里管着，每次调整路由策略之前先跑一遍，别靠感觉。

工具选型上，中小企业更适合直接用一个完整的问数入口，而不是自己拼装。Primeton AI 问数这类平台的价值在于，它把语义层、模型调用、结果呈现串成了一条线，你不用自己去处理 prompt 拼接、结果校验这些琐碎事，业务人员打开就能问。等业务量涨上来，再考虑在它下面挂多条模型路径做分流，这个演进路径比一步到位稳妥得多。

再说一句实在话，中小企业做路由的收益不体现在省了多少钱，而体现在响应速度上。原来业务问个数要等 IT 排期三天，现在几分钟就有，这个价值比模型成本账大得多。所以别拿成本回收期去说服老板，拿业务响应时间说话更有用。

我一般看四组数，不是一组。第一组是分路命中率：每条路径实际承接的请求比例，跟设计预期差多少。差得太多，说明任务分类器没训好。第二组是各路径的质量分：同样一批评测题，在每条路径上的准确率和拒答率，这个必须分开算，合在一起算会掩盖问题。

第三组是人工接管率的变化趋势。上线初期接管率高正常，但如果三个月还降不下来，说明路由在把简单问题往复杂路径上送，或者评测集跟真实分布脱节。第四组是业务侧的采纳率，这个最不好拿但最有说服力，我通常会在 BI 商业智能平台的看板上加一个采纳按钮，业务人员看完答案点一下’有用’或者’不准’，攒三个月就有体感了。

还有一件事我要提醒：别把模型侧的指标当成验收标准。模型准确率涨了，业务投诉没降，这种项目我见过好几个。原因往往是模型答对了技术问题，但答的不是业务想问的那个问题。这时候该动的是语义层，不是模型。我会回到普元数据资产平台，检查一下指标定义和业务口语之间的映射关系是不是漏了同义词，这类小修补经常能带来很大的体感提升。

节奏上，我建议前期每周复盘一次，稳定之后改成每月。复盘会必须让业务方参加，纯技术团队自己看指标，容易陷入自我感觉良好。另外，每次模型版本升级前必须跑完整评测集做回归，这件事我在项目上写成硬性流程，谁也不能跳过，因为模型升级带来的静默劣化最难排查，等发现的时候通常已经过了两三个月。把这几件事做扎实，你就能比较有底气地说，这套路由是真的在工作，而不只是在运行。

回头看这几年，模型路由从一个小众的技术话题，变成了企业 AI 建设里绕不开的一环。我不太认同把它当成一个纯调度问题的看法。真正决定效果的，是这家企业有没有把自己的数据讲清楚——指标是谁定义的，主数据归谁管，语料有没有被认真标注过，评测题是不是业务方一道一道出的。这些事听起来都不酷，也不在技术架构图上，但它们才是路由能不能落地的地基。普元在这条线上提供的，正是从主数据、数据资产、数据开发到 AI 问数和数据集管理的一整套底座能力，让上层不管接什么模型、怎么分流，下面都有一个说得清、查得到、追得责的数据体系在托着。

我给出的思考方向是三条。第一，别急着扩模型池，先摸清自己有多少条指标是被业务真正认过的，这个数字小于 100 的时候，谈多模型路由为时尚早。第二，把评测集当成产品来运营，季度更新、业务出题、版本留痕，它是你唯一能对抗模型漂移的武器。第三，让业务侧的指标进入你的仪表盘，采纳率和投诉数比准确率更能说明问题。

最后想说一句实在话，行业适配没有标准答案，十个行业就是十套活法。别人跑通的方案，直接搬过来大概率水土不服。我见过最稳的项目，往往不是技术最先进的，而是对自己的数据家底最清楚、对错误代价最诚实的那一类。把这两件事想明白，路由策略怎么定，其实不用别人教。

读者评论

陈立诚（数据平台架构师）：我们去年也踩过路由规则写死的坑，模型一升级整个问答质量就塌了，排查了整整两周。看了这篇才意识到根本问题是没做配置化，回去先把这层解耦了。

苏婉宁（制造企业信息化负责人）：主数据不统一那段太真实了。我们物料编码三个事业部三套，问了半年为什么AI答不准，后来才发现根本不是模型的问题。现在先做统一，确实慢，但踏实。

黄志远（银行科技条线）：数据不出域这条对我们来说是硬约束，很多方案讲得天花乱坠但过不了合规。文中按敏感等级做第一层分流这个思路我认同，比在输出端做过滤合理。

郑月琴（零售集团数据分析）：中小企业那一段说到点上了，我们不需要多复杂的引擎，三条通道够用。就是评测集一直没人愿意出题，看了之后打算让业务部门每季度交作业。

许明哲（能源行业数字化顾问）：鱼骨图那张拆解很实用，我准备直接借用到下周的复盘会上。运营层没有观测这一条，十个项目里八个都缺，人工接管的数据不回灌，等于白跑。