AutoNet实战：自动化神经架构搜索与超参数调优指南

过去几个月，我一直在帮一个做工业视觉检测的团队收拾他们的建模流程。问题倒不复杂：样本量不算少，特征也够，但每次换一批新产品，三位工程师就要重新做一轮特征筛选、网络结构选择、超参数调参。两周起步，做出来的模型还经常没法直接复用，换个光照环境就得返工。后来我把整套自动化机器学习（AutoML）流水线搭了进去，其中负责网络结构搜索与自动模型设计的关键组件，就是我们今天要聊的 AutoNet。

AutoNet 一句话概括：它把"设计一个神经网络长什么样、网络该多宽多深、怎么训练才划算"这件事，从人工拍脑袋变成机器在限定范围内搜索。它并不神秘，本质上是把神经网络架构搜索（NAS）、超参数优化（HPO）、训练策略推荐等几类技术揉进了一个可重复执行的流程。这篇内容适合三类人：一是数据团队里被建模周期压得喘不过气的工程师，二是想把 AutoML 工具用在自己的实验流程里、但不想只会点按钮的研究者，三是准备入坑自动化模型设计、想先建立整体认知的同学。我会尽量把原理讲清楚，再给一套可照搬的落地流程和几个真实踩坑记录，聊点搜索之外容易被忽略的事情。

1. 从AutoML的盘子里看AutoNet：它到底顶替了哪几号人力

1.1 传统建模里最耗人的三个动作

模型从数据到上线，传统路径里最消耗人力的不是训练本身，而是三个动作。第一是特征工程，要把原始日志、图像、表格字段变成模型能吃进去的数值表达，这一层很多成熟工具已经自动化了大半。第二是网络结构设计，你得决定用卷积还是注意力模块，层数、通道数、卷积核尺寸、下采样位置怎么排，这里面的组合数量几乎是天文数字。第三是超参数调优，学习率、批大小、正则权重、优化器动量、数据增强策略，每一个都得反复试。

我见过很多团队在三和环节最浪费：结构靠抄，超参靠猜。抄来的结构在公开数据集上表现不错，换到自己业务数据上却常常水土不服，于是开始无休止地网格搜索或随机搜索。网格搜索看起来很稳，但它对高维空间的覆盖效率极低，超参数一多就指数爆炸。随机搜索稍微好一些，但本质上还是在盲人摸象，没有利用已经评估过的结果来引导下一轮尝试。

1.2 AutoNet 在AutoML全家桶里的职责边界

AutoML 这个词现在被用得很泛，有些工具号称一条命令从头到尾全自动，实际上是把特征工程、结构搜索、超参搜索、模型压缩、部署格式转换全都串在一起。AutoNet 在这条流水线里不是一个"什么东西都管"的角色，它有非常明确的职责边界：专门负责网络结构搜索，以及和结构耦合最紧密的那部分超参数（比如不同模块的宽度因子、深度因子、是否有残差连接）。

为什么要把结构单独拆出来做成 AutoNet？因为结构搜索和普通超参搜索的难度不在一个量级。超参搜索面对的是连续或离散的少量数值变量，而结构搜索面对的是组合空间，候选结构不是"一个数的取值"，而是"一张计算图长什么样"。如果放任一个通用优化器去直接搜计算图，搜索空间大到连初始采样都很难做。AutoNet 的价值就是把"结构"这个对象表示成一种可以被搜索算法理解的形式，再通过专用策略在结构空间中导航。

1.3 和常规调参工具相比，AutoNet 的核心差异

为了说清楚差异，我列一张对比表，基于我实际接触过的几类工具来看：

传统 NAS 最大的问题是贵。早期做法是每生成一个候选结构就从零训练一个模型来打分，一轮搜索消耗几千卡时很正常。AutoNet 在工程上做了一个关键修改：大量候选结构共享同一套预训练权重，评估时只需做少量微调，把成本压到可以接受的范围内。这也是它能够在实际业务里落地、而不是只停留在研究环境的原因。理解了这层差异，后面的搜索空间、搜索策略和评估机制就都好理解了。

2. 搜索空间、搜索策略、评估机制：AutoNet 的三根支柱

2.1 搜索空间设计：先回答"机器能在哪些结构里挑"

搜索空间是 AutoNet 所有工作的边界。它规定了搜索算法可以生成哪些网络结构，不可以生成哪些。这个设计直接决定了最终模型的上限：如果空间里根本没有适合你数据的结构，那再厉害的搜索策略也白搭；如果空间开得太大，算法又会在大海里捞针，耗时剧增。

常见的结构搜索空间有三类。第一类是链式空间，把网络看成一串层首尾相接，你只需要决定每层类型、卷积核大小、通道数、下采样位置，以及哪些层之间加残差。这种空间简单、容易理解，适合中小规模任务，但表达力有限。第二类是细胞式空间，先搜出一个基本计算单元（cell），再把单元堆叠多遍形成完整网络。单元内部可以有多种连接方式，这种设计结构紧凑、参数量更可控，迁移性也好，在很多视觉任务上表现突出。第三类是组合式空间，允许任意层之间建立连接，形成有向无环图，表达力最强，但搜索难度也最高，工程实现上最容易出问题。

实操里最常见的坑是：把三类空间混着塞，搜索空间里既有极其便宜的三层小网络，也有昂贵到单卡根本放不下的重网络。搜索算法会渐渐偏向大网络，因为它们拟合能力强，在短评估里更容易刷高精度，可实际上线时延迟和显存都撑不住。我现在的做法是，先把搜索空间按计算量排序，设定一个显存和推理耗时的上限，再让算法在符合约束的子空间里找结构。

2.2 搜索策略：随机、进化、强化学习和梯度法的取舍

搜索策略解决的是"如何在结构空间里导航"的问题。AutoNet 常见的有四种策略，各有利弊。

随机搜索是最简单的基线，每次从搜索空间里均匀采样结构，评估后挑最好的。它最容易被低估，但如果搜索空间设计得好、采样数量足够，随机搜索的结果往往不差。原因在于很多结构空间里"还不错的点"并不稀疏，随机采样也能踩中。进化算法则是维护一个候选种群，每代通过变异和交叉产生新结构，优胜劣汰。它对评估噪声的容忍度比较高，还能天然支持并行，是我在小预算搜索时更偏好的一种。

强化学习则是用控制器生成结构，用评估结果作为奖励来更新控制器参数。它灵活，但奖励设计稍有不慎就会让搜索跑偏，训练也不够稳定。梯度类方法把离散的结构选择松弛成连续参数，可以用反向传播快速优化，速度快，但会引入离散化误差，搜完后还得对离散结构重新评估。没有一种策略绝对最优，多数时候取决于你的预算、并行度和对稳定性的要求。预算少选进化，实验性质选随机，追求极致效果且算力充足可以考虑强化学习或梯度法。

2.3 性能评估：共享权重、代理指标与排序稳定性

搜索策略负责生成候选，性能评估负责给候选打分。这里的成本矛盾非常直接：如果每个候选都从头训练 100 个 epoch，那么搜索 1000 个结构需要的算力谁都扛不住。AutoNet 常见的做法是共享权重：建立一个超网络（supernet），所有候选结构都是超网络的子图，它们共享大部分参数。搜索过程中只对超网络做一次性整体训练，子结构评估时继承对应位置的权重，再跑几个 epoch 微调，就能得到一个足够用于排序的分数。

在结构排序时还要引入代理指标。代理指标是那些不需要完整训练就能估算的量，比如参数量、FLOPs、内存占用、推理延迟。它们不能替代精度，但可以帮忙快速过滤掉明显不合格的候选，比如显存超了、延迟太离谱的，根本不用送进精细评估阶段。AutoNet 里典型流程是：先用代理指标粗筛一遍，再用共享权重微调精筛一遍，最后只对排在最前面的几个结构做短周期重训验证。

评估机制的最终目标不只是算出准确率数字，而是保证排序稳定。也就是说，搜索阶段得分高的结构，重训后确实还能保持优势。如果没有这层保障，搜索结果就失去了意义。为了验证排序稳定性，我会在候选重训后用真实训练流程跑一遍，计算搜索阶段得分和真实性能之间的排序一致性。一致性高，说明搜索阶段的设计是可信的；一致性低，就要回头检查是共享权重训练不足、还是代理指标不合理、又或是评估时网络没收敛。

3. 最小复现流程：从数据集到候选模型的完整链路

3.1 环境准备与数据拆分

我把一次完整落地过程拆给你看。首先是环境，AutoNet 这类组件一般依赖常见的深度学习框架和对应的分布式通信库。你应该准备一个至少单卡可跑的验证环境，把驱动、运行时版本对齐，否则搜索过程中冷不丁冒出一个算子不兼容的问题会非常恼人。建议先跑一遍框架自带的最小样例，确认前向反向都正常，再开始正式搜索。

数据方面，我最重视的是划分策略。AutoNet 搜索过程中会大量使用验证集来给候选打分，因此验证集一定不能和最终测试集混在一起。我习惯的做法是原始数据按 8:1:1 分成训练、验证、测试三段，搜索阶段只用训练和验证，最终做模型对比时才碰测试集。分类任务还要留意类别不平衡，如果某些类别样本极少，光靠准确率排序会误导搜索，可以在评估指标上叠加类别权重或者用宏平均指标。图像类任务建议先统一分辨率，AutoNet 的搜索空间通常围绕固定输入尺寸设计。

3.2 一份可以照抄的搜索配置

下面这份配置来自我最近一次落地，不同 AutoNet 实现的字段名可能略有差异，但逻辑是通用的。

project: name: autonet_industrial_demo seed: 2024 data: root: ./dataset train_ratio: 0.8 val_ratio: 0.1 input_size: [3, 224, 224] search: strategy: evolution population_size: 48 generations: 40 mutation_rate: 0.25 max_flops: 5e8 max_param_mb: 20 evaluate: batch_size: 128 eval_epochs: 10 early_stop_patience: 3 proxy_metrics: ["flops", "param", "latency"] train: optimizer: sgd learning_rate: 0.05 momentum: 0.9 weight_decay: 3e-4 warmup_epochs: 5 scheduler: cosine

这里有几个参数需要解释。population_size 是进化算法每一代保留的候选数量，我建议先从 32 到 64 之间起步，太小容易早熟，太大则评估压力陡增。generations 是迭代轮数，不是越大越好，关键是观察排序是否收敛。max_flops 和 max_param_mb 是硬约束，用来把搜索空间压到你业务可接受的范围内。eval_epochs 是候选评估的微调轮数，10 轮是一个比较稳妥的经验值，太少了排序容易不稳定，太多了评估成本会暴涨。

配置完成后，实际调用逻辑通常是这样的：

from autonet import AutoNet searcher = AutoNet( search_space="cell", strategy="evolution", metric="val_acc", max_flops=5e8, seed=2024, ) searcher.search(data_root="./dataset", config="./config.yaml") best_models = searcher.export_topk(3)

我说一句很实在的话：任何 AutoNet 实现，在正式跑大搜索之前，都值得先在一个小的数据子集上用极小预算（比如种群 16、迭代 10）完整跑通一遍。这一步能暴露大量愚蠢且致命的问题，比如路径配置错误、评估阶段显存溢出、数据加载顺序不稳定。跑通了再放大预算，能省下大量返工时间。

3.3 搜索完成之后的三件事：重训、微调、导出

AutoNet 直接输出的"最优结构"不等于可以直接上线的模型。原因在于搜索阶段的结构是在共享权重上评估的，它的参数没有经过充分训练，精度不是最优。按我的习惯，搜索结束后会做三件事。

第一是挑选 top-k 结构（通常取前 1 到前 5）进行独立重训。重训从随机初始化开始，用完整的训练流程跑足够多轮次，并保存每个候选的指标曲线。第二是模型微调，如果重训后的模型在验证集上仍然略低于搜索阶段的预期，我会尝试从超网络继承权重继续微调，有时比随机初始化收敛更快。第三是导出模型格式，用于后续推理或进一步压缩。AutoNet 的候选结构通常是以编码形式保存的，需要转换为标准网络定义再导出为可部署的格式。不要跳过这一步，否则结构只存在于搜索日志里，后续根本没法复现。

3.4 可复现性的底线：固定种子与固定流程

AutoML 工具最容易被人诟病的一点是不可复现：同一份数据跑两次，搜出的结构不一样。事实上这不见得是 bug，而是搜索算法本身含有随机性。但作为工程落地，我要求至少做到两种程度的可复现。一种是种子级可复现：固定随机种子、固定数据加载顺序、固定框架的卷积算法开关，确保同一配置在同硬件上能跑出完全一样的结果。另一种是统计级可复现：即使结构不完全一致，多次搜索得到的最优结构性能应该在统计上没有显著差异。

在配置里固定 seed 只是第一步，还要注意数据加载器的 shuffle 顺序也会影响结果。某些框架在多卡场景下会用非确定性算法做梯度聚合，搜出来的结构差异会更大。如果你需要严格复现，不妨在文档里记录所用框架版本、算子实现开关，以及跑搜索的机器拓扑。很多团队忽略这些细节，结果模型出了问题，连是不是搜索本身引入的都判断不了。

4. 搜索质量真正分流的地方：四个实操细节

4.1 学习率与批大小必须联动，否则候选排序会失真

搜索阶段的调参和正常训练有一个很大的不同：正常训练只关心最终模型精度，搜索阶段关心的是"候选结构之间的相对排序"是否准确。一个结构如果因为某个不合理的训练配置被压低了得分，它可能就被淘汰了，哪怕它本来潜力很高。最容易出问题的就是学习率和批大小的联动关系。

如果你在评估阶段把候选的批大小从 128 改成 32，却不改学习率，参数更新步数变多，等效学习率上升，某些结构会因此变得不稳定，得分出现异常。反过来，批大小从 128 调到 512，学习率不放大，参数更新变慢，所有候选得分都会偏低，排序也随之失真。我的实操经验是，搜索阶段确定批大小后，学习率要按线性缩放规则重新计算：批大小翻倍，学习率近似翻倍；批大小减半，学习率近似减半。同时加一个预热阶段，前几个 epoch 从很小的学习率慢慢升到目标值，避免超网络在刚开始时被几个随机样本带偏。

4.2 权重继承的相位问题：超网络练到什么程度才能用

共享权重的思路能压成本，但也引入了一个微妙的问题：超网络训练不到一定程度时，子结构的评估分数没有意义。刚初始化的超网络权重完全不同质，某些随机子结构可能会因为恰好避开了不稳定的路径而拿到一个虚高的分数。这类"捡漏"现象会让搜索算法早期被虚假信号误导，把搜索带去错误的方向，后面再想拉回来就得花更多预算。

实践里我一般把超网络训练分成两个阶段。第一阶段只训练超网络本身，不评估任何子结构，让整体权重分布变得可用；第二阶段才启动搜索，让候选子结构在共享权重的基础上做短评估。这个"相位门"可以是固定 epoch 数，也可以由验证集上的一个粗指标触发。虽然会多花一点时间，但排序稳定性提升非常明显。如果你发现搜索前面几代的 top 候选换得很勤、甚至没有收敛趋势，大概率就是超网络还没有进入可评估状态，不要太早动手。

4.3 评估噪声大：用低方差投票代替单次打分

候选结构的评估天然带有噪声。同一结构，超网络权重在同一轮评估时可能表现不错，下一轮评估又掉几个点。如果每次评估只打分一次就拿来排序，噪声会被当成真实信号，造成排序不稳定。尤其是搜索进行到后期，候选之间的差异本来就小，噪声甚至能把真正的差距盖过去。

我的做法是引入低方差投票机制。对进入精细评估阶段的候选，不只跑一次评估，而是跑多轮（比如 3 次），取中位数而不是平均数。中位数对极端噪声更稳健。多轮评估之间要重置部分扰动源，比如改变验证集的采样顺序，增加评估多样性。如果某个候选多次评估的方差特别大，它很可能是一个"运气型"候选，在重训阶段表现反而会缩水，我会在排序里对它适当降权。这个方法看起来不起眼，但对最终选出的结构质量影响很大。

4.4 空间坍缩：发现搜索多样性在下降的时候要做干预

进化类搜索最常见的失败模式不是找不到好结构，而是过早收敛到某一小片区域，种群多样性急剧下降。表现出来的症状是：每一代新生成的结构都和上一代高度相似，编辑距离很小，父代和子代基本是近亲繁殖。这时候搜索算法已经退化成局部爬山，搜索空间里其他区域完全被忽略了。

我习惯在搜索过程中监控种群的多样性指标。简单做法是记录当前代候选结构之间两两距离的平均值，如果连续多代下降并低于某个阈值，就主动干预：提高变异概率、强制随机插入若干个全新个体、甚至重启整个种群但保留历史最优个体。AutoNet 的断点续跑能力在这里很有用，可以让一次搜索在多个阶段之间切换策略，而不是死守一个从一而终的设定。多样性监控也可以直接看代理指标分布，如果种群里的 FLOPs 范围越收越窄，同样说明搜索走窄了，需要干预。

5. 真实排障记录：三个坑的完整排查链路

5.1 显存溢出：不是换一块大显存显卡就完事

有一次搜索跑到第 20 代左右，训练进程突然报显存溢出。我第一反应是调小批大小，从 128 改成 64，结果还是溢出。再往下排查，发现是进化策略在某次变异里生成了一批异常宽的网络结构，单个结构的中间特征撑爆了显存。问题根子不在批大小，而在搜索空间缺少对单结构资源占用的硬约束。

最后做了三处修改：在搜索配置里加了 max_flops 硬限制，让超出计算量预算的结构直接被否决；评估支路只对部分层启用梯度，其余层关闭参数更新，从机制上降低显存占用；打开混合精度训练，显存占用进一步下降。这次教训是：搜索空间里的结构分布是动态变化的，早年设计的空间可能在搜索中途产生意料之外的组合，显存预算不能只按平均值估算，要按"可能出现的最大单结构"来设防线。

5.2 两次搜索结果差异巨大，精度却相当：问题出在评估噪声

第二个问题也是我遇到的典型情况：用完全相同的配置跑两次搜索，两次的前一结构完全不同，可重训后的精度却非常接近。一开始我以为是自己代码里有 bug，查了半天也没发现问题。后来把两次搜索过程中对 top 候选的逐轮评估日志调出来，才发现两次评估的原始分数波动范围特别大，同一结构的分数在不同轮次之间能差出好几个点。

这说明搜索阶段使用的评估指标区分度不足，噪声淹没了真实差距。我做了两个调整：一是把评估次数从 1 次提升到 3 次，取中位数后参与排序；二是把评估用的验证集从单一批次扩展到多次抽样，让分数反映多个切片上的平均表现。调整后，两次搜索的 top 候选虽然结构仍然不同，但性能分布基本一致，说明搜索结果进入了统计可接受的范围。对比结构差异本身没有意义，可比的是它们真实性能的分布区间。

5.3 搜完重训，效果反而比搜索阶段还差

最让我头疼的一个现象是：搜索阶段得分很高的结构，按正常流程重训之后，精度不仅没有提升，反而还低于搜索阶段的评估分数。初看非常违背直觉：重训明明花了更多时间，数据也更多，怎么会更差呢？

排查后我发现问题出在两个地方。首先是重训的优化器配置和搜索阶段不一致。搜索阶段我用的是带热预热的余弦退火，重训时图省事换成了固定学习率，结构里部分层根本没有被充分训练。其次是搜索阶段得分高本身就有一部分来自"在共享权重下的捡漏"，结构占了一个恰好有利于预测的子路径，重训从随机初始化开始后，一切推倒重来，那个优势就消失了。解决方式很直接：重训时复用搜索阶段的优化器和调度策略，同时记录搜索阶段评估所用的权重版本。如果重训效果确实不佳，我会尝试从超网络对应位置的权重做初始化，而不是从零开始。这个方法不一定每次都会更好，但值得在对比实验里跑出来看看。

6. AutoNet 之后：自动化到什么程度才算合适

6.1 自动化的边界：结构之外的东西依然要人盯

AutoNet 把结构搜索自动化了，但它不会替你理解业务。我见过不少团队把 AutoML 工具跑起来后就撒手不管，最后模型线下指标很好，上线后却因为数据分布漂移而崩盘。结构搜索解决的是"在静态训练集下找到性能好的模型"这个问题，可真实业务里的数据分布是流动的，光照变了、样本来源变了、定义变了，原有结构可能就不适合了。

自动化流程里最不能省的人工环节有三个：一是数据质量核查，包括脏标签、离群样本、采集偏差；二是业务目标转化为指标定义，比如是把准确率放在第一位，还是更看重召回率或延迟；三是结果验证，任何搜索出来的模型都要放进真实业务场景中做验证，不能只看静态指标。AutoNet 是放大器，它会把好的数据设计和坏的数据设计都放大，工具本身不会判断什么是"好任务"。

6.2 给搜索加一层约束：延迟、体积与能耗

实际部署时，模型精度只是其中一个目标。边缘设备上还有延迟要求、内存限制、功耗预算。AutoNet 的搜索阶段如果完全不感知这些约束，搜出来的模型即便精度再高，上线也会被硬件条件卡住。与其事后做剪枝和蒸馏，不如把约束直接写进搜索目标，让搜索算法在定义好的约束范围内找帕累托最优解。

我在实际应用中会把推理延迟也建模成一个可以估算的量，放进代理指标，让搜索过程同时优化精度和速度的加权和。另一个有效做法是多目标搜索：一个目标最大化精度，一个目标最小化参数量，最后输出的不是一个"最优结构"，而是一组帕累托前沿候选，供业务方根据实际部署条件选择。这个方法比先搜索再压缩要顺畅得多，省去了很多来回调整。

6.3 一个可以落地的分阶段工作流建议

如果你所在团队正准备把 AutoNet 引入正式流程，我建议不要一开始就追求大而全，而是分阶段推进。第一阶段在离线数据上用小预算跑通全流程，目标是快速拿到一个能超过现有基线的模型，建立团队对自动化建模的信心；第二阶段扩大搜索空间和搜索预算，让 AutoNet 覆盖更广的业务场景，并建立标准化的候选输出与模型归档流程；第三阶段才是把 AutoNet 纳入日常建模流程，和人工建模并行，形成互相校验的机制。

每个阶段之间都要保留可回滚的验证点。AutoNet 的价值不只是替换人工，更重要的是它带来了可枚举的候选结构和量化对比，这让你在讨论"为什么这个模型更好"的时候，手里有证据而不是感觉。把搜索日志、候选结构编码、评估指标完整留档，是一件非常值得投入时间的事，后续排查问题、优化流程、积累经验都靠这些记录。

最后说一个我自己的习惯：我拿到 AutoNet 输出的 top-k 结构后，从来不会只选第一名，而是会多留几个后备结构，放到业务验证集上对比真实表现。搜索阶段的第一名有时只是评估噪声里的幸运儿，综合表现更稳定的往往是第二第三名。从超网络里挑结构时，我也会刻意选择那些在多次评估中方差更小的候选，哪怕它的平均分不是最高。就我自己落地几个项目的经验来看，这个技巧比追求搜索算法的花哨设计更能稳定提升最终上线模型的质量。