Planning In Natural Language Improves LLM Search For Code Generation翻译

摘要

虽然扩展训练的计算量已导致大型语言模型 (LLM) 显著改进，但扩展推理的计算量尚未产生类似的收益。我们假设一个核心缺失组件是缺乏多样化的 LLM 输出，导致搜索效率低下，因为模型反复采样高度相似但不正确的生成。我们通过经验证明，可以通过在自然语言中搜索用于解决问题的候选计划来缓解这种多样性的缺乏。基于这一见解，我们提出了 PLANSEARCH，这是一种新的搜索算法，在 HumanEval+、MBPP+ 和 LiveCodeBench（高难度编码的无污染基准）中表现出色。PLANSEARCH 会生成一组关于问题的多样化观察结果，然后使用这些观察结果来制定解决问题的计划。通过搜索自然语言中的计划而不是直接搜索代码解决方案，与基线搜索方法相比，PLANSEARCH 探索了更加多样化的潜在解决方案。在 Claude 3.5 Sonnet 上使用 PLANSEARCH 在 LiveCodeBench 上实现了 77.0% 的最先进的 pass@200，超过了不使用搜索（pass@1 = 41.4%）和使用标准重复采样（pass@200 = 60.6%）所获得的最佳分数。最后，我们表明，在分析的所有模型、搜索算法和基准测试中，我们可以准确预测搜索带来的性能提升，这是生成想法多样性的直接函数。

1.介绍

　　著名的bitter lesson是，有两种形式的扩展胜过其他一切形式：学习和搜索。尽管大型语言模型的最新进展消除了人们对学习有效性的所有怀疑，但搜索尚未证明其对大型语言模型的价值，尽管它在经典机器学习技术上取得了成功。
　　在这里，我们将搜索称为在推理时花费额外计算量以提高整体性能的任何方法。在这项工作中，我们专注于改进 LLM 搜索以生成代码，这是 LLM 当前最重要的应用之一。我们假设，阻碍在推理时广泛使用代码搜索的主要瓶颈是模型输出缺乏高级多样性。这种缺乏多样性的部分原因可能是通常用于将 LLM 训练为聊天机器人的特定后训练目标，其中模型通常经过优化以产生单个正确答案。我们通过经验证明，许多经过大量后训练的开源语言模型都是这种情况。具体而言，我们表明，在许多情况下，尽管指令微调模型在单个样本方案（pass@1）上的表现远胜于基础模型，但当生成许多样本时，这种趋势就会消失——有时甚至会逆转。我们将图 3 用作这种现象的一个例子。
　　此外，缺乏多样性对搜索算法尤其有害。在最恶劣的多样性很少或没有多样性的情况下，例如贪心解码，从模型中重复采样会返回高度相似的程序，导致额外的推理时间计算，但是带来的收益微乎其微。这种多样性问题也没有反映在许多公共排行榜（例如 LMSYS Chatbot Arena、LiveCodeBench、OpenLLMLeaderboard）中，这些排行榜通常只报告模型单个样本的通过率，而忽略了比较模型的整个维度。虽然单个样本通过率的性能是聊天机器人等应用程序的主要相关性指标，因为用户通常对延迟很敏感，但当允许使用更多的推理时间时，这个单一标量不足以完全捕捉模型的质量。
　　在本文中，我们探索了在推理时提高 LLM 多样性的几个方向。我们假设要搜索的正确多样性坐标轴是自然语言的概念/思想空间，并通过多个实验验证了我们的假设。首先，我们表明，当输入正确的解决方案草图时，模型可以生成正确的最终程序，其中这些草图已从传递解决方案代码“反向翻译”为思想空间中的草图（第 3.2 节）。其次，我们表明，当要求模型在 LiveCodeBench（IDEASEARCH）上实现之前生成自己的想法时，它们在特定草图上的准确率趋向于 0% 或 100%，这表明通过特定问题的大部分差异是由草图是否正确而不是任何其他因素决定的。这两个实验提出了一种改进 LLM 代码生成搜索的自然方法：通过搜索要实现的正确想法。
　　在 maximizing exploration of ideas 的原则指导下，我们提出了 PLANSEARCH。与许多现有的搜索单个token、代码行甚至整个程序的搜索方法不同，PLANSEARCH 搜索解决当前问题的可能计划，其中计划被定义为有助于解决特定问题的高级观察和草图的集合（图 2）。为了生成新计划，PLANSEARCH 会生成大量有关问题的观察，然后将这些观察组合成解决问题的候选计划。在将代码最终全部转换为最终代码解决方案之前，对生成的观察的每个可能子集都执行此操作，以最大限度地鼓励在想法空间中进行探索（第 4.2 节）。我们发现，在推理时有效使用计算方面，搜索计划优于标准重复采样和直接搜索想法（IDEASEARCH，第 4.1.2 节介绍）。
　　在 Claude 3.5 Sonnet 上应用 PLANSEARCH 可在 LiveCodeBench 上实现 77.0% 的 pass@200 最高得分，优于未使用搜索时获得的最佳得分（pass@1 = 41.4%）和标准最佳 n 采样得分（pass@200 = 60.6%）。此外，与最近关于在小型模型上进行搜索的有效性的发现一致，基于小型模型 (GPT-4o-mini) 的 PLANSEARCH 仅在 4 次尝试后就胜过未使用搜索增强的大型模型。在另外两个编码基准 HumanEval+ 和 MBPP+ 上对 PLANSEARCH 的评估表明也有类似的改进。
　　最后，我们通过 LLM-asa-judge 程序（第 6.1 节）测量所有搜索方法在思想空间上的输出代码多样性，并表明由此产生的多样性得分与该搜索方法产生的性能提升高度相关。这进一步支持了我们的假设，即有效探索思想空间中的计划是 LLM 搜索代码生成的关键（图 6）。

2.相关工作

我们重申，本文中定义的搜索是指任何花费推理时间计算来提高性能的方法。我们进一步将planning定义为任何形式的高级观察或抽象思维，以协助模型生成最终解决方案。我们的工作建立在扩展搜索和规划方面的长期工作基础之上。

2.1 Search in Classical AI

广度优先搜索、深度优先搜索和 A* 搜索等经典搜索算法已广泛用于寻路、规划和优化。蒙特卡洛树搜索 (MCTS) 等更高级的搜索技术已在游戏等领域取得了显著成功，使Go、poker和Diplomacy的表现超越人类。最近，Jones发现了棋盘游戏中人工智能系统性能的扩展规律，其中 ELO 随着推理所花费的计算量呈对数级提升。

2.2 Search with Language Models

在 LLM 之上应用搜索一直是一个备受关注的话题，尤其是针对代码生成。从历史上看，诸如beam search之类的方法显著提高了翻译系统的性能。如今，最近的几项研究探索了重复采样作为一种提高性能的搜索方法。重复采样是一种在中高temperatures下多次直接从模型生成候选代码解决方案的方法，希望其中产生的一个生成是正确的。然而，虽然这些研究解决了 pass@k 相对于 log k 的大致线性增长问题，但它们只关注最基本的重复采样版本，而没有在思想空间中进行搜索。
　　当与verifier、reward模型或其他过滤算法相结合以选择最佳生成（在 pass@k 由于缺乏测试用例而成为可行指标的情况下），它也被称为 best-of-n 采样。许多工作在智能选择这种过滤算法的情况下显示出相当好的结果。最近，有几种方法展示了重复采样的强大功能。例如，在均衡的计算基础上，从小模型中重复采样有时可以优于从大模型中抽取单个样本。与重复采样等在输出空间中搜索的算法不同，PLANSEARCH 的关键见解是，在潜在想法空间中搜索计划要有效得多。通过在生成代码之前明确搜索不同的自然语言计划，我们显著增加了最终代码输出的多样性，从而增加了足够大 k 的 pass@k 分数。
　　关于用自然语言搜索计划，一些方法也提出了将思维链推理概括为类似搜索的过程，例如“思维树”和“通过规划进行推理”。然而，先前的方法在很大程度上证明了对旨在突出搜索能力的有些人为制造的问题的有效性，例如 24 游戏，或经典的规划基准，例如 Blocksworld，这两个基准都更容易通过明确考虑许多选项来解决，并且搜索的“步骤”相当明显。相比之下，大多数现实世界的规划用于协助足够复杂以受益于但不需要额外探索计划的领域。我们证明了用自然语言进行规划的 PLANSEARCH 在代码生成领域的表现优于基线搜索方法。此外，我们的分析揭示了这种搜索有效的根本原因：它增加了生成想法的多样性，与其他反复提交高度相似、不正确的解决方案的方法相比，可以更有效地进行搜索。

3.Motivation

代码是搜索应该擅长的一个强大领域。虽然其他领域的搜索既需要生成许多解决方案，也需要在所有生成的解决方案中选择正确的解决方案，但编码通常只需要前者，因为任何有效的代码都可以通过针对给定的测试用例执行代码来测试。这使得代码搜索算法可以避开许多困扰更开放领域（例如生成诗歌）的搜索算法的问题，这些开放领域很难在所有生成的解决方案中选择正确的解决方案。

3.1 Defining the Search Space

也许，要激发强大的搜索能力，最重要的问题就是确定在哪个空间进行搜索，因为找到合适的抽象层对于该领域的进步至关重要。之前的方法各不相同，许多人搜索单个token、代码行甚至整个程序。我们假设关键因素是获得正确的解决方案草图，我们将其定义为自然语言空间中正确程序的描述。直观地说，在自然语言空间中进行推理过程使我们能够有效地利用 LLM 的训练过程，LLM 在训练前后都观察到了许多人类推理的痕迹。先前的研究已经观察到，允许使用自然语言进行这种推理会产生强烈的积极影响，使其成为搜索的自然场所。我们描述了两个实验，通过在 LiveCodeBench 基准上使用 GPT-4o-mini 作为我们的模型进行测试来为这一假设提供证据。

3.2 Backtranslation

　　为了调查假设，即以解决方案草图的形式实例化的想法空间是否是正确的探索领域，一个自然的问题是 LLM 是否可以在给定正确草图的情况下正确实现正确的代码解决方案。受机器学习中反向翻译方法的启发，我们尝试将代码解决方案“反向翻译”回想法空间。首先，我们使用 GPT-4o 生成代码解决方案，以生成 1000 个解决问题的尝试并过滤掉没有任何通过解决方案的问题。由于我们也没有与每个解决方案相关联的正确解决方案草图数据集，因此我们通过反向翻译生成候选正确想法。我们通过将问题和代码解决方案提供给 LLM 并要求 LLM 将所述解决方案转换为解决方案的自然语言描述来实现这一点。此外，我们通过对 LLM 的提示（例如“in w words”）来改变反向翻译想法的细节。提示的完整描述可以在附录 J.1 中找到，以及几个不同长度的反向翻译解决方案示例。
　　我们观察到，用反向翻译的想法提示模型可以显著提高准确率，并且准确率会随着翻译想法的长度而增加（图 4a），这表明，即使只生成 10 个token的反向翻译解决方案，拥有正确的草图也足以以相对较高的准确率产生正确的最终解决方案。这表明，正确的搜索方向是探索想法空间，以最大限度地提高得出正确想法的机会。

3.3 Conditioning on Idea Quality

在后续实验中，我们提示 LLM 生成自己的草图来解决 LiveCodeBench 问题，而不是通过反向翻译为其提供标准草图。首先，我们使用第 4.1.2 节中定义的 IDEASEARCH 为每个问题生成 5 个想法。然后，对于每个想法，我们抽取 25 个候选解决方案并测量它们的通过率。对于这个实验，我们过滤掉 GPT-4o-mini 解决率为 100% 或 0% 的任何问题，因为这些问题对于模型来说要么太简单要么太难，对这个实验没有帮助。我们最终得到了 75 个问题和 375 个草图。
　　为了验证我们的假设，即生成正确的草图是解决问题的关键因素，我们将基于给定草图生成正确代码解决方案的解决率分布与给定随机绘制的草图的解决率分布（即仅解决率分布）进行了比较。
　　正式来说，对于任何问题 $Pi$，我们从概率质量为 $P(I|P_i)$ 的某个条件分布中抽取一些草图 $I$。解决 $P_i$ 的概率为 $P(solve|P_i,I)$。我们将所有问题和所有草图的求解率分布 $P(solve|P_i,I)$ 与所有问题的求解率分布 ${\sum }_{I}P(solve|P_i,I)\cdot P(I|Pi)=P(solve|P_i)$ 进行比较。
　　虽然在没有外部标签的情况下很难验证草图的正确性，但一个关键的见解是，如果产生正确的想法是解决问题的关键因素，那么对特定草图的条件化应该会使解决率的分布向 {0, 1} 极化。如果给模型一个正确的草图，它应该始终生成正确的解决方案，而如果给模型一个糟糕的草图，它应该始终生成不正确的解决方案。
　　我们的结果证实了这一点。图 4b 显示了各个问题的解决率分布，既无条件的（红色），和基于每个草图为条件的（蓝色）。我们注意到，当按草图分组时，解决率确实会向 {0, 1} 极化。这一结果对于改进代码生成具有重要意义，表明性能差异的很大一部分可能来自模型是否能够生成正确的想法。因此，改进的自然途径是专注于草图生成步骤，并在生成解决方案代码之前在想法空间中搜索正确的草图和观察结果。

4.Methods

我们描述了我们在工作中探索的各种搜索方法。如果需要有关较难编程和相关符号的更多背景信息，我们在附录 K 中提供了更多（可选）信息。

4.1 Baselines

4.1.1 REPEATED SAMPLING

我们将基本提示方法视为基准，其中我们使用few-shot提示，在要求 LLM 解决所需问题之前为其提供一些问题解决方案对。附录 J.2 中给出了提示的完整示例。在代码生成中，最常用的搜索变体是重复采样，其中模型被重复采样，直到它们生成通过测试的输出或达到最大样本数。有关更多信息，请参阅相关工作（第 2.2 节）。

4.1.2 IDEASEARCH

4.1.1 节中讨论的重复采样方法的自然延伸是避免立即提示 LLM 解决方案代码。这可以看作是常用的“思维链”提示在编程问题中的应用，尽管我们发现 IdeaSearch 比标准的“思维链”提示显示出不可忽略的性能提升（参见附录 E）。
　　在 IDEASEARCH 中，LLM 被赋予问题 $P$，并被要求输出该问题的自然语言解决方案 $S$。然后，LLM 的一个单独实例被赋予 $P$ 和 $S$，并被要求按照提出的解决方案 $S$ 来解决问题 $P$。IDEASEARCH 的目的是找出解决问题的正确“想法/草图”的有效性。从经验上讲，我们发现明确强制搜索算法阐明解决问题的想法会增加多样性。有关详细提示，请参阅附录 J.3。

4.2 PLANSEARCH

虽然重复采样和 IDEASEARCH 都取得了成功并导致基准测试结果的改善，但我们观察到，在许多情况下，多次提示（pass@k）（即使在高temperatures下）只会导致输出代码发生微小、狭窄的变化，这些变化只会改变次要方面，但无法改善想法中的缺陷。

4.2.1 Prompting for Observations

从问题陈述 $P$ 开始，我们提示 LLM 对问题进行“观察”/提示。我们将这些观察表示为 $O_i^1$，其中 i ∈ { 1 , . . . , n 1 } i ∈ \{1, . . . , n_1\} i∈{1,...,n1​}，因为它们是一阶观察。通常，$n_1$ 的数量级为 3 到 6。确切的数字取决于 LLM 输出。为了利用这些观察来启发未来的想法，我们创建了 S 1 = { O 1 1 , . . . , O n 1 1 } S^1 =\{O^1_1, . . . ,O^1_{n_1}\} S1={O11​,...,On1​1​} 中所有大小最多为 2 的子集。这些子集中的每一个都是观察的组合，为了清楚起见，我们将每个子集表示为 C i 1 ， i ∈ { 1 , . . . , l 1 } C^1_i，i ∈ \{1, . . . , l_1\} Ci1​，i∈{1,...,l1​}，其中 $l_1=1+n_1+\left(\genfrac{}{}{0ex}{}{n_1}{2}\right)$。

4.2.2 Deriving New Observations

因此，所有观测值的集合可以定义为深度为 1 的有向树，其中根节点为 $P$，每个 $C_i^1$ 都有一条边从 $P$ 指向 $C_i^1$。然后，我们在每个叶节点 $C_i^1$ 上重复第 4.2.1 节中的此过程，以生成一组二阶观测值， S i 2 = { O i , 1 2 , . . . , O i , n i , 2 2 } S^2_i = \{O^2_{i,1}, . . . ,O^2_{i,n_{i,2}}\} Si2​={Oi,12​,...,Oi,ni,2​2​}。为了获得二阶观测值，我们用原始问题 $P$ 和 $C_i^1$ 中包含的所有观测值提示模型，这些观测值被构造为解决 $P$ 所必需的原始观测值。然后提示 LLM 使用/合并在 $C_i^1$ 中找到的观测值以得出新的观测值。
　　使用与第 4.2.1 节相同的过程来创建所有子集 $C_{i,j}^2$，其中 i ∈ { 1 , . . . , l 1 } i ∈ \{1, . . . , l_1\} i∈{1,...,l1​}。此过程可以任意重复，但出于计算限制，我们在深度 2 处截断树。
　　请注意，我们并不假设生成的任何观察结果都是正确的。事实上，必须注意的是，其中许多观察结果可能不正确。这些观察结果只是为了引导模型搜索更加多样化的想法。

4.2.3 Observations to Code

在做出观察之后，必须先将其作为想法付诸实施，然后再将其转化为代码。对于每个叶节点，我们用所有观察结果以及原始问题 $P$ 提示模型，以便生成问题 $P$ 的自然语言解决方案。为了增加多样性，对于每个生成的想法，我们都会假设该想法是错误的，并要求 LLM 给出批评/反馈，从而将我们提出的想法增加 2 倍。
　　然后将这些自然语言解决方案翻译成伪代码，随后将其翻译成实际的 Python 代码。我们采用更细致的方法来减少翻译错误（这可能会导致模型恢复到其原始模式，而忽略经过推理的观察结果）。我们在附录 J.4 中提供了所有章节的所有提示。

5.Experimental Results

J. Prompts

J.1 Backtranslation

J.1.1 Backtranslate System Prompt

You are an expert Python programmer. You will be given an algorithmic question (problem specification). You will return a high-level, natural language solution to the question, like an editorial. You will NOT return any code. Be as creative as possible, going beyond what you think is intuitively correct.

J.1.2 Implement Backtranslation Idea

You are an expert Python programmer. You will be given a question (problem specification) and a natural language solution/tutorial that describes how to solve the problem. You will generate a correct Python program that matches said specification and tutorial and passes all tests. You will NOT return anything except for the program inside markdown codeblocks.

J.2 Repeated Sampling

You are an expert Python programmer. You will be given a question (problem specification) and will generate a correct Python program that matches the specification and passes all tests. You will NOT return anything except for the program inside Markdown codeblocks.

J.3 Simple Idea

You will given a competitive programming problem; please output a high-level description of how to solve the problem in natural language. Below are examples:

Example input: PROBLEM DESCRIPTION HERE
Example output: EXAMPLE OUTPUT HERE
Here is the competitive programming problem: PROBLEM TO SOLVE

Brainstorm a high-level, natural language solution to the problem above. Note that your intuition may lead you astray, so come up with simple, creative ideas that go beyond what you would usually come up with and go beyond your narrow intuition. Brainstorming solutions that do not seem intuitively correct IS CRUCIAL.

J.4 PLANSEARCH

J.4.1 Prompt for Observation Part 1

You are an expert Python programmer. You will be given an competitive programming question (problem specification). You will return several useful, non-obvious, and correct observations about the problem, like hints to solve the problem. You will NOT return any code. Be as creative as possible, going beyond what you think is intuitively correct.

J.4.2 Prompt for Observation Part 2

You are an expert Python programmer. You will be given an competitive programming question (problem specification) and several correct observations about the problem. You will brainstorm several new, useful, and correct observations about the problem, derived from the given observations. You will NOT return any code. Be as creative as possible, going beyond what you think is intuitively correct.

J.4.3 Combining Observations

Here is a sample prompt from the function with placeholders:

Here is the competitive programming problem:

Problem statement placeholder

Here are the intelligent observations to help solve the problem:

Observation 1 placeholder
Observation 2 placeholder
Observation 3 placeholder

Use these observations above to brainstorm a natural language solution to the problem above. Note that your intuition may lead you astray, so come up with simple, creative ideas that go beyond what you would usually come up with and exceeds your narrow intuition. Quote relevant parts of the observations EXACTLY before each step of the solution. QUOTING IS CRUCIAL.

J.5 Measuring Diversity

You are an expert Python programmer. You will be given a competitive programming problem and two pieces of code which are attempts to solve the problem. For your convenience, you will also be given the idea for each code, summarized in natural language. You will be asked to answer whether the ideas behind the code are the same. You must ONLY output ’Yes.’ or ’No.’