Github2.5k星，Karpathy转赞，「流程工程」让LLM代码能力瞬间翻倍，直接淘汰提示工程

---

  新智元报道  

代码生成可以说是大模型应用中效果最好，使用人群最广的一项任务了。

但是由于编程语言众多，要应对各种不同的边缘场景，代码生成任务又是对模型能力要求最高的任务，一般的自然语言提示，甚至是CoT等方法，对于代码生成任务来说，效果也不是很好。

但是最近在GitHub上有一个项目大火，它通过一系列针对大模型代码生成任务的优化，将提示词工程升级为一个更加复杂的「流程工程」，能够大幅提升模型输出的代码质量。

项目地址：https://github.com/Codium-ai/AlphaCodium

就连AK看了，都很兴奋地转发，认为如果代码生成任务能够以更科学的流程，而不是简单的问答方式来和大语言模型互动的话，性能确实还有不少提升的空间。

作者把这个项目称为AlphaCodium ，一种基于测试的、多阶段、面向代码的迭代流程。

他们在由谷歌DeepMind提出的一个非常有难度的代码测试集CodeContests上进行测试，将GPT-4的成绩从19%提高到了44%。

由于CodeContests代码生成问题的复杂性，简单的提示优化，甚至CoT提示，无法获得有意义的性能提高。

最主要是因为就算强如GPT-4，也难以理解和「消化」问题，会不断产生错误的代码。

适用于自然语言任务的通用流程可能不适用于像CodeContests上这种有难度代码生成任务。

这个数据集包含约一万个可用于训练LLM的问题，以及用于评估LLM解决具有挑战性的代码生成问题的能力的验证和测试集。

作者没有训练专用模型，而是开发了一个面向代码的流程，这个流程可以应用于任何能够用于编码任务的预训练的LLM，例如GPT或DeepSeek。

下图展示了一个 CodeContests 数据集中的典型问题示例：

为什么CodeContests是一个评估代码生成任务的LLM的优秀数据集？

主要原因是：

1）CodeContests与许多其他竞争性编程数据集不同，它利用一套全面的不公开的测试来避免错误检测——每个问题包含约200个生成的代码解决方案，输出和输入都要通过这个测试。

2）LLM通常不擅长关注小细节，因为他们通常会将问题描述转换为某种「平均」描述，接近于模型接受训练时的常见案例。

另一方面，现实世界的问题经常包含正确解决问题内容中至关重要的小细节。

CodeContests 数据集的一个关键特征是，问题描述在设计上是复杂而冗长的，并且存在一些小细节和细微差别（参见上图中的典型问题描述）。

作者认为增加这种问题理解的自由度是有益的，因为它能真实模拟现实生活中的问题，这些问题通常很复杂，涉及多种因素和考虑因素。

这与更常见的代码数据集（例如 HumanEval）形成对比。

作者认为适当的自我反思会使问题更加清晰、更加连贯。这说明了问题理解作为流程的一部分的重要性，它很可能导致正确的代码解决方案。

为了应对这种和现实问题很接近的测试集，作者提出了这样一个流程：

该流程主要是一个迭代过程，作者根据输入输出测试反复运行和修正生成的代码。

这种以代码为导向的流程有两个关键要素：

• 预处理阶段是一个线性流程，用自然语言对问题进行推理。在预处理阶段生成额外的数据，如自我反省和公共测试推理，以帮助迭代过程；
  
  
• 代码迭代阶段包括根据特定测试生成、运行和修复代码的迭代阶段。这个阶段使用人工智能生成的额外测试来丰富公共测试。

AlphaCodium 流程广泛使用了以下设计概念：

YAML 结构化输出

结构化输出的使用——要求模型生成 YAML 格式的输出，相当于给定的 Pydantic 类——是我们提出的流程中的关键组件。此类指令的示例：

...Your goal is to present possible solutions to the problem.Make sure that each solution fully addresses the problem goals, rules, and constraints.

The output must be a YAML object equivalent to type $PossibleSolutions, according to the following Pydantic definitions:
class Solution(BaseModel):  name: str = Field(description="The name of the solution")  content: str = Field(description="A description of the solution")  why_it_works: str = Field(description="Why this solution is correct. Be specific and detailed regarding the problem rules and goals")  complexity: str = Field(description="The complexity of the solution")
class PossibleSolutions(BaseModel):  possible_solutions: List[Solution] = Field(max_items=3, description="A list of possible solutions to the problem. Make sure each solution fully addresses the problem rules and goals, and has a reasonable runtime - less than three seconds on a modern computer, given the problem constraints for large inputs.")

要点分析

当要求 LLM 推理问题时，要求输出采用要点格式通常会获得更好的结果。

LLM在生成模块化代码时做得更好

当要求 LLM生成单个冗长函数时，结果往往很差 - 代码通常包含错误或逻辑错误。

具有双重验证的软决策

LLM往往会在需要思考、推理并做出严格、重要决策的代码任务中遇到困难。

推迟决策，尽量避免直接提问，并留出探索的空间

向模型提出有关复杂问题的直接问题时，我们总是会看到幻觉和错误答案。

测试锚点

即使经过双重验证，一些人工智能生成的测试也会是错误的。

直接使用提示词 Vs AlphaCodium