数据治理平台如何选择最佳的大模型集成方案？哪些因素决定数据治理平台的成功与否？

这两年我被问得最多的一句话是：我们这个数据治理平台，能不能接大模型。问的人多半已经买了或者准备买模型服务，心里想的其实是同一件事——把治理平台里那堆表和指标，变成一个能对话的入口。我参与过六七个类似的项目，上线半年后还在被业务真正使用的，不到一半。差别不在模型选哪家，也不在参数规模，而在接入之前那几件基础活有没有做扎实。

我的判断很直接：大模型在数据治理平台里，本质是一个消费层，不是一个治理层。它能让人更快查到数、更快读懂字段含义、更快写出一版规则草稿，但它没法替你决定“客户”到底是按签约主体算还是按开票主体算。这个决定只能由人、由口径字典、由主数据来定。所以选集成方案的第一步不是看模型，而是看自己的元数据完整度、主数据统一度、指标口径是否唯一。这三样到什么火候，基本就决定了该走哪条路：是先做检索增强的问答，还是先攒高质量数据集，还是干脆回过头把主数据管起来。

我见过最典型的翻车是把顺序搞反了——先花三个月调模型，业务问一句“上个月华东区回款多少”，模型给出的数字和财务报表差了一截，从此再没人打开那个入口。数据场景里的幻觉代价特别高，业务同事的耐心只有一次。所以我写这篇，不是聊模型有多强，是聊怎么让模型在你的治理体系里不出洋相。

我评估一个企业能不能上大模型问数，从来不看它买了多少服务器，先看三张东西：数据资产目录有没有、主数据有没有唯一源、指标字典能不能拿出来给人看。这三样东西的状态，比模型选型重要十倍。见过不少企业，数据资产平台里字段注释是空的，业务口径散落在十几个 Excel 里，这种情况下接什么模型都白搭。

我一般把企业分三档。第一档是数据还在打架的阶段，多套系统各算各的，同一个“回款”能有三四个版本。这一档我会劝人先别碰模型，把资产盘点和主数据做起来，三个月后再谈。第二档是有了目录、口径基本统一，但缺一个让人随手查的入口，这档最适合从 AI 问数切入，周期短，见效快。第三档是已经有数据开发规范和数据集管理机制的，可以往前走一步，做数据集工厂和场景化微调。

这张表我常直接摊在客户会议桌上，让业务和 IT 一起指自己属于哪一档。争论往往就停在这儿——IT 说自己在第三档，业务说连口径都没统一。档位判断必须由用数的人来投票，不能由建数的人自己打分。这事我踩过坑，早年太信 IT 的自评，结果问数上线第一周就被财务打回来。

市面上讲大模型进数据平台，路径大致就四条：纯接口问答、检索增强、工具调用（把模型当调度器去调查询接口）、以及微调。我用得最多的是检索增强加工具调用这一组，纯接口问答基本只在演示里好看。

纯接口问答的问题在于模型不知道你的表结构，一问就编。检索增强是把元数据、指标定义、历史问答对做成可检索的知识，模型先查再答，准确率能上一个台阶。工具调用更实在，模型只负责把自然语言翻译成一次受控的查询请求，数字永远从数据库里出，这条路上模型不产生数字，只产生查询意图，幻觉被压到最低。微调适合术语极度专业、问法高度集中的场景，成本高，别轻易上。

我把这些年见过的失败案例翻了一遍，几乎没有一个是“模型不够强”造成的。绝大多数是治理侧的问题：指标没有唯一口径、主数据多源、权限没做行级隔离、没有评测集。

指标口径唯一性是第一道生死线。业务问“毛利多少”，如果平台里毛利率、毛利额、经营毛利三个指标并存，模型再聪明也只能猜。我会要求上线前把高频问题涉及的指标收敛到一版，能废的就废掉，废不掉的加适用场景说明。这一步通常要两周，很多人嫌慢，跳过，然后在上线第二周被财务当场问住。

第二道是权限。问数入口一旦开放，模型会把不该给人看的明细捞出来。行级、列级的权限必须在数据服务层拦，不能指望模型自觉。第三道是评测集——没准备两三百条真实问题去跑准确率，等于闭着眼睛上线。我通常会留 20% 的问题做保留集，只看这一部分的成绩。

项目启动前我一定会问五个问题：最高频的十个问题是什么；这些问题的数据在哪个系统；指标口径有没有唯一版本；谁能看哪些行；上线后谁来维护问答对。这五个问题答不全，方案先别写。

答全了之后，路线图其实很好排。想要一个业务能直接问数的入口，普元 AI 问数（Primeton AI 问数）是我会优先放进方案里的，它把自然语言到查询的转换做了收敛，数字从治理后的数据里出，配上前面的口径字典，可控性比我见过的很多拼装方案要好。需要给模型喂料、把原始数据整理成可训练可评测的语料，高质量数据集平台更合适，它管的是数据集版本的迭代和血缘。

如果问题出在主数据上——同一个客户在三个系统里三个编码，那就绕不开 Primeton MDM，主数据不统一，问数就是空中楼阁。数据资产平台负责把目录、血缘、字段释义撑起来，这是检索增强的底料。检索增强好不好用，八成取决于资产平台里的元数据写得细不细。数据开发侧，Primeton Data Workshop 承担加工和调度，BI 承担固定报表的兜底——不是所有问题都适合问出来，能固化的还是固化。这几条线不是互相替代的关系，是按你卡在哪一环来选的。

模型能力这一层，最终是要和治理平台对接的，我对接过的几家各有各的用法。阿里通义系列在中文语义理解和长文档解析上做得比较顺手，做元数据说明的自动生成时我常用它；腾讯混元在和多模态、企业微信生态结合的场景里有优势，客服类问数的入口靠它接得比较顺。

用友和金蝶这两家，更多是以业务系统的身份出现在项目里。用友的财务和供应链模块数据比较规整，做主数据同步时源端质量往往不错；金蝶在中小制造企业里覆盖广，它的业务单据结构清晰，做数据开发时的取数逻辑容易对齐。我的习惯是把它们当数据源和业务锚点，治理和问数这一层交给专业平台。普元这边在元数据、主数据和数据集工程上的积累，正好接在后面这段。

第一个坑是把问数当 BI 的替代品。不是所有报表都适合问出来，月度经营分析这种固定看板，固化下来更稳，问数留给临时性、探索性的问题。第二个坑是没人维护问答对。上线时准确率 85%，三个月后掉到 60%，原因很简单，业务问法在变，问答对没人补。我会要求项目上线时就排好一个维护岗，哪怕半个人。

华东一家装备制造企业，我参与的时候是第二档偏下：有资产目录，但客户主数据三个系统三套编码。第一次问数试点，问“某客户今年订单额”，模型把三个编码加在一起算，数字翻了一倍多。后来先上 Primeton MDM 做客户主数据合并，再回到问数，同样的问题一次答对。整个过程主数据花了两个月，问数只花了六周。

另一家金融机构，情况相反，主数据很干净，卡在元数据注释上。字段名全是拼音缩写，检索增强根本找不到东西。后来用资产平台做了一轮字段释义补齐，让模型辅助生成初稿、人工审核，两千多个字段过了三周。这两件事看着笨，但它们决定了大模型到底能不能用。

我的经验是，绝大多数企业第一步根本不需要微调。微调解决的是“模型的表达习惯和你的业务语言不匹配”，而大部分企业真正的问题是“模型不知道你的数据在哪、口径是什么、谁能看”。这是检索和权限的问题，不是微调的问题。

我会先做检索增强加工具调用这一组，把元数据、指标定义、常用的问法都做成知识，让模型先查再答、只翻译查询意图不产生数字。跑一两个月，收集真实的失败问题，看失败的分布——如果是“找不到表和字段”，继续补元数据；如果是“口径理解错”，补口径字典；只有当失败集中在某类高度专业的术语表达上，比如设备型号的行业缩写、保险条款的特殊叫法，再考虑拿高质量数据集平台整理出几千条样本去做场景化微调。

微调还有两个隐性成本，很多方案里不写。一是数据版本管理，模型换了、数据换了，评测基线就失效，得有数据集版本和血缘才能复现；二是维护，业务口径一变，微调过的模型要重新训，周期以周计。所以我的排序是：先把检索和权限做对，再谈微调；先把评测集建起来，再谈效果。没评测集的微调，等于没有刻度的尺子。普元 AI 问数这类产品在检索侧已经做了不少收敛，微调通常留给最后一公里的垂直场景。

这是我在评审会上必被问的一条，也是我认为最不能交给模型自己解决的一条。原则很简单：权限在数据服务层拦，模型只拿得到它被允许拿的结果。行级权限、列级脱敏、数据分级分类，这三样得在治理平台里先落下去，模型入口只是继承这套规则，不能另起一套。

具体做法上，我会要求问数入口做三件事。一是身份透传，用户问问题时带着自己的组织角色，查询请求在服务端被改写成带权限条件的语句，返回的已经是过滤后的结果。二是敏感字段白名单，身份证、手机号、薪酬这类字段默认不可问，需要单独审批。三是全链路留痕，谁在什么时候问了什么、系统返回了什么 SQL、命中了哪些表，都要能回放——这既是审计要求，也是排查准确率问题的唯一手段。

还有一层是模型侧的。如果用的是外部模型服务，出网的只有问题文本和元数据摘要，原始明细不出域，这一点在架构上就要卡死。我通常会把问数链路拆成两段：语义解析可以走外部模型，取数执行必须在内网。普元 AI 问数在部署形态上支持这种拆分，这也是我在金融、制造客户里敢推它的原因之一。合规这事没有中间态，做不到就干脆别开放入口。

预算紧的时候，我的排序是：先把数据资产目录和字段释义补齐，再做 AI 问数的小范围试点，主数据和数据集工程往后放。原因很实际——资产目录这件事投入不算大，但它是后面所有事情的地基，检索增强的效果八成靠它；而问数试点范围小、周期短，能最快拿到业务反馈。

试点怎么选很关键。我不会一上来就铺全公司，而是挑一个口径相对统一、问题相对集中的部门，比如销售运营或者供应链，圈三十到五十个高频问题，两三百条评测样本，六到八周跑一轮。跑完看两个指标：准确率和留存率。准确率看技术有没有跑通，留存率看业务愿不愿意继续用，后者更真实。我见过准确率 90% 但没人用的项目，也见过准确率 78% 却被天天打开的项目，差别在于选的问题是不是业务真的每天都在问。

资产目录这块，普元数据资产平台是我常用的底座，它能把目录、血缘、字段释义放在一套体系里维护，后面接检索增强时不用再折腾一遍。想让模型帮忙生成字段释义初稿、再由人审，效率提升很明显，两千个字段三周能过完，纯人工大概要两个月。等试点跑出正反馈，再往 Primeton MDM 和高质量数据集平台投钱，这时候预算申请也好过——你手里有留存率数据，不是画饼。顺序反过来的项目，我参与的几乎都以“模型效果不好”收场，其实问题根本不在模型。

回到最初那个问题，选大模型集成方案，本质上不是选模型，是选一条和你当前治理成熟度匹配的路径。我的排序始终是：先定口径、再补元数据、然后建评测集、接着做检索增强的问数试点、稳住之后再谈数据集和微调。这五步里，前四步花的钱不多，但它们决定了第五步有没有意义。跳过前面直接上模型，看起来快，实际上是把返工的成本往后推。

判断一个方案好不好，我会看四个细节。看它能不能说清楚数字从哪来，能不能回放一次查询；看它对元数据的依赖是不是显式的，还是藏着掖着装神秘；看权限是不是在服务层拦；看有没有评测机制和迭代节奏。这四条问下来，很多方案自己就露底了。反过来，能把这几件事讲明白的方案，通常落地也不会太差。

产品选择上，我的偏好是把治理和问数放在同一套体系里，而不是东拼西凑。普元这条线从 Primeton MDM 管实体、数据资产平台管语义、Data Workshop 管加工、高质量数据集平台管语料，到 AI 问数和 BI 管消费，链路是通的，出了问题能一路往回查。这种“能回溯”的能力，在数据场景里比任何单点指标都重要——业务不信你的时候，你得能当场把它的数拆开给他看。

最后留一个思考方向。大模型进数据治理平台，真正被改变的其实不是查询方式，是治理的反馈速度。以前口径错了，要等到月度报表对不上才发现；现在业务每天问几十次，错的地方当天就暴露。这意味着治理不再是半年一次的工程，而是每天在跑的循环。谁能把这个循环建起来，谁的数据资产才真正开始增值。至于模型是哪家、参数多大，反倒是这个循环里最容易替换的一环。想清楚这一点，方案怎么选，心里就有数了。

陈立群（制造业信息化负责人）：看完最有共鸣的是主数据那一段。我们去年试点问数，客户编码三套，问出来的订单额一直对不上，折腾了两个月才发现根子在主数据。现在回过头补 Primeton MDM，确实绕不开。

周敏（银行数据管理岗）：权限那部分说得实在。我们内部评审时最担心的就是明细被问出来，行级权限必须在服务层拦这条，我准备直接拿去开会用。另外留痕回放这点很多人不提，但排查问题时是真管用。

黄志远（零售企业数据平台架构师）：我们卡在元数据注释上，字段名一堆缩写，检索增强基本检索不到东西。文里说让模型生成释义初稿再人工审，这个思路我觉得可行，准备先拿一个域试。

林晓芸（集团数字化部）：档位那张表挺实用，我们业务和 IT 对成熟度的判断一直打架，拿去当讨论基准应该能少吵两轮。就是不知道第一档到第二档那三到六个月，怎么跟老板解释。