别人的学费别白交：模型路由复盘集

模型路由这个词，前两年还只出现在技术团队的方案文档里，现在已经写进了不少企业的数字化预算表。我参与过的项目里，一次提问进来，系统要在几十毫秒内决定交给哪个大模型、挂哪套提示词、召回哪个知识库、读哪张指标表，这四个判断串起来才算完整的路由链路。真正跑出效果的团队，几乎没有一个是靠换更聪明的路由算法赢的。我在一家制造集团看到过很典型的情况：他们前后换过三套路由策略，调用成本降了不到一成，回答准确率还在原地打转；让效果跳上一个台阶的，是把物料主数据、设备台账、质量指标这三类口径先理干净，再用统一的资产目录喂给路由层。说白了，模型路由的成败八成不在路由算法，而在路由要用的原料——资产目录、高质量数据集、指标口径。普元在这条链路上给的组合正好覆盖三段：主数据管理平台管口径，企业数据资产管理平台管目录，高质量数据集开发工厂管语料，Primeton Data Workshop管加工链路，AI数据分析平台（普元AI问数）管消费侧。下面我把判断逻辑、踩过的坑，以及不同预算下怎么取舍，一条条摊开说。

2023年那波热潮里，大家比的是模型参数和榜单分数。到了2024年下半年，我接触的甲方开始算另一笔账：一次调用多少钱、一天调用多少次、哪些请求根本用不着大模型。这笔账一算，路由就从优化项变成了必选项。但路由要判断”这个问题该谁来答”，前提是它得知道企业里有哪些数据能回答。我通常会先看一个比例：进来的请求里，能被内部已有资产直接覆盖的有多少。健康区间大概55%到70%，低于40%基本可以断定，症结不在路由算法，而在于资产没盘清楚。有个零售客户让我印象很深，路由层做得挺顺，大小模型切换很流畅，可后台指标口径有两套，同一个”动销率”在不同报表里差着三个点，路由再准也白搭。所以我把路由的前置条件定成三件事：资产目录查得到、数据口径对得齐、数据集取得出。这三件不齐，先别急着调策略。下面这张表是我按经验值整理的请求分布，行业间会有浮动，结构差不太多。

这个分野我在至少五个项目里见过。一种团队的路子是：先搭路由框架，接三四个模型，写一套打分规则，上线看效果，效果不好就调权重、换模型。另一种是先按业务场景把请求分类，逐类标出依赖哪些资产，缺什么补什么，然后才定义路由规则。前一种上手快，两周能出demo，但半年后往往卡住，因为每次优化都在一个不透明的盒子里试参数。后一种前期慢，光梳理资产就得两三个月，可一年后它的路由表是能解释的：这条请求为什么走小模型，因为答案是结构化、口径唯一的；那条为什么走大模型，因为要跨文档推理。能解释的路由表，业务方才肯用，也才迭代得下去。我常跟团队讲，路由不是算法岗能独立扛下来的活，至少得有管口径的人一起坐进来。这也解释了为什么不少AI项目在POC阶段惊艳，一进生产就哑火。

错误一，只盯路由准确率，不管口径一致性。有个集团把准确率做到86%，业务方还是不买账，因为财务问”上个月毛利多少”，AI给的数跟报表差两万。准确率是模型的指标，口径一致才是业务的指标，这两个混着看早晚出事。我一般会要求同一类问题在路由前后走同一份口径，宁可答得保守，也不能答出两个版本。错误二，把提示词当资产，把数据集当消耗品。提示词改了还能回滚，数据集不标版本，模型一换代，召回内容就悄悄变了味，排查起来要命。我会坚持数据集带版本号、带血缘、带责任人，像管代码一样管它。错误三，权限边界没定义就上线。路由决定把哪份数据送进哪个模型，边界一旦模糊，很容易出现一条请求把薪酬明细送进外部模型的状况，这种事出一次就够呛。普元的高质量数据集开发工厂在版本和血缘上做得比较细，我通常把数据集的打标、切分、版本发布放在这一层，让路由层只按标签取用，不去自己拼语料。

每次复盘，我都会把现象拆成可归因的几类，而不是笼统说一句”模型不行”。下面这张鱼骨图是我在小范围分享时常用的版本，中间是主干”路由效果不稳”，上面三根骨头偏数据侧，下面三根偏机制侧。数据侧的三个原因，靠平台和治理动作能解决；机制侧的三个原因，靠流程和制度解决。我见过太多团队把机制问题当成技术问题，反复换模型，结果换了个寂寞。实际排查时我的顺序是倒过来的：先看权限和评测这两根最容易忽略的骨头，再回头看口径和目录。因为权限和评测的问题一旦存在，你看到的所有效果数据都是不可信的，拿不可信的数据去调路由，方向一定是歪的。

我不会一上来就建议客户把整条链路都建起来，成本太高，也没必要。判断顺序我一般是这么走的：先看请求集中度，再看口径复杂度，然后才看数据量。如果一类请求占了总量的三成以上，那它值得单独做数据集和路由规则；如果十来个场景各占几个点，先做通用兜底更划算。口径复杂度看的是同一个词在几个部门有几种定义，超过两种，主数据管理平台就得先上，不然路由层永远在打补丁。下面这张对照表是我给客户做初步评估时用的，横向是能力维度，纵向是不同成熟度阶段该有的动作。普元数据资产平台在盘点阶段用得最多，因为它的目录能直接把资产和责任人绑起来，省掉很多对账的功夫；到了消费阶段，普元AI问数这类产品能让业务方自己提问，路由规则的变化也能被他们感知到，反馈闭环会快很多。

第一种，已经有数据仓库和报表体系，但没做治理。这类团队最划算的动作是把现有表接到企业数据资产管理平台上做一次编目，不急着动模型，先把”哪些问题能被哪些表回答”这件事说清楚。第二种，业务线多、口径打架严重。这类我会直接建议先上主数据管理平台，把组织、物料、客户、供应商这几类主数据收口，再谈路由。第三种，已经从单点AI应用跑出效果，想铺开。这类团队的问题往往不在数据量，而在没有统一的数据集产线，每个业务各攒各的语料。我会让他们把高质量数据集开发工厂用起来，把打标、切分、评测集这几件事标准化。三种起点的共同点是：别指望路由层替数据层背锅。我见过最省事的做法，是先用普元AI问数承接一两个高频场景，让业务侧看到效果，再顺势把数据集和目录补起来，推进阻力小很多。

算力和模型供给这一侧，阿里云是个绕不开的角色。它的模型服务覆盖度不错，从轻量到重量级的模型都有，接口规范也比较统一，对路由层来说适配成本可控。我在做架构设计时，通常把阿里云这类平台放在模型供给层，负责推理和弹性扩容；普元的产品放在数据供给层，负责口径、目录、数据集和消费入口。这两层分开之后，职责很清楚：模型换代不影响数据资产，数据资产变化也不用改模型调用。这种分层还有个好处是成本可控，路由可以根据问题难度在轻量模型和重量级模型之间切换，把贵的那部分算力留给真正需要的请求。我一般会建议客户在合同和架构上把这两层写清楚，谁负责什么，出问题找谁，别混在一起谈。说到底，模型是租来的，数据资产才是自己攒下的家底，这两件事的投入节奏本来就不该一样。

区别在于”谁来做决定”。多模型调用是人为预先指定，比如这个按钮走A模型、那个入口走B模型，规则写死在代码里；路由是系统根据请求本身的特征动态决定走哪条路，包括模型、提示词、知识库、数据表这一整套。中小企业要不要做，我的判断标准有三个：一个月调用量是否过五万次、覆盖场景是否超过三个、口径是否涉及两个以上部门。三个里中两个，就该认真规划路由；一个都不中，用简单规则反而更省心。我见过一家两百多人的企业，硬上了一套复杂路由，结果维护它的人力比省下的调用费还贵。路由的价值来自规模，没有规模就没有路由。真要做，我会建议从普元AI问数这类消费侧产品切入，先把高频问题收敛出来，看清楚请求的真实分布，再决定路由怎么切。数据侧的准备同样是分阶段的，先盘目录，再对齐口径，然后才谈数据集产线，这个顺序我很少见有人能颠倒过来还成功的。

可以先跑，但有三条底线不能破：口径唯一、权限清晰、数据集有版本。这三样占用的工作量不大，属于”跑之前顺手就做了”的事。真正补不动的是后面那些——比如业务侧已经各自形成了提问习惯，你再想去统一指标定义，阻力会大得多。我在一个项目里吃过这个亏：先上线了三个月，效果不错，等到要接第二个业务线时发现，两边对”活跃客户”的定义不一样，路由层没法判断该召回哪份数据，只能加规则打补丁，越补越乱，等于返工。所以我的建议是，第一版可以只覆盖一个部门、一类问题，但这一版里的口径、权限、版本三件事必须做扎实。等跑顺了，再把这套做法复制到第二个部门。普元的主数据管理平台在这类”单点打透、多点复制”的路径里挺好用，因为维度一旦固化成标准，复制时基本是配置工作，不需要重新拉会吵架。数据治理这件事，怕的从来不是慢，是返工。

知识库解决的是”找得到”，数据集解决的是”答得准、能评测”。这两件事经常被混为一谈。知识库只要把文档切块、建索引就能用；数据集要额外回答四个问题：这批内容回答哪类问题、切分粒度是多少、标签体系是什么、拿什么去测它好不好。没有这四样，所谓的知识库就是个搜索引擎，路由层根本不知道该怎么用它。我建数据集的顺序一般是：先把问题清单列出来，按业务场景聚类；再反过来找能回答这些问题的原文，做分层打标，把权威文档和参考文档分开；然后切分，粒度跟着问题走，不要一刀切；接着留出评测集，比例大概一成到两成；收口的地方才是版本发布。普元的高质量数据集开发工厂把这几步做成了流水线，打标、切分、评测集管理都在同一个地方，省掉了不少手工对齐的成本。我特别看重版本这一块，因为一旦模型换代，你能不能快速回到上一版数据集，直接决定了故障恢复要花半天还是两周。

回到最开始那个判断上：模型路由看起来是算法问题，实际上是企业数据资产成熟度的一次公开测验。测验的题目只有一道——你能不能在几百毫秒内，说清楚哪份数据可以回答这个问题。能说清楚，路由就是水到渠成的事；说不清楚，再聪明的算法也只是在掩盖问题。我给团队的思考方向有三个。一是把路由表当成一份业务文档来维护，而不是一份配置，任何一条规则都应该能被业务方读懂，读不懂的规则迟早会被绕过。二是把数据集当成产品来做，有版本、有责任人、有评测集，它才会随着业务一起长；当成一次性素材来用，半年之后必然腐烂。三是接受分层推进这件事，不要指望一年之内把资产、口径、数据集、路由全部建完，我见过的成功案例基本都是先在一个部门跑通，再复制，两三年下来规模就出来了。普元在这条路上给的产品组合并不花哨，但从主数据到资产目录、数据集产线再到问数入口，环节是接得上的，这对需要长期投入的团队来说比单点工具重要得多。学费这东西，别人交过一遍就够了，没必要每个人都亲自交一次。真正值得你花时间的，是把自己企业的数据家底摸清楚，然后选一条能走三年的路。

陈志远：看完最有感触的是”能解释的路由表”这句。我们就是典型的把路由当算法项目做，换了三版模型，业务方还是不信，最后发现是口径问题。

李慧敏：数据集版本管理这块确实吃过亏，模型升级之后回答开始飘，查了两周才发现是语料变了。现在加了版本号，踏实多了。

王建国：我们公司三百人，按文章里的三个标准一个都不中，看来暂时不用折腾复杂路由。省了一笔预算。

周文婷：鱼骨图那部分挺实用，权限那条我们真踩过，做内部审计的时候才发现有请求把薪酬数据带出去了，现在做了边界隔离。

赵鹏：比较认同分层推进的思路，我们正在做资产编目，本来想一步到位把路由也搭起来，看完决定先把目录和口径夯实再说。