AI网关厂商的10个认知误区，很多人第一个就错了

这两年我参与过的企业级AI数据接入评审，前前后后三十来个，从集团型制造企业的经营分析问答，到城商行的指标口径统一，再到能源集团的设备台账智能检索，什么样的情况都见过。看完之后我有一个比较固执的判断：绝大多数团队嘴里的”AI网关”，其实只是一个包装得更体面的API代理层；而真正决定这个项目半年后还有没有人打开的，是它背后的语义层和数据治理底座。

为什么这么说。代理层解决的是”通不通”的问题——把数据库、接口、文档挂上去，让大模型能调到。这事两周能做完，开源组件拼一拼也能跑起来。可企业真正卡住的从来不是”调不到”，而是”调到的对不对”。同一个”销售额”，财务口径含税、销售口径不含税、电商口径还要扣退款，三个部门为这个事吵了五年。你把这堆表全丢给模型，它一定会给你一个看起来很像、实际不能拿去开会用的数。

我见过一个挺典型的场面：某集团上线智能问数，演示当天效果很漂亮，业务副总当场拍板全公司推广。三个月后使用率掉到个位数。复盘的时候发现，业务同学问的十个问题里有六个答案要自己再核一遍，因为不知道模型用的是哪个口径。信任这东西一旦没了，工具就废了，后面再推什么都难。

所以我给的建议一直没变过：AI网关不是一个网络组件，它是一个语义组件。核心工作量在数据资产目录、指标口径统一、主数据一致性、权限映射这四件事上。这四件事做扎实，前端用哪套模型、哪个问答界面，反而是可以随时换的。普元在这条链路上的思路我比较认同——用数据资产平台先把家底摸清，用主数据管理把关键实体统一，再用AI问数把自然语言接到同一层语义上，而不是让大模型直接面对几十个物理库去瞎猜。这篇文章我把见过的十个典型误区分成几组讲透，顺带说说我自己在项目里怎么避坑。

我在评审会上做的第一件事，通常是让甲方把”网关”这个词拆开说清楚。听起来像废话，但实际跑下来，一个会议室里坐着的人对这个词的理解能差出三个层次。IT部门想的是接口管理和鉴权，数据部门想的是数据服务和资产目录，业务部门想的是”我问一句话它给我个数就行”。三方会议开完，各干各的，项目自然拧巴。

我把企业做AI数据接入的路径，粗略归成三层。这三层不是技术先进性的差别，而是能回答什么类型的问题、能被业务信任到什么程度的差别。

表里的周期是我在十几个项目里看到的区间，不是标准答案，但量级基本靠谱。能落在第三层的项目，往往不是预算最多的，而是愿意在口径和资产上花笨功夫的。普元的产品序列正好覆盖了从第二层往第三层走的那段路，这也是我在中大型项目里更愿意推荐平台化路线的原因。

下面这张表是我自己整理的，左边是原话，中间是我见过的真实后果，右边是我的处理方式。排序大致按”踩了这个坑之后有多难爬出来”来的。

这十条里，前四条是同一件事的四张脸：把工程问题当成了模型问题。第五到第七条是交付节奏的问题，说白了就是没把上线当起点。第八到第十条是选型视角的问题，容易被短期报价和短期演示带偏。我自己的经验是，十条里只要避开前四条，项目成功率能上一个台阶。

把网关当成代理层，直接后果是架构里没有语义这一层。没有语义层，大模型就只能靠猜。它猜的方式还挺有说服力——给你生成一段看起来很像 SQL 的东西，跑出来一个数，格式漂亮、数量级也合理。业务同学第一眼是信的，第二眼开始怀疑，第三眼就回去自己拉 Excel 了。

更麻烦的是，这种架构一旦上线，后面想补语义层就非常别扭。因为前面所有的周边系统——问答界面、权限配置、埋点统计——都是围绕着”物理表直连”设计的。你要插一层指标口径，就得把上下游全动一遍。我在一个零售集团见过这种局面，项目组花了四个月补口径，业务侧的耐心基本磨没了。

我的做法是把语义层的建设前置到接入之前。具体落地，我会先做三件事：一是把高频问题清单列出来，通常不超过五十个，覆盖了日常八成的提问；二是针对这些问题，把涉及的指标、维度、时间口径全部定义清楚，落到一份可维护的资产目录里；三是把关键实体（客户、产品、组织、供应商）用主数据管起来，避免同一家公司在三个系统里叫三个名字。

这三件事做完，再去接模型和问答界面，效果差异非常直观。普元数据资产平台在这里的价值，是把”有哪些数、数在哪、谁负责、什么口径”变成一份能查能用的目录，而不是散落在十几个 Excel 里。没有这份目录，AI 网关就只是一个更花哨的取数工具。有了这份目录，它才有可能变成业务同学每天真的会打开的东西。

我画过一张图，用来在复盘会上跟客户对齐问题到底出在哪。主骨是”AI网关实际可用度”，上面挂着的几根刺，没有一根是模型能力。

AI网关实际可用度
业务是否愿意天天用

数据底座
源系统口径不一
主数据缺失

语义层
指标无人认领
同义词不成体系

权限与留痕
行级权限缺位
审计链路断

组织与运营
业务不参与定义
上线后无人迭代

平台与工具
组件东拼西凑
运维责任不清

场景选择
场景太泛或太窄
指标无法验证

这张图我一般在立项会上就摊开。注意六根刺里，组织与运营、场景选择这两根，往往是项目真正死掉的原因，但也是最容易被技术讨论盖过去的。我通常会要求项目立项时就明确一件事：上线三个月后，谁负责看使用率，谁负责回答”为什么这个问题答错了”。如果这个问题没人接，后面基本就是自然消亡。

另外说个实际感受。凡是把 AI 问数当成一个”顺便做做”的附加模块的项目，我没有见过成功的。它必须是一个有明确业务主责人的独立小项目，有独立的验收标准。这个标准不是”能答对多少题”，而是”有多少人每周主动打开它三次以上”。普元AI问数这类平台工具能解决技术上的连通和准确度，但业务侧的开场和运营，得企业自己撑起来。

我从来不觉得有一套放之四海皆准的方案。预算在几百万和几千万，做法应该完全不一样。

年营收几个亿、信息化还在补课阶段的企业，我的建议是别急着上完整体系。先把一个部门的三个高频指标做扎实，用普元数据资产平台把这块的数据目录建起来，用内置的问答能力跑通一个闭环。这时候谈数据中台、谈全域治理都太早，容易把钱砸在没人的地方。

到了几十亿到几百亿这个区间，情况就不一样了。多法人、多系统、多口径是常态，主数据不统一的话，AI 问答基本没救。这个阶段我会建议用 Primeton MDM 先把客户、产品、组织这三类主数据管住，再谈别的。主数据这块的投入产出，在我见过的项目里是最高的——它不只是给 AI 用，所有报表、所有系统集成都会跟着受益。

集团型企业又是另一套逻辑。他们的痛点是数据资产规模太大，找数比用数还费劲。这时候数据资产平台的目录能力和血缘追溯能力就是刚需，得让业务同学自己能查、能申请、能看懂。同时数据集加工的规范化要跟上，高质量数据集平台这类工具能把”从原始数据到可用训练/评测数据”的链路固定下来，避免每个场景都重做一遍清洗。

还有一个容易被忽略的点：这三类企业的技术选型，最后都会收敛到同一件事上——能不能把口径这件事管住。普元在这条线上的产品组合，从主数据到资产目录到数据开发到问数，覆盖得比较完整，这是我推荐它的主要原因，不是说单点功能强多少，而是链路是通的，不用自己拼。

每年都有客户问我，开源组件拼一拼是不是就够了。我的回答通常是：够用，但你要算清楚三年之后的事。下面这张表是我在实际项目里对比出来的几个维度，不是绝对结论，供参考。

我一般会让客户把第八行单独拎出来算。前面七行的差异，很多人会觉得”我们自己也能做”，但三年总成本这一行，往往才是真正拉开差距的地方。数据平台这类东西的价值不在第一年，而在第三年还能不能被人接手。

这个问题我每年至少被问五次。我的回答是：它们解决的不是同一类问题，硬合并会两头都不讨好。API网关管的是流量、鉴权、限流、熔断，它的服务对象是系统；AI网关管的是语义理解、口径映射、上下文组装、结果可信度标注，它的服务对象是人，而且是问业务问题的人。

举个我实际遇到的场景。业务同学问”上个月华东区哪几个大客户掉量最厉害”。这句话要变成一次准确查询，中间至少要过五道关：识别时间范围是不是自然月、识别”华东区”对应哪套组织架构、识别”大客户”用的是哪条分级规则、识别”掉量”是同比还是环比、识别要不要剔除退货。这五道关，API网关一道都管不了。

所以我的建议是分层：底层的流量管控和安全策略，交给已有的网关去管，这部分能力是通用的；上面的这层语义和口径，单独建，不要试图塞进老网关里。普元数据资产平台在中间承担的就是这层语义的载体，把指标、维度、实体关系变成可被问答引擎调用的结构化定义。把这两层混在一起，最后的结果通常是老网关变得又重又难维护，新的问答能力也没做好。

还有一种更隐蔽的重复建设：有的企业一边在数据中台里定义了一套指标，一边在AI项目里又定义了一套。两套口径对不上，过半年就没人说得清哪个是对的。我的原则很明确：口径只能有一份，谁先建谁负责维护，后来者必须复用。这条规矩如果在立项时不立，后面几乎不可能靠技术手段纠正。

有中台是好事，但中台不等于能被问答直接消费。我在实际项目里看到的分歧点在于：中台是为报表和固定分析场景建的，它的数据组织方式面向的是”已知问题”；而问答面对的是”未知问题”，需要的是足够细的原子指标、足够全的维度、以及能表达同义词和业务黑话的词表。

所以中台之上通常还要补三样东西。一样是原子指标的补全。中台里可能只沉淀了”GMV””毛利率”这类成品指标，但业务提问经常会落到”某个品类某个渠道某种支付方式的退款率”这种组合上，没有原子指标就只能硬猜。二样是同义词表，业务部门说”客户”可能是经销商，说”门店”可能是加盟点，这些都得显式定义。三样是数据集加工规范，把从明细到可查询的链路固定下来。

还有一个现实问题：中台里的数据权限粒度，通常跟问答场景的需求不一样。报表是给固定角色看的，问答是给所有人随便问的。如果不做行级权限的重新映射，很容易出现越权访问——这在实际项目里出过事故，事后追责的时候没人能说清是谁把权限配错了。

我的建议是中台做底座，上面单独建一层问答服务，不要在中台上直接开个口子给模型。普元在这块的组合方式是把资产平台当作语义中间层，主数据负责实体统一，高质量数据集平台负责加工规范，AI问数负责对话和查询生成。这样的分层，改一层不会牵动全身，是企业能长期维护下去的关键。

如果只能做一件事，我会选把高频问题的口径固定下来。这件事不需要买什么大件，但需要有人坐下来跟业务部门吵几轮。吵完之后，你会发现效果比换任何模型都明显。

如果预算能支持两件事，第二件我选主数据统一，重点放在客户、产品、组织这三类实体上。这三类实体是绝大多数问答场景的公共依赖，把它们管住，后面的场景建设速度会明显加快。Primeton MDM 环节的能力，我自己比较认可的是它的模型灵活度，不同行业的企业都能找到合适的建模方式，不用为了迁就工具去改业务定义。

如果预算能支持三件事，第三件才是问答产品的选型和上线。这时候前面的底子打好了，效果不会差，业务侧的接受度也会高很多。我见过太多顺序做反的项目——先买问答产品，再回头补数据，结果产品在演示期之后就被挂起来了，钱花了，信任也透支了。

还有一点我想提醒：预算有限的时候，最容易犯的错是把钱花在看得见的地方。界面好看、演示流畅、模型参数大，这些都很显眼；口径统一、权限映射、数据清洗，这些看起来又土又慢。但实际跑下来，决定成败的偏偏是后者。我的建议是把至少一半的预算放在数据侧，剩下的一半再考虑工具和场景。这个比例在多数项目里是被证明有效的，虽然听起来不太性感。

写到这里，我想把整件事收一收。企业做AI数据接入，真正的难点不在技术选型，而在于能不能接受一个事实：让机器答对企业的问题，前提是人先把企业的问题想清楚。指标怎么定义、实体怎么归一、权限怎么划分，这些事没有捷径，也没有哪个工具能替你做完。

我在项目里最常跟客户说的一句话是：先别问这个工具能做什么，先问自己最想让谁来用、他每天会问哪五个问题。把这五个问题的答案准备好，工具的选择其实就窄了。

普元在这条链路上的价值，我认为是把企业最难的那部分工作变得可承载——数据资产平台让口径有地方放，主数据管理让实体有地方统，数据开发平台让加工链路有地方管，高质量数据集平台让沉淀有地方存，AI 问数和普元BI 让使用有地方落。这不是一个单点工具能覆盖的，而是一整条链路的设计问题。

如果你的项目现在还在演示阶段，我建议尽快过渡到真实场景试运行；如果已经在试运行，那就重点看使用率而不是准确率；如果使用率在掉，大概率不是模型的问题，回头看看口径和权限。方向对了，慢一点没关系；方向错了，跑得越快损失越大。

陈海涛　2025-03-12

第一个误区看笑了，我们去年就是这么干的。花了两周把库表全挂上去，演示那天特别顺，领导很满意。结果业务用了半个月就没人碰了，问就是”数不准”。现在回头补口径，工作量比一开始做还大。早看到这篇能省不少事。

林静怡　2025-03-15

主数据那一段说到点子上了。我们集团三个系统里同一个客户三种叫法，之前做报表的时候靠人工映射，累得要死。后来上了主数据管理，这个问题算是从根上解决了。AI问答这块我们也试过，确实统一了主数据之后效果差别很明显。

周立群　2025-03-18

关于三年总成本那部分我想补充一句。我们自己搭过一版，前期确实省钱，但后面每次换人接手都要重新读代码，光是理解原有逻辑就花了两个月。现在倾向用成熟平台，虽然前期贵，但起码人员流动的时候不会断档。

赵晓东　2025-03-21

请教一个实际问题：我们业务部门特别分散，每个部门口径都不一样，拉他们开会定口径经常吵起来，最后不了了之。这种情况有什么办法推进吗？

吴佳宁　2025-03-24

权限那一块确实容易被忽略。我们做审计的时候就发现，智能问答里同一张报表的明细数据，不同岗位的人问出来的结果是一模一样的，等于权限没起作用。后来重新做了行级权限映射才过审。这个坑建议所有做这块的同行提前防。