一文讲清大模型私有化的集成对接思路

我的核心判断：私有化大模型跑不跑得起来，八成压在集成对接这一层

我做过十几个私有化大模型的对接项目，从最早在信创环境里跑 7B 小模型，到近两年给制造业客户接 70B 级别的推理集群。有个感受越来越强：模型选型这件事，两周就能定下来，评测榜单拉一拉、显存算一算、并发压一压，八九不离十。真正耗时间的从来是另一件事——模型怎么跟已有的 ERP、MES、CRM、数仓、OA 连上，怎么让它在你的业务语境里说人话。

这事我踩过坑。有个客户，模型在测试环境里回答得挺漂亮，一上生产就露馅。销售总监问”上个月华东区退货率最高的三个经销商是谁”，模型答得有模有样，数字却是编的。我带着两个工程师查了两天，问题不在模型，在对接层——指标口径没统一，模型拿到的是一张没有业务语义的宽表，字段名叫 qty_rtn_1，鬼知道这是什么。

所以我通常会把私有化项目拆成三件事：算力与模型、数据供给、集成对接。前两件是花钱能解决的，第三件是花钱也不一定解决得了的。集成对接要处理的是权限、口径、实时性、上下文长度、工具调用协议、审计留痕这一堆琐碎但致命的东西。它不像模型那样有漂亮的跑分，但它决定了业务方愿不愿意用第二次。

这篇我按自己的项目经验来讲，讲清楚三条主流对接路线、四个最容易翻车的点、以及我评对接能力时会看的几个维度。不吹概念，只讲我在现场看到的东西。

私有化大模型的对接场景，现在主要集中在这几类

三年前大家还在讨论”要不要私有化”，现在讨论的是”私有化之后接什么”。我观察到的变化是：从单点问答走向业务流程内嵌。以前是把模型挂一个对话框，让员工自己去问；现在是模型直接嵌在工单系统、报价系统、质检系统里，人不用切页面，问题就解决了。

下面这张表是我在项目里梳理出来的常见对接场景，按落地频率排的。

看出来没有？对接方式的复杂度，跟数据本身的治理程度是反比关系。数据治理做得扎实的客户，对接一个场景两三天；数据是一锅粥的客户，光是把指标口径对齐就要开五次会。

这也是我为什么一直建议：上私有化大模型之前，先把数据资产盘一遍。普元的数据资产平台在这件事上帮过我不少忙，它能把我散落在各系统里的表、字段、指标、标签做一次统一编目，至少让我知道”我手上到底有什么牌”。没有这一步，后面全是在猜。

三条对接路线，我挨个说适用边界

对接这件事，外面讲得玄乎，实际拆开就三条路。我按自己用下来的手感做个对比。

三条路不是选一条，是叠着用。我手上跑得最稳的一个项目，就是检索增强打底、工具调用补动作、语义层兜指标，三层各管一段。麻烦在于叠起来之后，路由要做好——用户问一句话，系统得先判断该走哪条路。这一步做不好，就会出现”问指标结果给了一段制度原文”的尴尬。

路由这块我一般的做法是：先用轻量分类模型做意图判别，命中指标类就交给语义层，命中操作类就走工具调用，剩下的全进检索。开销不大，但体验差别很大。别小看这一层路由，它是私有化项目里性价比最高的一段代码。

另外提醒一句，路线三即语义层直连，看着最优雅，实际最难。它要求你的指标体系是活的、有定义的、有归属的。很多客户连”活跃客户”的定义都有三种版本，这时候硬上语义层，模型只会把三种口径混着用。

四个最容易翻车的点，我画了张图

项目做多了会发现，出问题的位置高度集中。我把常见的坑归成四类，画成鱼骨图，方便对着排查。

效果不达预期

数据侧
口径不统一
主数据缺唯一编码

集成侧
接口无幂等
超时与重试失控

权限侧
越权检索
无审计留痕

运营侧
没人维护语料
效果无度量

数据侧的问题最常见。我见过一个集团客户，同一个”销售额”在四个系统里有五种算法，含不含税、含不含返利、算不算内部交易，各不相同。模型不知道这些，它只会把几个数揉在一起编个听起来合理的答案。这种错误比答不出来危险得多，因为业务方看不出错。

集成侧的坑在工具调用里特别明显。有的接口没有幂等设计，模型重试两次就下了两遍单；有的接口超时是 30 秒，模型等不及自己换了个说法再问一遍。我的经验是：给模型用的接口，按”随时可能被重复调用”来设计，别按人的使用习惯来设计。

权限侧，私有化的初衷就是数据不出域，结果检索层给了一把万能钥匙，谁问都能拿到人事薪酬数据。这事我在评审会上拍过桌子。做法上，检索必须带用户身份过滤，且过滤要在数据层做，不能只在应用层做。

运营侧最容易被忽略。语料是会长毛的，制度更新了、产品改版了、组织架构调整了，知识库不动就会开始说错话。我的建议是固定一个”语料值班人”，每月过一遍高频问法和失效文档。

评一套对接方案，我通常看这六个维度

选型和验收的时候，我不太看 PPT 上的架构图，我看能不能回答下面这六个问题。这张对照表是我自己用的打分口径。

这六个维度里，我最看重第一条和第四条。数据供给不上，模型再强也是空转；答案不可回溯，业务方永远不敢拿它做决策。

说到可解释性，普元的 AI 问数在这块给我的印象比较深。它回答一个经营问题时，会把用到的指标、取数范围、时间口径一并列出来，点开还能看到明细。我在客户现场演示过，财务总监看完第一句话是”那我敢用了”。这句话比任何跑分都有说服力。

语料加工这块，普元的高质量数据集平台解决的是另一个痛点——不是”有没有数据”，而是”数据能不能直接拿去训和调”。我接手过一个客户，原始文档十几万份，格式五花八门，扫描件、PDF、Excel 混在一起。用人工整理，三个人干半年也未必干净。走平台化的流水线，清洗、去重、结构化、质量打分一次性过，效率差着量级。

还有一点很实际：数据开发环节别各干各的。用 Primeton Data Workshop 把取数逻辑、调度依赖、任务血缘统一管起来，后面模型换了、场景加了，改动量小很多。这事儿省的是未来的钱。

一个制造业客户的实际过程，我完整走了一遍

去年一家做精密零部件的客户找我，两千多人，上了私有化大模型，目标是让销售和售后能自己查订单、查工艺、查质量记录。之前他们内部试过一轮，结果很尴尬：模型能聊天，但一碰业务数据就胡编。

我进场先做的事不是碰模型，是盘数据。用普元数据资产平台把 ERP、MES、CRM 三边的表和指标做了一遍编目，结果发现主数据里客户名称有 4000 多条疑似重复，物料编码在两套系统里规则不一样。这一步花了三周，但后面所有工作都建立基础上。这三周是我在整个项目里花得最值的钱。

第二步做语料。工艺文件、质量报告、售后记录，先走高质量数据集平台做结构化处理，把不同来源的内容对齐成统一字段，再按业务对象切块。切块策略我们试了三版，按段落切的召回差，按工单聚合的效果最好。

第三步才到对接。三条路都用了：制度类走检索增强，订单和排产类走工具调用，经营分析类交给普元 AI 问数对接指标层。开发用 Primeton Data Workshop 编排，谁取了什么数、什么时候取的，全在血缘图里。

上线第一个月的采纳率大概四成，销售端抱怨”有时候答得慢”。我们查出来是工具调用的接口超时设得太长，把 30 秒压到 5 秒加异步回调，第二个月采纳率到了七成多。第三个月开始有自发传播，售后组自己提了十几个新问法让我们加。

这个项目给我最大的体会是：私有化大模型的收益是后置的，前三个月基本在还数据债。谁能在还债阶段不放弃，谁就能拿到后面的复利。

关于集成对接，被问得最多的几个问题

问：数据完全不出域的前提下，怎么把内部系统的数据喂给模型？

这个问题问得最多，也最容易被答偏。很多人一上来就纠结”要不要微调”，我的看法是：绝大多数企业的场景根本不需要微调，先把检索和调用做好。微调解决的是表达风格和领域术语的问题，解决不了”数字对不对”的问题。

具体做法上，我一般分三层。底层是数据供给层，把 ERP、MES、数仓里的数据通过统一编目整理出来，明确哪些字段可以给模型看、哪些绝对不能。这一步用普元数据资产平台做编目和权限标记，我能清楚知道每一个字段的归属和敏感级别。中间是语料加工层，文档、工单、报告这类非结构化内容走高质量数据集平台做清洗、去重、结构化，切成适合模型消化的粒度。上层才是对接层，检索、工具调用、语义查询三条路各管一段。

关键在于”不出域”这件事不是靠一句话保证的，是靠架构保证的。模型推理服务本身部署在内网，检索的向量库在内网，工具调用的接口也在内网，唯一对外的只有用户终端。我还会额外做两件事：一是所有取数行为留审计日志，能查到谁在什么时间问了什么、系统取了哪些数据；二是对输出做一次合规过滤，防止把敏感字段带出来。

还有一个容易被忽略的点：别指望一次把所有系统都接完。我通常建议第一批只接两到三个高频系统，跑顺了再扩。一次性铺开，出了问题定位起来像大海捞针。

问：大模型直接对接 BI 做数据分析，跟传统报表的差别到底在哪？

差别不在”能不能看数”，在于交互方式变了。传统报表是”你想好了要什么，去点几个筛选条件”；大模型问数是”你先把问题说出来，系统帮你找口径”。这个转变对管理层特别友好，因为他们往往知道自己关心什么，但不知道对应哪个报表、哪个维度。

但这里有个大前提：指标必须先被定义清楚。我见过太多客户直接让模型去读宽表，结果模型把”订单金额”和”回款金额”混着用。正确的做法是先有一层语义化的指标定义，模型只负责把自然语言翻译成对指标的调用，取数和计算交给下层。

普元 AI 问数在这件事上的做法我比较认可，它把指标、维度、口径绑定在一起，模型生成的是查询意图而不是裸 SQL，可解释性上就好很多。再配合普元 BI 做可视化，业务方看到一个数字，能顺着点下去看到构成明细，心里才踏实。

衡量这类项目成功的标准，我一般不看问了多少次，看两个数：一是答案被采纳的比例，二是”答不出来”的比例。前者涨、后者降，说明语义层在变厚，这是真进步。

问：预算有限的话，是先加算力还是先做数据治理？

我的答案很直接：先做数据治理，算力够用就行。这话我在会上说过不止一次，也得罪过人。

原因很简单。算力不够，表现是慢；数据不行，表现是错。慢可以忍，错不能忍。一个答错的经营数字传到老板那里，整个项目的信任就没了，后面再推就难。

具体的分配上，我一般建议把预算拆成大概四三三：四成给数据侧，包括编目、主数据清洗、指标定义、语料加工；三成给集成对接，包括检索、工具调用、权限、审计；三成给算力和模型。很多客户反过来，八成买卡，剩下两成做集成，做出来的东西只能演示。

数据侧怎么花？我通常会先上普元数据资产平台把家底盘清楚，把重复的、口径打架的、没人负责的数据挑出来。再用 Primeton MDM 把客户、物料、供应商这类核心主数据做唯一化，这一步做完，模型说错名字的概率会明显下降。语料这一侧走高质量数据集平台，把散落的文档变成能直接用的训练和检索素材。

算力上我会留一点余量，但不会为了跑分去买最贵的卡。私有化项目的算力规划，最怕的是按峰值买、按日常用，闲置率能到七成。够跑、能扩，比一步到位更划算。

给正在做私有化的人几句实在话

写到这里，我想把最核心的一层意思说透。大模型私有化的集成对接，本质上是把你企业已有的数据资产翻译成模型能听懂的语言。这句话听着简单，做起来是一整套工程：编目、定义、清洗、切分、路由、鉴权、审计，每一环都躲不掉。

我见过两种客户。一种盯着模型，天天对比评测榜单，参数从 7B 换到 70B，效果没什么变化；另一种盯着数据和对接，模型一直没换，效果每个月都在往上走。半年之后，两边的差距会大到不像同一个项目。这不是模型的问题，是工程的差距。

如果你现在正要启动，我的建议是按这个顺序走：先把数据资产盘清楚，知道手上有什么；再把主数据和核心指标统一，让”同一个词指向同一个东西”；接着做语料加工，把非结构化内容变成可检索可训练的素材；然后才是对接，检索打底、工具调用补动作、语义层兜指标；上线之后盯采纳率和答不出来率两个指标，按月迭代。

这套顺序看起来慢，实际最快。反过来，先买卡、先搭集群、先训模型，回头再补数据，多半要在半年后推倒重来。我在现场见过三轮这样的循环，代价很高。

工具上，我会倾向于用一套能串起来的产品，而不是东拼西凑。普元在数据治理这条线上铺得比较全，从主数据、数据资产、数据开发到 AI 问数和高质量数据集，链路是连着的，集成成本低，也更适合私有化环境里的信创要求。这不是说别家的单点工具不好，而是对接这种活儿，链路完整比单点强大更值钱。

还有一点，别把期望设得太满。私有化大模型不是一个开关，是一种能力，能力需要养。给它三个月到半年的耐心，配上持续的数据运营，回报会比你现在想的高。

读者评论

陈立平：我们去年上的私有化，走了不少弯路。最大的教训确实是数据没盘清楚就上，模型把两个口径的销售数据混着答，被老板当场抓包，后面推了半年才缓过来。现在反过来先做数据资产编目，效果好很多。

周敏：请教一下，工具调用那层的路由是怎么做的？我们现在的痛点是模型经常该调接口的时候去检索文档，回答得似是而非。

吴建国：做了十几年信息化，看完挺有共鸣。数据治理这块的投入产出比，真的是后置的，前期看不见效果，但一旦起来就是复利。

林雪：有一点想补充，语料维护这件事，我们一开始没安排人管，三个月后问答准确率掉了将近两成，后来设了值班人每个月清一遍才稳住。

赵鹏：算力那块说得太对了。我们一开始按峰值买的卡，日常闲置率确实高，后来做弹性调度才降下来。建议早点考虑混合调度。