导语一家企业完成了持续多年的数据治理建设。核心业务系统已经接入数据平台数据标准、元数据、主数据和质量规则陆续建立主题库和指标体系也开始稳定运行。过去分散在不同部门和系统中的数据已经可以被统一查询、关联和共享。按照传统数据治理项目的评价方式这是一项较为成熟的建设成果。当企业准备建设行业大模型、知识问答和业务智能体时新的问题却很快出现。数据部门认为核心数据已经完成汇聚主要字段的完整率、一致率和规范率也达到了项目要求。算法团队拿到这些数据以后却发现很难直接构造训练样本。结构化数据中有大量业务记录却缺少与目标任务对应的标签、判断依据和过程反馈。制度文档虽然已经统一归档却没有被组织成能够支撑复杂问答的知识单元。历史数据数量庞大但哪些代表典型场景哪些属于异常边界哪些可以用于训练哪些必须独立保留用于评测也没有明确答案。数据部门完成了治理工作算法团队却无法直接启动模型训练。双方都完成了各自职责人工智能应用仍然没有真正获得可用的数据基础。问题并不在于传统数据治理没有价值而在于以“数据已经完成治理”作为项目完成标准已经无法覆盖高质量数据集建设的全部要求。数据治理完成不等于数据集就绪。数据治理完成说明数据更加可信、规范和可管理。数据集就绪则意味着这些数据已经围绕明确任务完成重新组织能够被模型训练、检索、评测和调用并且具有清晰的适用范围和验证证据。治理后的可信数据资源与面向模型任务的数据集产品之间还存在一次任务化转换。真正值得继续追问的是当建设对象发生变化以后项目为什么也不能继续沿用原来的建设逻辑。传统治理成果与面向任务的数据集之间仍隔着任务定义、样本组织和模型验证三个环节如图1所示。图1 数据治理完成不等于数据集就绪一、高质量数据集建设不是数据治理项目增加几个新模块面对高质量数据集建设不少项目首先想到的是在现有数据治理体系上增加一些人工智能相关功能。原有平台缺少标注能力就增加标注模块。文档尚未向量化就增加解析、切分和向量入库能力。数据集需要持续更新就增加版本管理、发布和运营功能。这些能力都可能需要但它们并不能自动完成从传统数据治理项目到高质量数据集项目的转换。传统数据治理项目通常围绕数据标准、元数据、主数据、质量规则、主题库、指标体系和数据服务展开。它所形成的核心成果是可信、规范、可发现和可复用的数据资源及其管理能力。高质量数据集项目则要进一步形成面向明确任务的数据产品。这个数据产品可能是预训练语料、指令微调样本、知识检索数据、预测样本、偏好数据、智能体任务轨迹也可能是独立的验证集和测试集。不同数据集形态差异很大但都必须回答几个共同问题它服务什么任务模型怎样使用它基本样本单位是什么适用范围在哪里又通过什么方式证明它能够支撑目标任务。因此高质量数据集建设并不是把已有数据治理工作做得更细也不是在传统数据平台上增加若干人工智能模块。真正发生变化的是项目中心。传统数据治理项目的中心是可信数据资源高质量数据集项目的中心则进一步延伸为面向任务的数据产品。数据标准、质量规则、主题库和数据平台仍然重要但它们在新项目中更多承担可信基础和生产支撑作用不能代替核心数据集产品本身。一个项目可以建成完整的数据集管理平台也可以形成大量治理后的主题数据。如果项目仍然不能说明最终形成了哪一类数据集、服务什么任务、由哪些样本组成、如何进入模型那么支撑能力再完善也不能说明数据集已经就绪。二、项目起点不能只从“拥有什么数据”出发传统数据治理通常从数据现状盘点开始。企业有哪些系统系统中有哪些表和字段哪些编码需要统一哪些质量问题需要整改哪些数据应当进入主题库这些问题共同决定了治理范围。高质量数据集项目仍然需要盘点数据但盘点的出发点发生了变化。项目首先要回答的不再只是企业拥有什么数据而是模型需要完成什么任务。同样是一批制度文件如果目标只是帮助用户检索相关条款项目重点可能是文件版本、条款切分、语义索引和引用定位。如果目标是回答复杂业务问题就需要进一步组织问题、答案、适用条件、冲突规则和证据来源。如果目标是辅助审批还要把制度要求与业务材料、历史结论、人工判断过程和修正结果联系起来。数据来源可能相同最终形成的数据产品却完全不同。因此高质量数据集建设不能先确定“建设多少套数据集”再从现有系统中寻找可以加工的内容。也不能因为某一类文档数量最多、某一类数据最容易获取就自然把它确定为项目重点。一旦按照这种方式推进项目很容易从“模型完成任务需要什么数据”滑向“企业现有数据能够加工成什么成果”。高质量数据集项目中的数据盘点需要由业务问题和模型任务反向约束。业务场景说明为什么建设模型任务说明数据将被怎样使用数据需求则进一步明确需要哪些内容、采用什么结构、覆盖哪些场景和边界。这并不意味着项目可以脱离现有数据条件单纯从理想任务出发设计数据集。现实中任务需求、数据可得性和模型能力需要不断校准。有些理想场景会因为关键过程数据长期缺失而暂时无法实施有些原本被忽视的数据则可能在模型试验中表现出新的价值。字段质量达标只能说明数据本身可靠任务是否成立还要经过任务定义、样本组织和验证评估如图2所示。图2 字段质量达标以后还要保证任务成立因此高质量数据集项目的范围不是在项目开始时一次性冻结的而是在任务目标、数据基础和验证结果之间逐步稳定下来的。这也决定了它不能完全按照传统数据治理项目中“先确定范围再批量治理”的方式推进。三、项目里程碑必须重新设计高质量数据集建设与传统数据治理项目最明显的差异不是增加了多少新技术而是项目的推进节奏发生了变化。传统数据治理项目通常以标准发布、数据接入、质量整改、主题库上线和数据服务发布作为重要里程碑。这些里程碑能够判断数据治理工作是否按计划完成却不足以判断一套数据集是否适合进入规模化生产。因为一批数据是否真正适合模型使用往往无法仅靠数据质量检查和专家审阅得出结论。数据可以没有明显缺失标注人员之间的一致率也可以很高但模型训练后仍然可能没有改善。原因可能是样本过于简单没有覆盖真实任务也可能是数据分布与业务环境不一致还可能是问题表达高度重复模型只是记住了少量固定模式。还有一些问题只有当数据进入模型以后才会暴露。例如一个风险识别数据集可能字段完整、标签清楚模型测试准确率也很高。但进一步检查后发现模型输入中混入了风险事件发生以后才产生的处置结果。模型学到的不是如何提前识别风险而是如何读取事后结论。数据正确不等于样本正确。样本正确也不等于任务设计正确。因此高质量数据集项目不能先生产十万条、百万条样本再把全部数据交给算法团队进行最终验证。它需要重新设置一组面向任务的数据集里程碑任务可执行、样本可验证、规则可规模化、数据集可发布、效果可复现。其中最关键的变化是小样本验证不是规模生产后的抽检而是规模生产前的必要门槛。项目应先用小规模样本验证任务定义、样本结构、标签规则和评价方式再决定是否扩大生产规模如图3所示。图3 小样本验证是规模化生产前的门槛如果没有经过小样本试制和模型验证就直接进入大规模标注和数据生产项目放大的可能不是数据价值而是任务定义、标签规则和样本结构中的错误。传统治理可以根据已经明确的数据标准批量开展质量整改高质量数据集建设则需要先通过模型和任务验证逐步发现什么样的数据规则才真正有效。四、业务、数据和算法不能再只是前后交接传统数据治理项目同样需要多部门参与。业务部门负责解释数据含义和业务口径数据团队负责标准、模型和质量治理技术团队负责系统接入和平台实施。虽然各方需要不断沟通但总体上仍然可以按照相对清晰的专业工序进行分工。高质量数据集项目中的协作关系更加紧密。业务专家不仅要解释字段是什么意思还要定义真实任务中如何作出判断哪些条件会改变结论哪些情况属于例外哪些问题本身就不应给出确定答案。数据团队不仅要保证数据来源可信、结构规范还要把业务判断转化为可以生产、追溯和迭代的样本结构并管理数据划分、生成规则和版本变化。算法团队也不能等数据全部完成后再被动接收而需要在任务拆解、样本试制和规则调整阶段参与判断。模型是否能够使用这些数据错误究竟来自模型能力还是来自数据覆盖也需要算法团队尽早参与分析。三类团队不再只是前后交接而是围绕同一个数据集产品共同定义。业务部门只提供一批历史材料并不等于已经定义了模型任务。数据团队完成清洗和标注也不等于样本一定适合模型。算法团队训练出一个结果也不能单独说明数据集已经达到发布要求。如果项目仍然按照传统工序分段交付就容易出现一种典型状态业务部门认为材料已经提供数据团队认为数据已经完成算法团队则认为数据不可用。每个环节都完成了自己的工作却没有任何主体对数据集整体有效性负责。因此高质量数据集项目需要同时管理数据责任、任务责任和有效性责任。这些责任可以由现有项目负责人、数据产品负责人或者跨部门工作组承担不一定必须新增一个岗位。但项目不能只对局部交付进行分工而没有主体维护业务任务、数据产品和模型效果之间的完整关系。五、模型不仅使用数据也会反向发现治理问题传统数据建设往往被理解为一条单向链路源系统产生数据数据治理提升质量治理后的数据再向业务应用提供服务。在高质量数据集项目中这条链路开始转变为双向闭环。业务场景提出任务传统数据治理提供可信数据资源数据集工程将资源组织成任务样本模型验证则暴露数据覆盖、规则和结构中的问题。这些问题还会继续返回样本生产、数据标准甚至源业务系统。模型总是在某类条件下回答错误可能说明数据集中缺少相应场景。模型无法区分两个业务概念可能说明不同系统对同一概念的定义并不一致。模型引用了已经失效的制度条款可能说明文档版本和生效时间没有得到有效管理。模型测试效果异常优秀也可能不是数据质量极高而是训练数据与评测数据发生交叉或者样本中混入了结果字段。模型不仅是数据的使用者也开始成为数据治理问题的发现者。高质量数据集项目通过模型错误分析将问题返回样本规则、数据标准和源系统采集形成任务驱动、反馈回流的治理闭环如图4所示。图4 模型不仅使用数据也会反向发现治理问题传统数据治理没有被替代而是获得了更加具体的任务反馈。模型应用也不再只是治理成果的消费者而成为检验数据治理是否真正支撑业务目标的新机制。六、项目交付的不是一堆成果而是一套数据产品体系高质量数据集项目通常会形成多种交付物。数据标准、元数据、质量规则、治理后的主题数据、标注规范、加工流程、管理平台、训练数据、评测数据和验证报告都可能出现在同一个项目中。这些成果同时存在并不意味着项目范围失控。真正需要警惕的是它们被不加区分地并列交付却没有说明彼此之间的关系。高质量数据集项目必须有一个明确中心那就是面向具体任务的数据集产品。围绕这一核心产品项目还需要形成可信数据基础证明数据来自哪里经过哪些治理是否具有明确权属和合规依据。项目还需要形成生产与管理能力支持数据清洗、标注、版本、权限、发布和反馈。这些能力保证数据集能够持续生产和迭代但它们属于支撑体系不能代替数据集内容。如果项目只建成了平台却没有明确平台中管理的具体数据集支撑能力就取代了项目中心。如果项目交付了大量标注数据却无法说明样本结构与目标任务的关系标注数量就取代了数据产品价值。如果项目只完成一次模型训练却没有保留数据来源、生成规则、数据版本和适用边界一次实验结果也无法沉淀为可以持续使用的数据集。所以高质量数据集项目不能只列出一张交付清单还要说明不同成果之间的依赖关系哪些成果提供可信基础哪些规则把数据资源转化为样本哪些平台支持持续管理哪一个数据集产品最终进入模型又通过什么证据证明它已经达到发布条件。七、验收不能只证明数据做完了传统数据治理项目通常验收数据接入范围、标准建设数量、目录覆盖程度、质量规则数量、问题整改率、字段完整率和平台功能实现情况。这些指标能够证明约定的数据治理工作已经完成。高质量数据集项目仍然需要这些基础指标但不能止步于此。数据集是否具有明确任务和适用范围样本结构是否符合模型使用方式训练数据与独立评测数据是否有效隔离数据分布是否覆盖真实场景版本和生成过程是否能够追溯都应当进入验收范围。除此之外项目还需要形成两类相互关联的证据。第一类是数据证据它证明数据来源可信、内容准确、结构合理、版本清晰并满足权属、安全和合规要求。第二类是任务证据它证明数据集与目标任务相适配并且在明确的模型、基线、实验和业务条件下形成了可复现的有效性结果。数据证据回答“这批数据是否可信”任务证据回答“这批数据是否值得模型使用”。任务证据不能简单等同于展示一个模型准确率。模型效果还会受到模型架构、训练方法、参数设置和推理策略等多种因素影响。项目需要记录模型版本、训练方法、基线数据、评价指标和实验条件通过对照实验尽可能识别数据变化对任务结果产生的影响。高质量数据集项目需要依次通过数据证据和任务证据两道验收门槛缺一不可如图5所示。图5 高质量数据集项目的双证据验收检索类项目可以关注召回率、引用准确率和问题覆盖程度。问答类项目可以关注回答正确性、证据一致性和拒答边界。预测类项目可以关注识别能力、稳定性和业务收益。智能体项目则可以关注任务完成率、工具调用正确率、过程合规和执行安全性。不同项目的指标可以不同但验收逻辑应当一致不仅要证明数据已经被生产和管理还要证明它与目标任务相适配。项目通过验收也不意味着数据集从此固定不变。业务规则会调整数据分布会发生变化模型版本也会持续升级。首次验收只能证明当前数据集版本在当前条件下成立后续仍然需要通过反馈、评测和版本更新重新确认其适用性。高质量数据集项目的首次交付不是建设终点而是第一个经过验证的数据集版本。结语高质量数据集建设不能照搬传统数据治理逻辑不是因为数据治理已经过时也不是因为数据标准、元数据、质量规则和主题库不再重要。恰恰相反没有可信的数据基础高质量数据集很难稳定建设。真正发生变化的是项目的建设对象已经从可信数据资源进一步延伸为面向具体人工智能任务的数据产品。当建设对象发生变化项目逻辑就不能保持不变。项目起点不能只从企业现有数据出发还要由业务场景和模型任务反向约束。项目推进不能只以数据汇聚和质量整改为里程碑还要经过任务定义、样本试制、模型验证、规则稳定和版本发布。项目协作不能只是业务、数据和算法之间的前后交接而要围绕任务、样本和有效性共同定义。项目验收也不能只证明数据量、标注量和平台功能已经完成还要同时提供数据可信与任务有效的证据。更重要的是模型应用带来的错误和反馈还会反向推动数据标准、质量规则和源系统持续改进。这构成了一套不同于传统单向治理链的新闭环。数据可用不等于模型可用模型可用不等于任务有效一次有效也不等于能够持续复用。高质量数据集建设不能照搬传统数据治理逻辑因为它所要管理的已经不只是数据是否治理完成而是数据能否围绕明确任务形成模型能力并在持续反馈中不断得到验证。