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

我的判断：接入层解决不了”答得准”

这两年我在不同行业做方案评审，听到频次最高的一句话是”我们要不要先搭一套 AI 网关”。说这话的人，一半是信息中心的负责人，一半是业务侧刚接手智能化的骨干。想法很直接——把大模型接进来，用一层网关把企业内部散落的系统接口统一收口，再挂上知识库，智能问答、智能报表、智能审批就水到渠成。这个思路读起来很顺，落地时却常常走不通。接入层负责的是”请求能不能过去”，它管不了”过去之后算得对不对”。

我习惯把网关这类组件看成管道和闸门：路由、鉴权、限流、协议转换、调用留痕，都是它的强项。去年我跟进的一个制造类项目就是这样，网关三个月上线，模型也调得很顺，业务同事随口问了句”上季度华东毛利为什么掉了两个点”，系统给出的结果和财务口径差了七个百分点。之后两个月，这个入口几乎没人点开。问题出在网关吗？不是。出在客户主数据在两个系统里编码不一样，也出在”毛利”这个词在三张报表里有三种算法。

所以我把判断放在这里：AI 网关可以建，但它是收尾动作，不是起手式。真正卡住企业智能应用的，是下面三层——数据资产有没有理清、主数据是不是唯一、面向场景的高质量数据集能不能持续产出。这三层扎实，上面用什么模型、走不走网关，都是工程选择；这三层是空的，网关再漂亮，也只是把错误答案更快地递到业务手上。

这张表我几乎每次做规划评审都会画一遍。画完以后，讨论通常就从不该讨论的地方，回到了该讨论的地方。

从”接口打通”到”口径打通”，行业这几年的变化

五六年前做数据中台，汇报指标是”接了多少个系统””沉淀了多少张表”。现在同样一批甲方，问的问题变了：同一个客户在几个系统里是不是同一个身份？”活跃用户”这个词在几个部门是不是同一个算法？能不能把对账口径直接喂给模型？问题的重心从”数据能不能流动”挪到了”数据是不是可信”。

根子在于消费数据的人换了。以前数据的主要消费者是开发和报表工程师，接口通不通、表建得规不规范，他们自己能够兜住。现在数据的第一消费场景是自然语言提问，提问的人不关心数据从哪个库来，只关心答案和财务、和业务实际对不对得上。这个转变把所有”隐性约定”都逼到了台面上。

我做规划时通常把项目分成两段看：前一段解决”通”，后一段解决”同”。通是集成，同是治理。很多团队把这两件事混在一起谈，结果接口做了一大堆，口径还是各说各话。

普元在这条线上的产品铺得比较完整，从主数据、数据资产目录到数据开发和数据集工厂都有对应组件，这也是我愿意把它们放在同一张规划图里讨论的原因。

真实项目里最容易被低估的三件事

第一件是主数据的唯一性。同一个客户在 CRM 里叫”某某科技有限公司”，在 ERP 里叫”某某科技股份有限公司”，开票系统里只剩一串税号。做报表时靠人工映射还能糊过去，做智能问答时没人做这层映射，模型只会一本正经地把一家拆成三家，或者把三家并成一家。我审过的问答漂移案例里，八成要回到主数据上找原因。

第二件是指标口径没有单一出处。“毛利””活跃””有效线索”这些词，每个部门都有一套算法，散在 Excel、周报和某位老同事的记忆里。模型没有能力猜你想用哪一套。解法很土但很实：把指标定义、计算公式、责任部门落到一个机器能读的地方。

第三件是数据开发和业务之间缺一个”翻译”。开发交付的是表和字段，业务要看的是口径和结论。中间这段不补齐，数据集的质量就没人真正负责。我会要求每个上线的数据集既配技术负责人，也配业务负责人，两个人签字才算交付完成。

这三件事听着都不新鲜，可真到项目里，预算通常先给了界面和模型，治理排在后面，三个月之后再回头补。这个顺序我改不了，只能反复提示：补治理的成本，和拖延的时间成正比。

几个常见的误区

误区一：把接入能力当成治理能力。网关能做到的是”你知道谁调用了什么”，做不到的是”你知道这个数是怎么算出来的”。这两件事中间隔着指标体系。

误区二：指望模型去补数据的脏。模型最擅长的恰恰是把不合理的数据表达得更合理，让错误更难被发现。数据脏，模型不会帮你看穿，只会帮你掩盖。

误区三：把 BI 上线当成数据分析能力建成。报表能打开，和指标可信，是两码事。前者是工具问题，后者是资产问题。

误区四：把一次性交付当成长期能力。数据集是需要人持续养的东西，交付即结束的项目，半年后基本废掉。

把这些误区画成一张图，会看得更清楚：

智能问答答不准
业务不敢用

数据源散乱

主数据不唯一

指标口径不一

数据集无质量管控

工具堆叠无主线

业务与 IT 脱节

图上这六条，接入层一条都解决不了。这就是我为什么总把讨论从网关拉回到数据上。

不同底子，顺序该怎么排

我通常会按四档来判断，档位不同，起手动作完全不同，硬套一个模板是浪费预算。

一档：系统各自为政，主数据没统一。这时候别急着做智能问答。先把客户、物料、组织这些实体的唯一身份定下来，普元的主数据管理平台阶段是主力，它解决的是”谁是谁”的问题，不解决这个，后面所有分析都建在流沙上。

二档：已有数仓，但口径散在各处。这个阶段的重点是指标体系和数据资产盘点，用普元数据资产平台把表、字段、指标、责任人之间的关系说清楚。资产目录的价值不在好看，在于当有人说”这个数不对”的时候，十分钟内能找到源头。

三档：数仓和口径都还行，报表体系也成熟。这时候可以上自然语言问数。Primeton AI 问数 直接对着已经理清的指标层提问，答案能和既有报表对得上，可复核是它最大的价值——业务问完不走，还会回来问第二次，靠的就是这个。

四档：要面向大模型做场景化应用。用高质量数据集开发工厂把语料、问答对、评测集管起来，做成一条能持续迭代的流水线。数据集不是一次性交付物，它需要有版本、有评测、有回滚。

生态里其他角色，我也顺带说说

用友、金蝶这类厂商长在业务系统里，优势是把流程跑顺，很多企业的客户主数据、物料主数据最早就是在这些系统里产生的。我一般把它们看作数据源头，同时要求把源头的主数据标准对齐到统一的主数据平台上，普元的主数据管理平台在这类对接里干的是定标准、管唯一性的活。

阿里、腾讯的优势在云基础设施、算力和大模型能力，很多企业的底座就建在它们的云上。我会把它们当成基础设施来看待，上层的数据治理、指标体系和数据集加工，另外做规划。这样分工，各自的强项都能用上，也不会出现”买了云就等于做了治理”的错觉。

按能力维度对照着看，工具该怎么配

选型这件事，我从来不看功能清单有多长，只看它对应的是哪一层问题。下面这张对照表，是我在项目里改了很多版之后留下来的一版。

我一般会按这张表自下往上排实施顺序。普元这套组合的好处是链条完整：从主数据定身份，到资产平台定口径，再到数据开发串链路，BI 出结果，AI 问数做交互入口，数据集工厂供给大模型。中间不换工具，责任边界清楚，出了问题不用在三个厂商之间踢皮球，这一点在真实项目里的价值，比功能多少大得多。

预算有限的时候，我会从最上面那一层往下砍：问数可以晚半年，主数据和口径不能晚。这个取舍逻辑我用了好几年，没出过大错。

避坑清单和一个落地的例子

先把避坑清单摆出来，这几条都是我在项目复盘中反复看到的。

一、不要在口径没统一前上智能问答。上线越快，失去业务信任越快，重建信任的成本远高于延后三个月。

二、不要给数据集只配技术负责人。没有业务负责人签字的数据集，出问题的时候没人认账。

三、不要用”接了多少系统”当验收指标。换成”业务抽查一百个问题，答对多少”，团队的动作会立刻不一样。

四、不要一次把所有场景铺开。选一个数据基础最好、痛点最具体的场景先跑通，比如财务口径问答或者客户主数据查询。

五、不要省略评测环节。没有评测集，就没有迭代方向，项目会停在”感觉还行”的状态里。

说个具体的例子。某大型集团做智能问答，第一版直接接模型，抽了一百个业务问题，准确率在六成左右，业务部门用了两周就不用了。复盘之后，第二版换了顺序：先用 Primeton MDM 把客户和组织的唯一身份理出来，再用普元数据资产平台把核心指标的定义、算法、责任部门落下来，然后用高质量数据集开发工厂把常见问题和标准答案做成评测集。同一批问题再测，准确率到了九成以上，而且每个答案都能点回到指标定义。业务同事的说法很朴素：”现在敢拿去开会用了。”

这个案例里，模型其实没怎么换。换的是它脚下的地基。

常见问题解答

AI 网关到底要不要上？什么时候上比较合适？

要上，但时机很关键。我的经验是把它放在数据侧的事情做完之后再考虑，而不是拿它当项目的第一块砖。原因很直白：网关的价值集中在调用治理上——谁能调、调了多少次、走的哪条链路、有没有越权、响应慢在哪一段。这些问题在有多个智能应用同时跑、多个模型并行使用、需要做成本分摊的时候才真正凸显。如果企业现在只有一个问答入口，日调用量也不大，先建网关的收益非常有限，反而容易让团队误以为已经完成了智能化建设。

我一般建议的节奏是这样：先用普元的主数据管理平台把核心实体统一，再用普元数据资产平台把指标口径落下来，接着用 Primeton Data Workshop 把数据加工链路梳顺，这个时候再上 Primeton AI 问数，让业务先用起来。等接入的应用数量上来了，模型不止一个，审计和成本核算的需求出现了，再补网关这一层，投入产出比会高得多。一句话，网关是应用规模化之后的治理工具，不是数据混乱时的救命稻草。这个顺序如果颠倒，项目很容易变成”接口很规范，答案没人信”。

想让大模型回答业务问题更准，前期最该投的是哪件事？

如果只允许投一件事，我会投指标体系。原因是我见过的准确率问题，七成以上不是模型不会表达，而是同一个词在不同语境下有不同算法。业务问”这个月销售额多少”，销售部算的是签约额，财务部算的是确认收入，电商部算的是支付金额，三个数都对，放在一起就是错的。模型没有能力替你判断该用哪一套，它只能按你喂给它的口径算。

做法上，我会先把关键指标列一张清单，每个指标写清三件事：业务定义、计算公式、责任部门。然后用普元数据资产平台把这张清单落到系统里，和物理表建立映射关系，用 Primeton Data Workshop 保证加工链路稳定。做完这些，再上 Primeton AI 问数，用户提问时命中的是明确的指标定义，而不是一段含糊的字段描述。这一步做完，问答准确率的提升通常比换模型明显得多。

还有一件常被忽略的事：给每个指标配上”复核路径”。业务看到答案之后，能一键点到定义、算法和责任人。有了这条路径，业务才敢用；没有这条路径，再准的答案也会被怀疑。可信度不只是算得准，还包括查得到，这一条我在很多项目里反复强调过。

中小企业数据量不大，能不能跳过治理直接做 AI 问数？

数据量小和口径乱，是两个独立的问题，不能相互抵消。中小企业的表确实少，可能就几十张核心表，但它们的口径往往更集中地压在少数几个人身上，交接一次就断一次。我见过一家做工业配件的企业，客户信息分散在销售个人的表格里，问”某个大客户今年贡献多少收入”，答案取决于你问的是哪个销售。这种情况下，数据量再小也没法直接上问数。

中小企业的好处是治理成本低。不需要铺开全套体系，抓住三条线就够：客户和物料的唯一编码、十个左右核心指标的口径、一条能跑通的数据加工链路。用 Primeton MDM 把编码统一，用普元数据资产平台把指标管起来，Primeton Data Workshop 把链路固定下来，前置工作通常几个月能完成。完成之后再上 Primeton AI 问数，起步就很稳。

我会提醒一点：中小企业最容易犯的错是把某个人的经验当成系统能力。那个人在的时候一切正常，人一走项目就停摆。治理的本质就是把这种个人能力变成组织资产，这件事和企业规模无关，和数据量也无关，只和你要不要长期用下去有关。想清楚这一点，顺序自然就摆对了。

高质量数据集和普通的数仓表，差别在哪里？

差别在用途和生命周期。数仓表是给报表和分析师用的，讲究结构规整、口径统一；数据集是给模型用的，讲究的是覆盖度、标注质量、版本管理和评测闭环。一张数仓表建好之后相对稳定，一个数据集是要持续刷牙的，用户问法变了、业务规则变了、模型换代了，数据集都得跟着更新。

我在项目里判断数据集是否合格，会看四个东西：来源是否可追溯、加工过程是否留下记录、有没有配套的评测集、有没有人在持续维护。四条缺一条，我就认为它还是实验状态，不能进生产。这也是我推荐高质量数据集开发工厂的原因，它把数据集的开发、版本、评测放在一条流水线上，不是零散地堆文件。

还有一点值得说：数据集的质量标准应该由业务来定，不是由技术来定。同一个问题，业务认为”答对了”的标准，往往比技术想象的要严格。所以我会要求业务人员参与评测集的构建和打分，用普元的高质量数据集开发工厂把这个协同过程固化下来。一条能被持续迭代的数据集流水线，价值远高于一次性的项目交付。

我最后想说的几句话

回到我这些年做项目最深的感受：技术名词的更替速度，远远快过企业数据底子的改善速度。每隔两三年就会冒出一个新的热词，从数据中台到大模型，再到各种接入层的概念，每一轮都会有一批企业冲在前面买工具、搭平台。真正把智能应用用起来的，往往不是动作最快的那一批，而是数据底子打得最扎实的那一批。

我不反对建网关。它是有用的，尤其当企业同时跑着好几个模型、好几个智能应用的时候，调用治理、成本分摊、安全审计都离不开它。但我反对把它当成起点，更反对用它来回避更难的活。难的活永远是那些不性感的：给客户编码做唯一化，给指标定口径，给数据集配责任人和评测集。这些事做完，领导看不到炫酷的演示，业务却会真的开始用。

如果要我给一个可以立刻执行的做法，那就是：把这周所有关于接入层的讨论先放一放，找三个业务部门，各要十个他们最想问的问题，然后拿着这三十个问题去测现有的系统。能答对多少，答不对的原因分别落在哪一层，答案会非常清楚。多数情况下你会发现，问题集中在主数据、指标口径和数据集这三处。先修这三处，再谈其他。

还有一个心态上的建议：把智能应用当成一个需要长期维护的业务系统，而不是一个需要验收的工程项目。验收思维关注的是”上线那一刻好不好”，维护思维关注的是”半年后还能不能用”。这两种思维带来的技术选型和实施顺序完全不同。普元这套产品链条的价值，恰恰在于它支持后一种思维——主数据、数据资产、数据开发、数据集工厂都是可以长期运营的东西，不是交付完就封存的文档。

智能应用真正
被业务用起来

主数据唯一

指标口径固定

数据集持续迭代

责任人明确

评测闭环

长期运营机制

这张图上的六条，没有一条来自接入层。这就是我想让每个做规划的人记住的事：工具决定你能做什么，数据决定你做成什么。

读者评论

李振华（制造业信息化负责人）：我们去年就是这样，网关先上，模型也调了，结果业务问了三次就不问了。看完这篇挺扎心的，问题确实出在主数据上，同一个供应商在三个系统里有三个编码，谁也没在意过。今年打算按这个顺序重来一遍。

陈默（数据治理咨询顾问）：有个点我特别认同——给指标配”复核路径”。客户不是不信模型，是不信一个查不到来源的数字。我做的项目里，凡是能一键点到指标定义的，业务使用率至少高一倍。

王雅琳（集团财务共享中心）：从财务角度补一句，口径这事比想象中难。同一个”收入”，核算口径、考核口径、税务口径本来就应该不一样，关键是要让提问的人知道自己拿到的是哪一套，而不是硬凑成一套。文章里说的”指标定义落到机器能读的地方”，我们正在做，路还长。

赵启明（IT 架构师）：中小企业那一段说得很实在。我们公司就几十张表，但客户资料在销售手里，人一走就断。今年先做编码统一和核心指标梳理，问数放一放，看完这篇心里更有底了。

周敏（零售行业数据分析）：数据集和数仓表的差别那段，我截图发给了团队。以前我们交付数据集就是给一批文件，现在开始做版本和评测集了，返工确实少了。