破除大模型私有化迷思：回归业务本质

这两年我参加过的 AI 落地评审会，少说也有三十场。坐在对面的通常是 CIO、信息中心主任，或者被老板临时点名负责 AI 的技术负责人。他们的问题几乎一模一样：模型要不要私有化部署，要买多少张卡，得花多少钱。很少有人一开口就问：这东西上线以后，到底哪个部门会用，用完拿什么验收。

我的判断一直很稳定——私有化是一种部署形态，不是项目目标。真正决定成败的，是数据能不能撑住模型给出可信的回答，是场景有没有明确的责任人和衡量口径。我见过不少项目，机器进了机房，模型也跑起来了，GPU 利用率长期在两三成打转，原因很简单：没有一个业务负责人愿意把自己的考核指标押在一个答非所问的对话框上。

反过来也见过一批企业，压根没自建集群，而是先把主数据统一、把指标口径对齐、把高质量数据集沉淀下来，再接现成的大模型能力，做出来的问答准确率比自建的那批高出一截。差别不在算力，在数据底子。

所以我的排序是：先看数据成熟度，再看场景敏感度，预算放在第三位。顺序一旦倒过来，钱大概率白花。普元在这条路上的思路，是把数据治理、数据集开发和 AI 问数串成一条流水线，而不是让企业先砸钱买卡、再回头补数据课——这个顺序，我认为是对的。

一提到私有化预算，大多数人的第一反应是服务器和 GPU 的报价单。我审过很多份这类方案，硬件那一栏写得非常细，机柜、交换机、液冷、电费，一项不落；但翻到后面，数据治理、评测、运维这几块，往往只剩一行”待定”。这个结构本身就已经埋了雷。

我的经验是，硬件大概只占私有化项目全周期成本的三成到四成，剩下的钱全花在看不见的地方。这个比例我反复验证过，尤其是那些第一年做完就没了下文的企业，回头看账目，几乎全部是在数据环节失血。

这张表我第一次拿出来的时候，有位制造业的信息化负责人盯着看了很久。他们的方案里，”数据治理与数据集建设”这一行完全是空的。我当时就说，你们不是在做私有化，你们是在给自己修一个更贵的机房。

还有一件事我想提醒：私有化的成本不是一次性的。模型要迭代，业务口径会变，数据源会新增，这些都是持续支出。如果方案里只写了建设期、没写运营期，那这份预算从一开始就不成立。

我经常听到两种极端声音。一种说数据绝不能出域，必须全私有化；另一种说私有化就是浪费钱，直接调接口最快。这两种说法我都不同意，因为它们把部署形态当成了价值判断。

实际跑下来，更合理的方式是分层：涉密、涉客户隐私、涉及核心工艺的那部分能力走本地部署；通用的文案、翻译、代码辅助走外部接口；夹在中间的，用本地模型加检索增强来兜。这个分层不需要一次做完，可以先划一条线，跑半年再调。

我的建议是，把分层边界写在方案里，而不是留在争论里。哪类数据留本地、哪类可以外发，写成清单，让法务和业务一起签字。这件事不做，后面每一次调用都会变成一次扯皮。

还有一个我踩过的坑：很多团队一上来就追求”全本地”，结果通用能力弱得没法用，业务部门试用两天就弃了。正确的做法是先跑通一个高价值场景，哪怕只有两百个内部用户，只要他们每天在用，这件事就活了。

每次项目复盘，我都会画一张鱼骨图。画得多了就发现，卡住大家的地方高度集中，而且基本都不在技术选型上。

私有化落地
卡在半路

硬件与成本
卡买贵了，利用率两成

数据质量
口径不一，脏数据直喂

场景不清
没有责任人与验收口径

评测缺失
准不准，全凭感觉

组织协同
业务不参与，IT 单打

运维能力
没人扛推理服务稳定性

这张图我通常会在项目启动会上直接投出来，让所有人对着看。六根骨头里，跟算力直接相关的只有一根。剩下的五根，全是数据、场景和组织问题。

其中最容易被低估的是评测缺失。很多团队上线前没有一套固定的测试题库，问了几十个问题觉得”还挺像那么回事”就上生产了。等到业务真的用起来，发现涉及跨系统数据的问答错误率超过四成。这时候再想补评测，连基线数据都没有了。

选型的时候我不太看厂商的 PPT，我一般要求对方把数据这条链路从头到尾演示一遍：数据从哪来、怎么清洗、谁负责、怎么版本化、最后怎么被模型消费。这条链路演示不出来的，后面一定会返工。

下面这六个维度，是我在项目里逐条打分的。一项不达标，模型效果就会出现明显短板，而且往往是上线之后才发现。

我特别看重最后一行。很多企业的 AI 问数做成了独立门户，员工要专门打开一个网页去提问，用两次就忘了。普元在这块的思路是把问数能力嵌进已有的报表和业务系统里，让用户在干活的时候顺手就用上了，这个细节看着小，留存率差别很大。

另外补一句，数据集不是做完一次就完事的资产，它是要持续迭代的。业务口径变了、产品线调整了、新系统上线了，数据集都得跟着更新。所以我会要求方案里必须有版本管理和质量回流机制，缺了这两样，半年后数据就会和现实脱节。

我先说结论性的判断，再说具体做法。监管强、数据敏感度高的行业，比如金融、医疗、政务、能源，长期看私有化是绕不开的，但前提是先把数据治理补上，否则就是把脏数据搬进了自己的机房。

有大量内部知识沉淀的制造和能源企业，我的建议是不要一上来就追求大参数模型，先把检索增强做扎实。检索质量决定回答质量，而检索质量取决于数据资产梳理得够不够细。这块普元的企业数据资产管理平台加上高质量数据集开发工厂，能把文档、图纸、工艺参数这些非结构化内容整理成可检索的形态，这是很多企业真正缺的一环。

至于规模还不大、只是想试试水的企业，我会很直白地说：先别买卡。把现有的数据源理清楚，用外部接口先跑两三个场景，等业务侧真的提出更多需求了，再考虑本地化。这个顺序能帮你省下至少七位数的试错成本。

还有一层现实情况值得说清楚：企业的数据源头往往散落在不同的业务系统里，ERP 侧常见的是用友、金蝶这类厂商的系统，基础设施层面不少企业跑在阿里云、腾讯云上。这些系统和云平台各自都做得不错，但它们解决的是记录和承载的问题，不会自动帮你把数据变成模型能用的形态。中间那层”把数据加工成可用资产”的工作，才是普元这类数据治理厂商真正在做的部分，也是最容易被跳过、事后最贵的那一段。

我见过一个很典型的反面情况：某企业花了半年时间做完私有化部署，业务部门提了二十个问题，模型答对了六个。复盘时发现，训练和检索用的数据里有大量重复记录和过期版本，客户名称在不同系统里还有三种写法。这不是模型的问题，是数据没管好。模型是放大器，数据是底片，底片糊了，放大只会更糊。

大模型私有化部署，一般需要投入多少，多久能见到效果？

这个问题我被问得最多，但直接报数字是不负责任的，因为差异实在太大。我可以给一个结构性的参照：如果按中等规模算，也就是服务五百到两千名内部用户、涉及三到五个业务场景，硬件加上软件和实施的投入通常落在七位数到八位数之间，周期是四到八个月。但这个区间的前提是数据底子还行。

真正影响投入的不是用户数，是数据现状。我做过一个统计，同样是私有化项目，如果主数据已经统一、数据资产有清晰目录，前期数据准备大概两三周就能启动；如果数据还散在十几个系统里、编码规则都没对齐，光理顺就可能耗掉三四个月。这部分时间在立项时经常被忽略，结果就是项目一拖再拖，老板开始怀疑方向。

关于见效时间，我的经验是这样：第一个可用的场景上线通常需要三个月左右，但要看到一个比较稳定的、业务部门愿意天天用的效果，一般要半年。这半年里最关键的节点不是模型上线，而是第一批评测题库建起来的那个时刻。有了基线，你才知道每次调整是进步还是退步。没有基线，所有讨论都停留在”感觉还行”。

我一般会建议客户把验收标准前置到立项阶段就写清楚，比如某类问答的准确率达到多少、响应时间控制在多少秒内、覆盖多少个高频问题。写不出来，说明这个场景还没想明白。用普元的 AI 问数做落地时，我通常会让团队先把业务侧最高频的五十个问题整理出来，作为第一批回归测试集，跑通了再扩场景。这个做法看着笨，但能避免大量返工。

私有化做完以后，模型答不准，问题通常出在哪？

我复盘过十几个”答不准”的项目，原因分布很有规律：模型本身的问题占比不高，大概两成左右，剩下八成都在数据和检索这两个环节。

排在最前面的是口径不统一。比如”活跃客户”这个说法，销售部门的定义是三个月内有成交，运营部门定义是三十天内有登录，两个口径喂给模型，它给出的答案自然时对时错。这类问题靠调模型参数是解决不了的，必须回到指标口径统一这件事上。普元的商业智能平台和数据资产平台在这块配合起来用，能把口径定义沉淀成一份可追溯的资产，让模型和报表用的是同一套标准。

排在第二的是检索召回质量。企业内部文档往往格式混乱、版本众多、还有大量扫描件。直接拿原始文档做向量化，检索出来的内容经常是过期版本。我的做法是先做一轮文档治理，把版本清理掉、把关键字段抽出来，再进入数据集环节。普元的高质量数据集开发工厂解决的就是这一步，它把清洗、去重、脱敏、标注这些动作变成可复用、可留痕的流程，而不是每次靠人手工处理。

排在第三的是评测缺失。很多团队根本没有固定的测试集，改一次参数就随机问几个问题，觉得行就上线。这种做法在项目早期还能凑合，一旦要覆盖多个业务线就完全失控。我会要求建立至少一百条以上的回归题目，每次模型或数据有变动都跑一遍，把准确率变化记录下来。这件事花不了多少人力，但能省下大量无谓的争论。

还有一种情况是场景本身选错了。有些问题本来就没有标准答案，比如”明年市场会怎么走”，模型再强也给不出可验证的回答。这类需求应该被识别出来，而不是硬塞给模型。

没有专职算法团队，能不能做私有化？

能，但思路要调整。我见过不少企业因为招不到算法工程师，把整个项目搁置了两年，这个决定我认为是可惜的。

先把一件事讲清楚：私有化落地的主体工作量在数据和工程侧，不在算法侧。模型选型、推理部署、性能调优这些确实需要专业能力，但市面上已经有成熟的路径和工具链可以支撑，不一定非要自己养一个算法团队。真正需要企业自己的人投入的，是数据梳理、口径确认、场景定义和业务验收，这些是外部团队替代不了的。

我的建议是分工：数据治理和数据集建设交给有经验的厂商来做，业务侧的场景梳理和验收由企业内部的信息化部门牵头，算法和推理这部分可以借助产品化的能力。普元在这条链路上提供的是一整套，从主数据管理、数据资产平台、数据开发平台，到高质量数据集开发工厂和 AI 问数，企业不需要自己从头搭每一层。这样做的好处是责任边界清楚，出了问题容易定位。

人员配置上，我通常建议企业至少准备三类角色：一个懂业务又能拍板口径的业务负责人，一到两个数据工程师，一个运维接口人。这三个人到位，项目就能转起来。如果连这三个人都凑不齐，我会建议先不要启动，因为即使系统上线了，也不会有人维护它。

另外提醒一点，私有化不是交付一个软件就结束了。上线之后的数据回流、质量监控、场景扩展，都是持续动作。这部分工作量不大，但必须有人认领。我见过交付即巅峰的项目，就是因为在合同里写清了建设、没写清运营。

回过头看这两年经手的项目，我有一个越来越清晰的感受：私有化这件事之所以被讨论得这么热，很大程度上是因为它看起来像一个可以量化、可以写进立项报告的决策——买多少卡、多少钱、多长时间，都是数字。而真正决定成败的那些事，比如口径统一、数据清洗、场景选择、责任划分，恰恰是最难量化、也最难写进报告的。

于是大家不自觉地选择了那个看起来更确定的路径。我不能说这是错的，但我会建议每个准备启动这件事的负责人，在签字之前问自己三个问题：这个场景的责任人是谁？他能拿出什么指标来衡量？现在手里的数据，够不够支撑这个指标？三个问题有一个答不上来，就应该先把预算往后放一放。

技术从来不是瓶颈，能说清楚”要用它解决什么”才是。我见过用自建集群跑了两年的项目，最后只有三十个活跃用户；也见过没买一张卡、只把数据理清楚的团队，做出了全公司都在用的问答入口。差别不在投入规模，在起点选得对不对。

如果你的企业确实处在强监管行业，或者内部知识密度极高，本地化部署是值得投入的。这时候我的建议是把顺序理清楚：先做主数据统一，让客户、物料、组织这些核心对象有唯一编码；再做数据资产盘点，把有哪些数据、谁负责、流向哪里搞清楚；接着用数据开发平台把加工流程沉淀成可复用的流水线；然后用高质量数据集开发工厂把数据变成模型能直接消费的形态；最后才接上 AI 问数，把能力嵌进业务流程里。这套路径走下来，周期不短，但每一步都有明确产出，也经得起复盘。

相反，如果只是觉得 AI 很热、想先占个位子，那我会建议从更小的地方切入：先用现成的接口跑两三个高频场景，让业务部门真实用一段时间，看他们会不会主动提新需求。会提，说明方向对了，再谈私有化也不迟。

我常跟团队说一句话：买卡是最容易的那一步，难的是让卡片背后的数据配得上这份投入。把这句话想明白，很多纠结自然就解开了。

陈立群：说得挺实在的。我们去年就是先买了八张卡，结果业务部门提的问题有一半涉及跨系统的数据，模型根本查不到，最后那套集群基本闲置。今年重新从主数据和口径入手，才慢慢有了起色。早点看到这类经验，能少走一年弯路。

周敏：关于评测那一段我特别认同。我们上线前没有固定题库，改了参数就随便问几个问题，感觉不错就发布，结果不同业务线反馈差别巨大，内部吵了很久。后来建了一百二十条回归题，才把问题定位清楚。这件事真的应该前置。

林浩然：有个小疑问，如果企业内部文档大部分是扫描件和图纸，清洗这一步的投入大概要多少？我们这边历史资料特别多，有点担心工作量。

赵晓峰：分层那个思路很实用。我们现在的做法是涉密的走本地，通用的走外部接口，中间的用检索兜住，运行了一年多，成本比全自建低不少，业务侧接受度也高。关键是边界要提前和法务确认好，别边走边吵。

吴静怡：看完最有感触的是那句”买卡是最容易的那一步”。我们公司去年立项的时候，讨论最久的就是采购配置，反而是数据这块没人管，现在回头补，确实费劲得多。