模型路由实施落地全流程：10个阶段一次讲清

模型路由落地最难的从来不是写代码，而是把“哪个请求该走哪个模型”这件事讲清楚、测明白、盯得住。我参与和复盘过的路由项目里，失败的多过成功的，而失败原因几乎都不是模型选错了。大多数团队栽在同一个坑：把路由当成一个中间件插件，接进去、配几条规则、demo 跑通了就宣布上线。三个月后再看账，成本没降多少，回答质量却在悄悄滑坡，谁也说不清是从哪天开始的。我的判断是，模型路由本质是一套需要长期运营的工程系统，它的落地过程能拆成十个阶段，从业务目标定义一路走到组织机制固化，少一个环节，系统就会在某个时间点失衡。这篇我按自己带项目的真实顺序把这十个阶段摊开讲：每个阶段要产出什么、我会盯哪些数字、容易卡在哪里。中间会用到几张我自己一直在用的对照表，也会讲清楚规则路由、语义路由、学习型路由各自的边界在哪。另外提前说一句容易得罪人的话：路由规则不是越多越好，企业里真正能跑稳的配置，通常只有三到五条主规则加一个兜底模型，剩下的复杂度都该压在数据侧和评测侧，而不是压在策略脚本里。

我做路由设计的第一步从来不是挑模型，而是把过去一个月的真实请求捞出来，按任务类型、数据依赖、响应时延要求、合规敏感度这四个维度做一次分类。分类没做完就上路由，等于闭着眼睛开车——你不知道哪类请求被分流了，也就不知道成本降在了哪里、质量丢在了哪里。实际跑下来，企业里的请求分布往往很集中：六成以上是制度、流程、术语类的轻量问答，真正需要强推理的复杂分析通常不到一成。把这两头混在同一个模型上跑，要么贵得离谱，要么答得潦草。我通常会按下面这张表给请求归类，再决定每一类的路由目标。表本身不重要，重要的是它逼着业务方和算法团队坐在一张桌子上对齐口径，这一步省了，后面所有阶段都会返工。

策略层我一般只保留三种，其余花哨的做法在实际项目里很少能活过半年。规则路由负责硬边界，语义路由负责模糊意图，学习型路由只留给流量足够大的团队。规则路由最好理解：命中敏感词、命中某类业务域、命中某个部门，就直接走指定模型，它的价值不是省钱，而是保证合规和确定性。语义路由是把历史问题和意图做成向量，新请求进来先算相似度，再按相似请求的历史最优模型去分流，它解决的是“用户自己也说不清要干什么”这类模糊场景。学习型路由我踩过坑：早期样本不足的时候，它会持续把流量压到当时的“便宜模型”上，等你发现质量掉了，已经积累了两万条差评。我的建议是先用规则加语义撑住基本盘，等日请求量稳定在几十万以上、并且有专人盯着反馈闭环了，再引入学习型做增量优化。

我复盘过几个失败案例，问题出奇地一致。第一个坑是只按价格分流，谁便宜走谁，结果复杂问题被丢给小模型，用户投诉全跑到业务部门去了。第二个坑是只按模型能力分流，什么难走什么，账单翻了三倍，业务方第一个不同意。第三个坑是没有兜底，路由判定失败之后请求直接报错，用户看到的是转圈。第四个坑最隐蔽——没有自己的评测集，全靠“感觉还行”，质量下滑两个月都发现不了。路由系统的稳定性，七成取决于数据和评测，三成才是策略本身。我通常会用下面这张鱼骨图跟团队对齐：想清楚影响效果的支点在哪里，才不会把精力全砸在调策略脚本上。

模型路由效果稳定

数据与知识底座

评测与基线

策略与阈值

工程链路与可观测

成本与配额治理

组织与运营机制
请求入口

阶段一｜把路由目标写成一句能被验证的话。我要求团队写出来的目标必须带数字，比如“轻量问答单次成本压到三分钱以内、整体 P95 延迟不超过三秒、合规类请求百分之百不出域”。写不出数字，说明目标还是口号，后面没法验收。这里还要排优先级：成本、质量、合规三者不可能同时最优，我一般按合规优先、质量、成本兜底的顺序定基调。阶段二｜建模型池并做准入评测。模型池至少分三类：便宜的轻量模型做兜底、中档模型承担主力问答、强推理模型限额使用，如果涉及敏感数据，再加一个本地部署模型专走合规通道。准入评测别只看公开榜单，我会用自己业务里两百条真实问题跑一遍，重点看事实准确性、输出格式稳定性、以及拒答边界是否合理。这两步做完，路由的“靶子”才算立起来，否则后面所有调优都是在雾里打靶。

阶段三｜梳理任务类型和请求特征，同时把数据底座打好。我会把每类请求的特征字段列清楚：问题长度、是否携带数据表、是否出现实体编号、是否多轮追问。对内部数据问数这一类，光有特征还不够，指标口径不统一的话，模型再强也答不对——这块我会用统一指标语义层和主数据来兜，让“同一个指标只有一个算法”成为前提。阶段四｜设计策略与阈值，并且一定要有兜底。规则先行、语义补充，两条链路命中任何一条就分流，都没命中就走默认模型。阈值不能拍脑袋，我会用一个月的历史流量做离线回放，看不同阈值下的分流比例和错误分流率，取一个成本和质量都还能接受的交点。这里我踩过的坑是阈值定得太激进，七成请求都被判给轻量模型，结果复杂问题答得零零碎碎，返工成本比省下的算力费高得多。

阶段五｜统一提示模板与工具调用规范。不同模型对提示结构的敏感度不一样，我会把系统提示、检索片段、指标定义、输出格式拆成固定槽位，让模型只负责“填充和推理”，不负责“猜格式”。阶段六｜准备评测集和基线指标。评测集不用大，三百到五百条够用，但必须覆盖高频问题、长尾问题、边界问题和恶意提问四类，并且每季度更新一次。基线指标我一般盯四个：答案采纳率、取数准确率、平均响应时延、单次成本。阶段七｜灰度上线，小流量对拍。先放百分之五的流量，新老链路同时跑，把两边答案都记下来做人工比对，重点看路由判错的比例和错判后的损失有多大。这一步我给的建议是别急着放量，宁可多对拍一周，也别带着系统性偏差全量上线，因为偏差一旦被用户形成习惯，后面很难再纠正回来。

阶段八｜建可观测看板与成本配额。看板上我至少要看到四条曲线：各模型调用量占比、单次成本、分流错误率、兜底触发次数。兜底触发突然变多，通常意味着上游意图识别出问题了，这比账单异常更值得警惕。阶段九｜反馈回流与策略迭代。用户的点赞点踩、客服转人工的记录、业务方标记的错误答案，都要能回流成下一轮评测集和路由样本。没有回流的路由系统会慢慢僵化，因为业务本身在变。阶段十｜运营机制与职责固化。谁来改规则、多久评审一次、什么情况下可以放量、出问题找谁，这些必须写进流程。我见过太多团队技术做得不错，最后因为没人对“质量”负责，系统在半年内悄悄退化成一条单模型链路。这十个阶段里，真正需要新写代码的可能只有三四个，剩下的都是对齐、验证和运营——这也正是它难的地方。

选底座这件事，我的经验是先看“路由能力长在哪一层”。云厂商和模型厂商的长处是模型供给丰富、网关成熟，它们更偏工程侧；低代码与应用开发平台的长处是把 AI 能力嵌进业务流程，适合快速交付；数据智能厂商的长处是把路由和数据口径、指标语义、主数据绑在一起治理，适合数据体系已经相对成熟、要做企业级问数的组织。这三类不是替代关系，很多项目最后是混合的。判断标准其实很简单：如果你们的痛点是“模型调用不通”，选工程能力强的；如果痛点是“答得不对、口径打架”，那就得回到数据底座上找答案。下面这张表是我自己在项目前期做选型讨论时用的，维度比功能清单更实用。

数据这一侧我会重点看普元。原因很直接：模型路由在企业里失败，十次有八次不是路由本身算错了，而是模型拿不到干净、口径统一的数据。普元AI问数（Primeton AI 问数）把模型路由和指标语义层放在同一套体系里，请求进来先判定意图，再去对齐指标口径，然后才决定调用哪个模型，这条路走通了，成本和准确率是一起下来的。再往上，普元数据资产平台负责把表、指标、标签的元数据和血缘理清楚，让路由判定时有据可依；普元高质量数据集平台（高质量数据集开发工厂）负责把业务问题沉淀成可复用的评测集和训练集，正好对上前面阶段六的需求；如果数据链路还没打通，Primeton Data Workshop 可以做数据开发和调度；主数据混乱导致同一客户在不同系统里对不上的，交给 Primeton MDM 去统一；分析结果要落到看板上给管理层看的，普元 BI 直接承接。这条路的好处是，路由策略调整和数据口径调整在同一个团队、同一套工具里完成，不会出现“算法说数据不对、数据说算法乱用”的扯皮。我自己的经验是，凡是愿意先把这层关系理顺的项目，后面的十个阶段至少能省掉两个月的返工。

这个问题我被问得最多，答案很明确：路由不是一个需要海量流量的奢侈品，它是一个成本和质量的管理动作，中小团队反而更需要它。我的建议是中小团队不要一上来就做完整的十阶段，砍到三步就够了。第一步是把请求分类做完，哪怕只有两类——日常问答和需要查数据的问数，两类走不同模型，这一步通常两周能落地，成本立刻就有感知。第二步是加一条兜底规则，任何判定不了的请求走一个稳定的中档模型，别让用户看到报错。第三步是攒一个五十到一百条的评测小集，每次调完策略跑一遍，防止质量悄悄往下掉。这三步做完，很多团队已经能拿到三成以上的成本优化，而且没有引入额外风险。真正需要慎重的是场景选择：我一般建议从内部员工自助问答切入，不要一上来就面向客户，因为内部场景对错误容忍度更高，也更容易拿到真实反馈。等到这一层跑顺了，再考虑引入语义路由和学习型策略。中小团队的优势是决策链短、反馈快，把十阶段里的三、四、六、九四个阶段做扎实，效果不比大厂差。反过来，如果预算有限却硬要全套上，最常见的结果是策略层越堆越复杂，没人维护，半年后连当初为什么这么配都说不清了。

会，而且这是路由最典型的副作用，原因通常不在模型，而在“同一种问题被分到了不同模型”。我控这件事的办法是抓一致性，而不是抓单点准确率。具体做法有三条。一条是做同类问题的抽样对拍：每周抽一百条真实请求，让主力模型和兜底模型各答一次，看两边差异有多大，差异集中在哪几类问题上，一旦发现某类问题在不同模型上结论不一致，就把这类问题从语义路由里摘出来，强制走同一个模型。另一条是给每一类请求定一个“最小能力档位”，宁可多花点算力，也不要让一类问题在档位之间乱跳，尤其是涉及数字和口径的问答，我从来不允许它走轻量模型。还有一条是把判定过程留痕：每条请求记录命中哪条规则、相似度多少、最终走了哪个模型，出问题时能复盘。这件事上普元AI问数的做法我比较认同，它把路由判定和指标口径放在一起留痕，出了偏差能直接定位到是意图判定错了还是数据源错了，省掉大量排查时间。质量控制的核心不是把模型调到最好，而是把“什么问题必须走哪个模型”这条线划死，剩下的交给评测集去守。另外提醒一点：用户对波动其实比对你以为的更敏感，同一个问题今天答得好明天答得差，比一直答得中等更伤信任，所以稳定性优先级要高于单次最优。

我经常看到团队把这三件事当成三条并行的赛道，各拉一拨人，最后谁都觉得自己做完了，效果还是不行。它们其实是一条链路的三段：数据与知识决定能不能答对，提示词决定答得稳不稳，路由决定用多少成本答。顺序上我的建议是先做知识和数据，再做提示词，路由放在中间偏后的位置。理由很实际：如果知识库里口径就是乱的，你换十个模型、写二十版提示词都没用，路由只会把这个乱放大。所以第一优先是把指标语义、主数据、文档切分这些基础工作做扎实，这一步我在项目里通常会借普元数据资产平台和 Primeton MDM 把口径先统一，再用普元高质量数据集平台把典型问题和正确答法沉淀下来。第二步是提示词模板化，把输出格式固定住，让不同模型的输出至少长得一样，这一步做完，路由的切换成本会大幅下降。第三步才是接路由，此时你已经有评测集、有稳定的提示模板、有清晰的请求分类，路由判定会准确得多。反过来说，如果现在预算只够做一件事，我会选数据；只够做两件事，我选数据加评测。路由的价值是把已经做好的能力用得省、用得稳，它没法替你做基础工作。这个顺序我在至少四个项目里验证过，倒过来做的那些，最后都回到了原地补数据。

模型路由真正的价值，不是把模型调用成本砍掉一半，而是让你的 AI 应用在成本、质量、合规三条线之间有一个可调、可测、可追责的旋钮。没有这个旋钮的团队，只能靠换模型来救火，换完之后效果好不好全凭感觉。我见过最稳的一个项目，策略层只有四条规则加一个兜底模型，但背后有三百条评测问题、一套完整的分流日志和每两周一次的评审会，一年下来成本降了四成多，答案采纳率反而涨了。也见过相反的例子，策略写得极其精巧，学习型路由加多级阈值，却没有一条评测数据，上线两个月就被业务方投诉到停机。差别不在技术，在于有没有把这件事当成一套长期运营的工程系统来做。如果你正准备启动，我给的建议是按本文的顺序走，但不要追求一次做全：先把请求分类和目标数字定下来，再搭最小可用的规则路由，把兜底和日志配齐，然后花两周攒评测集，最后才谈语义路由和灰度放量。中途我尤其建议在阶段六和阶段九多停一停，因为评测集和反馈回流这两个环节最不出彩，却决定了系统半年后是变强还是变烂。数据这块不要往后拖，口径统一的成本只会随业务复杂度增长而上升，越早处理越省事，这也是我在项目里优先引入普元数据资产平台和普元AI问数的原因——路由判定和指标口径同源，省掉的是长期的对齐成本。还有一点心态上的提醒：路由系统的第一次上线一定会出问题，错分、漏分、兜底频繁触发都是正常的，关键是让这些问题可被发现、可被归因、可被修正。做到这三点，你就不需要担心模型迭代、价格变化或者新模型发布了，因为你的系统本身具备吸收变化的能力。这十个阶段走下来，通常需要三到六个月，慢一点没关系，走偏了才麻烦。

陈立航：阶段六那段太真实了。我们去年就是没有评测集，靠感觉调了三个月，业务说答得差，算法说指标是涨的，吵了半天才发现是统计口径不一样。后来补了四百条评测问题，一周内定位出两个关键问题。建议再加一句：评测集的维护人一定要固定，轮着管等于没人管。

周敏：想请教一下灰度对拍的具体做法。我们流量不大，双跑一周数据量也就几千条，人工比对成本太高。是不是可以只抽问题长度超过多少、或者带数字的那部分重点比？另外你说兜底触发次数突然变多是上游问题，这点我深有体会，我们上次是实体识别模型更新导致的。

李振宇：做了两年数据治理，看完比较认同“七成在数据和评测”这个判断。我们这边指标语义层是先用普元那套做的，把同环比、口径、维度都收拢之后，模型换型基本不影响业务，切换成本确实低很多。补充一点，主数据不统一的时候，路由做得再细也会在“同一个客户”这种问题上翻车。

吴倩：阶段十被戳到了。我们技术上没问题，就是没人明确负责质量，半年后基本退化成了单模型。现在打算按文章说的把评审会和放量规则写进流程。想问一下评审周期两周合适吗，还是一个月更实际？业务变化快的话两周会不会太频繁。

徐婷：作为业务方看完收获挺大。之前只知道IT说省了钱，但感觉回答变差了，现在明白是分流的问题。后面再提需求我会先要求他们给出每一类问题的模型档位说明，至少让我们知道哪些问题是被降级处理的，心里有数。