第五名解决方案：Team Danube

感谢 Kaggle 和所有参赛者带来了一场有趣的比赛。我希望这个比赛能再次举办，这次首届比赛算是解决所有问题的试运行 :)

以下是我们（与 @dott1718 和 @ilu000 合作）解决方案的简要总结。

数据与预训练

对于用于微调的最终模型，我们仅使用比赛数据以及单独的 33k 数据集。我们没有采用任何伪标签或知识蒸馏，也没有使用额外的 1M 数据集。

然而，我们发现对奖励数据进行预训练对最终模型有帮助。这是在探索 RewardBench 模型后发现的，我们发现当在竞争数据上微调时，某些顶级模型的表现优于这些模型的基础版本和指令版本。特别是 RLHFlow 分享的模型表现非常好，让我们很好奇，我们看到他们用大量的 UltraFeedback 和类似数据训练了这些模型。

因此，我们决定也在公共奖励数据（主要是 UltraFeedback 数据）上预训练 gemma-2-9b。我们尝试了各种设置，但最终发现仅训练二元 win/loss 标签就足够了。数据量也不是特别关键，所以使用 UltraFeedback 的所有数据就足够了。将这些预训练的检查点作为微调的起点，使我们的 CV 和公共 LB 分数提高了多达 20 分。我们最终的微调模型本地单折得分约为 0.880。

所有模型均使用 H2O LLM Studio 训练。

最终模型

我们的最终提交是两个模型的集成，这两个模型都是基于上述预训练检查点微调的 gemma-2-9b 模型。具体来说，我们在完整数据上将相同配置训练两次，每次一个 epoch。每次运行都交换了响应 A 和 B 的训练顺序以获得微小的多样性。最终提交然后运行这两个模型，其中一个按原始顺序运行，另一个按交换顺序运行以进行 TTA（测试时增强）。这种混合的本地单折得分约为 0.873。

推理

我们在 kernel 中探索了更快的推理，但不幸的是 Kaggle kernel 中的 T4 GPU 没有太多改进空间。我们发现最有效的设置如下：

• 在一个 GPU 上运行一半数据，在另一个 GPU 上并发运行另一半数据
• 按长度排序并优化批处理形成
• 使用 bitsandbytes 进行 INT8 量化和 float16 计算

即使最大上下文长度为 8k，这也可以轻松运行两个模型。为了安全起见，我们的最终提交使用 4k。

我们的最终推理代码 在线可用。