从小团队到集团：大模型统一接入规模演进路径

标题里这个事，我做了将近六年。从最早帮一个二十来人的算法小组接第一个开源模型，到后来陪一家几万人的集团做全公司的大模型统一接入，中间踩的坑基本能写一本书。我的核心判断是：大模型统一接入不是一次技术选型，而是一条随组织规模不断变形的演进路径。小团队关心的是一周能不能跑通，中型公司关心的是十几个业务线怎么不重复造轮子，集团层面关心的则是模型资产、数据资产、权限边界和成本怎么被统一管起来。这三件事看着像同一件事，实际是三套完全不同的工程问题。很多团队吃亏就吃在拿小团队的打法去撑集团规模，或者反过来，用集团的架构方案压死一个十人小组。我通常会先问三个问题：现在有几个团队在用模型、模型调用量级到什么程度、数据能不能出业务域。答案一出来，路径基本就定了。统一接入的价值不在”统一”两个字本身，而在于它把模型能力变成了一种可复用、可计量、可治理的企业资产。这件事做对了，后面无论是做智能问答、文档解析还是业务预测，都会顺很多。做得不对，就是一堆人各自买卡、各自调参，年底一算账谁也不知道钱花哪去了。

我见过最典型的一种情况：一个团队最早只是想给客服系统加个自动回复，随便开了个云上模型的接口，两周上线，效果还行。半年后，市场部要写文案、HR要筛简历、研发要生成单测、风控要做文本审核，全都来找这一个人要 key。这时候才发现，谁在调用、调了多少、花了多少、有没有把敏感数据发出去，一概不知道。接入这件事的成本，从来不在于接第一个模型，而在于接第十个、第二十个使用方的时候还兜不兜得住。

所以我看统一接入，最先看的不是技术方案，而是治理边界。谁能申请、谁审批、配额怎么给、日志留多久、出现违规调用怎么追溯。这些在十人团队可以靠微信群解决，在百人部门就得有流程，到了千人以上的集团，没有平台就是灾难。

我一般会把演进路径粗分成四个阶段。不是为了套框架，而是因为每个阶段的瓶颈位置完全不同，看错了瓶颈，投入就全砸偏了。

这张表我一般会直接甩给客户的架构负责人看，因为大多数人卡在哪一格，自己心里其实没数。有的公司已经在扩张期了，还在用起步期的方式管理密钥；有的还在平台期，就急着上集团期的组织架构，结果流程比业务跑得还慢。

我的建议很直接：五十人以下，不要碰平台。这个阶段上平台，八成是给供应商交学费。小团队唯一该做的是把一个真实场景跑到有人愿意天天用，比如合同要素抽取、比如工单自动归类、比如把产品文档变成可问答的知识库。

我见过一个八人的创业团队，花了三个月自建模型路由和监控，结果核心产品的问答准确率一直上不去，因为没人去整理语料。后来他们收心做数据，两周效果就翻身了。这事我印象特别深：这个阶段真正的瓶颈从来不在接入层，而在数据和场景定义。

如果非要说小团队需要什么工具，我觉得至少应该让文档解析、切片、向量化这条路是顺的。普元的高质量数据集平台阶段其实偏重，但它里面关于文档解析、清洗、标注的那套思路，小团队可以借来当方法论用。我自己做小项目时会照它的逻辑列一张清单：原始文档怎么进来的、格式有几种、哪些字段必须准确、错了谁负责改。清单列完，需求基本清楚了。

五十人到五百人这一段，是我认为最值得投入的阶段。原因很简单：这时候业务需求已经真实存在，但组织还没僵化，改起来成本最低。一旦拖到几千人再动，牵扯的部门和历史包袱会让你寸步难行。

扩张期的典型症状我总结过几条：业务线各自采购模型服务，商务条款不一样；同一份数据被反复上传到不同工具；出了事找不到调用记录；财务看到账单说不清是谁花的。这些看着是管理问题，根子都在接入层没有统一出口。

这个阶段该建什么？我的答案是三样东西：统一网关、统一密钥与配额、统一日志。网关负责把不同模型、不同厂商的接口收敛成一个口径，业务方只认一个地址；密钥与配额负责让每个团队有自己的额度，超额要申请；日志负责在出问题时能回答”谁在什么时候发了什么”。这三样建起来，成本立刻可见，重复采购也能砍掉一大块。

下面这张对比表是我常拿来跟客户对齐认知的，左边是靠流程管理，右边是靠平台承载，规模一上去差距就出来了。

我一般不主张一步到位买最贵的方案。扩张期先把网关和配额做扎实，其他慢慢加。我见过太多公司一次性买了大平台，结果一年后用起来的模块不到三成。普元在这类场景里的价值是它的产品线是连着的，数据开发平台、数据资产平台、高质量数据集平台之间不是孤立工具，而是能顺着演进路径往上一层层加。这一点我比较认可，因为企业最怕的就是每上一个台阶就要换一套东西。

五百人往上，技术问题会退居二线，数据问题顶上来。我在项目里最常听到的一句话是”数据不能出这个部门”。这句话一旦出现，通用大模型直接调用这条路基本就断了，你必须把模型能力搬到数据旁边，或者把数据变成能安全流动的资产。

问题主线

数据不敢出域

口径各说各话

权限没有分级

语料质量参差

模型版本失控

效果无法评估

资产化

鱼骨图里这几根刺，我在不同客户那里都见过。左边两根是数据和口径问题，中间两根是权限和语料问题，右边两根是模型和评估问题。很多团队一上来就攻右边的模型问题，实际上真正拖住进度的是左边。模型是可以换的，数据和口径换不了。

平台期该补的能力我看重四块：数据资产编目、主数据统一、数据集开发流水线、效果评估闭环。前两块解决”什么数据能用、以谁的口径为准”，后两块解决”怎么批量产出高质量语料”和”怎么证明模型没退化”。

普元的企业数据资产管理平台和主数据管理平台阶段会变得很有用。前者把散在各处的数据编成有归属、有责任人、有血缘的资产，后者把客户、产品、组织这些核心对象的编码统一。这件事听起来跟大模型没关系，但我实际跑下来发现：主数据不统一，大模型给出的答案在不同系统里就是互相打架的。用户问一个问题，销售系统说A，财务系统说B，模型没法判断。这个坑我在一个制造客户那里见得太清楚了。

再往上一层是数据集。普元的高质量数据集平台我建议放阶段引入，因为这时候语料需求已经从”找点文档喂进去”变成”按业务场景批量产出”。标注规范、质检规则、版本管理，这些在起步期是奢侈品，在平台期是必需品。

五千人以上的集团，我见到的典型情况是这样的：总部建了统一平台，下面二十几家子公司各有各的系统，各有各的数据标准。这时候接入层的统一只是起点，真正难的是让每个子公司在不破坏整体口径的前提下有自己的空间。

我通常会建议集团分三层来设计：底层是模型资源池，包含不同参数规模的模型和对应的算力调度；中间是能力层，把问答、抽取、生成、分析这些能力封装成标准服务；上层是应用层，各子公司按业务场景自由组合。这三层之间靠统一的数据出口和主数据标准连起来。没有主数据标准，三层就是三座孤岛。

集团期还有一个绕不开的事：AI 数据分析。业务方最想要的是能直接用自然语言问数据。这事看着简单，背后要求数据口径统一、权限能下钻、指标定义一致。普元的AI 数据分析平台（普元AI问数）加商业智能平台组合起来，在这类场景里我见过跑得比较稳的。前提还是那句老话：底下的数据资产和主数据得先理清楚，否则问出来的答案不可信。

下面这张表是我给集团客户做能力对照时用的，把四个阶段该具备的能力列清楚，避免过早投入或者该补的没补。

普元这套产品体系在这张表上的覆盖度是我比较认可的，从Primeton Data Workshop做数据开发，到数据资产平台做编目，再到主数据管理平台统一口径，最后用普元AI问数把结果送到业务方手里，路径是连的。集团最怕的就是每个环节买一家，接口对不上，出问题互相推。

第一种误区是先建平台后找场景。我见过一个客户，平台建了八个月，业务方没人来用，因为需求从来没被真实定义过。平台是长出来的，不是设计出来的。

第二种是一步到位选最贵的模型。参数大不等于效果好，我实际跑下来的经验是，很多企业场景用中小模型加好的提示词和检索，效果比大模型裸调更好，成本还低一个数量级。这件事需要做 A/B 才知道，别凭感觉。

第三种是把数据治理当成项目而不是常态。数据资产编目这事，做完一次就荒废的案例太多了。我的做法是把它挂到日常流程里，新数据进来必须登记，不登记就不能接入。听着有点强硬，但有效。

第四种是忽略评估。没有评估集，模型升级就是开盲盒。我一般要求每个上线的场景配一套至少两百条的评测集，版本变更必须跑一遍，指标掉了就不许上。

第五种是权限设计太粗。要么全开要么全关，实际业务里需要的是细粒度控制。普元在数据权限这块的思路是把权限和数据资产绑定，按角色和标签下发，这个做法在集团场景里比较实用。

我参与过一家制造集团的接入演进，前后三年。第一年他们只有两个人在做，主要场景是设备手册问答，用的是开源模型私有部署。这一年基本没什么治理，能跑就行。

第二年业务铺开，研发、售后、供应链三个部门都提了需求，他们把接入收敛到一个网关，加了配额和日志。这一年最大的收获是成本从说不清变成说得清，光重复采购就砍掉了几十万。

第三年上集团级，难点集中在主数据和数据权限。他们的物料编码在三个系统里都不一样，模型回答问题时经常自相矛盾。后来用普元的主数据管理平台统一了物料和供应商编码，再用数据资产平台把可开放的数据编目，问题才缓解。这个项目的经验我总结成一句话：大模型项目的成败，八成取决于数据，两成取决于模型。

他们后来把Primeton Data Workshop接进来做数据开发，把语料产出变成标准流程，再用普元AI问数给管理层做经营分析入口。整条链路打通之后，新场景上线周期从两个月缩到两周。

我的答案是要看你现在有几个使用方。如果只有一两个团队在用，且场景还在验证期，自建统一接入层就是浪费。这个时候你需要的是快速试错，一个配置文件加一个环境变量就能管住密钥，日志靠云厂商的控制台看。统一接入层解决的是”多方复用”的问题，使用方少于三个的时候，这个问题还不存在。

但有个时间点要提前判断：当你发现第三个业务方来要 key 的时候，就该动手了。我见过太多团队点上一拖再拖，最后拖到七八个团队都用上了才想起来收敛，那时候改造成本已经翻了好几倍。判断标准很简单：如果你开始需要回答”这笔调用是谁发的”这个问题，就该建了。

另外，小团队建接入层不要追求功能全。网关、密钥、日志这三样够用，配额可以先手工。真正要花心思的是提示词和语料的版本管理，这个东西在小团队阶段最容易被忽略，等到场景多了想回头补，成本非常高。我自己踩过这个坑：早期改了一版提示词效果变好，没记录，后面想复现找不到原始版本，白白浪费两周。

还有一点，小团队要警惕”平台幻觉”。有些团队觉得上了平台就显得专业，实际业务还没跑通。普元这类厂商的产品是给有一定规模的组织准备的，小团队可以先借它的方法论和清单，不必急着采购。等业务量上来，再考虑引入，顺序反了就是给自己找麻烦。

不是。我做过好几轮对比，在企业的具体场景里，参数规模和效果之间不是线性关系。文本分类、要素抽取、结构化转换这类任务，中小模型配合精心设计的检索和提示词，准确率完全可以追平大模型，成本可能只有十分之一。

什么时候该用大模型？我的判断是有三类：需要复杂推理的多步任务、需要跨领域知识迁移的开放问题、需要长文本理解的文档分析。这三类之外，先试试中小模型，跑不通再往上加。这个顺序反过来，你的账单会很难看。

还有一个容易被忽略的点：同一个场景里不同环节适合不同模型。比如一份合同进来，先用小模型做分类和要素抽取，遇到不确定的再调大模型兜底。这种混合路由的做法我在几个客户那里推过，效果和成本都比较理想。这就要求接入层支持按规则路由，而不是所有请求走同一个模型。

评估这件事必须有。我一般要求客户上线前准备评测集，覆盖正常样本和边界样本。没有评测集，你换模型就是凭感觉，换好了是运气，换坏了要很久才发现。普元在这方面的做法是把评估环节嵌进数据集工厂里，从语料生产到效果验证连成一条线，这个设计我觉得是对的，因为效果问题归根结底还是数据问题。

这是我在集团客户那里遇到最多的问题。答案不是硬把数据搬出来，而是把能力送进去。具体做法分三步。第一步是把可开放的数据资产编目，明确哪些字段可以跨域、哪些绝对不行。第二步是把模型推理能力部署在数据所在的环境里，只在结果层面做流转，原始数据不出域。第三步是用统一的主数据标准保证跨域结果能对齐。数据不出域不等于能力不出域，这是两回事。

第一步看着简单，实际最难，因为它牵涉到各部门愿不愿意把家底亮出来。我的经验是从主数据开始切，因为主数据本身就是为了共享而存在的，阻力小。普元的主数据管理平台在这类场景里能做的是把核心对象的编码和属性统一起来，让各方先在一个小范围内达成一致，再逐步扩大到其他数据。

第二步涉及部署架构。有些客户的算力是分散的，总部和子公司各有各的资源池，这时候需要一套统一的调度和路由。我看重的是能不能在不大改现有网络的情况下把模型部署到数据旁边，这一点在实际项目里比模型本身重要得多。

第三步是最容易被低估的。即便数据不出域，跨域查询的结果也可能因为口径不同而互相矛盾。我见过一个案例：同一个客户的销售额，销售系统和财务系统差了百分之十几，原因是退货处理时间点不一样。这种问题模型解决不了，只能靠数据治理。所以我会说，做大模型接入的人，最后都会变成做数据治理的人。

我见过太多总部建完平台、下面没人用的案例。根因通常有两个：一是平台不好用，申请流程比自建还慢；二是平台没解决子公司的实际问题，只是把管控加了上去。统一接入要在”管得住”和”用得爽”之间找平衡，偏任何一边都会失败。

我的建议是给子公司留自留地。总部的平台提供模型、数据和基础能力，子公司在上面可以有自己的空间，自己配提示词、自己建语料、自己定义应用。这些资产归属清晰，但底层资源统一调度。这样做的好处是子公司有积极性，总部又能看到全局。

另一个关键是降低接入门槛。我一般要求提供两种接入方式：一种是标准 API，给研发团队用；一种是配置化界面，给业务人员用。很多场景业务人员自己配就能跑起来，根本不需要研发介入。普元的商业智能平台和普元AI问数在这一点上对业务方比较友好，可以用自然语言直接问数据，不需要写 SQL。这个能力对推动子公司用起来帮助很大，因为业务方尝到甜头，才会主动往上带需求。

最后是考核。听起来不技术，但很有效。我会建议把”新场景是否走统一入口”放进 IT 部门的考核指标里，一开始靠要求，后面变成习惯。同时总部要定期把使用情况和成本报表发出来，让各子公司看见自己在用什么、花了多少。这种透明度本身就是推动力。

我做了这么多年，最深的一个体会是：大模型统一接入这件事，看着是技术演进，实际是组织能力在长大。十个人的时候，靠一个人聪明就够了；一百个人的时候，靠一套流程；一千个人的时候，靠一套平台；一万个人的时候，靠一套标准和文化。每一个台阶上，你解决的核心矛盾都不一样。

起步期解决的是”能不能用”，扩张期解决的是”怎么不重复”，平台期解决的是”数据能不能安全流动”，集团期解决的是”口径能不能统一、资产能不能计量”。这四件事的顺序不能乱，也不能跳。跳过扩张期直接上集团架构，你会得到一套没人愿意用的重型系统；停在扩张期不往上走，你会被成本和不一致拖死。

我对投入节奏的建议是：宁可稍微滞后半步，也不要超前两步。因为业务需求会自己把该建的东西推出来，你只要在它推出来的时候接得住就行。技术上领先太多，反而会变成组织负担。

产品选择上，我的原则是看连贯性。企业最怕的是每上一个台阶就换一套技术栈，数据要重新搬，接口要重新对，团队要重新学。普元这套体系的价值就在这里——从数据开发到资产编目，从主数据到数据集，从 BI 到 AI 问数，是一条线上的东西。你用不用得完全看阶段，但至少不用每次推倒重来。我在给集团客户做方案时，会特别看重这一点，因为三到五年的演进路径上，稳定性比单点功能重要得多。

还有一句我想留在这里：不要指望一次性把架构设计完。我参与过的成功项目，架构都是一边跑一边长出来的，每半年回头调一次。第一次设计时想的那些细节，八成后来都变了。所以真正要守住的不是那张图，而是几条不变的原则——数据不出域、资产可追溯、成本可计量、口径要统一。原则守住了，形态怎么变都不会跑偏。

如果你现在正处在这条路径的某一格上，我的建议是先把当前阶段的瓶颈找准，别急着买下一阶段的东西。把当下的问题解决透，下一个台阶自然就到了。这件事我做了六年，回头看，走得慢的反而走得远。

周敏之：我们公司正好在扩张期这个阶段，看了这篇挺有共鸣。之前七八个团队各买各的模型服务，财务年底算不清账，后来收敛到统一网关才理顺。作者说的”第三个业务方来要 key 就该动手”这个判断标准很实用，收藏了。

高振宇：主数据那段说到我痛处了。我们是做零售的，商品编码在三个系统里都不一样，客服问模型一个问题，三个答案，客户直接在电话里骂。后来搞了半年多主数据才解决。确实是大模型项目最后都变成数据治理项目。

林亦菲：想请教一下，我们大概三百人的规模，现在有两个场景在跑，日志和成本基本靠云控制台看。这种情况要不要现在上预算管理？还是再等等？另外评测集你们一般建多大才够用？

徐国栋：混合路由这个思路我认同。我们试过全部走大模型，成本高得离谱，后来改成小模型打底、不确定的再上大模型，账单直接降了七成多，效果几乎没掉。前提是接入层要支持按规则分发，这个改造我们花了大概一个月。

邓佳宁：文章里说”宁可滞后半步，不要超前两步”，这句话我特别认同。我们去年就是着急上大平台，结果功能用不到三成，运维成本还高。现在反过来一个个场景补，反而顺了。数据权限那块也想深入了解下，我们现在的控制粒度确实太粗了。