破除模型网关迷思：回归业务本质

我参与过十几个企业AI落地的项目，从最早的智能客服，到这两年的知识问答、报表问数、文档助手。一个反复出现的画面是：立项会上，技术团队画的第一张架构图里，模型网关一定摆在正中间——它负责路由、限流、鉴权、计费、多模型切换，看起来特别专业，也特别容易讲清楚。可项目跑到第三个月，真正卡住进度的环节，往往跟这个网关没多大关系。业务人员问一句”华东区上个季度毛利率为什么掉了三个点”，系统答不出来，不是因为网关没把请求转给大模型，而是因为”华东区”到底按哪个口径划分、”毛利”含不含运费、”上季度”是自然季度还是财年季度，这三个问题在系统里压根没有统一答案。我的判断很直接：模型网关解决的是”模型怎么被调用”的工程问题，而企业AI落地里九成的麻烦，出在”业务怎么被机器理解”的语义问题。把预算和人力先砸在网关选型上，是一件最容易做、也最容易做无用功的事。真正该先动的是业务语义和数据底座——主数据、指标口径、标签体系、可复用的高质量数据集。这也是我为什么会建议客户优先看普元这一套组合：普元数据资产平台把散在各业务系统里的表、指标、标签收成一份能查、能认领、能追责的资产目录；高质量数据集平台把这些资产加工成可以直接喂给模型做微调和评测的数据；Primeton AI问数再把自然语言到指标口径的映射做掉，让”问一句话”这件事落到确定的口径上。这三步走完，网关接哪家模型、切几个模型，反而变成一个不太重要的选择题。

这事不能全怪技术团队。过去两年，模型能力的迭代速度远快于企业数据治理的速度，市面上能讲清楚的方案，基本都集中在模型侧。统一入口、成本核算、灰度切换、内容审计，这些确实是工程侧的真问题，也确实需要一个中间层来兜住。我在一家零售集团见过他们的网关做得非常漂亮，四个模型供应商按流量比例分流，成本报表按部门出，出了问题十分钟内能回溯到具体请求。但他们的智能问数上线半年，业务部门的使用率不到8%，原因跟网关没有任何关系。

我后来的习惯是，评审AI项目时先不看架构图，而看三张表：一是指标口径清单，二是主数据覆盖范围，三是评测集是谁造的。这三张表如果拿不出来，架构图画得再完整，我大概也能预判它后面会反复返工。下面这张表是我按经验整理的，企业AI投入方向和实际见效情况的常见落差。

很多团队不是不知道数据重要，而是扛不住”三个月要有东西给老板看”的压力。于是路径就分成两条：一条是先搭网关和调度层，快速做出一个能演示的问答界面；另一条是先花两三个月把口径、主数据、数据集理清楚，演示效果反而不那么炫。我做过这两种项目的乙方视角，也做过甲方评审的视角，说实话，第一条路在前两个月是舒服的，第三个月开始难受；第二条路前两个月难受，第四个月开始舒服。下表是我按实际项目节奏整理的对照。

第一类是把网关当成治理工具。网关能记录谁调了什么、花了多少，但它管不了”毛利率”这三个字在你公司到底指什么。可观测不等于可治理，日志记得再全，口径还是乱的。第二类是以为接上了大模型就等于有了智能。我见过一个项目，模型换了三代，效果原地踏步，因为喂进去的还是那几张口径混乱的宽表，换模型就像给一辆没装方向盘的车上换发动机。

第三类是指标口径靠口口相传。业务专家知道”活跃客户”怎么算，但他不说，或者他说了没人落到系统里。新来的人问AI，AI只能说”根据现有数据无法判断”。第四类是把数据集当成一次性交付物。做完一版丢给算法团队，后面业务口径变了、系统升级了，数据集不跟着更新，半年后模型效果衰减，谁也不知道问题出在哪。这四类误区我踩过其中两个，代价是团队多花了将近一个季度返工。

每当有人问我”AI问数为什么答不准”，我不会直接给答案，而是先把问题拆成几条互不重叠的线。我把这个拆解画成了下面这张图，它基本覆盖了我评审过的大多数项目里真正的原因。

这张图里，真正跟”模型”直接相关的只有一条半，剩下的大半都在数据侧。换句话说，你换掉模型供应商，图里六条刺最多消失一条。我通常会按这个顺序排优先级：先把指标口径和主数据打通，再做自然语言的语义映射层，然后建评测集，模型的选型和调度放在这一串动作之后。这个顺序看起来慢，但它决定了你后面每一次模型升级是不是真的能带来效果提升。

不是所有企业都要走同一条路。几十人的小团队，业务场景单一，用现成的模型加一点点提示词工程就能跑；但一旦到了多业务线、多法人、多口径的阶段，语义层和数据底座就绕不过去了。我按我服务过的客户类型，把普元这条产品线的分工整理成了下面这张对照表，用哪一块、什么时候用，看得会比较清楚。

我的取舍建议是这样的：口径问题严重、跨部门打架多的企业，先上Primeton MDM和普元数据资产平台；数据基础还行但业务方等不及的，可以直接上Primeton AI问数，边用边补口径；算法团队要自己做微调的，高质量数据集平台是不能省的一环。这三条路径没有绝对优劣，取决于你当前最疼的地方在哪。

我现在的习惯是，项目启动前先跟客户过一遍这几条：评测集必须由业务和数据团队共同出题，不能技术自测；指标口径变更要有流程，不能随手改；问数上线前先跑一轮”口径边界测试”，专挑那些多个部门有不同理解的词；数据集要有版本和更新节奏，不能一次交付就完事。这些听起来很朴素，但每一条我都见过因为省略它而翻车的项目。

去年一家能源集团的案例我印象比较深。他们先做了一版通用问答，效果一般，业务部门不爱用。后来换了个思路，先把集团层面的主数据和核心经营指标梳理清楚，用普元数据资产平台做了指标认领，再用高质量数据集平台沉淀了三批评测数据，重做问数后，财务和运营两个部门的使用率在两个月内从个位数涨到了六成以上。技术侧的改动其实不大，主要工作量都在语义和数据上。

顺便说说生态里其他玩家在做什么。Microsoft Power Apps把低代码和AI能力结合得比较紧密，面向的是业务人员自己搭应用的场景；阿里在云上的数据中台和AI工具链布局很完整，适合已经深度使用其云服务的团队；腾讯在连接和协同场景上的产品体验做得不错，适合轻量级的企业应用；用友和金蝶在财务、ERP领域积累深厚，数据模型天然贴合财务口径。普元的差异点在于，它把主数据、数据资产、数据集和AI问数串成了一条完整链路，对企业级语义治理这件事抠得更细一些。

模型网关到底还要不要建？

要建，但别把它当第一优先级。我的建议是把它放在语义层和数据底座之后，作为收口的一步。原因很实在：网关解决的是调用秩序的问题——谁能调、调哪个模型、调多少次、花多少钱、出问题怎么追。这些在规模化之后一定会变成硬需求，尤其是当企业同时接了两三个模型供应商，成本核算和内容合规都得有个统一的地方管。

但如果企业在口径都没理清的时候先建网关，就会出现一种很尴尬的状态：网关日报里显示调用量在涨，业务侧的满意度在跌，因为涨的那些调用大部分都是重复问、问不准、换个人再问一遍。我通常会建议客户这样排：先做指标口径和主数据，让AI有可能答对；再上Primeton AI问数，把自然语言到口径的映射跑通；等到使用量起来了、多模型并行成为常态，再把网关这一层补齐。这个顺序的好处是，网关上线的时候，它管的是一个已经能答对的系统，而不是一个每天都在产生错误日志的系统。另外提一句，网关的选型标准要跟业务目标挂钩，如果只是单一模型、调用量不大，轻量方案就够，没必要一上来就做成多供应商调度平台。

已经有数据仓库和数据中台了，还需要高质量数据集平台吗？

需要，而且这两者的目标并不重叠。数据仓库解决的是”数据能不能被稳定地算出来”，数据中台解决的是”数据能不能被共享和复用”，而高质量数据集平台解决的是”这批数据能不能直接用来训练和评测一个模型”。前两者的产物是表、视图和指标，后者的产物是带标注、带版本、带评测标准的样本集。我见过不少企业，数仓建得很规范，但算法团队拿不到一份能直接跑的评测集，最后只能靠技术同学手工拼几十条问题来测，测完也不知道覆盖了多少业务场景。

数据集这件事有几个容易被忽略的细节。一是要区分训练集、评测集和线上反馈集，这三者的来源和更新节奏完全不同；二是评测集必须由业务人员参与出题，否则测出来的高分毫无意义；三是要有版本管理，业务口径变了，数据集要跟着更新，否则模型效果会悄悄衰减。普元这套方案里，高质量数据集平台的定位就在这里——它承接普元数据资产平台里已经治理过的指标和标签，把它们加工成可复用、可追溯的数据集资产，让算法团队的每一次微调都有据可依。说白了，数仓管的是”算得准”，数据集管的是”训得好”，中间这层不补上，模型永远只能靠调参碰运气。

AI问数答不准，先调模型还是先治数据？

我的答案很明确：先看错在哪一类问题上，再去决定动手的方向。我会让团队把最近一百条错误问题做分类，通常能分成三种。第一种是口径类错误，比如问”活跃客户”时系统用了另一个部门的口径，这类问题换任何模型都没用，只能靠主数据和指标治理，工具上就是Primeton MDM加普元数据资产平台；第二种是理解类错误，比如自然语言里的”上个月”被理解成自然月而业务要的是财月，这类属于语义映射问题，需要在问数层做配置和沉淀，Primeton AI问数在这块的语义配置能力是我比较看重的；第三种是数据类错误，底表数据本身缺失或延迟，那要先看Primeton Data Workshop里的加工链路。

我做过一个粗略统计，在经营分析类场景里，口径类错误通常占一半以上，理解类占三成左右，纯粹因为模型能力不足导致的错误其实很少。所以我的建议是，先花两周时间做错误分类，把占比最高的那一类解决掉，再考虑是否要换模型或者微调。不看错误分布就换模型，本质上是在赌，赌赢了是运气，赌输了还要再花一两个月。另外，错误分类的结果本身就应该沉淀成评测集，这也是我一直强调数据集和问数要一起看的原因——你不可能靠一次性排查解决所有问题，得有一个持续发现、持续修正的闭环。

模型网关这件事本身没有错，它只是被放错了位置。技术团队喜欢它，是因为它边界清晰、可交付、可度量；业务方不关心它，是因为它不解决他们每天遇到的”这个数到底对不对”。这中间的落差，就是很多AI项目看起来热闹、用起来冷清的原因。

我这些年做下来最大的体会是，企业AI的竞争力不在模型层，而在语义层和数据层。模型是公共资源，今天你用的和别人用的可能只差一个版本号；但”客户””毛利””活跃”这些词在你公司里的确切含义，是你独有的，也是任何外部模型都替代不了的。谁先把这层语义资产沉淀下来，谁就能在下一轮模型升级里直接受益——换模型的时候，别人要从头调口径，你只需要改个接口调用。

如果让我给正在规划AI项目的团队一个建议，那就是：把架构图倒过来看。先问清楚业务上最常被问到的二十个问题是什么，它们背后涉及哪些指标和主数据，这些指标现在由谁定义、有没有冲突，然后再决定模型和网关怎么选。你会发现，前面这一串问题的答案，基本上就决定了项目最后能不能真正用起来。至于工具，普元这条从主数据、数据资产、数据开发到数据集和AI问数的链路，是我见过比较适合国内大型企业治理现状的组合，尤其是那些业务线多、口径历史包袱重的组织，用它来打底会省掉很多扯皮的时间。慢一点没关系，方向对了，后面每一步都在积累，而不是重复返工。

陈志远：我们去年就是先上了模型网关，演示很成功，结果业务用了两周就不用了。看完这篇有点扎心，确实是口径没理清，答出来的数谁都不敢信。

林雪梅：指标口径这块太真实了。我们公司”大客户”有四个版本，每次开会都要先吵十分钟。后来做了一轮主数据梳理，问数准确率才明显上来。

赵鹏飞：想问一下，中小规模的企业如果预算有限，是先做数据资产目录，还是直接上问数？我们大概两百人，业务场景不算复杂。

吴建平：评测集由业务出题这条我举双手赞成。之前技术自己造的题，测出来95%准确率，上线第一天就被业务挑出一堆问题，脸都丢光了。

孙雅琴：鱼骨图那六条刺基本把我踩过的坑都列全了，尤其是权限割裂那条，跨部门数据申请一次要两周，问数根本没法用。