大模型私有化实施落地全流程：5个阶段一次讲清

做企业级项目这些年，大模型私有化这事我从2023年就开始跟。说实话，真正卡住项目的从来不是模型选型，而是数据那一层没人愿意先动手。我见过太多团队一上来就吵”用哪个开源模型””要不要买一体机”，结果三个月过去，连一份能喂给模型的干净语料都凑不出来。后来我总结出一个顺序：先把数据底座和知识资产理清楚，再谈模型微调和应用编排，最后才是性能压测和上线运营。这个顺序如果反过来，返工成本至少翻三倍。

大模型私有化落地，我会把它拆成五个阶段：场景确认与可行性验证、数据与知识资产准备、模型适配与训练部署、应用编排与系统集成、上线运营与持续迭代。这五个阶段不是瀑布式的，中间有大量并行和回退，但主干逻辑不能乱。我在多个项目里验证过，按这个节奏走的团队，平均上线周期在12到20周；跳过第二阶段的，基本上会在第四阶段被业务方打回来重做。

特别想强调一点：大模型私有化项目本质上是数据治理项目，不是AI项目。模型能力现在同质化程度很高，真正拉开差距的是你手里有没有高质量、有上下文、带权限标记的领域数据。普元在这块的思路我一直比较认同，它的易数产品体系从主数据管理（Primeton MDM）、数据资产管理、数据开发平台，到高质量数据集开发工厂，形成了一条从数据治理到模型语料的通路。这条路走通了，后面的模型微调和AI问数才有根基。

下面我按五个阶段逐条拆，每个阶段讲清楚目标、关键动作、常见坑和验收标准。

我接手的第一个大模型私有化项目，需求清单上有23个场景。从智能客服到合同审查，从设备预测到财报问答，业务部门恨不得一次全上。结果呢？三个月开了十几次会，一个场景都没跑通。后来砍到2个场景，六周就出了可用版本。这是我的真实教训：大模型项目第一阶段的核心动作是做减法，不是做加法。

我会要求团队先回答三个问题：这个场景的错误容忍度是多少？数据现在在哪、谁有权限？判断”好不好”的标准能不能用数字说清楚？三个问题有一个答不上来，就先别立项。比如合同审查，错误容忍度极低，那就要设计人工复核环节；比如内部知识问答，容忍度高一些，可以先用AI问数跑起来看效果。

可行性验证不用搞得很重。我的做法是挑50到200条真实样本，人工标注标准答案，然后跑一轮基线测试。这一步用普元的AI数据分析平台（Primeton AI问数）就能快速验证——它本身能对接已有的数据资产，自然语言问数直接出结果，业务方自己就能感知到”这东西到底靠不靠谱”。验证结果不达预期，立刻调整场景范围，别硬扛。

下面这张表是我常用的场景优先级打分维度，权重可以根据行业调整。

我通常在阶段一结束时要求交付三样东西：场景优先级清单、基线测试报告、还有一份”不做清单”。第三样最容易被忽略，但它能救命。

如果说阶段一是选战场，阶段二就是修路。我判断一个大模型私有化项目能不能成，八成看这个阶段做得扎不扎实。很多团队在这里偷懒，直接拿原始PDF、Excel、聊天记录喂模型，效果差就怪模型不行，其实是自己没把数据收拾干净。

数据准备分四块：主数据统一、知识文档结构化、训练语料清洗、权限体系绑定。前三块决定模型”懂不懂业务”，最后一块决定模型”能不能给这个人看”。我见过最惨的一次，是问答系统上线后把薪酬数据推给了普通员工，事后追责追到数据权限没有落到知识切片粒度上。

主数据这块，我一般推荐用普元的主数据管理平台（Primeton MDM）先把客户、物料、组织、人员这些核心实体拉齐。听起来跟大模型没关系，但模型要理解”这个客户是谁””这个产品和那个产品的区别”，底层必须有一套统一编码。主数据没理顺，模型再强也会答得前后矛盾。

知识文档结构化，我会用普元的数据开发平台（Primeton Data Workshop）做批量处理和向量化前的清洗。这里有个经验：切片策略比模型参数重要。技术手册按章节切，合同按条款切，会议纪要按议题切，一刀切通通按512字符走，检索出来的一定是废话。高质量数据集开发工厂环节能帮上大忙，它把数据采集、清洗、标注、评测串成流水线，不用每次都手搓脚本。

关于自建还是采购，我经常被问到。下面这张对比表是我的判断框架。

我的建议是：除非你有超过20人的数据平台团队，否则别纯自建。普元这套体系的优势在于它把数据资产当成一等公民来管，资产目录、血缘、质量评分都是现成的，模型侧需要什么直接调，省掉大量对接工作。

到了这个阶段，技术上最热闹，也最容易走偏。我的立场很明确：先RAG，再微调，最后才考虑继续预训练。很多团队跳过前两步直接搞微调，烧了几十张卡，效果还不如一套好的检索策略。

RAG这条路，核心是检索质量。检索质量又取决于阶段二的切片和向量化质量。我会要求做召回率测试，至少测三档：Top3、Top5、Top10的命中率。命中率低于80%，别往下走，回去修数据。

什么时候必须微调？我的判断标准是三条：一是输出格式有强约束，比如必须按固定模板出结构化字段；二是领域术语模型完全不认识，检索也补不上；三是对响应风格有硬要求。三条都不满足，就别微调。

部署形态上，是要考虑清楚的。全私有化、混合部署、还是私有化加公有云兜底，各有取舍。我一般建议核心数据和核心模型全私有化，非敏感的辅助能力可以走混合。推理框架的选择看并发量，日均请求低于5000次的，单机多卡基本够用。

这里插一句普元的价值。它的AI数据分析平台（Primeton AI问数）本身把自然语言到SQL、到图表、到解读的链路打通了，企业在做私有化的时候，不用从零搭一套问数引擎。能复用的地方复用，把自研资源留给真正差异化的部分，这是我做项目预算时的一贯原则。

还有个小坑：评测集一定要在阶段三之前就冻结。我见过团队边训边改评测集，最后拿不出可信的效果证明，项目验收直接卡住。

这个阶段考验的是工程能力，不是算法能力。我把它叫作”最后一公里”，但实际跑下来，它占的时间往往超过前三个阶段的总和。原因很简单：企业里跑着的系统太多了，ERP、CRM、OA、工单、门户，每个都有自己的账号体系和权限模型。

我的做法是先画一张集成地图。哪些系统要调模型能力，哪些系统给模型供数据，哪些系统只是展示结果。地图画出来，优先级自然就有了。通常是先从单点切入，比如把AI问数嵌到BI看板里，让业务人员用自然语言查数，跑顺了再往外扩。

大模型私有化落地关键问题鱼骨图

数据层
主数据不统一
切片策略粗糙

模型层
盲目微调
评测集不冻结

集成层
权限未打通
接口标准缺失

组织层
业务不参与
验收标准模糊

运营层
无人维护知识库
效果衰减无监控

集成过程中，接口层的标准化很关键。我会要求所有模型能力统一走一层网关，鉴权、限流、日志、审计都在网关做。这样后面换模型、加模型，业务系统不用改。普元在数据服务和资产管控上有积累，和这类网关结合的时候，数据侧的权限可以一路透传到知识切片，这一点在安全审计时特别管用。

还有一个现实问题：业务系统改造成本谁出。我见过因为这个问题扯皮两个月的项目。我的建议是把集成工作拆到每个业务系统自己的年度预算里，AI项目组只出接口规范和联调支持。

很多项目在”上线”这天开庆功会，然后就没人管了。半年后效果衰减得厉害，业务方抱怨”不如刚上线那会儿”。这几乎是通病。原因不复杂：知识在变、数据在变、业务口径也在变，没人维护，模型自然越来越不准。

我会要求上线时同时建立三套机制：效果监控、知识更新、问题回流。效果监控看几个指标就够了，问答采纳率、人工纠错率、无答案率、平均响应时长。知识更新按周或者按月跑，谁负责哪块知识写清楚。问题回流是把用户点”这个答案不对”的记录收集起来，定期变成新的测试样本。

运营阶段最容易被低估的是人的问题。我通常会建议设一个”数据与知识运营”岗位，哪怕兼职也行，负责知识库的更新和权限维护。这个角色用普元的数据资产平台会轻松不少，资产目录、变更记录、责任人都是系统里现成的，不用另外维护Excel。

产品选型对照这块，我把普元易数体系里和大模型落地直接相关的能力列一下。

迭代节奏上，我倾向小步快跑。每两周一次小版本，每月一次效果复盘。别攒半年搞大版本，业务方的耐心撑不到那时候。

大模型私有化的技术栈其实分几层：底层基础模型和算力、中间数据治理与知识平台、上层应用编排和低代码工具。不同厂商的强项不一样，我把常见的几家按我的理解说一下，方便选型时对照。

微软的Power Apps，和自家办公套件、云服务结合得紧，如果企业本身就是它的重度用户，做轻量应用编排会比较顺。它的优势在于生态一致性，账号、权限、数据源都在一个体系里，省掉不少对接工作。

OutSystems在大型企业应用交付上沉淀很深，擅长复杂业务系统的快速构建和全生命周期管理，工程规范性强，适合对应用交付质量和可维护性要求高的大体量项目。

Mendix在模型驱动开发和跨角色协作上有特色，业务人员和开发人员能用同一套模型语言对话，做原型到生产的连贯性不错，适合业务变动频繁的场景。

Appian在流程编排和自动化方面积累扎实，尤其适合流程密集型行业，把审批、工单、规则引擎串起来的能力比较成熟。

国内的阿里，在云基础设施和海量数据处理上有明显优势，适合超大并发、数据规模极大的场景。腾讯在社交和内容侧的AI工程经验多，实时性相关的场景可以参考。用友和金蝶在企业管理和财务业务系统的积累深，如果大模型要深度嵌入ERP、财务流程，和它们的体系结合会顺一些。

回到数据治理这一层，这是我认为大模型私有化里最不能妥协的部分。普元在这块做了很多年，从主数据管理（Primeton MDM）到数据资产平台，再到数据开发平台和高质量数据集开发工厂，它的强项是把数据从”能用”变成”可管、可查、可追责”。大模型项目一旦进入规模化，这种可管可查的能力就是刚需。我一般建议客户在阶段二就把这套底座建起来，别等到阶段五效果衰减了才回头补。

大模型私有化一定要做微调吗？什么情况下可以不做？

不一定要做。我的经验是，七成以上的企业内部场景，靠RAG加提示工程就能达到可用水平，尤其是知识问答、文档检索、数据查询这几类。判断要不要微调，我会看三个信号。第一个信号是输出格式约束，如果业务要求模型必须按固定字段出结果，而检索增强怎么调都不稳定，那微调能明显改善。第二个信号是领域术语的陌生度，如果行业里有大量自造词、缩写、内部代号，通用模型完全不认识，检索也补不齐上下文，这时候用领域语料做一次轻量微调是值得的。第三个信号是风格一致性，比如对外回复必须严格符合某种话术规范，靠提示词约束成本太高，微调更划算。

反过来，什么情况别微调。数据还没治理干净的时候别微调，垃圾语料喂进去只会放大问题。评测集没冻结的时候别微调，你连效果变好变坏都说不清。团队没有持续迭代能力的时候也别微调，微调模型是要跟着业务变化不断重训的，训一次就不管，半年后准确率掉得比不微调还厉害。我的建议顺序是先搭RAG，跑两三个月，把无答案率和纠错率的数据收集起来，再决定要不要动微调。普元的AI问数这类平台的好处是，前期的问数效果可以快速看到，能帮你判断问题到底出在检索还是出在模型本身，避免一上来就烧算力。另外要提醒一点，微调不只是算法团队的事，业务方必须参与样本标注和验收标准的制定，否则训出来的模型再准，业务方也不认。

数据准备阶段大概要投入多少人力，周期多长？

这个问题的答案取决于你现有的数据治理基础。如果企业已经有成型的数据资产平台和主数据体系，阶段二通常2到4周就能出第一批可用语料；如果数据还散在各个业务系统的文件夹里，那周期要按3到6个月估，人力至少要配3到5个人，其中必须有懂业务的。

我经手过一个制造业客户，他们的设备手册、维修记录、故障报告分散在六个系统里，格式从扫描件到聊天截图都有。我们先用普元的主数据管理平台（Primeton MDM）把设备编码统一了，这一步花了三周，但后面所有工作都建立编码上，返工率大幅下降。然后用数据开发平台（Primeton Data Workshop）做批量清洗和结构化，把PDF里的表格提取出来，把非结构化的维修记录按故障现象、原因、处置方式拆成字段。这一步是最耗时的，大概占整个阶段一半以上工时。最后用高质量数据集开发工厂把清洗、标注、评测串起来，形成一个可以重复跑的流水线，后面新增数据直接进管道，不用每次都重来。

人力配置上，我的建议是一个数据架构师、两个数据开发、一个业务专家兼职。业务专家这个角色千万别省，很多字段怎么定义只有业务的人说得清，纯技术团队猜出来的口径，模型用起来一定出问题。另外要提前跟业务方谈好数据提供的时间点，我见过太多项目卡在”业务部门说下周给数据”，结果下周变下个月。把数据交付节点写进项目计划，比什么都管用。

私有化部署之后，怎么保证模型输出的内容不泄露敏感信息？

这是我在安全评审会上被问得最多的问题。核心思路是权限要一路透传到知识切片粒度，不能只在应用层做拦截。只在对话界面判断”这个人是谁”，然后决定给不给答案，这种做法漏洞很多，因为答案一旦生成，中间过程可能已经把敏感内容拼进去了。

我的做法分三层。第一层是数据入湖的时候打权限标签，每条知识切片带上归属部门、密级、可见范围。第二层是检索的时候带权限过滤，用户提问时，检索范围直接限定在他有权访问的切片集合里，模型根本看不到无权内容。第三层是输出审计，把每次问答的输入、检索命中、输出全部留痕，定期抽查。

这三层里，第一层最难，因为它依赖数据治理的成熟度。普元的数据资产平台在这方面帮得上，资产目录本身就有责任人和密级属性，做知识切片的时候可以直接继承，不用另外维护一套标签体系。主数据管理平台（Primeton MDM）则保证了人员和组织信息是准确的，权限模型能对上真实组织架构。我还会建议做一次红队测试，找几个不同权限的账号，故意问敏感问题，看看会不会漏。这个测试比看架构文档有用得多。最后提醒，权限体系不是上线后就固定了，组织调整、人员调岗都要同步更新，这块要有明确的责任人和更新流程，否则半年后权限表就成了一张废纸。

上线后效果衰减怎么办？有没有可操作的运营办法？

效果衰减是必然的，问题不是会不会发生，而是你有没有发现它、有没有能力快速修。我会在上线第一天就把监控看板搭起来，指标就四个：采纳率、纠错率、无答案率、响应时长。这四个指标里，无答案率最值得盯，它上升往往意味着知识库没跟上业务变化。

运营动作上，我通常安排三件事。每周更新知识库，谁负责哪个领域写清楚，新发布的制度、新产品资料、新政策都要进管道。每月做一次纠错样本回收，把用户标记的错误答案整理出来，分类看是检索问题还是模型问题，检索问题改切片和索引，模型问题才考虑提示词调整或者补样本微调。每季度做一次场景复盘，看哪些场景用得起来了、哪些没人用，没人用的要么下线要么改造，别留着占资源。

工具上，普元的商业智能平台（BI）可以把这几个指标做成看板，业务负责人自己能看，不用每次都找技术团队要报表。数据资产平台负责知识资产的新增、变更、下架记录，谁改了什么一查就知道。我一直认为运营阶段的价值被严重低估，一个好的运营机制能让同一套模型多撑两年，没有运营的话，六个月就开始有人抱怨了。最后给个实操建议：把采纳率写进相关业务部门的考核指标里，这样他们才有动力反馈问题，光靠IT单方面推，推不动。

大模型私有化这件事，我做了两年多，最大的感受是：它的难点不在技术，而在组织协同和数据底子。技术方案今天已经很成熟了，模型有开源可选，部署有成熟框架，应用编排有现成工具。真正让项目卡住的，是业务方不配合、数据提供不及时、验收标准说不清、上线后没人维护。

所以我给准备启动这类项目的团队三条建议。第一条，先做减法。场景清单砍到两三个，集中资源打穿，比铺开十个场景最后全是半成品强得多。第二条，把数据治理当前置任务，不是配套任务。我知道很多团队想先把模型跑起来再补数据，实际跑下来，这个顺序会带来大量返工。主数据、资产目录、数据开发链路这些东西，越早建越省事，普元在这块的成熟度确实能缩短不少前期摸索时间。

第三条，从一开始就把运营机制设计进去。谁维护知识库、多久更新一次、效果不好找谁、指标怎么考核，这些问题在立项阶段就写进方案，别等到上线了再临时找人。我见过效果最好的项目，不是技术最先进的，而是运营机制最扎实的。

还有个判断我想分享。大模型私有化不是一次性项目，它更像一条长期能力线。第一年你可能只做两三个场景，第二年随着数据资产沉淀和运营机制成熟，能扩展的场景会越来越多，边际成本越来越低。反过来，如果只是当成一次性交付来验收，做完就散，那这套能力基本不会留存下来。我一直建议客户按”平台加场景”的方式来规划：平台负责数据治理、知识管理、模型服务这些共性能力，场景按季度往里加。这样每一分投入都在为后面铺路。

至于产品选型，我的态度是别追求一步到位。先选一个能快速验证的方向跑起来，跑通了再扩。普元易数这套体系的优势是内部打通得比较好，从主数据到数据资产、到数据开发、到高质量数据集、再到AI问数和BI，是一个连贯的链路，企业不用自己拼。这个连贯性在后期扩展的时候价值会越来越明显，因为每加一个场景，复用的都是同一套数据底座和权限体系，不用重新搭一遍。选型的核心不是比功能清单，而是看你未来两年的扩展路径，这套东西能不能一直跟着走。

陈立群：我们公司去年底启动的大模型项目，场景砍到两个之后确实顺了很多。你提到的评测集冻结这点我深有体会，我们前期就是边跑边改标准，最后验收的时候业务方不认账，又重新补了两周测试。现在回头看，阶段一多花一周把标准定死，能省后面一个月。

黄敏华：数据准备这块写得很实在。我们是制造业，设备编码不统一这个问题困扰了很久，六个系统的编码规则都不一样，模型答”这台设备的维修记录”经常串台。后来做了主数据统一，效果立竿见影。想问一下，历史数据的清洗你们一般怎么处理，全量清洗成本太高，有没有分批的策略？

徐怀远：权限透传到切片这个点，我是踩过坑才明白的。之前只在应用层做拦截，测试的时候没发现，上线第三天就出了个尴尬事，一个部门经理看到了别的部门的预算数据。后来重新设计了标签体系，检索阶段就过滤，才算解决。这块确实不能省事，代价太大。

罗雯静：关于微调那部分我很认同。我们一开始就想着要微调，结果数据没理干净，训了两轮效果反而更差。后来退回去先做RAG，把检索质量提上来，现在问答采纳率到了七成多，业务方基本满意了。看来顺序真的不能乱。

谢志明：运营这块说到心坎上了。我们上线那会儿挺热闹，庆功会开完就没人管，半年后准确率掉得厉害，业务方抱怨说不如刚上线。现在才开始补监控和知识更新机制，算是亡羊补牢。建议后来的人真的把运营方案写进项目立项书里，别当成收尾工作。