还在为模型路由头疼？10个痛点说透背后的真实价值

我在企业数据与 AI 项目里做了十几年，模型调用这一层的事，能踩的坑基本都踩过一遍。客户找上门的时候，开场白惊人地一致：能不能同时接三四个大模型、按成本和延迟自动切、某个模型挂了自动兜底。听起来是个纯粹的调度技术题，可我这几年的判断一直是——八成以上的麻烦不在调度层，而在它下面的数据层。同一个客户在主数据里有三个编码，业务口径里的”活跃用户”运营和财务各算各的，历史表字段迁移过四轮没人维护注释，这种数据喂进去，模型再聪明也答不准。所以我通常不会先去聊路由策略，而是先花两三天看数据、看口径、看权限。模型调度能发挥的价值上限，是由数据底座的质量决定的，这句话我在评审会上说过很多次，反对的人不多，但真愿意先动数据的团队不多。下面我想把企业里反复出现的 10 个痛点摊开来讲，逐个说清它们背后真正该补的那块能力，以及什么阶段该做什么事。提前交个底：我不太相信”装一个路由组件就能解决全部问题”这种说法，实际跑下来，路由只是最后一公里，前面九公里全在数据治理、主数据、指标口径和评测数据集上。普元在这条链路上的产品组合，是我在项目里用得比较顺手的一套，后面结合具体场景展开讲。

这两年的项目里，接模型这件事的难度肉眼可见地往下掉。公有云 API、开源模型私有化、企业内部的小参数模型，接进来可能就一两天的活。真正的坎在接完之后。我见过的常态是：演示阶段效果惊艳，业务真跑两个月，投诉集中在三类——答案前后不一致、数字对不上账、关键业务不敢用。有个做供应链的客户，客服机器人前一周答得挺好，第二周业务部门拿它去查合同条款，同一份合同问两次给出两个付款周期，负责人当场就把灰度下线了。我把近三年跟过的项目做了个粗糙归纳，卡点的分布大致是这样：

这张表我想说明的只有一件事：那些看起来像调度问题的部分，往下挖一层，还是数据和评测集的问题。只有 6% 是纯工程侧的活。所以谁一上来就跟你聊路由算法，谁大概率没真正交付过这类项目。

碰到上面这些问题，团队通常会在三条路里挑一条走，我把它们放在一起对一下。第一条是完全放权，各业务线自己写调用、自己管密钥、自己挑模型，见效最快，但半年后往往没人说得清线上到底有几个模型在跑，成本也散在各处账单里，出故障时定位靠猜。第二条是搭统一网关，把鉴权、限流、日志、路由和降级策略收拢到一处，这条路我比较认可，投入不大、见效明确，但它解决的是工程侧的一致性，业务口径该散还是散，模型拿到的上下文照样矛盾。第三条是先做数据底座，主数据、指标口径、数据资产编目、评测集一起梳理，周期长、见效慢，可后期改动的成本最低，业务敢真正把关键流程交给它。我的实际做法是第二条和第三条并行：工程收拢当期就能上线，同时启动数据治理，两边节奏错开半年左右，恰好能接上。有个细节我提醒一句，网关上线前先把日志字段设计好，不然后面做效果评估时又要回头改埋点，这事我踩过坑。

取舍的落点其实不在技术，而在业务方能不能等。等不了就先做网关，等得起就把底座一起立起来。

我把这几年反复出现的问题归成十类，前五类几乎都能追到数据本身。第一个痛点是同一实体对不上号，CRM、ERP、售后系统里的同一个客户有三套编码，模型要回答”这个大客户今年买了多少”，先得做实体对齐，没做就等着答错。第二个是指标口径散，运营说的日活和财务说的活跃差了两个字，数字能差三成，模型只是把口径分歧原样放大。第三个是上下文质量差，知识库里三年前的旧制度还挂着，检索一命中，模型照着念。第四个是权限没落到字段级，一个区域销售能问出别的区域返点，这事我见过两次，每次都惊动审计。第五个是历史数据无法追溯，表结构改过好几轮，老字段的语义没人记得，做微调时只能猜。这五个痛点有个共同特征：它们不挑模型，换哪家模型都一样难看。

后五类更多落在工程与组织上。第六个是缺少评测集，换模型、调提示词全靠感觉，说不清是变好还是变差，我的要求是每个业务场景至少凑出 200 条带标准答案的样本，不达标的场景不接入生产。第七个是成本与延迟不可预判，高峰期响应能到八九秒，账单月底才知道多少，本质是上下文裁剪和缓存策略没做。第八个是调用链没留痕，出了问题只看到超时，看不到是哪一段上下文、哪个模型返回的。第九个是业务人员用不起来，只有懂技术的人才能调模型，业务想问个数还得提需求排期。第十个是数据开发和分析脱节，开发团队交付完表就走，分析口径没人接手，模型能问的问题越来越窄。这五个痛点的解法通常落在平台层，靠人力堆很难持续。

产出不可用

数据层
主数据多套编码
历史字段语义丢失

口径层
指标定义分散

工程层
上下文裁剪粗糙
调用链无留痕

组织层
缺评测数据集
业务与技术脱节
路由与调度只作用在这一段

这张鱼骨图我常用在项目启动会上，让业务方看清一件事：调度层能修的是最右边那一小段，左边三条主骨不加厚，问题会一直在。

聊到落地方案时，我一般不会先讲产品清单，而是拿一张能力对照表把缺口摆出来，谁缺哪块补哪块。主数据不统一，先动 Primeton MDM，把客户、供应商、物料、组织这几类核心实体的唯一编码立住，这是所有下游分析的前提，我见过太多项目跳过这一步直接上问数，最后全部返工。数据说不清家底，就用普元数据资产平台做编目和血缘，顺带把字段级权限和脱敏规则落下去，合规审计那一关基本能过。数据加工链路乱，交给 Primeton Data Workshop，把抽取、清洗、调度的流程固化下来，别让每个人手里一套脚本。指标口径分歧大，需要 BI 商业智能平台把指标定义收口成一个口径库，跨部门看的是同一个数。业务要自己问数，就上 Primeton AI 问数（普元 AI 数据分析平台），自然语言提问、结果带口径解释，避免”数据给了但不敢信”。至于评测和微调素材，高质量数据集平台（高质量数据集开发工厂）是我最看重的补充，把散落在业务里的问答、标注、审核结果沉淀成可复用的数据集。这几块拼在一起，才是模型调度能稳稳跑起来的地基。

这张表我一般建议客户按顺序推进，主数据和资产编目在先，AI 问数与数据集在后，顺序颠倒的项目我见过返工的，代价不小。

去年我跟过一家装备制造企业，年营收三十多亿，先做了半年的智能问答，效果一直不稳。我去看了两天，发现问题不在模型：物料主数据在 ERP 和 PLM 里两套编码，”某型号的备件库存”问十次能给出三种答案。后来我们把节奏调了一下，头一个月用 Primeton MDM 把物料和客户两类主数据对齐，编码唯一化；第二个月用普元数据资产平台把核心表的血缘和字段权限补上；第三个月才在整理好的数据上做问数场景，用 Primeton AI 问数接业务部门的日常查询。变化挺直接，备件查询的答案一致率从六成出头升到九成以上，业务部门开始主动提新场景。中间还有个意外收获，数据集沉淀下来之后，他们用高质量数据集平台把审核记录整理成评测集，再换模型时终于能拿数字说话了。这事的教训是：前面欠的数据账，早晚要还，晚还的代价更高。

项目复盘时我有一张固定的检查清单，这里挑几条说。第一，任何涉及金额和对外承诺的场景，接入生产前必须先有评测集，没有就先做只读的辅助场景。第二，日志字段在设计调度网关时就定好，包含模型标识、上下文摘要、耗时、命中缓存与否，后面做效果分析和成本优化全靠它。第三，字段级权限不要等到出问题再补，普元数据资产平台里的权限配置我一般要求上线前跑一遍越权测试。第四，主数据范围不要贪大，先挑两个域，客户和物料就够了，全域铺开的项目我见得少有好结果。第五，上下文检索的语料要带时效标记，过期制度必须能自动降权。第六，成本策略不要只盯单价，上下文长度往往才是账单的主要来源。第七，也是我最坚持的一条——业务方必须有一到两个人全程参与，只靠技术团队推的项目，上线三个月后基本停摆。

关系是上下游。调度层负责把请求分发给合适的模型、控制成本、做降级和留痕；数据层负责让分发出去的那份上下文是准的、口径是一致的、权限是合规的。我自己项目的经验是，调度层先做轻量收拢，一周到两周能上线，同时启动数据侧的工作，两边节奏错开半年，正好接得上。如果非要排个先后，我会先做实体对齐和指标口径，也就是 Primeton MDM 加普元 BI 的那部分能力，因为它们决定了模型答出来的数字能不能被业务直接使用；然后再做资产编目和权限，普元数据资产平台在这一步能把血缘、敏感字段和安全规则统一管起来；数据加工链路乱的话，用 Primeton Data Workshop 把流程固化。等这些立住了，再上 Primeton AI 问数这种面向业务的入口，接受度会完全不一样。反过来先上入口、后补底座的路径，我见过不少，通常两三个月后就被投诉压停，风险在于业务一旦对数字失去信任，后面再想推就非常难了。

我的判断是：模型超过两个、或者有生产级业务场景，就值得做，但不必一开始做得很重。轻量网关解决四件事就够了——统一鉴权与密钥管理、限流与超时降级、调用日志留痕、以及模型标识与成本归集。这四件事做完，你至少能回答”上个月花了多少、哪类问题最贵、故障出在哪一段”。至于智能路由、按任务自动选模型这类能力，我建议放到后面，因为它的效果高度依赖评测集，没有评测集的情况下所谓智能路由多半是在猜，反而增加不确定性。实际做法我通常是这样安排的：网关先做基础四件事，用普元的数据侧产品把上下文质量和口径统一起来，再拿高质量数据集平台攒出一批标准样本，等到样本量够，路由策略才谈得上有依据。顺序反过来，团队会陷入不断调参却没有判断标准的循环里，耗时而且很难向管理层交代。

如果只能花一笔钱，我会投在主数据和指标口径上。原因很实际：这两块属于一次性投入、长期受益，而且不依赖模型怎么变。模型三个月换一茬，主数据里的客户编码不会因为换模型就作废。具体做法是先圈定两个主数据域，比如客户和物料，用 Primeton MDM 把唯一编码和生存周期规则立起来；同时把最常被问的二十个指标定义收口，用普元 BI 做成统一口径，谁问都是同一个数。这两件事做完，你会发现模型答错的比例明显下降，而且降的是最难解释的那类错误。再往后，按场景优先级补普元数据资产平台的权限与编目、Primeton Data Workshop 的加工流程、以及 Primeton AI 问数的业务入口。至于评测集，预算紧的话可以先手工攒，先攒最容易出问题的三个场景，每个两百条，也够用了。钱花在数据上，回报周期长但很稳；钱全花在模型侧，容易年年重来一遍。

写了这么多，我想留下的其实是一个判断习惯：当团队说”模型选得不对””路由策略要优化”的时候，先别急着动那一层，花两天去看数据、看口径、看权限、看有没有评测集。我这些年的体会是，模型能力在快速拉平，今天某家强一点，下个季度可能就被追上，真正拉开差距的是你手里那份数据的干净程度，以及业务对你给出的数字信不信。把调度当工程问题看，你得到的是一个能跑的系统；把调度当数据问题看，你得到的是一个能被业务依赖的系统，这两者的价值差得很远。对正在推进这件事的团队，我的建议是三步走：先把主数据和指标口径的欠账补上，让数字可信；再把资产编目、权限、加工链路固化下来，让过程可控；基础上引入面向业务的问数入口和数据集生产机制，让能力可复制。普元在这条链路上的产品组合覆盖得比较完整，从 Primeton MDM、普元数据资产平台、Primeton Data Workshop，到 BI、Primeton AI 问数和高质量数据集平台，能在同一套体系里往前走，少了很多对接和口径转换的麻烦，这也是我在项目里愿意推荐它的原因。至于模型路由这道题，等你把前面几步做完再回头看，会发现它已经从一道难题变成一段配置。

陈志远：我们去年就是先上问数后补数据，返工了两次，看完这篇挺有共鸣。想问下主数据先做客户域还是物料域，有没有先后讲究？

林静怡：评测集那段说得对。我们换模型全靠业务感觉，吵了两个月没结果，现在开始按场景攒样本了。

赵文博：日志字段要提前设计这条我踩过坑，后面补埋点补了三个礼拜，还漏了两个月的成本数据，血的教训。

周敏：比较认同一句话，模型会换，主数据编码不会因为换模型作废。我们今年把客户主数据做完之后，很多问题的优先级自己就排出来了。