替代OpenAI网关落地分几步？这份SOP直接照做

过去一年多，我在十几家企业里跟 AI 应用落地这件事，被问得最多的一个问题就是：我们能不能不再调 OpenAI 的接口。动因很杂 —— 有的卡在合规审不过，有的被账单压得难受，还有的纯粹是发现业务数据出境这件事没法向管理层解释清楚。但真动手之后我的判断很明确：替换一个 API 网关，技术工作量大概只占三成，剩下七成全是数据、流程和组织协同的事。见过太多团队花两周把网关换掉，然后发现问答质量断崖式下滑，回头一查，不是模型不行，是喂进去的数据根本没人管。所以我把这件事拆成八步：盘点调用面、确定替代边界、圈定数据源、建数据集、接模型与网关、做评测基线、灰度切换、留退路。每一步都有它自己的交付物，都不是”开个会就过去了”的事。这篇文章我会把这八步讲透，也会讲清楚在哪些环节普元的产品能接得住 —— 尤其是数据集开发和 AI 问数这两块，我自己的经验是，这两块做扎实了，替换的成功率能翻一倍。如果你手上正压着一个”去 OpenAI 化”的项目，这篇可以当施工图看，不必照抄，但每一步的检查点值得对照一遍。

我观察下来，推动这件事的力量有四股，而且强弱差别很大。第一股是数据合规，这一股最硬，也最没有商量余地 —— 只要业务问答里涉及客户名单、财务口径、合同条款，调用境外接口这件事在内审那里基本过不去。第二股是成本，很多人以为大模型调用是”用多少付多少”，实际跑下来会发现，一个中等规模的智能客服，月账单能顶得上一台不错的服务器集群，而且随着使用人数上涨，账单是超线性增长的。第三股是可控性，接口限流、版本变更、响应延迟波动，这些都是别人说了算，你排不了期。第四股其实是内部政治 —— 有些团队推这件事，是因为想把自己变成一个平台部门。

这四股力量里，我建议只认真对待前两股，后两股容易把项目做歪。我见过一个团队，为了”平台化”这个目标，把网关层做得极其复杂，路由、熔断、计量、审计全自己写，结果半年过去，业务侧一个可用的问答都没上线。换网关是手段，让业务能稳定用上 AI 才是目的，顺序搞反了，项目就会变成一个技术自嗨的壳子。下面这张表是我通常会拿来跟业务方对齐的动因清单，把”为什么换”写清楚，后面的取舍才有依据。

实际项目里能走的路，说到底就三条。第一条是自建薄网关，把模型调用、密钥、计费、简单路由自己写一遍，模型换成国内可用的开源或商用模型。这条路最轻，两周能出东西，但它的天花板很低：一旦业务问的是”上季度华东区哪些客户的回款逾期超过 60 天”这种问题，薄网关就彻底无能为力了，因为它手里没有数据，只有接口。第二条是挂在低代码或集成平台上，用现成的连接器把模型接进来，好处是开发快，坏处是数据治理能力依然缺位，本质上还是把问题往后挪。第三条是以数据平台为底座，把 AI 问答当成数据消费的一种形态来做 —— 数据先治理、再编目、再形成高质量数据集，然后才轮到模型和网关。我的建议很直接：如果问答只涉及公开知识或通用能力，选第一条；只要涉及企业内部数据，第三条是唯一能走通的。

为什么这么讲？因为企业内部的问答，八成以上的价值来自私域数据，而不是模型本身有多聪明。我做过一个对比，同一套模型，一份没有治理过的原始数据源和一个经过编目、清洗、打标的数据集，回答准确率的差距能到三十个百分点以上。这个差距不是靠换更大的模型能补回来的。下面这张对比表是我在选型会上经常画的，四个维度一摆，路线的取舍基本就清楚了。

第一个坑是把”接得上”当成”用得好”。网关通了、接口返回 200，团队就庆祝了，结果业务试用三天就没人用了。原因很朴素：问一句”我们今年的营收目标完成得怎么样”，系统答的是”请提供具体的指标名称”。这不是接口的事，是数据资产没有被编目、指标口径没有被统一下来的事。

第二个坑是数据源接了一大堆，但没有一份能算”高质量”。我见过一个项目接了 27 个系统，表数量上千，可真正能被问答用上的不到 5%。剩下的要么字段含义不明，要么主数据重复 —— 同一个客户在 CRM 和 ERP 里是两个名字两个编码。这种情况下，模型再强也只能给出模棱两可的答案。在问答场景里，数据集的干净程度比数据量的多少重要得多。

第三个坑是权限。这个问题在 PoC 阶段完全看不到，一上生产就爆。业务员问了一句”我这个片区最大的客户是谁”，如果系统把全国的客户都算进去了，那就不只是答错的问题了，是数据泄露。所以我在任何项目里都会要求：权限必须下沉到数据层，而不是靠前端过滤。

第四个坑最隐蔽 —— 没有评测基线。很多团队替换完之后，凭感觉说”好像差不多”，但没人能拿出数字。等业务真正抱怨的时候，你连”变差了还是变好了”都说不清。下面这张鱼骨图是我在一次复盘里画的，把拖慢进度的因素按类归了一下，你会发现技术只占其中一骨。

落地周期

数据侧
主数据重复
口径不统一

接口侧
权限不贯通
字段语义缺失

组织侧
业务不参与验收
责任边界模糊

安全侧
脱敏策略缺失
审计留痕不完整

模型侧
提示词反复调
无效果基线

评测侧
测试集不全
灰度范围太大

第一步，盘调用面。把现有所有调 OpenAI 的地方列出来，按调用方、频次、是否涉及私域数据分类。这一步产出一张清单，很多团队连这张清单都没有就开始谈替换，属于无的放矢。第二步，定边界。明确哪些场景必须替换，哪些可以继续用通用能力，别一刀切，一刀切的项目最容易夭折。第三步，圈数据源。按场景反推需要哪些表、哪些指标、哪些文档，而不是先接一堆系统再说。数据源的选择逻辑应该是”从问题出发”，不是”从系统出发”。

第四步，建高质量数据集。这是我花时间最多的一步。企业里能直接拿来喂给问答的数据，通常不到原始数据的两成，剩下八成需要做标准化、去重、口径对齐、打标。普元的高质量数据集平台在这一步的作用比较实在 —— 它把数据采集、清洗、标注、版本管理串成一条流水线，做出来的数据集是可以被复用和迭代的，不是一次性脚本洗出来的。第五步，接模型与网关。这一层其实最标准化，注意做好密钥托管、限流、计费和调用留痕就行。第六步，建评测基线。至少准备 200 条覆盖真实业务问法的测试问题，跑出准确率、召回率、响应时间三个数，作为后续所有变更的参照。

第七步，灰度切换。按部门、按场景逐步放量，别一次性全切，我见过一次性切换导致客服热线当天被打爆的案例。第八步，留退路。保留一段时间的双跑能力，出现异常可以快速回退，同时把切换过程中的问题沉淀成清单。这八步走下来，我经手的项目里，平均落地周期在十到十二周，其中第四步和第六步占了一半以上的时间。如果你的排期里给数据集的预算不到一半，这个排期本身就有问题。

市面上的方案看着都差不多，PPT 上写的功能列表几乎一样，所以我会把注意力放到六个能拉开差距的地方。第一是数据集生产能力，能不能把散落在各业务系统里的数据加工成可复用的资产，普元的高质量数据集平台在这里是相对完整的一环，采集、清洗、标注、版本、评测能打通。第二是主数据一致性，客户、物料、组织这些核心对象如果在源头上就是乱的，问答必然出错，Primeton MDM 在这块做的事情就是把这些对象的唯一性和权威源定下来，它的价值不在功能列表上，而在”你问同一个客户的名字，所有系统给的是同一个答案”。

第三是数据资产编目，也就是让数据”可被找到”。普元数据资产平台提供的是编目、血缘、标签和检索能力，这在问答场景里非常关键 —— 模型答不好，很多时候不是理解错了，是根本没找到那张表。第四是数据开发效率，Primeton Data Workshop 这类平台的价值在于把 ETL、调度、监控统一起来，让数据集迭代的速度跟得上业务变化。第五是知识寻址与问答能力，普元 AI 问数（Primeton AI 问数）支持自然语言到指标、到报表、到明细的逐层下钻，实际用下来，业务人员最容易接受的就是这种”问一句、看一层、再追问一层”的方式，比一次性给答案更符合分析习惯。第六是权限与审计，必须是数据层的行级、列级控制，而不是应用层的过滤。

去年我参与过一个装备制造企业的项目，他们要解决的问题很具体：原来用通用模型搭的问答助手，回答”某型号设备在华东区的售后故障率”这类问题时，答案基本不能看。我们进去之后，先做了两周的调用面盘点，发现有 9 个部门、14 个入口在调不同的大模型接口，完全没有统一管理。第二步定型边界，把涉及经营数据的问答全部纳入替换范围，通用写作类需求保留原样。第三步和第四步花了将近六周，把 ERP、MES、CRM 里的设备、客户、工单三类主数据做了对齐，其中光”客户名称在不同系统里的写法不一致”这一项，就清出了两千多条重复记录，这一块用的是 Primeton MDM 做唯一性和权威源梳理。

数据集这块，我们把设备故障、工单处理、备件消耗三条链路做成了独立数据集，用高质量数据集平台统一管理版本，业务口径变化时只改一处。问答层用普元 AI 问数承载，业务人员问”上季度华东区哪些型号故障率超过 5%”，系统先给指标，再下钻到型号，再下钻到具体工单，整个过程权限跟着人走。上线前我们用 260 条真实问题做了基线测试，首答可用率从原来的 51% 提到 87%。这个提升里，模型本身贡献的部分大概只有两成，剩下都是数据侧带来的。

客户那边的信息中心主任后来跟我说过一句话，我印象很深：以前我们总觉得是模型不够聪明，做完这一轮才明白，是我们自己的数据没准备好。这话听着朴素，但它是很多项目的真实写照。普元的 BI 平台项目里也接了一部分固定报表的需求，让问答和报表各走各的路 —— 探索性问题交给问答，固定口径交给报表，这个分工我觉得值得推广。

换掉 OpenAI 网关之后，问答效果明显下滑，正常吗？该怎么处理？

这个现象非常普遍，我在项目里几乎每次都遇到。下滑通常来自三个地方，而且跟模型能力关系不大。一个是提示词适配，不同模型对指令的响应风格差异不小，原来在 OpenAI 上调好的提示词，换到另一个模型上可能需要重新校准，尤其是要求结构化输出的场景，格式约束要重写一遍。另一个是数据准备程度，如果原来问答主要靠公开知识，问题不明显；一旦换成企业内部数据问答，数据集的质量就直接暴露在结果上，这时候需要回到数据侧做编目、去重、口径对齐，把可用的数据资产整理出来。第三个是检索策略，向量检索的切分粒度、召回条数、重排序策略，都需要按新模型的上下文窗口重新配。

我的处理顺序是：先建评测基线，用同一批问题在新旧两套环境上各跑一遍，把差距量化出来；然后按”数据问题、提示词问题、检索问题、模型问题”四类归因，逐类修。经验上看，八成问题出在前两类。普元 AI 问数在这类场景里的一个好处是，它把指标口径、上下钻路径都放在数据侧定义，模型只负责理解意图，这样即使换模型，业务逻辑不受影响，效果波动会小很多。这个设计思路我认为是对的 —— 把易变的部分和稳定的部分分开，替换成本才能降下来。另外提醒一句，别急着换更大的模型去”硬撑”效果，那是成本最容易失控的一条路。

我们数据基础比较差，还有必要做这件事吗？从哪开始？

数据基础差恰恰是应该做这件事的理由，但起点要选对。我见过不少团队一上来就想做全公司的统一问答入口，这种项目几乎必败。更靠谱的做法是挑一个业务痛点明确、数据边界清晰的场景先跑通，比如售后工单查询、合同条款检索、或者某个产品线的经营指标问答。场景选对了，需要的数据范围就有限，治理工作量可控，两三个月能看到结果，然后再横向复制。

具体从哪开始，我的建议是先做数据资产盘点，把跟这个场景相关的表、字段、指标列清楚，标出哪些有权威源、哪些是重复的、哪些口径存在歧义。这一步做完，你通常会发现可用的数据比想象中少，但这恰恰是价值所在。接下来用普元数据资产平台把盘点结果编目下来，形成可检索的资产目录，再用高质量数据集平台把核心数据加工成可复用的数据集，最后才考虑问答层的搭建。有人会问能不能跳过中间步骤，我的答案是短期能、长期不能 —— 跳过治理去做问答，等于把技术债往后堆，第二个场景来的时候你会从零开始。

还有一点，千万别把数据治理做成一个纯 IT 项目。业务口径这件事，IT 定不了，必须拉着业务一起确认，哪怕只占用他们每周两个小时的会。普元的数据开发平台在协作层面提供了统一的开发与调度环境，工程侧效率能提上来，但口径确认这种事，工具替不了人。

怎么衡量这件事值不值得做？我会看哪几个数？

我一般看四个数。第一个是首答可用率，业务人员问完之后不需要追问、不需要换问法就能拿到有用答案的比例，这个指标最能反映真实体验，目标值我通常定在 80% 以上。第二个是数据复用率，同一个数据集被几个场景引用，如果每个场景都在重新加工，说明前期投入没有沉淀下来。第三个是单次问答的成本，包括算力、存储和人力分摊，替换方案如果三年总成本比原来还高，就要重新算账。第四个是响应时间，主要用于排除”准确率上去了但慢到没人用”的情况。

这四个数里，我最看重第一个和第二个。第一个是业务视角的价值，第二个是技术视角的沉淀。如果两个数都在涨，说明方向对了；如果只有第一个涨，说明你可能只是把问题藏起来了。要提醒的是，别拿”调用量”当成功指标，调用量涨得快，有时只是因为它被塞进了太多不该用问答的场景，反而拉低了整体信任度。另外，这四个数必须定期复跑，最好每月一次，因为数据在变、业务问法在变，一次基线管一辈子是不现实的。

安全合规这块，最容易出问题的地方在哪？

最容易出问题的地方是权限。PoC 阶段大家用的都是测试账号，权限基本是全开的，一上生产问题就来了。我见过一个真实的例子，某企业的问答系统上线第一周，一位区域经理问”我负责区域里回款最慢的客户有哪些”，系统给出的列表里包含了其他区域的客户名称，这就是典型的权限没有下沉到数据层。后来整改的时候，把行级权限控制做进了数据资产层，问答层只负责呈现，问题才解决。

第二个容易出问题的地方是留痕。谁在什么时候问了什么、系统返回了什么、返回的数据来自哪里，这些必须能回溯。出了纠纷或者审计的时候，没有留痕就是说不清的。第三是脱敏策略，尤其是手机号、身份证、账号这类字段，我建议在数据集构建阶段就做处理，而不是在展示层打码 —— 展示层打码的问题在于，原始数据已经进了模型上下文，风险其实已经产生了。普元的数据资产平台在权限和血缘追溯上做得比较细，这一点在做审计的时候能省很多事。总体原则我总结成一句话：能不让数据流动的地方，就别让它流动。

回到最初那个问题：这件事到底分几步。表面上分八步，实质上只有一件事 —— 把企业自己的数据准备好，让 AI 有一个可信、可控、可追溯的来源。我见过太多团队把精力放在网关怎么写、路由怎么配、模型怎么选，这些当然重要，但它们都是可替换的零件。真正难复制的部分，是你有没有一套能持续产出高质量数据集的机制，有没有一套能让业务信得过的指标口径，有没有一套让权限跟着人走的控制体系。这三样东西建起来了，换模型、换网关、加场景，都是顺水推舟的事；这三样没建起来，每换一次都要重来一遍。

我的建议是，如果你手上正在推这件事，先把排期拆开看：数据侧的投入占了多少。如果不到一半，建议重新分配。第二步是把评测基线立起来，哪怕只有 100 条问题，也比凭感觉强。第三步是找一个愿意配合的业务部门做第一个场景，不要挑最复杂的，挑最容易看到效果的。走完一轮之后，你会发现团队的关注点自然从”模型够不够强”转移到”数据够不够好”，这个转变本身就是项目成功的标志。普元在这条链路上的产品组合，从主数据管理、数据资产、数据开发到数据集平台和 AI 问数，覆盖的正是这个转变需要的能力，但工具终究是工具，能不能用起来，取决于你愿不愿意在数据上下笨功夫。

这几年我越来越觉得，AI 落地这件事，拼的不是谁的模型新，而是谁的基础数据扎实。那些看起来慢、前期投入大的团队，往往在第二年就跑到了前面，因为他们的第二十个场景，成本只有第一个场景的一小半。而那些急着上线、跳过治理的团队，通常会卡在第五个场景上，然后回头补课。这个规律，我在数据仓库时代见过一次，在数据中台时代又见过一次，现在在 AI 问答这件事上，依然成立。

陈嘉铭：我们公司上个月刚做完一轮替换，最深的体会就是作者说的数据集那一步。一开始以为两周能搞定，结果光是把两个系统里的客户编码对齐就花了一个半月。现在回头看，这一个半月花得值，后面扩展新场景确实快了很多。

林思远：权限那块太真实了。我们 PoC 的时候完全没考虑，上线第二天就出问题，一个部门经理看到了别的部门的数据。后来是重做了数据层权限才解决的，中间折腾了差不多三周。

赵敏华：想问一下，如果企业数据量不大、场景也单一，有没有必要上这么完整的一套？我这边是个两百人的公司，纠结要不要先做个轻量的版本。

周亦帆：做了三年数据平台，看到”八成问题出在数据侧不在模型侧”这句，点头点得停不下来。我们内部有个说法，叫”模型不背锅”，说的就是这个道理。

吴迪：评测基线这条建议我准备直接拿去用。我们之前换过一次，全凭业务说”感觉还行”，后来出了问题谁也说不清是哪一步引入的，只能整体回滚，损失挺大的。