5.3 特定任务的 NAS

5.3 特定任务的 NAS

本节摘要：任务决定"什么才算好"，NAS 的搜索对象要跟着任务变。本节拆解七个任务族的 NAS 搜索对象：图像分类搜 CNN 与增强策略、目标检测搜 Backbone/Neck/Head、图像分割搜编码器-解码器与损失、NLP 搜 Transformer 组件与嵌入、语音搜声学/语言/解码器、推荐搜 Embedding/交互/排序、强化学习搜策略/价值网络，并讨论任务相关评估指标与知识迁移。

读完这一节你会得到

阅读完本节，你应当能够：

1. 说出图像分类、目标检测、图像分割三类视觉任务的 NAS 搜索对象差异
2. 解释"目标检测搜 Backbone/Neck/Head"中各部分的职责
3. 列举 NLP 与推荐系统中 NAS 搜索的三个典型对象
4. 理解任务相关评估指标（mAP、BLEU 等）如何改变搜索目标

一、问题与直觉：搜索对象要跟着任务换

上一节按"数据类型"分，这一节按"任务"分。两者的区别：数据类型决定"架构用什么运算"，任务决定"评估用什么标准、搜什么组件"。图像分类的 NAS 搜整个骨干网；目标检测的 NAS 搜的是检测器里的 Backbone、Neck、Head——因为检测器的整体框架（两阶段还是单阶段）通常是固定的先验，值得搜的是其中相对独立的部分。

这个"任务决定搜索边界"的思路，是特定任务 NAS 的核心智慧。SOURCE 的观点是：传统 NAS 以通用任务（如图像分类）为目标，搜索到的架构可能无法在特定任务上达到最优性能。任务不一样，性能指标就不一样——分类看 Top-1 准确率，检测看 mAP，分割看 mIoU，NLP 看 BLEU。指标不一样，"什么架构好"的判断就不一样，搜索对象自然要跟着变。

任务特定 NAS 的工程价值，是把 NAS 从"学术界玩法"变成"工业界工具"——工业场景没有"通用任务"，每个任务都有自己的结构和指标，只有把搜索对象嵌进任务框架，NAS 才能真正落地。

二、核心原理：七个任务族的搜索对象

图像分类。搜 CNN 结构（层类型、卷积核、通道数、激活），外加两个增量维度：数据增强策略（随机裁剪、旋转、翻转、颜色抖动——AutoAugment、RandAugment 就是搜增强策略的代表）和损失函数（交叉熵、Focal Loss、Label Smoothing）。分类任务是最成熟的主场，EfficientNet、MobileNetV3 是代表成果。

目标检测。固定检测框架，分部件搜索。Backbone 网络——负责提取图像特征，搜 ResNet/Darknet/EfficientNet 的变体。Neck 网络——融合不同尺度特征图，搜 FPN、PANet 的变体。Head 网络——预测目标位置与类别，搜 YOLO Head、SSD Head、Faster R-CNN Head 的变体。还有 Anchor Box 尺寸比例的设计搜索。DetNAS 搜 Backbone 和 Head，Auto-FPN 搜特征金字塔——都符合"框架固定、部件搜索"的模式。

图像分割。搜编码器-解码器结构（U-Net、DeepLab 的变体）、注意力机制（空间注意力、通道注意力）、损失函数（交叉熵、Dice Loss、IoU Loss）。Auto-DeepLab 在 Cityscapes 上通过搜编码器-解码器拿到当时最好精度。分割的搜索空间与分类共享骨干网，差异在解码端与损失。

NLP。搜 Transformer 结构（层数、注意力头数、维度）、词嵌入方法（Word2Vec、GloVe、FastText）、预训练语言模型的微调策略（学习率、Batch Size、Epoch 数）。NLP 的 NAS 评估最贵——语言模型训练和评估都慢，所以可微 NAS 少见，进化/强化学习为主。

语音识别。三个组件分别搜：声学模型（语音转音素序列，搜 CNN/RNN/Transformer 结构）、语言模型（预测音素序列概率，搜 RNN/Transformer）、解码器（音素转文本，搜 CTC 解码器、Attention 解码器）。

推荐系统。搜 Embedding 模型（用户/物品转向量，矩阵分解、神经协同过滤）、交互模型（捕捉用户物品交互，深度学习、注意力机制）、排序模型（对候选排序，LambdaMART、GBDT 变体）。

强化学习。搜策略网络（学习最优策略，CNN/RNN/Transformer）、价值网络（估计状态价值）、奖励函数设计。强化学习场景的 NAS 多了一层复杂度：评估要跟环境交互，成本更高。

任务与数据类型的关系。任务与数据类型不完全对应——图像分类和语义分割都处理图像数据，但搜索对象不同（一个搜骨干，一个搜编码解码）。设计搜索空间时两个维度都要考虑：数据类型决定"操作集合"，任务决定"搜索边界与评估指标"。一张"图像分类任务 + 图数据"是常规组合，而"图分类任务 + 图数据"就要同时换操作集合和搜索边界。

三、工程实践要点：任务特定 NAS 的三个原则

原则一：先固定框架，再搜部件。别从零搜整个检测器或整个推荐系统。把任务框架里"已验证可靠"的部分固定下来（检测的 RPN 流程、推荐的召回排序结构），只搜"瓶颈部件"（检测的 Backbone/Neck、推荐的交互模型）。SOURCE 里的案例几乎全是这个模式——DetNAS 固定检测器框架搜骨干，Auto-FPN 固定主干搜特征金字塔。

原则二：评估指标必须任务对齐。搜索目标函数里的"性能"，必须用任务自己的指标。检测任务搜出 mAP 最高的架构，分割任务搜出 mIoU 最高的架构——指标定义错，搜索方向就错。特别提醒：分类准确率与检测 mAP 的"好架构"可能完全不是一回事，别拿分类指标评估检测架构。

原则三：部件间的耦合要留神。Backbone 和 Neck 不是独立变量——换了 Backbone，最优 Neck 可能跟着变。工程上要么联合搜索（成本高），要么分阶段搜索（先定 Backbone 再搜 Neck，可接受次优）。SOURCE 提到的"任务相关的知识迁移"——图像分类搜出的骨干结构迁移到检测任务——就是利用这种耦合的常见做法。

⚠️ 常见坑：在目标检测里直接搜整个端到端检测器。检测器的搜索空间维度爆炸（骨干+颈部+头部+锚框+损失全是变量），评估又贵，搜索几乎不可能收敛——固定框架搜部件才是工程上唯一可行的路线。

💡 关键直觉：任务特定 NAS 的搜索对象，往往不是"整个模型"，而是"任务流程里的可替换部件"。检测、分割、推荐、语音的成功案例都在证明同一件事：把 NAS 用在组件级，既保住了任务先验，又获得了自动搜索的收益。

四、特定任务 NAS 的机制细节与实战案例

目标检测的"三段式"搜索为什么有效

DetNAS 搜 Backbone 和 Head、Auto-FPN 搜特征金字塔——两个案例都符合"固定框架、部件搜索"的模式。这个模式有效有三个原因。第一，检测框架（两阶段/单阶段、RPN 流程、损失设计）经过多年打磨已经成熟，整体搜索收益不大、风险却高。第二，检测的评估贵（COCO 训练评估要几百 GPU 小时），全量搜索预算扛不住，部件搜索把空间砍到可控。第三，部件之间的耦合有边界——Backbone 决定特征质量，Neck 决定特征融合，Head 决定预测，三段职责清晰，分开搜的次优性可控。SOURCe 在第 5.3 节把检测的搜索对象拆成 Backbone/Neck/Head/Anchor 四块，正是这个"职责清晰才能分而治之"的思路。

分割任务 NAS 的独特变量：损失与注意力

图像分割 NAS 除了搜编码器-解码器结构，还搜两个独有维度：注意力机制（空间注意力、通道注意力，用于捕捉重要信息）和损失函数（交叉熵、Dice Loss、IoU Loss，用于处理类别不平衡）。SOURCe 把它们单列的原因：分割的瓶颈往往不在骨干网络，而在"细粒度信息的保留"（注意力）和"小目标/不平衡类别"（损失）。工程启示：分割 NAS 的搜索空间里，结构变量与损失变量应该同时放开——只搜结构不搜损失，可能漏掉"结构平平但损失得力"的最优解。

NLP NAS 与视觉 NAS 的三个差异

第一个差异是搜索对象：视觉搜 CNN 结构，NLP 搜 Transformer 组件（层数、头数、维度）和嵌入方法——SOURCe 明确列了 Word2Vec、GloVe、FastText 作为嵌入搜索对象。第二个差异是评估成本：NLP 的训练评估明显更贵，可微 NAS 用得少，进化/强化学习 + 权重共享更常见。第三个差异是先验强度：Transformer 的成功先验太强，搜索空间通常被限制在"Transformer 变体"范围内，很少允许搜出完全不同的架构——这是"先验决定空间边界"在 NLP 上的体现。

强化学习 NAS 的"评估+交互"双重成本

RL NAS（给强化学习智能体搜网络）比其他任务 NAS 多一层成本：评估一个策略网络，需要在环境里交互跑完多个回合，而不是跑一次训练评估。SOURCe 在 5.3 节把 RL NAS 的搜索对象列为策略网络、价值网络、奖励函数——策略网络的评估尤其贵，因为要"与环境的真实交互"才能知道策略好坏。工程应对：用"简化环境"评估（交互回合数减半、状态空间降维），或先在小环境粗搜再在大环境精评——又是评估阶梯思想在 RL 场景的移植。

五、FAQ：特定任务 NAS 的常见疑问

"任务特定 NAS"和"特定数据 NAS"会不会重叠？

会，而且经常同时出现——一个任务既决定数据形态（检测处理图像、翻译处理文本）又决定搜索对象（检测搜 Backbone/Neck/Head、翻译搜 Transformer 组件）。两个维度的分工是：数据维度管"操作集合"（卷积还是注意力），任务维度管"搜索边界与评估指标"（搜哪些部件、用什么分数）。设计时两个维度都要过一遍，缺一个都可能漏掉关键变量。

分类任务搜出的架构能直接用做检测骨干吗？

能，而且常用——图像分类搜出的 Cell（NASNet 的成果）被广泛用作检测的 Backbone。SOURCe 在 5.3 节把"将图像分类任务上的 CNN 结构迁移到目标检测任务上"列为有潜力的方向。但要注意两点：骨干只是检测流程的一部分，Neck/Head 仍需按检测任务单独设计；分类任务上最优的骨干在检测任务上未必最优（耦合问题）。迁移后至少要按检测任务的指标复验，别默认"分类好就检测好"。

任务的评估指标能直接当搜索目标吗？

能，但要注意指标的可微性。准确率、mAP、BLEU 这类指标都是不可微的——搜索算法只能在"评估后"拿到分数，不能直接对它做梯度优化。处理方式：用可微的代理目标（交叉熵损失）做梯度优化，用不可微的指标（mAP）做评估排序——"优化用代理目标、评估用真实指标"是标准配置。SOURCe 在 5.3 节强调"任务相关的评估指标"的重要性，正是这个意思。

推荐系统 NAS 的特别之处在哪？

推荐系统的搜索对象（Embedding、交互、排序）与视觉/NLP 完全不同，而且评估指标（点击率、AUC）依赖用户行为数据，与离线训练指标存在偏差。SOURCe 在 5.3 节把推荐单列，因为它代表"结构化表格型数据 + 在线反馈"这类 NAS 的新场景。工程上的难点是"离线搜索的架构在线上未必最优"——需要结合 A/B 实验验证，这是推荐 NAS 独有的闭环。

• 任务决定边界：检测搜部件、分割搜编码解码、NLP 搜组件
• 七任务七对象：分类骨干+增强、检测 Backbone/Neck/Head、分割编码解码+损失、NLP Transformer+嵌入、语音三组件、推荐 Embedding/交互/排序、RL 策略/价值网络
• 指标必须对齐：mAP、mIoU、BLEU、AUC 各自定义"好"
• 固定框架搜部件：DetNAS、Auto-FPN 都是组件级搜索
• 耦合要留神：Backbone 与 Neck 互相影响，分阶段搜接受次优
• 迁移复用：分类骨干结构可迁移到检测，利用部件耦合

下一节看 NAS 的理论分析——不追效果，追问"为什么有效"。