批内候选数为什么和 batch 绑在一起？
课堂上下文：从哪个问题来
从同一个视图列表指认查询、自身和正例：4×4 到 6×6，每行候选从 3 项到 5 项。随后再把候选来源转为计算组织问题，为 MoCo 队列做铺垫。
SimCLR 从 N 张原图产生 2N 个视图。P14 的两轴使用同一个视图列表，行是查询、列是候选。两张原图 A、B 对应 A1、A2、B1、B2；矩阵是 4×4。固定查询 A1，A1 自身排除，A2 是同源正例，B1、B2 是其余候选，所以每行比较 3 项。三张原图再加 C1、C2，矩阵成为 6×6，每行比较 5 项。一般地，每行排除自身后有 2N−1 项：1 个同源正例、2N−2 个其他候选。
主对角用灰色斜线排除，绿色格表示同一原图的另一个视图。若采用“两组不同视图分别作为两轴”的另一种排法，正例可以在对角；不能离开轴身份，仅凭绿色位置判断矩阵的含义。
这些候选都由当前参数编码，彼此处于同一轮表示空间；代价是本步要处理更多图像与反向传播状态，完整的两两比较矩阵随视图数平方增加。增大 N 也会改变优化行为，并不只是免费加几个负例。
MoCo 的提问是：能否复用前几批已经算好的 key，让候选数超过当前 batch？这是下一方法的资源取舍，不是在 SimCLR 这一次比较中直接把旧键塞进矩阵。保存向量通常比保存整个图像计算图轻，但旧向量来自旧参数。下一页的队列解决“从哪里拿更多候选”，再下一页的 EMA 处理“拿来的旧候选是否仍可比较”。
两轴同列六个视图；A1 排除自身，A2 是同源正例，B1、B2、C1、C2 是四个其他候选。历史字典是下一方法的资源取舍。 查看对应图解状态
- 全部来自当前批次
- 能否复用历史特征？
- 3 张原图 → 6 个视图
- 原图 A
- A1
- A2
- 原图 B
- B1
- B2
- 原图 C
- C1
- C2
- 两轴使用同一个视图列表；行表示查询
- A1
- +
- A2
- +
- B1
- +
- B2
- +
- C1
- +
- C2
- +
- A1
- A2
- B1
- B2
- C1
- C2
- 固定查询 A1
- A1：自身，排除
- A2：同源正例
- B1、B2、C1、C2：其余候选
- 每行：1 + 4 = 5 项
- 自身排除
- 同源正例
- 2N−2 个其余候选
- 当前编码 6 个视图；完整比较矩阵 6 × 6（随 2N 平方增长）。
- 下一方法：MoCo 的取舍
- 先问能否保存已算的 key
- 复用旧向量，减少本轮编码
- 候选数与当前批次能否解耦？
- 旧键还足够可比吗？