第7名方案

框架与硬件

起初我们尝试同时使用 TF 1.15 和 TF 2.0。不幸的是，TF 2.0 流程的得分明显较低（我们可能没有弄清楚如何正确使用 TF 2.0 的 API），因此我们所有排名靠前的提交以及下文描述的内容都是在 TF 1.15 中完成的。

所有的实验都在 Google 云 TPU 上进行。这是我第一次认真使用 TPU，不得不说，感觉非常棒。因为它们速度非常快，而且 Google 很慷慨地给了我们 5 个 TPU，实验周期大大缩短了。

验证方案与实验设置

我们注意到评估指标在较小的验证集上不是很稳定，例如在 dev00（1600个样本）上较好的模型在 dev01 上可能并不更好。因此我们完全依赖整个开发集（7830个样本）进行验证（即选择检查点、选择模型、调整阈值、调整集成权重）。公共 LB 也是如此。它只有 346 个样本，甚至比 dev00 还不稳定。

我们的大多数模型都基于 joint-bert 的官方实现，这令人惊讶地难以超越。对于 joint-bert 的每个变体，我们在 TPU 上同时运行 5 个训练会话，使用不同的批大小和学习率。我们每 500 或 1000 步保存一次检查点。通常 bs=64 和 lr=4e-5 训练 1 个 epoch 能获得最佳分数。

官方 Joint-BERT 的变体

我们尝试了以下对 joint-bert 的改进。其中许多想法来自这篇 IBM 的论文：https://arxiv.org/pdf/1909.05286.pdf。第 1) 和 2) 点是最重要的，添加它们总是有帮助的，它们造就了最佳的单模型。第 3) 到 6) 点有时有用，有时没用，它们相互依赖。不过，使用这些变体进行训练确实产生了许多多样化的模型，这有利于模型集成。

1) 预训练权重

官方 joint-bert 是从 "BERT-Large, Uncased" 训练的，但从 "BERT-Large, Uncased (Whole Word Masking)" 开始训练会有很大的提升。

我们还尝试在 NQ 上微调 joint-bert 之前，先在 Squad 2.0 上进行微调。

2) 负采样

官方 joint-bert 在可回答问题（即不包含答案的滑动窗口）和不可回答问题中都采样 2% 的负样本。正如 IBM 论文中所解释的，joint-bert 倾向于对不可回答的问题过于自信，因此可回答问题采样 1% 和不可回答问题采样 4% 似乎更好。我们通过负采样看到了 F1 分数大约 1 个百分点的提升。

3) max_seq_length, doc_stride

默认值分别为 512 和 128。这意味着对于不在文章开头的答案，它们在预处理后会出现约 4 次（在训练中每个 epoch 样本被看到 4 次，在推理中预测 4 次，然后选择 logit 最大的那个），这似乎有些过头。

所以我们在推理期间将 doc_stride 改为 256，这对分数影响不大，但将推理时间减少了一半。

对于训练，我们使用了默认值 128 以及 192 和 256。IBM 论文声称 192 效果最好，但我们没有看到太大差异。

4) max_contexts

默认值是 48。有些维基百科文章非常长，所以 joint-bert 只取每篇文章的前 48 个段落/表格/列表。我们尝试了不同的值，如 100 和 200。使用更大的值是在更多答案覆盖率与更多“空”窗口之间进行权衡。

5) 句子顺序打乱

IBM 论文中也提出了这一点：打乱包含短答案的段落中的所有句子。这是一种数据增强方法。

6) 区分大小写

do_lower_case=False。为此，我们通过将所有 NQ 特殊标记添加到区分大小写的 BERT 词汇表中生成了一个新的 vocab 文件。

7) 注意力机制

IBM 论文中提到这是最重要的改变，但对我们不起作用。

模型集成

在 3 小时内，我们可以对 doc_stride=256 的 3 个模型进行推理。幸运的是，n=3 恰好是我们最佳集成的数量：增加第四个模型不再有帮助。集成策略简单地是平均每个候选跨度的概率。

我们的 2 次提交由以下 5 个单模型组成：

• a. wwm, stride=256, dev