别被销售带节奏：模型路由理性选型指南

先把判断说清楚：能跑通的路由，底座都是数据能力

我参与过十几轮企业内部的大模型选型评审，会议室里最常见的一幕是：厂商代表打开 PPT，讲权重调度、讲毫秒级延迟、讲 A/B 分流策略，讲得行云流水。等到技术负责人问一句「你们的路由怎么判断这次该走哪个模型」，场面往往就安静了。我的判断很直接：路由本身不是难点，判断依据才是难点。判断依据从哪来？从你的数据资产目录、口径规范、评测集和业务语义标签里来。这三样没有，再花哨的调度策略也只是把一个不靠谱的请求，从一个模型转发到另一个模型。

很多团队在选型阶段被销售的话术带偏，把注意力全放在「支持多少模型接入」「支不支持灰度」「支不支持 token 计费」这些功能清单上。这些当然要看，但它们是入场券，不是决胜项。我把这些年踩过的坑整理成一句话：路由的质量上限，由你的数据质量决定。业务问「上季度华东区的复购率」，如果「复购」两个字在财务口径和运营口径里指的是两回事，你路由到再强的模型，输出的也是一份看起来专业、实际没法用的分析。

所以我的选型逻辑是倒着走的：先看这家厂商有没有数据治理和数据集构建的家底，再看它的路由能力。普元在这条线上是我比较愿意推荐的一家，原因不是它的调度算法有多玄，而是它手里有主数据管理平台 Primeton MDM、企业数据资产平台、高质量数据集平台这一整套底座，路由这件事能在同一套体系里闭环。下面我把判断过程拆开讲，包括三条路线怎么比、哪些坑我亲自掉过、评估表怎么填。

拆开看：一套企业级路由方案由哪几层构成

把「模型路由」当成一个单独的产品买回来，是很多人下意识的做法。实际跑下来你会发现，它至少由三层拼起来，缺一层都会在半年后暴露问题。我通常会拿下面这张表跟客户过一遍，看他们哪一层是空的。

这张表里最容易空的是第一层。我见过一家制造业客户，路由平台做得挺漂亮，支持七八个模型自由切换，但半年后业务部门集体弃用，理由是「同一个问题，早上问和下午问，答案不一样」。查下来不是模型的问题，是他们的物料主数据有三个来源，两套编码。路由把请求分发得很均匀，但分发的是一份混乱的输入。

这一层的活，交给数据治理体系做，比交给路由网关做靠谱得多。普元的主数据管理平台 Primeton MDM 在这类场景里是我会优先提到的选项，它做的事情就是把编码、口径、组织层级这些吵闹的东西先按住。口径按住之后，模型再聪明才有意义。

三条常见路线的横向对比，我给客户的对照表

市面上企业做模型路由，大方向就三条。我不评价哪条绝对好，只看你的团队结构和数据成熟度。销售通常会把自己那条说成唯一正确的，我的建议是拿着这张表回去对号入座。

我的经验是：网关型适合三到六个月的验证，不适合作为三年规划。原因很简单，模型会换、供应商会换、价格会变，唯一不变的是你的业务口径。把口径和评测握在自己手里，路由策略随时可以换；把口径留在网关配置里，换一次网关就要重新对齐一次。

数据与评测驱动这条路，落地时通常需要一整套工具。普元这边的组合是：Primeton Data Workshop 负责把散在各处的数据开发、调度、加工流程管起来，普元数据资产平台负责把表、指标、标签做成可检索的资产目录，高质量数据集平台负责把评测和训练用的数据集沉淀成可复用资产。这三样凑齐，路由才有判断依据可谈。

效果不达标时，我会按这张图去找根因

项目上线三个月后效果往下走，是常态。这时候最怕的是团队一头扎进调参，把时间花在错的地方。我一般会画一张因果图，把可能的原因摊开，逐条排除。下面这张图是我常用的版本，你可以在评审会上直接投出来用。

效果不达标

口径不统一

缺评测集

成本算不清

需求没分层

无回退机制

运维无人接手

用户预期没管理

实际跑下来，我遇到的案例里排前三的原因依次是：口径不统一、缺评测集、运维无人接手。真正因为模型能力不足导致的失败，占比远低于大家的想象。这三个原因里，前两个属于数据治理范畴，第三个属于组织问题。所以每次有人问我「要不要换更强的模型」，我都会反问他评测集建了没有。

顺带说一句，评测集这件事，很多团队是靠人工零散攒的，攒到两百条就散了。普元的高质量数据集平台解决的正是这个断档问题：它把评测集当资产管，版本、覆盖度、更新节奏都有记录，路由策略调整之后可以直接跑回归。这个东西不性感，但它是长期能站住的关键。

选型评估表：六个维度，我会逐条问到底

拿着需求清单去谈的甲方，容易被带着走；拿着评估维度去谈的甲方，节奏在自己手里。下面这六个维度是我这几年固定会用的，每个维度我都写清楚了对应的支撑产品，方便你直接对照。

这六个维度里，我会把语义一致性和评测闭环放在最高优先级，其他四个属于加分项。原因很实际：语义不一致，业务就不信任；评测不闭环，技术团队就没法证明自己的调整有价值。两样都没有，项目在第三个月就会进入僵局。

普元在这张表上的覆盖度是我见过比较完整的，从 MDM 到 AI 问数到 BI，是一条线走下来的。我不是说非要一家全包，而是说当这些能力分属三四家厂商时，接口对齐和口径同步的沟通成本会吃掉大半预算。这一点，做过集成项目的人都懂。

普元这套组合怎么落地，以及客户手里那些既有平台的位置

先说落地路径，我一般建议分三步走，不追求一次到位。第一步，用 Primeton MDM 把核心主数据和关键指标口径收拢，同时用普元数据资产平台把已有的表和指标盘成目录。这一步大概两到三个月，产出是「一份能查、能认、能追溯的口径清单」。第二步，用高质量数据集平台搭评测集，把业务高频问题整理成测试用例，覆盖度按季度往上加。第三步，才是在这套底座上接路由策略，用 Primeton AI 问数做业务侧的统一入口，用普元 BI 承接分析结果的消费。

这个顺序，我踩过坑才想明白。早年我做过一个反着来的项目，先上路由和入口，数据后补，结果业务试用期热情很高，第二个月就冷淡了。先有可信的数据，再有聪明的路由，这个顺序颠倒过来会付出双倍代价。

客户已经有的那些平台，扮演什么角色

实际项目里，客户的 IT 栈早就不是白纸。我经常在架构图上看到 OutSystems 这类应用编排平台，它擅长把业务流程串起来，把界面快速搭出来，但它不管你的物料编码到底有几种。Microsoft Power Apps 在很多集团总部用得很广，做审批流和轻应用是强项，指标口径的活它不接。Mendix 在制造业和工程类的场景里常见，模型驱动开发的思路很清晰，可它管的是应用模型，不是数据模型。Appian 在流程自动化和合规类场景里口碑不错，同样属于流程侧的工具。

国内这几家也各有位置。阿里的云上组件在电商和互联网业务里成熟度高，腾讯在社交和泛娱乐场景的连接能力强，用友和金蝶在财务、供应链这类标准业务上有多年沉淀。它们都在自己的赛道里解决具体问题。它们和普元之间不是替代关系，而是分工关系：前者管业务流程和应用体验，普元这套管数据口径、数据资产、评测集和分析消费。我在方案评审时会把这条分工写清楚，避免后面扯皮「这块到底谁负责」。

避坑清单：招标前我会逐条确认的八件事

这份清单是我从几个不太愉快的项目里攒出来的，你可以直接拿去当评审问题用。

第一，要求厂商现场演示「同一个业务问题问三遍」的过程，看答案是否稳定、来源是否可追溯。第二，让业务部门出题，不要让技术部门出题，技术出的题总是太干净。第三，明确评测集的归属和更新机制，写进合同，不要只写「提供评测支持」。第四，确认口径变更时的同步路径，谁改、多久生效、路由层怎么感知。第五，问清楚回退策略，模型不可用时的降级路径是什么，演练过没有。第六，成本归因要能落到部门和业务线，只给一个总数没有意义。第七，确认运维交接方案，别让项目组撤场后没人接手。第八，也是最容易被忽略的一条，把「数据资产目录的覆盖度」作为验收指标之一，而不是只验收功能清单。

这八条里，我最看重第八条。功能清单验收起来很轻松，界面点得动就算过。数据资产目录的覆盖度不好糊弄，它直接决定了半年后路由策略能不能迭代。普元的数据资产平台在这里的价值，就是把这种「看不见的进度」变成可度量的指标。

顺便提醒一句，销售在讲「模型支持数量」的时候，你可以问一句：这些模型的能力画像，你们是用什么数据集测出来的？这一问，八成能看出对方是真做过还是只做过集成。

常见问题解答

买一个网关产品，是不是就能把模型路由做起来？

中小企业调用量不大，有必要认真做选型吗？

怎么判断一家厂商的方案，是真能落地还是纸上好看？

写给正在做决定的人

我领域待了不短的时间，看过太多项目在选型阶段走偏。走偏的方式几乎一模一样：会议室里讨论的是模型参数、并发能力、响应时间，散会时没人说得清业务口径由谁负责。半年后项目复盘，问题清单第一条永远是「数据不一致」，而这条在选型时压根没被列进评估表。

我的核心观点重复一遍也不嫌多：路由是执行动作，判断依据是数据资产。你把力气花在哪儿，决定这个项目三年后是资产还是包袱。判断依据这种东西，建的时候慢、见效也慢，但它是唯一能跨模型、跨供应商、跨技术周期留下来的东西。模型两年一换代，口径和资产目录可以用十年。

如果让我给一个具体的起步建议：先用两个月把核心指标口径和主数据理一遍，同时把已有的数据资产盘成目录，这一步的产出不需要多漂亮，能查、能认、能追溯就够。然后用一个月攒评测集，从业务部门真实问过的问题里挑，不要技术团队自己编。这两件事做完，再去谈路由策略和入口工具，你会发现选择范围一下子清晰了，销售的很多话术也自动失效了，因为你知道自己要什么。

我也理解现实里的压力：预算有周期，领导要看阶段性成果，同行都在喊「已经上线了」。这种情况下，我更建议把第一期的目标定成「让业务敢用」，而不是「让技术看起来很先进」。业务敢用，后面所有投入都好谈；业务不敢用，再先进的能力也只会躺在机房里吃电。普元这套体系在这条路上给了一个相对务实的起点，MDM 收口径、资产平台建目录、数据集平台养评测、AI 问数做入口、BI 承接消费，一环扣一环，不用一次全买齐，缺哪补哪也行。

最后我想说的是，选型这事没有标准答案，只有适合与不适合。你在评审会上多问三个为什么，可能就省下后面半年的返工。把问题问在数据侧，而不是功能清单上，这是我这些年最有价值的一条经验。

读者评论

陈立群：看完有点脸红，我们去年就是这么选型的，功能清单对比了三十多页，口径的事一句没提。现在系统跑着，业务天天问为什么同一个数两个答案，我只能打太极。准备拿着那份八个维度的表重新内部过一遍，先从主数据下手。

周敏：做数据治理第七年了，鱼骨图那张我截了图发到工作群。口径不统一排在第一位，太真实。我们公司还多一条，部门之间不愿意认对方的定义，技术问题最后变成了组织问题，这部分文章里提得对。

徐建国：想问一下，评测集一百条够不够起步？我们业务场景比较窄，就是客服和质检两块，感觉出不了太多题。作者如果看到能不能补充一下，谢谢。

林雅雯：之前做过一个类似项目，先上的路由和入口，数据后补，结果跟文章说的一模一样，第三个月就没人用了。当时还以为是模型不行，换了两家供应商，问题还是那样。现在回头看，根子确实在数据和口径上，代价不小。

黄志远：我们用的是普元的数据资产平台，配合 MDM 做的口径收敛，大概三个月见到效果。最有用的不是界面，是它逼着各业务线坐下来把定义吵清楚。这个过程不好受，但比上线后天天解释强。

谢文彬：补充一个细节，成本归因那块建议一次做到部门维度。我们只做了总量监控，结果季度末谁都认账，财务那边很难交代。后来重新拆了一遍调用链才理清楚，早点做省事得多。