函数级执行反馈驱动的代码偏好优化
研究者提出 STEP-KTODER，将代码生成中的"步骤"定义为多函数程序的模块级函数，通过自动单元测试给出正确性标签，…
在代码生成任务中，如何对大模型的推理过程进行监督，一直是研究者关注的难题。数学推理中的过程监督方法（如逐步 KTO）已取得显著进展，但代码生成缺乏天然的"步骤"定义——监督可以针对行、推理轨迹或程序状态，难以统一。arXiv 上的一项新工作提出了 STEP-KTODER 框架，把"步骤"定义为多函数程序中的模块级函数，并通过自动生成的单元测试给出二元正确性标签，为代码场景下的过程监督提供了具体的实例化方案。
框架思路：从行级监督转向函数级监督
STEP-KTODER 的核心是把代码偏好优化（preference optimization）与可执行的程序语义结合：
- 把待生成的代码视为由若干模块级函数组成的多函数程序；
- 对每个函数单独运行自动生成的单元测试，得到二元的正确/错误标签；
- 在此基础上，将"函数级过程监督"与"完整程序的输出级反馈"叠加，相当于在代码领域复现逐步 KTO（stepwise KTO）的训练信号。
这一思路绕开了"一行代码难以独立评测"的困难，让过程奖励在代码任务上变得可操作。
实验设置与结果
研究者在四类主流代码基准上评估 STEP-KTODER：
- HumanEval（及 HumanEval+）；
- MBPP（及 MBPP+）；
- BigCodeBench；
- LiveCodeBench。
对比基线为仅使用结果级反馈的 KTO 与 DPO。摘要报告，STEP-KTODER 在上述基准上均稳定优于这两类仅依赖最终正确性的偏好优化方法，说明执行反馈带来的过程信号在代码偏好学习中具有增量价值。
关键发现：LLM-as-a-judge 会系统性过判失败
论文的另一项值得关注的结论是关于评测方式的消融：
- 用 LLM-as-a-judge 来给函数级步骤打标时，模型会系统性高估失败率；
- 这种"过判"会污染正向步骤标签；
- 受污染的标签被用于偏好优化训练后，会损害下游效果。
也就是说，对于代码执行类任务，运行真实的单元测试比让大模型充当裁判更可靠。这一观察为"以 LLM 评分代替可执行验证"的常见做法敲响了警钟，也支持了 STEP-KTODER 选择自动单元测试而非 LLM 打分的设计取舍。
开源与适用场景
作者已将代码开源（github.com/inechnech/STEP-KTODER），便于复现并迁移到其他多函数代码任务。对于希望在不依赖昂贵人工标注的情况下，把过程监督引入代码大模型微调的研究者与工程师，该框架提供了一个相对轻量、可执行的参考路径。