Dreaming to Distill: Data-free Knowledge Transfer via DeepInversion

这篇博客介绍了DeepInversion和AdaptiveDeepInversion技术,用于在没有原始训练数据的情况下进行知识迁移。DeepInversion通过改进DeepDream的图像生成过程,合成高质量的类条件图像,而AdaptiveDeepInversion则通过引入竞争正则化增加图像多样性。实验表明,这种方法在剪枝、知识迁移和增量学习等任务上取得了显著效果,生成的图像在视觉保真度上优于其他方法。

Dreaming to Distill: Data-free Knowledge Transfer via DeepInversion

1. 论文信息

论文标题

Dreaming to Distill: Data-free Knowledge Transfer via DeepInversion

论文来源

CVPR2020, https://arxiv.org/abs/1912.08795

代码

https: //github.com/NVlabs/DeepInversion

2. 背景梳理

将所学知识从一个训练好的神经网络转移到一个新的神经网络具有许多吸引人的应用。此类知识迁移任务的方法基本都基于知识蒸馏。然而,这些工作假设先前使用的训练数据集,或者代表先前训练数据集分布的一些真实图像可用。考虑到数据集可能规模大、难以传输、管理,且涉及到数据隐私问题,先前使用的训练数据集可能无法获得。

在缺乏原先训练数据的情况下,一个有趣的问题就出现了——如何从训练的模型中恢复训练数据并将其用于知识迁移。DeepDream[1] 合成或变换输入图像,使其在给定模型的输出层中对选定的类别产生高输出响应。这个方法对输入(随机噪声或者自然图像)进行优化,使用一些正则项,在保持选定的输出激活是固定的情况下,让中间特征无约束。但以这种方式生成的图像,缺少自然图像的统计特征,很容易被识别为非自然图像,并且对知识迁移不是很有用。

论文贡献

  • 提出了DeepInversion,用于为分类模型合成class-conditioanl的图像。此外,通过Adaptive DeepInversion来利用学生与教师的分歧,提高合成图像的多样性。
  • 我们将DeepInversion应用于无数据剪枝、无数据知识迁移和增量学习。

3. 方法

3.1 背景

知识蒸馏

给定教师模型 pTp_TpT 和数据集XXX,学生模型的参数WSW_SWS 可以通过下式学到
min⁡WS∑x∈XKL(pT(x),pS(x)) \min_{W_S}\sum_{x\in X}KL(p_T(x),p_S(x)) WSminxXKL(pT(x),pS(x))
其中pT(x)=p(x,WT)p_T(x)=p(x,W_T)pT(x)=p(x,WT)pS(x)=p(x,WS)p_S(x)=p(x,W_S)pS(x)=p(x,WS)是教师和老师的输出。

DeepDream

给定一个随机初始化的输入x^∈RH×W×C\hat{x}\in R^{H\times W\times C}x^RH×W×C和一个任意的目标标签yyy,通过优化以下目标来合成图片:
min⁡x^L(x^,y)+R(x^), \min_{\hat{x}} \mathcal{L}(\hat{x},y)+\mathcal{R}(\hat{x}), x^minL(

2439: 12-29 21:10:57.285353 3677 3677 D SystemUi--Keyguard: FpUnlockHelper-->checkFpMode = STOP 2443: 12-29 21:10:57.286151 3677 3677 D FingerprintManager: cancelAuthentication called by com.android.systemui 2446: 12-29 21:10:57.286931 3003 4586 D FingerprintProvider/default: [cancelAuthentication] sensorId: 1 ,token: android.os.BinderProxy@6a48479 ,requestId: 4574 2447: 12-29 21:10:57.286953 3003 4586 D Biometrics/FingerprintProvider/FingerprintServiceProviderExtImpl: [handleCancelAuthentication] opPackageName = com.android.systemui, clientToken = android.os.BinderProxy@6a48479, passedInToken = android.os.BinderProxy@6a48479 2457: 12-29 21:10:57.289057 3003 3465 D BiometricScheduler: cancelAuthenticationOrDetection, requestId: 4574 2466: 12-29 21:10:57.289920 3677 3677 I SystemUi--Keyguard: FpUnlockHelper-->notifyFingerprintAuthHasStopped reason: keyguard is goingAway & deviceInteractive 2502: 12-29 21:10:57.295089 3003 4586 V WindowManager: State movement: ActivityRecord{97561029 u0 com.android.launcher/.Launcher t6} from:STOPPED to:RESUMED reason:resumeTopActivity 2600: 12-29 21:10:57.300382 2366 2756 V [FP_HAL][IFingerprintCore]: [captureImg] enter 2602: 12-29 21:10:57.300389 2366 2756 I [FP_HAL][IFingerprintCore]: [captureImg] mode=3, retry_index=0 2709: 12-29 21:10:57.307048 3677 11270 D FingerprintManager: onUdfpsPointerDown sensorId: 1 2740: 12-29 21:10:57.312958 3003 4586 D ActivityTaskManager: addStartingWindow for ActivityRecord{97561029 u0 com.android.launcher/.Launcher t6}, mainWin=Window{cfa126 u0 com.android.launcher/com.android.launcher.Launcher}, mVisible=false, mVisibleRequested=true, drawn=false, mDestroying=false, state=RESUMED, isKeyguardLocked=false, isKeyguardGoingAway=true 2974: 12-29 21:10:57.361406 2366 2756 I [FP_HAL][IFingerprintCore]: [captureImg] 1st need_transmit_last_touch_up=0 2975: 12-29 21:10:57.361413 2366 2756 I [FP_HAL][IFingerprintCore]: [captureImg] need_retry_capture_for_self_cali=0 2976: 12-29 21:10:57.361418 2366 2756 D [FP_HAL][IFingerprintCore]: [captureImg] result_type=0, result_value=0 2977: 12-29 21:10:57.361422 2366 2756 I [FP_HAL][IFingerprintCore]: [captureImg] ignore_too_fast=0 3033: 12-29 21:10:57.369910 2366 2756 V [FP_HAL][IFingerprintCore]: [captureImg] exit 3174: 12-29 21:10:57.409454 2366 2756 V [FP_HAL][IFingerprintCore]: [authenticateCompare] enter 3234: 12-29 21:10:57.451439 3003 3373 I KEYLOG_OplusKeyEventUtil: mIsPowerKeyDown =true 3560: 12-29 21:10:57.509879 3677 3804 I SystemUi--Keyguard: KeyguardViewMediator-->isKeyguardGoingAwayToShade,isGoingToNotificationShade:false,getWakeAndUnlocking:false,mWallpaperSupportsAmbientMode:false 3720: 12-29 21:10:57.535686 3677 3677 I SystemUi--Keyguard: KeyguardRapidUnlockUtils-->setVisibilityBySurfaceControl isShow: false, view: com.android.systemui.shade.NotificationShadeWindowView{d65f1cf V.E...... ........ 0,0-720,1570 #7f0a0721 app:id/legacy_window_root aid=173 alpha=1.0 viewInfo = } 3728: 12-29 21:10:57.536792 3677 3677 I SystemUi--Keyguard: OplusPowerBlockController-->updatePowerBlock mFpAuthInScreenOff:false, mScreenTurnedOff:false, dreaming=false, fpUnlockingInScreenOff:false, screenFinishedSleep:false, screenRealSleep:false, mInOccluding:false, hasResumeActivity:false, isKeyguardGoingAway:true, reason:UnlockAnimationStarted 3857: 12-29 21:10:57.560169 3677 3677 D SystemUi--Keyguard: FpUnlockHelper-->checkFpMode = STOP分析该段日志为什么有两次checkFpMode = STOP的打印
最新发布
01-01
```markdown ### 问题分析:为什么日志中出现了两次 `checkFpMode = STOP` 的打印? 从提供的日志片段可以看出,**确实存在两次 `FpUnlockHelper-->checkFpMode = STOP` 的调用记录**。虽然日志未完整显示第一次的打印行(只有后续调用栈中的相关信息),但结合上下文可明确推断出这两次 `STOP` 状态的触发时机和原因不同。 --- #### 🔍 日志时间线与关键事件梳理 | 时间戳 | 关键日志 | 说明 | |--------|--------|------| | `21:10:57.285353` | `FpUnlockHelper-->checkFpMode = STOP` | 第一次进入 `STOP` 模式 | | `21:10:57.286151` | `cancelAuthentication called by com.android.systemui` | 主动取消指纹认证 | | `21:10:57.300382` | `[captureImg] enter` | 用户触碰指纹 → 启动采图 | | `21:10:57.307048` | `onUdfpsPointerDown sensorId: 1` | 上报触摸事件 | | `21:10:57.369910` | `[captureImg] exit` | 采集完成 | | `21:10:57.409454` | `[authenticateCompare] enter` | 进入比对阶段 | | `21:10:57.536792` | `isKeyguardGoingAway:true, reason:UnlockAnimationStarted` | 锁屏正在退出动画中 | | `21:10:57.560169` | `FpUnlockHelper-->checkFpMode = STOP` | 第二次进入 `STOP` 模式 | --- ### ✅ 两次 `STOP` 的根本原因解析 #### 🟢 第一次 `checkFpMode = STOP`(约 `21:10:57.285`) - **触发时机**:锁屏界面即将关闭前 - **前置动作**: ``` Keyguard going away + deviceInteractive = true ``` - **系统行为**: - 系统检测到用户已通过滑动、人脸识别或其他方式解锁 - 调用 `stopListeningForFingerprint()` 取消防伪监听 - `FpUnlockHelper.checkFpMode()` 返回 `STOP` - **目的**:防止在锁屏消失后继续运行指纹服务,节省功耗并避免误识别 > ⚠️ 此时指纹认证已被取消,但之后又发生了手指触摸(见下文) --- #### 🔴 第二次 `checkFpMode = STOP`(约 `21:10:57.560`) - **触发时机**:指纹已经完成采集和比对,系统处于“解锁动画执行后期” - **关键背景**: - 尽管此前取消了认证请求(第一次 `STOP`),但用户仍触碰了指纹传感器 - 触摸事件触发了新的 `captureImg` 和 `onUdfpsPointerDown` - HAL 层完成图像采集和特征比对(`authenticateCompare`) - **为何再次判断为 `STOP`?** - 此时 `keyguardGoingAway=true` 依然成立(仍在退出动画) - 即便有指纹输入,系统也不会重新启动认证流程 - 因此再次查询模式时仍返回 `STOP` > 📌 注意:第二次 `STOP` 并不表示“取消认证”,而是表明当前环境**不允许启动或继续指纹认证流程** --- ### 🧩 特殊情况解释:为何取消认证后还能采图? 这是一个看似矛盾但实际上合理的设计逻辑: | 阶段 | 行为 | |------|------| | 1️⃣ 认证取消 | Framework 层调用 `cancelAuthentication`,停止接收结果回调 | | 2️⃣ 手指触碰 | 指纹传感器硬件中断仍有效,HAL 层继续响应触摸 | | 3️⃣ 图像采集 | 驱动层启动 `captureImg` 流程(这是低级操作) | | 4️⃣ 结果处理 | 由于没有有效的认证会话,比对结果被丢弃,不会上报成功/失败 | 👉 **结论**: - `cancelAuthentication` 是 Framework 控制层面的操作 - `captureImg` 是 HAL/驱动层面的响应 - 两者异步,因此可能出现“先取消、后采图”的现象 --- ### ✅ 总结:两次 `STOP` 的本质区别 | 次数 | 触发条件 | 含义 | 是否正常 | |------|---------|------|----------| | 第一次 | 锁屏退出,主动取消认证 | 停止监听指纹输入 | ✅ 正常 | | 第二次 | 解锁动画进行中,用户触碰指纹 | 不允许重启认证 | ✅ 正常 | > 💡 **根本原因**:两次 `checkFpMode = STOP` 都是因为 `keyguardGoingAway = true`,即系统已决定退出锁屏界面,无论是否有新指纹输入,都不再进入认证状态。 --- ### 🛠️ 延伸知识点 - **指纹认证的生命周期由锁屏状态控制**:只要 `keyguardGoingAway` 为真,`checkFpMode` 必然返回 `STOP`。 - **HAL 层采图 ≠ 认证生效**:即使底层完成了图像采集和比对,若上层无有效会话,则结果无效。 - **用户体验优化设计**:允许在退出动画期间采集指纹,是为了实现“快速返回锁屏时立即可用”的体验(下次亮屏无需等待初始化)。 ``` ### 知识点 - **锁屏状态主导指纹模式**:`keyguardGoingAway` 为 true 时,`checkFpMode` 强制返回 `STOP`,禁止认证。 - **认证取消与采图异步**:Framework 取消认证后,HAL 仍可响应物理触摸并采集图像。 - **结果不上报即无效**:无活跃会话时,即使完成比对,结果也会被丢弃,不触发解锁。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值