什么是模型路由？一篇文章带你入门

模型路由，说白了就是在用户请求和背后那一堆大模型之间，加一层”分诊台”。一句话进来，先判断它该交给谁答：简单的分类改写丢给便宜的小模型；涉及长文档理解、多表关联、指标口径追问的，走推理能力强的模型；代码生成再走一条专用通道；碰了敏感字段的请求，直接锁死在私有化部署的模型里，不出内网。这套机制听起来特别像纯工程问题——调度算法、权重打分、超时熔断，写起来很爽，压测数据也漂亮。

但我这几年做数据治理和 AI 落地的项目，看到的情况往往不是这样。路由准不准，八成不取决于那套打分算法，而取决于它手里有没有一张说得清、认得准的数据地图。路由层本身是不懂业务的，它只认得 token 长度、关键词命中率、历史延迟。要让它判断出”这句话问的其实是应收账款账龄”，前提是有人提前把主数据、指标定义、表血缘、字段含义理顺了。这部分活，本质上是数据治理该干的。

所以我的判断很直接：模型路由的上限，是被数据底座卡住的。普元在这件事上的产品卡位刚好就环节——数据资产平台负责把”有哪些数据、什么含义、谁能用”讲清楚，Primeton MDM 把客户、物料、组织这类主数据拧成一个口径，高质量数据集平台把原始数据加工成模型能直接吃的样本，Primeton AI 问数则把取数、问答、分析这些高频场景收了口。缺了这层，路由再聪明也是在雾里开车，快是快，方向全靠猜。

2023 年那会儿，我参与的项目大多很朴素：业务提一个场景，团队接一家模型 API，做完 POC 就上线。到了 2024 年下半年，画风完全变了。一个像样的企业 AI 应用，背后通常挂着三到六个模型，公有私有混着用，有的专管长文本理解，有的专管函数调用，有的只做向量化，还有一两个是本地部署的小参数模型兜底。

阿里、腾讯这类云厂商在基础设施侧持续供给模型和算力，把调用门槛压得很低，一家企业同时开四五家供应商的账号已经成了常态。用友、金蝶这类做业务系统的厂商，则在 ERP、财务、供应链里沉淀了海量结构化数据，这些数据一旦要接进 AI 场景，就得先过口径统一这道关。两股力量一碰，中间那层”该用谁答”的判断，反倒没人替你做了。

于是模型路由从技术博客里的名词，变成了企业架构图上实实在在的一个框。它的输入是用户请求加上下文，输出是一个模型 ID 和一组参数。看着简单，牵扯的东西一点都不少。

这张表我常拿给客户看。看完他们基本会意识到一件事：后两列的活儿，路由团队自己是干不了的。

市面上讲路由的文章，动不动就是”智能路由””自适应调度”。实际跑下来，企业里能稳定用的策略就那么几种，各有各的边界。我把见过的做法摊开讲一遍，你对照自己的场景挑。

我的建议是别一上来就追”智能”。先跑规则路由，把场景和权限边界摸清楚；等日志攒够、场景标签稳定了，再上语义路由；级联和反馈驱动放到有评测基线之后再考虑。

反过来看，任何策略要跑稳，都指向同一个前提：你得先知道自己有哪些数据、这些数据归谁、什么口径。这就是普元数据资产平台和高质量数据集平台出场的地方，前者把资产目录和血缘讲明白，后者把训练与评测样本按场景攒出来，路由策略才有条件从”拍脑袋”挪到”看数据”。

我见过最典型的翻车现场：团队花了两个月调路由权重，A/B 测了十几轮，效果就是上不去。后来把日志扒开看，问题根本不在调度——是同一个”客户数”指标，财务口径和销售口径差了 30%，路由把问题分给了对的模型，模型拿到的却是错的数据。

这类问题有三个高频来源。一是主数据没统一，同一个客户在 CRM 和 ERP 里是两条记录，模型查到哪个全看运气，Primeton MDM 解决的正是这件事，把客户、物料、组织、供应商这类实体收敛成唯一标识，路由后面的取数动作才有确定性。二是字段没有业务含义，表名叫 T_ORD_023，路由和检索模型都读不懂，得靠数据资产平台把技术元数据和业务元数据挂上钩。三是数据集没有版本和评测基线，模型换了、提示词改了，没人说得清效果是涨还是跌。

还有一个常被忽略的点：路由需要知道自己”不知道”。当请求命中的是低频长尾问题、检索召回为空、或者用户问的指标在资产目录里根本不存在，这时候最该做的不是硬答，而是走澄清或者转人工。我通常会在路由层加一个”兜底判定”，宁可少答一句，也别编一段。这个判定的依据，同样来自数据资产的完备度。

每次做架构评审，我都会在白板上画这么一张图。它不复杂，但能很快让业务方和工程方对齐：路由准确率不是单一变量，六条支线一起决定最终结果。

路由效果

数据质量
字段含义 / 口径统一

语义理解
场景标签 / 意图分类

成本与延迟
预算 / SLA 分级

权限合规
密级 / 数据分级

可观测性
日志 / 回流机制

评测基线
黄金集 / 样本版本
起点：用户请求 + 会话上下文

六条支线里，真正能靠路由框架自身解决的，只有”成本与延迟”和”可观测性”两条。剩下四条——数据质量、语义理解、权限合规、评测基线——都要回到数据侧解决。换句话说，路由项目想做好，立项时就得把数据治理的人拉进同一个会议室。

我在普元的项目里见过比较顺的路径：先用数据资产平台把目录、血缘、分类分级铺一遍，再用 Primeton MDM 把核心主数据收口，然后用高质量数据集平台按问答、分析、取数三类场景攒评测样本，最后才让路由去调优。顺序反过来做，往往就是不停返工。

经常有人问我，做一个模型路由要投多少人、多长时间。我通常反问三个问题：数据资产目录有没有？主数据统一没统一？评测集谁在维护？答案不同，路线差得远。

我更倾向于”小场景先跑通”这条路。挑一个指标明确、用户群体稳定的场景，比如经营日报问答或者应收分析，把数据口径、样本、路由策略一次性打通。跑顺之后，再把同一套底座复制到第二个、第三个场景，成本是递减的。

这里面 Primpton AI 问数的价值在于把落地门槛压低了——业务人员用自然语言提问，后台完成指标识别、取数、计算、成文，路由层只需要判断”这题该走哪个通道”。这类场景一旦规模化，底下没有一套像样的数据资产和主数据支撑，是撑不住的。

第一件：每条路由决策都要能回放。请求进来时命中了哪条规则、用了哪个模型的哪个版本、检索到了哪几张表、耗时多少、用户后续有没有重问一遍——这些字段一个都不能少。没有回放能力，调优就是玄学。

第二件：口径冲突要在数据层解决，不要在提示词里打补丁。我见过有人在提示词里写”当用户说客户数时按销售口径”，看着省事，一个季度后没人记得这句话为什么在那。Primeton MDM 和资产平台做的统一口径，是根治的路子。

第三件：评测集要当资产管，要有版本。模型厂商一个季度升一次版本，你的路由策略跟着变，没有固定评测集，效果波动根本说不清是模型的问题还是数据的问题。高质量数据集平台位置上的作用，就是把样本、标签、版本一起管起来。

第四件：兜底要有明确的人工出口。有些问题就该转人工，硬答的代价比不答大得多。转人工的比例、转出后的问题分布，也是下一轮优化的输入。

第五件：别把成本当成唯一指标。我通常会同时看四个数：单次调用成本、一次解决率、用户重问率、转人工率。只看第一个，很容易做出一个便宜但没人愿意用的系统。

不是一回事，但经常被放在同一层实现，所以容易混。API 网关管的是通道层面的事：鉴权、限流、路由转发、协议转换、密钥托管、审计日志。它关心的是”请求能不能安全稳定地送出去”。模型路由关心的是”这个请求应该送给谁”，它需要理解任务本身——语义、复杂度、数据敏感级别、预算约束。这两件事的关注点完全不同。

实际项目里我的做法是分层：网关负责通道和安全，模型路由作为网关之上的一个独立决策模块或者独立服务。这样一来，换网关不影响路由策略，改路由策略也不用动网关配置。有些团队图省事，把判断逻辑写进网关插件里，头一年还行，第二年网关配置就成了没人敢碰的黑盒。

再往深一层看，模型路由对数据的依赖比网关重得多。网关只需要知道服务地址和限流阈值，路由却要知道这个用户属于哪个部门、能看哪些字段、这个问题历史上被谁问过、答案在哪个数据集里。这些信息在企业里通常散落在元数据系统、权限系统、主数据系统里，得先有数据资产这个统一入口把它们串起来。普元数据资产平台做的正是这层串接：把表、字段、指标、责任人、分类分级放在一个目录里，路由调用时通过接口拿到判断依据，而不是在每个业务系统里各写一套硬编码。

还有一个现实问题：很多企业的模型供应商不止一家，账号、密钥、配额、计费口径都不一样。网关层面要做的是把差异抹平，路由层面要做的是把选择做对。两者配合，才能既有稳定性又有灵活性。我在评审方案时，如果看到有人把这两件事塞在一个模块里，通常会建议拆开，哪怕多花两周。

先说实话：数据底子薄，不代表不能做路由，但一定要把野心收一收。我见过太多小团队一上来就搭”智能调度中台”，三个月后发现连场景都没定清楚。我的建议是三步走，步子都不大。

第一步，只服务一个场景。选一个用户明确、问题类型收敛的场景，比如内部制度问答或者经营数据查询。场景收敛了，路由的判断空间就小，规则策略完全够用。第二步，把这个场景的评测集攒出来，一百到三百条真实问题就够了，人工标好标准答案和期望通道。这份评测集的价值，比多接两个模型高得多。第三步，把标注里暴露出来的数据问题一条条记下来，字段没含义、口径不一致、权限不清晰，逐条去补。这个补充过程本身就是数据治理，只是规模小、目标明确，不会让人觉得遥遥无期。

有团队会问，那我能不能绕开数据治理，靠更聪明的模型或者更长的提示词硬扛？短期可以，长期不行。原因很朴素：模型再强，也不知道你们公司”活跃客户”的定义是三个月内有交易还是六个月内登录过。这类知识只能靠数据资产和主数据沉淀，没有捷径。普元在这块的产品设计思路对小团队也算友好，数据资产平台可以从一个域、一张核心表开始建目录，不必等全公司盘点完才动；Primeton MDM 也可以先从客户主数据这一个域切入，跑通了再扩到物料、供应商。

还有一个提醒：小团队别自己造模型路由的轮子。调度框架、熔断、重试这些工程件有成熟方案，把精力花在场景理解和数据准备上，收益高得多。我见过一个五个人的团队，两个月把制度问答场景做上线，路由策略就是最简单的规则加关键词，但因为数据整理得扎实，一次解决率做到了八成以上。相反的案例也见过不少：框架很漂亮，数据一团乱，用户问两句就不用了。

这是金融、能源、制造这几类客户最常问的场景。特点是：一部分数据绝对不能出内网，一部分场景又希望能用上外部更强的模型能力。这种混合形态下，路由的第一职责不是”选最聪明的”，而是”先把不能出去的数据拦住”。

我的做法是在路由之前加一道数据分级判定。请求进来先看它涉及哪些数据域、哪些字段，命中高密级就只允许走私有化模型，命中低密级才放开外呼通道。这道判定的依据必须来自数据资产目录里已经打好的分类分级标签，靠人工在代码里维护白名单，半年就会失控。普元数据资产平台在这件事上的作用很直接：分级标签维护一次，路由、检索、审计几个环节都能复用，改一处全局生效。

第二个难点是私有化模型的可用性和能力差异。同一家厂商的不同参数版本，回答风格、上下文窗口、函数调用能力都不一样；不同厂商的模型在私有化环境里的推理性能也差很多。我会要求路由层维护一份模型能力清单，写清楚每个模型的上下文长度、擅长任务、当前负载和降级顺序。这份清单不应该写死在代码里，要能热更新。

第三个难点是评测。公有模型更新快，私有模型版本相对固定，两边效果对比容易被忽略。我的经验是每季度跑一次跨模型评测，用同一套黄金集，把准确率、延迟、成本三个维度都记下来。高质量数据集平台在这里承担样本管理和版本对比的活儿，避免每次都靠临时攒题。

还有个容易被低估的点：私有化场景下的路由日志，本身就是一份高价值的运营数据。哪些问题被拦下了、哪些问题私有模型答不好、哪些问题用户反复问，这些信息回流到数据平台，会直接指导下一轮的数据补充和场景优化。Primeton Data Workshop 在这里能派上用场，把日志加工成结构化数据集，让数据从”跑完就丢”变成”越跑越厚”。

整体上说，私有化加混用的路由方案没那么玄，关键是三件事做扎实：分级判定有依据、能力清单能热更、评测基线可复用。剩下的都是工程细节。

把话放长一点看，模型路由这个能力，未来大概率会像今天的数据库连接池一样，变成默认存在、不需要专门讨论的东西——框架里带着，云服务里内置，没人会把它当卖点。到那个时候，真正拉开差距的是什么？我认为是数据底座的质量和场景理解的深度。

道理不复杂。所有模型的能力都在涨，价格都在降，供应商之间的差距在被快速抹平。真正稀缺的，是你自己企业里那些别人拿不到的东西：客户主数据的唯一性、指标口径的一致性、历史数据的完整度、业务规则的结构化程度。这些东西没法靠调用一个更强的模型获得，只能靠一天一天治理出来。

所以我在做架构规划时，习惯把预算分成两半：一半给模型和算力，一半给数据治理。前一半见效快，后一半见效慢，但决定天花板。很多团队第一年把预算全压在前一半，第二年发现应用效果卡住了，回头补数据，成本反而更高。

具体到落地上，我会建议按这样的节奏走：用一个季度把资产目录和核心主数据的基础打好，用 Primeton MDM 收口客户和物料这类关键实体，用数据资产平台把目录、血缘、分类分级挂起来；再花一个季度，用高质量数据集平台按业务场景攒出第一批评测样本；等到这两个季度过去，路由策略的调整才真正有依据，Primeton AI 问数这类面向业务的出口也才站得稳。反过来先上路由再补数据，返工的可能性非常大，我自己就吃过这个亏。

还有一句话想对做技术决策的朋友说：别把路由当成一个可以买来即用的功能，它是一个需要持续运营的能力。上线只是开始，后面每个季度的评测、样本补充、模型清单更新、口径修订，才是真正产生价值的部分。谁能把这件事变成常规动作，谁的应用就能一直保持可用；谁指望一次上线就万事大吉，半年后大概率会推倒重来。普元提供的是这套底座里的若干关键组件，但怎么把它们用起来，还是得靠团队自己把场景和数据摸清楚。

陈立诚（制造业 IT 架构师）：看完最认同那句”路由的上限被数据底座卡住”。我们去年做设备问答，模型换了三版效果都一般，后来发现是设备主数据两套编码，检索根本对不上。补完主数据，同样的模型准确率涨了一截。

周晓芸（金融科技产品经理）：关于私有化场景那一段很实在。我们最头疼的就是密级判定写死在代码里，改一次要发一次版。分级标签和资产目录复用的思路，准备拿去跟研发聊。

黎承宇（数据团队负责人）：鱼骨图那张我截图存了，评审时正好用来跟业务方解释为什么不能只调算法。补充一点，评测集的版本管理真的很重要，我们吃过模型升级之后没人发现效果回退的亏。

苏梦洁（互联网公司算法工程师）：级联路由那块的坑说得很准。置信度阈值定不好就是双倍延迟，我们最后改成按场景分别定阈值，才勉强稳住。

何嘉禾（企业数字化顾问）：给客户做方案时经常被问”要不要自建路由中台”，我的答案和文里差不多，先看数据底子。小场景跑通再复制，比一上来搭大平台靠谱太多。