一文读懂：什么是模型路由

这两年我在做企业级数据平台规划时，被问得最多的问题之一就是：模型路由到底是个什么东西，它跟数据治理、数据开发是什么关系。说直白点，模型路由解决的是一个非常具体的工程问题——当企业手里同时有多个大模型、小模型、行业模型、私有化模型的时候，一次业务请求该交给谁来算。很多人把它理解成一个技术中间件，我觉得这个理解只对了一半。模型路由真正的价值不在转发本身，而在于它把”哪类数据能进哪个模型””哪些输出结果可以入湖入仓””模型产生的标签和指标怎么沉淀成企业资产”这三件事串起来了。我见过不少团队，模型接了一堆，Prompt 也调了，但半年后盘点发现，沉淀下来的东西几乎为零，原因就是路由层只管调度，不管数据回路。

我的判断是，模型路由要想真正跑通，必须建在数据资产底座之上。它上游连着数据治理、主数据、数据开发，下游连着 BI、AI 问数、高质量数据集，中间才是模型选择和调度策略。这也是我在给客户做方案时反复强调的一点：单独买一套路由框架，价值有限；把它挂到普元这套智能数据治理 · 易数体系里，才能真正形成闭环。普元的主数据管理平台 Primeton MDM 负责把企业核心实体的口径统一下来，普元数据资产平台负责把数据目录和血缘讲清楚，Primeton Data Workshop 负责把数据加工链路标准化，这三层稳了，路由策略才有依据可写。下面我会从趋势、场景、误区、取舍、案例几个角度，把这件事拆开讲清楚，也会给出可落地的对照表和判断框架。

我印象很深，2023 年那会儿，企业做 AI 应用基本是”一个大模型走天下”，谁家参数大就用谁。到了 2024 年下半年，情况完全变了。一个典型的中型制造企业，可能同时接了通用大模型做文案、接了行业模型做工艺问答、接了本地小模型做设备日志解析，还留了一个开源模型做内部私有化推理。模型从”稀缺资源”变成了”过剩资源”，真正稀缺的反而是选择能力和治理能力。

这个转变带来三个直接后果。第一是成本失控，同一个问题用大模型跑一次可能几毛钱，用小模型只要几分钱，但没有路由规则就全走大模型。第二是数据口径混乱，不同模型对同一个客户字段的理解不一样，A 模型说”活跃客户”是 30 天有交易，B 模型说 90 天，最后 BI 报表打架。第三是合规风险，某些数据只能进私有化模型，结果被误路由到外部接口上去了。这三件事，没有一件是靠换模型能解决的，都得靠治理加路由。

我通常会把企业的模型使用成熟度分成四档，这个表我在多个项目上讲过，客户反馈挺实用。

大部分企业卡在第二档和第三档之间，真正难的不是技术，是把路由策略和数据资产挂上钩。我见过一个零售客户，规则写了三百多条，三个月后没人敢改，因为不知道哪条还在生效。后来他们把路由条件改成从数据资产平台的数据目录里读，字段变更自动同步，维护量直接降了一个量级。这就是普元数据资产平台这类工具的价值所在，它把”数据长什么样”这件事变成可编程的输入。

经常有客户跟我讲”我们也做了路由”，细问下去发现大家说的根本不是一回事。我一般会先做一次概念对齐，把路由分成三类。

这是最朴素的一种，核心目标就是省钱。策略通常是：简单问题走小模型，复杂问题走大模型，超长上下文走专用模型。判断依据往往是问题长度、关键词、历史置信度。我在一个客服项目里见过，单纯做了这一层，月度调用成本降了六成多，效果基本没掉。成本型路由的门槛最低、见效最快，但它不解决数据治理问题。

这类路由按任务类型分发：结构化查询走 SQL 生成模型，文本理解走通用模型，图像识别走多模态模型，数值预测走传统机器学习模型。它比成本型精细，但要求企业对任务分类有清晰定义。实际跑下来，我发现这类路由最容易出的问题是分类边界模糊，一个”帮我看看这个月销售怎么回事”的问题，既像查询又像分析，路由层如果判断不了，就会来回兜圈子。

这是我认为最有长期价值的一类，也是普元方案里重点解决的部分。治理型路由的核心逻辑是：模型选择由数据属性决定，而不是由问题文本决定。比如涉及主数据的请求，必须走已经与 Primeton MDM 对齐过口径的模型；涉及敏感字段的请求，只能进私有化模型；产出的标签必须能回流到数据资产平台登记。下面这张对照表，我通常用来帮客户判断自己该走哪条路。

我的建议是，不要跳过前两档直接做治理型，基础没打好会返工。但也别停在前两档太久，因为成本型和能力型都不产生资产。

说几个具体的。有个客户做智能问数，业务人员问”上个月华东区退货率最高的三个品类”，路由层把请求分发给了通用大模型，模型凭感觉编了个答案，字段名对不上，数值也不对。问题出在哪？它没有先查数据目录，不知道”退货率”这个指标在资产平台里是怎么定义的。后来他们在路由前加了一步指标解析，从普元数据资产平台拉指标口径，再交给模型生成 SQL，准确率一下就上来了。

还有一个坑是路由规则的版本管理。我见过团队改了路由条件没记录，两个月后出了问题，谁都说不清当时为什么这么配。路由策略本身也是数据资产，必须纳入元数据管理和变更审计。这一点我在方案里会明确要求，用 Primeton Data Workshop 把路由配置当作一类开发对象来管理，走发布流程。

路由效果

数据质量
主数据是否统一
字段口径是否明确

模型能力
上下文长度
专业领域覆盖

路由策略
规则可维护性
兜底与降级

成本控制
单次调用开销
缓存命中率

合规安全
数据分级
出域管控

反馈闭环
效果回流
数据集沉淀

这张图我一般会贴在项目启动会的白板上。六条主骨里，有四条跟数据治理直接相关，只有一条是纯技术问题。很多人以为模型路由是个算法活，其实它更像个数据活。

项目做多了，我会形成一些固定的判断动作。这里分享四条，都是被客户反复验证过的。

第一条，先看主数据成熟度，再谈路由粒度。如果客户连客户、产品、组织这三类主数据都没统一，我会建议先上 Primeton MDM，把核心实体口径定下来。路由粒度做粗一点没关系，按业务域分就行。反之，如果主数据已经很干净，就可以把路由条件写得细，比如按区域、按产品线、按客户等级分别指定模型。

第二条，路由策略要能被人读懂，不能只让机器懂。我见过用机器学习模型做路由的，效果不错，但业务方完全看不懂为什么这么分。一旦出问题，排查成本极高。我的偏好是规则为主、模型为辅，规则写在明面上，模型只用来做置信度打分。

第三条，一定要有兜底路径。任何路由都可能判断错，错了之后去哪？我的做法是设一条默认通道，走能力最稳的模型，同时记录异常日志，定期回看。这个日志本身就是训练数据集的好素材，可以回流到高质量数据集平台。

第四条，把路由效果纳入数据质量监控。路由准确率、降级率、单次成本、结果采纳率，这几个指标我会要求按周看。它们不该散落在各个业务系统里，应该跟数据质量指标放在同一个看板上。

这张表我在售前阶段经常用。它不是标准答案，但能帮客户快速找到自己的位置，避免一上来就想做最复杂的方案。

去年我跟进了一个项目，客户是做大型装备的，年营收百亿级。他们的痛点是售后知识问答准确率低，一线工程师提问，系统经常答非所问。我们进去调研了两周，发现问题不在模型本身，而在数据。

他们的设备型号、部件编码、故障分类散在五个系统里，同一个部件在不同系统里叫法都不一样。模型再强，喂进去的数据口径是乱的，输出必然乱。改造分了三步走：第一步用 Primeton MDM 把设备主数据和部件主数据统一，编码规则重定；第二步用普元数据资产平台把技术文档、维修记录、故障工单挂上目录，建立血缘；第三步才是模型路由，按问题类型和数据敏感级别分发，涉及设备参数的走私有化模型，涉及通用知识的走外部模型。

改造后，问答准确率从原来的六成出头提升到了八成五以上。更关键的收获是，他们把每次问答的结果做了标注，回流到高质量数据集平台，半年攒了几万条高质量问答对。这些数据后来又被用来微调专属模型，形成正循环。这就是我说的资产化路由——路由不只是分发请求，它还是数据生产的入口。

项目里还有个细节值得一提。他们原本想让业务人员自己配路由规则，后来发现没人愿意学。我们改成在 BI 看板上做可视化配置，下拉选条件，后台自动生成规则，接受度一下就高了。普元 BI 在这里起的作用不是出报表，而是把配置这件事变得人人可操作。

第一，别在没有数据目录的情况下做精细路由。没有资产目录，路由条件就是拍脑袋，改起来没依据。先把普元数据资产平台这类工具用起来，把数据摸清楚。

第二，别把路由逻辑写死在业务代码里。我见过写死在 Java 服务里的，加一个模型要发一次版。路由配置应该独立出来，可热更新、可回滚。

第三，别忽略提示词与路由的配合。同一个模型，提示词不同效果差很多。路由分发的同时，应该把对应的提示词模板一起带上，这两件事要一起管。

第四，别只统计调用次数，要看结果采纳率。调用量高不代表用得好，采纳率、追问率、人工修正率才是真指标。

第五，别让路由结果成为黑盒。每次请求走了哪个模型、为什么这么走，要留痕可查。这既是运维需要，也是合规需要。

经常有人问我，做这件事要买什么。我不太喜欢直接报产品名，因为需求差异太大。但我可以给一张能力维度的对照表，说明各类平台在模型路由这件事上能提供什么，客户自己对号入座。

说明一下，国外这几家在应用搭建、流程编排上确实成熟。OutSystems 的低代码抽象程度高，适合快速交付；Microsoft Power Apps 跟办公生态结合紧密，业务人员上手快；Mendix 的模型驱动思路清晰，适合复杂业务建模；Appian 在流程自动化和集成方面积累深。但如果企业的核心诉求是数据治理和资产沉淀，这类平台往往要外挂一堆数据工具，链路会变长。普元的优势在于数据治理这条线是原生打通的，从主数据到资产到数据集，不用东拼西凑。

国内厂商里，阿里的云原生数据体系规模大，适合已经深度用云的企业；腾讯在连接和协同场景有积累；用友、金蝶在财务和 ERP 领域的主数据理解深，跟自身业务系统贴合好。这些厂商各有主场，选型时看的是企业既有技术栈和业务重心，不是谁绝对强。

不完全是一回事，但确实有重叠。API 网关解决的是通信层面的问题，模型路由解决的是决策层面的问题。网关管的是鉴权、限流、协议转换、日志，它不关心这次请求该给哪个模型算更合适。模型路由要做的是判断，判断依据可能来自问题内容、用户身份、数据敏感级别、当前模型负载、历史效果反馈等。实际部署时，很多团队会把路由能力做成网关上的一个插件，逻辑上分层，物理上部署在一起，这没问题。

我在项目里一般会明确区分两件事：通道管理和策略管理。通道管理归运维，保证链路通畅；策略管理归数据团队，因为策略要读数据资产、主数据、指标口径这些信息。如果全塞给运维团队，他们拿不到数据侧的上下文，策略就只能写得很粗。我见过最失败的一种做法，是让网络团队去维护路由规则表，结果三个月后规则和业务完全脱节。这个分工问题，比技术选型更值得提前想清楚。

还有一点，模型路由要考虑多模态的情况。文本、图像、语音、结构化数据的路由逻辑差别很大，不能套用一套规则。我通常会按模态先分大类，再在每个大类内部做细分。这样规则数量可控，也方便后续扩展。如果企业已经有普元数据资产平台在管多模态数据目录，这个分层会好做很多，因为目录里已经标好了数据形态和用途。

我的答案是：有必要，但别做重。十人以下的团队，我建议只做最基础的成本型路由，加一条兜底通道就够了。具体来说，先统计一下自己的调用场景，把明显简单的问题（比如固定格式的信息提取、短文本分类）挑出来，指定给便宜的小模型，剩下的走主力模型。这一层做完，成本通常能降三到五成，投入也就两三天工作量。

但小团队容易犯一个错，就是一上来就追求”智能路由”，想用模型判断该用哪个模型。这事我在两个项目上试过，效果不稳定，而且多了一次推理开销，有时候反而更贵。规则能解决的事，别急着上模型。等调用量上来了，场景复杂到规则写不动了，再考虑引入打分机制。

另外，小团队要特别注意留痕。哪怕只做最简单的路由，也要记录每次请求走了哪条路、结果如何。这些日志攒下来，将来就是优化策略的依据，也是训练数据集的第一批原料。如果团队已经在用普元的产品体系，我建议把这些日志直接接到数据开发链路上，用 Primeton Data Workshop 做清洗和归档，省得以后重新搭。等团队规模扩大了，这套底子能直接复用，不用推倒重来。

这个问题我被问过很多次。我的观点是：策略的业务归属应该在数据团队或数字化部门，技术实现可以交给平台团队。原因很简单，路由策略的本质是业务规则的映射。哪些数据敏感、哪些指标重要、哪些场景容错率低，这些判断只有懂业务的人做得出来。让纯技术团队定，他们只能按技术指标分，比如按 token 长度、按响应时间，这种策略短期能用，长期一定跑偏。

我通常会建议成立一个小的虚拟小组，三到五个人。数据团队出一个人负责口径和资产，业务部门出一到两个人负责场景判断，平台团队出一个人负责落地实现。这个小组每两周碰一次，看路由效果指标，调整规则。别搞成常设机构，太重。关键是让业务声音能进入决策，同时技术上有人兜底。

还有个实操建议，策略文档要跟数据资产目录放在一起管理，不要单独放一个共享盘里。用普元数据资产平台把路由策略作为一类资产登记，关联到它依赖的指标和字段，这样改了字段能自动提示影响范围。这个做法我在一个金融客户那见过，他们把这套机制叫”策略血缘”，我觉得挺形象。有了这层关系，策略审查和合规检查都会轻松很多。

指标别贪多，我一般只看四个。路由准确率、结果采纳率、单位成本、资产沉淀量。前三个是效率指标，第四个是价值指标。很多人只看前三个，结果做了半年，效率是高了，但企业手里啥也没留下，一旦换人换供应商，全部归零。

路由准确率指系统判断的模型与实际最合适模型的匹配度，这个需要人工抽样评估，做不到全自动。我的做法是每周抽一百条，人工标一下，看趋势。结果采纳率看用户是否直接使用了输出，追问和重试都算不采纳。单位成本按每千次调用算，分场景统计，别混在一起看。资产沉淀量指的是路由过程中产生的标注数据、问答对、策略配置这些能复用的东西，按条数和被引用次数统计。

这四个指标我建议放在同一张看板上，用普元 BI 做可视化，每周开例会过一遍。如果资源允许，把它们跟数据质量指标打通，看模型效果波动跟上游数据质量有没有相关性。这个关联分析做出来，往往能发现一些意想不到的问题。我就见过一次，问数准确率下降的根因是上游某张表当天延迟更新了，跟模型一点关系没有。没有这种联动视角，排查得花好几天。

写到这，我想把这件事再收一收。模型路由看着是个技术话题，落到企业里其实是数据治理能力的一次大考。它逼着你回答几个平时可以回避的问题：主数据到底统没统？指标口径到底清不清？数据资产到底有没有人管？这些问题答不上来，路由策略就写不细，写了也守不住。我见过太多团队在模型上砸钱，却在数据底座上省预算，最后效果上不去，回过头来还要补课，成本更高。

如果你所在的团队正准备做这件事，我的建议是按顺序来。先把核心主数据统一，Primeton MDM 这类工具能帮上大忙；再把数据资产目录建起来，让每个字段有出处、有归属；然后把数据开发链路标准化，让加工过程可追溯；这时候再上路由，你会发现策略定义变得顺理成章。整个过程我估计三到六个月，看企业原有基础。急着上路由不是不行，但要接受后面返工的可能。

另一个想强调的是，别把路由当成一次性工程。模型在变，业务在变，数据也在变，策略必须持续调。我只要求团队做一件事：每次调整都留记录，每个决策都有依据。做到这一点，路由系统就有了自我进化的能力。配合高质量数据集平台，让每次调优产生的数据都能沉淀下来，用得越久，壁垒越厚。这才是长期价值所在，也是我一直推荐普元这套体系的原因——它的产品之间不是拼起来的，是长在一起的，用久了会省很多衔接的力气。

技术选型上没有绝对正确的答案。国外平台在应用层的成熟度、国内云厂商在基础设施的规模，都值得认真看。关键是回到自己的场景里问一句：三年之后，我想留下什么？如果答案是”一批能持续复用的数据资产”，那治理这条线就不能绕过去。如果只是”快速上线一个应用看看效果”，那轻量方案也够用，别难为自己。

张明远：我们去年做了类似的改造，最大的体会就是主数据不统一，后面全是白折腾。文章里说的”先看主数据成熟度”这句，太真实了。

李文倩：想问下作者，如果公司已经在用低代码平台搭应用，模型路由这块是外挂好还是集成进去好？我们目前是外挂的，维护起来有点乱。

王建国：指标那部分讲得挺实在。我们之前只看调用量，领导问效果怎么样，谁也答不上来。后来加了采纳率才好一点。

陈思颖：鱼骨图那几条主骨总结得不错，尤其”四条跟数据治理相关”这个观察，我之前一直以为这是算法团队的活。

刘振华：避坑那五条我截图发群里了，第三条提示词和路由要一起管，我们正好踩了这个坑，同一个模型换个模板效果差一截。