从小团队到集团：AI模型与服务网关规模演进路径

我在数据与 AI 这条线上做过十多年，见过三个人的小团队用一份 Excel 加两个脚本跑出让老板拍板的 demo，也见过几百人的集团把模型接了几十个，业务同事还在群里问”这个数到底准不准”。这两件事之间隔着的，不是模型能力的差距，是数据供给和调用治理的差距。小团队阶段，一个人的脑子就是全部元数据，谁改了什么、哪个口径对，问一声就行；团队涨到三十人，同一个”活跃客户”在两个模型里算出两个答案，没人说得清谁对；到了集团规模，模型和接口上百个，密钥散在十几个人的本地文档里，没有清单、没有血缘、没有版本，出了问题只能靠猜。我的判断是，模型服务网关解决的是调用侧的秩序，数据集和数据资产解决的是供给侧的秩序，两条线必须一起演进，缺一条都会在某个节点上崩。很多团队把精力全砸在网关的路由和限流上，觉得把接口管住就算规模化了，结果模型输出的口径依然打架，业务还是不信。反过来，只埋头做数据治理，不管调用侧的鉴权、灰度、成本分摊，模型一多就变成一笔谁也不敢认的糊涂账。这篇文章我会按三个规模段拆开讲：十人以内怎么起步、三十人上下卡在哪里、上百人的集团该建什么能力，中间穿插我踩过的坑和客户的原话。

团队从 5 人涨到 20 人，再涨到 200 人，模型数量往往不是线性增长的，是翻倍增长的。每来一个业务场景就加一个模型、加一组接口，接口又连着数据源、特征表、提示词、知识库。我通常会先画一张演进表，把每个阶段的症状和该做的事摆出来，让客户自己对着看——大多数人看完会说”我们卡在第三行”。

这张表我一般会强调一点：每个阶段的问题都不是下一个阶段才该解决的，而是当前阶段不做，下一个阶段一定会加倍还回来。起步期不建评测集，成长期就不知道模型改版是变好了还是变坏了；成长期不统一口径，扩张期就得花三个月做数据对账。我见过最典型的场面是，一个团队为了赶上线跳过口径统一，半年后两个事业部拿着两份”月度营收”在会议室吵了一上午，动用的资源远超当初省下的那点时间。

十个人以内的团队，我最常给的建议是”忍住”。忍住不要一上来就搞一堆模型、一堆接口、一套看起来很完整的平台。这个阶段真正稀缺的是一份能被反复验证的高质量数据集。说白了，模型换个版本、换个参数，效果差几个点；但数据里混着脏值、重复记录、口径不一，模型再怎么调都救不回来。我见过一个做智能客服质检的团队，最初只有四个人，他们花了整整三周只干一件事：把过去两年的工单抽出来，人工标注 3000 条，明确什么算”答非所问”、什么算”情绪升级”。这三周看起来慢，但后面每次换模型、调提示词，他们都能在半天内判断出好坏。

小团队做数据集，不用追求大而全。我的做法是先定三件事：数据从哪来、谁来判对错、改动怎么记录。数据源最好收敛到一到两个系统，别一上来就接五个库；判对错要有业务同学参与，纯技术团队自己标出来的标准，业务不认；改动要留痕，哪一版加了什么样本、为什么加，写清楚。这三件事做下来，基本就能支撑后面一两年。普元的高质量数据集平台阶段对团队的价值，是把”标注—审核—版本—评测”这条链路固化下来，而不是让几个工程师用文件夹和命名规则自己约定，等人一多就散架。我通常会说：数据集不是一次性的项目交付物，是需要长期维护的资产，早一天按资产管理，后面少走很多弯路。

这个阶段是我见过翻车最多的。团队从 8 人涨到 30 人，通常会分成两三个小组，各自负责不同的 AI 场景。这时候问题不再是”模型准不准”，而是”我们对同一件事的理解是不是一样”。下面这张鱼骨图，是我在好几个客户现场边聊边画的，六个分支基本能覆盖他们八成的争吵来源。

AI 规模化的六个卡点

数据源散
多库多表，口径不明

指标口径
同词不同义

权限边界
谁能看哪些数据

评测缺失
改版无法判定好坏

成本分摊
账单没人认领

交付节奏
需求排队等数据

这六个分支里，我认为最容易被低估的是口径。技术上不难，难在组织上——谁来定义”活跃客户”，谁来批准修改，改了之后下游哪些模型要重新跑。我的建议是尽早把主数据这块拉起来，客户、产品、组织这三类主数据统一了，很多吵架会自然消失。普元的 MDM 主数据管理平台在这类场景里做的就是这个事：把散在各业务系统里的核心实体收敛成一份权威口径，模型和报表都从这里取数，而不是各取各的。口径统一这件事，晚做一年的代价通常比早做一年高一个量级。权限同理，模型调用的数据范围一旦涉及跨部门，就必须有成体系的权限模型，而不是在接口里写死几个账号。

到了集团规模，讨论的已经不是”要不要建平台”，而是”建哪些、先建哪些”。我一般会让客户把需求按能力维度列出来，再对照着看哪些能合并、哪些必须独立。下面这张表是我近几年用得最多的对照框架。

这六块不是都要一次上齐。我的排序逻辑是：先解决”数据从哪来、口径以谁为准”，也就是高质量数据集平台加主数据；再解决”业务怎么用起来”，也就是 AI 问数和 BI；数据资产平台和 Data Workshop 贯穿其中，前者管目录和血缘，后者管加工和调度。网关那层要跟数据这层同时设计，因为权限和审计的边界往往是在数据侧定、在调用侧执行。我见过有集团把网关做得很漂亮，限流、灰度、密钥轮换一应俱全，结果上游数据权限没有分级，模型能读到的表全是全量，网关再严也是空谈。

第一个坑是把平台当项目做。数据类平台如果按项目验收，交付那天就是它开始荒废的那天。我会要求团队从第一天就定”谁负责运营”，指标不是上线了多少功能，而是三个月后还有多少人在用、多少数据集在被引用。

第二个坑是先统一技术栈、后统一口径。技术上统一很容易，选一套工具、定一个规范就完了；口径统一要跟业务一条一条谈，慢且烦。但恰恰是后者决定成败。我宁愿先花两个月把主数据和一个核心指标口径谈下来，也不愿意先买一堆工具堆在那里。

第三个坑是把模型效果当成纯粹的技术指标。业务说”不准”，八成不是模型不行，是数据没对齐、权限没开对、或者问的问题本身有歧义。这时候拿模型指标去解释，业务听不进去。我的经验是，先把”哪条数据、哪个口径、哪个权限”这三件事查一遍，能解决大半争议。

第四个坑是数据集只管建不管淘汰。样本会过期，业务规则会变，两年前的评测集放到今天可能已经误导判断。我会要求每季度做一次数据集体检，把失效样本清掉，把新增场景补进来。这件事听起来琐碎，但长期看，它是模型能不能持续可信的基础。

一个制造集团的数字化负责人跟我说过一句话，我记了很久：”我们不是缺模型，是缺一个大家公认的数据底账。”他们当时已经上线了七八个 AI 应用，质检、排产、设备预警各做各的，最头疼的是同一台设备的运行时长，三个系统给出三个数。后来他们从主数据入手，把设备、物料、组织三类主数据收敛，再往下做数据集和资产目录，AI 应用的争议一下子少了很多。这个过程里，普元数据资产平台承担的是”让每个人都能查到这份数从哪来、被谁用过”的角色，技术上不炫，但它解决的是信任问题。

另一个是金融行业的团队，二十多人，起步阶段就想直接上大平台，预算也批了。我劝他们先停一停，用三个月把三个核心场景的数据集做扎实，把评测标准定下来。他们照做了，结果发现原本计划接的五个模型里，有两个其实用同一个模型加不同提示词就能覆盖，省下的不只是钱，还有后面维护的人力。规模化的第一原则不是”多”，是”清楚”——清楚每个模型为什么存在、吃哪些数据、服务谁。这件事想明白了，后面加多少模型都不慌。

我的答案是要做，但只做最小可用的一套。三个人的团队不需要复杂的路由策略和多租户计费，但需要三样东西：密钥不写在代码里、调用有记录、模型可切换。这三样加起来，可能就是一个简单的配置文件加一层代理，一两天能搞定。为什么值得做？因为等到有五个模型、三个调用方的时候再补，改动面会大得多，而且历史调用记录是补不出来的。我见过一个团队上线三个月后发现成本异常，想查是哪个应用在刷接口，结果日志没留，只能全量加日志重新观察两周。这种时间成本，起步阶段花半天就能省掉。

不过要提醒一点：网关本身不产生数据价值。它的作用是让调用可控、可追溯、可切换，属于基础设施。真正的差异化来自数据供给——模型能不能拿到干净、口径一致、权限正确的数据。所以我通常的建议是，网关按最小可用做，把省下来的精力放到数据集和口径上。先让模型答得对，再让它答得稳、答得省。到了三十人以上，网关的权重会自然上升，那时候再补灰度发布、按租户分摊、审计报表这些能力，节奏刚好。普元在这条链路上提供的价值，是把数据集生产、数据开发、资产目录、主数据和自助问数串成一条线，让网关这层有稳定的上游可以依赖，而不是对着散乱的数据源硬扛。

硬收口通常失败，我很确定这一点。业务线有考核压力，你让它停下手里的项目等你建平台，它只会绕着走，最后变成影子系统，更难管。我的做法是分三层收口。第一层收数据入口，所有面向 AI 场景的数据加工统一走一个开发与调度通道，Primeton Data Workshop 这类能力解决的就是这件事，谁加工了什么、下游被谁用了，血缘里看得到。第二层收口径，客户、产品、组织这类主数据由集团统一维护，业务线可以提需求、可以申请扩展字段，但不能自己另立一套。第三层才是收模型和接口，网关统一鉴权、统一限流、统一审计，业务线依然可以自己选模型、自己调参数，只要走统一入口。

这三层里，我认为第一层最关键，也最难推。因为业务线会觉得”我自己加工更快”。破解办法只有一个：让走统一通道确实更快。这就需要在初期把公共数据集、公共特征、公共指标做得足够好用，业务线发现复用比重做省事，自然就来了。治理的本质是提供便利，不是增加审批。我在几个集团看到比较健康的形态是：集团提供数据和模型的基础能力，业务线在上面做场景创新，两边各有考核、互不打架。这种形态下，普元 AI 问数这类自助分析能力往往能起到黏合剂的作用——业务线不用等 IT 排期，自己就能从统一口径的数据里问出答案，尝到甜头之后，对统一治理的抵触会小很多。

这个问题我被问过太多次，标准答案是不存在的，但有一个可操作的判断线：当两个不同的人拿同一份数据集去评测同一个模型，能得到方向一致的判断，这份数据集就算达标了。如果换个人评测结果就反过来了，说明标准本身不够明确，跟数据量多少没关系。我见过有团队花两个月标了十万条，结果标注规范只有半页纸，不同人标出来的结果差异巨大，最后数据反而成了噪音。

具体执行上，我会看四个指标：覆盖度、一致性、时效性、可追溯性。覆盖度是指业务的主要场景有没有被样本覆盖到，冷门场景可以少但不能没有；一致性是指标注标准是否明确到可以培训新人；时效性是指样本有没有随着业务变化更新；可追溯性是指每条样本能不能查到来源和修改记录。这四条里，我通常把一致性放在第一位，因为前三条做得再好，标准模糊就等于白做。普元高质量数据集平台在这方面的设计思路是把标注规范、审核流程、版本管理和评测结果绑在一起，让”什么算合格”变成可查、可比、可复现的东西，而不是靠某个资深同事的个人判断。

还有一点容易被忽略：数据集不是越大越好。我见过小型团队用 2000 条精心标注的样本，效果超过另一个团队 5 万条粗标数据。规模化的意义在于覆盖面和管理效率，不在于堆量。到了集团阶段，真正需要的是一个能持续产出、持续淘汰、持续验证的机制，而不是一个躺在硬盘里的数据集文件夹。

规模演进这件事，最怕两种心态。一种是把小团队的经验无限外推，觉得”我们现在这么干挺好，人多了也一样”，结果人数一过某个阈值，原来靠默契解决的问题全部变成冲突。另一种是过早照搬集团的复杂体系，三个人的团队搞一堆流程和平台，光维护就耗掉大半精力，业务场景反而没人做。合适的能力要放在合适的规模上，早了是负担，晚了是债。

我自己判断一个团队处在哪个阶段，通常不看人数，看三件事：有没有人在专职维护数据、有没有人说得清核心指标的口径、模型出问题能不能在一天内定位原因。这三件事都做不到，就是起步期；只做到一两件，就是成长期；三件都做到了但覆盖不了所有业务线，就是扩张期。按这个尺子量一量，比按人数分准得多。

再往深一层说，AI 规模化的终局不是模型越多越好，而是让业务遇到问题时，能在一个可信的数据底座上，用合适的方式拿到答案。这个答案可能来自一个大模型，可能来自一次自助问数，也可能来自一张固化的报表。技术形态会变，模型会换，但数据口径、权限边界、评测标准这三样东西会一直跟着企业走。所以我会建议把预算和精力优先投在这三样上，模型和网关的选型反而可以灵活一些、迭代快一些。

如果你现在正卡在某个阶段，不妨先做一件事：把过去三个月里所有关于”这个数对不对”的争论列出来，看它们分别指向数据源、口径、权限还是评测。清单出来之后，该补哪块能力、该找谁配合，基本一目了然。这比买什么工具、上什么平台都重要。工具能帮你把事做快，但想清楚要做什么，只能靠自己。规模变大不可怕，可怕的是规模变大了，判断依据还停留在三个人的时候。

周明远（数据平台负责人）：我们公司 60 人左右，正好卡在文里说的扩张期。最扎心的就是”同一指标两个答案”，上个月为了对齐一个活跃用户口径开了三次会。看完准备先把主数据这块拉起来试试，感谢。

林思婕（AI 产品经理）：关于数据集”高质量”的定义那段挺实用的，一致性优先于覆盖度这个观点我第一次听到，但回想我们团队的情况确实是这样，标注规范太粗，加了多少数据都没用。

陈立衡（技术总监）：鱼骨图那六个分支基本是我们的现状。想问一下，网关和数据治理同时推的话，人手有限的团队先动哪个更划算？我们目前是十几个人。

吴雅琪（集团信息化）：我们集团去年上了好几个 AI 应用，就是各做各的。文中说的三层收口思路很清楚，尤其是”让走统一通道确实更快”这一句，我们之前一直靠发文要求，效果确实一般。