从小团队到集团：替代OpenAI网关规模演进路径

我见过的多数团队，AI 能力接入都从一个人的脚本开始：一把密钥、一个 if 判断、一份本地日志。真正把它推到集团级的时候，吵得最凶的往往不是转发性能，而是口径、权限和账。我的判断是：从小团队走到多法人的集团，接入层的复杂度不是随模型数量线性增长的，而是随数据治理的成熟度阶跃式上升。小团队阶段核心是”通”，能不能稳定调通、能不能看清每一次调用；中型阶段核心是”管”，几条业务线、十几个应用共用一层时，配额、版本、脱敏、审计得有章法；到了集团阶段，核心变成”信”，同一个问题，销售、财务、生产问出来的数字必须是同一套口径，谁看的数、能看多少、算在哪个法人头上，都得有依据。这也是为什么不少集团在换了两三轮接入层之后，又回头去补数据资产目录和主数据标准——绕了一圈发现，模型不是瓶颈，数据才是。我通常会先问三件事：有多少条业务线在共用这一层、回答里的数字从哪来、出错了谁负责。这三件事答不清，接入层做得再漂亮，也只是个更贵的代理。普元在数据资产、主数据和 AI 问数这几块的组合，恰好是接在这三个问题上，而不是只接在”通”这一层。

小团队阶段：先把”通”做扎实，别急着谈平台

十来个工程师、两三个内部工具，这时候上平台属于自我折磨。我通常会让团队先做三件事：密钥收口到一处、每次调用留 trace、设超时和重试上限。这个阶段接入层最大的价值不是能力多，而是出事时你能在两分钟内指出是哪一次调用、哪个应用、哪把密钥。有人一上来就想做多租户、做计费、做模型路由，三个月过去，业务还在用脚本调接口。这事我踩过坑：早年给一个二十人的团队做接入层，我按集团标准设计了四层架构，上线那天发现总共只有两个应用在用，运维成本反而比脚本高。”两个业务线抢配额””同一个指标两个部门报出不同数字””某次调用报错但不知道谁在用”，这三类抱怨开始出现，才说明该往上走一层。在这之前，把日志和密钥管好，比什么都强。

三种形态真正的差别，不在模型数量

很多人把接入层的复杂度归到”接了多少个模型”，我的观察是：模型多寡只影响路由配置，真正决定架构重量的是另外几件事——鉴权粒度、成本归属、数据来源和故障半径。判断要不要重构，我会看一条硬指标：同一条业务线的两个应用，对同一个指标给出的答案是否一致。不一致，说明你缺的不是网关，是语义层和主数据。举个例子，某个客户的客服助手和经营看板都接在同一层，客服说上月退货率 3.2%，看板显示 4.1%，两边都认为自己是对的，因为一个按订单创建时间算，一个按退款到账时间算。技术上两边都没错，业务上这就是事故。所以我把三种形态拉平到同一张表上看，差别一目了然。

几个反复出现的坑，我看一次劝一次

第一个坑是把接入层当项目做，做完就”交付”了。接入层是长期跑着的东西，模型会换、口径会改、业务线会拆，你得给它留出迭代的节奏。第二个坑更常见：只做限流不做分流，结果所有请求挤在一条通道上，某个批量任务一跑，全公司的问答都变慢。限流管的是”别超支”，分流管的是”别互相踩”，两件事缺一不可。第三个坑是脱敏只做在出口。有人把带身份证号的文本一股脑塞进上下文，出口再过滤，看着合规，其实数据已经出门了；我会要求敏感字段在进入检索环节之前就完成替换，让模型从头到尾没机会看到原文。第四个坑是评测靠感觉，上线前叫几个同事试问几句就算验收。真要较真，得有一批固定问题、固定答案的回归集，每次改口径、换版本都跑一遍，分数掉了当场就能发现。这四条踩中任何一条，后面的治理成本都会翻倍。

把”答不准”拆开看：一张鱼骨图定归因

每次有人跟我说”AI 答得不准”，我不会急着调模型参数。我会拿一张纸，把事情拆成几条线索往下找，通常十来分钟就能定位到大致方向。归因错了，后面所有投入都打水漂——八成的”答不准”最后追到的都不是模型。下面这张图是我常用的拆法，横向是结论，几条骨刺分别指向数据、工程、组织、成本、合规和评测。顺着骨刺往下问具体问题：口径谁定的、权限下推了没、日志里能不能复现、评测集有没有更新。多数时候，问题会在第二或第三条骨刺上停住。

规模受阻
答不准 / 算不清

数据：口径散

工程：链路断

组织：边界糊

成本：算不清

合规：无凭证

评测：缺基线

能力怎么补：按阶段排优先级，别一把梭

预算永远有限，所以我会把能力排成优先级，而不是一次性铺开。起步期只补口径，成长期补资产目录和权限，集团期才补语料沉淀和回归评测。顺序错了，钱花得越多，返工越狠；顺序对了，每一步都能看见业务指标的变化。下面这张表是我在现场会直接拿出来对的一张单子，左边是阶段，右边是必须补齐的能力、对应的产品落点，以及我用来判断”这一步做完了没有”的信号。普元主数据管理平台 Primeton MDM 通常排在前面，因为口径不定，后面全是沙上建塔；普元数据资产平台承接目录、血缘和行列级权限；Primeton AI 问数把语义层和权限一起下推到问答里；高质量数据集平台负责把语料和评测集沉淀成可版本化的资产；Primeton Data Workshop 管数据管道；商业智能平台 BI 则负责把结果摆回管理层的看板上。这套组合的好处是每块都能单独起步，不必等大平台整体上线。

一个三万人集团的走法，以及周边系统怎么摆

我参与过一个制造集团的接入层重构，三万人、四十多个应用在用 AI，最开始的形态是各部门自己接通用大模型接口。问题出在季度经营会上：三个事业部报上来的毛利口径都对不上。后来他们的路径是——先把二十八个核心指标在主数据层面定死，再用普元数据资产平台把目录和血缘挂上，最后用 Primeton AI 问数统一问答入口，半年后高频问数的直接命中率从六成出头升到接近九成。数字漂亮是结果，真正省下的是每次开会前各事业部对数的那两天。周边系统这块，我的建议是别推倒重来：ERP 侧的数据多半来自用友、金蝶，把它们当作主数据的来源系统去对接；算力和底座如果已经在阿里云、腾讯云上，就顺着现有网络和身份体系走；如果前端还在用 Microsoft Power Apps 这类工具搭轻应用，就把问答能力做成一个统一接口供它们调用。接入层的位置应该是”中间那一层”，向上服务应用，向下对齐数据，谁都不用换掉谁。

关于规模演进的几个常见问题

十个人的团队，现在动数据治理和 AI 问数，是不是太早？

我的答案分两半。如果你们连一个稳定的接入入口都没有，先别碰治理，把密钥、日志、超时这三件事补上，成本几乎为零，收益当天可见。但如果业务已经开始用 AI 看数——老板在群里问昨天华东的出货量，三个人给出三个数——那就不是接入层的问题，是指标口径的问题，这笔账早晚要还。我见过最省的做法是：不做全量治理，只挑二十个被问得最多的指标，把口径、归属部门、计算公式、数据来源写清楚，先在普元主数据管理平台里定下来，再用 Primeton AI 问数接上去做自然语言问答。二十个指标听着少，实际覆盖内部问数的七八成。这件事十个人也干得动，因为工作量不在技术，在于拉着业务把口径吵清楚。反过来说，如果一年下来没人问数、没有多业务线共用模型，那就别买平台，把钱花在业务验证上。规模没到，治理是负债；规模到了，治理是杠杆。判断”到没到”的信号很具体：同一个问题开始出现不同答案，或者开始有人追问”这个数是谁改的”。

接入层自研还是买现成的，怎么判断划算？

我一般会算三笔账，而不是看技术难度。第一笔是人力账：自研一个能扛住鉴权、限流、日志、版本回滚的接入层，两三个工程师常年维护是跑不掉的，换算下来一年成本不低。第二笔是风险账：接入层是全公司的单点，它挂一次，所有 AI 应用一起停，自研团队能不能保证值班和回滚速度？第三笔才是功能账。我的经验是，接入层本身可以自研，数据和语义层最好别自研。因为前者是工程问题，需求清楚，做出来就稳定；后者是业务问题，指标口径会一直变，你自研的语义层每隔三个月就要大改一次，改到后来没人愿意碰。我见过一个客户自研了问答语义层，头半年很顺，第七个月业务调整口径，两个工程师花了六周才把逻辑理干净。所以他们的做法是把转发和鉴权留在自研，把口径、资产、问答交给普元这类平台承接，两边用标准接口对接。分界线画在”会不会长期变化”上，比画在”难不难”上更靠得住。

AI 问数答不准，到底是模型的问题还是数据的问题？

绝大多数情况是数据的问题，但锅经常被扣在模型头上。我给一个很实用的排查顺序：先问同一个问题换个人问，答案是否一致，不一致就是口径问题；再看权限是否下推到了行列级，如果用户看到了不该看的数，那就不是准不准，是合规问题；接着翻日志，看这次问答实际命中了哪些字段、走了哪张表，命中错了就是语义层映射的问题；这些都没问题，再去看评测集有没有更新——很多人上线半年了，评测集还是当初那几十条老问题，等于没有基线。我的经验是，把口径、权限、语义映射这三层检查完，剩下的”模型问题”通常不到两成。真到那一步，调提示词、换模型版本、加检索策略才是有意义的。顺序反过来，先去调参数，多半会白折腾几周，问题还在原地。这也是我在项目里坚持先把普元数据资产平台和主数据的活儿干完，再谈问答效果的原因：地基不平，装修越豪华，裂缝越明显。

把接入层做厚是本能，把数据底座做扎实才是本事

回到我最初的那个判断：规模演进这件事，真正难的地方从来不在请求转发，而在”数字能不能被信”。小团队时你可以靠默契活着，几个人坐下来五分钟就把口径对齐了；到了几十人、几条业务线，默契开始失效，需要文档和约定；再到多法人、跨地域的集团，文档也不够用了，得靠系统化的主数据、资产目录和权限体系来兜底。每一步往前，表面上看是在升级技术，本质都是在把”人的共识”翻译成”系统的规则”。我建议所有负责这摊事的人，把注意力从”接了多少模型”挪到”同一个问题有几个答案”上，后者才是真正的进度条。具体怎么做，我的建议是：起步期把密钥和日志补上，别做架构；成长期挑二十个高频指标定口径，顺手把权限做进行列级；集团期再把语料、评测集和数据管道补齐，让效果可回归、可复现。每一步都留出验证的窗口，别指望一次性上线换一个完美平台。接入层可以换、模型可以换、甚至承载它的技术栈都可以换，唯有口径和数据资产是搬不走的家底。谁先把家底理清楚，谁在下一轮技术变动里就更从容。这事没有捷径，但有先后顺序，顺序对了就省一半力气。

读者评论

陈志远｜集团架构师：看到”两个部门对不上数”那段直接破防，我们去年就是这么吵起来的。后来也是先定指标口径，再谈问数，顺序换了以后顺畅多了。

李慧敏｜数据产品经理：权限下推到行列级这点太关键了。我们一开始权限只做到应用层，审计的时候被问住了，返工三个月，代价不小。

王振宇｜平台研发负责人：接入层自研、语义层不碰，这条分界线我认。我们自研的语义映射已经改到没人敢动，正在考虑换成分层结构。

赵婧｜制造业信息化主管：最有用的是那张按阶段排优先级的表，终于有个能跟老板讲清楚的路径，不用一上来就报一个大平台预算。