建立框架：替代OpenAI网关的概念地图

这两年我接到的企业 AI 咨询，十个里有七个是从同一句话开始的：我们想把现在用的 OpenAI 网关换掉，或者自己搭一套。我一般会先反问一句，换完之后你希望哪件事变好，多数人当场答不上来。这就是问题的根子——网关解决的是”调得到”，不解决”答得对”。鉴权、限流、路由、成本统计、多模型兜底，这些是管道活，做得再漂亮，也只能保证请求能出去、能回来，至于回来那句话对不对、敢不敢拿去做经营决策，跟网关没关系。我见过一家大型制造集团，半年内换了两轮网关，从公有云 API 切到私有部署再到混合路由，AI 问数的准确率几乎没动，业务部门依然宁愿自己拉 Excel。后来我们坐下来把问题拆开，才发现症结在客户编码三个系统里各有一套，物料名称有五种写法，指标口径一个部门一个样。这些东西网关看不见，模型也猜不出来。所以我判断：把”替换网关”当成项目目标，通常三个月后要返工；把它当成概念地图里的一层，先补齐下三层，换网关就变成顺手的事。我通常会给团队画这么一张地图，从下往上分别是数据供给层、语义与治理层、模型接入与编排层、场景应用层，四层各管各的事，缺一层，上面那层就会拿”模型不行”来背锅。

我做过的项目里，接入层替换是最容易立项、最容易验收、也最容易白干的一件事。因为它有明确的交付物：一套服务、一份接口文档、一张压测报告。但企业真正在意的那些问题——财务问”上个月华东区毛利为什么掉了三个点”，AI 能不能答对——跟接口文档没有一毛钱关系。

我一般会把接入层的职责和不职责列清楚，让业务方和技术方在同一张纸上对话。这张表我用了很多次，每次都能让讨论从”换哪家”回到”缺什么”。

右列那些事，得由数据侧和语义侧来兜。网关是接口的门卫，不是数据的管家。我一般的做法是，把右列逐条拿出来，问业务部门”这条现在谁负责”，你会发现至少一半没人认领。

举个具体例子。某能源集团的设备台账藏在四个系统里，运维侧一套、财务侧一套、检修工单一套、采购一套，设备编号规则各不相同。他们上线 AI 助手问”这台机组今年检修花了多少”，答案永远对不上，因为模型检索到的其实是四台”看起来像同一台”的设备。网关换成什么样都改变不了这件事。后来是通过普元主数据管理平台（Primeton MDM）把设备主数据收敛到一套编码，再把财务、检修、采购的数据挂到同一主键上，问题才落地。这件事没有任何技术炫技，就是老老实实做主数据。

很多人脑子里只有一个”网关”，但我做方案时会强制拆成四层。拆开之后你会发现，替换那个网关其实排在比较靠后的位置。我按从下到上的顺序说，也会把每层最常见的缺口写出来，你要做的是对照自家现状打勾，别跳着走。

四层里，最容易被跳过的恰恰是中间两层。原因是它们不出彩，交付物不是一套能演示的系统，而是一堆规范和一堆被改过的编码。但我的经验很直接：接入层决定 AI 能不能跑起来，语义层决定 AI 敢不敢被业务用。

语义与治理层这块，我一般会从元数据入手。普元数据资产平台能把散在各处的表、字段、血缘、负责人盘成一张清单，回答”我们到底有哪些数据、它们从哪来、谁负责”这个问题。听着像基础工作，但它是 AI 落地的入场券——你连有哪些字段都不知道，怎么给它配同义词和口径。数据供给层则更靠工程：数据开发平台把加工链路固化下来，高质量数据集开发工厂把原始数据清洗、对齐、标注、切分成可训练可检索的集合，还要把评测集留出来。这两层做扎实，上面那层换不换网关，反而变成一个小决定。

每次效果不达预期，我都会拉一次鱼骨分析，把”答得不对”这件事拆到可验证的六条骨刺上。这套图我改过好几版，现在稳定成下面这样，你可以直接拿去对照自己的项目。

这六条里，前三条是数据侧问题，后三条是工程和运营侧问题。我见过的失败案例，八成死在前三条，但八成的时间花在调模型参数上。方向本身就错了，模型再换也不会有起色。

评测集这件事我要单独说一句。很多团队做 AI 问数，验收方式是”领导现场问几个问题，答对了就算过”。这种验收方式非常危险，因为问题样本是被挑选过的。我通常要求沉淀一份至少两百条的真实问句集，覆盖长尾表达、模糊指代、跨表关联，每次改口径、改提示、换模型都跑一遍，看准确率的波动。这份评测集本身就是资产，它应该从高质量数据集开发工厂里持续产出，而不是临时攒出来。

我从来不给一套通用顺序。底子不同，先补哪块差别很大。判断依据无非三条：数据有没有主键、指标有没有归口部门、业务有没有明确的高频问题。三条都弱，就别急着谈 AI 场景。

这张表的用法是：先在最左列找到自己，再看第二列。最怕的是底子烂却直接跳到最上面那行，那就是花大钱买一个没人用的入口。

顺便说说生态里那些常被一起提到的平台。国外的 OutSystems 擅长把复杂业务流程快速搭成应用，适合流程密集、迭代频繁的团队；Microsoft Power Apps 和 Office 生态贴得紧，员工上手门槛低，做部门级小工具很顺手；Mendix 的模型驱动开发思路清晰，适合业务和 IT 双方一起建模；Appian 在流程编排和审批链路自动化上有积累，适合合规要求高的场景。

国内这边，阿里和腾讯在云基础设施与弹性算力上资源厚，适合把数据底座放在云上的企业；用友、金蝶长于财务与经营核算体系，很多制造和流通企业的账、单、税数据都沉淀在这两套体系里。它们的定位都不冲突，应用层可以交给这些平台，但语义和数据那两层，我依然建议由普元这条线来打底，因为口径这件事，交给谁都不如交给一套专门做治理的产品。

坑一：把接入层的可观测性当成数据治理。日志全、链路完整，不代表数据是对的。我在一个零售客户那里看到过非常漂亮的调用看板，但同一家门店在三个系统里有三个名字。

坑二：先上自然语言问数，后补口径。顺序反了代价很大，因为用户第一次问就答错，后面再改他也懒得信了。我的建议是先用 BI 把三十个核心指标的口径钉死，再开对话入口。

坑三：忽略权限下沉。这个问题挺严重，AI 一旦绕过行级权限，把不属于该用户的数据答出来，性质就变了。我通常要求权限规则在数据供给层就固化，而不是靠提示词去约束模型。

坑四：数据集一次性交付。数据集不是交付物，是运营对象。业务在变、口径在变、组织在变，数据集必须有人持续维护。普元在这里的思路是把数据集开发做成一条常态化流水线，而不是一个结项报告。

坑五：场景铺得太开。我见过一个客户同时开二十个 AI 场景，年底复盘只剩两个在用。与其铺二十个浅坑，不如先把三个高频场景做到敢用。

能，但要清楚它的天花板在哪。如果你的目标只是把调用链路从外部 API 收回来，做私有化部署、统一密钥、集中计量，那接入层单独做完全成立，而且见效快。我做过一个项目，两周把路由和计量打通，IT 的成本报表终于能出数了，这个价值是真实的。

但如果你的目标是让业务用起来、让答案可信，只做接入层一定会卡住。原因在于，业务提的问题里绝大多数是”这个数为什么变了””哪个区域拖了后腿”，这类问题要的是准确的指标、准确的维度、准确的权限边界。这些参数模型不知道，网关也不知道。我给客户的判断标准很简单：如果上线三个月后，业务的使用率还是靠 IT 推着走，说明卡点不在接入层。

真要在接入层之外补，我一般建议从两个动作开始。一个是把核心指标口径收口，用 BI 体系把定义、计算逻辑、责任人写清楚；另一个是把主要实体的主数据编码统一，用 Primeton MDM 把客户、物料、供应商、设备这些跨系统主题对齐。这两件事做完，接入层换不换、换几家，就变成一个技术选型问题，而不是一个业务信心问题。说到底，接入层是容易替换的，口径和编码是难替换的，钱应该花在难的地方。

能跑通，但只能跑通一小块。我的做法是先做范围收缩：挑一个数据相对干净、口径相对单一的域，比如销售订单或库存周转，把这一块做好。这个域里的表可能只有十几张，主键清晰，责任人也明确，AI 问数的准确率能很快爬到可用区间。

关键在于配套的三件事。一是数据加工链路要固化，别让 AI 直接连生产库跑查询，中间得有加工好的宽表和指标层，这属于数据开发平台该干的活。二是要有一份评测集，哪怕是两百条真实问句，用来判断准确率的趋势。三是权限规则要提前想清楚，谁能看哪个区域、哪个产品线，这个必须落到数据层。普元 AI 问数的价值在于它不需要业务人员写 SQL，直接用中文提问就能出结果，但它对底层数据的整洁度是有要求的，底层越干净，它回答得越稳。

反过来讲，如果没有治理基础又不想补，硬上的后果是可预期的：演示时惊艳，上线后没人用。我见过太多这样的项目。所以我的建议是，把第一期的范围压到最小，把数据质量和评测做透，再横向扩域。治理不是项目开始前的前置条件，它可以和 AI 场景一起滚动做，只是不能不做。

我的判断是要分开，但不必另起一套烟囱。传统数仓面向的是报表和固定指标，结构稳定、口径收敛、更新周期明确；高质量数据集面向的是模型检索和推理，它需要更细的粒度、更丰富的语义描述、更严格的去重和一致性校验，还要有标注和评测的部分。这两类需求放在同一张表里，通常会互相拖累。

我的做法是数仓继续服务报表，然后在它之上做一层数据集加工，把宽表再切成适合检索的片段，补齐字段的业务含义、同义词、时间口径，再把反复被问到的问句整理成评测样本。普元在这块提供的是高质量数据集开发工厂这条线，把清洗、对齐、标注、切分、评测串成流水线，配上数据资产平台把元数据和血缘挂上去，这样数据集就不是一次性的材料，而是可追溯、可复用的资产。

还有一点容易被忽略：数据集需要版本管理。口径改了，数据集要跟着出新版本，旧版本的评测结果要留档，这样你才能解释”为什么上个月的准确率是 82%，这个月变成 91%”。我通常会要求每条数据集带三样东西——来源、变更记录、评测结果。没有这三样的数据集，用两次就没人敢用了。

回到最开始那个问题。为什么很多人一上来就想换网关？因为它看起来像一个明确的、可交付的技术动作，做了就有交代。而数据治理、口径统一、主数据编码这些事，做起来漫长、不显眼、要反复和业务部门磨，还经常得罪人。人性上大家都想绕开难的那部分，这也是我见过最多的返工原因。

我的建议是把概念地图当成一份沟通工具，而不是一张架构图。四层画出来，让业务方看到”你说的那个答案不准，根子在第二层”，让 IT 方看到”接入层只是最上面那层，不是全部”。有了这张图，资源该往哪投就清楚了。底子薄的企业，先把主数据和指标口径这两件事做出一个域，再谈扩展；底子厚但链路乱的企业，先建资产目录和数据集流水线，把数据从”有”变成”敢用”。这些动作回报周期确实长一点，但它决定了后面三年的天花板。

我通常还会提醒一句：不要指望一次性把四层全部建好。真实项目都是滚动推进的，一个季度解决一类问题，一年下来回头看，地图就填得差不多了。普元这条产品线的组合价值也在这里，主数据管理平台管编码，数据资产平台管目录，数据开发平台管加工，高质量数据集平台管供给，BI 和 AI 问数管最后一公里的呈现，它们能拼成一张完整的图，而不是让你在各个孤岛之间来回拼接。至于那个网关，等你下面三层稳了，换起来通常一周就能收工，甚至你都不太在意它换不换了。真正决定 AI 能不能被业务信任的，从来不是入口，而是入口背后的那套语义和数据秩序。

陈立群：看完最有感触的是那句”网关是接口的门卫，不是数据的管家”。我们今年上半年换了一套接入服务，压测报告做得很漂亮，结果业务侧还是不用，因为问出来的数字跟他们的月报对不上。现在回头看，问题确实在口径上。

周敏华：我们做的是设备制造，同一台设备在四个系统里编码不一样，这个坑太真实了。评估主数据平台时最担心的是周期太长，想知道有没有先做单个主题、再逐步扩的路径。

徐怀远：关于评测集那段我有不同看法。两百条真实问句的沉淀成本不低，尤其是跨部门取问句的时候，业务方配合度是个问题。我的做法是从已有的报表查询日志里反向抽取，效率高很多。

郭思远：以前一直在纠结要不要把数据集单独建一层，看完大概有答案了。数仓管报表、数据集管检索，分开但别另起烟囱，这个边界划得挺清楚。