炒股配资门户 Codeforces难题不够刷? 谢赛宁等造了AI出题机, 能生成原创编程题

机器之心报道炒股配资门户

Rich Sutton 曾说过：「AI 只能在可以自我验证的范围内创造和维持知识。」爱因斯坦与英费尔德在合著的《物理学的进化》中也写道：「提出一个问题往往比解决问题更重要，后者或许仅仅是数学或实验技巧的问题。而提出新的问题、新的可能性，从新的角度审视旧的问题，则需要创造性的想象力，并标志着科学的真正进步。」

随着大型语言模型（LLM）朝着通用能力迈进，并以通用人工智能（AGI）为最终目标，测试其生成问题的能力也正变得越来越重要。尤其是在将 LLM 应用于高级编程任务时，因为未来 LLM 编程能力的发展和经济整合将需要大量的验证工作。

首先，为编程竞赛出题需要比解决问题更深刻的算法理解。

例如，基础问题可能会被归结为可识别的模板，用简单的技巧就能解决；许多标准的编程问题也常常允许提交部分正确或样板化的解决方案，这可能会掩盖错误的推理过程。而竞赛编程问题有着严格的标准，旨在评估对底层算法设计原则、数据结构和复杂性权衡的更深层次理解。验证数量庞大的可能解法，并充分覆盖各种捷径或边界情况是极具挑战性的，但这对于竞赛编程问题而言是必需的。因此，出题不仅包含了解决问题的所有挑战，甚至还超越了它。

其次，更好的出题能力将带来更严谨的竞赛编程基准测试。由于像 Codeforces 和 AtCoder 这类顶级平台的官方测试数据并不公开，研究人员目前依赖于合成的数据集，如 CodeContests+、TACO 和 HardTests。

然而，分析表明，现有的测试数据集可能同时存在高误报率（FPR）和高漏报率（FNR)。例如，一个时间复杂度不佳的贪心算法可能会通过一系列小规模的随机测试，但却会在旨在暴露其缺陷的对抗性构造案例面前失败。这一关键弱点造成了一个扭曲的评估环境，奖励了那些能发现捷径的模型。

第三，成功地提出新颖的挑战可能为模型的自我完善和 AGI 铺平道路，同时也能验证模型在复杂软件栈中的部署情况。

那么，我们能否像训练 AI 解决问题一样，训练它提出高质量、甚至是人类想不到的新问题呢？最近，LiveCodeBench Pro 团队给出了一个响亮的回答：AutoCode。这是一个系统性的框架，可在一个闭环、多角色的系统中使用 LLM，以自动化竞赛编程问题创建和评估的整个生命周期。

论文标题：AutoCode: LLMs as Problem Setters for Competitive Programming

论文地址：https://arxiv.org/abs/2510.12803v1

项目页面：https://livecodebenchpro.com/projects/autocode/overview

值得注意的是，该团队包含来自十个机构的研究者，共有 5 位共同一作。此外，作者名单中还包括谢赛宁等著名研究者。

整体而言，这项研究做出了两大贡献：

一个增强的验证器-生成器-检查器（Validator-Generator-Checker）框架，它在测试用例生成方面实现了最先进的可靠性。

一个用于生成高质量新问题的创新过程。该过程是从一个「种子问题」开始，以在一个有前景的方向上启发 LLM。

测试用例生成

该团队的测试用例生成过程是一个结构化的框架，旨在实现最大程度的严谨性和覆盖率。

如图 1 所示，该框架始于验证器（Validator)，它是整个系统的基石。其功能是确保任何给定的输入都严格遵守问题描述中指定的所有约束。一个验证器对于最小化漏报率（FNR）至关重要，因为它能防止正确的程序在格式错误的数据上失败。

接下来，生成器采用多样化的策略来创建广泛的输入，旨在减少误报率（FPR)，即错误或低效的程序被错误地判定为正确。生成器产生的任何无效案例都会被验证器过滤掉，从而确保该团队获得一套高质量的输入。

最后，为了评估参赛者的输出，检查器会将其与参考解法的输出进行比较。

而对于交互式任务，交互器（Interactor）会与参赛者的程序进行多轮对话以给出最终判决。

由于该团队的一个突出目标是为 RLVR（Reinforcement Learning from Verified Results）提供高质量的验证器，该团队特别关注降低误报率（FPR)。该团队将测试用例（test cases)（输入 - 答案对）与测试数据（test data）区分开来，后者还包括评估所需的检查器和交互器程序。

基准测试：测试用例的稳健性

为了严格评估该团队的测试用例生成框架，他们建立了两个不同的基准。

主要基准包含 7538 个问题，来源于著名现有数据集的交集：CodeContests+、CodeContests、HardTests 和 TACO。

值得注意的是，这个大规模集合不包含交互式问题，并且由于这些数据集固有的筛选，其测试数据生成的平均难度略低于典型的 Codeforces 比赛。

为了解决这个问题并在更具挑战性的真实条件下测试新系统，该团队创建了第二个基准，包含了 720 个来自 Codeforces 的近期、有评分的比赛问题。这个集合是完全未经过滤的，包括了那些以难以处理著称的交互式问题和需要复杂、结构化测试数据的问题。该团队表示，无法在这个较新的基准上评估先前的方法，因为它们的数据生成代码库并未公开。

该团队的评估基于三个关键指标：

一致性（Consistency）衡量该团队的测试得出的判决与官方判决之间一致的总体百分比。该团队进一步将不一致的情况分解为两个关键的错误率。

误报率（FPR）定义为被该团队的生成测试错误地接受的官方不正确解法的比例。

漏报率（FNR）是被该团队的测试错误地拒绝的官方正确解法的比例。

与其他基准的比较

该团队在包含 7538 个问题的基准上，将 AutoCode 与四个领先的基准进行了评估。

如表 1 所示，该团队的框架与官方判决的一致性达到了 91.1%。这标志着一个重大的飞跃，因为之前的方法的一致性未能超过 81.0%。至关重要的是，AutoCode 将误报率（FPR）大幅降低至仅 3.7%，漏报率（FNR）降低至 14.1%，这代表着这两项指标相较于当前最先进技术均减少了约 50%。

图 2 展示了错误判决的分布，显示了大多数问题的判决与地面真实判决是一致的。

为了进一步测试该系统的稳健性，该团队还整理了一个更具挑战性的基准，包含了 720 个近期的、未经过滤的 Codeforces 问题，包括复杂的交互式任务。

如表 2 所示，AutoCode 保持了其卓越的性能，实现了 98.7% 的一致性。这一结果验证了该团队的方法在现代、困难问题上的有效性，而先前的方法无法在这些问题上进行评估。

该团队也通过消融实验验证了方法的有效性。

在建立起如此强大的测试用例生成能力之后，研究人员便将目光投向了更具创造性的任务：直接生成全新的高质量问题。

问题生成

该团队新提出的问题生成框架建立在前述的稳健测试生成框架（如图 1 所示）之上，但引入了一个关键的双重验证协议，以确保在没有人工干预的情况下实现正确性。

每个生成的问题都由顶尖的人类竞赛程序员根据一个 6 级量表进行评分。该团队咨询 8 位人类专家出题人，他们都表示在创作新问题时，常常会基于某个特定的现有问题。通过对这样一个「种子问题」的某些条件进行添加、删除或修改，他们可以创造出新的、通常更困难的、需要新颖洞察力的问题。

受他们见解的启发，该团队的方法是首先随机选择一个 Codeforces 问题（难度评分低于 2200）作为「种子问题」。LLM 的任务是通过增、删、改这个种子问题的某些条件来生成一个新问题，并同时提供一个高效的参考解法（std.cpp）和一个暴力解法（brute.cpp)。

brute.cpp 通常时间复杂度更高，但基本不可能出错，因此该团队利用它来压力测试问题的有效性。使用该团队增强的测试用例生成技术，该团队构建了一套全面的测试数据，完全覆盖了小规模案例。然后 brute.cpp 和 std.cpp 都在这个数据集上运行。只有当对于每一个测试用例，两个程序的输出（其中暴力解法可能因超时而合法地无法完成）都被检查器成对地验证为一致的答案和输出时，一个问题才被认为是正确的。

这种设计的巧妙之处在于，它利用了「虽然慢但几乎绝不会错」的暴力解法，为「虽然快但可能存在逻辑漏洞」的高效解法提供了一个无需人工干预的、绝对可靠的「事实标准」，从而实现了自动化的正确性校验。

这个双重验证协议（其中 brute.cpp 作为初始的地面真实，并且经过验证的参考解法还要再经过一个完整的测试生成周期）成功地过滤掉了 27% 的易错问题，将 LLM 提供的参考解法的正确率从 86% 提高到了 94%。

经过筛选后，超过 80% 的问题被标注为具有足够的质量，可以作为模型的训练数据，并且 23% 的问题涉及新颖或创造性的设计。该团队在图 3 中展示了详细的评分标准和分数分布。