LLM如何才能有助于调试代码？

译者 | 布加迪

审校 | 重楼

大语言模型（LLM）正在改变软件开发生命周期，其在代码理解、代码生成、调试等方面发挥着功效。本文深入探讨如何利用LLM调试代码库，详述了其核心功能、用于训练的方法以及应用未来进一步发展的方向。尽管LLM存在幻觉等一些问题，但事实证明，通过复杂的智能体调试框架将LLM集成到开发环境中可以提高开发人员的效率。

引言

LLM在编码领域不断演变的角色

LLM已证明不仅可以应用于自然语言处理领域，在各种与代码相关的任务（包括代码生成和翻译）中也取得了卓越的性能。它们为GitHub Copilot和Cursor等AI编码助手提供支持，并在HumanEval和MBPP等标准基准测试中展现出媲美人类的性能。

LLM可以根据文本描述生成完整的代码片段、完成函数并提供实时语法建议，从而简化代码创建的初始阶段。然而，其应用显然可以扩大到软件开发生命周期中更复杂、更迭代的过程。

代码调试的重要性

调试是软件开发中一个耗时却又至关重要的部分，涉及错误识别、定位和修复。这些错误涵盖从简单的语法错误到复杂的逻辑缺陷等各类错误。传统的调试方法通常具有挑战性，尤其是对于初级程序员来说，他们可能难以应对晦涩难懂的编译器消息和复杂的代码库。调试过程的效率直接影响开发进度和软件质量，因此需要更先进、更直观的工具。

LLM的核心功能

代码理解与分析

除了针对海量代码语料库进行广泛的预训练以理解自然语言外，LLM 还专门使用大型编码数据库进行训练，以识别常见的编程模式并推断代码段的预期含义。这项基础功能使它们能够分析代码中的语法错误和逻辑不一致之处。

错误定位与识别

LLM在调试中的一项主要应用是能够协助识别和定位错误。基于LLM的调试迎来了最新进展，不仅限于行级错误识别。较新的方法可以更精细地预测错误位置，其精细度从行级延伸到token级。我们可以采用各种技术来识别错误并修复错误。这可以通过利用CodeT5等编码器LLM来实现，它们可以更精确地定位有问题的代码段。

代码修复

最近，LLM智能体还可以直接提出代码修改建议。它们可以采用迭代过程来改进和修复源代码。

人们对自我修复技术的兴趣也日益浓厚：LLM运行其生成的代码，观察结果，然后根据错误原因进行调整。这整个过程有助于提高最终代码的可靠性和质量。这种自我修正机制模仿了人工调试的某些方面，即开发人员测试、观察错误，然后修改代码。

比如说，开发人员可能会这样提示LLM修复错误：

Python

# User Prompt:
# "The following Python function should calculate the factorial of a number,
# but it's returning an incorrect result for inputs greater than 0.
# Can you identify the bug and fix it?"

def factorial(n):
if n == 0:
return 1
else:
return n * factorial(n) # Bug is here - infinite recursion!

# --- LLM's Suggested Fix ---
def factorial(n):
if n == 0:
return 1
else:
return n * factorial(n - 1)

针对代码库和问答论坛的检索增强生成（RAG）

LLM可以对内部代码库和问答论坛（内部和外部）执行高效的检索增强生成（RAG），并提供相关且简洁的摘要，这对调试过程大有帮助。这需要理解本地更改的构建或运行时错误、设计和访问模式方面的问题，或即时执行RAG以了解并提供概述和相关提示。LLM可以将其与对代码库的理解相结合，从而为进一步调试和可能的修复提供提示。

这预示着未来调试技术的进步将不仅依赖更出色的面向代码的模型，还依赖将自然语言理解与代码推理相结合的创新方法，使LLM能够以一种更概念化、更类似人的方式解释和解决编码问题。

用于调试的测试用例生成

LLM可以通过强大的测试用例生成功能为高效的调试机制提供支持。它们可以创建具有多样化测试输入的单元测试用例，这对于有效检测错误至关重要。一些AI编程工具体现了这种能力，允许开发人员通过提供自然语言提示来生成结构良好的测试用例。

Python

// User Prompt:
// "Generate a JUnit test case for the following 'Calculator.add' method.
// Include a test for positive numbers, negative numbers, and zero."
class Calculator:
    def add(self, a, b):
        return a + b

// LLM-Generated Test Case:
import unittest

class TestCalculator(unittest.TestCase):

    def test_add_positive_numbers(self):
        calculator = Calculator()
        self.assertEqual(5, calculator.add(2, 3), "Adding two positive numbers")

    def test_add_negative_numbers(self):
        calculator = Calculator()
        self.assertEqual(-5, calculator.add(-2, -3), "Adding two negative numbers")

    def test_add_with_zero(self):
        calculator = Calculator()
        self.assertEqual(2, calculator.add(2, 0), "Adding a number to zero")

if __name__ == '__main__':
    unittest.main()

构建调试能力的方法

数据完善和监督式微调

使用所需语言的高质量调试数据集进行领域特定训练，对于增强LLM，使其能够有效调试并实现最佳性能是一个非常重要的环节。

监督式微调（SFT） 需要在公共和内部代码库上运行，以了解设计、构建和测试模式。研究表明，与较小的模型（比如70亿参数的模型）相比，较大的LLM、尤其是参数超过700亿的模型表现出非凡的调试能力和卓越的错误修复准确性。

自然语言作为中间表示（NL-DEBUGGING）

NL-DEBUGGING框架通过引入自然语言作为代码调试的中间表示，俨然是一大进步。这种方法将代码转换成自然语言理解，便于更深层次的语义推理并指导调试过程。这使得LLM能够提出多种调试策略和解决方案。常用的自然语言表示包括草图、伪代码和关键思维点。

高级提示工程策略

提示设计是有效调整LLM以执行错误修复任务的关键因素。提供全面的上下文（比如原始源代码）可以显著提高LLM生成的错误解释的质量和准确性。

可以采用各种提示工程策略来优化性能，包括一次性提示、为LLM分配特定角色（比如指示其“像一位非常资深的Python开发人员一样行事”）以及将复杂任务分解成更小、更易于管理的子任务。进行负面提示也可能有效，明确表述期望输出不应包含的内容。

多 LLM 和智能体调试流程

为了克服单一LLM的固有局限性，并超越通常无法应对复杂调试场景的简单的“提示输入，代码输出”模型，研究人员正在开发多LLM和智能体调试框架。不同的LLM有不同的角色，比如“代码学习者”和“代码教师”，它们集成编译器反馈，以提高错误识别和修复的准确性。

比如说，使用Claude进行代码检索，使用GPT-4进行深度分析。此外，当LLM旨在校正或调试自身输出时，可以采用迭代式改进。

局限与挑战

浅层代码理解和语义敏感性

当今大语言模型在调试方面的一个关键局限性是，它们通常缺乏对代码实际工作方式的深入理解。其理解能力严重依赖词汇和句法特征，而非对程序逻辑的语义理解。

研究表明，进行一些细小的非语义更改（比如删除死代码、更新注释/变量命名等）时，LLM可能会失去在相当一部分（比如78%）的错误程序中调试相同错误的能力。LLM还可能难以丢弃不相关的信息，将死代码视为对程序的语义有积极贡献的代码，这可能导致在错误定位过程中出现误诊断。

复杂和逻辑错误方面的性能

虽然LLM大有前景，但整体调试性能仍然不如人类。分析表明，某些类别的错误对于LLM来说仍然极具挑战性——具体来说，与更简单的语法和引用错误相比，逻辑错误和涉及多个相互关联问题的错误对于LLM理解/调试起来要困难得多。

上下文窗口约束和可扩展性问题

现代软件存储库通常很庞大，涵盖成千上万个token。在这样的环境中进行有效的调试需要LLM全面处理和理解整个代码库。尽管最近的技术进步使得传递大型上下文成为可能，但LLM仍难以在极端上下文规模下保持可靠的性能。据观察，随着上下文长度的增加，性能会下降，这限制了它们完全理解和调试大型多文件项目的能力。

幻觉和输出不一致的问题

LLM的一个关键漏洞是很容易产生“幻觉”——听起来似乎合理但实际上不正确或完全捏造的内容。这通常意味着开发人员需要反复检查，有时甚至需要花另外的时间去调试AI建议的代码或修复方案。幻觉可能源于多个途径，包括编写不当的提示、馈送给模型的上下文信息不清晰，或使用过时的模型版本。

测试覆盖问题

虽然开发人员可以生成可执行且多样化的测试用例，但他们常常难以掌握测试中更具战略性和逻辑性的方面：识别需要覆盖哪些特定的语句、分支或执行路径。这种限制对于调试至关重要，因为有效的调试通常依赖精心设计的测试用例，这些测试用例可以隔离并暴露特定的问题代码路径。

“调试衰减”现象

研究表明，AI调试的有效性遵循指数衰减模式。经过几次迭代后，LLM发现错误的能力会显著下降（下降60%-80%），这使得连续的、无指导的迭代计算开销大、效率低。这表明，需要人工干预来重置和指导调试过程，而不是依赖长时间的独立AI迭代。

结论

LLM 将通过提高效率和开发人员生产力来彻底改变代码调试。它们能够理解代码、定位错误、提出修复建议并生成测试用例，这标志着相对传统方法有了重大进步。

未来在于这样一种协作模式：AI协助人类开发人员，增强他们的技能，而不是取代他们。通过持续学习、战略整合以及关注人机合作，LLM将成为软件开发生命周期中不可或缺的工具，有望将调试转变成更主动、更智能的过程。

原文标题：​​LLMs for Debugging Code​​，作者：Surya Teja Appini