Nevis‘22基准：以计算效率为核心，重塑持续学习评估范式

1. 项目概述：为什么我们需要一个全新的持续学习基准？

在计算机视觉乃至整个机器学习领域，我们正面临一个日益严峻的挑战：模型如何在一个不断变化、新数据和新任务如潮水般涌来的世界中，持续地、高效地学习？传统的“训练-部署”范式假设数据是静态的，模型一旦训练完成就固定不变。然而，现实世界是动态的。一个自动驾驶系统需要识别新出现的交通标志；一个医疗影像分析工具需要适应新的疾病类型或成像设备；一个内容推荐引擎需要理解用户不断变化的兴趣。如果每次遇到新情况都从头训练一个模型，不仅计算成本高昂，更关键的是，模型会“忘记”之前学到的所有知识，这种现象被称为“灾难性遗忘”。

这就是“持续学习”或“终身学习”要解决的核心问题。它的目标是让模型能够像人类一样，在非平稳的数据流中，持续地获取、整合和精炼知识，同时保持对已学任务的性能。听起来很美好，对吧？但实际操作起来，困难重重。其中一个根本性的难题是：我们如何公平、全面地评估一个持续学习算法的好坏？

长期以来，研究者们使用着一些“约定俗成”的基准，比如在MNIST、CIFAR等少数几个数据集上，人为地划分任务序列。但这些基准存在明显的局限性：任务数量少、数据同质化严重、任务间差异小，无法模拟真实世界中数据流的复杂性和多样性。一个在MNIST旋转数字序列上表现优异的算法，放到一个从人脸识别到卫星图像分析，再到医学影像诊断的漫长学习流中，很可能就失灵了。更关键的是，评估往往只关注最终的平均准确率，却忽略了算法达成这一性能所付出的“代价”——计算成本。一个通过暴力穷举超参数、反复从头训练所有数据而获得高分的算法，和一个能够巧妙复用知识、快速适应新任务的算法，在现实世界的资源约束下，价值是天差地别的。

Nevis‘22基准的诞生，正是为了填补这一空白。它不是一个简单的数据集集合，而是一个精心设计的、面向真实世界复杂性的持续学习评估生态系统。它的核心是构建了一个跨越30年（1992-2021）、包含106个异构计算机视觉数据集的时序流。这个流模拟了研究社区兴趣的演变：从早期的纹理、人脸数据集，到PASCAL VOC、ImageNet等大规模物体识别，再到细粒度分类、医疗影像等专业领域。模型需要在这个流中按时间顺序学习，每个数据集视为一个独立的任务。这极大地增加了评估的挑战性和真实性。

但Nevis‘22更革命性的贡献在于其评估协议，特别是它对计算效率的量化方式。它明确提出了一个关键问题：我们不仅要看模型学得“多好”，还要看它学得“多省”。为此，它引入了累积浮点运算次数作为核心评估指标之一。这个选择背后有深刻的考量，旨在引导社区不仅追求更高的准确率，更要开发出能够优雅扩展、适应未来更大规模数据和任务的高效学习器。接下来，我们将深入拆解这个基准的设计思路、实现细节以及它带给我们的启示。

2. Nevis‘22基准的整体设计与核心思路

2.1 数据流构建：一部计算机视觉的“编年史”

Nevis‘22基准的核心骨架是其数据流。它并非随机堆砌数据集，而是遵循一个严谨的构建逻辑，旨在模拟技术发展的真实轨迹。

2.1.1 构建原则与采样方法

构建团队采用了一种基于文献引用的时间顺序采样法。他们从1990年代初期计算机视觉领域开创性的数据集（如Aberdeen人脸数据库）开始，依据学术论文发表的时间顺序，将后续研究中广泛使用的新数据集依次纳入流中。这种方法确保了数据流与领域研究热点的历史演进同步。例如，你会先看到2000年代初期的COIL物体数据集和经典的MNIST，然后是2005年后的PASCAL VOC挑战赛数据集，接着是2010年左右引爆深度学习革命的ImageNet，再到近年来的细粒度数据集（如CUB-200鸟类、FGVC Aircraft飞机）和医疗影像数据集（如NIH Chest X-ray）。

这种设计带来了几个关键特性：

1. 时序真实性：模型学习任务的顺序，与人类研究者接触和解决这些问题的历史顺序一致，增加了评估的现实意义。
2. 任务异构性：流中包含了分类（C）、多标签分类（M）、计数等多种任务类型，以及人脸、物体、场景、纹理、医学影像、手写字符等极其多样的图像域。这迫使模型必须具备强大的跨域适应和知识迁移能力。
3. 规模与复杂度递增：早期数据集样本量小、分辨率低（如MNIST的28x28），后期数据集规模庞大、分辨率高（如ImageNet的百万级图像）。这模拟了真实世界中数据量和复杂度的增长趋势。

2.1.2 数据集概览与挑战

从提供的列表可以看出，数据流涵盖了从Aberdeen (1992) 到COVID-19 X-ray (2021) 等106个数据集。每个数据集都被定义为一个独立的“任务”。对于分类任务，评估指标是测试集准确率；对于多标签分类等，则采用相应的合适指标。

这种设置带来了前所未有的挑战：

• 领域偏移：上一个任务可能是识别手写数字（MNIST），下一个任务就要识别自然场景中的物体（PASCAL VOC），模型必须快速调整其视觉表示。
• 灾难性遗忘：在学习新任务（如识别花卉）时，如何保证不严重损害对旧任务（如识别人脸）的性能？
• 正向迁移与负迁移：学习任务A（如通用物体识别）获得的知识，可能在多大程度上帮助或阻碍学习任务B（如医疗影像诊断）？
• 可扩展性：随着任务数量增加到上百个，算法在内存、计算时间和参数数量上的增长是否能被接受？

2.2 评估协议的双重维度：性能与效率

Nevis‘22的评估不仅仅看最终的平均准确率。它建立了一个更全面的评估框架，主要包含两个维度：

1. 学习性能：这是传统评估的核心。它衡量模型在所有已见任务上的平均表现。通常，在学完整个流或特定阶段后，会在所有任务的测试集上评估模型，计算平均准确率。为了深入分析知识迁移，Nevis‘22还引入了迁移矩阵的计算（在附录J中描述）。这个矩阵的每个单元格(i, j)表示，在任务j上训练后，再在任务i上微调得到的性能，与直接在任务i上独立训练得到的性能之比。这能直观地揭示任务间的知识迁移是正向（帮助）还是负向（干扰）。

2. 计算效率：这是Nevis‘22的重点创新。它质问：为了达到某个性能水平，算法消耗了多少计算资源？一个总是“推倒重来”、从头训练所有数据的算法，即使准确率高，在实际部署中也可能因为成本过高而不可行。因此，需要一个公平的指标来比较不同策略的效率。

2.3 计算效率度量：为什么是浮点运算次数？

在附录K中，论文详细阐述了选择累积浮点运算次数作为效率指标的原因。他们考虑并否决了其他几种可能方案：

• 总训练样本访问量（含重复）：这可能会不公平地惩罚那些使用重放缓冲区或缓存机制的算法。这些算法会存储部分旧数据用于复习，虽然增加了数据访问次数，但能有效缓解遗忘，整体上可能是更高效的。惩罚数据访问会限制算法设计的灵活性。
• 总优化步数：这可能会对使用大量小步幅更新的算法（如某些自适应优化器或二阶方法）不利。步数多不代表计算量大，也可能代表更精细的优化。
• 实际训练耗时（墙钟时间）：这个指标最直观，但最不公平。它严重依赖于特定的硬件（GPU型号）、软件实现（框架优化程度）、以及并行化策略。一个算法可能因为不能充分利用GPU的并行计算能力而显得很慢，但这不代表其算法思想本身低效。

那么，为什么选择浮点运算次数？论文给出了几个核心理由：

1. 对算法设计保持中立：FLOPs计数不歧视任何特定的学习策略。无论是重放、正则化、参数隔离还是元学习，只要执行了前向和反向传播，就会产生FLOPs。它为所有算法提供了一个统一的“货币”来衡量计算量。
2. 近似反映实际成本：在现代硬件加速器（如GPU、TPU）上，计算的核心成本很大程度上由浮点运算量决定。虽然达到硬件的峰值算力需要优化，但FLOPs与能耗、计算时间有很强的相关性。它比墙钟时间更底层，更少受实现细节干扰。
3. 忽略相对廉价的资源：存储（用于重放缓冲区）和内存访问的成本，通常远低于数值计算本身。因此，在比较算法效率时，可以主要关注计算量。
4. 可复现与可比较：研究者可以使用像JAX这样的框架提供的成本分析API，在CPU上模拟运行并获得与硬件无关的FLOPs估计值。这确保了不同团队、在不同硬件上得出的效率指标是可比较的。

实操心得：在你自己进行持续学习实验时，尤其是在对比不同方法时，强烈建议除了记录准确率，也估算一下FLOPs。你可以使用jax.profiler或PyTorch的torch.profiler等工具。这能帮你判断性能提升是来自算法本质的改进，还是简单地“大力出奇迹”——堆了更多计算资源。对于希望将研究推向实际应用的团队，计算效率是必须考量的关键因素。

3. 核心细节解析：迁移矩阵与超参数搜索

3.1 深入理解迁移矩阵

Nevis‘22附录J描述的迁移矩阵，是一个极其强大的分析工具。它不仅仅是一个评估指标，更是一个诊断工具，能让我们深入理解算法内部的知识流动。

3.1.1 迁移矩阵的计算过程

1. 建立基线：首先，为流中的每一个任务i，运行一个标准的“独立学习者”基线。这个基线模型会在这个任务的数据上，进行一轮完整的随机超参数搜索（例如，学习率、权重衰减等）。最终，选择在任务i上验证集性能最好的那个模型及其训练过程。这个最佳运行在任务i测试集上的准确率，就是矩阵中的“参考精度”，记为Acc_ind(i)。它代表了在不考虑任何其他任务知识的情况下，单独攻克该任务所能达到的最佳水平。
2. 顺序微调：接下来，进行迁移实验。对于每个任务i的最佳模型，我们将其作为预训练模型，按数据流的时间顺序，在所有后续任务j(j > i) 上进行微调。注意，这里是单向的、向前的时间流，模拟了实际持续学习中的知识积累过程。对每一个(i, j)组合，微调时同样会进行一轮随机超参数搜索，以找到在该迁移路径下的最佳微调参数。
3. 计算相对性能：对于单元格(i, j)，其值计算为：Acc_ft(i|j) / Acc_ind(i)。其中Acc_ft(i|j)表示用任务j上训练后的模型，在任务i上微调后，在任务i测试集上的准确率。
   • 比值 > 1：表示正向迁移。学习任务j获得的通用特征或知识，帮助了任务i的学习，使其性能超过了独立学习。
   • 比值 ≈ 1：表示中性迁移。任务j的知识对任务i既无帮助也无害处。
   • 比值 < 1：表示负向迁移。学习任务j干扰或污染了模型对任务i相关特征的表示，导致性能下降。

3.1.2 迁移矩阵能告诉我们什么？

• 知识通用性：如果某一行（即某个源任务i的模型）在许多后续任务j上都表现出正向迁移（比值 > 1），说明这个任务学习到的特征非常通用，是一个好的“预训练”起点。例如，在ImageNet上训练的模型，可能对后续很多物体识别任务都有帮助。
• 任务相似性：如果两个任务i和k在作为源模型时，对同一个目标任务j都产生很强的正向迁移，可能暗示任务i和k在数据分布或语义上具有相似性。
• 算法抗干扰能力：一个优秀的持续学习算法，其迁移矩阵的对角线下方（即用未来任务知识微调过去任务）应该尽可能保持比值接近1，这表明算法能很好地保护旧知识不被新任务破坏。同时，非对角线区域可能出现大量正向迁移，表明算法促进了知识复用。

注意事项：计算完整的迁移矩阵计算代价极高。论文中提到，为了构建这个矩阵，他们进行了超过90,000次训练运行（106个独立任务 + 106*105/2 对迁移任务，每对再进行16组超参数随机搜索）。这凸显了大规模基准评估对计算资源的巨大需求，也说明了为什么需要一个像FLOPs这样的标准化效率指标。

3.2 超参数搜索的策略与公平性

在Nevis‘22的评估中，无论是独立学习基线还是迁移微调，都使用了随机超参数搜索。这是一个关键的设计选择，旨在确保比较的公平性。

• 为什么是随机搜索？相比于网格搜索，随机搜索在超参数空间探索上更高效，尤其当某些超参数对性能影响不大时。它为每个学习“机会”提供了公平的探索资源。
• 对独立学习者和持续学习者的意义：
  • 对于独立学习者（即每个任务从头训练），超参数搜索是为了找到该任务上的最优解，作为性能上限的参考。
  • 对于持续学习者，超参数搜索则更为复杂。它可能包括：全局超参数（如网络架构、优化器类型）、任务特定超参数（如每个任务的学习率调度）、以及持续学习策略超参数（如重放缓冲区大小、正则化强度）。Nevis‘22的协议要求，持续学习算法在流上的整个学习过程中，只能进行一次或有限次数的超参数搜索，并且搜索成本必须计入总FLOPs。这模拟了现实场景：我们无法为流中成百上千个任务逐一进行精细调参。
• “暖启动”的考量：一些持续学习算法会利用之前任务的信息来初始化新任务的超参数（即“暖启动”超参数配置）。这在Nevis‘22中是允许的，甚至是被鼓励的，因为这体现了知识复用。但关键在于，这种暖启动机制本身不能消耗过多的额外计算资源（例如，不能为每个新任务都运行一次完整的超参数搜索）。

公平性的核心在于，评估协议将计算效率和学习性能放在了同等重要的位置。一个算法如果通过为每个新任务进行大规模超参数搜索来获得高性能，其累积FLOPs会非常高，在效率排名上就会落后。这迫使研究者去设计那些对超参数鲁棒、或能自动、低成本地适应新任务的算法。

4. 实操指南：如何在Nevis‘22基准上评估你的算法

假设你设计了一个新的持续学习算法，并希望在Nevis‘22基准上验证其有效性。以下是具体的操作步骤和核心环节。

4.1 环境与数据准备

1. 获取数据流：你需要按照论文附录L和M中的列表，获取全部106个数据集（或其短版本中的26个）。这本身就是一个挑战，因为部分老旧数据集的链接可能失效，格式也需要统一。建议使用像torchvision、tensorflow-datasets或huggingface datasets这样的库，并编写脚本自动化下载和预处理流程。
2. 数据预处理标准化：为了公平比较，必须对所有数据集采用相同的预处理流程。这通常包括：
   • 图像重设尺寸：将所有图像缩放到一个统一的输入尺寸（如224x224）。注意，原始数据集的平均分辨率差异很大，从28x28到3281x2228不等，缩放策略（直接拉伸、中心裁剪、随机裁剪等）需要明确定义。
   • 数据增强：在训练时，通常采用标准的随机水平翻转、颜色抖动等。关键点：数据增强策略应在整个数据流中保持一致，且不能针对特定任务进行特殊优化，否则就违背了持续学习“未知任务流”的前提。
   • 训练/验证/测试集划分：严格使用每个数据集官方或公认的划分方式。不得为了提升性能而重新划分或混合数据。

4.2 实现评估循环

评估循环模拟模型在数据流中的学习过程。伪代码逻辑如下：

# 初始化：选择模型架构（如ResNet-18）和持续学习算法（如ER、GEM、DER等） model = YourCLAlgorithm(backbone='resnet18') total_flops = 0 performance_log = [] # 记录每个任务后的评估结果 transfer_matrix = np.zeros((num_tasks, num_tasks)) # 如果计算迁移矩阵 for task_id, task_data in enumerate(nevis22_stream): # 任务数据：task_data['train'], task_data['val'], task_data['test'] # 阶段1：在当前任务上训练/适应 # 你的持续学习算法在此处被调用，它内部会处理知识更新、防止遗忘等逻辑 # 必须在该函数内部记录此次训练所消耗的FLOPs task_flops = model.learn_task(task_data['train'], task_data['val']) total_flops += task_flops # 阶段2：评估当前学完后的模型在所有已见任务上的性能 current_accuracies = [] for seen_task_id in range(task_id + 1): acc = evaluate(model, all_tasks_test_data[seen_task_id]) current_accuracies.append(acc) performance_log.append(current_accuracies.copy()) # 记录历史准确率 # 计算平均准确率（ACC）和向后传递（BWT）等指标 # ... # 流学习结束后，输出最终指标和总FLOPs print(f"Final Average Accuracy: {compute_final_avg_acc(performance_log)}") print(f"Total Cumulative FLOPs: {total_flops}")

关键实现细节：

• FLOPs计数：你需要使用分析工具（如fvcore、ptflops库，或框架自带的profiler）来估算一次前向+反向传播的FLOPs。然后乘以训练的总迭代次数（epochs × batches per epoch）。注意，不同批大小下的FLOPs是线性的。确保你的计数包含了模型所有部分（包括算法可能引入的额外网络，如生成器、判别器、额外分类头等）。
• 评估阶段：评估时，模型应处于推理模式，不计算梯度，因此评估本身的FLOPs通常不计入总成本（除非你的算法包含需要前向传播的复杂评估过程）。评估所有已见任务是为了监控遗忘情况。

4.3 计算核心评估指标

完成数据流学习后，你需要计算以下核心指标：

1. 平均准确率：这是最直接的性能指标。通常有两种计算方式：

   • 最后准确率：模型学完整个流后，在所有任务测试集上准确率的平均值。
   • 平均增量准确率：模型在学完每个任务后，立即评估所有已见任务，然后将所有这些准确率平均。这个指标更能反映学习过程中的稳定性。

2. 向后传递：量化灾难性遗忘的程度。计算公式通常为：BWT = (1/(T-1)) * Σ_{i=1}^{T-1} (R_{T,i} - R_{i,i})，其中T是总任务数，R_{i,i}是刚学完任务i后在任务i上的准确率，R_{T,i}是学完所有任务后，再回头测试任务i的准确率。BWT越接近0越好，负数表示发生了遗忘。

3. 累积浮点运算次数：你的算法在整个学习过程中消耗的总FLOPs。这是Nevis‘22强调的效率指标。

4. 帕累托前沿分析：将你的算法与其他基线算法在平均准确率-总FLOPs的二维平面上画点。一个优秀的算法应该位于这张图的左上角区域（高准确率、低FLOPs）。通过比较不同算法与帕累托前沿的距离，可以综合判断其优劣。

5. 常见问题、挑战与避坑指南

在实际使用Nevis‘22基准进行研究时，你会遇到不少挑战。以下是一些常见问题及解决思路。

5.1 数据获取与处理的挑战

• 问题：106个数据集来源分散，部分数据集链接过期，标注格式不统一（如PASCAL VOC的XML，COCO的JSON），图像尺寸、色彩空间各异。
• 解决方案：
  • 使用标准化接口：尽可能利用torchvision.datasets、tensorflow_datasets或huggingface datasets。对于它们不包含的数据集，可以尝试提交新增数据集的请求或自己编写加载脚本。
  • 建立本地数据仓库：将所有数据集下载、预处理（统一缩放、格式转换）后，存储在高性能的本地存储或网络存储中，并编写一个统一的DataLoader。这是一次性的基础设施工作，但能极大提升后续实验效率。
  • 编写健壮的预处理流水线：确保你的预处理代码能处理各种边缘情况（灰度图转RGB、异常图像文件等）。

5.2 计算资源与实验管理

• 问题：完整运行106个任务的流，即使对于短版本，也需要巨大的计算资源和时间。超参数搜索和迁移矩阵计算更是“计算怪兽”。
• 解决方案：
  • 从短版本开始：Nevis‘22提供了一个包含26个数据集的“短版本”流。在进行算法原型开发和初步调优时，应优先使用短版本。
  • 分布式计算：如果计算迁移矩阵或进行大规模超参数搜索，必须利用分布式训练框架（如PyTorch DDP, Horovod）。
  • 实验跟踪与管理：使用Weights & Biases,MLflow或TensorBoard等工具严格记录每一次实验的超参数、FLOPs、中间准确率和最终结果。混乱的实验管理会在大规模基准测试中导致灾难。

5.3 算法设计的针对性调整

• 问题：我的算法在小型基准（如Split MNIST）上效果很好，但在Nevis‘22上崩溃了（性能骤降或计算爆炸）。
• 排查与调整：
  • 检查内存增长：许多基于重放的算法需要存储旧样本。在106个任务的长期流中，缓冲区管理策略至关重要。是固定大小？还是动态增长？动态增长可能会最终导致内存不足。你需要设计一个高效的样本选择与淘汰策略。
  • 审视参数数量：基于参数隔离（如添加任务特定模块）的方法，其参数量会随任务线性增长。在长期流中，这可能变得不可接受。考虑参数共享、动态网络或参数剪枝技术。
  • 优化器与学习率调度：长期流中，不同任务的最优学习率可能不同。简单的固定学习率或阶梯下降可能不适用。考虑使用更鲁棒的优化器（如AdamW），或引入与任务相关的学习率自适应机制。
  • 领域适配：Nevis‘22流包含剧烈的领域变化。你的算法是否包含某种形式的领域泛化或特征解耦组件？学习对领域变化不敏感的通用特征，对于在这个基准上取得好成绩至关重要。

5.4 对FLOPs指标的误解与澄清

• 误解：“我的算法FLOPs低，所以一定更好。”

• 澄清：FLOPs是一个效率指标，必须与性能指标结合来看。一个FLOPs极低但准确率也很低的算法没有实用价值。Nevis‘22鼓励寻找准确率与FLOPs之间的最佳权衡。有时，为了获得小幅性能提升而大幅增加FLOPs可能是值得的，但边际效益会递减。你的目标应该是推动帕累托前沿向外移动。

• 误解：“我可以通过工程优化（如混合精度训练、更快的卷积实现）来大幅降低FLOPs，从而‘刷榜’。”

• 澄清：FLOPs衡量的是算法层面的计算复杂度，而不是实现层面的绝对执行时间。工程优化虽然重要，但Nevis‘22更关注算法思想本身的效率。所有对比算法应在相似的实现优化水平下进行比较。论文中使用JAX API在CPU上估算FLOPs，正是为了剥离硬件特定优化带来的影响。

5.5 结果分析与论文撰写

• 问题：我的算法在某个指标上领先，但在另一个指标上落后，如何呈现？
• 建议：
  • 全面报告：必须同时报告平均准确率（或平均增量准确率）和累积FLOPs。绘制准确率-FLOPs散点图，将自己的算法与主流基线（如独立训练、微调、EWC、GEM、ER、DER等）放在一起比较。
  • 消融实验：如果你的算法包含多个组件（如重放+正则化），需要通过消融实验说明每个组件对性能和FLOPs的贡献。
  • 分析失败案例：诚实地分析你的算法在哪些类型的任务上表现不佳（例如，从自然图像到医学图像的过渡），并讨论可能的原因。这比只展示优点更有价值。
  • 讨论可扩展性：基于你在106个任务流上的观察，推测你的算法在更大规模（如1000个任务）流上的表现。其FLOPs增长趋势是线性的、对数的还是指数的？这对于判断算法的长期实用性至关重要。

我个人在尝试复现和基于Nevis‘22进行实验的过程中，最大的体会是：它迫使你从“玩具问题”的舒适区走向“现实世界”的复杂性。你不能再仅仅关注精巧的防止遗忘机制，还必须严肃思考计算预算、内存管理和跨域泛化。这个基准就像一面镜子，清晰地照出了哪些算法是“温室里的花朵”，哪些真正具备了在动态世界中生存和成长的潜力。它可能提高了研究的门槛，但无疑将推动持续学习领域朝着更实用、更高效的方向发展。