过去几个月我一直在帮一个做工业视觉检测的团队收拾他们的建模流程。问题倒不复杂样本量不算少特征也够但每次换一批新产品三位工程师就要重新做一轮特征筛选、网络结构选择、超参数调参。两周起步做出来的模型还经常没法直接复用换个光照环境就得返工。后来我把整套自动化机器学习AutoML流水线搭了进去其中负责网络结构搜索与自动模型设计的关键组件就是我们今天要聊的 AutoNet。AutoNet 一句话概括它把设计一个神经网络长什么样、网络该多宽多深、怎么训练才划算这件事从人工拍脑袋变成机器在限定范围内搜索。它并不神秘本质上是把神经网络架构搜索NAS、超参数优化HPO、训练策略推荐等几类技术揉进了一个可重复执行的流程。这篇内容适合三类人一是数据团队里被建模周期压得喘不过气的工程师二是想把 AutoML 工具用在自己的实验流程里、但不想只会点按钮的研究者三是准备入坑自动化模型设计、想先建立整体认知的同学。我会尽量把原理讲清楚再给一套可照搬的落地流程和几个真实踩坑记录聊点搜索之外容易被忽略的事情。1. 从AutoML的盘子里看AutoNet它到底顶替了哪几号人力1.1 传统建模里最耗人的三个动作模型从数据到上线传统路径里最消耗人力的不是训练本身而是三个动作。第一是特征工程要把原始日志、图像、表格字段变成模型能吃进去的数值表达这一层很多成熟工具已经自动化了大半。第二是网络结构设计你得决定用卷积还是注意力模块层数、通道数、卷积核尺寸、下采样位置怎么排这里面的组合数量几乎是天文数字。第三是超参数调优学习率、批大小、正则权重、优化器动量、数据增强策略每一个都得反复试。我见过很多团队在三和环节最浪费结构靠抄超参靠猜。抄来的结构在公开数据集上表现不错换到自己业务数据上却常常水土不服于是开始无休止地网格搜索或随机搜索。网格搜索看起来很稳但它对高维空间的覆盖效率极低超参数一多就指数爆炸。随机搜索稍微好一些但本质上还是在盲人摸象没有利用已经评估过的结果来引导下一轮尝试。1.2 AutoNet 在AutoML全家桶里的职责边界AutoML 这个词现在被用得很泛有些工具号称一条命令从头到尾全自动实际上是把特征工程、结构搜索、超参搜索、模型压缩、部署格式转换全都串在一起。AutoNet 在这条流水线里不是一个什么东西都管的角色它有非常明确的职责边界专门负责网络结构搜索以及和结构耦合最紧密的那部分超参数比如不同模块的宽度因子、深度因子、是否有残差连接。为什么要把结构单独拆出来做成 AutoNet因为结构搜索和普通超参搜索的难度不在一个量级。超参搜索面对的是连续或离散的少量数值变量而结构搜索面对的是组合空间候选结构不是一个数的取值而是一张计算图长什么样。如果放任一个通用优化器去直接搜计算图搜索空间大到连初始采样都很难做。AutoNet 的价值就是把结构这个对象表示成一种可以被搜索算法理解的形式再通过专用策略在结构空间中导航。1.3 和常规调参工具相比AutoNet 的核心差异为了说清楚差异我列一张对比表基于我实际接触过的几类工具来看工具类型搜索对象依赖人工程度能发现新结构的能力典型代价网格搜索/随机搜索预设超参组合高需人工指定网格无只能调已有结构每次训练完整模型贝叶斯优化类工具超参中需预设结构弱结构固定仍需反复训练传统 NAS 实现网络结构中高强可生成新结构极高动辄上千卡时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_spacecell, strategyevolution, metricval_acc, max_flops5e8, seed2024, ) 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 结构后从来不会只选第一名而是会多留几个后备结构放到业务验证集上对比真实表现。搜索阶段的第一名有时只是评估噪声里的幸运儿综合表现更稳定的往往是第二第三名。从超网络里挑结构时我也会刻意选择那些在多次评估中方差更小的候选哪怕它的平均分不是最高。就我自己落地几个项目的经验来看这个技巧比追求搜索算法的花哨设计更能稳定提升最终上线模型的质量。
