​

引言

上一篇中，我们了解了高质量数据集建设的核心管理模式、具体目标与支撑其实现的总体技术架构，从制度、标准、工具三个层面构建了协同共建共治的完整闭环。然而，一个健全的体系不仅需要宏观的设计，更需要微观的精耕细作。当标准与工具就位，如何确保最终产出的数据集本身具备支撑模型训练所需的高质量特性？这一篇，我们聚焦到端到端的全流程，详细阐述每个阶段具体要做的事情。

端到端流程

以数据集的全生命周期管控为目标，从现状需求分析识别、数据规划、标准制定、数据工程（采、处、标、存、测等）、编目上架、数据治理监管、发布应用。最终实现数据集的开放与供给，对内支撑算法模型的迭代优化，对外提供市场化的服务，以实现数据集价值的最大化。

如上图所示，一个高质量数据集从诞生到交付使用，是一个包含八个关键阶段的、循环迭代的端到端闭环流程。每个阶段都承载着将业务需求转化为可靠数据资产的具体任务。下面，我们将逐一拆解这八个阶段的具体工作内容与核心产出。

需求调研环节

该阶段的核心目标，是基于场景驱动，业务部门根据调研模板，从AI模型视角整理对数据的依赖关系，按步骤漏斗式分析识别筛选形成高质量数据集清单。

第一步：现状数据摸底

现状数据摸底的核心，在于将分散、隐性的数据资源，系统性地转化为一份结构清晰、可评估的资产目录。通过组织技术团队与数据管理部门协同工作，深入盘点各业务系统、数据库及数据仓库中的现有数据资产，并依据标准化模板，详细记录每个数据项的业务归属、具体来源（如表名或接口）、内容描述、格式结构、质量状况（如完整性、准确性、时效性）、更新频率、数据规模、存储方式及已有管理规范，为后续的需求匹配提供清晰的图谱。

严格上来说呢，这一步其实算是基础工作，但是据观察很多单位连这一块都没做好，而且没做好的原因竟然出奇的一致：其一，缺乏跨部门协同的有效机制，技术团队与业务部门之间对数据资产的理解存在鸿沟；其二，没有坚持使用统一的标准化模板进行盘点，导致盘点结果散乱、无法后续整合；其三，将盘点视为一次性项目而非持续更新的过程，使得资产目录很快过时。

不过，实话实说，这一步能够做到大而全的单位少之又少。更务实的策略是 “抓大放小、由点及面” ，即不必强求在项目初期一次性完成所有数据资产的完美盘点，而是优先聚焦于与核心业务场景紧密关联、或近期有明确智能化需求的高价值数据域，从小切口入手，明确与相关场景有关的已有数据基础即可，这也引出了下面一个步骤。

第二步：拆解数据，明确智能场景数据需求

根据各部门提出的智能化场景需求，我们上一步已经大致梳理了已有的数据基础，心里好歹有了个底，这一步就是需要将每个智能场景（如隐患识别、智能问答等）拆解为具体的数据依赖项，明确“需要什么数据”。

通常，我们会按照上述表格样式进行归纳整理，主要包含智能场景描述、需要的数据(样例)、数据描述、数据来源、数据类型、用途、要求等等。

• 智能场景描述：用一段话清晰地阐述该场景要解决的业务问题、实现的目标以及预期价值。如一个隐患图片比对智能体，则应该描述为：“实现对隐患排查数据质量和隐患整改真实性的自动化批量比对分析，帮助省厅监管人员快速发现问题数据，提升监管的能力”。这段描述是后续所有数据拆解的根本依据。
• 需要的数据(样例)：逐项列出为实现该场景所必需的具体数据项或数据实体，每个数据项应尽可能具体，如列出：“巡查的隐患图片”、“巡查的隐患数据”、“场所巡查隐患处置痕迹信息”等。如果数据形式复杂（如特定格式的样本文件），可作为附件提供。
• 数据描述：对“需要的数据”中列出的每一项数据，进行业务含义上的补充解释。目的是确保业务和技术理解一致。例如，对于“巡查的隐患数据”，描述为“工作人员填写的隐患内容”，明确了其业务来源和内容性质。
• 数据来源：明确指出每个数据项当前存储或产生的具体业务系统、数据库或接口名称，这是数据可获取性的关键；如果数据来源不同，需分别准确填写。
• 数据类型：标明每个数据项的基本技术形态或格式。主要分类如“图片”、“结构化”（指数据库表、Excel等行列规整的数据）、“文本”、“音视频”等。这直接决定后续的数据处理技术选型。
• 用途：说明该数据项在智能场景中的具体作用或使用目的。例如，是用于“小模型训练”、“规则引擎分析”、“生成报告”还是“可视化展示”。这直接关联到对数据质量、时效性、样本量的不同要求。
• 数据要求：针对每个数据项，提出具体的、可衡量的质量或规格要求。此字段至关重要，且往往需要深入讨论后填写。这是将模糊需求定量化的关键一步。例如：对“巡查的隐患图片”：可要求“分辨率不低于1920x1080，需包含隐患部位特写与全景两张，图片需附带时间、地理位置元数据”；对“巡查的隐患数据”：可要求“字段完整率需达100%，隐患等级分类准确率需达99%以上”；对“处置痕迹信息”：可要求“数据更新延迟不超过1小时，状态字段必须包含‘待整改’、‘整改中’、‘已完成’、‘已复核’”。
• 其他：填写上述字段未能涵盖的额外补充信息或特殊说明。例如，数据获取的权限审批流程、数据的敏感等级、是否有已知的数据质量问题等。

形成了这份表之后，后续不管是数据对接还是问题排查或者说是定责都会方便许多了。

第三步：明确系统建设完成后，可沉淀产生的新数据

这一步是建议大家去做的，因为智能体场景的建设必定会产生新的数据结果，如果条件允许的话，可以结合信息化建设规划，识别并定义那些在新建或升级业务系统后，能够被规范化沉淀下来的新的数据资源。这样一来，我们所构建的就不再是一个静态的数据供应体系，而是形成了一套推动数据资产持续积累、反哺业务智能升级的长效化机制。

举个容易理解的例子：智能场景（如隐患识别模型）在运行过程中，会持续产生新的数据结果，例如模型的预测结果、人工复核的反馈、处置效能的统计等，这些数据本身是优化模型、评估业务价值、发现新规律的宝贵资源是十分必要的，所以，在规划一个智能巡检系统时，就理应同步设计好“标准化巡检记录（含多媒体）”、“设备健康度时序日志”等数据资产的产出规范。

这一步的深层价值在于构建一个自我增强的数据飞轮。每一轮新系统的上线，都会依据第三步的规划，向数据资产目录中注入新的、标准化的数据燃料。这些新数据不仅能满足现有需求，更可能催生出如“模型效果持续监控”、“数据驱动流程优化”等新一代的智能场景，进而反馈并更新第二步中的需求清单。如此循环，数据资产得以持续积累与增值，智能化应用也因此获得源源不断的动力，真正实现从项目化建设到体系化运营的长效演进。

第四步：供需关系确认

在完成了前三步之后，我们手中已经掌握了自己理解的数据资产，但是这个资产有没有用，还是得业务部门二次确认，所以这一步我们的核心任务就是再次组织跨部门的协同会议，识别并筛选出真正有建设价值的“潜在高质量数据集”，并厘清各部门在其中扮演的供给方与需求方角色，明确权责关系。

会议主要要确认数据项细节、供给与消费关系、筛选与优先级等等。

以城市指挥中心大脑为例，我们需要构建一个《指挥中心高质量数据集-供需明细表》，这一步骤通过组织由指挥中心（需求方）、各业务数据源部门（供给方，如公安、消防、医疗、交通等）及数据管理牵头部门共同参与的专题研讨会来完成。会议将围绕指挥中心在第二步中提出的具体智能场景（例如“城市应急事件实时融合指挥视图”）展开，核心是逐项确认并填充明细表中的关键信息：

• 供给与消费关系确认：这是明细表的核心输出。对于每个确认可获取的数据项，将明确记录需求方（消费部门，此处即指挥中心）；供给方（生产部门，例如，实时警情数据由公安情报部门供给，消防资源状态由消防指挥系统供给，120急救车轨迹由卫健委信息中心供给）。
• 数据项细节确认：针对“融合指挥视图”所需的具体数据（如警情事件、消防资源位置、急救车状态、道路拥堵指数），会议将逐项核实其数据现状和数据规划中的数据存在情况、具体形态、可获得性以及需治理改造的点。例如，公安部门需确认警情数据的实时接口能力与字段，交通部门需说明拥堵指数的更新频率与覆盖范围等，明确字段清单、更新频率（如秒级、分钟级）、交付方式（如服务接口、数据交换平台）、质量标准（如数据延迟<30秒）等，形成跨部门共识并记录在案。
• 筛选与优先级初判：这里和第一步数据摸底时说的是一个意思，并非所有数据需求都能无条件满足，要基于实现的复杂性、成本、业务价值的紧迫性，进行初步筛选与排序。例如，指挥中心提出的“全量社会监控视频流实时接入”需求，可能因成本与技术挑战被调整为“重点区域监控视频智能摘要与报警事件推送”，从而筛选出当前阶段最可行、最紧迫的高价值数据集组合。

通过此会议产出的《指挥中心高质量数据集-供需明细表》，将原本分散、模糊的数据需求与供给，转化为一份权责清晰、细节明确、经过跨部门背书的合同文件。

第五步：形成高质量数据集清单

完成以上步骤后，根据数据的具备条件、需求频度，形成最终可以产出的高质量数据集清单。

数据规划环节

该环节主要目标是完成高质量数据集的编目化及内容设计，基于筛选确认的高质量数据集清单，对每个数据进行分类分级、数据特征、标签、元数据、样例数据整理，编制数据集内容规范《高质量数据集目录建设标准》，为后续的数据生产加工与智能应用提供清晰、统一的执行依据。

在正式开展每个数据集的详细规划前，需要先明确一套贯穿始终的顶层设计，确保所有数据集在框架、分类和编目上保持一致，避免后续出现 “数据孤岛” 或标准不一的问题。这里可以参考从0开始全面认识高质量数据集建设（1）中提到的建设指南和政策依据，规范包括：

• 高质量数据集内容框架
• 高质量数据集分类体系
• 高质量数据集编目要求

然后重点来了，针对于上述的高质量数据集清单，我们其实是可以进一步拆分分类的，比如说按照从0开始全面认识高质量数据集建设（1）中提到的可以拆分为通识类数据集、行业通识类数据集、行业专识类数据集，但是一般而言，内部建设智能体场景时，只有行业通识类数据集和行业专识类数据集。

关于这两类数据集，我们可以抽象出一套构建方法，包含设计和实施两部分：

完成设计与实施两个阶段的所有工作后，我们将最终输出一份 《高质量数据集目录建设标准》。这个目录需要包含下面最最三个关键的部分：

• 基本信息编目：对数据集名称、分类分级、来源单位、使用场景等描述性和管理性信息进行挂载管理。
• 设计数据内容结构：界定数据集的特征属性、标签值、 参考的主数据等，明确数据的详细内容定义。
• 明确生产加工要求：对每个数据集的采集质量要求、采集方式、预处理加工、标注输出格式等进行说明。

我们还是以城市指挥中心大脑为例，结合其核心业务场景（城市应急事件实时融合指挥、日常运维调度、异常情况预警研判等），具体拆解这三个关键部分的落地内容。

基本信息编目

城市指挥中心大脑作为城市治理的“中枢神经”，其数据集覆盖多部门、多场景，基本信息编目的核心是实现“每一份数据都有明确身份、明确归属、明确用途”，避免多部门协同中的数据混淆、责任不清问题。

数据集名称与编码

采用“城市指挥中心-业务主题-数据类型-版本”的统一命名规范，编码采用“CZ-ZH-业务编码-数据类型编码-版本号”，确保唯一性和可读性，示例如下：

• 数据集名称：城市指挥中心-应急事件融合数据-结构化数据-V1.0
• 数据集编码：CZ-ZH-YJ-01-V1.0（CZ-ZH代表城市指挥中心，YJ代表应急事件，01代表结构化数据，V1.0为版本）
• 补充说明：版本号随数据更新、规范优化同步升级，每次升级需标注更新内容和更新时间，确保可追溯。

分类分级管理

全部归入“行业专识类数据集”（城市指挥中心大脑场景具有极强的政务治理专业性，数据仅适配指挥中心核心智能场景，复用范围限定在城市治理领域），下属细分分类按业务主题划分，如应急事件类、交通运行类、公共安全类、医疗救援类等，结合政务数据安全规范，分为三级，适配不同权限管控需求

• 绝密级：涉及城市核心安全的数据，如应急事件核心涉密信息、重点区域监控数据（如党政机关、交通枢纽），仅对指挥中心核心运维人员、应急处置人员开放；
• 机密级：涉及民生隐私但需用于指挥调度的数据，如120急救车轨迹、警情详细信息，对指挥中心相关业务科室、协同部门（公安、医疗）授权开放；
• 秘密级：可内部共享、无敏感信息的数据，如城市公共设施点位数据、日常运维调度记录，对指挥中心全体工作人员、相关协同部门开放。

来源单位与责任链路

结合前文供需关系确认环节的协同部门，明确每个数据集的供给方（来源单位）、管理方（责任单位），建立“来源可追溯、问题可追责”的链路，示例如下：

使用场景与价值描述

明确每个数据集支撑的城市指挥中心大脑智能场景，避免数据闲置，同时量化其业务价值，示例如下：

• 使用场景：支撑“城市应急事件实时融合指挥视图”“应急事件智能研判预警”“多部门协同调度”三大核心场景，用于AI模型的实时推理、事件态势分析、资源调度匹配。
• 价值描述：整合多部门应急相关数据，打破部门数据壁垒，实现应急事件的实时可视化呈现、快速研判（缩短研判时间30%以上），支撑指挥中心快速下达调度指令，提升城市应急处置效率和协同能力，降低应急事件处置成本。

设计数据内容结构

城市指挥中心大脑的核心需求是“数据融合、智能研判”，因此数据内容结构设计需兼顾“各部门数据的兼容性”和“AI模型的适配性”，明确每一份数据的特征、标签和参考标准，避免因数据口径不一、定义模糊，导致融合失败、模型研判不准。结合其核心数据集（以应急事件融合数据集为例），具体设计如下：

特征属性定义

以“应急事件融合数据集”为例，明确每个字段的业务含义、数据类型、约束条件和示例值，确保公安、消防、卫健委等多部门提供的数据“同源、同径、同标”，示例如下：

标签与标注体系

城市指挥中心大脑的AI模型（如事件研判模型、异常预警模型）需要标准化的标签支撑，因此需针对核心数据集设计统一的标签体系，以应急事件融合数据集、监控视频数据集为例：

• 应急事件融合数据集标签：
  • 标签类别：事件类型标签（火灾、交通事故等）、事件等级标签（1-4级）、处置状态标签（待处置、处置中、已完成、已复核）、涉及资源标签（警车、消防车、救护车等）。
  • 标注规则：标签取值严格遵循预设范围，不可自定义；多标签关联时，需确保逻辑一致（如“火灾”事件需关联“消防车”“消防员”等资源标签）。
• 重点区域监控视频数据集标签（核心级数据）：​
  • 标签类别：异常行为标签（聚集、斗殴、违规用火）、异常物体标签（明火、烟雾、障碍物）、人员/车辆标签（执勤人员、急救车辆、工程车辆）。​
  • 标注规则：标注精度需达到95%以上，明火、烟雾等关键异常标签需标注具体位置；标注工具采用指挥中心统一指定的视频标注工具，输出格式为COCO格式，便于AI模型调用。

主数据与参考标准

结合城市治理相关国家标准、地方规范，明确指挥中心数据集参考的主数据和标准，避免多部门数据口径混乱，核心参考如下：

• 主数据参考：行政区划主数据（采用当地政务统一的行政区划代码）、应急事件类型主数据（遵循《突发事件分类与分级标准》）、公共服务设施主数据（采用城市政务地理信息平台统一数据）。
• 参考标准：
  • 数据格式标准：结构化数据遵循JSON/CSV标准格式，视频数据遵循H.265标准，地理信息数据遵循GIS相关标准；
  • 编码标准：事件ID、人员ID、车辆ID等编码，遵循城市指挥中心统一编码规范，与各协同部门编码规则兼容；
  • 命名标准：字段名称、标签名称采用统一的中文命名，避免缩写、歧义（如“发生时间”不可简写为“时间”）。

明确生产加工要求

城市指挥中心大脑对数据的“实时性、准确性、完整性”要求极高，尤其是应急事件、交通运行等核心数据，直接影响指挥调度的及时性和准确性。因此，生产加工要求需结合其业务时效性、安全性需求，制定可量化、可落地的操作规范，仍以应急事件融合数据集、交通运行实时数据集为例，具体要求如下：

采集质量要求

采集方式与频率

结合指挥中心不同业务场景的时效需求，明确定义采集方式和频率，避免“采集不及时”“采集方式不合理”导致数据价值下降：

标注输出格式

针对需要用于AI模型训练、推理的数据集（如监控视频数据集、应急事件标注数据集），明确标注输出格式、质量抽检要求，确保标注结果可直接被指挥中心大脑的AI模型调用：

未完待续~