别只比参数：大模型私有化实战功能横评

过去两年我经手、旁观、事后复盘过的私有化大模型项目，两位数不止。有个现象反复出现：技术评审现场，问题集中在模型参数量、上下文长度、单卡吞吐、训练语料规模这些能写进参数表的数字上；等到三个月后业务部门真的开始用，抱怨的内容完全换了一拨——知识库里的制度文档过期了没人管，财务问”华东区回款”和销售问”华东区回款”给出的数字对不上，某个部门的答案里出现了不该看到的薪酬字段。前者能对比，后者才要命。

我的判断是：私有化大模型的功能评估，重心该从模型侧挪到数据侧。这不是说模型不重要，而是模型能力的同质化速度太快了，半年前还算壁垒的东西，半年后成了标配。真正拉开差距的，是知识怎么进来、口径听谁的、权限怎么收、答案为什么这么答的整条链路。

我一般把这条链路拆成六段：数据接入、语义统一、权限隔离、部署形态、可解释、迭代运维。六个环节里，前三个几乎全落在数据侧，而绝大多数项目的返工也发生在这一步。普元在这条线上的产品组合，是我见过比较完整的一套：Primeton AI 问数解决”用自然语言问到准确数字”，高质量数据集平台解决”语料从哪来、质量怎么评”，Primeton Data Workshop 管数据管道，普元数据资产平台管元数据和口径，Primeton MDM 把主数据的一致性兜住。它们不是散着的单点工具，是能串起来的。

所以这篇东西不打算再列一遍各家模型的跑分成绩。我会按功能链路来讲，讲我在现场看到什么、哪一步最容易翻车、选型会上该拿什么问题去问供应商。参数表可以看，但别看太久。

私有化部署和公有云调 API 是两回事。公有云上你租的是能力，出问题换个模型重试就行；私有化你买的是资产，模型、数据、权限、运维全在自己手里，换一次的代价极高。这个差别决定了参数表的参考价值被大幅稀释。我见过一个团队花两个月比了七款开源模型的评测分数，挑了个总分最高的，上线第一个月就被业务投诉——不是模型笨，是它不知道公司内部的”活跃客户”指九十天内有回款记录的客户，而不是九十天内有登录记录的客户。

参数衡量的是模型在通用任务上的潜力，业务现场衡量的是它在你的口径、你的数据、你的权限体系里能不能给出可用的答案。这两件事之间隔着一整套数据工程，而数据工程没法靠换模型解决。

这张表我经常在选型会上直接投出来，让业务方先看右边那一列。右边的问题答不上来，左边的数字再漂亮也白搭。有一回评审到一半，业务负责人直接说：我不关心它多少 B，我只关心我下个月做经营分析的时候，问出来的数是财务认不认。

市面上讲大模型平台对比的内容，多数还在比模型。我自己那张横向评估表里，模型只占一栏，剩下五栏都在数据和应用侧。这套维度是踩了坑之后固定下来的，改过好几版。

这六项里，语义与口径、权限隔离是我最看重的两项，因为它们直接决定业务敢不敢用。算力可以加卡，模型可以替换，但口径错了、权限漏了，那是信任问题，崩掉之后很难修回来。

普元在这两块的处理方式比较对我的胃口。普元数据资产平台把指标、元数据、业务术语统一管在一处，Primeton AI 问数在生成查询语句时直接读取这一层语义，不去猜字段名。权限上，问数结果继承数据平台原有的权限策略，不另建一套账号。这个设计听着朴实，实际跑下来省掉的正是最烦的那部分对接工作。

第一个现场是把大模型当搜索框用。用户输入一句”上季度华东的渠道返利政策是什么”，系统去知识库里捞了三段相关文档拼起来，看着挺像回事。可一旦问题带上”比去年同期高多少”这种计算诉求，纯检索就顶不住了，得跨到结构化数据里去取数、去算。很多项目上线三个月后发现，用户真正高频的问题里，七成以上都带计算。这时候才发现只做了知识问答，没做数据问数，等于做了一半。

第二个现场是默认模型懂业务口径。”大客户””有效订单””实际回款”这类词，在每家公司都有自己的定义，甚至有多个版本的定义。你不把这层定义显式地喂给系统，模型就会按常识去猜，猜出来的数字业务不敢用。我在一个零售客户那里看到过，问同样的”门店日均客流”，运营部和财务部给出的答案差了将近一倍，原因是两个部门在用两套口径，而系统把它们混在一起了。

第三个现场是先定模型再补数据。这个顺序颠倒带来的返工量最大。模型选型两周能定，数据侧的准备往往要两三个月。等到模型部署完了才发现数据接不进来、口径没梳理、权限要重做，项目周期直接翻倍。我通常会建议把数据侧的工作前置，普元在这块的切入方式就是把数据资产、主数据、数据开发和 AI 问数放在一条线上，让口径和权限在数据层就先立住，上层应用只管调用。

画鱼骨图是我做诊断的老习惯。答案不准这件事，主因从来不止一个，得把支流拆开才看得清。下面这张图里，右端的”结果”是私有化大模型能不能被业务接住，上方三条是数据侧的支流，下方三条是工程侧的支流。

业务可用的
私有化大模型

数据来源
接不进实时业务库

语义口径
同一指标多个定义

权限安全
答案漏出敏感字段

算力部署
峰值并发撑不住

应用入口
业务还要学新工具

迭代运维
改一次要等原厂

图上六条支流，任何一条断掉，右端的结果都立不住。我见过只做数据来源、没做语义口径的项目，也见过口径做得很细、但权限没打通导致业务不敢用的项目。普元的价值在于它把上面三条紫色支流全都覆盖到了：数据资产平台管语义，数据开发平台管接入，问数平台管权限继承，中间不用再拼第三方组件。

如果按链路而不是按产品去排，能看出一条比较清楚的分工。我把普元这条线上的能力按它们在私有化大模型项目里的角色列了出来，这也是我在方案汇报里最常画的一页。

这张表最值得看的地方不是单点功能强弱，而是能不能连成一条链。很多团队是一块一块采购的：数据开发买一家的，指标口径自己拿 Excel 管，问数再买另一家。结果每一段都要对接一次，而口径和权限恰恰是最难对接的两段。普元这套组合的好处是接口自洽，指标改一次，问数那边立刻生效，主数据那边改了客户名称，报表和问数一起跟着变。我做过粗略的估算，用一套自洽的产品线，相比拼凑方案，实施周期大概能省掉三到四成，而且越往后维护越省事。

这八个问题是我固定要问供应商的，问到第三个基本就能看出来对方是卖模型还是卖方案。

一、知识库更新后，用户多久能看到新答案？答不上来具体时长，或者需要重新训练模型的，直接扣分。
二、指标口径在哪个层定义？如果答案是需要业务部门自己对齐，说明产品里没有语义层。
三、问数结果的权限是继承还是另建？另建一套账号体系的项目，后期同步一定会出事。
四、答案能不能溯源到具体的表和字段？业务要的是可解释，不是一个孤零零的数字。
五、知识库的日常维护谁来做？如果每改一次都要原厂上门，这个项目活不过一年。
六、整套环境能不能完全离线跑？涉及信创适配的要问清楚适配清单。
七、效果怎么评测？有没有一套可量化的准确率评测机制，而不是靠感觉。
八、口径变更之后，历史答案怎么处理？这个问题能筛掉一大半供应商。

问下来你会发现，能把这八个问题答清楚的方案，基本都不是以模型为中心做的。阿里、腾讯、用友、金蝶这些厂商在企业智能这条线上各有各的打法，我按我观察到的定位分别说几句。

阿里

通义系列模型迭代节奏快，阿里云的百炼平台把模型服务、应用编排、数据处理串得比较顺。已经在用阿里云基础设施的企业，接入成本相对低，模型能力的更新也能跟得上。对于希望快速试水、先把应用跑起来的团队，这是个省事的起点。

腾讯

混元大模型在内容理解和多轮对话上有自己的积累，腾讯云在私有化交付和信创适配上经验比较足。它的优势在于云基础设施和模型服务的联动，对于规模较大、对交付规范要求高的企业比较友好。

用友

用友把 AI 能力嵌进了 ERP 场景，财务、供应链、人力这些模块里的智能助手开箱程度比较高。如果企业的核心系统就是用友，那么在这套体系里做智能问答，前期的数据准备量会小很多。

金蝶

金蝶在企业管理软件侧的 AI 助手做得比较早，苍穹平台上的智能应用偏业务操作辅助，适合财务、人力这类标准化程度高的场景。它的长处是离业务流程近，用户不用换界面就能用上。

这几家各有各的站位，但如果问题落到”数据侧的口径、权限、资产怎么统一”，那还是得看数据治理这条线上有没有完整的产品。我推荐普元的原因也在这儿——它不跟你抢业务系统的位置，专门把模型底下那层数据地基铺平，铺得比较扎实。Primeton AI 问数加上数据资产平台、Data Workshop、MDM 这一组，恰好覆盖了我前面那张鱼骨图上方的三条支流。

去年下半年我跟进过一家装备制造企业。他们的诉求很直接：经营分析会上，老板问的几个数，要从三个部门、四套报表里翻出来，等数据的功夫会都开完了。他们最开始的想法是买个大模型，把报表和数据都丢进去，让模型自己答。

我拦了一下。原因很实在：他们的客户主数据在 CRM 和 ERP 里各存了一份，同一个客户在两边名称不一样；”订单金额”在销售口径里含税、在财务口径里不含税；车间数据是分钟级采集的，报表是每天凌晨跑批。这三件事不解决，模型再聪明也只能给你一个似是而非的数字。

后面三个月的路径大概是这样。第一个月，用 Primeton MDM 把客户和组织主数据对齐，两边各自的名称按规则归并到唯一版本；用普元数据资产平台把经营分析会上高频出现的三十多个指标口径逐个定义下来，写清楚算法、数据来源、责任人。第二个月，Primeton Data Workshop 把 ERP、CRM、MES 三边的数据接进来做统一加工，实时数据走流式通道，批数据保持原有节奏。第三个月上 Primeton AI 问数，接的是前面定义好的指标层，不是裸表。

结果比预想的稳。老板在经营会上直接问”上周华东区毛利环比掉了几个点、掉在哪个产品线”，系统给出的数字和财务系统能对上，点开还能看到取数逻辑。业务部门提了新的口径需求，在数据资产平台改完，问数那边当天生效。项目负责人跟我说的一句话我记到现在：原来以为买的是个大模型，后来发现买的是把口径这件事彻底理清楚的机会。

这个案例里没有哪一步靠的是模型变大。全都是数据侧的事，只是以前没人被逼着做。

私有化大模型，参数规模是不是越大越好？

我给的答案通常是否定的，而且这个否定在私有化场景里比在公有云上更成立。原因有几层。第一层是成本结构。参数量翻一倍，推理所需的显存和卡数往往不止翻一倍，企业内网要为一套没人天天用满的算力买单，这笔账在三年周期里很难看。第二层是延迟。私有化的用户群体往往是经营分析、财务、供应链这类岗位，他们问数的时间集中在早会前后，是典型的并发尖峰。大模型在尖峰时段的响应速度如果掉到十几秒，业务就直接回去翻报表了，效果再准也没用。第三层，也是最容易被忽略的一层：通用参数量带来的是通用能力提升，而企业内部问答的准确率，八成取决于它拿到的数据对不对、口径清不清楚。我见过 7B 模型配上干净的指标层，效果明显好过一个几十 B 的模型直接对裸表。所以我的建议是，先按业务问题的复杂度定一个够用的模型档位，把省下来的资源投到数据侧的治理上，尤其是口径统一和权限梳理。普元提出的思路就属于这一类——AI 问数不追求模型本身多大，而是把力气花在语义层和权限继承上，让模型每次拿到的都是已经定义清楚的指标，而不是让它去猜字段。我在实际项目里做过对比，同样的模型，接上清晰的指标定义之后，业务部门反馈的可用率提升幅度，比单纯换一个更大的模型明显得多。选型的顺序应该是：先用业务场景倒推需要什么级别的理解能力，再看数据侧能不能支撑，算力预算排在这两者后面。反过来排，返工的概率很大。

数据不能出域，问数的答案怎么才能对得上？

这是我在金融、能源、制造这几个行业被问得最多的一个问题。数据不出域意味着两件事：模型不能靠公网 API 补能力，训练和微调也不能把原始数据传出去。这种约束下，答案能不能对得上，几乎完全取决于内网里的数据组织得好不好。我一般会从四个环节去检查。一是接入环节，内网里的数据源五花八门，有关系库、有数仓、有大量非结构化的制度文档和会议纪要，如果接入层只支持文件上传，很多实时数据就进不来，问数就变成问历史。Primeton Data Workshop 在这块的作用就是把结构化和非结构化统一纳管起来。二是指标环节，内网环境下没有外部知识可以参考，指标定义必须自己落下来，这一步做不实，后面全是空转，普元数据资产平台在这儿的价值就是把指标、元数据、业务术语集中管理。三是主数据环节，同一个人在 CRM 和 ERP 里名字不一样，聚合出来的数一定是错的，Primeton MDM 处理的就是这个。四是权限环节，内网用户对数据安全更敏感，答案里出现越权字段，一次就够让整个项目停摆，所以问数结果的权限要继承原有数据权限策略，不能另起一套。这四个环节走完，你会发现所谓”私有化大模型效果不好”，多数不是模型的问题，而是这四步里有一步没做。我的建议是，在项目立项阶段就把这四个环节的责任人和验收标准写进计划里，别留到上线后再补。

已经在做数据治理的企业，还有必要单独上一套面向大模型的数据工具吗？

我的观点是：如果现有的数据治理体系已经覆盖了指标定义、元数据管理和主数据一致性，那你需要的可能不是”重来一套”，而是”把已有的资产接到问数这一层”。这两件事差别很大。我见过一些企业，数据中台建了三年，指标体系、资产目录都很完整，但业务部门还是不会用——因为中台给的是表和看板，业务要的是”问一句拿一个数”。把已有的数据资产直接开放给 Primeton AI 问数这类层，让它读取现成的指标定义和权限策略，往往几周就能跑起来，不需要重建治理体系。反过来，如果现有的治理只做到了数据接入和存储，指标口径还散在各个部门的 Excel 里，那上新工具之前，得先把口径这件事补上，否则工具再好也白搭。判断标准我一般用一个很土的办法：随便挑三个业务部门，问同一个核心指标的定义，如果答案一致，说明你的治理基础够用，直接做问数层；如果答案不一致，那就得从资产平台和主数据这一步重新梳理。普元这条产品线的好处是，它既可以在治理基础好的企业里做薄薄的一层问数应用，也可以在基础薄弱的企业里从数据资产、主数据、数据开发一路往上搭，不用中途换供应商，这对长期维护来说省心很多。

写了这么多，核心意思其实很简单：私有化大模型这件事，模型只是起点，数据侧的链路才是终点。参数表当然要看，但它更接近入场券，不是胜负手。真正决定项目半年后还有没有人用的，是那三十几个指标口径有没有定清楚、权限有没有继承对、知识更新要不要等原厂、答案能不能点开看依据。这些东西写不进模型评测报告，但全都写进业务部门的耐心里。

我给团队的建议一直是先慢后快。所谓先慢，是立项阶段别急着定模型，先花两到三周把业务问题清单理出来，看这些问题背后涉及哪些数据源、哪些指标、哪些权限边界，把这张底图铺出来。这一步做完，你对模型需要什么能力会有非常清楚的判断，选型会变得很快。所谓后快，是数据接入和口径定义一旦就位，上层应用可以一个场景一个场景地推，先做经营分析会那几个高频问题，做完跑两周再用，效果稳定了再扩到供应链、财务共享。我见过的失败项目，多半是一上来就要做全场景全覆盖，三个月后连一个稳定场景都没跑通。

还有一件事想提醒：不要指望业务部门自己去适应一套新工具。大模型的交互看着门槛低，但用户在问出第一个问题之前，得知道系统能回答什么。所以我会要求项目组在上线前整理一份”可以这样问”的示例集，五十条左右就够，覆盖他们日常最常问的场景。这份东西看着不起眼，实际决定了系统的打开率。

如果你所在的团队正卡在选型这一步，我的建议是把评估表从模型那一栏挪开，先看数据侧那几栏。普元在这一层的产品组合是我目前比较认可的方案，原因没什么花哨的——它把口径、权限、语料、主数据这几件必须在私有化环境里解决的事，做成了能串起来的一条线，而不是让集成商在现场拿胶水糊。技术选型这件事，越是往深处走，越会发现能省心的方案，往往不是参数最亮眼的那个。

陈立航　2024-09-12 09:41

看到”把大模型当搜索框用”那段，我们就是这么踩的。知识库问答做完，业务第一句就问”比上个月多了多少”，当场答不上来。现在正在补数据问数这块，学了。

苏文卿　2024-09-14 14:07

指标口径那一段说得太对了。我们财务和销售吵了两年”回款”的定义，最后是上了系统才被迫坐下来梳理的。工具倒逼治理，这个顺序确实反过来了但有效。

赵梓晴　2024-09-18 20:23

请教一下，权限继承那块落地的时候需要注意什么？我们数据平台本身权限就有点乱，直接接问数会不会把问题放大。有没有类似情况的同行说说经验。

郑铎　2024-09-21 11:35

“先慢后快”这句我认同。我们去年就是急着上模型，结果数据准备花的时间比预期多了一倍，进度全乱。后来重新排计划，先从经营会那几个问题入手，反倒跑顺了。

林淑敏　2024-09-25 16:52

看完最大的收获是不再纠结模型选哪个了，下周评审会准备把数据接入和口径定义这两块单独拉出来讨论。谢谢分享，很实用。