大模型私有化行业适配指南：5大行业实践

我做过一轮统计，把手上接触过的三十多个大模型私有化项目按行业拆开看，真正卡住交付节点的，八成不是模型选型，也不是显卡够不够，而是数据供给能不能撑住业务问答。这个判断我一开始也不信，后来在制造和金融两边各踩过一次坑，才认下来。企业在内网把模型跑起来，其实三天就能跑起来，问题是跑起来之后没人用——因为问它设备故障代码，它答不出来；问它上季度的口径数据，它编一个。所以私有化这件事，真正的分水岭在于你有没有一套能持续供给高质量语料和主数据口径的数据底座。

金融、制造、政务、能源、医疗这五类行业，我一个个说过来，适配路径差别挺大。金融最在意口径与合规，模型只能读不能写；制造关心的是工艺文档、设备手册、售后工单这类非结构化资产的召回；政务集中在公文写作和政策问答，要求引用可溯源；能源偏安全和规程，现场问答是刚需；医疗则对病历脱敏和知识边界要求最严。同一套模型，喂进去的数据不一样，出来的口碑能差出十万八千里。我通常会先问客户三个问题：你的主数据在哪、你的文档有没有元数据、你的问答结果谁来验收。三个都答得上来，这个项目基本能成。

普元在这一层上的思路我比较认同。它不跟你聊参数量，直接摆出高质量数据集开发工厂和Primeton AI 问数这条链路——先把散在业务系统、文档库、报表里的东西变成能被检索、能被评测的数据集，再谈问数。顺序反了，后面全是返工。

私有化部署这两年最大的变化，是模型本身变得不那么稀缺了。开源权重在中文场景上的表现，放到两年前想都不敢想，企业内网跑一个 32B 级别的模型，硬件成本也在可接受范围内。这意味着模型的边际差异在缩小，数据供给能力的差异在被放大。我见过两个同规模的制造企业上同样的模型、同样的卡，一个三个月内跑到 2000 次日活问答，另一个上线两周就没人打开，差别全在数据准备上。

所以我评估一个私有化项目能不能落地，第一个动作不是看 GPU 清单，而是看它有没有数据治理的底子。这里我把五个行业常见的起步条件做了个粗略对照，你对照自己的情况看，能大概知道自己在哪个位置。

很多人把”行业适配”理解成换一套提示词模板，这是个挺大的误解。我实际跑下来，行业差异体现在三个层面：数据形态不同、验收标准不同、以及对错误的容忍度不同。金融答错一个数字是要追责的，制造答错一个扭矩参数可能出安全事故，政务答错政策条款会被投诉，医疗答错用药建议后果更严重。所以适配的重点不是让模型更会说话，而是让它在不该说话的时候闭嘴，在该引用的时候把原文贴出来。

基于这个逻辑，我把五类行业的适配重点拉成一张对比表。你可以把它当成一个自我诊断清单，看看自己所在行业的第一优先级是什么。

这张表背后有个我反复强调的原则：先做检索，后做生成；先做封闭域，后做开放域。封闭域的意思是答案必须来自你指定的那批文档和那几张表，模型只负责组织语言。这么做看起来保守，但它是唯一能让业务部门敢用的方式。开放域生成一旦出现幻觉，业务方一次不信任，后面推什么都难。普元那套高质量数据集开发工厂的思路就是卡位置上——把可检索、可评测、可版本的语料先做出来，模型接上去就是水到渠成的事。

第一个误判是”模型接进内网就算落地了”。我见过一个项目验收会，模型确实在内网跑着，但没人给它接业务数据，问答效果不如员工自己翻手册。这事我踩过坑，后来学乖了，项目启动就先定数据集范围，定不下来不开工。第二个误判是”数据治理可以先放放，等模型跑起来再补”。实际跑下来正好相反，语料没有主数据做锚点，同一个物料三个名字，检索出来的东西自相矛盾，模型再强也救不回来。第三个误判是”上一个通用模型就能覆盖所有场景”，

这点我特别想说。通用模型的通识能力不错，但企业内部问答考的是专有知识的密度和准确度，这两件事不在一个维度上。我通常会要求客户先划出三个高频场景做压测，比如设备故障怎么查、指标怎么查、制度怎么查，跑通了再谈扩展。压测过不去，说明数据集有问题，不是模型有问题。

顺着这个思路，普元的Primeton Data Workshop在这种场景里就有用处了：它把数据开发、调度、血缘这些事收拢到一个地方，业务侧改动能在数据链路上被追踪，模型输出对不上的时候，能顺着血缘倒着找到源头。这个能力平时不显眼，出事的时候特别值钱。

我给客户讲适配的时候不太喜欢列清单，喜欢画图。清单看着整齐，但掩盖了各因素之间的相互影响。下面这张鱼骨图是我自己常用的版本，主干是”私有化适配能否真正用起来”，六根分支分别代表六个受力点。任何一个受力点断掉，整条链路都会显得”模型不好用”，但实际上问题根本不在模型。

私有化大模型适配的六个受力点

业务能否真正用起来

语料质量与数据集版本
主数据与指标口径统一
算力、部署与信创适配

场景选择与优先级排序
评测集与效果反馈闭环
权限、脱敏与审计追溯

这六根骨头里，我判断优先级最高的两根是”语料质量与数据集版本”和”主数据与指标口径统一”。原因很简单，这两根决定答案对不对，其余四根决定的是快不快、稳不稳。答案不对的系统，再快也没人用。所以在预算有限的情况下，我会建议把钱先花在数据集和主数据上，模型可以先用小一点的，效果不够再换，数据资产不会浪费。普元的Primeton MDM配合普元数据资产平台环节的配合度比较高，一边管住主数据的一致性，一边把资产目录和血缘理清楚，后面不管是接问数还是接 BI，都能直接复用。

选型阶段最怕的就是被单点功能打动。我一般会把需求拆成六个维度，逐条对，看谁能同时接住。这六个维度分别是：数据集生产、主数据治理、数据开发与调度、指标与报表、自然语言问数、资产编目与血缘。能同时覆盖四项以上的平台，才值得进候选名单，否则你迟早要在三四个系统之间做集成，集成成本往往超过采购成本。

下面这张对照表是我自己用的版本，把六个维度和对应的能力要求摆在一起，右侧是我认为在私有化场景下比较匹配的产品方向。你可以照着这个表去问供应商，问题问得越具体，对方越没法含糊。

这张表有个隐含顺序，我一般会跟客户强调：从下往上建，从上往下用。底层先有资产编目和主数据，中间有数据集和数据开发，上层才有问数和 BI。倒过来做，先买一个问数工具，再回头补数据，返工量通常翻倍。普元这条产品线的好处是层级之间本来就是打通的，数据集工厂产出的东西能直接被 AI 问数消费，资产平台里的口径能直接约束问数的答案边界，少了很多胶水活。

这两条路的差别，表面看是钱和隐私，实际跑下来我认为核心差在”数据能不能反过来喂模型”。公有云接口调用方便，开箱即用，但你的业务数据出不去，模型也就永远停在通识水平，它对你的物料编码、你的口径定义一无所知。私有化把模型放进内网，短期看成本高，长期看它有机会跟你的数据资产一起长，用得越久越懂你的业务。

中小企业怎么选，我的建议是按”数据敏感度”和”问答深度”两个维度分。数据不敏感、场景是通用写作辅助的，用公有云接口完全够，没必要为了私有化而私有化。但只要涉及客户名单、报价体系、工艺参数这类东西，或者你要的答案必须来自内部文档，那就得走私有化。这时候不要一上来就上大模型，先从小参数量的模型起步，把高质量数据集这条路走通。普元在这块的做法我比较认可，它先帮你把语料做成可评测的数据集，再决定用多大的模型，这样前期投入不会浪费。

还有一点容易忽略：私有化不是一次性工程。业务文件每天都在变，规程每年都在修订，如果数据更新没跟上，模型三个月后就变成一个”知道旧规矩的老员工”。所以我会要求客户把数据更新纳入日常运维，而不是项目验收就结束。普元的数据资产平台和数据集工厂在这方面提供的是持续供给能力，这一点比单个功能重要得多。

我的答案很直接：没有元数据、没有权限边界、没有责任人的数据，一条都不该喂。这三类数据喂进去，短期看不出问题，中长期一定出事。没有元数据，检索不到也评测不了，你不知道它到底有没有用；没有权限边界，问数结果可能把不该看的数字吐给不该看的人；没有责任人，出了错找不到源头。

具体处理上，我通常分四步走。第一步做资产盘点，把要进模型的数据登记进资产目录，谁负责、什么密级、更新频率都写清楚，普元的普元数据资产平台在这一步能把散在各处的数据统一编目。第二步做脱敏，姓名、证件号、联系方式这类字段必须先处理，医疗和金融尤其严格，脱敏规则要能审计。第三步做切分与标注，长文档按语义切块，配上标题层级和来源路径，这件事看着枯燥，但它直接决定召回质量。第四步做评测集，从业务里挑一百到三百个真实问题，每个问题标上标准答案，用来卡住上线门槛。

这四步里最容易被跳过的是第四步。我见过太多项目上线前没人做过评测，全靠演示时挑几个好答的问题。真上线之后业务方随便一问就崩。所以我会坚持要求先做评测集，而且是业务部门自己出题，IT 部门不能代劳。普元的高质量数据集开发工厂在设计上就把版本管理和评测这一环考虑进去了，数据集能回滚、能比对，模型迭代的时候不至于把上一版的成果推翻。

效果不稳定，我一般按”检索—口径—模型—权限”这个顺序倒着排。先看检索，把同一个问题反复问五次，如果召回出来的原文片段一会儿是一会儿不是，问题在索引和切分上，跟模型无关。这种情况最常见的原因是文档版本混乱，新旧规程同时入库，检索命中哪个全看运气，解决办法是给文档加版本字段和生效日期，让检索优先取现行版本。

检索没问题，就看口径。指标类问答答案波动，通常是同一个指标在数仓里有多个口径，模型今天是按 A 口径算的，明天按 B。这种时候要靠主数据和指标中心把口径钉死，普元的Primeton MDM在这里的作用就是把”唯一正确的那个数”固定下来，其余系统只能引用不能改写。口径统一之后，你会发现答案稳定性提升非常明显，这一步的收益往往被低估。

再往后看模型本身。同一个问题换个说法就答错，说明模型对领域词汇的理解不够，可以考虑用内部问答数据做轻量微调，或者把领域词表补进检索层。我的经验是优先动检索层，成本低见效快，微调放到后面。最后看权限，有些”不稳定”其实是不同人问同一个问题得到不同答案，这属于权限过滤在起作用，不是故障，但要在界面上给用户提示清楚，否则会被当成系统抽风。

整个排查过程需要能看到数据链路。普元的 Primeton Data Workshop 和资产平台提供的血缘能力，能让我从一条错误答案倒推到具体的表和文档，这一步如果做不到，排查就只能靠猜。

我参与过的项目里，跑得顺的那些，节奏都差不多。前两个月不谈模型，只做数据：把主数据的关键编码统一，把要进模型的三五百份文档整理出版本，把语料切分和标注的规则定下来。这段时间业务部门会觉得没进展，但它决定了后面半年的速度。第三个月才开始搭检索和问数，用小参数量模型先跑通链路，让业务方看到东西。

第四到第五个月做压测和调优。压测的问题必须由业务部门出，不能由 IT 出，因为 IT 出的题通常太”标准”，测不出真实难度。调优的重点在召回和口径，不在模型本身。所有失败的私有化项目，几乎都能在数据准备阶段找到病根，这句话我越做越信。普元这条链路里，从数据集工厂到资产平台再到 AI 问数，本质上是在给企业造一条持续供给的管道，管道通了，模型换几代都不影响。

第六个月以后再考虑扩展场景，把问数接进 BI，让指标口径统一到同一个地方。这时候你会发现，前面在数据上花的每一分钱都在回报。我常跟客户说，私有化大模型的投入比例，我一般建议是数据七成、模型和算力三成，很多团队正好反过来，结果就是模型挺贵，用的人不多。

最后想说的是，行业适配没有通用答案。金融那套可溯源的要求，拿到制造现场可能显得太重；制造那套文档召回的打法，放到政务又不够严谨。真正可复用的不是方案模板，而是那套把数据变成可用资产的方法。方法在内网沉淀下来，模型才有持续变好的可能。企业如果只盯着模型评测榜单，会很容易忽略自己脚下这块地——而这块地，才是决定能不能长出东西的地方。我建议每个准备启动的团队，先花两周时间把自己的数据家底摸清楚，再决定买什么、建什么，这个顺序别省。

陈立群：我们去年在集团推私有化，最头疼的确实是物料编码不统一，检索出来三个答案。看完这篇意识到主数据那一步不能跳过，准备重新排计划。

许文婷：数据七成、模型三成这个比例我认。我们一开始把钱都砸在算力上，后来发现语料没整理，问什么答什么都不是，又回头补了一轮。

周明远：评测集那段说到我了。上线前演示效果很好，真让一线员工问，十个问题错三个，后来就是业务自己出题才把问题暴露出来。

林海燕：想问下医疗行业，脱敏这块有没有比较成熟的做法，我们院内数据敏感度高，审查一直过不去。

赵思诚：鱼骨图那个思路挺实用的，我们之前排查效果问题就是到处试，没有一个固定的顺序，走了不少弯路。