Beyond Code Pairs: Dialogue-Based Data Generation for LLM Code Translation
本文介绍了一种自动化的、基于对话的数据集生成流水线，该流水线利用具有编译器和运行时反馈的双 LLM“提问者-求解者”设计，来创建经过验证的代码翻译和推理对话，从而显著增强了大型语言模型在 Fortran 和 CUDA 等低资源领域的函数正确性。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正试图教导一位才华横溢但缺乏经验的学徒，如何将一份复杂的食谱从一种古老、晦涩的语言（如 Fortran）翻译成现代语言（如 C++ 或 CUDA）。
问题：“黑盒”式翻译
传统上，当我们教 AI 进行代码翻译时，我们会将“源代码”与“目标代码”并排展示给它。这就像是给学徒一份食材清单和最终做出的菜肴，却从未让他们看到烹饪的过程。他们可能会猜对菜肴，但如果出了错，他们不知道为什么或者如何去修复。他们只是产生了一个看起来正确、但在实际尝试食用（运行代码）时可能会失败的结果。
解决方案：“提问者”与“求解者”
这篇论文介绍了一种新的训练 AI 的方法，称为 Beyond Code Pairs。他们没有仅仅展示起点和终点，而是创建了一个系统，记录了翻译过程中整个对话和挣扎的过程。
把这想象成一个有两个不同角色的厨房：
- 提问者（主厨的批评家）： 这个 AI 不负责编写代码。相反，它扮演着一位严厉的主厨角色。它观察当前的状态，检查是否存在错误（例如编译器错误或运行时崩溃），并提出具体的问题：“为什么这里崩溃了？”或者“你检查内存限制了吗？”它利用来自计算机的真实反馈来引导整个过程。
- 求解者（学徒）： 这个 AI 负责实际的编写工作。它尝试翻译代码，编写单元测试（类似于味觉测试），并尝试修复提问者指出的错误。
过程：是一场对话，而非独白
论文描述了一个流水线，其中这两个 AI 通过多轮对话进行交谈：
- 第 1 步： 提问者要求求解者为原始代码编写一个测试。
- 第 2 步： 求解者编写测试。提问者检查是否通过。如果不通过，他们会争论并不断完善，直到测试成功。
- 第 3 步： 提问者要求进行翻译。求解者编写新代码。
- 第 4 步： 提问者运行新代码。如果代码崩溃，提问者会说：“你忘记处理这个特定的错误了！”然后求解者会对进行修复。
- 第 5 步： 他们重复此过程，直到代码能够编译、运行并通过所有测试。
其神奇之处在于，研究人员保存了这场对话中的每一次回合。他们不仅保存了最终的代码；他们还保存了错误、问题、编译器错误信息以及修复方案。
结果：小模型，大胜利
研究人员使用这种方法生成了数千个关于 Fortran 到 C++ 以及 C++ 到 CUDA（一种用于图形卡的语言）翻译的“对话”。
当他们使用这些对话数据来训练较小的开源 AI 模型（例如 70 亿参数的模型）时，结果令人震惊：
- 功能正确性： 这些模型不仅写出了看起来正确的代码，而且写出了真正能运行的代码。在将 C++ 翻译为 CUDA 这一困难任务中，通过测试的成功率从 12.5% 大幅跃升至 68.8%。
- 击败巨头： 在让代码编译并运行而不崩溃的关键指标上，经过这种“对话”数据训练的小型开源模型，表现优于庞大且昂贵的闭源系统（如 Google 的 Gemini 或 Meta 的 Llama 4）。
核心启示
该论文认为，要教会 AI 执行复杂的任务（如代码翻译），你不应该只展示答案。你需要展示挣扎的过程、提出的问题以及进行的修正。通过在这些“对话”而非仅仅是静态的代码对上进行训练，即使是更小、更便宜的 AI 模型，也能学会如何通过错误进行推理，并产出高质量、功能完备的软件。
简而言之：不要只教 AI 答案，要教它如何思考、如何争论以及如何修复自己的错误。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。