第三名解决方案报告

首先，我想感谢 Aimo 和 Kaggle 组织了这次比赛，同时也感谢所有在整个过程中分享见解和想法的参与者。多亏了你们，我学到了很多，并在整个旅程中获得了极大的乐趣。

虽然我的解决方案相对简单，但我最终获得了第 3 名。
公共榜单得分：25/50
私有榜单得分：30/50

1. 模型

没有额外的训练，没有 DPO、GRPO 或类似的操作——我只是采用了开放解决方案中使用最流行的模型（可能是 7B 版本之后）——由 ShelterW 进行 AWQ 量化的 Deepseek-R1-Distill-Qwen-14B。

2. 动机

• 在 10 个验证问题上运行模型时，我真的感到很烦恼，因为在解决简单任务时，大多数解决方案分支通常都会导向相同的答案，但我们却花费了太多时间。我非常希望能够动态控制何时继续生成变得毫无意义。这在 10 个解决方案中已有 9 个正确，而最后一个陷入循环并一直生成直到最终 token 的情况下尤其相关。

• 我也遵循了以下直觉——很可能，我们越接近解决方案的开始，所有解决方案分支之间的共同点就越多。似乎随着生成的进行，产生幻觉的概率会增加。根据我手动审查验证问题的经验，前 ~4096 个 token 在任何根本方式上并没有太大差异。

3. 解决方案的核心部分：

所以让我们来看看这个想法——基于上述动机，我实施了以下算法：

1. 我们从 5 个解决方案分支开始，为每个分支生成前 4096 个 token。
2. 然后我们复制每个分支（所以下一轮我们将有 10 个解决方案），再生成另外 4096 个 token。
3. 此时，我们可能已经有了足够的解决方案来做出决定，所以我实施了以下规则：
   • 如果在 8192 个 token 之后，我们已经有超过 6 个完成的解决方案（使用正则表达式 \boxed{} 检测），并且其中一个答案占所有的 70% 以上，我们就停止生成。确实，模型从这一点开始产生不同答案的概率相当低，我们可以节省宝贵的 token（尤其是考虑到随着上下文变长，注意力机制的计算复杂性也在增加）。
   • 如果不是，我们进入第 4 步。
4. 由于复制每个解决方案会导致 20 个分支，这太多了，我随机选择了 7 个未完成的分支，复制它们—— resulting in 14 个分支——并生成接下来的 4096 个 token。
5. 然后我们收集所有解决方案并进行多数投票。

因为在最坏的情况下，我们不得不重新计算相同的 KV 缓存（甚至两次）——所以在 vllm.LLM 中设置标志 enable_prefix_caching=True 非常重要。

通过这种方式，我们可以生成 14 个高达 12k token 的解决方案，加上那些 0-3 个可能在 8k token 处达到答案的分支（实际上，即使在 4k token 处，代码通常也保持不变，但由于这种情况很少发生且为了简单起见，我省略了该细节）。我没有收集完整的统计数据，但根据我的观察，这通常需要大约 6-7 分钟。考虑到我们经常能获得早期答案，平均而言我们应该在时间限制内。

这个优化并非没有缺陷——例如，由于共享前缀，解决方案仍然会有些许相关性。然而，这似乎并不太关键，并且通过不同分支的不同提示词部分抵消了。

另外，如果时间不足（基于 cutoff_times 数组），我们从 6 个分支开始，在 4096 个 token 后复制它们，并在 8192 个 token 处停止。

所有额外细节（温度、提示词等）你可以在笔记本中查看。

我的得分部分归功于运气，然而，核心想法似乎很有趣，我很乐意看到它进一步发展。

我很乐意回答您可能有的任何问题，所以请随时提问！