【前言】
现在的NEURAL ARCHITECTURE SEARCH(NAS)基本都采用权重共享的supernet方案，但是其中原理几何，有什么局限，鲜有人提及，权重分配并没有理论保障，其影响也没有得到很好的研究，大部分同学都是用的爽就行，接下来从两篇同个实验室的论文来看看权重共享机制，到底怎么影响NAS搜索到的架构。以下文章中说法上，child model = 子架构 = 子模型。
注：以下图片都来自论文原文、文字基于原文翻译和个人主观理解，作者水平很差，大家手下留情，如有错误欢迎大家指正，拜谢
DEEPER INSIGHTS INTO WEIGHT SHARING IN NEURAL ARCHITECTURE SEARCH
作者来自Microsoft
论文地址：https://arxiv.org/abs/2001.01431
【简介】
基于对整个大搜索空间有效的方案对于小空间也一样有效的思想，和基于计算成本的考虑，本文用了一个非常小的搜索空间，只有4*4*4种子模型，来训练一个超网络，顺便探究权重共享到底怎么样影响到搜索到的架构。
观察到几点：
1、子模型的排序在不同每次训练都不太一样，波动大，事实上，不稳定性不仅普遍存在于不同的运行次数中，也存在于同一次运行中连续的训练时期epochs。
2、然后，适当的减小权重共享的密度，可以更稳定地找到更好的子模型。下图是整个搜索空间的示意图，基于DARTS。采样用uniformly sample，每个batch只训1个子模型。数据集使用CIFAR-10，train from scratch 的超参设置和训超网络的一致，batch size 256，学习率余弦下降，epochs 200。
【几个需要解决的问题】
1、发现的子模型与搜索空间中最好的子模型的准确性相差多远？
2、在多次搜索过程中能够稳定地找到最好的子模型吗？
3、权重共享如何影响发现的子模型的准确性和稳定性？
【本文用到的评价指标】
1、S-Tau：度量从多个实例生成的模型排序的稳定性，
2、GT-Tau：可以理解为kendall Tau，可以理解为超网络的子模型架构排序和这些架构的真实acc排序的相关性
3、TnR：它是用来衡量一个实例在寻找最优秀的子模型方面有多出色。TnR是通过从一个实例生成的排序中中选择前n个子模型，并找出这n个子模型的最优ground truth 排序
【权重共享的训练方式稳定吗】
就像一个好的深度学习模型可以不断收敛到一个具有相似性能的点一样，权重共享NAS也期望具有这样的稳定性，这里做了几个实验，初始化不同（不同的seed）、重复训练固定排序的64个子模型、random训练64个子模型。【这里好像没有保证每次训练的batch一致，也存在一定随机性其实】，希望它们会在相同的epochs后产生相同的排序，从下表结果来看，第一列，不同的初始化，对权重共享的训练影响很大，最大最小的Tau差很多，不同的训练顺序对排序的影响也很大。
从另一个角度，单个实例连续的epoch，其实子模型的排序也在波动，如下图：
从现象上看，超网络产生的排名似乎没办法指导搜索到一个好的子模型，并且超网络排序No.1的子模型多半也不是真的好，既然多个实例显示出了很大的差异。总的来说，同一实例最后几个epoch中生成的rank是高度不稳定的，这说明选择不同的epoch来生成rank对最终获得的性能有很大的影响啊。
在顺序/洗牌这个实验中，因为重复了10次，所以有10次的rank表，对每个表看看每次的rank怎么样？下图可以看到虽然权重共享是不稳定的，但生成的排名可以用来快速过滤出表现不佳的子模型，并可能用于进行搜索空间修剪，例如，逐步丢弃排名最低的子模型，只进一步训练排名最高的，就是权重共享还是有效的
选择初始化不同的这组实验详细来看看，在不同的epoch阶段，看看权重共享时候的每个子模型的波动情况，再看看如果把这些子模型继承超网络权重后finetune一定step后表现怎么样，如下图，鲜艳颜色的线代表的是ground truth高的子模型，深颜色的线代表ground truth低的子模型架构，从图上可以看到，无论是在第100epoch还是在最后200epoch的时候，在训练共享权重的超网络时候，每个架构的acc波动很大，并且在某些step，有些差的模型acc还比f好的模型acc高，而在finetune的时候，好的坏的倒是很确定，也正确。
可以感觉到不同架构训练再相互干扰并且更加厉害的是下图，发现如果按固定顺序架构训练，可以看到呈现一定的周期性，大概就是刚训的架构acc会上去，然后因为又训了别的架构，权重共享相互影响下，这个架构acc又下去了，当然如果是乱序的话，这个周期性就没有，但是大致也是起起伏伏：
【减小权重共享的密度有用吗】
这里采用两种减小权重共享密度方案、组共享/部分层共享
【组共享】
简单说，把64个训练的架构分m组，每个组间权重共享，不同的组权重不同享权重，这里又有两种分法，一种是random分，看运气，另一种是按相似性分：可以看到随缘分的效果不管分多少组效果都很随缘，甚至更差，按相似性分却在不停的提升：
这里认为说，训练A架构对B架构是促进作用，但是对于C架构却在抑制，选择合理的架构共享权重有利用这些架构更好被训练，【所以是不是也解释了为啥bignas把最大的架构丢进去一起训有效果】
【部分层共享】
当k = 0时，只有前两个conv层是共享的。当k = 4时，除最后的完全连接层外的所有层都被共享。结果也很一目了然，共享层的数目越少，相互影响越小，rank排序更正确
How Does Supernet Help in Neural Architecture Search?
论文地址：https://arxiv.org/abs/2010.08219
论文作者和上面那篇基本一致，同一个团队出的文章。
【核心要点】
1、权重共享对于某些搜索空间效果好，对有些搜索空间无效
2、超网络对某些架构存在偏好
3、通过剪枝搜索空间来增加找到最佳架构的概率
【简介】
超网络毫无疑问是基于在超网络中验证子架构的acc是这个子架构的真实acc这样一个假设，虽然一直被质疑，但是本文通过实验发现确实超网络对某些op、连接和模型尺寸存在偏好。并且发现，权重共享的超网络能够找到排名前10%的架构，但是很难找到最好那个。这文章也是uniformly sample
【实验部分】
【长时间的训练并不能保证一个更好的相关性rank】
直觉上会认为说，超网络训练的越充分，越能够提供一个好的相关性排序，那是如此吗？从下图可以看到，DARTS-CIFAR10在64期训练时相关性达到0.54，但随着训练时间的延长，相关性下降到0.2左右。对于PTB，相关性甚至可能是0。在top-k上也有类似的现象。尽管top-k对相关性的变化不是很敏感，但是当supernet训练时间变长时，所选架构的性能仍然会下降。
从下图也可以发现权重共享的有效性取决于搜索空间，并不是对所有类型的所有空间都有效
【减小权重共享的密度没有用】
像上一篇文章说的，直觉上，不同的架构相互干扰，所以提出了减低权重共享密度的方式来缓解相互干扰的现象 ，但是在同一作者下现在这个结论被推翻了。下图实验表明对于NAS-Bench-101来说，缩小搜索空间到几十倍上百倍其实对于相关性来说并没有起到促进的作用，但是对于NAS-Bench-201还是有用的【这里有疑惑，不是用哪个组共享的方案，划分组来减小权重共享的密度嘛，直接缩减搜索空间还是random肯定起不到好作用吧】
【权重共享存在偏好】
权值共享所带来的偏见似乎是一致的，并且是基于权值共享本身的本质。看格子的深浅分布会发现用256epoch去预测1k/4k都是相关性挺高的
并且，
权重共享偏好大模型，而事实上，具有大量参数(FLOPs)的架构通常具有较好的真实精度，并且上图也显示了NAS-Bench-101的ground truth performance与parameter size的相关性高达0.67【
回顾另一篇论文Prioritized Architecture Sampling with Monto-Carlo Tree Search ，从下图其实就能看到，FLOPs的增加比参数的增加对精度的贡献更大。
】
【权重共享偏好3x3 conv】
下图是supernet性能和ground truth性能之间的关系，显然，权重共享更青睐Conv3x3。幸运的是，具有Conv3x3的架构确实具有相对较好的性能，【我觉得3x3本来就好，也不是超网络刻意偏好】，这就是为什么NAS-Bench-101上的top-k相当好。在NAS-Bench-201上，权值共享仍然倾向于Conv3x3作为连接单元输入节点到输出节点的算子，但几乎所有具有最高ground truth精度的架构都选择跳跃连接，但是超网络觉得跳层没有1x1香，更不如3x3,【我怀疑直接跳层影响到了超网络的训练和参数分布】。
由于确定权重共享的顶层架构比较困难，以往的工作都是将权重共享作为一种修剪最坏的方法，希望改善搜索空间的性能分布，从而增加找到最优的可能性，权重共享在精简后的搜索空间中仍然有效吗?为了回答这个问题，看下图，测试了权重共享的能力，降低搜索空间，总是训练真实acc好的那些架构，但是NAS没有获得更多的收益。虽然top acc确实在上升，相关性系数就很迷，我觉得还是需要smart的裁剪空间方法更重要，
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
评论（0）