行业特性决定方案：大模型私有化适配手册

这两年找我聊大模型私有化的企业不少，开场问题几乎一模一样——“我们该选哪个模型？”我每次都会把这个话题往回拽一拽。跑过的项目越多，我越确信一件事：模型在私有化项目里的权重，比我入行时预想的要小得多。真正决定项目成不成、上不上得去的，是行业特性——数据长什么样、合规红线在哪、内网是个什么环境、业务端对“对错”的判定标准是什么。

金融客户问的是“每句话能不能溯源到制度文件的第几条”，制造客户问的是“设备日志和工艺卡能不能一起喂进去”，政务客户问的是“能不能全程不出内网、能不能跑在信创服务器上”，能源客户问的更直接——“我们现场很多点位连外网都没有”。这四句话指向的方案骨架，根本不是同一套东西。

所以我不太相信“一套私有化大模型方案通吃全行业”这种说法。我通常会按行业先切一刀，再谈数据层、问答层、算力层怎么组。普元在这条链路上做的恰好是数据侧那些最容易被低估、又最影响最终问答质量的部分。行业特性决定方案，不是一句口号，它决定了预算怎么花、周期怎么排、谁该先动。

我习惯在项目启动会上先画一张表，把客户自己说不清的东西摆到明面上。行业不同，数据的“形态”和“脏法”完全是两码事。如果连数据形态都没对齐就开始选模型，后面八成要返工。

这张表看着简单，但我在现场见过太多团队跳过它。制造企业拿着一堆 PDF 工艺文件去做问答，效果还行，一接上设备时序数据就崩了——因为两边的指标定义压根对不上，问“三号线昨天的良率”能出来三个数。政务那边则相反，文档质量很高，但版本一多，模型引用的是三年前的旧政策，答复的权威性立刻就没了。

我的建议是，启动阶段就把这张表填满，越具体越好。数据形态决定预处理方式，约束条件决定部署架构，两者都清楚了，方案才有讨论余地。普元在数据治理这一侧积累的东西，恰好是在填这张表的时候用得上的——主数据、数据资产、数据开发这几块，本质上是把“数据说不清”这件事先解决掉。

聊完数据，我会再问一句：你们希望这个系统回答什么问题？是查制度、查数据、还是做分析？这三种诉求对应的路线完全不同，钱和时间也差着量级。我不建议客户一上来就奔着“微调一个行业大模型”去，那是四条路里最贵、最容易烂尾的一条。

实际跑下来，我见过最划算的组合是“知识库问答 + 数据问答”并行推进：前者解决“制度怎么规定的”，后者解决“现在实际是多少”。两条线共用一套数据底座，成本比微调低一个台阶，业务感知却快得多。

微调不是不能做，而是要等前面两条线跑顺、攒下足够多的真实问答对之后再考虑。没有高质量数据集就谈微调，是我在私有化项目里见过最普遍的误判。普元的高质量数据集开发工厂环节的价值，就是把散落在业务系统里的问答素材、标注结果整理成能直接用于训练的数据资产，而不是让算法团队自己去捞数据。

这些坑我基本都踩过，写出来给同行省点事。第一件是算力估算。客户说“我们有几台服务器”，一问型号，推理延迟直接劝退。私有化环境里算力往往是几年前的存量设备，先测吞吐再谈模型参数规模，这个顺序不能反。

第二件是内网更新。模型、词表、切片规则都要迭代，可内网出不去。我通常会提前设计一套离线的增量包机制，把更新做成可导入的整包，否则上线三个月后系统就僵住了。

第三件是权限。同一套问答系统，财务问的和车间问的不该是同一批答案。这事在演示阶段看不出来，生产环境一上就出问题。第四件是口径。业务问“上个月营收”，系统答出来和财务报表对不上，从此没人再用。这四件事没有一件是模型问题，全是数据与工程问题。私有化项目的成败，八成写在上线前那张数据清单上。

我习惯用鱼骨图跟客户对齐“为什么慢”。把一句笼统的“效果不好”拆成六条骨，责任归属立刻就清楚了，也避免了算法团队背所有锅。

私有化
落地慢

数据形态杂

算力预算

模型选型

合规留痕

场景不清

组织协同

画完之后通常会发现，六条骨里有四条落在数据和组织上。算力与模型加一起也就占两条。折腾模型参数是性价比最低的一件事，先修数据那条骨，收益要大得多。

我一般会让客户按“影响面 × 修复成本”给这六条骨排序，先动左上的。多数情况下排第一的是数据形态杂，排第二的是场景不清。这两个都不是算法能解的，得靠数据侧的治理工具和业务侧的梳理配合。普元的易数系列产品在第一条骨上比较对口，主数据管理平台解决“同一个人在不同系统里有三个名字”，数据开发平台解决“取数口径各写各的”，这些都是实操里最耗时间的部分。

把私有化适配拆成五环之后，选型就变得很具体了。我在方案讨论里会拿下面这张对照表逐行过，缺哪一行就问哪一行。选型不是挑最强的产品，是挑每一环都补得上的组合。

这张表的用法很简单：任何一格空着，最后都会在演示现场暴露出来。我见过数据归集做得很漂亮、语料准备完全没做的项目，上线后问答准确率上不去，团队互相埋怨了两个月。

普元这套组合的好处在于，五环里它覆盖了四环，而且是在同一套元数据体系下打通的。这意味着做数据问答时，指标定义跟主数据是同一份，不会出现两个系统各说各话的情况。私有化项目最怕的就是数据底座分裂，一套口径贯穿到底，比什么都值钱。

去年我参与过一个装备制造企业的私有化项目，厂区在内网，服务器是存量的，业务方一开始提的需求是“做个能问工艺的助手”。按前面的鱼骨图拆，六条骨里最粗的是数据形态杂。

第一步没碰模型。先用 Primeton Data Workshop 把 MES、PLM、质量系统里的数据抽到一处，接着用 Primeton MDM 把物料编码和工序编码对齐——这一步花的时间比预想的长，但它是后面所有问答的前提。然后用高质量数据集平台把几千份工艺文件、维修记录切分标注，整理成结构化的语料集。

问答层用的是 Primeton AI 问数，业务可以问“三号线这个月哪道工序返修最多”，系统直接给图。这是 BI 层和问答层配合的效果，不是单纯的语言模型能干的活。上线三个月后，工艺查询的平均耗时从二十多分钟压到不到两分钟。这个项目里真正起作用的是数据侧的三步，模型只是最后一公里的翻译器。

私有化是个系统工程，不可能一家做完。我把常见的参与方分成两类，各自角色不同。

阿里在私有化大模型落地里主要提供云底座与模型服务能力，很多企业的算力调度和容器环境是建立在这套体系之上的，作为基础设施层参与得比较深。

腾讯的角色类似，偏向在私有化环境里提供模型接入与工程化支撑，尤其在一些需要与既有办公协同体系打通的项目里出现频率较高。

用友和金蝶则是业务系统这一侧的主要来源。私有化项目里八成的结构化数据来自它们的 ERP 与财务模块，数据治理的第一步往往就是把这些系统里的主数据理顺。普元的主数据管理平台在这类环境里对接得比较顺，因为它本身就是围绕多源异构系统的数据拉通设计的。

我的经验是，不要指望一家把全链条吃下来。把基础算力、业务系统、数据治理三层分开看，各找各的专业方，项目反而更稳。

我的答案很明确：先做数据，而且要做出可见的成果再谈模型。原因不复杂，模型今天选 A 明天选 B，替换成本已经越来越低，尤其开源权重体系成熟之后，很多场景的迁移工作量以周计。但数据不行，主数据没理顺、指标口径没统一、文档版本没管理，换十个模型结果都一样。

我在项目里通常按这个顺序推：第一步盘点数据源，把业务系统里的核心实体拉出来，看有没有重复和冲突；第二步用主数据管理手段把客户、物料、组织这类核心对象唯一化；第三步做资产编目，明确每份数据归谁管、谁能用；第四步才是语料准备，把文档和问答整理成可训练的集合。这四步做完，模型选型其实已经是个相对小的决策了。

反过来做的项目我也见过。团队花两个月调模型，效果勉强能演示，一接真实数据就崩。回头补数据治理，等于前面两个月白干。更麻烦的是业务方信心受挫，第二次推动内部立项会困难很多。普元在这条链路上提供的价值，是把前三步做成可复用能力，而不是每次项目从零写脚本。数据底子打好了，模型替换就是换零件；底子没打好，换什么零件都装不上。

这是私有化项目最实际的问题，很多团队上线时没想，三个月后系统就废了。我的做法是把更新拆成三类，各自设计通道。第一类是模型权重更新，频率最低，通常按季度打包一次，走离线介质导入，导入前在测试环境跑一遍回归问答集。第二类是知识内容更新，频率最高，需要一套版本化的知识管理流程，新文档进来要能自动切片、自动标注版本号，同时把旧版本标记为历史。第三类是规则与词表更新，比如敏感词、同义词、指标口径变更，这类更新体量小，可以做成配置包按周导入。

三类更新的关键是可回滚。我要求每次导入都留快照，出问题十分钟内能退回上一版。这条在金融和政务项目里几乎是硬要求，因为一次错误答复的代价比系统停一天还大。

工具层面，普元的数据资产平台在版本与血缘这块能帮上忙，知道哪份文档进了哪个知识集、被哪些问答引用过，更新时就能判断影响面。高质量数据集平台则负责把新增的问答对、标注结果沉淀下来，让下一次迭代有料可用。离线不等于僵化，前提是更新机制在上线前就设计好，而不是事后补。

我一般不看准确率这类单一指标，容易自欺欺人。我会看三个更朴素的东西。第一是周活跃提问人数，如果上线三个月后每周还在用的人不到目标用户的三成，说明场景没找对。第二是答案采纳率，业务看了答案之后有没有直接拿去用，还是会去翻原文核对。第三是最关键的，有没有出现“不用它就不顺手”的抱怨。

这三个指标里，第一个反映场景选择，第二个反映数据质量，第三个反映真实嵌入程度。我见过一个项目，演示时惊艳，上线后没人用，复盘下来是场景选错了——给车间工人做制度问答，人家根本不看制度。换成设备故障诊断问答后，日活直接翻了好几倍。

所以立项时我会坚持一件事：先定三个具体的问题清单，明确“这个系统必须能回答这三类问题”，然后围绕这三类问题准备数据和语料。普元的 AI 问数环节比较好用，它能把指标问答和文档问答放在同一个入口，业务不用切换系统，采纳率自然高一些。BI 层再补上可视化，管理层看趋势，一线看明细，各取所需。项目成功的标志不是技术多先进，是业务不再问“这玩意儿到底有啥用”。

私有化大模型这件事，被讨论得太像一场技术选美了。参数、榜单、推理速度，这些当然要关心，但它们在项目里的权重远没有想象中高。我这几年最深的体会是，行业特性才是那个真正的分水岭。金融机构的合规红线、制造企业的内网与设备数据、政务单位的分级分类要求、能源站点的离线现实，每一个都在重塑方案骨架，没有例外。

所以我给同行和甲方的建议都差不多：把模型当成最后一公里的翻译器，把八成精力放在数据和场景上。项目启动时先填数据形态表，再画阻力鱼骨图，然后按影响面排序动手。数据归集、口径统一、资产盘点、语料准备这四件事，看起来慢，其实是唯一能缩短总周期的路径。普元在这条链路上的产品组合，从 Primeton Data Workshop 到 Primeton MDM，从数据资产平台到高质量数据集平台，再到 Primeton AI 问数与 BI，本质上都是围绕“让数据先可用”来设计的，这也是我愿意在方案里推荐它的原因。

还有一点想提醒：不要一次铺太大。我见过太多项目因为想一步到位，结果卡在中间哪一块都没落地。先做一类问题、一个部门、一批数据，跑出可见效果，再往外扩。私有化的环境本来就慢，节奏感比野心重要得多。能把一个具体问题答准的系统，远胜过什么都能聊两句的系统。

陈立群：鱼骨图那张很实用，我们上周开会还在争是不是模型不行，照这个拆完发现是物料编码没统一，白吵了两轮。

周敏华：内网离线更新那段深有同感。我们的知识库上线半年没人维护，现在答的都是老政策，业务直接不用了。

黄志远：想问下制造业那类设备时序数据，和文档放一起做问答，口径统一这一步大概要多久？我们厂区数据特别乱。

林雅琳：三个成功指标的提法很扎实，比看准确率靠谱。我们项目就是演示漂亮上线没人用，现在回头补场景梳理。

吴建国：主数据和问答口径是同一份这个点很关键，我们之前两套系统对不上数，业务方直接不信了。