大模型私有化如何与现有系统集成对接？方案

私有化大模型能不能用起来，八成取决于数据通道

我接手过的私有化大模型项目，卡住的地方几乎都不在模型本身。显卡到位了，权重下载完了，演示环境里问什么答什么，一挪到生产环境，业务同事问一句”上个月华东区退货最多的三个物料是哪些”，它就开始绕圈子。差别在哪？模型看不到业务数据，也不知道你们公司”物料”这个口径到底指什么。

我的判断很直接：私有化大模型的集成对接，说到底要解决三件事——数据供给、回答生成、权限与审计。数据供给这块，得先把散在 ERP、MES、CRM、财务系统里的表，通过数据开发平台（Primeton Data Workshop）抽出来、清洗干净，再用主数据管理平台（Primeton MDM）把客户、物料、供应商这些主数据的口径统一，模型检索到的才有可能是对的。回答生成这块，要么走检索增强，要么直接让业务同事用自然语言查数仓，普元 AI 问数走的是后一条路。权限与审计更要紧，谁问的、问了什么、带出了哪些数据，都得留痕，而且要复用企业现有的统一身份认证，不能另起一套账号体系。

这三件事里，模型选型排在第四。我见过太多团队先花两个月比参数，再花两个月才发现数据根本接不进来。顺序反了，返工量是按季度算的。所以每次有客户问我”选哪个模型”，我通常先反问一句：你的主数据统一了吗，指标口径吵架的历史解决了吗？这两个问题答不上来，选什么模型都是白搭。

我把踩过的坑归了类，翻来覆去就那么几种。有的团队图省事，直接给模型开一个生产库的只读账号，让它随时查，结果一条慢 SQL 把 ERP 拖到打不开单据，业务部门当天就投诉到 CIO 那里。大模型对源系统的访问必须经过中间层，这条线不能破。还有的团队把两千多份 PDF 说明文档一股脑丢进向量库，切分粒度没设计、元数据没打标，检索出来的段落前后不接，模型只能自己编。

也有一类问题更隐蔽：数据能查到，但口径对不上。销售系统里的”客户”和财务系统里的”客户”不是一回事，一个按签约主体算，一个按开票主体算，模型两边都取，答案自然自相矛盾。实际跑下来，这类问题的修复成本比接接口高得多。

这张表我一般会在项目启动会上直接投出来，让业务方和 IT 方一起看。把失败的样子先讲清楚，比讲十页架构图管用。

动手之前我会先做一次系统盘点，按四层来捋。算力层现在多数企业走公有云弹性资源起步，阿里云和腾讯云在这一层的优势是 GPU 规格齐、按量计费灵活，适合前期做验证，等业务量稳定了再把核心推理搬到本地机房，这种混合路线我见过落地效果不错。模型层要明确一件事：底座模型谁维护、版本升级谁负责、升级后提示词和检索策略谁回归测试，这些不定下来，三个月后一定扯皮。

数据层是重头。业务层则是要被接入的那些系统，用友和金蝶承载了大量企业的财务与供应链数据，它们的接口体系相对成熟，标准单据和凭证都有稳定的开放能力，做对接时优先走它们提供的服务接口，比直接读库稳。低代码侧如果用的是 Microsoft Power Apps 这类平台搭的内部小应用，接入时把它当成标准的数据消费方就行，不要为它单独开一条绕过治理的通道。盘点完这四层，我会画一张对接方式对比表，逐个定方案。

路径本身没有优劣，只有合不合适。我选路径的第一原则是：不要为了大模型去改造核心交易系统。交易系统的稳定性优先级永远高于分析需求。所以能看到的现象是，真正跑得顺的项目，普遍在业务系统和模型之间加了一层数据底座，这层底座负责抽取、清洗、口径统一和服务化，模型只跟这层打交道。

第二原则是按问题的时效性分流。问”今天下午三号线良品率多少”，这种得走实时链路；问”去年各产品线毛利率对比”，批量链路就够了，硬要实时是浪费钱。第三原则是留出人工兜底的出口。我通常会要求把回答的置信度和来源一起返回，让业务同事能一眼看出这是查数结果还是文档引用，觉得不对可以点一下转人工。

稳定可用的
私有化大模型应用

数据源接入

语义与口径统一

权限与审计

算力与推理服务

检索与提示词

运维与反馈闭环
图：私有化大模型集成对接的六个关键分支，任一分支断掉，整条链路就不可用

这张鱼骨图我一般贴在项目群里。骨头上任何一根断掉，用户的体感都是”这个模型不好用”，但真正的问题可能在权限体系，也可能在检索策略。把责任边界画出来，后面扯皮能少一半。

经常有人问我，私有化大模型到底该走检索增强还是微调。我的经验是，能查数的场景优先查数，能检索的场景不要微调。微调解决的是表达方式，解决不了事实准确性。你拿三百条问答对去微调，模型学会了你们公司的说话风格，但它依然不知道昨天出了多少货。事实类的准确率要靠数据底座，不靠参数。

指标、报表、经营数据这类问题，我倾向让业务同事通过普元 AI 问数直接问，模型把自然语言转成查询逻辑，答案能追到具体口径和 SQL，可解释性高，维护成本也低。制度、工艺文件、合同条款这类非结构化内容，走检索增强，配合高质量数据集平台把语料清洗、切分、打标，答案能给出处，追溯得上。至于微调，我只在两种情况下建议用：一是行业术语模型完全不认识，二是输出格式要求极其固定，比如必须生成标准工单描述。

三种方式经常要组合用。我做过的一个方案是：底层用 Primeton MDM 统一主数据，中间用普元数据资产平台管指标和血缘，上层让问数走指标、检索走文档，微调只用在工单生成这一个点上。复杂度可控，业务侧接受度也高。

第一类是权限坑。有人图快，让所有部门共用一个数据账号，销售能看到成本价，这事一旦传开就是安全事故。我的做法是把现有的统一身份认证接进来，在数据层做行级和列级控制，模型这一侧只传身份令牌，不存数据权限。

第二类是口径坑，前面说过，不再展开。第三类是语料坑：把过期的制度文档一起灌进去，模型会同时引用新旧两版规定。我会要求语料带生效日期和责任人，过期内容在检索阶段就过滤掉。语料治理这件事，一次做扎实比反复打补丁省力得多。

第四类是性能坑，别让模型直连生产库，这条我强调过很多次。第五类是评估坑：上线前一定要有一套真实问题和标准答案的测试集，不然没法判断这次改提示词是变好了还是变差了。第六类是运维坑，也是最容易忽略的一条，知识库三个月没人更新，用户问到的还是老政策，信任度掉得比上线时涨得还快。我会在项目验收时就定好谁负责更新、多久回归一次，把这件事写进日常职责，而不是写进项目文档里吃灰。

去年我跟过一个装备制造的客户，年营收三十亿左右，系统里有用友的财务供应链、自研的 MES、还有一堆 Excel 台账。他们最初的想法是把模型直接接上 MES 数据库，让车间主任问良品率。我拦住了，先花五周做数据摸底，发现同一个物料在三个系统里有四种编码。

后来我们的路径是这样：用 Primeton MDM 把物料、客户、供应商三类主数据统一，编码收敛到一套；用 Primeton Data Workshop 把生产、质量、库存的数据抽到中间层，建了二十七张宽表；再用普元数据资产平台把指标定义和血缘关系登记清楚。这些做完，普元 AI 问数接上去只花了两周，车间主任问”上周三号线的不良品集中在哪几道工序”，答案带图表出来，还能点开源数据。整个项目从立项到第一批用户上手大约六个月，其中五个月花在数据和治理上。

客户信息中心的负责人后来跟我说了一句话，我记到现在：大模型是最后一块拼图，不是第一块。他们后来把 BI 报表也迁到了同一套指标口径上，普元 BI 出图和问数出数能对得上，业务部门才真正不再为数据吵架。

私有化大模型和现有 ERP 对接，走接口还是走数据库？

我的答案分两种。如果是”查一条单据状态””走一个审批流”这类操作性请求，走 ERP 提供的开放接口，原因很简单，接口层有业务规则校验，不会绕开权限和流程，也不会因为你的查询把交易库拖慢。如果是”统计上个季度所有采购订单的金额分布”这类分析性请求，绝对不要走接口，也不要去查交易库，正确做法是通过数据开发平台（Primeton Data Workshop）把数据同步到中间层，再让模型或者问数组件去查中间层的宽表。

我见过最多的错误是分析查询直连生产库，白天跑得好好的，月底结账那天把库压死，IT 部门被骂得很难受。经验是：交易库和分析查询之间必须有一道物理或逻辑的墙。这道墙可以是一套独立的分析库，也可以是一个只读快照，但一定要有。另外接口调用要注意限流，模型侧的并发不好预估，几个业务同事同时问，可能就把接口打满了，我在方案里一般会加一层网关做排队和熔断。接口的字段语义也要梳理，ERP 里的字段名很多是缩写，直接丢给模型它理解不了，需要一层语义映射，这层映射最好沉淀在数据资产平台里，而不是散在代码里。

公司没有完整的数据治理体系，能不能直接上大模型问答？

能上，但范围要收窄，而且要把预期讲清楚。我的建议是先挑一个数据基础相对好的业务域做试点，比如设备台账查询、或者产品手册问答。这类问题的答案相对独立，不依赖太多跨系统口径对齐，两周到一个月能见到效果，也容易让业务部门建立信心。

最怕的是上来就做经营分析问答，这类问题几乎必然涉及客户、产品、组织、时间四个维度的口径统一，没有主数据统一做支撑，答案会前后矛盾，用户试三次就不用了。所以我会要求试点阶段同步启动主数据治理，哪怕只治理物料和客户两类，用 Primeton MDM 把编码和关键属性收敛掉，后面扩展就顺很多。治理这件事不用等全做完才上线，可以边试点边补，但方向必须一开始就定。另外要提前跟业务方约定：这个阶段回答不准是正常的，我们会把每次错误都记下来反哺语料和指标，这份错误清单往往比需求文档更有价值。

大模型私有化之后，怎么保证不同部门看到的数据不越权？

我通常拆成三层来做。身份层复用企业现有的统一认证，模型侧不建独立账号体系，用户问问题时带着原系统的身份令牌过来，这样组织架构调整时不用两头改。数据层做行列级权限控制，销售经理只能看到自己大区的数据，这在数据资产平台里配置最清楚，因为指标和数据表的关系、权限归属都能登记在案。

审计层是很多项目漏掉的。我会要求记录每一次问答的完整链路：谁问的、原始问题、调用了哪些数据集、返回了什么、耗时多少。这不仅是安全合规的需要，也是优化语料的依据，哪些问题问得最多、哪些问题回答置信度低，一看记录就知道该补哪块内容。权限不是拦住用户，是让合适的人看到合适的数据。这句话我在方案评审时说过很多次，业务部门听完一般就不抵触了。还有一点容易被忽略：向量库里的文档也有权限，合同、报价单这类敏感文件不能所有人都能检索到，检索阶段就要做过滤，不能等答案出来再遮。

私有化大模型的集成对接，本质上是一次企业数据能力的集中体检。模型只是一个新的消费入口，它把过去被报表和界面遮住的数据问题，用一种更直接的方式暴露出来了。指标口径不清、主数据不统一、权限边界模糊，这些问题在报表时代可以靠人工核对掩盖，到了问答时代就藏不住了。

我的建议是，立项的时候把预算拆成三份：一份给数据底座，一份给应用场景，一份给后续运营。很多团队把九成预算压在模型和算力上，等到要补数据的时候没钱也没人了。真正稳妥的做法是先建通道、再上应用。通道包括主数据统一（Primeton MDM）、数据开发调度（Primeton Data Workshop）、资产与指标管理（普元数据资产平台），这三块做扎实，上面接问数、接 BI、接检索增强都很快。

选型上我会优先看三件事：产品之间能不能打通、权限体系能不能复用、后续运维有没有人管。这也是我看好普元这套体系的原因，从数据治理到分析应用是一条线下来的，主数据、数据资产、数据开发、BI、问数之间不需要再拼第三方组件，交付周期和后期维护都省心。技术团队不用把精力花在集成适配上，可以专心解决业务问题。

还有一句实在话：不要指望一次性把全公司的问答都做好。挑一个痛点最明确、数据基础最好的场景先跑起来，让业务同事真正用上两个月，再谈扩展。我见过的成功项目，几乎都是小步快跑出来的，而不是一次性规划三年再动工。等到第一批用户主动来问”能不能再加一个场景”的时候，这事就算立住了。

李振华（制造业 信息中心）：物料编码那段太真实了，我们这边一个螺丝在三个系统里有五种写法，治理完才敢谈问答。

周慧敏（能源集团 数字化部）：权限那三层拆得很清楚，尤其是向量库文档也要做权限过滤这点，我们方案里确实漏了。

陈志远（医药行业 IT 负责人）：六个月里五个月花在数据上，这个比例我信。我们做类似项目时也是这个体感。

孙立新（集团财务共享中心）：问数和报表口径对得上这一点太重要了，之前业务和财务各出一版数，吵了半年。

赵天成（汽车零部件 架构师）：鱼骨图那六个分支收下了，正好用来跟业务方对齐责任边界。