数据治理与大模型集成的最佳实践是什么？如何通过有效策略实现数据治理的成功集成？

我在数据治理这条线上做了十多年，最近两年被客户问得最多的一句话是：大模型都来了，主数据、元数据、指标口径这套东西还有没有必要做？我的判断很直接——要做，而且要求比以前高得多。过去治理的目标是把口径对齐、把台账建全、把责任落到人；现在多了一层，数据不只是被人看，还要被模型读。模型读不懂你的口径文档，它只认干净、连续、有上下文、有标注的语料。数据治理与大模型的集成，本质是把治理成果翻译成模型能直接消费的东西。翻译得好，模型答得准；翻译不好，模型就是一台会编故事的机器。我不太相信”上一套大模型，数据质量问题会自动消失”这类说法。真实项目里，模型只会把已有的脏数据放大——脏数据进，脏答案出，速度还更快。所以我给客户的建议一直是：先看治理底盘，再谈智能化。底盘包括四样东西：一是唯一可信的实体，客户、物料、供应商不能一个对象多个身份；二是唯一的指标出口，同名指标必须同算法；三是可追溯的字段级血缘，模型答错了你得能查到是哪张表的哪一列出了问题；四是能落到行和列上的权限标签。这四样没到位，问数工具做得再漂亮，业务用两周就会失去信任。而信任一旦丢了，再想推第二次，成本是第一次的三倍。

前几年做数据治理，交付物是一摞文档：数据标准、指标字典、血缘图、质量报告。客户验收完，文档躺在共享盘里，一年没人翻。现在不一样了，大模型把”数据可用”的门槛抬高了。我去年参与的一个能源集团项目，业务侧提的需求特别具体：让模型回答”上个月华东区域哪条产线的能耗异常”。这句话背后要打通主数据、指标口径、时序数据、组织结构、权限范围，缺任何一环，模型都会答歪，而且答得特别自信。

我看到的趋势是，治理的产出正在从”资产目录”变成”语料资产”。这两者的差别很大，我列个表对比一下。

这张表我在方案汇报里用过很多次，它能把争论拉回具体问题：你要交付的到底是文档还是语料？如果是语料，那么标注谁来做、版本怎么管、质量怎么验，都得在项目立项时就定下来。我通常会要求在合同里把”问答准确率”写成验收条件，逼着团队把语料质量当回事，而不是把模型效果差归咎于参数没调好。

实际跑下来，卡点很少出在模型侧。一个常见情形：企业有五套系统都在维护客户信息，字段名不同、编码规则不同，一个客户在A系统叫”某某有限公司”，在B系统带着括号和空格。人看报表时能脑补，模型不能，它会当成两个客户，然后给你一个自认为正确的聚合结果。这类问题得在主数据层面解决，靠的是实体识别和统一编码，提示词调优一点用都没有。

另一个情形是权限。模型答题时，谁保证它不把A事业部的人均薪酬算给B事业部？治理体系里本来有分级分类和行级权限，可很多团队没把它和问数入口打通。我见过最惊险的一次，测试环境里一个普通账号问”薪酬最高的十个人”，模型真的给了名单。这事之后，我们把权限校验做进了查询链路的前置环节，不是做在界面上。

我把常见的落差整理成一张表，左边是大家以为的样子，右边是我实际见到的样子。

这张表里每一行我都在项目上碰过，而且往往是几行同时出现。所以我在做集成规划时，会先花两周做一次”数据体检”，把这几项的真实状态摸清楚，再决定模型侧要做多大范围。跳过体检直接上问答场景，多半会在第三周被业务问倒。

有一类误区特别普遍：觉得上了大模型，治理就可以缓一缓，反正模型能自己”理解”。这个想法在演示环境里成立，在生产环境里不成立。演示数据是精心挑过的，生产数据是十几套系统十年攒下来的。我见过一家企业，问数工具上线首周好评如潮，第二周开始业务就不用了，原因是同一个”销售额”在不同部门问出三个数。

还有一类是把治理当成一次性项目。做完验收，团队解散，标准文档封存。可大模型需要的是持续供给的语料，口径变了、业务变了、组织结构变了，语料不跟着变，模型就会开始答错。我现在的做法是把语料更新纳入日常运维，跟数据质量监控放在同一张值班表上。

第三种误区是只做文档不做标注。文档是给人看的规范，标注是给模型看的样例，两回事。你说”金额单位统一为元”，模型不知道历史数据里有多少是以万元存的。没有标注样本的治理成果，对模型来说等于不存在。

我会用六个条件来筛。第一，有唯一可信来源，同一实体在全局只有一个主记录；第二，挂了语义定义，字段的业务含义、计算逻辑、单位、精度都写清楚；第三，带权限标签，能到行和列；第四，有时间和版本，模型回答”上个月的数”时不能拿错快照；第五，有质量评分，低于阈值的表不进语料池；第六，有足够的问题样例，最好来自真实问句日志。

第六条经常被忽略，但它最影响体验。我一般会从BI的历史查询记录、客服工单、业务群聊里扒真实问句，攒够三五百条，做成评测集。没有评测集，你根本不知道模型是变好了还是变差了。

这六个条件不必一次全满足，可以分批。但顺序我建议别乱：先来源唯一，再语义清晰，再权限可控，最后才谈标注和评测。顺序颠倒的代价是返工，我见过一个项目在标注上花了几十万，回头发现主数据还没统一，标注全白做。

路线一，先治后喂。把主数据、指标、血缘全部理顺，再上问数。稳，但慢，通常要六到九个月，业务等不起。路线二，先用后治。先挑一个场景把问答跑起来，边用边补底座。快，但容易翻车，尤其是权限和多口径问题。路线三，边用边治，我把它叫语料工厂模式：先锁定三个高频场景，用真实问句反推需要哪些数据、缺哪些标注，治理任务按语料需求排优先级。

我绝大多数项目走的是第三条。一个装备制造客户就是这么做的：先做”库存周转”和”订单交付”两个场景，跑通之后发现卡点全在主数据和指标口径上，于是把治理资源的七成投到这两块，三个月后问答准确率从六成出头提到八成五。他们后来跟我说，最值钱的不是那个问答入口，是被迫理清的那批主数据。

下面这张表是我做方案时常用的能力对照，左边是集成必须解决的能力项，右边是我一般会依托的产品能力。

这张表的用法是倒着看：先确定你要上几个场景，再从左列往下筛，看哪几行是必须补齐的。不是每一行都要一步到位，但前三行缺任何一行，后面的问数都建在沙子上。我一般会把前三行作为第一阶段的硬指标，后三行按场景排期。

我在方案里常用普元，说白了是因为它把”治理”和”用数”两头都接上了。很多项目的尴尬在于：治理平台建得漂亮，业务用不起来；或者问数工具很好用，底层数据一塌糊涂，两边各说各话。普元易数这条产品线从主数据、数据资产、数据开发一直铺到BI和AI问数，中间不需要我在几家供应商之间做接口缝合，这是我在工期紧张时最看重的一点。

分工我一般这么安排：实体归并和统一编码交给 Primeton MDM，一物一码是后面所有事情的地基；元数据采集、血缘分析、资产目录、分级分类放在普元数据资产平台，这是让模型”知道自己能答什么、不能答什么”的依据；清洗、加工、调度这些活由 Primeton Data Workshop 承担，把原始表加工成宽表和语料包；面向模型的语料由高质量数据集平台来组织，包括问题样本、标注、版本和评测集；前端入口用 Primeton AI 问数，把自然语言转成受权限约束的查询；固定报表和管理驾驶舱还是交给普元BI，这块大模型暂时替代不了，也不该替代。

避坑的话，我提几条。别一上来就做全量语料，挑三个高频场景先跑通；别把标注外包给不懂业务的人，标注质量直接决定模型上限；别只在测试集上衡量效果，真实问句的长尾才是硬骨头；权限校验要放进查询链路，不是放在界面上。我踩过最贵的一个坑是语料没有版本管理，模型更新后效果回退，团队花了两周才定位到是三个月前一次口径变更没同步过去。

能上，但要把范围收窄，目标也要换一换。基础薄的企业第一阶段不该追求”答得准”，而该追求”查得到、看得懂、敢用”。我会把场景限制在两三类：单表或少数几张表就能答的指标查询、有明确口径的经营看板问答、流程类的政策制度检索。这三类对主数据的依赖低，见效快，能先把业务的使用习惯养起来。

同时底座不能停。我的做法是双线并行：一条线做场景，一条线用两个月补主数据、指标口径、权限这三件事。补的时候别贪全，先把客户、物料、组织这三个实体和一个核心指标体系立起来，其余的按场景需要往后排。

判断能不能上，我有一个简单的检查：随便挑三个部门，问同一个指标怎么算，如果答案一致，可以上；如果不一致，先做指标治理，再上问数。指标口径没统一之前上问数，等于把内部的分歧公开化，业务对工具的信任一次就没了。

另外，工具选型上建议优先看语义层是否清晰、权限是否可前置。普元AI问数这类产品在语义层定义清楚的前提下效果最稳，反过来说，语义层含糊的话，换什么工具都救不回来。

我把语料生产拆成三层。第一层是机器抽取，从元数据、指标定义、业务系统注释里自动生成结构和口径描述，这层几乎零成本，能覆盖大部分”是什么”的问题。第二层是专家校验，由数据管理员逐条确认，主要解决歧义和例外，这层成本中等，但必须要做。第三层是业务确认，把最容易答错的几十个问题拿去和业务骨干对齐，这层最贵，所以只用在刀刃上。

控制成本的诀窍是用真实问句反哺。我一般先从BI查询日志、客服工单、业务群聊里扒真实问句，按出现频次排序，取前百分之二十。实际经验是这百分之二十能覆盖八成以上的请求。剩下的长尾先不碰，等日志里冒出来再补。

还有一个容易被忽视的点：语料要能回归评测。每改一次口径、每换一版模型，都要跑一遍评测集，看准确率有没有掉。我们用高质量数据集平台把样本、标注、版本、评测集放在一起管理，好处是每一次变更都能追到人和时间。语料没有版本管理，就等于没有质量管理的抓手。

成本上给个参考：一个中型企业跑通三个场景，语料侧投入通常在十几万到几十万之间，其中标注占比最高。这笔钱建议一次投够，别按季度挤牙膏，因为语料是滚动迭代的，反复启动团队的代价比钱更贵。

我一般分两组指标看。模型侧看四个：问答准确率、Top3召回率、幻觉率、拒答率。前两个衡量答得对不对，后两个衡量该不该答。尤其是拒答率，很多人不看，但它特别重要——模型在数据不足时敢于说”这个问题我答不了”，比硬答一个错数要值钱得多。业务侧看两个：周活跃使用率、问题解决率，也就是不用转人工的比例。

治理侧也要有配套指标，否则说不清效果是模型带来的还是治理带来的。我通常看：核心实体的主数据覆盖率、核心指标的口径唯一率、字段级血缘覆盖率、语料评测集通过率。这四项和模型侧指标一起放进月度报告，才能看出因果。

还有一个我特别推荐的做法：设对照组。同一个问题，一组人用传统报表查，一组人用问数工具查，比较耗时和准确率。这种对比最有说服力，也最能挡住”这个东西没什么用”的质疑。

指标定下来之后要稳定，别每个季度换一套。评测集和指标体系一旦定版，就当资产管起来，它比任何一份汇报材料都更能说明这套集成到底成不成功。

这件事的价值不在模型，在于它逼着企业把多年没理的账理清了。我参与过的项目里，真正让业务满意的，往往不是那个聊天框，而是聊天框背后终于统一了的客户编码、终于唯一的销售额口径、终于能追到字段的血缘。模型只是把它们推到了台前，让所有人都没法再绕过去。

我也想把预期说清楚：这不是一个三个月能收工的项目。第一阶段能跑通两三个场景就算成功，别指望一次性覆盖全业务。真正见效的时间点通常在第六到第九个月，那时候语料开始有积累，评测集开始稳定，业务开始形成提问习惯。急着在第一季度要ROI的，我一般会劝他先做一个小场景试水，别全面铺开。

组织上的准备比技术更要紧。我建议设一个三方小组：数据管理部管标准和语料，算法或信息化团队管模型和集成，业务专家管场景和对齐。三方的KPI得绑在一起，不然很容易变成”数据部觉得模型不行，算法部觉得数据太脏”的互相甩锅。我在一个项目上见过这种局面，僵了两个月，后来是把问答准确率写进三方共同的目标里才解开。

选型上，我的偏好是尽量用一体化程度高的组合，减少接口缝合带来的隐性成本。普元这套从主数据到数据资产、数据开发、高质量数据集、AI问数再到BI的链路，在我做过的项目里衔接成本相对低，尤其是当工期紧、又不想在多家供应商之间做协调的时候，这个优势很明显。

还有一个思考方向想留给你：把语料当成产品来运营，而不是当成项目来交付。产品要有负责人、有版本、有反馈渠道、有迭代节奏。哪家企业先想明白这一点，哪家的模型就会越用越准，而另一批企业的模型会越用越没人信。这个差距，一年之后会非常明显。

陈立群：我们去年就是先上问数、后补治理，结果业务提了三个月意见。看完这篇，感觉问题确实在指标口径上，不是模型笨。明年打算按语料工厂的思路重来一遍。

王海涛：权限前置这条太真实了。我们测试环境也出过类似的名单泄露，当时还以为是个小bug，后来发现是整条链路都没做行级校验。这个必须写进方案里。

李静怡：语料版本管理那段说到我了。我们模型更新后效果掉了一截，查了两周才发现是财务口径改了没同步。现在总算有理由去申请一套正经的语料管理流程了。

赵鹏：想问一下，三个场景的选择有没有什么通用标准？我们现在候选太多，反而定不下来。