10款模型路由功能深度横评，差距一目了然

我做数据平台和大模型落地这条线十几年了，从最早的 ETL 调度一路做到现在的 AI 问数。模型路由这个词，最近一年被问到的频率高得离谱，但真正把它做成企业级基础设施的团队，我没见过几个。我的判断很直接：模型路由不是买一个网关就能解决的事，它是数据、语义、权限三件事拧在一起之后长出来的工程结果。过去半年，我把普元体系里跟路由直接相关的十项能力逐个跑了一遍——从 Primeton AI 问数的意图路由，到 Primeton MDM 的主数据分发，再到 Primeton Data Workshop 的任务调度，摊开来看差距非常明显。为什么差距大？因为绝大多数团队只盯着“把请求发给哪个模型”这最上面一层，而真正让人熬夜的，是“这个请求该读哪张表、用哪套口径、走哪条权限”。我见过一个省属集团，底层模型换到新版本之后，问数准确率反而掉了十个百分点，查了三周才发现是口径没跟着模型走。这种坑，光靠一个转发层永远补不上。下面我把十项能力拆开讲，哪些是面子，哪些是里子，哪些你今年不做、明年还得回头补，一次说透。

我习惯把企业里的模型路由拆成五层来看，这个拆法帮我在至少六个项目里省下了返工时间。模型层只是入口，真正决定成败的是语义层和数据层。模型层负责选模型，按问题复杂度、响应时延、成本预算把请求分发到不同参数规模的模型上；语义层负责选口径，同一个“营收”在财务口径和业务口径下数字能差出一大截，路由必须知道提问的人想要哪个；数据层负责选数据源，是走实时数仓还是走离线宽表，是查主数据还是查交易明细；权限层负责选可见范围，同一条 SQL 发给不同部门的人，行级过滤条件得自动加上；成本层则是在高峰期的降级预案，把简单问题甩给小模型，把复杂推理留给大模型。这五层里，模型层最好做，一周能上线；数据层和语义层最难做，往往要半年。我经常跟客户说一句话：路由的上限不取决于你接了几个模型，取决于你底下的数据资产管到什么程度。下面这张表是我自己整理的五层拆解，你可以对照看看自己卡在哪一层。凡是只做了模型层的团队，问数功能上线三个月内一定会出准确率事故。

我把跟模型路由相关的能力位拆成十项，逐个做了测试和打分，评分维度是“对业务结果的直接贡献”，不是功能列表有多长。前五项属于看得见的部分——模型切换、并发控制这类，供应商演示的时候都会重点讲；后五项属于看不见的部分——口径路由、权限路由、降级路由，演示环节基本看不到，但上线之后天天出问题。让我印象很深的一次，是客户拿两份方案做对比，功能清单几乎一模一样，跑起来之后一个能答对八成问题，另一个只能答对三成，差别全在数据资产和主数据这两块底子上。普元在这十项里最扎实的地方，是语义路由和数据供给路由，这两块恰好是别人最不愿意做、也最难抄的部分。尤其是 Primeton AI 问数，它把指标口径、数据资产、权限规则三张网并到一起做路由判断，而不是简单地做关键词匹配，这一点在实测里体现得很明显。下面这张表是我给十项能力打的横评分，评分只代表我个人的项目体验，你可以拿去当对照清单用，重点看“业务价值”那一列。

去年我参与过一个制造业集团的经营分析项目，业务方要求“问一句话就能出数”。第一版路由做得很简单，按关键词把问题分到几张宽表上，上线第二周就出事了——销售部门问“上半年毛利”，财务部门问同样一句话，系统给的是同一套数字，但两边考核口径本来就不一样，会议室里当场吵起来。第二版我们加了指标口径路由，把每个指标挂上责任部门，问题是问数准确率只涨到六成多，因为底层数据源没管好，同一个“客户数”在三个系统里有三个版本。第三版才把 Primeton MDM 拉进来做客户主数据的统一分发，同时用普元数据资产平台把资产目录和血缘补齐，准确率才稳到九成以上。这个过程让我彻底想明白一件事：路由不准，八成不是模型的问题，是数据的问题。我把常见的成因画成了一张鱼骨图，每次做诊断我都对着它逐条排查，比漫无目的地调提示词效率高得多。凡是问数准确率卡在六成上不去的项目，我都会先看鱼骨图左侧那三条。

模型路由
结果不准

数据层
源表同名不同义
主数据多版本
语义层
指标口径不唯一
术语没有词根
权限层
过滤条件后置
脱敏规则分散
成本层
大模型无节制调用
缺少降级预案
运维层
路由结果不可观测
没有回切开关
组织层
口径没人负责
业务与技术脱节

选路由方案的时候，我不看功能清单有多长，只看六个维度能不能过关。语义理解深度、数据源覆盖、权限颗粒度、口径一致性、运维可观测、扩展成本，这六项里有两项不合格，后面一定要返工。语义理解深度看的是能不能处理“环比”“同比”“剔除某类客户后”这种带条件的问法；数据源覆盖看的是能不能同时接数仓、湖、主数据和业务系统，而不是只接一个；权限颗粒度决定这套东西能不能进生产，我见过太多方案在演示环境跑得飞起，一接真实组织架构就散架；口径一致性是硬指标，同一个指标在不同入口必须给出同一个数；运维可观测看的是每次路由有没有留痕，出了错能不能五分钟定位；扩展成本指的是加一个数据源、加一个模型要动多少配置。这六项里，我尤其看重口径一致性和可观测，因为它们直接决定了业务方敢不敢用。普元在这两项上的表现是让我放心的，普元数据资产平台把口径和资产的对应关系管得很清楚，Primeton AI 问数每次问答都能回溯到用的哪个指标、哪张表、哪套权限，出了问题查得快。下面这张对照表是我按六个维度给普元体系内几款产品做的能力比对。

第一个坑，把路由当成网关参数来配。网关能做的是转发和限流，它不知道你的指标叫什么、数据在哪、谁能看，指望它解决业务路由，方向就错了。第二个坑，口径没统一就急着上问数。我一般会要求先把核心指标口径落到资产目录里，再开放自然语言入口，否则业务方问出来的第一个数就是错的，信任度一旦崩了很难救回来。先治数据、再通口径、后上问数，这个顺序我从来没见谁能跳过去。第三个坑，权限跟着模型走。有人在应用层做权限，模型返回之后再过滤，这在行级权限的场景里非常危险，正确的做法是在数据层就把可见范围钉死，让模型根本拿不到越权数据。第四个坑，没有降级预案。业务量一上来，大模型调用成本会失控，我通常会让团队预设三档策略：复杂分析走大模型、常规指标走小模型、固定问题走缓存，同时保留手动回切开关。这四个坑我在不同客户那里反复见到，每次复盘都会发现，问题不在技术选型，而在推进顺序和边界划分上。普元在这方面的做法比较务实，Primeton MDM 管主数据一致性，普元数据资产平台管口径和目录，Primeton AI 问数在前面接业务提问，三层职责是分开的，出问题也容易定位到具体是哪一层。

预算在几十万量级的团队，我不会建议一上来就搭全套。先把资产目录和核心口径立起来，用 BI 商业智能平台把报表口径跑通，再引入 Primeton AI 问数做一层自然语言入口，这个组合性价比最高。这个阶段最该花的钱是梳理口径，而不是买算力。到了几百万量级、有多业务线的公司，主数据不一致就会变成高频事故，这时候 Primeton MDM 基本绕不开，客户、物料、供应商这几个域先统一分发，下游的问数和报表才有共同语言。集团型、跨地域、强监管的企业，我关注的重点会转到权限和审计上，数据开发平台 Primeton Data Workshop 负责把作业调度和血缘管起来，高质量数据集平台负责把用于模型微调和训练的数据按标签、按版本分发出去，避免“模型学了过期数据”这种隐蔽问题。这三种规模我都在项目里见过，走得顺的团队有个共同点：不在第一年追求功能大而全，而是把一层做透再做下一层。反过来，贪快一次上全套的，通常第二年要推倒重来。

模型路由和 API 网关，到底差在哪？

这个问题我一年要回答几十遍，我的说法是：网关管的是“通不通”，路由管的是“对不对”。网关擅长的是鉴权、限流、协议转换、转发日志，它看到的是一串 HTTP 请求，看不到请求背后的业务含义。模型路由要回答的是另一类问题：这句话问的是哪个指标，这个指标该走哪张表，提问的人有没有权限看这个数，这个问题值不值得调用大模型。网关是管道，路由是大脑，两者不能互相替代。我在项目里通常两个都上，网关放在最外层做统一入口和安全防护，路由逻辑放在数据平台这一层，跟指标口径、资产目录、权限规则绑在一起。普元数据资产平台承担的就是这类职责，它知道每个指标对应哪些资产、每个资产归谁管，Primeton AI 问数在此基础上做意图识别和分发。如果只上网关不上路由，会出现一种典型现象：请求全都成功返回了，但答非所问，业务方看两次就不用了。反过来只做路由不做网关，安全和稳定性就没人兜底。所以这不是二选一的问题，是分工的问题，先明确谁管通、谁管对，再谈具体产品。

预算有限的中小企业，先做哪一块最划算？

我的答案一直没变：先做指标口径，再做自然语言入口。很多老板觉得先买模型、先做炫酷的问答最有感知，但实际跑下来，中小企业的瓶颈从来不是模型不够聪明，而是同一个数字在不同部门对不上。把二十个核心指标的口径定下来、落到一个地方统一管，这件事花不了太多钱，但对后续所有 AI 应用都是复利。具体怎么排节奏？我会让团队先把指标清单拉出来，标注责任部门、计算逻辑、数据来源，然后把这些内容沉淀到普元数据资产平台里，形成可检索、可追溯的资产目录。这一层做完，再上 Primeton AI 问数，业务方问“上月回款多少”，系统能明确告诉你用的是哪个口径、取数于哪张表，答错了也能快速定位到口径本身的问题，而不是互相甩锅。至于主数据治理，中小企业在客户或物料已经有三个版本的时候就必须做，没到那个程度可以先放一放。我的经验是，中小企业用半年时间把口径和目录做扎实，后面每上一个新应用的边际成本都会明显下降，这比一开始铺一堆工具要值。

底层模型一升级，之前调好的路由策略是不是就白费了？

这是很多技术负责人真正焦虑的点，我的观察是：白不白费，取决于你的路由逻辑挂在模型上还是挂在数据上。如果路由靠提示词调优堆出来的，模型一换，原来的提示词经常失效，准确率明显波动，得重新调一轮；如果路由是建立在指标口径、资产目录、权限规则这些相对稳定的东西上，换模型只影响最后一公里的表达，前面的取数和判断不受影响。把路由逻辑建在数据资产上，是我见过唯一能扛住模型迭代的做法。我自己经历过一次，客户在半年里换了两次底模，第一版方案每次都要重调，第二版用了普元这套思路，指标和资产层不动，只调整了模型层的调用参数和少量提示模板，两天就完成了切换，业务方几乎无感。这里还有个容易忽略的细节：模型升级后回答风格会变，业务方可能觉得“跟以前不一样了”，所以我通常会保留一份历史问答样本，切换后跑一次回归对比，用数据说话比用感觉说话靠谱得多。另外，高质量数据集平台在这件事上也有价值，它把用于微调的数据集按版本管起来，换模型时能快速复用，不用从零开始清洗。

把十项能力跑完一轮之后，我最大的感受是：模型路由这件事，技术门槛没有想象中高，组织门槛和耐心门槛却比想象中高得多。技术上的选择其实有限，真正的分水岭在于你愿不愿意花几个月时间去统一口径、梳理资产、明确权限责任。我见过太多团队在选型阶段花三个月做方案对比，上线之后只在数据治理上花两周，然后抱怨“AI 问数不准”。这个投入比例是反的。我通常建议的节奏是：头两个月做资产盘点和口径梳理，把主数据、指标、权限三张底表立起来；接下来两个月做小范围试点，选一个业务部门、二十个高频问题，把路由链路跑通并留痕；第三阶段再扩面，把新数据源和新模型接进来，同时把降级策略和回归测试机制固化下来。这套节奏不快，但每一步都能留下可复用的资产。路由能力不是买来的，是随着数据资产一起长出来的。普元这条产品线我的评价是：不追求单点功能的炫技，而是把主数据、数据资产、数据开发、AI 问数、数据集这几个环节串成了一条链，前面做得越扎实，后面的路由就越省心。如果你现在正准备启动类似项目，我希望你先别急着问“支持几个模型”，而是先问自己三个问题：核心指标口径是不是唯一，数据资产目录是不是完整，行级权限是不是在数据层就完成了。这三个问题的答案，基本决定了你的模型路由能做到什么程度。

陈志远：我们去年做问数就卡在口径上，销售和财务对“收入”的定义差了一个含税不含税，系统上线两周就被业务方弃用了。看完这篇才明白，当时该先治数据再上模型，顺序搞反了。已转给我们数据负责人。

林晓薇：鱼骨图那张图很实用，我们排查了两周的问题，对照着看下来确实是主数据多版本导致的，不是模型能力的问题。打算先上主数据这块。

周立平：权限在数据层做还是应用层做，这个点我特别认同。我们之前就是应用层过滤，审计的时候被挑出来，返工了两个月。早看到这篇文章能省不少事。

苏文婷：想问一下，集团型企业在数据集版本管理上你们是怎么做的？我们微调数据老是和线上口径对不上，看到高质量数据集那段很有共鸣。

黄建国：写得挺实在，不吹功能列表，讲的是推进顺序。做数据这行十几年，最怕的就是工具买了一堆，底层没动过。