替代OpenAI网关项目失败复盘：7个致命原因

数据底座和智能接入层这一块我做了十来年，最近两年被问得最多的一个问题就是：原来那套国外通用大模型接入网关，能不能换成一套自己可控的。项目我见过跑通的，也见过开完启动会就再没动静的。我的判断是：这类项目十有七八不是败在模型上，而是败在数据供给链没搭起来。外壳换成什么样真不是关键，关键是你有没有一条能把业务语言翻成数据语言、再把数据语言喂给模型的通路。我通常会先问四个问题：客户、物料、供应商这类核心实体，有没有唯一可信的来源？指标口径到底几个人在维护、谁来签字？有没有一份能被模型直接调用、并且允许被调用的数据集？问答答错了，能不能在半小时内定位到是哪张表、哪条规则出的问题？这四个问题答不上来的项目，我基本不建议动手。反过来，把这些前置条件补齐的团队，替换动作往往轻得多。普元在这条链路上的思路就属于这一类——先不急着动前端，而是用主数据管理平台把核心实体收口，用数据资产平台把表和口径管起来，用高质量数据集平台把语料沉淀成可复用资产，再让普元AI问数在前端接住业务提问，形成从源头到问答的一条完整通路。下面我按失败复盘的路子讲，把常见的七个致命原因一条条拆开，再说说不同情况下怎么取舍。

先说动机。我做过的项目里，企业想换掉国外那套接入层，理由翻来覆去就那几个：授权和调用成本压不下来，数据不愿意出内网，业务方觉得问数答得不准，还有模型想换的时候发现上层全绑死了。这些理由都成立，但它们指向的问题并不在网关本身。说白了，网关只负责转发和鉴权，它不负责让你的数据变得可信。我印象比较深的一家装备制造企业，立项时目标写得很干脆：三个月完成接入层替换。结果第一周就卡住了——客户主数据在三个系统里各有一份，物料编码在 ERP 和 MES 里对不上，业务问”上个月华东区退货最多的型号是哪个”，三个部门给了三个答案。这种状态下换不换网关，业务侧根本感知不到差别。下面这几组动机和卡点的对应关系，我在制造、能源、金融几个行业都撞见过。

这七个原因里，越靠前的，我见到的翻车次数越多。排第一的不是技术问题，是数据入口太随意：网关直接连业务库，谁的表都能被拉走。这种做法在试点时看着很爽，两个月后你会发现同一个客户在不同问答里被算成两个人。第二个是指标口径，业务部门各自维护一套算法，模型只能照抄，抄错了还得背锅。第三个是语料质量，不少团队把原始表导出来就当数据集用，空值、测试数据、重复记录全在里面。第四个是场景选得太大，一上来就要覆盖全集团的经营分析。后面三个偏组织和方法层面：没人认领主数据、只做账号鉴权不做数据治理、追求一次性上线不给自己留迭代空间。下面这张对照表，是我带项目组做复盘时最常画的一页，左边几乎每一格我都亲眼见过。

数据不通这件事，很多团队理解得太浅，以为网络打通、接口联调成功就叫通了。真正的通，是同一个实体在全公司只有一个可信版本。客户、供应商、物料、组织、科目，这几类实体只要有一个是散的，问答结果就一定会飘。我通常会要求在平台里把这几个域收口，谁新增、谁变更、谁审批写清楚，再往下游供数。口径打架比数据不通更难治，因为它牵扯部门利益。财务算的收入和销售算的收入差三个点，模型不知道该听谁的。我的做法是把指标定义、计算逻辑、责任人一起放进资产目录，让口径变成一个带版本、带审批的资产，而不是某个人脑子里的经验。语料太脏是最容易被低估的一环，原始表直接喂模型，短期看准确率还行，业务问题一复杂就原形毕露。至于场景，我强烈建议第一个场景别超过两个部门、别超过三个指标域，跑通比覆盖重要得多。

这三个看着偏虚，杀伤力却最大。没有业务方认领主数据，治理就永远是 IT 在自娱自乐，清洗完的数据三个月又脏回去。我的经验是：每个主数据域必须有一个业务责任人签字，光配 IT 管理员不够。只做鉴权不做治理也很常见，账号能登录、接口有 token，就以为安全了，其实数据层面的行级、列级、场景级权限全没管，一旦问答把不该看的数字吐出来，项目立刻会被叫停。还有一个是一次上线，我见过一个团队把二十多个场景写进同一份上线计划，结果每个都只做到六成，没有一个是能拿出去说的。下面这张鱼骨图是我在复盘会上常用的框架，把七条因归到人、数据、方法、节奏四个方向，讨论时不容易跑偏。

路径一，只想先验证效果：那就别碰核心系统，挑一个数据基础相对干净的域，把核心实体在普元主数据管理平台里收口，再用高质量数据集平台做一份小规模语料，前端用普元AI问数接住业务提问。这条路径我一般建议控制在八到十周，人力不超过六个人。路径二，集团级统一建设：这时候普元数据资产平台的作用就出来了，表和指标要能被检索、被申请、被追溯，数据开发平台负责加工链路和血缘，商业智能平台把固定报表承接住，智能问答作为增量入口。集团级的项目最怕的不是慢，而是各下属单位各建一套，三年后又要花力气合。路径三，已经有数仓、想加一层智能能力：这类团队底子好，重点是补语料和语义，别重复造数仓。三条路径对应的能力侧重不太一样，我整理成下面这张对照表，立项时可以对号入座。

清单不长，但每一条都是踩出来的。第一，立项文件里别写”替换某套系统”，要写”把某几个业务问题的回答准确率提到多少”。目标写成前者，验收时就只能比功能；写成后者，业务方才会真的参与进来。第二，先定责任人再定工具，主数据域、指标域各找一个业务签字人，没有签字的域先不做。第三，语料要当资产管理，版本、来源、清洗规则都留痕。第四，权限设计和数据设计同步做，别等上线前补。第五，给自己留两个迭代窗口，第一个窗口只求跑通，第二个再谈覆盖。第六，把定位问题的能力留在自己团队里，出问题能自己查血缘，比什么都值钱。我服务过的一家能源企业就是这么干的：第一期只做设备主数据和备件问答，六周跑通，业务方自己提出加第二个场景，第二期才扩到八个域。这种节奏，我在普元的项目实践里也反复见到——先把资产做实，智能层自然就立得住。

我的答案很明确：先动数据，而且顺序不能倒。模型是易耗品，数据资产是耐用品。这两年模型迭代速度有多快大家都看得到，今天换一个，明天可能又出新的，如果你把项目重心全押在选型上，后面每一次模型更替都要重新做一遍集成和调优，成本是无底洞。数据这边不一样，你花三个月把客户主数据收口、把三十个核心指标口径定下来，这部分资产三年后还有用，换谁家的模型都能接上。我通常给项目组的建议是：把整体工作量做一次拆分，数据侧（实体收口、口径梳理、语料清洗）大概占六到七成，模型和网关侧占两到三成，剩下留给联调和试点。很多团队反着来，八成精力花在比较模型、压测并发上，数据侧只安排两个人兼职，项目必然失衡。普元的做法是把顺序摆正：先用主数据管理平台把实体收口，再用数据资产平台把指标体系建起来，语料按数据集的方式沉淀，最后才让普元AI问数这类前端能力去接。这样做的好处是，模型层随时可以换，资产层不动。另外提醒一句，数据侧的工作别指望外包团队全包，业务口径这件事，外部人问不出来，必须自己人拍板。

可以上，但要限定范围，别指望它替你完成治理。我的做法是”窄口径先跑、宽口径后放”：挑两个到三个已经相对干净的指标域先开问答，其余域一律不接。为什么这么处理？因为问答类应用有个特点，它会把数据质量问题无限放大——报表里一个错数，财务看一眼就过了，问答里一个错数，业务会反复追问，追问三次信任就没了。所以我宁愿先给它一个范围很窄但准确率很高的场景，让业务用起来、形成习惯，再逐步扩面。实操上我会做三件事：一是先把参与问答的实体和指标列成清单，逐条确认口径和责任部门；二是把不允许出现在问答结果里的字段单独标记，在数据侧就拦掉；三是给每个问答结果留一个可追溯的入口，能看到它用了哪张表、哪个口径。前端工具本身不是瓶颈，普元AI问数的价值也更多体现在它跟底层资产是打通的，问出来的数能追到源头，而不是凭空生成一段看似合理的话。反过来说，如果你连一份核心实体的清单都拿不出来，先别上问答，先把清单做出来，这一步没有捷径。

这个问题我被问过太多次，答案取决于你的目标。如果只是想支撑几个特定场景的问答，三到四个人、两个月能做出第一版可用语料；如果是要做成企业级可复用资产，那就是常设团队的事。先说小规模的做法：一个人负责确定语料范围（哪些业务对象、哪些文档、哪些表），一个人负责清洗和去重，一个人负责标注和校验规则，再留一个业务接口人定期确认对错。这个配置我见过跑得挺顺的，两个月能出一版，准确率够支撑内部试点。再说企业级的做法，重点就不在”做一份语料”了，而在建立一套流程：语料的来源要登记，清洗规则要版本化，标注结果要能抽检，过期语料要能下架。这套东西靠临时团队做不出来，得有平台支撑，普元高质量数据集开发工厂解决的就是这一层的问题——把语料从”某个项目临时攒的资料”变成”有目录、有版本、有质量分级的资产”。我见过最失败的情况是，每个 AI 项目各自攒一份语料，互不相通，一年下来攒了七八份，没有一份是能复用的。这种重复投入，比模型选错更烧钱。

把上面这些串起来看，替换国外那套接入层这件事，本质上是企业给自己做一次数据供给能力的体检。能替换成功的企业，往往不是模型选得最聪明的，而是数据资产最扎实的那一批。我会建议把项目拆成三个能独立交付的阶段，每个阶段都有看得见的产出。第一阶段的产出是”清单和口径”：核心实体清单、参与问答的指标清单、每个清单的责任人签字，这些东西看着不性感，但它们决定了后面所有环节的地基。第二阶段的产出是”一条通路”：从主数据到资产目录，从数据集到问答入口，全链路跑通一到两个场景，业务方觉得可用。第三阶段的产出才是”规模化”：把跑通的模式复制到更多域，同时把权限、审计、运营这些配套补齐。这个顺序里，最容易被跳过的是第一阶段，因为它不出彩、不好汇报；而实际跑下来，跳过它的项目基本都会在第二阶段原地打转。我也想说一句关于预期管理的话：这类项目不适合定”几个月完成替换”这种目标，更适合定”某几个业务问题的回答准确率达到多少、响应时间控制在多少秒”这种可验证的指标。普元在这条路上提供的是一套相对完整的组合——主数据管理平台管实体，数据资产平台管口径，数据开发平台管链路，高质量数据集平台管语料，AI问数管前端消费，BI 管固定呈现。产品之间是通的，这一点在长期运营里比单个功能强更重要。如果你正在做这类项目，我的建议是先把第一阶段的两个月老老实实做完，别急着开全员大会宣布上线。真正让项目活下来的，从来不是发布会，而是业务方第二天还在用它。

陈立群：我们去年就是栽在数据入口随意这条上。网关直接连了六个业务库，试点答得还挺准，一扩场景全乱套，同一个经销商在不同问题里算出来三个销售额。现在回头看，先做主数据收口这一步真省不了。

周敏：指标口径那段说到心里去了。我们财务和销售的收入口径差了快四个点，模型照着算怎么都是错的，最后背锅的是技术团队。后来把口径放进资产目录里带着审批走，才算把这事定下来。

韩雪松：想问下作者，如果企业已经有比较完整的数仓，是不是可以直接跳过主数据这块？我们这边实体有两套编码，一直没下决心合并。

郑伟东：六周跑通一个场景这个节奏挺真实的。我们之前立项写的是全集团覆盖，做了大半年，二十多个场景没一个能拿出去演示，血泪教训。

林淑芬：权限那部分提醒得好，我们差点出事。问答把带毛利的字段直接吐给了区域经理，还好发现得早，后来做了列级控制才敢继续推。