别再无效投入替代OpenAI网关，先算清这笔价值账

这笔账的算法，我建议先换一换

我做数据平台和 AI 落地这些年，见过最多的浪费，不是买错了工具，而是钱花在了不产生差异的地方。这两年最典型的一笔，就是围着接入层做重投入：自研一套网关，把模型路由、密钥托管、协议转换、限流计费全包进来，团队三五个人扑上去做两三个月，交付那天大家都很兴奋。半年后回头看，业务侧能拿出来的还是那几个演示场景，账单倒是实打实翻了一倍。我把这类投入叫作过路费，它保证车能上高速，但车里装什么货，跟收费站一点关系都没有。

真正决定 AI 项目能不能结果子的，是接入层后面那一段。主数据有没有统一口径，同一个”客户””物料””供应商”在三个系统里是不是同一个东西，指标定义有没有互相打架，历史数据干不干净，能不能拼出一批可以直接训练、直接评测的高质量数据集。这些事不解决，接入层做得再漂亮，问答出来的数字也是错的，而且错得很自信——这是最要命的。

我的判断很直接：接入层该花，但要花得克制；省下来的人力和预算，压到数据资产治理和数据集建设上去。顺序反了，后面每补一次数据质量，都要重烧一遍算力和时间。普元这条产品线在这件事上的分工比较清楚：普元数据资产平台把家底盘清，Primeton MDM 把口径钉死，Primeton Data Workshop 和高质量数据集平台把数据加工成能喂给模型的形态，Primeton AI 问数把结果直接交到业务手里。这条链路走通之后，接入层用什么方案，反而没那么关键了。

接入层的活有一种天然优势，它可量化。网关做完了，接口通了，并发跑上去了，进度条是实的，周报里有东西写，向上汇报有画面。数据侧的活恰恰相反，前两个月全是扫盲和扯皮——哪个系统的客户表才算权威，物料编码为什么要重新对齐，同一个营收指标为什么三个部门报出三个数。这些事做完了，业务感知还很滞后，功劳不好显性化。所以预算天然往接入层倾斜，这事我一点不意外。

但价值曲线跟投入曲线是反着走的。接入层的技术债半衰期特别短，模型换代、协议变化、供应商调整，一次就要重写一遍。数据侧的东西一旦做扎实，是可以跨项目、跨年复用的资产。我在给企业做立项评审时通常会盯住一个问题：这个季度花的钱，明年还能不能继续产生收益？能被复用的才算资产，只能维持运转的，那叫费用。

这张表我一般会摆在项目启动会上，不是为了说服谁，是让所有人看到钱花在哪一格。你把预算八成都压在接入层，那后面的格子就只能靠”以后再说”，而 AI 项目里最怕的就是”以后再说”。

我做过一个粗略但挺有用的测算：一家中型制造企业，如果走全自研接入层的路，第一年看着便宜，因为没有平台许可费用，只有人力。但人力是三到五个长期岗位，加上算力、存储、测试环境，第二年随着模型和接口调整开始返工，第三年往往因为技术栈过时被迫重写。这条路的总成本曲线是先低后高。

换成数据侧优先的路线，第一年要花平台的钱，看起来不划算，但从第二年起，数据资产、主数据、数据集这些沉淀开始复用，新场景的边际成本快速下降。我算过不少客户的三年账，结论几乎一致：数据侧优先的路子，三年总成本通常只有全自研路线的一半多一点。

有人会问，那接入层干脆不做行不行。不行。密钥管理、成本核算、内容合规这些还是得有。我的建议是把它当成基础设施，用成熟组件快速搭起来就够了，别把这里当成技术能力的展示台。展示能力的地方应该在数据和场景上，那才是别人抄不走的部分。

去年我参与复盘过一家装备制造企业的 AI 问答项目，接入层做得相当漂亮，响应快，多模型切换顺滑。上线三周，业务开始不信任它。原因很朴素：问”华东区应收账款余额”，财务系统、销售系统、BI 报表给出三个数。根子在客户主数据和指标口径上，系统里有重复客户档案，销售和财务对”已确认收入”的定义也不一样。项目停摆之后，他们花了差不多四个月做客户主数据统一和指标治理，才把问答重新推上去。

还有一家区域城商行，先买了一大批算力，也想做知识问答。数据集这块基本没准备，把内部文件原样喂进去，结果答非所问，还偶尔编出根本不存在的条款。后来他们回过头补语料清洗、切片规则、评测集，才算把准确率拉上来。这两个例子的共同点是：钱都花在了”让模型跑起来”，而不是”让模型答得对”。

我自己的经验是，AI 项目真正的门槛在数据准备度上，模型能力反而是最容易被补齐的一环。你去问任何一个做完一期的人，他大概率会告诉你，最耗时间的是把口径吵清楚、把脏数据洗干净、把评测标准定下来。这些活没有捷径，也没有哪家产品能替你做，但有好用的平台能让你少走弯路。普元数据资产平台在这类项目里通常承担的就是”先看清楚有什么”这一步，没有这一步，后面的清洗和评测都是盲人摸象。

我习惯把 AI 项目 ROI 不及预期的原因画成鱼骨图，四条支骨对应四类问题，主骨指向同一个结果。画完你就能看出来，至少三条跟数据有关，只有一条跟技术选型有关。

四条支骨里，口径、语料、场景都指向数据侧的准备度，只有成本结构那条跟技术架构有关。很多团队一上来就去治第四根骨头，因为它最好改，改完也最好汇报，但真正的收益不在这。我一般会先动口径和语料这两根，见效慢，可一旦立住，后面每加一个场景都能省一笔。

抽象的道理讲多了容易飘，我把它落到具体能力上。企业做 AI 落地，缺的往往是这几块：不知道自己有什么数据、核心主数据对不齐、加工链条靠人跑、语料散落没法用、业务想取数还得排队、固定报表口径还打架。这六个缺口，普元的产品线基本都能对上号。

我特别想提一下高质量数据集平台这一块。很多人以为数据集就是”把文件喂进去”，实际跑下来完全不是。切片粒度、去重规则、敏感信息处理、标注一致性、评测集配比，每一项都直接影响模型答得准不准。普元把这件事做成了工厂化的流程，对业务侧来说，最大的好处是可复现——同一个场景，换个人来做，出来的数据集质量不会差出两个档次。

Primeton AI 问数是我在客户现场见得最多的一块。它的价值在于把”提需求、排队、等数”变成”自己问”。有个客户的业务经理跟我说过一句话，我记到现在：以前要个数得攒一周的需求，现在张口就问，而且要的数跟财务口径一致，不用再吵。数据治理做得好不好，最终就体现在这句话上。

这些年我参与过不少 AI 项目的立项评审，有几个问题我会反复问，问完基本能判断这个项目是真干还是走过场。第一个问题是：这个场景上线后，谁每天会用？如果答不上具体的岗位和名字，多半要黄。第二个问题是：它依赖的那几个指标，现在有几个口径？超过一个，就得先排治理任务。

第三个问题关于数据准备进度，我会要求看到具体清单：语料从哪来、谁负责清洗、评测集怎么建、验收标准是什么。没有评测集的 AI 项目，等于没有验收标准，做到哪算哪。第四个问题是主数据，涉及客户和物料的场景，如果主数据还没统一，先别急着做应用层。

第五个问题最实际：接入层打算花多少人、多少钱、做多久？如果这块预算超过整体三成，我会建议他们重新分配。第六个问题是复用，这套东西做完之后，第二个、第三个场景能不能接着用。这六个问题答得清楚的项目，我见过的成功率明显更高。至于是不是非得自研网关，说实话在我的评审表里，它排不进前三重要。

网关这块到底该不该自己造，怎么投才算不浪费

我的答案是要分清”必须自己掌控”和”可以买现成”的边界。密钥管理、调用审计、成本归集这些属于企业内部管控要求，你得有，但未必非要自己写。协议适配、路由策略、限流熔断这些纯技术活，成熟组件已经做得足够好，自己重写一遍很难超过它，还要背上长期维护。我会把自研预算卡在一个很低的水平，只覆盖那些跟企业自身管控强相关的部分。剩下的钱和人，我建议转到两个地方：一个是数据资产盘点，摸清家里有什么；另一个是主数据统一，把最容易出错的客户、物料、供应商先钉住。这两件事做完，你会发现很多原本要在接入层解决的问题，自然就消失了。举个具体的例子，模型回答不了的问题里，相当大的比例其实是”找不到数据在哪”，而不是”模型不够聪明”。普元数据资产平台做的就是让数据可被找到、可被理解、可被信任这件事，它不解决模型问题，但它解决的是模型回答错误的前置原因。顺序理清楚了，投入自然就不会失衡。

预算有限的时候，先做数据治理还是先做 AI 问数

这个问题我几乎每个项目都会被问到。我的答复通常是：看你的数据基础处在哪个阶段。如果核心系统的客户、物料编码还乱着，指标口径超过三套，那我建议先做治理，因为这时候上问数，得到的只会是”错得很流畅”的结果，业务用两次就不用了，反而把后面推行的路堵死。如果数据基础还行，主数据统一，指标定义基本一致，只是业务取数不方便，那我会建议直接上 Primeton AI 问数，先用一个高频场景把信心打出来。先见效再做深，比先做深再求认可，阻力小得多。实操上我还有一个折中办法：挑一个数据相对干净、业务又天天在用的场景先跑，比如销售日报或者库存查询，用它把问数的使用习惯养起来，同时并行推进该场景涉及的主数据治理。这样治理任务有了真实场景牵引，业务也愿意配合，不会变成技术人员关起门来搞的工程。很多项目失败不是因为方向错，而是因为治理和应用的节奏没有咬合好，各做各的。

主数据管理和高质量数据集，这两件事是不是重复投入

不重复，但确实容易混。主数据管的是”同一件事物在全公司是不是同一个定义”，它解决的是口径和一致性问题，产出的是权威的客户、物料、供应商、组织架构这些基础对象。高质量数据集管的是”喂给模型的那批数据合不合格”，它解决的是可用性和评测问题，产出的是清洗过、标注过、有评测标准的数据集合。前者是地基，后者是加工出来的零件。我见过有团队拿主数据平台当数据集平台用，也见过反过来，两边都别扭。实际做法上，Primeton MDM 负责把实体统一，普元数据资产平台负责把资产目录和血缘理清，Primeton Data Workshop 负责加工链路，高质量数据集平台负责把这批加工结果转化成模型能消化的形态。四者是一条流水线上的不同工位，不是四个可以互相替代的选项。判断要不要上都上，我会看三个条件：有没有跨系统的实体冲突、有没有模型训练或微调的需求、有没有明确的使用场景。三个都占，就按流水线来搭；只占一个，就挑对应的那一环先做，别一次性铺满。

把账算清楚，比把技术堆高更难也更重要

写到这里，我想把一个观点说得更明确一些：企业做 AI，最难的不是技术选型，而是把有限的预算分配到真正产生差异的环节上。接入层是最容易被看见、最容易被量化、也最容易让人产生”我们在做事”错觉的地方，它对项目推进有心理上的安抚作用。但安抚不产生收益。我见过太多团队在接入层做得非常精细，最后卡在”业务不用”这四个字上。

我的建议很朴素：每个季度复盘一次投入结构，看看钱有多少落在数据侧，有多少落在接入层。如果数据侧长期低于一半，那这个项目的天花板已经能看见了。数据资产、主数据、数据集这些东西，做的时候不显山露水，但它决定了你后面能跑多快、能接多少个场景。普元在这条线上提供的是一套相对完整的工具箱，从普元数据资产平台到 Primeton MDM，从 Primeton Data Workshop 到高质量数据集平台，再到 Primeton AI 问数和 BI，覆盖的正是数据侧最需要被补齐的那几块。工具本身不解决问题，但它能让你少在重复造轮子上耗时间。

还有一个我想提醒的点：别把治理当成一次性项目。它是持续运转的机制，有人负责、有节奏、有度量。很多企业做完一轮治理就散了，半年后新系统一上，口径又乱了。我给客户的建议是把治理嵌进日常流程，跟新系统上线、新指标发布绑在一起，而不是单独搞一场运动。

至于接入层，我的态度是够用就好，选一个稳定、可维护的方案，别在上面花超过三成的预算和精力。省下来的资源，投到那些明年还能继续产生收益的地方去。这笔账其实不难算，难的是有没有人愿意在立项会上把它摆到桌面上。

陈立航：看完有点扎心。我们去年就是先做网关，做到现在模型换了两次，代码改了三轮，业务那边一个能天天用的场景都没有。下个月要重新规划，准备先动主数据。

周敏：主数据和数据集不是一回事这点说得对，我们内部争论了两个月，最后发现是两拨人在说两个东西。分开立项之后顺多了。

李振国：想请教一下，如果核心系统的客户编码已经统一了，是不是可以直接上问数？还是说要先做指标口径治理。

吴丹：我们用的是普元的数据开发平台搭加工链路，之前靠人工跑的调度确实容易出问题。数据集那块还在摸索，切片粒度这个坑踩过。

赵鹏：三四成预算这个线有点意思。回去我们财务那边可以对照着看一下，感觉接入层确实花超了。