LLM代码生成中的幻觉问题
我经常看到开发人员尝试使用LLM编写代码时遇到幻觉——通常是LLM发明了一个不存在的方法,甚至是一个完整的软件库——这让他们对LLM作为编写代码工具的信心崩溃。

我经常看到开发人员尝试使用LLM编写代码时遇到幻觉——通常是LLM发明了一个不存在的方法,甚至是一个完整的软件库——这让他们对LLM作为编写代码工具的信心崩溃。如果这些工具会发明不存在的方法,那么谁还能有效地使用它们呢?
代码中的幻觉在是你能遇到的最无害的幻觉之一。
在这里,当我提到“幻觉”时,我指的是LLM生成完全不真实的事实的情况,在这种情况下,输出的代码引用根本不存在。我认为这是与错误和其他错误分开的问题,其余的内容将在本文的其他部分讨论。
使用LLM编写代码时真正存在的风险是它们会犯一些不会立即被语言编译器或解释器捕捉到的错误。这种情况总是发生!
当你运行LLM生成的代码时,任何幻觉出的方法都会立即显现出来:你会得到一个错误。你可以自己修复这个错误,或者你可以将错误反馈给LLM并看着它自我修正。
相比之下,在常规散文中的幻觉需要批判性的眼睛、强烈的直觉和良好的事实核查技能来避免分享不正确且直接损害你声誉的信息。
在代码方面,你可以免费获得一种强大的事实核查方式。运行代码,看看它是否工作。
在某些设置中——ChatGPT代码解释器、Claude代码,以及越来越多的“自主”代码系统,它们会循环编写和执行代码——LLM系统本身会发现错误并自动进行修正。
如果你在不运行代码的情况下就使用LLM,你在做什么?
幻觉出的方法是一个如此微小的障碍,当人们抱怨它们时,我认为他们几乎没有花时间学习如何有效地使用这些系统——他们在第一个障碍前就放弃了。
我有些愤世嫉俗的一面认为他们可能一直在寻找理由否定这项技术,并抓住了第一个机会。
我比较不愤世嫉俗的一面认为,可能没有人警告过他们,你需要投入大量的工作才能从这些系统中获得好的结果。我已经探索了它们在编写代码方面的应用超过两年,而且我几乎每天都在学习新的技巧(以及新优缺点)。
1、手动测试代码是必不可少的
即使代码看起来不错并且没有错误,也不意味着它真的在做正确的事情。再仔细的代码审查,甚至是全面的自动化测试,也不能证明代码实际上在做正确的事情。你必须亲自运行它!
证明代码有效是你的工作。这就是为什么我认为LLM不会让软件专业人士失业的原因之一。
LLM生成的代码通常看起来非常棒:好的变量名、令人信服的注释、清晰的类型注解和逻辑结构。这可能会让你产生虚假的安全感,就像来自ChatGPT的语法正确且自信的回答可能会诱惑你跳过事实核查或应用怀疑的眼光一样。
避免这些问题的方法与你审查其他人编写的代码或你自己编写的代码时避免问题的方法相同:你需要主动测试这段代码。你需要具备出色的手动质量保证技能。
编程的一般规则是,永远不要信任任何未经你亲眼验证其运行情况的代码——最好是看到它失败然后修复它。
在我的整个职业生涯中,几乎每次我都假设某些代码在不主动执行的情况下工作了——例如很少触发的分支条件,或者我不期望发生的错误消息——后来我都后悔了这个假设。
2、减少幻觉的技巧
如果你真的看到LLM生成的代码中有大量幻觉细节,有几种方法可以解决这个问题。
- 尝试不同的模型。可能是另一个模型对你的选择平台有更好的训练数据。作为一名Python和JavaScript程序员,我目前最喜欢的模型是Claude 3.7 Sonnet(开启思考模式)、OpenAI的o3-mini-high和GPT-4o(带有代码解释器)。
- 学习如何使用上下文。如果LLM不知道某个特定库,通常可以通过输入几十行示例代码来解决。LLM非常擅长模仿事物,并且能够从非常有限的例子中迅速掌握模式。现代模型的上下文窗口越来越大——我最近开始使用Claude的新GitHub集成来将整个仓库导入上下文,效果非常好。
- 选择无聊的技术。我确实发现自己选择了一些存在已久库,部分原因是这样更有可能让LLMs能够使用它们。
我会用一个相关的观察来结束这个抱怨:我不断看到人们说“如果我不得不逐行审查LLM写的代码,还不如我自己写!”
这些人大声宣布他们已经在阅读、理解和审查他人代码的关键技能上投资不足。我建议多加练习。审查由LLM为你编写的代码是很好的练习方式。
原文链接:Hallucinations in code are the least dangerous form of LLM mistakes
汇智网翻译整理,转载请标明出处
