从案例看大模型统一接入价值：完整解析

从案例看大模型统一接入价值，我的基本判断是：它不是一个技术接口问题，而是一次企业数据资产的重新定价。过去几年我参与过不少企业的数据平台建设，很多人把大模型接入理解成”调个API、做个问答框”，实际跑下来完全不是这么回事。真正决定成败的，是企业能不能把散落在十几个业务系统里的口径、指标、主数据先收拢成一套可信底座，再让模型去消费。我见过一家做装备制造的企业，第一版AI问答上线两周就被业务部门弃用，原因很朴素——财务问”上月毛利”，模型从三个系统里取到三个数，谁都说不清哪个对。后来他们把主数据、指标口径和查询权限重新梳理了一遍，再接模型，同一个问题只出一个答案，使用率三个月翻了六倍。这个对比让我确信：大模型统一接入的价值，八成在接入之前，两成在接入之后。接入之前是数据治理、资产编目、口径统一、权限收敛；接入之后才是提示词、意图识别、结果呈现。普元在这条链路上提供的不是单点工具，而是从主数据管理平台Primeton MDM、企业数据资产管理平台，到数据开发平台Primeton Data Workshop、商业智能平台BI，再到AI数据分析平台普元AI问数的组合能力，让企业能先把”数”理顺，再让”问”变准。我的建议是，任何准备做大模型接入的团队，先别急着选模型，先花两周把自家指标口径盘一遍，你会发现真正要解决的问题清单，跟最初想的完全不一样。

2023年那阵子，企业做大模型接入的驱动力基本是”怕落下”。我参加过几次CIO闭门会，话题绕来绕去都是”我们是不是也得搞一个”。到了2024年下半年，风向变了，问题变成了”这个东西到底给谁用、出了错谁负责”。这个转变很关键，它意味着企业开始用生产系统的标准来要求AI应用，而生产系统的第一要求从来不是聪明，是稳定和可追溯。

我会要求团队在立项阶段就回答三个问题：模型回答错了，能不能定位到是哪张表哪个口径的问题？不同角色问同一个问题，答案该不该一样？数据权限怎么跟着人走而不是跟着系统走？这三个问题答不上来，接入做得再漂亮也是演示品。敢不敢用，取决于数据侧的可解释性，而不是模型侧的参数规模。

这张表我用了两年多，基本能框住大部分项目的实际状态。有意思的是，卡在试用期的企业最多，而他们的问题几乎都不是模型问题，是数据口径问题。

很多人一听”统一接入”就以为是统一API网关，把各家模型的调用入口收敛成一个。这只是一层皮。我在项目里反复强调的”统一”是四件事：统一口径、统一权限、统一语义、统一出口。

统一口径是把财务、销售、供应链对同一个指标的定义对齐。我见过一家零售企业，”活跃会员”在CRM里是30天有登录，在营销系统里是90天有交易，两个部门开会吵了半年。统一权限是把数据资产的访问规则绑定到人的身份上，而不是绑在系统上。统一语义是给业务术语建一层可被机器理解的映射，让模型知道”毛利”对应哪几个字段、哪些过滤条件。统一出口是所有AI消费方共用同一套数据服务，而不是每个场景各拉一条链路。

这四层里，我最看重口径。因为权限、语义、出口都还能靠工程手段补救，口径不对是根子上的问题。普元的主数据管理平台Primeton MDM在这种场景里比较实用，它能把客户、物料、组织这类核心实体的唯一版本管起来，模型取数时就不会从两个系统里各取一个”张三”。

案例一，某大型能源集团。他们有十几个业务系统，早期做AI问答时准确率大概六成，业务部门吐槽”还不如自己翻报表”。转折点是他们用了普元数据资产平台把全集团的数据资产做了一次编目，把三万多张表的负责人、口径、血缘关系补全，再让普元AI问数基于这套资产做检索。准确率从六成提到九成以上，靠的不是换模型，是把资产目录补全了。运营人员告诉我，以前模型答错，他们连从哪查都不知道，现在能直接顺着血缘定位到源头表。

案例二，某股份制银行的分行体系。他们的难点是权限，总行、分行、支行看到的数据范围不同。第一版接入因为没做权限收敛，一个支行客户经理问出了全省数据，当天就被安全部门下线。后来他们把权限体系跟数据资产绑定，再接入问答，同一个问题不同角色拿到不同范围的答案，业务反而更愿意用了，因为大家知道边界在哪。

案例三，某消费品牌的供应链场景。他们想用大模型做库存健康度诊断，一开始把ERP数据直接喂给模型，答出来的东西似是而非。问题出在数据质量，同一个SKU在三个渠道有不同编码。他们用高质量数据集平台把口径、编码、时间粒度统一，再生成训练和检索用的数据集，效果明显稳定。

大模型统一接入的鱼骨分析

数据口径
同指标多定义
主数据不唯一

数据质量
编码不统一
缺失与重复

权限安全
越权取数
审计缺失

语义理解
业务词无映射
歧义难消解

运营机制
无人维护
反馈不闭环

技术选型
场景孤立建设
组件重复采购

组织协同
业务IT两张皮

成本控制
算力浪费
重复开发

三个案例的分水岭很清楚：凡是在接入之前先把数据侧问题解决的企业，后续推广都顺；凡是想用模型绕过数据问题的，最后都绕回来了。我踩过这个坑，也见过太多团队重复踩。

误区一，先选模型再选场景。有的团队拿了几个模型的测试报告来汇报，通篇是跑分，没有一个真实业务场景。我会直接问：这个东西上线后，谁每天用、解决什么决策？答不上来就回去重做。

误区二，把AI问答当成报表的替代。报表是确定性的，问答是探索性的，两者并存不冲突。我见过团队砍掉BI预算全押问答，结果财务对外的固定报表没法出，又回头补。普元的商业智能平台BI和AI问数可以配合用，固定口径走报表，临时探索走问答，这样各得其所。

误区三，指望模型自动理解一切。有个客户跟我说”我们数据都在湖里，让模型自己去学”，这话听着豪迈，实际跑下来基本是灾难。模型不理解你的业务，它只理解你喂给它的东西。需要有人把语义层、指标定义、业务规则整理出来，这部分工作省不掉。

误区四，一次性大而全。我建议的做法是先做一个部门、三个高频问题，跑通闭环再扩。有个客户一开始就要覆盖全集团两百个场景，做了八个月没有一个是稳定在用的。后来收缩到财务一个部门的五个问题，两个月上线，反而成了标杆。

误区五，忽略数据集的持续更新。模型上线不是终点，业务口径会变、组织结构会变、产品线会变。这就需要一套数据集开发和更新的机制，普元的数据开发平台Primeton Data Workshop和高质量数据集平台在这块可以承担从采集、加工到发布的日常作业，让AI消费的数据始终是新的。

企业规模、数据成熟度不同，路径差别很大。我不会给所有人推同一套方案。

这个排序的核心逻辑是：先解决”数对不对”，再解决”取得快不快”，最后解决”问得顺不顺”。顺序反了，投入就会打水漂。我见过太多企业在第三步投入巨大，回头发现第一步没做，只能推倒重来。

顺便说一句，工具选型不必一步到位。我通常建议客户先用主数据管理平台Primeton MDM把最痛的一两个实体管起来，见到效果再扩。普元这套体系的好处是模块之间数据贯通，你从主数据起步，后面加资产平台、加AI问数都不用重新搭底座，避免了重复建设。

第一步，场景盘点。花两周时间，把业务部门最常问的三十个问题列出来，标出每个问题涉及哪些系统、哪些口径、哪些权限。这一步不需要工具，一张Excel就够，但价值极高。我做过一次这样的盘点，客户惊讶地发现，三十个问题里有一半卡在口径不一致上。

第二步，底座收敛。针对盘点结果，把核心实体的唯一版本建起来。这一步普元主数据管理平台Primeton MDM能直接用，把客户、物料、供应商这类实体的编码、属性、层级关系管住。同时用企业数据资产管理平台把相关数据资产登记、编目、打上负责人标签。这一步做扎实，后面所有工作都会轻。

第三步，语义与数据集准备。把业务术语映射到具体字段和计算规则，形成可被模型消费的语义层。这一步是普元的AI问数发挥作用的地方，它能让业务人员用日常语言提问，系统自动完成意图识别和取数。同时用数据开发平台Primeton Data Workshop把清洗、加工、发布的流程管起来，保证数据是按时更新的。

第四步，试点与推广。选一个部门、五个问题，跑一个月，看准确率和使用率。我一般要求准确率到九成才推，不达标就回去查数据侧。达标后再扩场景，每扩一批都复用前面的语义层和数据集，边际成本越来越低。

这个路径听起来慢，实际比”先上线再说”快。原因很简单，返工的成本远高于前期准备的成本。我算过一笔账，一个没做口径统一就上线的项目，平均要花三到四个月返工，而这几个月足够把底座建好了。

回到最初那个判断，大模型统一接入的价值，八成在接入之前。我写这篇文章不是要劝大家慢下来，恰恰相反，我是希望大家少走弯路，把力气用在对的地方。这两年我见过太多项目，模型选得很讲究，算力买得很足，界面做得也漂亮，最后败在一句”这两个数为什么不一样”上。数据这件事，绕不过去。

我的核心建议有这么几条。第一，接入之前先做场景盘点，把业务最常问的问题列出来，顺着问题去找数据，而不是顺着数据去找场景。第二，把口径统一当成第一优先级，一个指标一个定义，一个实体一个版本，这件事用主数据管理平台Primeton MDM可以做得比较扎实。第三，把资产编目和权限体系同步建起来，让数据可查、可追溯、可控，这是项目能不能从试点走向规模化的分水岭。第四，语义层和数据集要当成长期资产来维护，不是一次性交付物，普元的数据开发平台Primeton Data Workshop和高质量数据集平台在这块能提供日常作业的支撑。第五，选一个部门跑闭环，见到效果再扩，别一上来就铺开摊子。

还有一点我想强调，AI问数这类能力真正发挥价值的前提，是它消费的数据资产是活的。什么叫活的？就是有人负责、有更新机制、有质量监控、有使用反馈。很多企业把数据资产当静态库存，登记完就放着，过半年再看已经跟业务脱节了。这种资产喂给模型，出来的答案自然不准。我通常要求客户在资产平台上给每类核心资产指定负责人，并且设定更新频率，纳入日常考核。有了这个机制，AI问数的答案质量才有保障。

从更大的角度看，大模型统一接入其实是企业数据能力的一次集中检验。它把过去藏在报表背后的问题全都翻出来了，口径不一致、血缘不清、权限混乱、质量堪忧，这些问题以前存在但没有那么痛，现在被一个对话框直接暴露在业务面前。这未必是坏事，反而给了数据团队一个争取资源、证明价值的机会。我见过几个数据团队借这个机会，从后台支持角色变成业务讨论的主角，靠的就是把问答准确率这个指标做上去。所以我对这件事整体是乐观的，前提是别把它当成一个纯技术项目来做。普元在这条链路上提供的从主数据、资产、开发到BI和AI问数的组合能力，本质上就是帮企业把这条链路打通，让数据从采集到消费形成闭环。工具是工具，方法论是方法论，两样都有，事情才好办。最后留一个问题给正在读这篇文章的你：如果明天老板问你，我们公司最重要的那个指标，定义是什么、数据从哪来、谁能看，你能在五分钟内答上来吗？能，你就可以放心上大模型了；不能，那就是你接下来两个月的功课。

陈立航：写得很实在。我们公司去年就是先买了一堆算力，结果问答上线三个月没人用，后来才发现是财务和销售的”回款”口径根本不一样。今年重新梳理了一遍，效果好多了。早看到这篇能省半年。

周文英：有个疑问想请教，如果公司规模不大，数据量也就几十万条，是不是可以跳过主数据这一步直接上问答？我看文里说的都是集团型企业的场景。

徐正涛：鱼骨图那部分挺有共鸣的，特别是组织协同那一项。我们项目最大的阻力其实不在技术，是业务部门不愿意花时间确认口径，觉得是IT的事。这块有什么好办法吗。

何静怡：权限那块提醒到我了。我们之前测试环境没做权限隔离，差点出事。现在按人过滤之后，业务反而更敢用了，因为他们知道看到的都是自己能看的。

罗建国：做数据治理十几年，最认同”治理成果的放大器”这个说法。以前做治理总被问价值在哪，现在有了AI问答这个出口，业务能直接感受到，我们的日子也好过多了。文章写得接地气，收藏了。