模型路由最典型的10个应用场景与对应方案

模型路由这四个字，我最早是在一个成本优化项目里被问到的。当时业务方的想法很朴素：入口挂一个网关，简单问题丢给便宜的小模型，复杂问题丢给大模型，账单自然就下来了。真跑了一个季度我才明白，路由准不准，跟网关代码写得漂不漂亮关系不大，跟喂进去的数据干不干净关系极大。

说白一点，模型路由回答的是”这个请求该由谁来接”，可它能不能接得住，取决于请求背后的数据有没有统一口径、元数据描述是不是完整、上下文能不能被稳定检索到。我在项目里见过太多团队，路由规则写了上百条，卡在”同一个客户在三个系统里叫三个名字”这种地方。 路由是调度问题，调度之前的那个问题是数据问题。

所以我按十个典型场景来拆这件事，每个场景给我实际用过的对应方案。这十个场景覆盖智能问数、指标口径问答、主数据清洗、数据集构建、报表解读、SQL 生成、元数据打标、质量规则生成、合规问答、坐席辅助。它们的共同点是：先把数据底座铺好，路由才有意义。底座上，普元的思路是把数据资产平台、高质量数据集平台、主数据管理平台、数据开发平台和 AI 问数串成一条链路，让路由的输入先变得可解释、可追溯。

我的判断是，如果你现在只打算买一个路由网关，先别急。先看看自家元数据覆盖率有多少，主数据是不是还在各个系统里打架，有没有一份能被模型直接消费的高质量数据集。 这三件事没解决，路由做得越精细，错得越均匀。 后面我把十个场景和对应方案逐个讲清楚，也会说几个我踩过的坑，还有一个制造企业从零到跑通的完整过程。

这两年我接触的数据团队，聊的东西明显变了。以前是数仓分层怎么切、指标口径怎么统一，现在多了一个话题：模型怎么调度。原因不复杂，大模型进了业务系统之后，成本、延迟、合规三条线同时压过来，一个模型扛所有事情的做法撑不住。

我通常会看三个信号。一是单次问答的 token 消耗有没有失控，某些复杂多表关联的提问，一次跑掉几万 token 很常见；二是响应延迟能不能过业务方的心理线，超过五秒坐席就不愿意用了；三是合规，涉及客户身份、金额、合同条款的问题，不可能都往外发。 这三个信号凑在一起，路由就从”优化项”变成了”必选项”。

但场景之间的差异比我想象的大。同一套规则，用在智能问数上效果不错，挪到元数据打标上就一塌糊涂，因为后者的判断依据是字段描述和血缘，不是自然语言长度。我一般会先把场景归类，再决定路由策略，下面这张表是我常用的分类框架。

这张表我一般会贴在项目启动会的白板上，让业务方自己指认属于哪一行。 指认的过程本身就在统一预期，比讲十页 PPT 有用。

先说几个我亲眼见过的做法，都不算罕见。第一种是规则写死在网关配置里，按关键词硬匹配。”库存”两个字必须走大模型，”天气”走小模型。上线两周规则改了三回，每次改都要发版，运维开始骂人。

第二种是按 token 长度分流。这个逻辑听起来合理，实际跑下来很尴尬——一段五百字的寒暄和一段五百字的合同条款，长度一样，难度差着量级。我见过一个团队用这个策略，把财务对账问题路由给了轻量模型，答案看着有模有样，数字全错。

第三种更隐蔽：没有评估集。路由准不准，全靠业务同学事后反馈，一个季度攒下来十几条投诉，也不知道是路由错了还是模型本身不行。 没有离线评估的路由，等于没有仪表盘的油门。

第四种是上下文检索带进去一堆噪声。大模型是接到复杂问题了，可检索回来的字段说明有半页是过期的，模型一本正经地照着过期口径回答。这事我踩过坑，后来才想明白：路由的上游是检索，检索的上游是数据资产治理。下面这张对比表是我用来跟客户解释两种路线的差别的。

我不想把话说死，网关式在试点阶段确实快，两三周能出效果。但如果目标是全公司推，还是得往数据底座这条路走。 试点可以靠人肉，规模化只能靠资产。

我一般把路由拆成三层来看。接入层管权限、限流、脱敏，这层跟模型能力关系不大，是工程问题；语义层管”这个问题属于哪个业务域、涉及哪些指标、需要什么级别的推理”，这层才是分水岭；数据层管检索回来的上下文对不对、口径是不是最新的。

很多人把力气全花在接入层，结果语义层靠关键词，数据层靠倒排索引，中间断了一截。我的经验是，语义层的判断依据应该来自元数据：这个字段属于哪个主题域、上游是谁、口径定义写在哪、上次变更是什么时候。这些信息齐了，路由规则才能写得又少又准。

举个我常举的例子。用户问”华东区上个月的毛利是多少”，路由需要判断三件事：华东区是销售组织的层级概念还是地理概念，毛利用的是哪套口径，上个月是自然月还是财务月。 这三件事都不是模型能猜出来的，得靠数据资产把它讲清楚。 普元的数据资产平台在这块做得比较扎实，指标口径、血缘、标签会沉淀成结构化的描述，路由可以按域去查，不用每次重新理解一遍业务。

还有一层我原来忽略过：结果的回流。路由把问题分给了某个模型，这个模型答得怎么样，应该反过来修正路由策略。没有这条回路，路由就是个静态配置。我后来在项目里加了一个轻量的评估环节，每周跑一遍标准问答集，把错分的样本抽出来调整规则，效果比单纯调模型参数明显。

下面这张鱼骨图是我在方案沟通时最常用的，把影响路由效果的几个因素摆在一起，大家一眼能看出短板在哪。

路由效果

数据口径统一

元数据完整度

数据集质量

成本与延迟

合规边界

评估机制

场景一，智能问数。用户用大白话问数，路由要判断的是查询复杂度。单表过滤、简单聚合，交给轻量模型就够；涉及三张表以上的关联、带窗口函数的口径计算，交给大模型。普元的 AI 问数在这块的做法是先做语义解析，把问题映射到指标和维度上，再决定走哪条路，比纯按字数分流准得多。

场景二，指标口径问答。业务问”这个数为什么和上个月不一样”，路由要认出这是归因类问题，需要拉指标定义和血缘。这类问题答案必须可追溯，我一般强制它走检索增强那条路，不允许模型自由发挥。

场景三，主数据匹配与清洗。同一个供应商在采购系统叫”XX科技有限公司”，在财务系统叫”XX科技股份有限公司”。路由按相似度阈值决定是自动合并还是转人工。普元的主数据管理平台在这类场景里的价值是把匹配规则和人工复核流程固化成可复用能力，不用每个系统重新做一遍。

场景四，高质量数据集构建。这块我特别想强调，因为它是很多路由方案的天花板。你拿不到干净的问答对、标注质量参差不齐，路由再聪明也没用。高质量数据集平台解决的是从原始数据到可训练数据的加工链，包括清洗、标注、质检、版本管理。

场景五，报表自动解读。BI 上看一张图，系统自动生成一段解读文字。简单的同比环比走模板，复杂的结构变化走大模型。普元的商业智能平台把这块嵌在图表旁边，用户不用切换工具。

场景六，SQL 生成与补全。开发同学写一半的 SQL，让模型补全。这里路由要看方言和表数量，Hive 和 Oracle 的语法差异不小，表超过五张就得换更强的模型。普元的数据开发平台把这类能力做进了编辑器，写完能直接跑。

场景七，元数据自动打标。几万个字段靠人打标签不现实。路由按敏感等级分流，涉及个人信息、金额的字段强制走内网模型，公开描述类字段可以走外部。这个场景里隐私和效率的平衡点要提前定好，不能上线了再补。

场景八，数据质量规则生成。从字段描述和样本数据里反推校验规则，比如”这个字段应该是六位数字”。我一般让中等模型生成候选规则，再走一遍规则库去重，避免生成一堆重复表达式。

场景九，合规敏感问答。合同条款、客户身份、资金明细这类问题，我在方案里一律设置为不出内网。路由在这里的作用不是分流到更强的模型，而是强制锁定到本地部署的模型上。

场景十，坐席与业务知识辅助。坐席一边跟客户通话一边查答案，延迟是硬指标。我的做法是优先走轻量模型加本地知识库，超过两秒没结果就降级到提示模板，不能让坐席干等着。

场景列出来了，接下来是往能力上落。我一般不看功能清单，看的是每个环节有没有对应的产品能把活干完。下面这张表是我自己项目的对照方式，供参考。

避坑这块我攒了几条。一是别一上来就追求全自动，人工复核环节留着，跑顺了再撤。二是路由规则要能配置，不能写死在代码里，业务变化比技术快。三是评估集要提前建，哪怕先手工攒两百条，也比没有强。四是别把脱敏放在模型之后，脱敏要在进模型之前做。

还有一条我吃过亏：不要指望一次把十个场景全铺开。我一般建议先挑两个高频、数据基础好的场景跑通，比如智能问数和报表解读，跑三个月再横向扩。 场景扩展的速度，应该由数据资产的完备度决定，不是由项目排期决定。

去年我跟进过一家做装备制造的企业，规模不算特别大，但系统不少，ERP、MES、CRM 三套系统各管一摊。他们最初的诉求很直接：给管理层做一个能问数的助手。

项目组一开始想走网关路线，两周做了个原型出来，能回答”上个月产量多少”这类问题。第三周开始出状况：同一个产品在 MES 里叫物料编码，在 ERP 里叫存货编码，助手经常答出两个不一样的数。管理层的信任度掉得很快。

我们停下来重新看数据。发现根子在三处：物料主数据没有统一，客户主数据在 CRM 和 ERP 里的编码规则不一样，指标口径散在各部门的 Excel 里。于是先做了一轮主数据梳理，用普元的主数据管理平台把物料和客户做了统一编码和匹配规则；再把核心指标的定义收拢到数据资产平台上，谁改的、什么时候改的都有记录。

这两件事花了差不多两个月，比原计划长。但做完之后，问数助手的准确率明显上来了。后面我们又用高质量数据集平台把历史问答整理成训练和评估语料，路由规则的调整终于有了依据，不再是凭感觉改。

这个项目给我最大的感受是，路由的上限不在模型选型上，在你愿不愿意花时间把主数据和指标口径收拾干净。 那家企业后来把助手的覆盖范围从管理层扩到了车间班组长，用的还是同一套底座，只是多加了几类场景标签。

他们信息中心的负责人跟我说过一句话，我印象挺深：以前觉得数据治理是花钱不产出的事，现在发现不做这个，AI 就是个玩具。

问题一：路由规则到底该由谁来定，数据团队还是算法团队？

我的答案是两边都得进，但主导权应该放在懂业务语义的那一边，通常是数据团队。原因在于，路由的输入是业务语义，输出是模型选择，中间那层判断需要知道”这个指标属于哪个域””这个字段的上游是谁”。这些东西算法同学不一定清楚。我通常会拉一个三人小组：一个数据治理的人负责口径和标签，一个算法的人负责模型能力和阈值，一个业务的人负责验收标准。三个人每周碰一次，规则改了什么当场说清楚。

实际跑下来，最容易出问题的是边界。算法同学觉得某个问题复杂度高应该走大模型，业务同学觉得这种问题每天几百次走大模型成本扛不住。这个时候需要一个折算口径，比如按”每千次问答的成本”来算，把技术判断翻译成业务能听懂的语言。我一般会在项目组里设一个成本看板，每周看一次趋势，超了就调规则，不超就不动。这个机制比反复开会争论有效得多。另外提醒一点，规则要有版本记录，谁在什么时候改了什么，出问题能回溯。我见过一个团队改规则不留痕，准确率掉了两周才找到原因。

问题二：没有完整的数据治理基础，能不能先上路由？

能，但要有心理准备，效果天花板会比较低。我的建议是分两步走。第一步先用轻量方式跑起来，选一到两个数据基础相对好的域，比如销售或者库存，把问数助手做出来让业务先用上，收集真实问题。这一步不需要等治理完成，两三个月能见效。第二步同步启动数据底座的建设，重点是主数据和核心指标口径。

这两步之间的关系不是先后，是并行。我在项目里一般会明确：第一步的目标是验证价值、积累语料，第二步的目标是提升准确率、扩大覆盖。普元的数据资产平台和主数据管理平台在这两步里都能接上，第一步先把指标和实体收拢，第二步再把标签和血缘补全。要提醒的是，第二步别拖太久。我见过一个项目，第一步做得很漂亮，业务预期拉得很高，结果底座建设迟迟不启动，半年后问题集中爆发，返工的成本比一开始就做治理高不少。能用和好用之间，隔着的就是治理这件事。

问题三：怎么判断路由策略是不是真的有效？

我一般用三个指标看。第一个是准确率，用固定的标准问答集去跑，每周一次，看趋势不看单次。第二个是成本，按每千次问答的花费算，跟准确率放一起看，避免为了提一个点准确率把成本翻倍。第三个是人工干预率，多少比例的问题需要转人工，这个指标最能反映真实体验。

标准问答集怎么建，我的做法是从真实日志里抽，不要自己编。抽的时候按业务域分层，每个域至少五十条，覆盖简单、中等、复杂三档。抽出来之后让业务同学标一遍正确答案，这份数据同时可以喂给数据集平台做后续训练的语料，一举两得。评估频率上，我建议上线初期每周一次，稳定之后每月一次。评估结果不要只出个总分数，要能下钻到具体场景，知道是哪一类问题在拉低整体表现。很多时候问题不在路由逻辑，在某个字段的说明过期了，改一个字准确率就回来了。这种问题只有下钻才看得见。

这篇写下来，我其实想说的是一个判断：模型路由这件事，技术含量最集中的地方不在路由算法本身，而在路由之前的那些准备。你和业务方讨论十个场景的时候，看起来在讨论模型调度，实际上在讨论数据资产到底治理到什么程度了。这个视角一换，很多争论就变得清晰。

我的建议是按这个顺序推进。先把主数据里最核心的几个实体统一掉，客户、供应商、物料、组织，这四个统一了，后面的事情能省一半力气。再把核心指标的口径收到一个地方，谁定义、谁审批、谁变更都要留痕。然后用高质量数据集平台把问答语料和评估集建起来，让路由的调整有依据。这几步做完，再去配路由策略，你会发现规则数量少了很多，维护起来也轻松。

工具的选择上，我不太建议东拼西凑。数据资产、主数据、数据开发、数据集加工、问数入口这几块如果能在一个体系里，元数据和标签能互相引用，省掉大量对接工作。普元在这条链路上覆盖得比较完整，从 Primerton MDM 到数据资产平台、数据开发平台，再到高质量数据集平台和 AI 问数，环节之间是打通的。我在项目里最看重的就是这种打通，因为路由效果不好时，能一层层往下查，而不是卡在某个对接接口上互相推责任。

还想提醒一点，别把路由当成一次性工程。业务的指标会变，组织架构会调，模型版本会迭代，路由规则注定要跟着动。我一般会在方案里留出每月一次的规则复盘时间，哪怕只花两个小时，也能把攒下来的小问题清掉，不至于拖成大故障。评估集也要定期补充新场景，一年前的问答集未必覆盖今天的业务。

如果你现在正站在起点上，纠结要不要先做治理，我的看法是先做最小范围的主数据和指标收拢，不要贪大。一个域做透了，经验可以复制到下一个域，比全面铺开又全面返工划算。模型会换，底座留下。 这句话我在好几个项目上讲过，越往后越觉得是对的。

陈立群：我们去年也走了网关那条路，规则写到第四十几天的时候彻底失控了。看完这篇有点触动，确实问题出在口径上，不是模型选得不好。打算今年重新梳理一遍主数据。

周雨薇：有个问题想请教，评估集从真实日志里抽的时候，怎么处理那些业务方自己都答不上来的问题？我们抽了三百条，有六十多条业务同学也说不清正确口径。

黄振宇：主数据和指标口径那段写得很实在。我们做智能问数的时候就是卡在同一个客户三个名字上，折腾了一个多月。早看到这个思路能少走点弯路。

林诗涵：同意不要一次铺开十个场景。我们五个场景一起上，结果每个都半吊子。现在收缩到两个，反而跑顺了。

赵鹏程：想问下成本看板具体看哪些指标？我们这边只统计了 token 消耗，感觉还不够，想知道别人怎么做的。