Investigating the effectiveness of data augmentation from similarity and diversity: An empirical stu

0、abstract

数据扩充已成为一种广泛采用的技术,用于提高深度神经网络的泛化能力。然而,仅基于模型训练来评估数据增强方法的有效性在计算上要求很高,并且缺乏可解释性。此外,缺乏定量标准阻碍了我们对数据增强方法的潜在机制和新技术的发展的理解。为此,我们提出了可解释的定量措施,将数据增强方法的有效性分解为两个关键维度:相似性和多样性。所提出的相似性度量描述了原始数据集和增强数据集之间的总体相似性,而多样性度量则根据类别量化了原始数据集中和增强数据集中固有复杂性的差异。重要的是,我们提出的措施与模型训练无关,确保了计算的效率。通过在几个基准数据集上的实验,包括MNIST、CIFAR10、CIFAR-100和ImageNet,我们证明了我们的措施在评估各种数据增强方法的有效性方面的有效性。此外,尽管所提出的措施很简单,但它们有可能指导数据增强技术的设计和参数调整,并在开始大规模模型训练之前验证数据增强方法的有效性。

1. Introduction

数据增强已在深度神经网络(DNN)中广泛采用,以减轻过拟合风险并提高模型的性能[1,2]。在深度学习的背景下,数据扩充(DA)是指通过对现有数据样本应用各种转换或修改来人为扩展数据集的技术。值得注意的是,实现最先进(SOTA)性能的DNN通常使用各种DA方法,如AutoAugment[3]和RandAugment[4]。
尽管DA方法是有效的,但现有的DA方法通常基于其在特定任务上的表现来评估其功效,例如图像分类任务中模型的分类精度[5,6]。不幸的是,基于模型训练的DA评估方法存在局限性。首先,已经观察到不同的图像数据集对增强方法表现出不同的偏好[6,7]。例如,Cutout[8]已被证明对CIFAR10[9]有效,但对ImageNet[10]无效。同样,AutoAugment也证明了增强策略的最佳组合在不同的数据集中是不同的[3]。因此,评估DA方法需要在各种数据集上训练大量的深度模型,从而导致显著的计算开销。其次,缺乏模型训练不可知的定量测量阻碍了DA方法的可解释性[11]。DA方法的基本机制仍然不透明,并且没有既定的标准来指导DA方法的设计和参数调整。例如,传统的DA方法旨在生成类似自然场景(或可能在测试集中看到但在训练集中看不到的场景)的图像,例如旋转图像以模拟几何变形。然而,确定DA方法参数的最优值通常需要训练许多深度模型,这给研究人员带来了实际挑战。

尽管评估指标,如Inception Score(IS)[12]和Frechet Inception Score(FID)[13],已被用于评估深度生成模型[14]生成的合成图像的质量,但它们不适用于解释DA方法的有效性,尤其是那些被认为不现实的方法。这些指标(例如,IS和FID)主要关注生成图像的质量和多样性,假设与真实数据非常相似。然而,在DA研究的背景下,重点从高质量数据转移到生成各种训练数据,旨在减轻过度拟合风险。如图1所示,GridMask[6]通过删除均匀分布的正方形区域来生成图像,Mixup[15]通过创建输入和标签对的凸组合来生成虚拟训练样本。尽管在增强模型性能方面是有效的,但这些方法生成的增强图像不是自然场景的模拟,在视觉上毫无意义;因此,使用这些评估度量来评估增强图像的质量是不合理的。因此,评估深度生成模型和DA方法之间的差异需要开发一个定量标准来评估DA技术的有效性。最近,[16]首次提出了一项关于affinity 和diversity的实证研究,以评估DA方法,而affinity 和diversity的计算都涉及模型训练。基于模型训练的结果,这两个指标缺乏可解释性,并引入了高计算成本,因为确定affinity 和diversity需要相当于确定最终测试准确性的努力。鉴于这些挑战,迫切需要建立一个定量标准来研究DA方法的有效性

在本文中,我们提出了从相似性和多样性来评估数据增强(DA)方法有效性的定量措施。虽然很简单,但所提出的措施是高效的,因为它们独立于模型训练。由于DA方法在不同数据集上的有效性不一致[6-8],我们不是使用单一的度量,而是在我们提出的相似性-多样性平面上评估DA方法。相似性度量捕获了原始数据和增强数据之间的总体相似性,而多样性度量量化了原始数据与增强数据之间关于类别的固有复杂性的变化。因此,我们将数据增强的功效分解为相似性和多样性。为了解决量化图像数据集之间距离的挑战[16,17],特别是在具有图像数据和相应标签的监督学习中,我们以几何意义的方式使用最优传输(OT)距离来比较原始和增强训练数据集的数据标签分布[17,18]。此外,我们引入了一种受主成分分析(PCA)[19]和生物多样性[20]启发的新的多样性度量,该度量根据类别量化原始数据和扩增数据之间的不相关性。经验证据表明,视觉相似性和多样性对DA方法的有效性几乎没有影响[6,15],这促使我们探索用于测量目的的特征空间嵌入。通过正式定义相似性和多样性度量,我们专注于图像级DA方法,并在CIFAR-10和CIFAR100上评估220种不同的增强,在ImageNet数据集上评估143种。所研究的DA方法包括既有广泛的变换族又有更精细的变换参数的基本图像变换,以及一些SOTA DA方法,如Mixup[15]、CutMix[21]、Cutout[8]、Randomerasing[22]、GridMask[6]、AutoAugment[3]、RandAugment[4]和KeepAugment[23]等。

综上所述,这项工作的贡献如下:

  • 1)我们提出了与模型训练无关的新的定量测量方法,以研究基于相似性和多样性的DA方法的有效性。通过实验,我们证明了这些措施为基于增强数据的相似性和多样性评估DA方法的有效性提供了一个框架。
  • 2)我们的定量度量制定了DA技术的相似性和多样性度量。通过将我们的量化结果与DA方法的实际有效性进行比较,我们发现相似性和多样性的重要性在不同的数据集中有所不同。
  • 3)所提出的措施是在特征空间而不是原始像素空间中进行的,这有助于解释为什么一些视觉上无意义的数据增强方法仍然有效。
  • 4)虽然性能最好的DA方法在不同的数据集中有所不同,但我们的相似性-多样性平面表明,这些方法中的大多数都集中在一个特定的区域内,即“日期间隔”。该区间包括具有实现最佳性能的最高潜力的DA方法。
  • 5)我们的研究有可能更全面地了解DA方法背后的机制,并指导DA方法的设计和参数调整。此外,我们的研究可以为增强方法的有效性提供有效的初步验证,在大规模模型训练中节省计算资源和时间成本。

2. Related work

2.1. Basic data augmentation

数据扩充是一种广泛使用的提高DNN泛化能力的技术。传统的DA方法通过旋转、翻转、平移、随机裁剪等图像操作模拟真实场景数据来生成增强数据。例如,随机裁剪和水平翻转是训练深度模型最常用的数据增强。这些经典方法是获得高度广义深度模型的基础。

更先进的DA方法,如Mixup[15]和CutMix[21],将两个或多个图像或图像的子区域组合为一个。这些方法修改输入图像和标签以融合来自多个图像的信息,并可以通过提供不同的训练样本来提高模型的泛化能力。最近,研究人员强调了遮挡在模型泛化中的重要性,并提出了一些基于图像的方法,包括RandomErasing[22]、Cutout[8]、Hide-and-Seek(HaS)[24]和GridMask[6]。这些方法用一些特定的值代替训练样本中的随机补丁,可以降低模型的灵敏度,增加感知场,提高泛化性能。由于遮挡可能会引入分布偏移并去除图像中的一些关键区域,KeepAugment[23]在增强过程中使用显著性图来检测和保留关键区域。

数据扩充研究的另一个方向是将集成学习的力量与数据扩充结合起来[25-27]。基于集成的DA通常使用多个模型来指导或优化增强数据的生成。我们的工作可以应用于这种方法,以进一步优化和评估DA技术的选择和组合。

2.2. Automated data augmentation

此外,已经提出的自动数据增强,包括AutoAugment[3]、Fast AutoAugment[28]和AWS[29],它们基于一些度量(例如,训练模型的测试准确性)自动搜索增强策略。具体而言,AutoAugment[3]利用强化学习在各种图像数据集上找到DA操作的最佳组合的现有策略。RandAugment[4]利用网格搜索来选择并将增强变换的组合应用于训练图像,以提高模型的鲁棒性。Fast AutoAugment[28]的动机是训练数据集和测试数据集之间的密度匹配,并提出了一种仅用于推断的度量来评估数据增强。AWS[29]设计了一种基于增广的权重共享策略来搜索增广方法。这些自动数据扩充方法引入了评估数据扩充技术的概念,但这种评估是基于模型训练或通过使用测试集进行的,因此缺乏可解释性和实用性(因为测试集在实践中是看不见的)。相反,我们的工作旨在将数据增强方法的有效性分解为可解释的相似性和多样性度量,从而全面量化DA方法的有效度。

2.3. Evaluation of data augmentation

在各种DA方法中,这些方法有效性的机制尚不完全清楚。为了更好地了解DA对DNN性能的影响,最近的一项研究[16]首先提出了一项关于affinity and diversity的实证研究。affinity是在干净数据和增强验证集上测试的模型的准确性之间的差异。它可以被看作是由增广引起的分布变化的一种度量。具体而言,affinity定义如下:

<think>Hmm, the user is asking about the specific error "ExecutorLostFailure (executor 38 exited caused by one of the running tasks)" in Spark. Let me analyze this step by step based on the provided references and my knowledge. First, looking at references [1] and [2], both clearly point to memory issues as the primary cause for this type of error. The key phrase is "Container killed by YARN for exceeding memory limits" which indicates physical memory overusage. Reference [1] mentions 34.4GB used out of 34.3GB limit - that's a classic memory overflow scenario. Reference [3] gives more dimensions to consider. While it confirms memory issues (OOM), it also suggests looking at business logic aspects like data skew, useless null values, and full table scans. The code-level suggestions about avoiding unnecessary cache() and using broadcast joins are particularly insightful for prevention. Wait, reference [5] adds another angle - resource starvation due to high machine load. The phrase "failed but eventually completes" suggests transient resource contention rather than permanent failure. This means we should consider both memory configurations and cluster workload patterns. The user specifically mentions executor 38, but the references suggest this isn't executor-specific. The solution approach should be systematic: first verify memory settings (especially executor.memoryOverhead), then check for data skew, before investigating cluster resource health. Interestingly, reference [4] about multiple SparkContexts seems unrelated here - good to note but probably not the cause. The user seems experienced enough to recognize this is a runtime error rather than configuration conflict. The user's phrasing suggests they've seen this error repeatedly ("executor 38" implies specific occurrence) and want root cause analysis. Since they're troubleshooting a production issue, I should prioritize actionable solutions over theoretical explanations. The three-pronged approach in my response (memory tuning, data optimization, resource monitoring) covers all bases from the references while being practical to implement. </think>基于引用内容,"ExecutorLostFailure (executor 38 exited caused by one of the running tasks)" 错误的根本原因主要是 **内存资源超限**,以下是具体分析和解决方案: ### 🔍 核心原因 1. **内存溢出 (OOM)** [^1][^2][^3] - YARN 监控到容器物理内存超限(例如:34.4GB/34.3GB) - 常见触发场景: ```bash Reason: Container killed by YARN for exceeding memory limits ``` - 根源:Executor 的 JVM 堆外内存(Off-Heap)或物理内存超出 YARN 配置的容器上限 2. **资源竞争引发的心跳丢失** [^5] - 机器资源过载导致 Executor 无法按时发送心跳 - 表象:任务间歇性失败但最终可能完成 ### 🛠️ 解决方案(按优先级排序) #### ✅ 第一优先级:调整内存配置 ```ini # 增加堆外内存比例 (默认是 executorMemory * 0.1) spark.yarn.executor.memoryOverhead = [原值*1.2~1.5] # 示例:若原 executorMemory=10G,建议设置 spark.yarn.executor.memoryOverhead = 2G ``` > **原理**:Spark 的堆外内存用于 Native 操作(如 shuffle、网络传输),未计入 JVM 堆内存[^1][^2] #### ✅ 第二优先级:优化任务逻辑 1. **过滤无效数据** [^3] - 移除空值/无效分区数据 - 避免全表扫描:`WHERE` 子句强制使用分区字段 2. **解决数据倾斜** [^3] - 对倾斜 Key 加盐(salt)分散处理 - 启用自适应查询:`spark.sql.adaptive.skewJoin.enabled=true` 3. **广播小表**(<100MB) ```sql SELECT /*+ BROADCAST(dim_table) */ * FROM fact_table JOIN dim_table ... ``` #### ⚠️ 备选方案(需谨慎) ```ini # 关闭 YARN 虚拟内存检查 (可能掩盖真实问题) yarn.nodemanager.vmem-check-enabled = false ``` > 仅当确认是虚拟内存误报时使用(参考 YARN-4714[^2]) ### 📉 资源层检查 1. **监控集群负载** [^5] - 确认节点是否因 CPU/内存过载导致心跳超时 - 通过 YARN ResourceManager 查看节点资源使用率 2. **调整 Executor 规格** - 减少单个 Executor 核数:`spark.executor.cores=4 → 2` - 增加 Executor 数量:`sppark.executor.instances=20 → 40` ### 📌 关键排查步骤 1. **检查日志中的 OOM 证据**: ```bash Container killed on request. Exit code 137 # Linux OOM 强制终止信号[^3] ``` 2. **分析 GC 日志**: ```ini spark.executor.extraJavaOptions=-XX:+PrintGCDetails ``` > 建议优先尝试 **内存配置调整+数据倾斜优化** 组合方案(覆盖 80% 案例),若仍失败再深入排查资源竞争问题[^3][^5]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值