NASBench-101：给神经网络架构搜索建一个标准化的「考场」

在深度学习研究者的日常里，训练一个神经网络是一件耗时又费力的事情。更让人头疼的是，当你提出一种新的网络架构设计时，很难回答一个根本问题：这个架构到底算好还是不好？ 传统做法是和已有的经典网络（如 ResNet、VGG）比准确率、比参数量，但不同任务的差异让这种横向比较往往缺乏说服力。

2019 年，Google Research 团队交出了一份答卷——NASBench-101，一个将神经架构搜索（Neural Architecture Search，NAS）领域标准化的里程碑式基准工具。它穷举了超过 42 万种 不同的卷积神经网络架构，将每一种架构在 CIFAR-10 数据集上的训练结果全部预先计算并存储为可查询的数据库。研究者只需几毫秒，就能知道任意一个架构的准确率、参数量和训练时间——无需真正去训练它。

背景：NAS 的痛点与基准数据集的诞生

神经架构搜索的目标是让算法自动「发明」最优的网络结构。2017-2019 年间，NAS 领域论文层出不穷，但几乎每篇论文都用自己的搜索空间、自己定义奖励函数、自己选择数据集，结果是方法 A 说准确率 95%，方法 B 说 96%——却根本无法直接比较。根本原因在于：训练一个架构需要数小时甚至数天，搜索空间又极其庞大，研究者通常只探索其中的极小一部分，且往往只跑一次（不关注方差）。

Chris Ying、Aaron Klein 等研究者在 ICML 2019 发表的论文《NAS-Bench-101: Towards Reproducible Neural Architecture Search》中指出了这个问题，并给出了解决方案：既然搜索空间固定（最多 7 层节点、9 条边、3 种操作），那就把整个搜索空间全部穷举出来。423,624 个架构 × 4 种训练预算（4/12/36/108 epoch）× 3 次重复训练 = 超过 500 万个训练结果，全部预先算好存进数据库。

这个数字背后意味着什么？研究者做 NAS 实验时，原来需要几天的训练时间，现在变成了一个数据库查询操作。

核心机制：如何用一张矩阵描述一个神经网络

NASBench-101 的设计巧妙之处在于架构的数学表示。它用一张有向无环图（DAG）来描述卷积模块的结构：

邻接矩阵（Adjacency Matrix）：一个 V×V 的 0-1 上三角矩阵，记录节点之间的连接关系。V 最多为 9（包含输入输出节点）。
节点操作（Operations）：每个节点可以是 conv1x1-bn-relu、conv3x3-bn-relu 或 maxpool3x3 三种之一。
骨架（Skeleton）：所有架构共享一个固定的主干网络（stem + 3 个模块 + 全局池化 + 分类头），只有中间的模块部分允许自由探索。

用户在 Python 中只需定义这两个数据结构，就能查询该架构的性能：

from nasbench import api

model_spec = api.ModelSpec(
    matrix=[[0, 1, 1, 1, 0, 1, 0],
            [0, 0, 0, 0, 0, 0, 1],
            [0, 0, 0, 0, 0, 0, 1],
            [0, 0, 0, 0, 1, 0, 0],
            [0, 0, 0, 0, 0, 0, 1],
            [0, 0, 0, 0, 0, 0, 1],
            [0, 0, 0, 0, 0, 0, 0]],
    ops=['input', 'conv1x1-bn-relu', 'conv3x3-bn-relu',
         'conv3x3-bn-relu', 'conv3x3-bn-relu', 'maxpool3x3', 'output'])

nasbench = api.NASBench('/path/to/nasbench.tfrecord')
data = nasbench.query(model_spec)
# data 包含: train_accuracy, validation_accuracy, 
#           test_accuracy, trainable_parameters, training_time

API 会自动对输入的架构进行剪枝（去除未使用的节点），并验证是否在搜索空间内。如果架构超出范围，会抛出 OutOfDomainError。这个设计确保了所有查询都是有效的。

代码架构：从数据生成到查询的全链路

整个项目结构清晰，分为数据生成脚本和对外 API 两大部分：

核心文件：

文件	作用
`nasbench/api.py`	对外主接口：`NASBench` 类负责加载 TFRecord 并提供 `query()`、`get_metrics_from_spec()` 等查询方法
`nasbench/lib/model_spec.py`	`ModelSpec` 类：验证架构合法性（矩阵格式、操作类型），提供图可视化
`nasbench/lib/model_builder.py`	TensorFlow 模型构建：根据 ModelSpec 动态组装网络
`nasbench/lib/evaluate.py`	训练与评估：定义 `train_and_evaluate()` 和异常处理
`nasbench/lib/cifar.py`	CIFAR-10 数据集处理
`nasbench/lib/graph_util.py`	图操作工具：可达性分析、拓扑排序
`nasbench/lib/training_time.py`	训练时间估算
`nasbench/lib/config.py`	超参数配置（训练 epoch 数、batch size 等）
`nasbench/lib/model_metrics.proto`	Protobuf 数据格式定义
`nasbench/scripts/generate_graphs.py`	穷举搜索空间中的所有合法图
`nasbench/scripts/run_evaluation.py`	对每个图执行多次训练

数据存储格式： 所有预训练结果以 TensorFlow TFRecord 格式存储，使用 Protocol Buffers 序列化，包含训练/验证/测试准确率、参数量、训练时长等多维指标。完整数据集约 2GB（nasbench_full.tfrecord），108 epoch 子集约 500MB。

参数-训练时间-准确率散点图

图1：参数数量、训练时间与验证准确率的综合关系图。可以看到 108 epoch 训练下不同架构的性能分布，揭示了参数量与精度之间的权衡关系。

上手体验：安装、数据获取与实际使用

安装过程非常简洁：

git clone https://github.com/google-research/nasbench
cd nasbench
virtualenv venv && source venv/bin/activate
pip install -e .

唯一强制依赖是 TensorFlow，其余均为标准库。项目提供了完整的 Colab notebook（NASBench.ipynb），可以直接在 Google Colaboratory 中运行，无需本地下载数据集。

数据集下载是最大的门槛： 完整数据集约 2GB，下载需要稳定的网络连接。如果网络不稳定，需要配合代理或科学上网工具。数据集下载后，首次加载 TFRecord 需要较长 I/O 时间（约数十秒）。

使用场景举例：

NAS 算法评测：用 NASBench-101 作为强化学习/进化算法/梯度方法的测试环境，对比不同搜索策略的效率
架构分析：研究哪些子图结构（跳过连接、瓶颈设计等）更有利于性能
元学习：将架构-性能对作为训练数据，学习架构的隐式规律

需要注意的是，NASBench-101 仅覆盖 CIFAR-10 任务，且搜索空间相对较小（最多 9 节点），将其结论直接迁移到 ImageNet 等大型任务时需要谨慎。后续工作（如 NASBench-201）扩展了搜索空间并使用了不同的数据集。

局限性与后续演进

NASBench-101 并非完美，有几个值得关注的局限：

1. 搜索空间有限 最多 9 个节点、3 种操作，相比后来 NAS 领域提出的更大搜索空间（如 NASBench-201 的 5 种操作、DARTS 的连续松弛空间），NASBench-101 的空间相对较小。这意味着基于它得出的 NAS 规律，不一定能在更大空间上复现。

2. 仅限 CIFAR-10 所有架构都在 CIFAR-10 上评估。如果研究目标是 ImageNet 或其他任务，迁移效果未知。实际上，许多 NAS 研究后来都发现了 CIFAR 和 ImageNet 之间的「最优架构不一致」问题。

3. 基于 TensorFlow 1.x 项目代码基于 TensorFlow 1.12 以上版本，在 TensorFlow 2.x 大行其道的当下，直接用 pip install tensorflow 安装最新版本可能存在兼容性问题（虽然 API 层面影响不大）。

后续演进方面，Google 团队在 NASBench-101 之后又推出了 NASBench-201（使用 DARTS 搜索空间）、NASBench-301（代理模型基准）等，形成了 NAS 基准工具的完整生态。这些工具共同推动了 NAS 研究的可复现性。

行业意义与影响

NASBench-101 的出现，在 2019 年的 NAS 领域算得上一次「标准化运动」。它将 NAS 研究从「各自为战」的混沌状态，引向了可量化、可比较的阶段。

在学术影响上，截至目前该仓库已获得超过 719 个 GitHub Stars，被引用数百次，启发了大量后续基准工具的设计思路。它让 NAS 论文的实验变得更加公平——大家都在同一个数据集上比，方法优劣一目了然。

在工程实践上，NASBench-101 显著降低了 NAS 研究的门槛。过去做一个 NAS 实验需要 GPU 集群运行数天，现在只需要一台能运行 Python 的机器加上一个 TFRecord 文件。这使得更多研究者能在有限资源下探索 NAS 算法。

更深远的意义在于，NASBench-101 揭示了一个反直觉的发现：更复杂的架构并不一定带来更好的性能。很多被精心设计的复杂操作，在穷举比较中并未显著优于简单设计。这促使 NAS 研究者开始反思「搜索空间设计」本身的重要性——选什么样的操作、允许多少节点，往往比用什么样的搜索算法更关键。

如果你对神经架构搜索感兴趣，或者想在自己的项目中引入 NAS 基准测试，NASBench-101 依然是入门的最佳起点之一。