QuoTe: Quality-oriented Testing for Deep Learning Systems

本文提出了一种新的深度学习测试框架QuoTe,专注于质量导向,通过量化测试用例对模型属性增强的价值和模型改进的收敛性,以提高模型鲁棒性和公平性。与传统的神经元覆盖率方法不同,QuoTe考虑了再训练过程,弥补了现有测试方法与模型质量提升之间的差距。
部署运行你感兴趣的模型镜像

Quote:深度学习系统的质量导向测试

摘要:

        一个流行的方向是深度学习测试——也就是说,给定测试的属性,通过模糊测试或借助某些测试指标的引导搜索来发现深度学习系统的缺陷。然而,最近的研究表明,大多数现有的DL测试方法通常使用的神经元覆盖度量并不一定与模型质量相关(例如,最常被研究的模型属性是鲁棒性),并且也不是测试后对模型质量的置信度的有效度量。在这项工作中,我们通过提出一种名为 QuoTe(即面向质量的测试)的新颖测试框架来解决这一差距。 QuoTe 的关键部分是对(1)每个测试用例在增强相关模型属性(通常通过再训练)方面的价值和(2)模型属性改进的收敛性的量化度量。 QuoTe利用提议的度量标准来自动选择或生成有价值的测试用例,以提高模型的鲁棒性和公平性。提议的度量标准也是一种轻量级但强大的指标,可以用来衡量改进的聚合程度。

介绍:

        在测试DL系统的给定模型属性(如健壮性和公平性)时,有两个关键因素。第一个关键因素是测试充分性度量(为了简单,我们称之为测试度量),它用于评估测试用例或测试套件的质量。多种稳健性测试指标被提出,包括神经元覆盖率[55]、多粒度神经元覆盖率[45]、MC/DC覆盖率[64]、组合覆盖率[44]和惊喜充分性[35]。通常的思路是在基于神经元网络模型的不同抽象层次所定义的某个子空间中尽可能地探索多样性,如神经元激活[55]、神经元激活模式[45]、神经元激活条件[64]、神经元激活向量[35]。第二种方法是用于生成测试用例的方法,通常是在测试度量标准的指导下对一组种子输入进行突变。现有的测试用例生成技术,如DeepXplore[55]、DeepConcolic[64]、DeepHunter[81]、DeepCT[44]、ADAPT[40]等,大多是为了提高神经元覆盖率指标而设计的。虽然现有的测试方法在一定程度上有助于暴露DL系统的缺陷,但最近的研究却不幸地发现神经元覆盖度量不利于提高模型的鲁棒性[13,26,43]。因此,与传统的软件测试的情况不同,传统的软件测试在修复了测试中暴露的缺陷之后,软件质量肯定会得到提高,而使用生成的测试用例进行再训练之后,人们可能不容易提高DL系统的质量。

        在本工作中,我们提出了一种新的DL测试框架QuoTe(即面向质量的测试)来解决现有DL测试方法的局限性,该框架设计时考虑了DL模型质量增强,旨在弥合测试和模型质量增强之间的差距。如图1所示,QuoTe与现有的神经元覆盖指导测试工作在以下几个重要方面有所不同。第一,以质量为导向。对于给定的属性(例如,健壮性或公平性),QuoTe将用户定义的关于该属性的需求作为输入,并将再训练过程集成到测试管道中。此要求在之前是为了保证质量而提供的。例如,用户可能要求“增强的模型应该减轻80%的对抗实例(可能来自独立验证)”。QuoTe然后通过生成测试用例和对模型进行再训练以满足需求,迭代地改进模型的质量。其次,在引用中,我们提出了一组新的轻量级度量标准,它们与用于测试的属性密切相关。度量标准可以定量地度量用于模型增强的每个测试用例的相关性,并被设计为有利于能够显著提高模型质量的测试用例。

背景:

        测试用例选择:测试用例选择对于在有限的再训练预算下改善模型属性和减少标记工作至关重要 。选择的关键是定量衡量每个测试用例的价值。 DeepGini [17] 最近被提出选择最有可能被模型错误分类的信息最丰富的测试用例来指导模型再训练过程,这被证明比基于神经元覆盖的指标在提高模型鲁棒性方面更有效。 MCP [61] 是另一种基于不确定性的度量,它通过 top-2 概率选择接近决策边界的测试用例。利用包括 LSA(基于可能性)和 DSA(基于距离)在内的惊喜充分性 指标来选择具有较大惊喜值的测试用例 [7]。 PRIMA [75]被提出通过基于设计的变异规则的智能变异分析来选择测试用例。最近的一项工作 DAT [28] 对不同数据分布下模型增强的几种选择指标的性能进行了实证研究。

                模型再训练被证明是提高模型质量的有效方法,通过修正模型对测试算法(例如DeepXplore [55] 和 DeepTest [66])生成的测试用例的预测结果。重新训练通常是通过将暴露漏洞的测试用例添加到原始训练数据集中来完成,而模型结构和损失函数等训练设置保持不变。例如重新训练 [3, 16, 17] 或修复 [42, 84]。这种改进是通过修补传统软件测试中发现的错误来保证的(假设回归错误并不常见)——也就是说,传统软件的错误揭示测试的有用性不需要任何理由,而对于深度学习系统来说,测试的有用性是必要的。只能通过考虑再训练步骤来判断情况。换句话说,每个测试用例通过再训练对质量改进的贡献可能有很大不同。

        验证集的选择:Dv的选择对于模型质量的实际评估至关重要,并且如何形成Dv仍然是一个开放的研究问题。在实践中,用户经常采用不同的对抗性攻击(例如,用于鲁棒性的 PGD [48] 和用于公平性的 ADF [87])来使用对抗性/歧视性样本构建这样的验证集。这种经验观点易于测试,有助于 QuoTe 有效比较测试(重新训练)前后模型的质量。此外,它也很实用,因为它将评估与许多现有的对抗性攻击和测试技术联系起来。

模糊算法:

您可能感兴趣的与本文相关的镜像

TensorFlow-v2.15

TensorFlow-v2.15

TensorFlow

TensorFlow 是由Google Brain 团队开发的开源机器学习框架,广泛应用于深度学习研究和生产环境。 它提供了一个灵活的平台,用于构建和训练各种机器学习模型

<think>我们正在解决Gradle内部项目互相引用时出现无法解析 com.cpq:sf-cpq-quote-api:6.0.2 的问题。 根据错误信息,项目`sf-cpq-sys-manage`的子模块`sf-cpq-sys-manage-server`在main配置中无法解析依赖`com.cpq:sf-cpq-quote-api:6.0.2`。 可能的解决方案: 1. 确保被引用的项目(`sf-cpq-quote-api`)已经正确构建并发布到本地仓库,或者确保在多项目构建中正确配置了依赖关系。 2. 检查项目的仓库配置,确保能够找到该依赖。如果该依赖是公司内部的私有库,需要确保仓库地址正确且网络可访问。 根据引用[5]的提示,我们可以添加国内镜像仓库来加速公共依赖的下载,但如果是私有依赖,则需要配置私有仓库地址。 具体步骤: 步骤1:确认依赖是否存在 首先,确认`com.cpq:sf-cpq-quote-api:6.0.2`这个依赖是否存在于你的仓库中。如果是本地项目,确保该项目已经在settings.gradle中正确包含,并且已经定义了项目依赖。 步骤2:检查多项目构建的设置 如果是多项目构建,确保在根项目的settings.gradle文件中包含了所有子项目。例如: ```groovy include ':sf-cpq-quote-api' include ':sf-cpq-sys-manage:sf-cpq-sys-manage-server' ``` 步骤3:检查依赖项目的构建配置 在需要依赖`sf-cpq-quote-api`的项目中(即`sf-cpq-sys-manage-server`),确保在build.gradle文件中正确声明了依赖: ```groovy dependencies { implementation project(':sf-cpq-quote-api') } ``` 注意:如果`sf-cpq-quote-api`项目不在同一个根项目下,而是作为单独的模块,你可能需要先将其发布到本地Maven仓库,然后在`sf-cpq-sys-manage-server`中通过`implementation 'com.cpq:sf-cpq-quote-api:6.0.2'`来引用,同时确保仓库配置正确。 步骤4:配置仓库 如果该依赖是发布在私有仓库中,则需要在根项目的build.gradle或项目的build.gradle文件中添加私有仓库地址。例如: ```groovy repositories { maven { url 'https://your.private.repo/repository/maven-public/' // 如果需要认证 credentials { username = 'user' password = 'password' } } // 或者添加阿里云镜像加速公共库 maven { url 'https://maven.aliyun.com/repository/public' } maven { url 'https://maven.aliyun.com/repository/google' } maven { url 'https://maven.aliyun.com/repository/jcenter' } mavenLocal() mavenCentral() } ``` 步骤5:检查依赖版本 确保版本号`6.0.2`确实存在,并且没有被错误地拼写。 步骤6:检查网络和代理 如果依赖在远程仓库,检查网络连接,以及是否需要配置代理(参考引用[2]的解决方法)。在gradle.properties文件中配置代理: ```properties systemProp.http.proxyHost=proxy.example.com systemProp.http.proxyPort=8080 systemProp.https.proxyHost=proxy.example.com systemProp.https.proxyPort=8080 ``` 步骤7:清理和重新构建 尝试清理项目并重新构建: ``` ./gradlew clean build ``` 步骤8:发布到本地仓库 如果`sf-cpq-quote-api`是本地项目,你可以将其发布到本地Maven仓库: 在该项目的build.gradle中添加: ```groovy apply plugin: 'maven-publish' publishing { publications { maven(MavenPublication) { groupId = 'com.cpq' artifactId = 'sf-cpq-quote-api' version = '6.0.2' from components.java } } } ``` 然后运行`publishToMavenLocal`任务将其发布到本地仓库。然后在依赖项目中,确保添加了`mavenLocal()`仓库。 总结:根据以上步骤逐一排查,特别是确保项目依赖关系正确配置,仓库地址正确,且依赖确实存在。 如果问题仍然存在,请提供更多信息,例如项目结构、构建脚本片段等。 相关问题: 1. 如何在Gradle中配置私有仓库认证? 2. Gradle多项目构建中如何正确设置项目依赖? 3. 如何将Gradle项目发布到本地Maven仓库? 4. Gradle构建中如何配置代理? 注意:在引用中,我们看到类似问题(引用[1]和[3])都是因为找不到依赖,解决方案通常是添加仓库或确保依赖存在。引用[5]提供了添加国内镜像仓库的方法,这在下载公共依赖时非常有用。 </think>### 解决Gradle内部项目引用错误:`Could not resolve com.cpq:sf-cpq-quote-api:6.0.2` #### 问题分析 当Gradle内部项目互相引用时出现`Could not resolve com.cpq:sf-cpq-quote-api:6.0.2`错误,通常由以下原因导致: 1. **本地依赖未发布**:被引用的模块`sf-cpq-quote-api`未发布到本地仓库 2. **仓库配置缺失**:未配置私有仓库或镜像仓库地址 3. **版本不一致**:依赖版本与实际构建版本不匹配 4. **网络/代理问题**:无法访问远程仓库(如公司私有仓库) --- #### 解决方案 ##### 1. 确认本地模块依赖关系(推荐方案) 在`sf-cpq-sys-manage-server`的`build.gradle`中,**使用项目路径引用代替模块坐标**: ```groovy dependencies { // 替换 implementation 'com.cpq:sf-cpq-quote-api:6.0.2' implementation project(':sf-cpq-quote-api') // 确保项目路径正确 } ``` **关键验证**: 1. 检查根目录`settings.gradle`是否包含两个模块: ```groovy include ':sf-cpq-quote-api', ':sf-cpq-sys-manage:sf-cpq-sys-manage-server' ``` 2. 确保模块的目录结构与声明一致: ``` ├── sf-cpq-quote-api │ └── build.gradle ├── sf-cpq-sys-manage │ └── sf-cpq-sys-manage-server │ └── build.gradle └── settings.gradle ``` ##### 2. 配置镜像仓库(若需远程依赖) 在**根项目**的`build.gradle`中添加阿里云镜像(引用[5]): ```groovy allprojects { repositories { maven { url 'https://maven.aliyun.com/repository/public' } maven { url 'https://maven.aliyun.com/repository/google' } maven { url 'https://maven.aliyun.com/repository/jcenter' } mavenLocal() // 优先使用本地仓库 // 添加公司私有仓库(若有) maven { url 'https://your.company.repo/repository/maven-public' credentials { username = 'user' password = 'password' } } } } ``` ##### 3. 发布模块到本地仓库 在`sf-cpq-quote-api`的`build.gradle`中添加: ```groovy plugins { id 'maven-publish' } publishing { publications { maven(MavenPublication) { groupId = 'com.cpq' artifactId = 'sf-cpq-quote-api' version = '6.0.2' from components.java } } } ``` 执行命令发布到本地仓库: ```bash ./gradlew :sf-cpq-quote-api:publishToMavenLocal ``` ##### 4. 代理配置(若存在网络限制) 参考引用[2],在`gradle.properties`中配置代理: ```properties systemProp.https.proxyHost=your.proxy.com systemProp.https.proxyPort=8080 systemProp.https.nonProxyHosts=*.company.com ``` ##### 5. 清理缓存并重试 ```bash # 清理Gradle缓存 ./gradlew clean --refresh-dependencies ``` --- #### 验证流程 1. 确保`sf-cpq-quote-api`模块已成功构建(`./gradlew :sf-cpq-quote-api:build`) 2. 检查本地仓库是否存在该依赖: - 路径:`~/.m2/repository/com/cpq/sf-cpq-quote-api/6.0.2/` 3. 运行主项目构建:`./gradlew :sf-cpq-sys-manage:sf-cpq-sys-manage-server:build` > **关键提示**:优先使用`project(':module')`方式引用内部模块,避免不必要的远程依赖解析[^4]。 --- ### 相关问题 1. 如何在Gradle多模块项目中正确声明子模块依赖? 2. 配置Gradle私有仓库认证时需要注意哪些安全事项? 3. Gradle的`publishToMavenLocal`和`install`任务有何区别? 4. 如何强制刷新Gradle依赖缓存解决版本冲突问题? [^1]: 引用[1]中提到的仓库配置文档 [^2]: 引用[2]中的代理配置方案 [^4]: 引用[4]关于Gradle依赖声明方式的说明 [^5]: 引用[5]提供的镜像仓库配置方案
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值