GIT：斯坦福大学提出应对复杂变换的不变性提升方法 ICLR 2022

Posted 2023-03-20

参考技术A

论文: Do Deep Networks Transfer Invariances Across Classes?

[图片上传失败...(image-81c922-1652190840065)]

  优秀的泛化能力需要模型具备忽略不相关细节的能力，比如分类器应该对图像的目标是猫还是狗进行响应，而不是背景或光照条件。换句话说，泛化能力需要包含对复杂但不影响预测结果的变换的不变性。在给定足够多的不同图片的情况下，比如训练数据集包含在大量不同背景下的猫和狗的图像，深度神经网络的确可以学习到不变性。但如果狗类的所有训练图片都是草地背景，那分类器很可能会误判房子背景中的狗为猫，这种情况往往就是不平衡数据集存在的问题。
  类不平衡在实践中很常见，许多现实世界的数据集遵循长尾分布，除几个头部类有很多图片外，而其余的每个尾部类都有很少的图片。因此，即使长尾数据集中图片总量很大，分类器也可能难以学习尾部类的不变性。虽然常用的数据增强可以通过增加尾部类中的图片数量和多样性来解决这个问题，但这种策略并不能用于模仿复杂变换，如更换图片背景。需要注意的是，像照明变化之类的许多复杂变换是类别无关的，能够类似地应用于任何类别的图片。理想情况下，经过训练的模型应该能够自动将这些不变性转为类无关的不变性，兼容尾部类的预测。
  论文通过实验观察分类器跨类迁移学习到的不变性的能力，从结果中发现即使经过过采样等平衡策略后，神经网络在不同类别之间传递学习到的不变性也很差。例如，在一个长尾数据集上，每个图片都是随机均匀旋转的，分类器往往对来自头部类的图片保持旋转不变，而对来自尾部类的图片则不保持旋转不变。
  为此，论文提出了一种更有效地跨类传递不变性的简单方法。首先训练一个input conditioned但与类无关的生成模型，该模型用于捕获数据集的复杂变换，隐藏了类信息以便鼓励类之间的变换转移。然后使用这个生成模型来转换训练输入，类似于学习数据增强来训练分类器。论文通过实验证明，由于尾部类的不变性得到显著提升，整体分类器对复杂变换更具不变性，从而有更好的测试准确率。

  论文先对不平衡场景中的不变性进行介绍，随后定义一个用于度量不变性的指标，最后再分析不变性与类别大小之间的关系。

  定义输入 ，标签 属于 ， 为类别数。定义训练后的模型的权值 ，用于预测条件概率 ，分类器将选择概率最大的类别 作为输出。给定训练集 ，通过经验风险最小化（ERM）来最小化训练样本的平均损失。但在不平衡场景下，由于 的分布不是均匀的，导致ERM在少数类别上表现不佳。
  在现实场景中，最理想的是模型在所有类别上都表现得不错。为此，论文采用类别平衡的指标来评价分类器，相当于测试分布 在 上是均匀的。
  为了分析不变性，论文假设 的复杂变换分布为 。对于不影响标签的复杂变换，论文希望分类器是不变的，即预测的概率不会改变：

[图片上传失败...(image-c53a8f-1652190840065)]

  为了度量分类器学习不变性的程度，论文定义了原输入和变换输入之间的期望KL散度（eKLD）：

[图片上传失败...(image-1f0350-1652190840065)]

  这是一个非负数，eKLD越低代表不变性程度就越高，对 完全不变的分类器的eKLD为0。如果有办法采样 ，就能计算训练后的分类器的eKLD。此外，为了研究不变性与类图片数量的关系，可以通过分别计算类特定的eKLD进行分析，即将公式2的 限定为类别 所属。
  计算eKLD的难点在于复杂变化分布 的获取。对于大多数现实世界的数据集而言，其复杂变化分布是不可知的。为此，论文通过选定复杂分布来生成数据集，如RotMNIST数据集。与数据增强不同，这种生成方式是通过变换对数据集进行扩充，而不是在训练过程对同一图片应用多个随机采样的变换。
  论文以Kuzushiji-49作为基础，用三种不同的复杂变换生成了三个不同的数据集：图片旋转（K49-ROT-LT）、不同背景强度（K49-BG-LT）和图像膨胀或侵蚀（K49-DIL-LT）。为了使数据集具有长尾分布（LT），先从大到小随机选择类别，然后有选择地减少类别的图片数直到数量分布符合参数为2.0的Zipf定律，同时强制最少的类为5张图片。重复以上操作30次，构造30个不同的长尾数据集。每个长尾数据集有7864张图片，最多的类有4828张图片，最小的类有5张图片，而测试集则保持原先的不变。

[图片上传失败...(image-5f3fc6-1652190840065)]

  训练方面，采用标准ERM和CE+DRS两种方法，其中CE+DRS基于交叉熵损失进行延迟的类平衡重采样。DRS在开始阶段跟ERM一样随机采样，随后再切换为类平衡采样进行训练。论文为每个训练集进行两种分类器的训练，随后计算每个分类器每个类别的eKLD指标。结果如图1所示，可以看到两个现象：

  从前面的分析可以看到，长尾数据集的尾部类对复杂变换的不变性较差。下面将介绍如何通过生成式不变性变换(GIT)来显式学习数据集中的复杂变换分布 ，进而在类间转移不变性。

  如果有数据集实际相关的复杂变换的方法，可以直接将其用作数据增强来加强所有类的不变性，但在实践中很少出现这种情况。于是论文提出GIT，通过训练input conditioned的生成模型 来近似真实的复杂变换分布 。

[图片上传失败...(image-20dfe8-1652190840065)]

  论文参考了多模态图像转换模型MUNIT来构造生成模型，该类模型能够从数据中学习到多种复杂变换，然后对输入进行变换生成不同的输出。论文对MUNIT进行了少量修改，使其能够学习单数据集图片之间的变换，而不是两个不同域数据集之间的变换。从图2的生成结果来看，生成模型能够很好地捕捉数据集中的复杂变换，即使是尾部类也有不错的效果。需要注意的是，MUNIT是非必须的，也可以尝试其它可能更好的方法。
  在训练好生成模型后，使用GIT作为真实复杂变换的代理来为分类器进行数据增强，希望能够提高尾部类对复杂变换的不变性。给定训练输入 ，变换输入 ，保持标签不变。这样的变换能够提高分类器在训练期间的输入多样性，特别是对于尾部类。需要注意的是，batch可以搭配任意的采样方法(Batch Sampler)，比如类平衡采样器。此外，还可以有选择地进行增强，避免由于生成模型的缺陷损害性能的可能性，比如对数量足够且不变性已经很好的头部类不进行增强。

[图片上传失败...(image-40eca8-1652190840065)]

  在训练中，论文设置阈值 ，仅图片数量少于 的类进行数据增强。此外，仅对每个batch的 比例进行增强。 一般取0.5，而 根据数据集可以设为20-500，整体逻辑如算法1所示。

[图片上传失败...(image-cc1aaf-1652190840065)]

  论文基于算法1进行了实验，将Batch Sampler设为延迟重采样(DRS)，Update Classifier使用交叉熵梯度更新，整体模型标记为 。all classes表示禁用阈值 ，仅对K49数据集使用。作为对比，Oracle则是用于构造生成数据集的真实变换。从图3的对比结果可以看到，GIT能够有效地增强尾部类的不变性，但同时也损害了图片充裕的头部类的不变性，这表明了阈值 的必要性。

[图片上传失败...(image-a4fa9-1652190840065)]

  不同训练策略搭配GIT的效果对比。

[图片上传失败...(image-8eadb8-1652190840065)]

  在GTSRB和CIFAR数据集上的变换输出。

[图片上传失败...(image-ed16a2-1652190840065)]

  CIFAR-10上每个类的准确率。

[图片上传失败...(image-7d693a-1652190840065)]

  对比实验，包括阈值 对性能的影响，GTSRB-LT, CIFAR-10 LT和CIFAR-100 LT分别取25、500和100。这里的最好性能貌似都比RandAugment差点，有可能是因为论文还没对实验进行调参，而是直接复用了RandAugment的实验参数。这里比较好奇的是，如果在训练生成模型的时候加上RandAugment，说不定性能会更好。

  论文对长尾数据集中的复杂变换不变性进行了研究，发现不变性在很大程度上取决于类别的图片数量，实际上分类器并不能将从大类中学习到的不变性转移到小类中。为此，论文提出了GIT生成模型，从数据集中学习到类无关的复杂变换，从而在训练时对小类进行有效增强，整体效果不错。

 
 
 

Java 并发编程对象的不变性和安全的公布对象

一、不变性

        满足同步需求的还有一种方法是使用不可变对象（Immutable Object）。

到眼下为止，我们介绍了很多与原子性和可见性相关的问题，比如得到失效数据。丢失更新操作或光查到某个对象处于不一致的状态等等，都与多线程视图同一时候訪问同一个可变的状态相关。假设对象的状态不会改变，那么这些问题与复杂性也就自然消失了。

        假设某个对象在被创建后其状态就不能被改动，那么这个对象就被成为不可变对象。线程安全型是不可变对象的固有属性之中的一个，他们的不变性条件是由构造函数创建的，仅仅要他们的状态不改变，那么这些不变性条件就能得以维持。

        不可变对象非常easy。他们仅仅有一种状态，而且该状态由构造函数来控制。在程序设计中一个最困难的地方就是推断复杂对象的可能状态。然而，推断不可变对象的状态却非常easy。

        尽管在 Java 规范和 Java 内存模型中都没有给出不可变性的正式定义，但不可变性并不等于将对象中全部的域都声明为 final 类型，即使对象中全部的域都是 final 类型的，这个对象也仍然是可变的，由于在 final 类型的域中能够保存对可变对象的引用。

当满足下面条件时，对象才是不可变的：

• 对象创建完之后其状态就不能改动
• 对象的全部与都是 final 类型
• 对象时正确创建的（创建期间没有 this 的逸出）

我们来分析以下这个类。

@Immutable
public final class ThreeStooges {
    private final Set<String> stooges = new HashSet<String>();

    public ThreeStooges() {
        stooges.add("Moe");
        stooges.add("Larry");
        stooges.add("Curly");
    }

    public boolean isStooge(String name) {
        return stooges.contains(name);
    }
}

        在不可变对象的内部仍能够使用可变对象来管理它们的状态。如 ThreeStooges 所看到的。虽然保存姓名的Set对象是可变的，但从ThreeStooges的设计中能够看到。在Set对象构造完毕后无法对其进行改动。stooges是一个final类型的引用变量，因此全部的对象状态都通过一个final域来訪问。最后一个要求是“正确地构造对象”。这个要求非常easy满足，由于构造函数能使该引用由除了构造函数及其调用者之外的代码来訪问。

        因为程序的状态总在不断地变化，你可能会觉得须要使用不可变对象的地方不多。但实际情况并不是如此。

在“不可变的对象”与“不可变的对象引用”之间存在着差异。

保存在不可变对象中的程序状态仍然能够更新，即通过将一个保存新状态的实例来“替换”原有的不可变对象。

       

Final 域

        keyword final 能够视为 C++ 中 const 机制的一种受限版本号，用于构造不可变对象。final 类型的域是不能改动的（但假设 final 域所引用的对象时可变的，那么这些被引用的对象是能够改动的）。然而，在 Java 内存模型中，final 域还有着特殊的语义。final 域能确保初始化过程的安全性。从而能够不受限制的訪问不可变对象，并在共享这些对象时无需同步。

注：个人理解为，final 字段一旦被初始化完毕。并且构造器没有把 this 引用传递出去，那么在其它线程中就能看到 final 字段的值（域内变量可见性，和 volatile 类似），并且其外部可见状态永远也不会改变。它所带来的安全性是最简单最纯粹的。

注：即使对象是可变的，通过将对象的某些域声明为final类型。仍然能够简化对状态的推断。因此限制对象的可变性也就相当于限制了该对象可能的状态集合。仅包括一个或两个可变状态的“基本不可变”对象仍然比包括多个可变状态的对象简单。通过将域声明为final类型，也相当于告诉维护人员这些域是不会变化的。

        正如“除非须要更高的可见性，否则应将全部的饿域都声明为私有域”[EJ Item 12]是一个良好的变成习惯，“除非须要某个域是可变的，否则应将其声明为final域”也是一个良好的变成习惯。

演示样例：使用 Volatile 类型来公布不可变对象

        之前我们讲过， volatile 能够用来保证域的可见性而不能保证变量操作的原子性，更为准确的讲。仅仅能保证读写操作具有原子性，而不能保证自增 i++ 等运算操作的原子性。

        在前面的UnsafeCachingFactorizer类中，我们尝试用两个AtomicReferences变量来保存最新的数值及其因数分解结果，但这样的方式并不是是线程安全的，由于我们无法以原子方式来同一时候读取或更新这两个相关的值。相同。用volatile类型的变量来保存这些值也不是线程安全的。然而，在某些情况下，不可变对象能提供一种弱形式的原子性。

        因式分解Servlet将运行两个原子操作：更新缓存的结果，以及通过推断缓存中的数值是否等于请求的数值来决定是否直接读取缓存中的因数分解结果。

每当须要对一组相关数据以原子方式运行某个操作时，就能够考虑创建一个不可变的类来包括这些数据，比如 OneValueCache。

@Immutable
class OneValueCache {
    private final BigInteger lastNumber;
    private final BigInteger[] lastFactors;

    /**
     * 假设在构造函数中没有使用 Arrays.copyOf()方法。那么域内不可变对象 lastFactors却能被域外代码改变
     * 那么 OneValueCache 就不是不可变的。
     */
    public OneValueCache(BigInteger i,
                         BigInteger[] factors) {
        lastNumber  = i;
        lastFactors = Arrays.copyOf(factors, factors.length);
    }

    public BigInteger[] getFactors(BigInteger i) {
        if (lastNumber == null || !lastNumber.equals(i))
            return null;
        else
            return Arrays.copyOf(lastFactors, lastFactors.length);
    }
}

        对于在訪问和更新多个相关变量时出现的竞争条件问题，能够通过将这些变量所有保存在一个不可变对象中来消除。

假设是一个可变的对象，那么就必须使用锁来确保原子性。

假设是一个不可变对象，那么当线程获得了对该对象的引用后，就不必操心还有一个线程会改动对象的状态。假设要更新这些变量。那么能够创建一个新的容器对象。但其它使用原有对象的线程仍然会看到对象处于一致的状态。

        在 VolatileCachedFactorizer使用了OneValueCache来保存缓存的数值及其因数。我们将 OneValueCache 声明为 volatile，这样当一个线程将cache设置为引用一个新的OneValueCache时，其它线程就会马上看到新缓存的数据。

@ThreadSafe
public class VolatileCachedFactorizer implements Servlet {
    private volatile OneValueCache cache =
        new OneValueCache(null, null);

    public void service(ServletRequest req, ServletResponse resp) {
        BigInteger i = extractFromRequest(req);
        BigInteger[] factors = cache.getFactors(i);
        if (factors == null) {
            factors = factor(i);
            cache = new OneValueCache(i, factors);//声明为 volatile 。防止指令重排序，保证可见性
        }
        encodeIntoResponse(resp, factors);
    }
}

        与cache相关的操作不会相互干扰。由于OneValueCache是不可变的。而且在每条对应的代码路径中仅仅会訪问它一次。通过使用包括多个状态变量的容器对象来维持不变性条件。并使用一个volatile类型的引用来确保可见性，使得Volatile Cached Factorizer在没有显式地使用锁的情况下仍然是线程安全的。

二、安全公布

        到眼下为止，我们重点讨论的是怎样确保对象不被公布，比如让对象封闭在线程或还有一个对象的内部。当然，在某些情况下我们希望在多个线程间共享对象，此时必须确保安全地进行共享。然而，假设仅仅是像以下程序那样将对象引用保存到公有域中，那么还不足以安全地公布这个对象。

//不安全的公布
public Holder holder;

public void initialize() {
    holder = new Holder(42);
}

        你可能会奇怪。这个看似没有问题的演示样例何以会执行失败。

因为存在可见性问题，其它线程看到的Holder对象将处于不一致的状态，即便在该对象的构造函数中已经正确地构建了不变性条件。这样的不对的公布导致其它线程看到尚未创建完毕的对象。

不对的公布：正确的对象被破坏

        你不能指望一个尚未被全然创建的对象拥有完整性。某个观察该对象的线程将看到对象处于不一致的状态。然后看到对象的状态突然发生变化，即使线程在对象公布后还没有改动过它。其实，假设以下程序中的Holder使用前面程序中的不安全公布方式，那么还有一个线程在调用assertSanity时将抛出AssertionError。

public class Holder {
    private int n;

    public Holder(int n) { this.n = n; }

    public void assertSanity() {
        if (n != n)
            throw new AssertionError("This statement is false.");
    }
}

        因为没有使用同步来确保Holder对象对其它线程可见，因此将Holder称为“未被正确公布”。在未被正确公布的对象中存在两个问题。

        首先，除了公布对象的线程外，其它线程能够看到的Holder域是一个失效值。因此将看到一个空引用或者之前的旧值。

        然而，更糟糕的情况是，线程看到Holder引用的值是最新的，但Holder状态的值却是失效的。情况变得更加不可预測的是，某个线程在第一次读取域时得到失效值，而再次读取这个域时会得到一个更新值。这也是assertSainty抛出AssertionError的原因。

        假设没有足够的同步，那么当在多个线程间共享数据时将发生一些很奇怪的事情。

不可变对象与初始化安全性

        因为不可变对象是一种很重要的对象，因此Java内存模型为不可变对象的共享提供了一种特殊的初始化安全性保证。我们已经知道，即使某个对象的引用对其它线程是可见的，也并不意味着对象状态对于使用该对象的线程来说一定是可见的。为了确保对象状态能呈现出一致的视图，就必须使用同步。

        还有一方面。即使在公布不可变对象的引用时没有使用同步，也仍然能够安全地訪问该对象。

为了维持这样的初始化安全性的保证。必须满足不可变性的全部需求：状态不可改动，全部域都是final类型。以及正确的构造过程。（假设Holder对象是不可变的，那么即使Holder没有被正确地公布。在assertSanity中也不会抛出AssertionError。

）

        不论什么线程都能够在不须要额外同步的情况下安全地訪问不可改变对象，即使在公布这些对象时没有使用同步。

        这样的保证还将延伸到被正确创建对象中全部final类型的域。在没有额外同步的情况下，也能够安全地訪问final类型的域。然而。假设final类型的域所指向的是可变对象。那么在訪问这些域所指向的对象的状态时仍然须要同步。

安全公布的经常使用模式

        可变对象必须通过安全的方式来公布，这通常意味着在公布和使用该对象的线程时都必须使用同步。

如今，我们将重点介绍怎样确保使用对象的线程可以看到该对象处于已公布的状态。并稍后介绍怎样在对象公布后对其可见性进行改动。

        安全地公布一个对象。对象的应用以及对象的状态必须同一时候对其它线程可见。一个正确构造的对象能够通过下面方式来安全地公布：

• 在静态初始化函数中初始化一个对象引用
• 将对象的应用保存到volatile类型的域或者AtomicReferance对象中
• 将对象的引用保存到某个正确构造对象的final类型域中
• 将对象的引用保存到一个由锁保护的域中。

        在线程安全容器内部的同步意味着，在将对象放入到某个容器。比如Vector或synchronizedList时，将满足上述最后一条需求。假设线程A将对象X放入一个线程安全的容器。随后线程B读取这个对象，那么能够确保B看到A设置的X状态，即便在这段读/写X的应用程序代码中没有包括显式的同步。虽然Javadoc在这个主题上没有给出非常清晰的说明，但线程安全库中的容器类提供了下面的安全公布保证：

• 通过将一个键或者值放入Hashtable、synchronizedMap或者ConcurrentMap中，能够安全地将它公布给不论什么从这些容器中訪问它的线程（不管是直接訪问还是通过迭代器訪问）
• 通过将某个元素放入Vector、CopyOnWriteArrayList、CopyOnWriteArraySet、synchronizedList或synchronizedSet中，能够将该元素安全地公布到不论什么从这些容器中訪问该元素的线程
• 通过将某个元素放入BlockingQueue或者ConcurrentLinkedQueue中，能够将该元素安全地公布到不论什么从这些队列中訪问该元素的线程。

        类库中的其它数据传递机制（比如Future和Exchanger）相同能实现安全公布。在介绍这些机制时将讨论它们的安全公布功能。

        通常，要公布一个静态构造的对象，最简单和最安全的方式是使用静态的初始化器：
                public static Holder holder = new Holder(42);

        静态初始化器由JVM在类的初始化阶段运行。

因为在JVM内部存在着同步机制，因此通过这样的方式初始化的不论什么对象都能够被安全地公布[JLS 12.4.2]。

事实不可变对象

        假设对象在公布后不会被改动，那么对于其它在没有额外同步的情况下安全地訪问这些对象的线程来说，安全公布是足够的。全部的安全公布机制都能确保。当对象的引用对全部訪问该对象的线程可见时，对象公布时的状态对于全部线程也将是可见的，而且假设对象状态不会再改变，那么就足以确保不论什么訪问都是安全的。

        假设对象从技术上来看是可变的，但其状态在公布后不会再改变。那么把这样的对象称为“事实不可变对象（Effectively Immutable Object）”。这些对象不须要满足之前提出的不可变性的严格定义。在这些对象公布后。程序仅仅需将它们视为不可变对象就可以。通过使用事实不可变对象。不仅能够简化开发过程，并且还能因为降低了同步而提高性能。

        在没有额外的同步的情况下，不论什么线程都能够安全地使用被安全公布的事实不可变对象。

        比如，Date本身是可变的，但如果将它作为不可变对象来使用，那么在多个线程之间共享Date对象时，就能够省去对锁的使用。

如果须要维护一个Map对象，当中保存了每位用户的近期登录时间：
                public Map<String, Date> lastLogin =Collections.synchronizedMap(new HashMap<String, Date>());

        假设Date对象的值在被放入Map后就不会改变，那么synchronizedMap中的同步机制就足以使Date值被安全地公布。而且在訪问这些Date值时不须要额外的同步。

可变对象

        假设对象在构造后能够改动，那么安全公布仅仅能确保“公布当时”状态的可见性。对于可变对象，不仅在公布对象时须要使用同步，并且在每次对象訪问时相同须要使用同步来确保兴许改动操作的可见性。

要安全地共享可变对象。这些对象就必须被安全地公布。并且必须是线程安全的或者由某个锁保护起来。

        对象的公布需求取决于它的可变性：

• 不可变对象能够通过随意机制来公布
• 事实不可改变必须通过安全方式公布
• 可变对象必须通过安全方式公布。而且必须是线程安全的或者由某个锁保护起来

安全的共享对象

        当获得对象的一个引用时，你须要知道在这个引用上能够运行哪些操作。

在使用它之前是否须要获得一个锁？能否够改动它的状态，或者仅仅能读取它？很多并发错误都是因为没有理解共享对象的这些“既定规则”而导致的。当公布一个对象时，必须明白地说明对象的訪问方式。