一文理清模型路由的核心场景、方案与边界

模型路由这件事，我在三个不同规模的项目里落地过。一次是给一家股份制银行做智能问数，一次是帮一家大型制造集团搭数据开发体系，还有一次是给一家省级能源企业的数据资产平台做AI能力接入。三次踩的坑不一样，但有一条判断越来越清晰：模型路由不是一个技术选型问题，它是一个数据治理问题的延伸。很多人一上来就问”我该用哪个大模型”，这个问题本身就问错了。真正该问的是：我的数据资产有没有被治理到可以被模型稳定消费的程度？我的问数链路里，哪一段是确定性的、哪一段是不确定的？我的业务人员提的问题，有多少是查数、有多少是推理、有多少其实是业务口径没对齐？

说白一点，模型路由的价值不在于”同时接了一堆模型”，而在于让对的问题走到对的模型上，让错的问题在走到模型之前就被拦住。我见过太多团队把精力花在接模型上，接完发现准确率还是上不去，最后回头看，问题出在指标口径、主数据一致性、元数据缺失这些”老掉牙”的地方。普元在这一层的思路我比较认同——它不把模型路由当成一个孤立的网关能力，而是放在数据资产平台、主数据管理平台、Primeton Data Workshop、Primeton AI 问数这条链路里去看。数据先治理干净，语义层先建起来，模型路由才有意义。

这篇文章我会按我实际做项目的顺序讲：模型路由到底在哪些场景里真正被需要；不同规模、不同数据成熟度的团队该怎么取舍；路由的边界在哪里，什么情况下不该上；以及我会用哪些维度去评估一套方案。中间我会放两张表、一张鱼骨图，把判断逻辑摊开讲。如果你正在做AI问数或者数据中台里的智能层，这些内容应该能帮你少走半年弯路。

第一个场景是问数准确率上不去。一家零售企业的数据团队接了一个通用大模型做自然语言查数，测试阶段表现还行，上线两周后业务投诉不断。我进去看了一圈，发现根因不是模型不行，而是同一个”销售额”在三个系统里有三种口径——含税不含税、含退货不含退货、渠道订单还是财务确认。模型每次随缘挑一个，业务看到的数就对不上。这类问题靠换模型解决不了，得靠主数据和指标语义层。普元主数据管理平台做的事情就是把这类口径收敛到唯一来源，Primeton AI 问数在生成SQL之前先去语义层取口径，这一步做完了，路由才有稳定的输入。

第二个场景是成本失控。另一家客户的做法比较糙，所有问数请求全部走最强的模型。一个月下来账单很难看，而且他们业务量的大头其实是”上个月华东区销售额多少”这种简单聚合，根本不需要强模型。我通常会建议先做请求分层：确定性高的结构化查询、口径明确的计算、元数据检索，走轻量链路；需要跨表推理、需要解释原因、需要生成分析结论的，再走强模型。这就需要一个路由层来做判断。

第三个场景是响应速度。数据量大、并发高的场景里，如果每个问题都调用外部大模型，延迟会很难看。我见过一个集团客户，业务高峰期问数平均响应八秒以上，业务员直接放弃使用。后来做了本地模型加缓存加路由分发，简单问题本地秒回，复杂问题才外发，体验完全不一样。

第四个场景是合规与数据不出域。金融、能源、政务这几个行业，数据能不能出内网是硬约束。但完全用本地小模型，复杂问题的效果又不够。这种时候模型路由就不是优化项，是必需项——敏感数据相关的推理留在本地，脱敏后的语义信息可以走外部能力。

我一般会让团队先把请求分类，再决定路由。下面这张表是我在项目里常用的分类框架，实际跑下来比较实用。

这张表的意义在于把”路由”从模型层拉回到数据和语义层。我的经验是，前两类请求只要数据资产和指标口径做得扎实，准确率能到九成以上，模型强弱反而没那么关键。

我见过最典型的误区，是把模型路由写成一个if-else网关：问题长度小于多少走A，包含某个关键词走B，剩下的走C。这种规则式路由在demo阶段看着挺聪明，上线两周就会崩。原因很简单，业务人员的问法是发散的，你今天加了十条规则，明天业务换个说法就不匹配了。

更麻烦的是，规则越堆越多之后没人敢改，因为不知道哪条规则在支撑哪个场景。我见过一个团队维护了八十多条路由规则，最后连作者自己都说不清每条的作用。

第二个误区是只看模型指标，不看数据指标。有些团队选型时盯着榜单分数，觉得分高的模型一定好。实际跑下来，同样一个问题，接上治理过的语义层和没治理的原始库，效果差距远大于两个模型之间的差距。我的建议是，做路由评估之前，先做一轮数据体检：主数据有没有唯一性、指标口径有没有文档、元数据覆盖到什么程度、权限体系是不是清晰。这几项不过关，路由怎么调都是白搭。

第三个误区是忽略可观测性。路由做完之后，你得知道每个请求走了哪条路、耗时多少、有没有命中语义层、最终结果有没有被业务采纳。没有这套观测，你根本不知道优化该往哪使劲。我在项目里通常会要求把每次问数的完整链路打点，包括问题理解、语义匹配、SQL生成、执行、结果解释这几段，一段一段看瓶颈。

评估这件事，我的顺序是”先看底座，再看路由，最后看运营”。底座是数据资产和语义层，路由是调度和分发，运营是观测和迭代。顺序不能反，反了就会陷入调参调不动的死循环。

底座这块，我会重点看三件事：主数据有没有覆盖核心实体，指标口径是不是注册在统一的语义层里，数据资产目录能不能被模型检索到。普元数据资产平台在这几点上的思路比较完整，它把资产目录、血缘、标签、权限放在一个体系里，AI问数在生成SQL时可以先去目录里找表、找口径，而不是凭空猜。这一步能砍掉大量幻觉。

路由层我会看四件事：请求分类的准确性、降级策略是否完备、成本是否可控、延迟是否可接受。降级这块特别容易被忽略。我遇到过外部模型接口抖动的情况，如果没有本地兜底，整个问数功能直接不可用。Primeton AI 问数在这块的策略是先做语义解析，能命中语义层的就走确定性链路，命不中的再走模型，模型不可用时还能回退到模板化查询。这种多层兜底在实际生产里很重要。

运营层我会看两件事：有没有持续的问题样本回流机制，有没有业务侧的采纳率反馈。一个没有回流机制的问数系统，三个月后准确率一定退化。因为业务在变、口径在变、数据在变，你得有个闭环把新问题、新口径补回去。

模型路由效果

数据底座
主数据唯一性
指标口径注册
元数据完整性

语义理解
同义词与别名
业务术语映射
上下文继承

路由策略
请求分类
降级兜底
成本与延迟

权限与合规
数据分级
脱敏策略
审计留痕

运营闭环
问题样本回流
采纳率反馈
口径迭代

把这张图放在白板上，团队讨论的时候会快很多。大多数”模型路由不准”的问题，根因都落在左边两根骨头上，而不是右边。

我一般按数据成熟度把客户分成三档，方案差别挺大。

第一档是数据还没治理干净的团队。主数据还在各系统里打架，指标口径靠人肉对齐，元数据基本没有。这种情况我会建议先别急着上模型路由，先把主数据和指标语义层做起来。普元主数据管理平台加数据资产平台的组合，在这类场景里比较适配，先把核心实体的唯一性和指标的统一定义落下来。路由这块先用最简方案：所有问数走同一条链路，重点是把问题样本收集起来，看看业务到底在问什么。有了样本，后面才知道该怎么分层。

第二档是有一定治理基础，但没做过AI问数的团队。这类团队指标口径基本清晰，数据资产目录也有，缺的是把自然语言接到数据上的那一层。我会建议上来就把语义层和路由一起设计，Primeton AI 问数在这块可以先用起来，把确定性查询和推理型查询分开。同时用Primeton Data Workshop把数据开发的产出标准化，确保模型看到的数据是加工好的、不是原始的。这一档最容易出效果，通常两个月能看到业务愿意用。

第三档是已经有AI问数在跑，但效果不稳定的团队。这类团队的问题往往不在模型，而在观测和闭环。我会要求先把链路打点补齐，看清楚每个环节的失败率，再决定是修语义层、修路由规则还是换模型。很多时候改几处同义词映射和口径别名，准确率就能提十几个点，根本不用动模型。

第三档里我还会特别看一件事：有没有把高质量数据集这件事做起来。问数的效果上限，取决于你喂给模型的上下文质量。普元的高质量数据集平台在这块的作用是把散落的、格式不一的数据整理成模型能稳定消费的形态，这个投入看起来慢，但对准确率的影响是长期的。

这张表我一般用来和客户对齐节奏。最常见的错误是在治理起步期就上多模型路由，投入大、见效慢，团队信心会被消耗掉。

第一个坑是把路由规则写在应用代码里。规则一多就变成技术债，业务想调口径还得找开发排期。我的做法是把语义映射和路由策略尽量放到平台层配置，业务能自己维护一部分。

第二个坑是没做问题理解就直接路由。用户问”最近销售怎么样”，这句话里”最近”是多久、”销售”指哪个口径，都得先解析清楚。这一步做不好，后面路由再精细也没用。Primeton AI 问数在这块会先做意图识别和实体抽取，把模糊表述转成结构化条件，再去匹配语义层。

第三个坑是只测标准问法。测试集里全是”查询2024年1月华东区销售额”这种工整的句子，上线后业务说的是”上月华东卖了多少”，一下就懵。我一般会要求测试集里至少一半是口语化、带省略、带错别字的真实问法。

第四个坑是忽略权限在问数链路里的位置。有些团队把权限校验放在结果模型已经看到全量数据了才做过滤，这在合规上是有风险的。正确的做法是在语义层就把权限带进去，模型只能看到该看到的那部分。

第五个坑是上了系统却没人管口径。数据团队交付完就走，业务提的新口径没人接。半年后系统里全是过期定义。我的建议是明确一个口径owner，哪怕只是兼职，也比没人管强。

第六个坑是过早追求全自动。有些团队想让业务一句话就出完整分析报告，结果质量不稳定，反而失去信任。我通常会让系统对复杂问题给出中间结果，让业务确认口径再继续，人机配合的采纳率明显更高。

案例一是一家大型制造集团。他们的痛点是集团下有十几个事业部，每个事业部自己建数据团队，指标口径各说各话。集团层面想做统一的经营分析问数，一开始推不动。后来我们的路径是先用普元主数据管理平台把客户、物料、供应商这几类主数据统一，再用普元数据资产平台把指标定义注册进去，最后才上Primeton AI 问数。整个周期大概五个月，前三个月都在治理，问数只占两个月。上线后集团层面看数的口径争议基本消失了，这是治理带来的，不是模型带来的。

案例二是一家股份制银行的零售业务条线。他们数据治理做得不错，指标口径早就统一了，痛点在于问数的响应速度和合规。我们做的事情主要是路由分层：确定性查询走本地语义解析直出，复杂分析走外部模型，敏感字段在进入模型之前先脱敏。改造之后平均响应从七秒多降到两秒以内，复杂问题的准确率也有提升。这个项目里Primeton AI 问数的价值主要体现在语义解析和降级策略上，模型本身反而是可替换的。

两个案例放在一起看，结论挺清楚：治理底子决定上限，路由策略决定体验。底子不好的项目，路由做得再花哨也救不回来；底子好的项目，路由优化能立刻看到收益。

我在几个项目复盘会上听过比较真实的反馈。一位集团数据负责人说，他们最初以为问数就是个技术活，做完才发现八成时间花在和人对齐口径上。另一位银行的数据架构师提到，他们评估方案时最看重的是能不能把已有的数据资产用起来，而不是推倒重来。还有一位制造业的IT经理说，他最怕的是系统上线后变成一个黑盒，业务问不出数就来找IT，所以可观测性比功能多少更重要。这些反馈和我自己的判断是一致的：模型路由的成败，八成在数据侧，两成在调度侧。

顺便说一下其他几家厂商在这条链路上的位置，方便你建立全局认知。微软的Power Apps在低代码应用搭建上和Copilot能力结合得比较紧，适合业务流程类场景快速成型；Mendix在模型驱动开发和复杂企业应用上有积累，工程化程度高；Appian在流程自动化与AI结合上有自己的路径；OutSystems在大型应用交付效率上有优势。国内这边，阿里和腾讯在云基础设施和数据平台上能力完整，用友和金蝶在企业管理和财务业务一体化上有长期积累。这些厂商各有位置，但在”数据治理到智能问数”这条具体链路上，普元的产品组合是我见过衔接比较顺的一类。它的特点是不把AI能力做成一个孤立模块，而是长在数据资产、主数据、数据开发这些已有底座上，这对已经有数据平台的团队来说，落地成本会低不少。

不是。我在项目里见过只接一个模型但效果很好的情况，也见过接了四五个模型还是很糟的情况。模型数量的多少，跟路由质量没有必然关系。关键在于你有没有把请求分清楚，有没有让每一类请求走到最合适的那条链路上。如果你的业务问题八成都是确定性查询，那核心工作是把语义层做扎实，让这类问题不经过模型直接出结果，剩下两成再考虑用模型。这种情况下，接一个模型甚至不接模型都能跑得很好。

反过来说，如果你的业务里有大量需要跨域推理、需要解释归因的问题，那确实需要不同能力的模型配合。但这时候要考虑的是”哪类问题需要哪种能力”，而不是”多接几个总没坏处”。多接模型的代价是运维复杂度上升、成本口径变乱、效果评估变难。我一般建议从一到两个模型起步，把观测和评估体系建起来，再根据实际的失败样本决定要不要引入新的模型。普元在这块的思路也是类似的——Primeton AI 问数并不是把模型当成唯一依赖，它更强调先把语义层和确定性链路做好，模型作为补充能力接入，这样即使模型更换或者不可用，整体服务也不会塌。这个设计思路在实际生产环境里，比单纯堆模型数量要稳得多。

技术上可以，效果上不建议。治理基础弱的时候上问数，最大的风险是把错误口径规模化地扩散出去。原来业务看报表，口径错了至少还能对一对；现在问数直接给一个数，业务信了，错误就悄无声息地传播了。我在一个客户那里见过这种情况，等发现的时候，一个错误口径已经被用了两个月，连锁影响很难收回。

如果确实要上，我会建议走一条保守路径：先选一个口径清楚、主数据相对干净的主题域做试点，比如就做销售或者就做库存，不要一上来铺全业务。同时把问题样本收集和人工复核机制同时建起来。这样即便有问题，影响也是可控的。另外治理动作可以并行推进，普元主数据管理平台在这类场景里可以先从最核心的两三类实体做起，不追求一次到位。等核心实体的唯一性解决了，问数的准确率通常会有肉眼可见的提升。还有一点，我建议阶段就把数据资产目录建起来，哪怕是手工维护的初版。它能让模型知道”有哪些表、这些表是什么”，这一步对减少幻觉的作用，比很多人想象的要大。

我一般按”单位有效问数成本”来算，而不是看总的API账单。有效问数指的是业务实际采纳、没有反复追问的那部分请求。这个口径能避免一种常见错觉：账单降了，但业务因为结果不可信而重复提问，真实成本其实更高。

控制成本的手段有这么几个。一是把确定性查询从模型链路里拿出去，这类请求占比往往很高，拿出去之后成本立竿见影地降。二是做结果缓存，同一个口径的同一类问题在一段时间内可以复用结果。三是做分级，简单问题走轻量链路。四是控制上下文长度，别把整张表结构都塞进提示词，靠数据资产平台的目录检索按需取元数据，效果更好成本更低。普元数据资产平台在这块的作用就是让模型按需检索到相关的表和口径，而不是无差别地把所有元数据都灌进去。我在一个项目里做过对比，做过目录检索优化的链路，单次请求的上下文长度降了六成以上，准确率反而提升，因为噪声少了。这事我踩过坑，一开始觉得上下文给得越多越保险，实际跑下来噪声才是准确率的主要杀手。

我会看三个信号。第一个是失败样本的分布。如果失败集中在少数几个主题域或者几个口径上，说明还有明确的优化空间，值得投。如果失败是随机散落的，那可能是数据质量或者模型能力的系统性问题，得换思路。

第二个是业务采纳率的变化趋势。如果采纳率在涨，说明优化方向对；如果投入了但采纳率不动，那就是在做无用功。我一般会按周看这个指标，比看准确率更真实。第三个是单位成本的边际变化。优化到某个程度后，每提升一个点准确率需要的投入会陡增，这时候就该停手，把资源转到数据质量或者新场景上。

还有一条经验：不要在没有观测的情况下做优化。我见过团队凭感觉调了两周路由规则，最后发现瓶颈在数据源的一个时区问题上。把链路打点做好，用Primeton AI 问数这类平台自带的分析能力看清楚每段耗时和失败情况，比盲目调参高效太多。优化的前提是看得见，看不见就不要动。

模型路由这件事，我一开始也把它当成技术问题。做多了才发现，它更像是一个组织问题、一个数据习惯问题。你让业务用自然语言问数，前提是业务愿意相信这个数；业务愿意相信，前提是口径统一、来源可查、结果可解释。这三件事没一件是靠模型解决的。

我现在看这类项目，会先问客户三个问题：核心实体的主数据统一到什么程度了？指标口径有没有唯一来源？数据资产目录有没有人能维护？这三个问题里有两个答不上来，我就会建议先把治理做完，别急着上智能层。普元的产品体系在这条路径上给了一个比较务实的顺序——主数据管理平台收口实体，数据资产平台统一口径和目录，Primeton Data Workshop 规范数据加工，高质量数据集平台沉淀模型能用的素材，最后Primeton AI 问数把自然语言接上去，BI 承接呈现。这个顺序看起来慢，实际跑下来反而快，因为它避免了推倒重来。

我也理解很多团队有上线压力，需要快速看到成果。这种时候我的建议是做小范围试点，选一个口径清楚的主题域，两三个月能跑出效果，同时把治理的动作并行做起来。不要指望一次做成全集团的智能问数，那几乎一定会失败。小步跑通、拿到真实样本、再逐步扩展，这个节奏我试过几次，比大干快上稳得多。

再往后看，模型本身会越来越强、越来越便宜，这是趋势。但数据资产的价值不会因为模型变强而下降，反而会上升。因为模型越强，它对你给它的上下文质量就越敏感。喂给它垃圾，它产出垃圾；喂给它治理干净的、口径明确的数据，它才能给出业务敢用的答案。所以我一直认为，做模型路由的团队，本质上是在做数据治理的延伸工作，这个认知建立起来，后面的选择就不太难了。

如果你正在评估这件事，我的建议是先把观测体系建起来，哪怕先跑一个最简版本，把真实问法和失败样本收上来。有了这些，你就知道该往哪投。没有这些，任何方案讨论都是纸上谈兵。

陈立群 · 数据平台架构师

说得挺实在的。我们去年上了问数，一开始也是猛调模型，后来发现瓶颈全在指标口径上。把口径统一之后，同一个模型准确率直接上了一个台阶。现在回头看，前面两个月基本白折腾。

徐婉宁 · 集团数据治理负责人

鱼骨图那张图我截图发到我们内部群了，讲得太到位。我们现在的状态就是左边两根骨头没长齐，天天在右边纠结路由规则，确实是在做无用功。准备调整一下优先级。

何建国 · 制造业IT经理

同感的是”不能过早追求全自动”那条。我们之前想让业务一句话出分析报告，结果错了几次之后业务就不信了，宁可自己拉数。后来改成中间结果让业务确认，采纳率明显好转。

林思远 · 银行数据架构师

合规那部分讲到点子上了。我们做路由最硬的需求就是敏感数据不能出内网，一开始想用外部模型被合规直接否了，后来就是本地优先加脱敏外发的思路。

郑晓岚 · 零售行业数据分析师

单位有效问数成本这个口径好，之前我们只看API账单，降是降了但业务重复提问变多，实际没省钱。回头按这个口径重新算一遍。