Question

1. 在本节中，我们提出并研究了一种multi-step program synthesis 范式，其中 program synthesis 被分解成多步，系统在每个步骤中合成一个子程序。为了研究这种范式，我们首先开发了一个Multi-Turn Programming Benchmark: MTPB 。MTPB 包括 115 个由专家编写的问题，每个问题都包括一个自然语言的 multi-step description（即，prompt ）。为了解决一个问题，一个模型需要合成功能上正确的子程序：遵循当前步骤的 description 、考虑当前的 description 以及前面步骤已经合成的子程序（例如，对前面步骤中定义的函数和/或变量的正确 back-reference ）。下图给出了一个例子。

   

2. benchmark 构建：我们（ 4 位作者）首先定义了一组 115 个需要不同编程知识的问题，包括数学、数组操作、字符串操作、算法、数据科学以及需要其他知识的问题，使得每一类问题的数量大致平衡。对于每个问题，我们构建一个由 multi-turn prompts$P$$ P $ 、测试用例输入$I$$ I $ 、测试用例输出$O$$ O $ 组成的 triplet 。

   • multi-turn prompts$P$$ P $ 的设计遵循两个约束条件：问题被分解成 3 个或更多的 turns 、单个 turn 无法解决该问题。

     例如，实现一个线性回归模型可以被表述为 "Perform linear regression on x and y" 。由于 main task 在这个 prompt 中得到了充分的表达，所以理解这个 prompt 就足以执行这个任务。我们通过人工检查来避免这种情况，使得多个 turn 才能解决问题。

   • 与 prompt 一起，我们要求问题作者准备 5 组测试用例的输入$I$$ I $ 和输出$O$$ O $ ，以评估模型输出的功能正确性。为了减少错误地奖励那些给出无意义程序、但通过测试的 false positive 方案，我们检查并修改这些案例以确保测试质量。

   在HumanEval 中，模型要补全一个部分定义的函数。 与HumanEval 不同的是，MTPB 问题只提供 prompt ，因此模型必须从头开始生成解决方案。虽然自由形式的生成可能允许更多潜在的解决方案，但缺乏一个入口来提供测试用例的输入，因此使得在不同的测试用例上测试生成的代码具有挑战性（因为自由生成的情况下，函数签名可能都不是固定的，因此难以提供测试接口）。为了克服这一挑战，我们在 prompt 中嵌入了测试用例的输入。具体而言，prompt 是用 Python 的格式化字符串编写的，当一个特定的测试用例应用于问题时，输入值会被替换成变量名。例如，一个 prompt ，"Define a string named ’s’ with the value {var}." ，连同测试用例输入 var = 'Hello' 将被格式化为 "Define a string named ‘s’ with the value 'Hello'."。参考 Figure1 的①。

   这里将测试用例的输入嵌入到 prompt 中，而不是作为函数接口来调用。

   问题：

   

   

3. 执行环境和解决方案评估：对于执行，prompt 和生成的 completion 组成的 pair ，会被拼接起来从而构成一个独立的程序（如 Figure 1 中的③）。然后遵从 single-turn HumanEval benchmark 在一个孤立的 Python 环境中执行该程序。然而，HumanEval 中的问题中，函数签名是已知的，因此在一组功能性的单元测试下调用生成的代码是很简单的。在我们的multi-turn case 中，无法保证生成这样的入口点（或返回值）。为了避免 missing return signature ，MTPB 中 multi-turn problem 的最后一个 prompt 总是被指定为向终端打印出结果状态。然后，benchmark 执行环境重载了 Python print(args) 函数，并将 args 存储在栈上。

   如果一个问题的最后一个prompt 的 sampled code 不包括 print()语句 ，那么生成的代码的 AST 将被突变以注入 print() 的调用。最后，针对问题的 pre-defined gold output ，对 args 进行类型放松的等价检查（例如，list 和 tuple 之间的隐式转换），以确定测试的失败或成功。

4. multi-step 编程能力随模型大小和数据大小的变化而变化：在这个分析中，我们研究了模型大小和数据大小是如何影响 multi-turn 范式下 program synthesis 能力的。在 MTPB 中，每个问题有 5 个测试案例，我们用每个模型为每个测试案例采样 40 个样本，在此基础上计算每个问题的通过率。我们的 CODEGEN 模型、baseline 和 OpenAI Codex 模型的 MTPB 评估结果（平均通过率）如下表所示。

   很明显，MTPB 的性能随着模型大小和数据大小的变化而提高。这表明，multi-step program synthesis 的能力随着模型大小和数据大小的变化而扩大。这些模型只是用 autoregressive language modeling objective 进行训练。当模型和数据规模 scale up 时，multi-turn program synthesis 的能力就涌现了，也就是以 multi-turn 方式合成程序的能力。

   

5. 用 multi-trun factorization 更好地理解用户规范：我们假设， multi-trun factorization 增强了模型对用户意图规范的理解，这反过来又导致了更高的 program synthesis 能力。为了测试这个假设，我们通过将每个规范拼接成 single turn ，形成 multi-turn specification 对应的 single-turn 版本。如前所示，我们采用 prompt perplexity 作为用户意图理解的代理。因此，我们比较了四种 CODEGEN-MONO 模型下的 multi-turn prompt 和 concatenated single-turn prompt 的困惑度。

   这里比较了相同的 prompt 对应于 multi-turn 和 single-turn 之间的效果差异：

   • 对于 multi-turn，直接使用原始的多个 prompt。

   • 对于 single-turn，将多个 prompt 拼接起来形成单个长的 prompt 。

   下表的左侧显示了 MTPB 中所有问题的平均困惑度。对于所有的模型，single-turn specification 比 multi-turn specification 的平均困惑度高。这意味着 multi-turn用户规范可以被模型更好地理解。我们注意到，在较大的模型下，multi-turn 和single-turn 的意图规范的平均困惑度都略低于较小的模型，这说明较大的模型比小的模型更能理解用户意图。

   我们比较了使用 multi-turn prompt 的 program synthesis 通过率、以及使用 concatenated single-turn prompt 的 program synthesis 通过率。结果显示如下表右侧所示。在所有的模型规模中，multi-turn specification 都接近或超过了 single-turn specification 的 10 个百分点。结合上面的困惑度分析，似乎将用户规范分解成多个步骤，并利用大型语言模型的涌现能力emerged capacity ，使他们更容易理解规范，更成功地合成程序。

   

   此外，我们根据问题的平均通过率按难度分类（低于 30% 表示"难"，大于 70% 表示 "易"），并研究问题难度和模型大小对 multi-turn factorization 的改进的影响。如 Figure2所示。

   在几乎所有的模型大小和难度级别中，multi-turn prompt 都会比single-turn prompt 带来明显的改善，而且大多数改善接近或高于 10 个百分点。有趣的是，更大的模型(6.1B and 16.1B )对容易的问题的 multi-turn factorization 是不变的（见 Figure 2 中的两个短条，0.19% 和 -0.25% )。这意味着，当问题可以很容易地被模型理解时（由于问题的简单性和较大模型的高容量的综合影响），对规范进行分解是没有必要的，也没有收益的。这实际上与我们的动机假设是一致的，即把 complicated specification 进行分解，会使问题容易理解并改善 program synthesis 。

   

6. 定性的例子：为了进一步了解模型行为在模型规模上的差异，我们研究了大型模型与小型模型具有不同性能的案例。我们特别选择了CODEGEN-MONO 16.1B 和 CODEGEN-MONO 2.7B 在性能上表现出明显差异的问题。在 CODEGEN-MONO 16.1B 表现明显较差的问题上（与 CODEGEN-MONO 2.7B 相比），我们观察到，由于按字面意思理解 prompt ，更大的模型变得不灵活。例如：

   • 初始化一个数字的结果总是一个整型，prompt 提示要求 cast 成一个字符串（Figure 3 ）。

     

   • prompt 中的 "return" 关键字触发了一个函数定义，而其用户意图是直接生成一个可执行程序（Figure 4 ）。

     

   然而一般来说，较大规模的模型克服了由于小模型对 prompt 的误解而导致的错误，包括同时赋值多个变量（Figure 5 ）或理解任何 comparison 的概念（Figure 6 ）。

   

   

7. 我们还在 Mostly Basic Python Problems: MBPP 上评估了我们的模型。结果如下表所示。遵从 Codet 的做法，我们从 sanitized MBPP 中为我们所有的模型采样 program ，$n=100$$ n=100 $ ，温度为 0.8 。最后四行来自于原始论文。

   总的来说，我们观察到在不同的版本（NL, Multi, Mono ）上性能提高的一致趋势，我们最大的 CODEGEN-MONO 16.1B 接近于code-cushman-001 的结果。

   我们不知道 OpenAI 模型中是否是 《Evaluating large language models trained on code》报告的 "Codex 12B" ，但我们相信我们的模型在 MBPP 上也取得了合理的结果。我们还注意到，我们的 CODEGEN-MONO 6.1B 的表现明显优于 INCODER 6B 。

   

8. 生成的程序长度和通过率的关系：

   

   

   

9. 生成的程序长度和 prompt 长度之间的关系：