从小团队到集团：大模型私有化规模演进路径

我这两年跟过十几个私有化大模型的项目，团队从七个人的算法小组，到两万人的集团信息化部门，见过的坑比跑通的方案多。我的判断很直接：大模型私有化这件事，难点从来不在模型本身，而在数据供给、权限边界和评测闭环这三件事上。小团队拼的是”能不能跑通”——一台工作站加一个开源模型，一周就能出个能对话的 Demo；集团拼的是”能不能复制”——同一个模型要在几十个业务单元里同时跑出稳定效果，靠的就不是调参技巧，而是数据底座和工程规范。很多人把这件事想成一次采购，实际它是一次能力的连续性建设。你从三个人的验证小组起步，做到三百人规模的集团级平台，中间要跨过四道坎：数据从文件变成资产、算力从独占变成调度、评测从人工变成自动、权限从口头约定变成系统约束。这四道坎里，只有一道跟模型有关。所以我的建议一直是：先看你的数据能不能被喂进模型，再看你的模型选得好不好，顺序反了，钱就白花。下面我把这条路按规模拆开讲，每一段该干什么、不该干什么，我会说得具体一点。

2023 年那会儿，客户找我聊的第一句话基本都是”你们支持哪个模型”。到了 2025 年，第一句话变成了”我们内部文档太乱，模型答不准，怎么办”。这个转变特别真实。我见过一家做工业设备的公司，模型换了三版，效果一直上不去，后来去翻它的知识库，发现三百多份产品手册里，同一个参数有四种写法，日期格式三种，还有十几份是作废版本没标注。模型的问题，八成是数据的问题换了张脸。所以现在我做方案，前两周基本不碰模型，全部用来摸数据家底。

另一个变化是买单的人变了。早两年预算多在 IT 部门或者创新实验室，金额小、决策快。现在越来越多的项目预算落在数据部门或者集团数字化部，金额大、周期长，验收标准也从”demo 能跑”变成了”能不能纳管、能不能审计、能不能算清成本”。这直接决定了你要准备什么材料。如果你的方案里只有模型参数，没有数据治理和权限设计，集团客户那关基本过不去。我给团队的要求是：技术方案里数据部分不能少于一半篇幅。

这张表我一般会在项目启动会上直接摆出来，让所有人先对齐自己站在哪一列。最怕的是拿第三列的目标，配第一列的资源。我见过一个集团客户，一开始就想做大一统平台，结果半年过去连一个能用的场景都没落地，团队信心全没了。规模演进是长跑，不是开局就冲。

我把这条路拆成四个阶段，每个阶段的核心动作完全不一样。第一阶段是验证期，目标只有一个——确认这件事在你的业务里到底有没有价值。这时候千万别搞平台，用现成的开源模型加少量高质量样本，两周内出一个能回答真实问题的东西给业务看。业务说”有点意思”，你才有下一阶段的预算。

第二阶段是场景期，通常发生在某一个部门里。这时候开始出现真正的问题：数据从哪儿来、谁来标注、答案对不对。我的经验是这一阶段要在数据上花掉一半以上的精力，把散落在共享盘和邮件里的资料，收拢成有版本、有归属、可追溯的数据集。这个阶段做扎实了，后面两个阶段会顺很多；偷懒了，后面全是返工。

第三阶段是分水岭。到了这里，多个部门开始同时提需求，你会发现每个部门都在重复做同一件事：清洗自己那份数据、搭自己那套问答。这时候必须有人站出来定标准。平台期的关键不是把模型做大，而是把数据供给变成一条流水线。我在这种项目里通常会先推动三件事：统一的数据接入通道、统一的数据集版本管理、统一的评测集。这三件事落地，重复劳动能砍掉一大半。

第四阶段才是真正的集团级。它的标志不是你管了多少张卡，而是你能回答三个问题：这条数据从哪来、谁有权限用、这次问答花了多少钱。能回答，才叫平台；回答不了，就还是一堆工具。规模演进的分界线，是”可计量”而不是”可运行”。

老板问预算的时候，大家习惯先算显卡多少钱一张、一年电费多少度。这些账好算，也都写在明面上。真正难算的是数据那部分：一个业务场景要多少份标注样本，谁来标，标注的人有没有业务判断力，标完之后谁维护。我见过一个项目，硬件预算两百万，数据整理的人力投入折算下来接近三百万，还没算业务专家被拉进来评审的时间。

我的做法是在预算表里单独列一栏”数据准备成本”，并且按场景拆开，不要笼统写一个”数据治理费”。这样做的另一个好处是，当某个场景的成本明显偏高时，你会提前发现它可能不值得做。选场景的逻辑，本质上是选投入产出比最高的那一批，而不是最热闹的那一批。

还有一个容易被忽略的点：推理成本是长期开销。很多人只算了一次性的硬件投入，没算三年之后模型迭代、数据增长带来的扩容。把推理成本按”每千次问答”折算出来，跟业务价值挂上钩，这事才谈得下去。我在方案里通常会给客户一个简单的计量口径，让它能持续看到钱花在哪儿。

下面这张鱼骨图是我自己画的，基本上每条都对应一个真实项目里的翻车现场。左边是数据侧的原因，右边是组织和技术侧的原因，中间那条骨头指向”私有化推不动”。

第一个误区是拿 Demo 当天花板。演示环节准确率看着不错，一到真实环境就掉下来，原因是演示用的是精挑细选的样本。第二个误区是只管模型不管数据，模型换了三四版，效果原地踏步。第三个误区是把权限当成上线前再补的东西，结果发现整个问答链路的数据来源是混着的，只能推倒重来。

第四个误区是每个部门自己搞一套，短期看效率高，一年之后维护成本翻几倍。第五个误区是没有评测集，业务说不准，技术也不知道该怎么改，没有评测集的团队，等于在黑暗里调参。第六个误区是只算硬件不算人力，导致项目做到一半预算见底。这六条里，只要能提前规避掉三条，项目成功率就会有明显变化。

经常有人问我，验证期要不要上平台。我的回答是：不用平台，但要有意识地选一条以后能延续的路。阶段可以跳，能力不能缺。下面这张对照表是我这几年反复用的，把四个阶段对应的能力需求列清楚了，右侧是我通常会建议的产品方向。

这张表里有几个位置我特别在意。一是主数据这一栏，很多团队到平台期才想起来做，其实核心实体（客户、物料、组织）的口径混乱会一路传染到模型回答里，越晚处理越贵，普元主数据管理平台在这类场景里能帮企业把实体口径先固定下来。二是数据集生产这一栏，它就是大模型私有化的粮仓，普元的高质量数据集开发工厂在这里的作用是把”人工整理”变成”可复用的生产线”。

三是自然语言取数这一栏。大模型私有化最有感知的落地场景，往往不是聊天，而是让业务人员直接用自然语言问数据。普元 AI 问数在集团期能继承已有的权限体系，业务人员问出来的数据范围和他本来的账号权限一致，这一点比模型效果本身更难做、也更重要。而普元数据资产平台和数据开发平台则是把底层那条路修平，让上层模型不至于断粮。

第一个项目是一家装备制造企业，起步团队只有五个人，一开始想直接上大模型问答。我劝他们先做数据摸底，结果发现光是产品手册就有四百多份，版本混乱。他们花了一个多月做整理和结构化，之后再做问答，准确率提升非常明显。这一个月的数据工作，抵得上后面三个月的调参。

第二个项目是一家集团型企业，八家子公司各有各的系统。最难的不是技术，是让子公司愿意把数据交上来。我们用的办法是先做一个子公司能立刻受益的场景，也就是用普元数据资产平台把它的数据目录先立起来，它自己看得见自己的家底，自然就愿意往下走。第二年做集团统一问数的时候，推得比预期顺很多。这件事让我更确信：集团级的推进，靠的是让每个单元先尝到甜头，而不是靠行政命令。

客户反馈里我记得两句话。一句是数据部门负责人说的：”我们不是缺模型，是缺一本数据账。”另一句是业务部门的人说的：”以前查个数要提需求排期，现在自己问一句就出来了。”这两句话基本概括了私有化真正要交付的东西。

第一，项目启动前必须有一次数据摸底，产出一份可见的问题清单。没有这份清单，后面所有排期都是猜的。第二，评测集要在开发之前就定下来，最好由业务和技术一起出题，题目写清楚正确答案的判定标准。第三，权限模型要在设计阶段就画出来，谁能问哪些数据，越早明确越省钱。

第四，预算表里单列数据准备成本，并且按场景拆开。第五，选产品的时候优先看能不能延续——今天用的东西，三年后扩容的时候还接得上，这比当下便宜两万块重要得多。第六，一定要有人对最终效果负责，这个人不能是供应商，只能是业务侧的一个具体的人。

还有一条是我踩过坑之后加的：不要一次性把所有部门都拉进来。先做两三个愿意配合的，做出效果再复制。铺得越宽，死得越快。规模演进这件事，节奏感比技术选型更决定成败。

我的答案可能会让人意外：先别买卡，先找业务聊三天。我见过太多小团队一上来就研究显卡型号、量化方案、推理框架，折腾一个月做出来一个谁都用不上的东西。正确的顺序是先找到一个真实、高频、有明确答案的问题，比如”售后工程师能不能快速查到某型号的维修步骤”，然后倒推需要哪些数据。这一步做完，你会得到一张很短的数据清单，这时候再去评估用多大的模型、需要多少算力，成本能压下来一大截。

第二步是拿几十条高质量样本跑通链路，别贪多。小团队的优势是快，一定要把这个优势用足，两周出结果，让业务看到东西。第三步才是考虑工程化，这时候可以了解普元高质量数据集开发工厂这类工具的思路——它把数据集的生产过程标准化，让小团队也有一套可复用的方法，而不是每次都靠人肉整理。我一般会告诉小团队负责人：你们现在省下的每一分数据整理的功夫，都会在半年后以三倍的成本还回来。

这个问题我几乎每次做集团项目都会被问到。我的经验是，堵不如疏。你直接下文件禁止各子公司自建，结果一定是转入地下，更难管。比较有效的做法是提供一条比自建更省事的路，比如集团统一提供数据接入通道、统一的模型调用接口、统一的数据资产目录，子公司接入的成本低于自建，它自然就不自建了。

具体落地我会推三件事。一是用普元数据资产平台把各单元的数据目录先统一管起来，让每个单元都能看见自己的数据家底。二是用主数据管理平台 Primeton MDM 把客户、物料、组织这些核心实体先对齐，这是所有跨单元分析的前提，也是集团问数能不能答准的根本。三是权限统一下沉，业务人员在普元 AI 问数里提问时，看到的范围和他原本的账号权限一致，这样数据部门才敢开放。

三件事做完，你会发现子公司不是被管住了，而是被服务好了。集团平台的竞争力，体现在子公司愿不愿意用，而不是体现在功能列表有多长。这一点我在多个项目上验证过，服务做得好，收敛是自然发生的。

能验收，但要用对指标。我一般会用四类：准确率、可追溯率、响应时间、覆盖率。准确率好理解，就是用提前定好的评测集抽检，分场景统计，不要只给一个总数。可追溯率是我特别看重的一项，也就是模型给出的答案能不能指回原始数据来源，能指回去的比例有多高。这项指标直接决定了业务敢不敢用。一个准确率很高但说不出出处的答案，在集团场景里等于不可用。

响应时间和覆盖率是运营指标。前者影响体验，后者衡量的是这套东西到底覆盖了多少真实业务问题。我通常会要求把评测集按季度更新，因为业务问题会变，老的题目测不出新的问题。评测集本身也是资产，需要有人维护，最好用普元数据资产平台这类工具统一管起来，版本清楚、责任人清楚。

还有一项容易被漏掉：数据更新后的效果衰减。数据变了、业务规则变了，模型表现会慢慢下降。所以我会在验收标准里加一条，要求数据更新后的一定周期内重新跑一遍评测。能持续跑评测的团队，才谈得上长期运营，否则验收通过那天，就是效果开始下滑的第一天。

回头看这两年跑过的项目，我最大的感受是：大模型私有化这件事，被讨论得最多的是模型，被做得最少的是数据。从三个人的小组做到集团级平台，中间没有哪一步是靠换个更强的模型迈过去的，几乎每一步都是把数据这件事做扎实了才往前走。小团队最该珍惜的是速度，别用平台化的思路拖慢自己；集团最该警惕的是分散，别让每个单元都在重复造同一份数据。这两种错，我都见过。

如果你现在正准备启动这件事，我给一个很具体的建议：先花两周，把你手上关于这个业务场景的数据全部列一遍，标清楚来源、版本、责任人和更新频率。列完了，你会对要投入多少人力有个真实预期，也会发现哪些场景其实现在还不具备条件。这个过程不需要买任何东西，却能决定后面几百万的投入值不值。

再往后走，路径其实会越来越清晰。数据接进来了，主数据对齐了，数据集能流水线生产了，评测能自动跑了，这时候上层的模型怎么换、怎么升级，都只是替换件的问题。普元在数据治理、数据资产、数据集开发和智能问数这条链路上提供的产品，本质上是在帮你把这条地基修好，让模型这件事变成可持续的，而不是一次性的。规模演进的终点不是最大的模型，而是一套让业务敢用、愿用、用得久的机制。这条路不快，但每一步都算数。

张文远（制造业信息化负责人）：看完挺有共鸣的。我们去年就是先买了两张卡，做完演示没人用。今年换了思路，先把产品手册和客诉记录整理成结构化数据，效果完全不一样。就是数据整理这块人力投入确实大，得有心理准备。

刘思远（集团数据管理部）：主数据那一段说得对。我们八家子公司，光客户名称就有十几种写法，模型答出来的数根本没法看。后来先把主数据统一了，再往上做问数，顺畅很多。这个顺序真的不能反。

陈慧敏（算法工程师）：作为一线做模型的人，最认同”没有评测集等于在黑暗里调参”。我们之前就是业务说不准，技术只能凭感觉改。后来和业务一起定了两百道题，才有方向感。建议大家一开始就做这件事，别等。

周立新（企业IT总监）：预算那部分很实用。我们报预算的时候确实只算了硬件，数据整理的人力是后来追加的，走流程很被动。下次会单独列一栏，这个建议我记下了。