分享嘉宾：董付春 群核前沿技术研究院
大纲：
- 数据: 驱动AI发展的核心要素
- 数据上面临的挑战性问题
- 数据训推过程中性能的提升与探索
- 未来展望: 数据系统架构
数据：驱动AI发展的核心要素 #
数据、算力和模型参数是驱动AI发展的核心要素。这个结论来自于 2020 年 OpenAI 发布的一篇具有划时代意义的论文《Scaling Law for Neural Language Model》。该论文探索了模型表现跟训练时间、上下文长度、数据集大小、模型参数量和计算量的关系。我们清晰得看到如果数据集和模型参数量在足够充足的情况下，算力越大，模型的损失会降得越低，说明模型的效果会越来越好。数据集和参数量对模型效果的影响也与算力相同。
Scaling laws #
这里引入诺贝尔物理学奖得主Philip W. Anderson 的一句名言：”More is Different“。他提出：复杂系统会涌现出无法仅通过底层单元解释的新性质，物理系统在每一个复杂度上都会出现全新的性质。
回看OpenAI的论文，其实展示了当数据、算力、模型参数得到大幅提升，才能带来智能的涌现，通向未来 AGI的路径。
Data Scale & Parameter Scale #
下图是过去 20 年所有大模型的发展情况，趋势是模型参数的密度越来越高。
下图是数据集的增长情况。相比于数据集的增长，参数增长在近两年表现得越来越大规模，且增长非常迅猛。
Chinchilla Scaling laws #
在 2022 年，又有一篇叫《Chinchilla Scaling laws》的论文出现。它揭示了算力模型大小和数据量之间的黄金标尺。这个阶段大家开始重视参数量和模型数据量的同比例增长，才能达到模型的最优训练。
Recent work on data scaling laws #
最近两年，大家在数据层面做了更多、更细致和深入的Scaling Law研究。比如大家会更加注重数据的质量，进行数据剪枝；提出了关于数据质量和数据效率同数据量同等重要的概念；多模态的模型训练中，数据比例的调控；如果在数据量很小的情况下，如何达到更优的模型效果；如何去使用重复数据，包括一些合成数据的使用等。
AI本质=数据 建模 × 压缩 × 泛化 #
通过以上理论，我们逐渐发现其实 AI 的本质是对数据的建模和压缩，以及对于未来模型的泛化能力。当 AI 如果用最短的规则还原出最大的数据集的时候，说明 AI 已经抓住了世界的秩序。如果数据里面噪声很多，规律稀薄，再好的网络也只是对数据的死记硬背。
下图展示了将所有的数据都映射到向量空间里，揭示了用最短规则把所有的数据还原出来的道理。
数据上面临挑战性问题 #
- 数据量不足：下图展示了从 2020 至 2034 年的数据预测曲线。最上面的绿色线代表着人类在公网里产生的数据量的增长情况。中间的蓝色线展示了几个典型预训练模型的数据量增长情况。而到 2027 、2028 年，其实人类产生的数据就很难满足模型训练所需要的数据量。
下图告诉我们，如果数据量跟不上的话，即使模型的参数量增加，看任何一条曲线，模型效果并不会再增加了，这更说明数据量的重要性。
图8
- 数据质量：在模型训练的时候，会有一些典型的数据不完整，比如异常值、重复性、缺乏代表性等。我们做图片数据的相关训练时，往往标签很多，很难做筛选，数据的利用率也比较低。我们做空间数据筛选数据集的时候，可以对比一下，下图是常见的要去剔除的低质量数据：
下图则是高质量的数据，我们会通过智能化的模型去做数据的打分，来挑选出高质量的数据。
数据质量-低质量3D方案数据
因为我们做 3D 会多一些，低质量的 3D 方案数据会对我们造成很大的困扰，需要把它们去剔除掉。举几个典型例子，比如下面右上角的图片，在 3D 的空间方案里，这个位置可能是厨房的冰箱，这说明有家具的缺失；右下角的图是一个空洞的房间，缺少的是沙发。如何把这些数据去标注、去剔除，然后筛选出高质量的数据，这也是我们目前在做的事情。
#
数据标注 #
业内现在数据标注的工具有很多，有些工具不一定适用于我们的场景，标注本身对业务领域的专业性要求也会比较高，不同的行业有各自领域的专家，并且标注很多时候也是人类偏主观的行为。如果我们要请专门的标注人员，成本也会比较高。
在实际业务中比较典型的数据复杂问题：
- 工具不统一：缺少统一标注平台，难以制定团队/公司级标准；存在Label studio、fiftyone、doccano、CVAT等；
- 存储分散：不同任务数据存储 cos、seaweedfs、服务器等；
- 流程低效：标注任务管理系统，支持任务分配、审核、版本追踪；
- 学习成本高：不同工具、内部培训文档和模板，新人/领域专家上手门槛高。
复杂特征选择与工程化 #
在特征的选择和工程化方面，举一个例子，首先我们需要将大量数据导入到数据平台，根据标签做筛选，接着会做相似性检查。当检查完，通过代码做数据集的统计，最后我们会看这次训练的数据大概分布是什么样的，需要做可视化的检查。
分布式存储系统选型 #
之前也遇到过数据存储选型的挑战，主要是经典存储如Cephfs、Lustre、S3fs跟当前新兴存储技术如Alluxio、JuiceFS、Seaweedfs的对比选型。对比的过程主要会考虑几个因素：私有部署运维成本、上手难度、性能以及云原生是否支持足够好。 
数据治理 #
- 数据量失控：早期通过hostpath 挂载存储，所有用户的数据都存在一个bucket中，无法精准控制每个用户的使用量和多租户管理。
- 数据缺少生命周期管控：多机房训练环境下，一份数据可能在多个机房都存在，缺失版本管理引起混乱。
数据训推过程中性能提升与探索 #
关于群核
群核科技是一家以GPU（专用图形处理器）集群和AI（人工智能）技术为底座的空间智能企业，在过去数年的技术沉淀中构建了一套物理正确的世界模拟器，并将之运用在室内空间场景下的实时渲染、工业生产制造，以及智能体合成数据训练等场景中。群核科技旗下拥有空间设计软件【酷家乐】、海外版产品【Coohom】、面向室内环境AI开发的下一代空间智能解决方案【群核空间智能平台（SpatialVerse）】、具备增强建筑信息建模（BIM）功能的【群核酷空间】以及创意内容云设计平台【美间】等。目前是全球最大的空间设计平台，平台上有3.6亿个商品素材模型，服务了超过45，500家企业，平均每月活跃访问者超过8600人。
真实3D数据采集与标注 #
由于3D场景下会遇到数据量不足的问题，看看业界是如何去采集3D数据的：（以下需要播放动态视频）
合成数据使用 #
由于真机采集数据的硬件设备比较昂贵，标注人员的成本也会比较高，所以现在会有一些合成数据的使用。下图从左到右是业界比较典型的合成数据集：ProcTHOR有10K ，HSSD有 200 多个，ASE有 100K 。中间的数据集是个高质量的仿真出我们真实 3D 空间的数据集。
对比一下，下图ARKitScenes是帧级采集和标注的数据集，HSSD和ASE都是合成数据集，它们的差别主要是：首先帧级采集的数据量级比较少，但是内容比较丰富，是从现实世界里采集出来的，此外，相关设备比较昂贵，采集和标注成本会升高。
而中间的 HSSD 数据集，虽然数量少，但它是专业设计师能够搭建出来的 3D 数据。相当于是合成的数据，并且我们是可以方便地对场景进行编辑和操作，比如想换掉图里的沙发，可以很方便地去移动。同理，右边的ASE数据集里的场景也可自由移动，也是合成数据，相比于真实数据的价格是非常便宜的。
空间智能平台发展历程 #
空间智能平台 SpatialVerse是群核科技五大产品品牌之一，其核心在于庞大且物理正确的数据集库，该数据集库专为通过逼真的虚拟模拟训练复杂模型而设计。依托强大的3D设计数据集、渲染引擎和空间编辑工具，群核空间智能平台构建高度逼真且物理正确的合成虚拟数据集，模仿真实世界的物理特性和空间关系。
空间智能平台核心模块 #
因为真机采集会比较困难，业内现在人类产生的物理世界的数据也已经不够用，所以我们搭建了一套数据生产的管线。最左侧是酷家乐，其平台上有海量的 3D 的素材和场景数据；最右侧是 AIGC、VR/AR、具身智能等行业。左侧的酷家乐好比数据的矿山——我们框架的设计平台，有海量的 3D 合成数据，右侧是各行业需要的数据燃料；在中间，我们做了数据的引擎，相当于把数据矿山提炼成各个行业需要的合成的数据。
丰富3D合成数据 #
当有了这些生产的合成数据以及合成数据生产的管线，我们就有海量且丰富的 3D 合成数据去解决平时训练过程中物理世界数据不足的问题。下图是合成数据的样例，左侧是原始场景，物理世界里拍了一张照片，右侧是仿真出来的合成数据所搭建出来的场景。如果没有标注出来，大家很难分辨出哪些是真实的场景，哪些是合成数据仿真出来的场景。
#
3D数据采集与表征 #
有了这些合成数据之后，如何看3D 数据采集与表征呢？
在公司内部我们有多种模态对 3D 数据的表征。内部也有很多数据格式，如KSG、cc-wordinfo、IFC 和MSD等，数据模态有场景描述、3D、材质图片、视频文本等。下图是数据类别所对应的应用场景的例子。
统计数据表征与转化 #
对于AI训练，为了保障数据的稳定，我们做了一个数据表征和转化的过程。下图上方是酷家乐的原始的数据，不管中间是通过 IFC 还是 OpenUS去表征 3D 数据，我们做了一个 Adapt 层把统一的数据格式进行转化。如果业务训练完之后想去应用这些数据，再通过一个反向的 Adapter 回到业务数据去使用。
数据处理 #
有了这些数据之后，我们就开始做 AI 数据的处理。之前，是通过开源的基于kubeflow pipeline开发了一套分布式数据处理框架，叫qunhe-kfp，主要有以下功能：
- 实现了数据自动分片，支持txt，csv，hive等模态数据的分片，或者文件集合（文件夹）的分片，以及分片的合并
- 集成了诸如pandas，numpy等常用的数据处理library
如下图代码展示，首先定义了kfp operator（处理的算子），它会读 CSV 文件数据，然后去做Shard的分片。中间的代码是做了数据 merge 的过程，最后通过 kfp 提交数据处理 pipeline 的时候，相当于在整个 kubeflow 的后台能够形成图中所示的数据处理流程。它会将分片分配到不同的GPU或CPU上做数据计算，再去merge，然后把整个数据做并行化的处理。
数据处理pipeline #
我们有原始的数据，通过语义分割、文本打标、特征提取，形成带有 meta 信息的数据，之后再做数据集去重，形成候选数据集。当有了这些数据集，再根据训练任务的不同，做筛选，形成 Lora 训练子集或者 controlnet训练子集。这里展示的是一个文生图或图生图的场景，也是整个数据处理的pipeline。
数据处理性能效果 #
经过数据处理之后，我们最大的收益是在效率上。通过改造 KFP 数据处理任务的框架，在增加了分布式之后，实时数据流处理实现数据即时可用，处理海量的大批量数据的时间从天级降到了小时级/分钟级。可扩展性方面，我们整个单任务的数据吞吐量能从百MB/s提升到GB/s，系统处理能力随着资源增加而提高，整个数据处理任务非常快。
数据标注 #
这里展示的是数据标注的演化过程。最开始我们用过fiftyone和label studio，最后我们开发了一套群核自己的标注系统。
典型标注类型 #
这里是数据标注的几种类型。因为我们标注的数据模态不一样，与业界常用的标注方式可能有些不同，也形成了我们自己的标注方式。
数据标注：AI布局数据标注 #
数据标注: CAD户型识别数据标注 #
#
数据标注: 人机协同的智能标注体系 #
通过这样的人机协同智能化标注系统，我们形成了对多种模态的标注，背后是由我们的业务专家、协作平台以及自动化的工具/算法模型所形成的标注齿轮，可不断提升整个标注系统的效率。下图右侧是我们整个标注处理的链路，包括数据预处理、标注规则的定义、数据标注、数据标注质量的控制，形成训练集的评估，然后又回到数据采集的循环过程。
数据集生成 #
数据集的生成从下图最左侧的原始数据开始，然后到标注平台，经过数据处理就形成了训练集和验证集，接着再把训练集同步到训练机房，将验证集用于模型评测。我们平时常用的数据集包括 3D 的设计方案、点云、图片、文本、视频等。
点云数据集 #
这里具体看下点云数据集：
点云数据集：https://huggingface.co/datasets/manycore-research/SpatialLM-Testset
今年 3 月份我们开源了SpatialLM模型。就像我们环顾四周环境便可以理解背后的空间结构一样，SpatialLM模型能够基于从手机视频中提取的点云数据，准确认知和理解其中的结构化场景信息，并将它以脚本语言的形式呈现出来，这也是一个典型的数据集的训练过程。
#
高质量空间场景数据集 #
数据存储场景 #
在数据系统侧，我们业务上会产生结构化的数据，会有结构数据的存储。在AI系统侧，我们做模型开发，会有训练集的存储；在训练的过程中，会不断产生Checkpoint；模型训练好之后，会有模型仓库的存储，以及模型要部署上线，则需要推理模型库的存储。所以，数据存储主要是这么四个类别。不同的类别，对存储的要求也不一样。比如在数据收集和预处理阶段，对存储的需求是大容量和高吞吐；在模型训练和Checkpoint阶段，存储需要低延时，从而能够最大程度使用GPU的算力资源；在模型推理阶段，要求模型能够做快速的分发。
数据存储方案 #
下图是我们搭建的数据存储方案，在模型训练阶段用的是Alluxio，作为分布式缓存，在模型推理阶段用的是JuiceFS+Redis，最底层使用的是seaweedfs+tikv。
数据存储演化 #
我们整个数据存储方案也经历了三个阶段的演化过程：
阶段一：最早AI训练的存储方案是使用对象存储Swift+Redis sentinel，上面用JuiceFS去挂载。 
遇到的问题：
- redis 大量删除/新增时内存暴涨，进程重启甚至kvm宕机；
- swift 数据倾斜问题（数据前缀分桶）；
- swift ai和渲染未做物理隔离,相互影响；
- redis sentinel 容量问题（32G内存约支持6000万文件)。
#
阶段二：TiKV + SeaweedFS
遇到的问题：
- TiKV磁盘不回收，定位为safepoint问题；
- 容量管控问题（hostpath->pvc），缺少多租户；
- Seaweedfs元数据同步和性能问题严重；
- 单节点缓存上限,关注（单节点磁盘有限）。
#
阶段三：Alluxio + SeaweedFS
我们使用Alluxio 替换了SeaweedFS的 client。之前完全是通过SeaweedFS的 client去训练任务的节点来读数据，但开源的SeaweedFS的 client 经常会挂掉。于是，我们在训练过程会使用Alluxio的分布式缓存的预热等方式来提升训练性能，并且alluxio worker 节点非常容易扩容，所以形成了下图右边的架构。
我们现在的训练任务如PytorchJob，通过 alluxio的PVC挂载到alluxio-pv，然后再形成alluxio-fuse的链接过程。下面就是alluxio-worker节点，通过此节点，我们通过 S3 的协议去访问到 SeaweedFS。通过这样的方式，PytorchJob不再直连SeaweedFS client，这样就规避了稳定性的问题，整个训练的稳定性也有非常明显的提升。
Alluxio 分布式缓存加速 #
Alluxio 无论是在多机还是单节点的训练和推理上，完全都可以通过分布式的缓存高效加载我们需要的数据。下图右侧是我们常用底层的存储，如HDFS，Ceph和SeaweedFS，都可以通过Alluxio去访问。 
存储性能提升 #
在使用 Alluxio 的时候也做了一些性能验证。下图左侧是我们在没使用Alluxio的时候，可能只训练到4个epoch，而当使用了Alluxio加载训练数据，明显训练的epoch会加速很多。同时，我们分别做了在磁盘充足或者磁盘不充足两种场景下的多项任务实验。尤其在本地磁盘缓存不充足的情况下，使用Alluxio对性能的提升是非常明显的，有个别任务可以实现提升20%-30%的水平。
数据生命周期管理 #
数据治理早期是所有任务通过hostpath都挂载到同一个bucket，后来我们改为了pvc，为每个算法工程师分配了一个自属的bucket，这样可以避免所有人的数据都混在一个bucket里，可以进行很好控制。当bucket里的数据过期，会自动删除不用的数据。从数据成本管控的角度，也在做数据的分级存储。在数据清理的层面，由于底层使用的SeaweedFS没有很好的办法做数据过期的处理，现在是定期做扫描和删除，以比较暴力的方式清除，只有粗粒度控制，没有细粒度的控制。
集群间数据管理与流转 #
我们有多个本地训练机房，在公有云上也有一些弹性的训练机房。为了方便在训练的时候，算法工程师可以快速加载所需数据，我们做了一个数据流转平台（如下图所示），将数据存储在计算近端，算法工程师可以选择不同的机房和不同的bucket来访问和流转这些数据。
性能与效率提升结果 #
通过以上实践，我们现在可以达到99.9%的稳定性；数据处理效率上我们从单点到分布式，速度提升也从10天到小时级别。数据系统的标注过程也能让我们的标注更高效，同时数据版本得到有效控制，从而对数据质量也有很好的提升。
未来展望——数据系统架构模式 #
下图是我们正在构建的群核AI数据平台，让数据经过存储与处理系统之后形成了稳定的数据集，然后再传输到训练集群。该平台主要依托于数据湖/仓的AI一体化架构和更强大的分布式计算框架。
