高质量数据集建设为什么不能照搬传统数据治理逻辑

导语

一家企业完成了持续多年的数据治理建设。

核心业务系统已经接入数据平台，数据标准、元数据、主数据和质量规则陆续建立，主题库和指标体系也开始稳定运行。过去分散在不同部门和系统中的数据，已经可以被统一查询、关联和共享。按照传统数据治理项目的评价方式，这是一项较为成熟的建设成果。

当企业准备建设行业大模型、知识问答和业务智能体时，新的问题却很快出现。

数据部门认为，核心数据已经完成汇聚，主要字段的完整率、一致率和规范率也达到了项目要求。算法团队拿到这些数据以后，却发现很难直接构造训练样本。

结构化数据中有大量业务记录，却缺少与目标任务对应的标签、判断依据和过程反馈。制度文档虽然已经统一归档，却没有被组织成能够支撑复杂问答的知识单元。历史数据数量庞大，但哪些代表典型场景，哪些属于异常边界，哪些可以用于训练，哪些必须独立保留用于评测，也没有明确答案。

数据部门完成了治理工作，算法团队却无法直接启动模型训练。双方都完成了各自职责，人工智能应用仍然没有真正获得可用的数据基础。

问题并不在于传统数据治理没有价值，而在于以“数据已经完成治理”作为项目完成标准，已经无法覆盖高质量数据集建设的全部要求。

数据治理完成，说明数据更加可信、规范和可管理。数据集就绪，则意味着这些数据已经围绕明确任务完成重新组织，能够被模型训练、检索、评测和调用，并且具有清晰的适用范围和验证证据。

治理后的可信数据资源与面向模型任务的数据集产品之间，还存在一次任务化转换。真正值得继续追问的是，当建设对象发生变化以后，项目为什么也不能继续沿用原来的建设逻辑。

传统治理成果与面向任务的数据集之间仍隔着任务定义、样本组织和模型验证三个环节，如图1所示。

图1 数据治理完成，不等于数据集就绪

一、高质量数据集建设不是数据治理项目增加几个新模块

面对高质量数据集建设，不少项目首先想到的是在现有数据治理体系上增加一些人工智能相关功能。原有平台缺少标注能力，就增加标注模块。文档尚未向量化，就增加解析、切分和向量入库能力。数据集需要持续更新，就增加版本管理、发布和运营功能。

这些能力都可能需要，但它们并不能自动完成从传统数据治理项目到高质量数据集项目的转换。

传统数据治理项目通常围绕数据标准、元数据、主数据、质量规则、主题库、指标体系和数据服务展开。它所形成的核心成果，是可信、规范、可发现和可复用的数据资源及其管理能力。

高质量数据集项目则要进一步形成面向明确任务的数据产品。这个数据产品可能是预训练语料、指令微调样本、知识检索数据、预测样本、偏好数据、智能体任务轨迹，也可能是独立的验证集和测试集。不同数据集形态差异很大，但都必须回答几个共同问题：它服务什么任务，模型怎样使用它，基本样本单位是什么，适用范围在哪里，又通过什么方式证明它能够支撑目标任务。

因此，高质量数据集建设并不是把已有数据治理工作做得更细，也不是在传统数据平台上增加若干人工智能模块。真正发生变化的是项目中心。传统数据治理项目的中心是可信数据资源，高质量数据集项目的中心则进一步延伸为面向任务的数据产品。

数据标准、质量规则、主题库和数据平台仍然重要，但它们在新项目中更多承担可信基础和生产支撑作用，不能代替核心数据集产品本身。一个项目可以建成完整的数据集管理平台，也可以形成大量治理后的主题数据。如果项目仍然不能说明最终形成了哪一类数据集、服务什么任务、由哪些样本组成、如何进入模型，那么支撑能力再完善，也不能说明数据集已经就绪。

二、项目起点不能只从“拥有什么数据”出发

传统数据治理通常从数据现状盘点开始。企业有哪些系统，系统中有哪些表和字段，哪些编码需要统一，哪些质量问题需要整改，哪些数据应当进入主题库，这些问题共同决定了治理范围。

高质量数据集项目仍然需要盘点数据，但盘点的出发点发生了变化。项目首先要回答的，不再只是企业拥有什么数据，而是模型需要完成什么任务。

同样是一批制度文件，如果目标只是帮助用户检索相关条款，项目重点可能是文件版本、条款切分、语义索引和引用定位。如果目标是回答复杂业务问题，就需要进一步组织问题、答案、适用条件、冲突规则和证据来源。如果目标是辅助审批，还要把制度要求与业务材料、历史结论、人工判断过程和修正结果联系起来。数据来源可能相同，最终形成的数据产品却完全不同。

因此，高质量数据集建设不能先确定“建设多少套数据集”，再从现有系统中寻找可以加工的内容。也不能因为某一类文档数量最多、某一类数据最容易获取，就自然把它确定为项目重点。一旦按照这种方式推进，项目很容易从“模型完成任务需要什么数据”，滑向“企业现有数据能够加工成什么成果”。

高质量数据集项目中的数据盘点，需要由业务问题和模型任务反向约束。业务场景说明为什么建设，模型任务说明数据将被怎样使用，数据需求则进一步明确需要哪些内容、采用什么结构、覆盖哪些场景和边界。

这并不意味着项目可以脱离现有数据条件，单纯从理想任务出发设计数据集。现实中，任务需求、数据可得性和模型能力需要不断校准。有些理想场景会因为关键过程数据长期缺失而暂时无法实施，有些原本被忽视的数据则可能在模型试验中表现出新的价值。

字段质量达标只能说明数据本身可靠，任务是否成立还要经过任务定义、样本组织和验证评估，如图2所示。

图2 字段质量达标以后，还要保证任务成立

因此，高质量数据集项目的范围不是在项目开始时一次性冻结的，而是在任务目标、数据基础和验证结果之间逐步稳定下来的。这也决定了它不能完全按照传统数据治理项目中“先确定范围，再批量治理”的方式推进。

三、项目里程碑必须重新设计

高质量数据集建设与传统数据治理项目最明显的差异，不是增加了多少新技术，而是项目的推进节奏发生了变化。传统数据治理项目通常以标准发布、数据接入、质量整改、主题库上线和数据服务发布作为重要里程碑。这些里程碑能够判断数据治理工作是否按计划完成，却不足以判断一套数据集是否适合进入规模化生产。

因为一批数据是否真正适合模型使用，往往无法仅靠数据质量检查和专家审阅得出结论。数据可以没有明显缺失，标注人员之间的一致率也可以很高，但模型训练后仍然可能没有改善。原因可能是样本过于简单，没有覆盖真实任务，也可能是数据分布与业务环境不一致，还可能是问题表达高度重复，模型只是记住了少量固定模式。

还有一些问题，只有当数据进入模型以后才会暴露。例如，一个风险识别数据集可能字段完整、标签清楚，模型测试准确率也很高。但进一步检查后发现，模型输入中混入了风险事件发生以后才产生的处置结果。模型学到的不是如何提前识别风险，而是如何读取事后结论。

因此，高质量数据集项目不能先生产十万条、百万条样本，再把全部数据交给算法团队进行最终验证。它需要重新设置一组面向任务的数据集里程碑：任务可执行、样本可验证、规则可规模化、数据集可发布、效果可复现。

其中最关键的变化是，小样本验证不是规模生产后的抽检，而是规模生产前的必要门槛。项目应先用小规模样本验证任务定义、样本结构、标签规则和评价方式，再决定是否扩大生产规模，如图3所示。

图3 小样本验证是规模化生产前的门槛

如果没有经过小样本试制和模型验证，就直接进入大规模标注和数据生产，项目放大的可能不是数据价值，而是任务定义、标签规则和样本结构中的错误。传统治理可以根据已经明确的数据标准批量开展质量整改，高质量数据集建设则需要先通过模型和任务验证，逐步发现什么样的数据规则才真正有效。

四、业务、数据和算法不能再只是前后交接

传统数据治理项目同样需要多部门参与。业务部门负责解释数据含义和业务口径，数据团队负责标准、模型和质量治理，技术团队负责系统接入和平台实施。虽然各方需要不断沟通，但总体上仍然可以按照相对清晰的专业工序进行分工。

高质量数据集项目中的协作关系更加紧密。业务专家不仅要解释字段是什么意思，还要定义真实任务中如何作出判断，哪些条件会改变结论，哪些情况属于例外，哪些问题本身就不应给出确定答案。

数据团队不仅要保证数据来源可信、结构规范，还要把业务判断转化为可以生产、追溯和迭代的样本结构，并管理数据划分、生成规则和版本变化。算法团队也不能等数据全部完成后再被动接收，而需要在任务拆解、样本试制和规则调整阶段参与判断。模型是否能够使用这些数据，错误究竟来自模型能力还是来自数据覆盖，也需要算法团队尽早参与分析。

三类团队不再只是前后交接，而是围绕同一个数据集产品共同定义。业务部门只提供一批历史材料，并不等于已经定义了模型任务。数据团队完成清洗和标注，也不等于样本一定适合模型。算法团队训练出一个结果，也不能单独说明数据集已经达到发布要求。

如果项目仍然按照传统工序分段交付，就容易出现一种典型状态：业务部门认为材料已经提供，数据团队认为数据已经完成，算法团队则认为数据不可用。每个环节都完成了自己的工作，却没有任何主体对数据集整体有效性负责。

因此，高质量数据集项目需要同时管理数据责任、任务责任和有效性责任。这些责任可以由现有项目负责人、数据产品负责人或者跨部门工作组承担，不一定必须新增一个岗位。但项目不能只对局部交付进行分工，而没有主体维护业务任务、数据产品和模型效果之间的完整关系。

五、模型不仅使用数据，也会反向发现治理问题

传统数据建设往往被理解为一条单向链路：源系统产生数据，数据治理提升质量，治理后的数据再向业务应用提供服务。

在高质量数据集项目中，这条链路开始转变为双向闭环。业务场景提出任务，传统数据治理提供可信数据资源，数据集工程将资源组织成任务样本，模型验证则暴露数据覆盖、规则和结构中的问题。这些问题还会继续返回样本生产、数据标准甚至源业务系统。

模型总是在某类条件下回答错误，可能说明数据集中缺少相应场景。模型无法区分两个业务概念，可能说明不同系统对同一概念的定义并不一致。模型引用了已经失效的制度条款，可能说明文档版本和生效时间没有得到有效管理。模型测试效果异常优秀，也可能不是数据质量极高，而是训练数据与评测数据发生交叉，或者样本中混入了结果字段。

高质量数据集项目通过模型错误分析，将问题返回样本规则、数据标准和源系统采集，形成任务驱动、反馈回流的治理闭环，如图4所示。

图4 模型不仅使用数据，也会反向发现治理问题

传统数据治理没有被替代，而是获得了更加具体的任务反馈。模型应用也不再只是治理成果的消费者，而成为检验数据治理是否真正支撑业务目标的新机制。

六、项目交付的不是一堆成果，而是一套数据产品体系

高质量数据集项目通常会形成多种交付物。数据标准、元数据、质量规则、治理后的主题数据、标注规范、加工流程、管理平台、训练数据、评测数据和验证报告，都可能出现在同一个项目中。

这些成果同时存在并不意味着项目范围失控。真正需要警惕的是，它们被不加区分地并列交付，却没有说明彼此之间的关系。

高质量数据集项目必须有一个明确中心，那就是面向具体任务的数据集产品。围绕这一核心产品，项目还需要形成可信数据基础，证明数据来自哪里，经过哪些治理，是否具有明确权属和合规依据。

项目还需要形成生产与管理能力，支持数据清洗、标注、版本、权限、发布和反馈。这些能力保证数据集能够持续生产和迭代，但它们属于支撑体系，不能代替数据集内容。

如果项目只建成了平台，却没有明确平台中管理的具体数据集，支撑能力就取代了项目中心。如果项目交付了大量标注数据，却无法说明样本结构与目标任务的关系，标注数量就取代了数据产品价值。如果项目只完成一次模型训练，却没有保留数据来源、生成规则、数据版本和适用边界，一次实验结果也无法沉淀为可以持续使用的数据集。

所以，高质量数据集项目不能只列出一张交付清单，还要说明不同成果之间的依赖关系：哪些成果提供可信基础，哪些规则把数据资源转化为样本，哪些平台支持持续管理，哪一个数据集产品最终进入模型，又通过什么证据证明它已经达到发布条件。

七、验收不能只证明数据做完了

传统数据治理项目通常验收数据接入范围、标准建设数量、目录覆盖程度、质量规则数量、问题整改率、字段完整率和平台功能实现情况。这些指标能够证明约定的数据治理工作已经完成。

高质量数据集项目仍然需要这些基础指标，但不能止步于此。数据集是否具有明确任务和适用范围，样本结构是否符合模型使用方式，训练数据与独立评测数据是否有效隔离，数据分布是否覆盖真实场景，版本和生成过程是否能够追溯，都应当进入验收范围。

除此之外，项目还需要形成两类相互关联的证据。第一类是数据证据，它证明数据来源可信、内容准确、结构合理、版本清晰，并满足权属、安全和合规要求。第二类是任务证据，它证明数据集与目标任务相适配，并且在明确的模型、基线、实验和业务条件下形成了可复现的有效性结果。

任务证据不能简单等同于展示一个模型准确率。模型效果还会受到模型架构、训练方法、参数设置和推理策略等多种因素影响。项目需要记录模型版本、训练方法、基线数据、评价指标和实验条件，通过对照实验尽可能识别数据变化对任务结果产生的影响。

高质量数据集项目需要依次通过数据证据和任务证据两道验收门槛，缺一不可，如图5所示。

图5 高质量数据集项目的双证据验收

检索类项目可以关注召回率、引用准确率和问题覆盖程度。问答类项目可以关注回答正确性、证据一致性和拒答边界。预测类项目可以关注识别能力、稳定性和业务收益。智能体项目则可以关注任务完成率、工具调用正确率、过程合规和执行安全性。不同项目的指标可以不同，但验收逻辑应当一致：不仅要证明数据已经被生产和管理，还要证明它与目标任务相适配。

项目通过验收，也不意味着数据集从此固定不变。业务规则会调整，数据分布会发生变化，模型版本也会持续升级。首次验收只能证明当前数据集版本在当前条件下成立，后续仍然需要通过反馈、评测和版本更新重新确认其适用性。高质量数据集项目的首次交付不是建设终点，而是第一个经过验证的数据集版本。

结语

高质量数据集建设不能照搬传统数据治理逻辑，不是因为数据治理已经过时，也不是因为数据标准、元数据、质量规则和主题库不再重要。恰恰相反，没有可信的数据基础，高质量数据集很难稳定建设。

真正发生变化的是，项目的建设对象已经从可信数据资源，进一步延伸为面向具体人工智能任务的数据产品。当建设对象发生变化，项目逻辑就不能保持不变。

项目起点不能只从企业现有数据出发，还要由业务场景和模型任务反向约束。项目推进不能只以数据汇聚和质量整改为里程碑，还要经过任务定义、样本试制、模型验证、规则稳定和版本发布。项目协作不能只是业务、数据和算法之间的前后交接，而要围绕任务、样本和有效性共同定义。项目验收也不能只证明数据量、标注量和平台功能已经完成，还要同时提供数据可信与任务有效的证据。

更重要的是，模型应用带来的错误和反馈，还会反向推动数据标准、质量规则和源系统持续改进。这构成了一套不同于传统单向治理链的新闭环。

高质量数据集建设不能照搬传统数据治理逻辑，因为它所要管理的已经不只是数据是否治理完成，而是数据能否围绕明确任务形成模型能力，并在持续反馈中不断得到验证。