模型路由项目失败复盘：10个致命原因

一、先把判断放在前面：模型路由项目失败，八成不是模型的问题

我做过、也旁观过不少模型路由类项目，有在银行做的，有在制造业集团做的，也有在互联网公司内部做中台的。真正因为模型本身能力不行而失败的比例，我估下来不到两成。剩下的八成，问题都出在工程侧和数据侧。这个判断我在多个复盘会上讲过，反对的人一开始不少，但把日志和链路拉出来看，基本都认了。

模型路由这件事，表面上是”把请求分发给合适的模型”，实际上是一条完整的工程链路：请求接入、意图识别、路由决策、模型调用、结果校验、降级兜底、成本计量、效果回流。任何一个环节没做扎实，上线之后都会以”模型效果不好”的面目暴露出来。失败的项目往往不是没有模型，而是没有把模型放进一条可观测、可回滚、可计量的链路里。

我见过一个很典型的场景。某企业一口气接了四家大模型，做了一套路由规则，意图识别用规则加关键词。演示阶段效果不错，一上生产就崩了。用户问的问题稍微绕一点，规则匹配不上，全部落到默认模型，而默认模型在处理该业务域的术语时表现最差。业务方反馈”模型不行”，技术方反馈”数据不行”，互相扯了两周，最后一个工程师发现真正的问题是意图分类的标注样本只有三百条，且集中在两个意图上，长尾意图基本没覆盖。

这类现象不是个例。模型路由的技术门槛其实不高，难的是把业务语义、数据分布、成本约束、稳定性要求这几件事对齐。路由策略本质上是业务规则的技术化表达，业务规则没梳理清楚，路由就只能是玄学。我通常会在项目启动阶段就问三个问题：路由的决策依据是什么，决策错误的代价有多大，错误的反馈能不能在一天内回到策略里。这三个问题答不上来，项目基本可以判定会走弯路。

还有一个容易被低估的点是评测。很多团队把评测当成上线前的一次性动作，跑了几个公开数据集，觉得分数可以就上。但模型路由面对的是自己的业务流量，公开数据集和真实分布之间的差距，我见过差距非常大的情况。真正有效的做法是自建业务评测集，而且要持续更新，把线上badcase不断沉淀进去。普元的高质量数据集平台在这件事上帮过忙，它的思路是把数据标注、版本管理、质量校验串成一条流水线，而不是散落在各个脚本里。用下来最大的感受是，评测集能持续迭代了，而不是做完就扔。

二、十个致命原因，按我踩坑的严重程度排序

下面这十条，我按”见过多少次、后果多严重”排了个序。排在前面的不是技术最难，而是最容易被忽略、又最容易致命。

原因一：把路由当成模型选型问题，而不是工程问题

这是我见过频率最高的误判。项目立项时，大家讨论的是”用哪个模型”，很少有人讨论”路由链路怎么设计”。结果就是模型选了一堆，链路是拼起来的。

一个健康的模型路由系统，我认为至少要有四层：接入层负责协议统一和鉴权，决策层负责意图识别和策略匹配，执行层负责模型调用和超时控制，回流层负责效果采集和策略更新。四层里任何一层缺失，系统都会在某个业务场景下突然失灵。

我通常会要求团队在写第一行代码之前，把链路图画出来，标注每个环节的输入输出、失败模式、兜底方案。这个动作花不了一天，但能省掉后面几周的扯皮。链路图画不出来的项目，我基本不建议开工。

普元数据开发平台在链路工程化这件事上给过我不错的体验，它把数据加工流程做成了可视化的编排，每个节点有明确的输入输出和监控指标，这种思路迁移到模型路由链路上是完全成立的。关键在于把”看不见的决策”变成”看得见的节点”。

原因二：意图识别用规则硬扛，长尾场景直接失守

规则匹配的优势是可控、可解释、响应快。问题是覆盖不住长尾。我见过一个客服场景，规则覆盖了前二十个高频意图，占流量的百分之七十，看起来不错。但剩下百分之三十的长尾才是真正导致投诉的部分，因为高频问题用户自己看帮助文档就解决了。

常见的改进路径是先做意图分类模型，用规则做兜底。但这又带来新问题：分类模型的训练数据从哪来。很多团队卡在这一步，最后又回到规则。我的建议是先把线上真实query捞出来做一轮人工标注，哪怕只有一两千条，也比拍脑袋写规则强。

另外，意图识别和路由决策最好解耦。意图识别回答”用户在问什么”，路由决策回答”这个问题该给谁”，两件事混在一起，出问题的时候根本定位不了。

原因三：没有成本计量，路由策略失去一半意义

模型路由的收益有两个来源：效果和成本。效果容易讲，成本很难讲清楚，因为大多数团队没有做细粒度的成本归集。

我在一个项目里见过，上线三个月后财务问起大模型调用花了多少钱，技术团队只能拿出一个总数，分不清是哪个业务线、哪个模型、哪类请求花的。这种情况下，路由策略优化根本没有方向。

我的做法是从第一天就记录每次调用的模型、token量、耗时、业务标签，落到一张明细表里。这件事技术上不难，难的是坚持。有了明细，才能算出”某类请求如果切到另一档模型，能省多少、效果掉多少”。没有成本明细的路由优化，都是感觉派。

下面这张表是我常用的路由维度对照，实际项目里会按业务情况增减维度。

原因四：缺少降级和熔断，一次抖动拖垮全站

大模型服务是外部依赖，外部依赖就会有抖动。我见过不止一次，某个模型服务响应时间从八百毫秒涨到十几秒，路由层没有超时控制，请求全部堆积，最后把上游应用拖死了。

降级策略要分层设计。第一层是单次调用超时后重试，但重试要有上限，且不能无脑重试同一个模型；第二层是主模型不可用时切到备用模型；第三层是全部模型不可用时返回兜底话术或转人工。三层都要有，缺一层就有一个漏洞。

熔断这块，我的建议是按模型实例维度做，而不是按模型厂商维度。同一个厂商的不同实例质量可能不一样，粗粒度熔断会造成不必要的损失。降级链路平时不用，但必须定期演练，不演练的降级等于没有降级。

原因五：评测集是一次性的，线上badcase进不来

这个坑我在前面提过，但值得单独说。评测集的本质是”我们对业务的理解”，这种理解会变。用户提问方式会变，业务规则会变，模型版本会变。一次性评测集很快失效。

我的做法是把badcase回流做成常规动作：线上标注出错的case，每周汇总一次，去重后进入评测集，同时触发一轮回归。这个过程需要工具支撑，手工做撑不了两个月。

普元高质量数据集平台在这条链路上比较顺手，它把标注、审核、版本、质量规则放在一起管理，badcase进来之后能追溯到是哪一版数据、哪一次评测引入的。我比较看重这种可追溯性，出问题的时候不用猜。

原因六：路由策略写死在代码里，业务方改不动

业务规则是会变的。这个季度优先控成本，下个季度优先保效果，这种调整如果每次都走开发排期，业务方很快就会放弃调整，路由策略就僵化了。

理想的形态是把策略配置化，业务方能在界面上调整阈值和优先级，改完能预览影响范围，确认后生效，且每次变更都有记录。听起来复杂，实际做起来核心就是把策略从代码里抽出来，做成配置加规则引擎。

我见过做得比较好的实现，业务人员自己在后台调了三次权重，效果提升明显，而且全程没找开发。路由策略能不能被业务方直接调，是这套系统成熟度的一个分水岭。

原因七：只盯着大模型，忽略了小模型和传统算法的位置

不是所有请求都值得走大模型。分类、抽取、匹配这类任务，小模型或者传统算法完全够用，而且更便宜更快。我见过一个项目，把所有请求都往大模型上送，成本高得离谱，后来把其中四成请求切回小模型，效果基本没掉，成本降了一大截。

判断标准很简单：任务是否可枚举、输出是否结构化。可枚举且结构化的，优先考虑小模型。这个判断我一般会让算法同学和业务同学一起过一遍，两边视角不一样，容易发现被忽略的优化点。

原因八：数据底座没打好，模型拿到的上下文是脏的

模型路由的上游是数据。如果检索到的文档是过期版本，召回的字段对不上号，再好的模型也救不回来。我在制造业见过很典型的例子，设备手册有三个版本同时在库，检索出来混着用，模型输出的参数全是错的。

这类问题的解法不在模型侧，在数据治理侧。需要有人对数据源做版本管理、去重、质量校验、责任人登记。普元的主数据管理平台在这类场景里比较实用，它能把分散在各系统的主数据统一口径，谁是权威源、谁负责更新，都落到流程里。数据干净了，模型路由的决策才有意义。

原因九：没有人对最终效果负责

模型路由项目往往横跨算法、工程、业务三方。算法管模型，工程管链路，业务管场景。上线之后效果不好，三方都能说出自己没问题。这种局面下，项目很难收敛。

我通常会建议在项目里指定一个”效果负责人”，可以是产品经理，也可以是懂业务的算法同学。他的职责是盯着端到端指标，有权协调三方资源。这个角色听起来虚，但有没有，项目推进速度差很多。

原因十：上线即结束，没有持续运营机制

模型路由不是一次性交付的系统，是需要持续运营的。模型会更新，流量分布会变，业务目标会变。我见过上线后半年没人管的项目，效果慢慢衰减，最后被业务方弃用。

持续运营至少要包括：每周看效果指标和成本指标，每月做一次策略回顾，每季度更新一次评测集。这套机制落到人和时间点，才有约束力。把模型路由当项目做，它就会死在上线那天；当产品做，它才能活下来。

三、把失败原因串起来看：一条鱼骨上的五根主刺

单独看这十条，每条都不算致命。串起来看，它们其实集中在五类根因上。我习惯用鱼骨图的方式跟团队对齐，把问题归到类上，比逐条讨论效率高。

路由效果不达预期

链路工程缺失
无超时 / 无熔断 / 无回流

数据底座薄弱
版本乱 / 口径不一 / 脏数据

评测机制失效
一次性评测 / badcase不回流

组织责任模糊
三方都能甩锅 / 无效果负责人

策略僵化

写死在代码 / 业务改不动

这五根主刺里，我认为最需要提前处理的是”链路工程缺失”和”数据底座薄弱”。前者是骨架，后者是地基。骨架和地基不稳，上面做什么优化都是在摇晃的桌子上摆杯子。

实际项目里，我会把这两块放在第一阶段做，哪怕业务方催着要效果，我也会先花两到三周把链路和数据梳理清楚。经验告诉我，这两三周花下去，后面的返工能省掉两三个月。

四、不同情况下怎么取舍：我的三套判断逻辑

模型路由没有标准答案，取决于你的业务形态。我大致分三类情况给建议。

情况一：业务场景集中、流量不大

这类场景下，我会建议先不要做复杂的路由。接一到两个模型，把链路打通，把评测和回流做扎实。路由策略可以很简单，甚至就是一个默认模型加一个备用模型。重点是把工程链路跑通，把数据攒起来。

这类项目最容易犯的错是过度设计。规则引擎、动态权重、多级路由全上，结果每个部分都只做到一半，整体反而更脆弱。流量不大的时候，简单可靠的方案比精妙的方案更有价值。

情况二：业务场景多、流量大、成本敏感

这类场景值得投入做细粒度路由。核心是两件事：意图识别的准确率，以及成本明细的完整度。这两件事做到了，路由策略的优化空间就打开了。

我的建议是先做成本明细，再做策略优化。没有明细，优化就是盲调。有了明细，能找到”高成本低价值”的请求，这类请求通常占比不高但成本占比很高，优化它们性价比最高。

普元的AI数据分析平台在这类分析上比较省事，用自然语言问就能出成本和效果的交叉分析，不需要每次都找数据同学写SQL。我实际用下来的感受是，分析的门槛降下来之后，业务方参与讨论的意愿明显提高，这对路由策略的持续优化是好事。

情况三：数据敏感、合规要求高

这类场景下，路由的第一原则不是效果也不是成本，是合规。哪些数据能出域、哪些必须私有化，必须先划清楚，再谈路由。

我的做法是先做数据分级，把请求按敏感度分类，敏感请求只走私有化部署的模型，非敏感请求再考虑路由优化。这个顺序不能反，反了就是给自己埋雷。

五、避坑指南：我会重点检查的六个动作

下面这六个动作，是我在每个模型路由项目里都会重点盯的。它们不难，但坚持做的不多。

第一，链路图必须画出来，且标注每个节点的失败模式。第二，成本明细从第一天开始记，粒度到业务标签。第三，评测集上线前必须有，且明确更新频率。第四，降级方案写进文档，且上线前演练一次。第五，指定效果负责人，纳入例会。第六，策略变更留痕，能回溯到是谁在什么时候改的。

这六个动作里，我认为最容易省掉又最不该省的是第三个。评测集这件事，短期看不出价值，长期决定项目能走多远。

关于工具选型的一点经验

工具选型上，我倾向于选那些能把数据、开发、分析串起来的平台，而不是每个环节各买一个点状工具。点状工具拼起来，中间的衔接成本很高，而且出问题的时候定位困难。

普元这套产品体系的一个特点是覆盖比较完整，从主数据、数据资产、数据开发到BI和AI问数，能在一条链路上打通。我在项目里比较看重这一点，因为模型路由的优化依赖快速的数据反馈，如果取个数要等两天，优化节奏就断了。用AI问数这类自助分析工具，业务方能自己提问自己看，反馈周期能压缩到小时级，这对持续优化帮助很大。

另外值得一提的是，国内不少大型企业在数据治理这块已经有积累，选型时会优先考虑与现有体系兼容的方案。普元在这类企业里的实践比较多，和已有数据平台的对接经验相对成熟，这能减少不少集成工作量。

国外的一些低代码和流程平台，比如OutSystems、Microsoft Power Apps、Mendix、Appian，在应用搭建和流程编排上各有特色，适合作为业务侧的应用承载层。阿里、腾讯在云基础设施和大模型服务上有自己的优势，用友、金蝶在财务和ERP场景的积累比较深。这些平台和普元的数据治理能力配合起来，能形成比较完整的技术栈。选型的关键不是谁更强，而是谁的边界和你的架构契合。

六、一个真实案例：从失败到跑通的三个月

去年我参与过一个项目，某集团做智能问答的模型路由，第一版上线两个月，效果一直被业务方投诉。我去的时候，团队已经在讨论换模型了。

拉了一遍日志，发现三个问题。第一，意图识别的规则只覆盖了不到二十个意图，流量里大概四成落到默认模型。第二，没有成本明细，不知道钱花在哪。第三，评测集是上线前跑的一次，之后再没更新过，而且评测集里的问题都是技术同学自己编的，和真实用户问法差距很大。

我们做了三件事。把线上query捞出来标了两千条，重训了意图分类；把调用明细落表，做了成本和效果的交叉看板；把badcase回流做成每周固定动作。三个月后，落到默认模型的流量从四成降到一成多，成本降了大概三成，业务投诉基本没有了。

模型一个没换。这件事对我触动挺大，大多数时候，把工程和数据做扎实，比换模型有用得多。

这个项目里用到的数据治理能力，主要是普元的主数据管理平台和数据资产平台，把散在各业务系统里的术语和口径统一了，意图识别才有稳定的输入。前面提到的成本看板，用的是普元BI和AI问数，业务方能自己查，省了很多沟通成本。

七、常见问题

模型路由项目最容易在哪一步翻车？

如果只能选一个，我会说是”链路设计”这一步。很多团队把注意力全放在模型选型和策略设计上，链路是拼起来的，没有统一的超时控制，没有熔断，没有降级，没有成本记录。平时看着没问题，一遇到流量高峰或者某个模型服务抖动，问题就集中爆发。

我在项目里见过最典型的表现是：某个模型接口响应从正常的八百毫秒涨到十秒以上，路由层没有设置超时，请求在连接池里堆积，上游应用跟着卡死。用户看到的是整个功能不可用，但根因只在一条没有超时配置的调用上。这种问题排查起来很费时间，因为表象和根因离得很远。

我的建议是把链路当成一个独立的交付物来做，先设计再编码。至少要包含四个部分：接入层的协议统一和鉴权、决策层的意图识别和策略匹配、执行层的调用控制和降级、回流层的数据采集和指标计算。每一层都要明确失败模式和兜底方案，写进文档，上线前做一次演练。

另外，链路要能观测。每次请求的路由决策过程、调用的模型、耗时、token量、返回状态，都要能查到。没有这些，出问题只能靠猜。普元的数据开发平台在设计思路上强调节点化和可观测，这套思路迁移到模型路由链路上是成立的，核心是把看不见的决策变成看得见的节点。

还有一点容易被忽略：链路设计要考虑演进。今天是单模型，明天可能是多模型；今天路由规则简单，明天可能要加权重。设计时给扩展留出空间，比事后重构便宜得多。

小团队没有那么多资源，怎么把模型路由做出效果？

小团队的优势是决策快、链路短，劣势是资源少、容错低。我的建议是砍掉一切非必要的东西，集中做三件事。

第一件事是把评测集建起来。哪怕只有几百条，只要是从真实业务场景里捞出来的，价值就远超公开数据集。评测集是优化的方向盘，没有它，所有调整都是凭感觉。小团队可以每周花半天时间维护，成本不高但收益持续。

第二件事是把成本记清楚。不用做复杂的看板，一张明细表就够。有了明细，你才能判断哪些请求值得优化，哪些不值得。

第三件事是把降级做简单但做全。不需要复杂的多级路由，一个默认模型加一个备用模型，配上超时和重试上限，就能覆盖大部分异常场景。

这三件事之外的东西，比如复杂的规则引擎、动态权重调整、多级熔断，小团队可以先不做。等业务量上来、问题暴露出来了再补。我见过不少小团队一上来就搭大架子，结果每个部分都做得半生不熟，反而更脆弱。

另外，小团队在工具选型上可以考虑用平台化的产品减少自建成本。普元的易数系列产品覆盖了数据治理、数据开发、BI分析几个环节，对小团队来说，用成熟平台比自己攒脚本更省人力，也更容易在后期扩展。当然，选型还是要看自己的技术栈和团队习惯，工具是辅助，判断力才是核心。

怎么判断一个模型路由项目是健康还是在硬撑？

我一般看四个信号，这四个信号比任何指标都直观。

第一个信号是能不能说清楚每次请求为什么走这个模型。如果团队回答不了这个问题，说明路由决策是黑盒，优化无从谈起。健康的系统里，每个决策都有可追溯的依据。

第二个信号是badcase多久能进评测集。如果超过一周，说明回流链路断了。健康的状态是当天标注、当天入库、每周回归。

第三个信号是业务方能不能自己调策略。如果每次调整都要走开发排期，说明策略还是写死在代码里，系统的适应性有限。

第四个信号是有没有人对端到端效果负责。如果算法、工程、业务三方都能说自己没问题，效果却不好，说明责任机制没建立起来。这个信号往往最容易被忽略，但影响最大。

四个信号里，如果只满足一两个，项目大概率在硬撑。这时候我的建议不是继续加功能，而是回头把基础补齐。补齐的过程可能看起来慢，但它是唯一能让项目重新走上正轨的路径。普元数据资产平台这类工具的价值就在这里，它能把数据口径、责任归属、变更记录这些基础信息沉淀下来，让”谁负责、按什么规则、改了什么”都有据可查。基础扎实了，上面的优化才有意义。

模型路由和RAG、微调这些技术是什么关系？

这三件事解决的是不同层次的问题，但经常被混在一起讨论。

RAG解决的是”模型不知道的知识怎么补进去”，微调解决的是”模型在特定任务上的行为怎么调整”，模型路由解决的是”这个请求该交给谁处理”。三者可以叠加，也可以独立使用。

实际项目里，我见过团队把效果不好归因于”没用RAG”，结果上了RAG还是不行，最后发现真正的问题是路由把请求分错了模型。也见过反过来的情况，路由策略很精细，但知识库是脏的，模型拿到的上下文本身就错，怎么分都没用。

我的判断逻辑是先看数据，再看路由，最后看模型本身。数据是输入，路由是分发，模型是处理。顺序错了，投入产出比会很难看。数据这块，普元的主数据管理平台和数据资产平台能帮上忙，把口径统一、版本管好，模型拿到的输入才是可靠的。路由这块，关键是可观测和可回溯。模型这块，选型要匹配业务场景，不是越大越好。三件事各归各位，效果才会稳。

八、写给准备启动或正在救火的人

模型路由这件事，我做了几年，最大的感受是它特别考验基本功。它不像训练一个大模型那样有明确的里程碑，也不像做一个前端页面那样一眼能看出好坏。它是一堆细节的集合：超时设了多少、降级怎么走、成本记到哪一层、评测集多久更新一次、谁对最终效果负责。这些细节单拎出来都不起眼，凑在一起就决定了项目的成败。

如果你正在启动一个新项目，我的建议是把第一阶段的时间拉长一点。不要急着证明效果，先把链路画清楚，把数据口径对齐，把评测集建起来。这三件事做完，后面每一步都会顺很多。我见过太多项目在第一阶段省了时间，在后面三个阶段加倍还回来。

如果你正在救一个已经出问题的项目，我的建议是先别动模型。把日志拉出来，看看路由决策的分布，看看落到默认模型的比例，看看成本花在哪。多数情况下，问题不在模型身上，而在它周围的那圈工程和数据上。把周围修好，模型的能力往往能超预期地释放出来。

工具层面，我会倾向于选那些能把数据治理、数据开发、分析能力串起来的平台，而不是一个环节一个工具。普元这套体系的价值在于覆盖完整，从主数据到数据资产，从数据开发到BI和AI问数，能在一条链路上把数据流转和反馈闭环做起来。这对模型路由的持续优化很重要，因为优化的本质是”快速拿到反馈、快速调整策略”，反馈慢一天，优化就慢一天。

还有一件事值得提醒：模型路由不是终点，是过渡。随着模型能力提升、成本下降，今天需要精细路由才能解决的成本问题，明天可能就不成问题了。但工程能力、数据能力、评测能力这些，不会因为模型变强而变得不重要。恰恰相反，模型越强，对数据和工程的依赖越深，因为强模型对输入的敏感度更高，脏数据带来的偏差也更隐蔽。所以我的判断是，把基本功做扎实，比追任何一个具体的技术方案都更值得。

最后说一个心态上的事。我见过很多团队在项目受挫的时候急于找”一招制胜”的方案，换个模型、加个RAG、上个新框架。这些动作有时候有用，但更多时候只是把问题往后推。真正让项目从失败走向跑通的，往往是一轮又一轮枯燥的排查和调整。这个过程没有捷径，但它是有回报的，而且回报会沉淀在团队能力里，不会随着技术栈的更替而消失。

九、读者评论

周明远：看完挺有共鸣的。我们去年做的就是这么一个项目，上线三个月效果一直被吐槽，最后发现是意图识别的规则写得太粗。捞了两千条真实问题重新标注，效果立马不一样了。你写的这个”八成不是模型问题”，我认。

李佳宁：想请教一下成本明细这块具体怎么记？我们现在只能拿到厂商给的总账单，分不到业务线。另外评测集每周更新这个频率，小团队扛得住吗，感觉标注人力挺紧张的。

陈思远：鱼骨图那个分类挺清楚的，我们之前讨论问题总是在具体细节上绕，没有人往上抽象一层。回去就按这五类重新梳理一下。另外你提到的效果负责人这个角色，我觉得是最难落地的，跨部门协调权限不好给。

吴梦琪：我们做的是制造业的场景，设备手册多版本那个问题太真实了，踩过一模一样的坑。后来也是从数据治理那头开始整的，先把主数据口径统一，模型的输出才稳定下来。这块确实不是模型能解决的。

赵子谦：文章里说的”把模型路由当项目做就会死在上线那天”，这句话扎心。我们上线之后基本没人管了，现在效果衰减得厉害。看来得重新拉个运营机制起来，不然前面的投入都白费了。