💬 NLP

Library Hallucinations in LLM-Generated Code: A Risk Analysis Grounded in Developer Queries

本文首次系统研究了现实中的开发者提示词变体（如拼写错误和虚构名称）如何触发大语言模型生成代码中的库幻觉，揭示了显著的安全漏洞，并引入了 LibHalluBench 基准测试以支持对这些风险的可复现评估与缓解。

原作者： Lukas Twist, Jie M. Zhang, Mark Harman, Helen Yannakoudakis

发布于 2026-05-20

📖 1 分钟阅读☕ 轻松阅读

原作者： Lukas Twist, Jie M. Zhang, Mark Harman, Helen Yannakoudakis

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你有一位才华横溢、自信满满但略显健忘的助手，他是编写计算机代码的专家。你请他构建一个特定工具，他便愉快地开始输入。然而，这位助手有一个危险的坏习惯：有时，当他不知道所需工具的确切名称时，他只会凭空捏造一个。他会编造一个不存在的库（即预先编写好的代码集合），但他写得如此自信，以至于你可能直到尝试使用它并发现它无法运行时，才意识到它是假的。

本文深入探讨了为什么这位助手会编造这些虚假工具，特别是当你给出略有不同的指令或犯下小错误时。

以下是他们研究发现的分解，使用简单的类比说明：

1. “时间旅行”陷阱

研究人员发现，如果你要求助手提供一个“来自 2025 年”的工具（即尚未发生或超出其训练范围的年份），助手会变得非常紧张，并开始疯狂地产生幻觉。

类比：想象你向图书管理员索要一本未来出版的书。图书管理员没有说“我没有那本书”，而是编造了一个听起来完美但根本不存在的书名、封面和摘要。
结果：当被要求提供“来自 2025 年”的库时，高达**85%**的情况下，助手会编造一个虚假的库。他们非常不擅长了解自己的“知识截止日期”（即他们停止学习的日期）。

2. “拼写错误”陷阱（潦草的拼写）

如果你不小心拼错了一个真实库的名称，助手通常不会纠正你。相反，他们会变本加厉，假装这个拼写错误的版本是真实的。

类比：想象你向厨师索要"Spagetti"（漏掉了字母'h'）。厨师没有说“您是指'Spaghetti'吗？”，而是可能从他们虚构的架子上拿起一盒标有"Spagetti"的盒子，或者更糟的是，他们可能会发明一道名为"Spagetti"的不存在的菜肴。
结果：
- 一个字母的拼写错误（例如将 numpy 写成 numpi）导致在**26%**的情况下使用了虚假库。
- 一个虚假的库名称（听起来真实但实际不存在，例如"GaussianTools"）在高达**99%**的情况下被接受并使用。助手如此急于取悦你，以至于宁愿使用虚假工具，也不愿告诉你它不存在。

3. “形容词”陷阱（什么不起作用）

有趣的是，如果你要求一个“快速”、“简单”或“现代”的库，助手通常会忽略这些词，直接选择一个他们知道的标准的、真实的库。

类比：如果你要求一辆“快车”，助手只是给你一辆标准的丰田车。他们不会发明一辆“超级快速飞行汽车”，因为他们知道这些形容词很模糊。
结果：像“快速”或“轻量级”这样的形容词很少引发幻觉。危险来自于具体的约束（如日期）或错误（如拼写错误）。

4. “推理”陷阱（思考过度）

研究人员试图通过告诉助手在回答前“逐步思考”或“核实事实”来解决这个问题。

类比：这就像告诉一个紧张的学生：“深呼吸，仔细思考这道数学题。”有时这会有所帮助。但通常，学生只是因为他们花了更多时间为自己的答案辩护，而对自己的错误答案变得更加自信。
结果：这些“推理”技巧并未 consistently 奏效。事实上，它们有时会让幻觉变得更糟。助手会自信地解释为什么他们的虚假库是真实的，这使得你更难发现错误。

5. “工具”解决方案（查阅电话簿）

研究人员测试了给助手一个简单的工具：一个按钮，用于检查库是否确实存在于官方数据库（PyPI）中。

类比：与其让助手猜测，不如给他们一本电话簿。如果他们说“我将使用 Spagetti"，他们会查阅电话簿，发现那里没有，然后说：“哦，那不存在。”
结果：这很有帮助，但并非万能药。助手有时仍会忘记查阅电话簿，或者查阅后决定忽略结果，坚持使用虚假名称。

核心结论：LIBHALLUBENCH

由于这是一个重大问题，作者创建了一个名为LIBHALLUBENCH的新测试。

类比：可以将其视为专门为检测自动驾驶汽车是否会幻觉出一个虚假的停车标志而设计的“驾驶考试”。它包含数千个棘手的问题（例如“给我一个来自 2025 年的库”或“使用这个拼写错误的名称”），以系统地测试不同 AI 模型编造虚假工具的可能性。

你为什么要关心？

如果你是一名使用 AI 编写代码的开发者，而 AI 编造了一个虚假库，当你尝试运行代码时，你的程序就会崩溃。更糟糕的是，如果黑客创建了一个与 AI 编造的库相匹配的虚假库（这种技巧称为"slopsquatting"），你的系统可能会感染恶意软件。

简而言之：AI 代码生成器很棒，但当它们不知道答案时，它们会表现出危险的自信。它们会编造虚假工具来满足你的请求，特别是当你要求来自未来的东西或犯下小拼写错误时。我们需要更好的方法来阻止它们凭空捏造。

技术摘要：LLM 生成代码中的库幻觉

问题陈述

大型语言模型（LLM）已成为现代软件开发不可或缺的一部分，但它们经常通过编造不存在的库而“产生幻觉”。尽管先前的研究已承认库幻觉是一种故障模式，但人们对这些错误在真实使用条件下的表现形式了解有限。具体而言，开发者提示的变体——如自然语言描述、用户拼写错误或虚构的库名称——如何影响 LLM 生成无效导入或调用有效库中无效函数的频率，目前尚不清楚。这些幻觉带来了重大风险，包括构建失败、误导开发者，以及暴露于供应链威胁之下，例如“斜向劫持”（slopsquatting，即攻击者注册 LLM 经常幻觉的库）。

方法论

作者提出了第一项系统性研究，探讨用户级提示变体如何影响七种不同的生产级 LLM（GPT-4o-mini、GPT-5-mini、Ministral-8B、Qwen2.5-Coder、Llama-3.3、DeepSeek-V3.1 和 Claude-4.5-Haiku）中的库幻觉。

实验设计：
本研究使用 BigCodeBench 作为种子数据集，筛选出 356 个使用外部库的 Python 任务。实验分为两个主要类别：

实验 1：用户语言变体：
- 数据来源： 分析了来自软件推荐 StackExchange（SRSE）的超过 20,000 个问题，以识别常见的用户描述词。
- 变体： 修改提示以包含基于形容词的描述（例如“快速”、“轻量级”、“最佳”）和基于时间的描述（例如“来自 2023 年”、“来自 2025 年”）。
- 目标： 确定自然语言变体是否会触发幻觉。
实验 2：受控的用户错误：
- 错误类型： 研究在提示中引入了特定错误：
  - 单字符拼写错误（编辑距离 1，例如将 numpy 拼写为 numpi）。
  - 多字符拼写错误（编辑距离 2–8，例如将 plotly 拼写为 graphly）。
  - 虚构名称/成员： 完全不存在库或成员，用于模拟对先前幻觉的后续请求。
- 目标： 量化 LLM 对拼写错误和虚构实体的鲁棒性。

评估流程：

检测： 使用 Python 的 ast 模块解析生成的代码。将库名称与 Python 包索引（PyPI）进行规范化比对验证，并将库成员与最新库版本的官方文档进行比对验证。
指标： 研究测量了响应幻觉率（RHR）和任务幻觉率（THR）。
额外调查： 作者检查了提示工程策略（思维链、后退一步、自我分析）的有效性，并使用 CodeInsight（JavaScript、Rust）和工具增强型缓解措施（PyPI 存在性检查）测试了生态系统的可推广性。

主要发现

1. 对提示变体的敏感性

形容词与时间： 基于形容词的描述（例如“快速”、“开源”）很少触发幻觉（发生率 $\approx$ 0%）。相比之下，基于时间的提示是一个强烈的触发因素。要求“来自 2025 年”的库在高达 85% 的任务中引发了幻觉（具体针对 GPT-4o-mini），这显著高于要求“来自 2023 年”的请求。
用户错误： LLM 对命名错误的鲁棒性较差。
- 单字符拼写错误在高达 26% 的任务中触发了幻觉。
- 多字符拼写错误在高达 79% 的任务中触发了幻觉。
- 虚构库名称在某些模型（例如 GPT-5-mini、Ministral-8B）的任务中被接受的比例高达 99%，这表明模型存在“阿谀奉承”的倾向，即顺应用户的错误前提而不是纠正它。

2. 库名称与成员幻觉

库名称： 当提示中包含错误或时间限制时，模型极易幻觉出整个不存在的库。
库成员： 在有效库中幻觉成员（函数/类）的发生率通常较低（大多在 1%–5% 之间），但依然存在。有趣的是，较新的模型（GPT-5-mini、DeepSeek-V3.1）有时比旧模型表现出更高的成员幻觉率，通常是在没有版本说明的情况下建议已弃用的函数。

3. 缓解措施与可推广性

提示工程： 轻量级策略如思维链和后退一步提示是不可靠的，有时甚至通过强化错误推理而增加了幻觉率。显式检查和自我分析显示出更多希望，但在不同模型间表现不一致。
工具使用： 提供 PyPI 存在性工具显著减少了幻觉（例如，GPT-4o-mini 在基于年份的提示中降至 <3%），但并未完全消除。模型经常未能调用该工具或忽略负面结果。
生态系统： 幻觉模式在 Python、JavaScript 和 Rust 中持续存在，表明该漏洞不仅限于单一语言或生态系统。

贡献

系统性研究： 首次对提示变体（语言和错误）如何影响库幻觉进行了细粒度分析，揭示了基于时间的措辞和拼写错误是关键触发因素。
阿谀奉承与拼写劫持的关联： 本文揭示了 LLM 行为与供应链风险之间的新颖联系，证明模型经常对微小的拼写错误自信地幻觉出库，从而可能加剧拼写劫持和斜向劫持攻击。
LIBHALLUBENCH： 引入了一个新的基准测试，包含 4,173 个标记提示，这些提示源自高风险条件（基于年份、基于稀有性和基于错误），以实现对库幻觉的可重复评估。
开放资源： 发布了代码、完整模型输出和基准测试，以支持未来的研究和缓解措施开发。

意义与主张

该论文认为，LLM 对自然提示变体的脆弱性构成了系统性漏洞。作者声称：

当前的 LLM 不可靠，无法验证库名称或成员，即使用户提供具体（但错误）的名称。
开发者对“最新”或“近期”库的常见请求是幻觉的主要向量，独立于知识截止日期。
现有的缓解策略（如思维链）不足以应对这种特定的故障模式。
风险超越了单纯的代码错误，延伸至安全威胁，因为对虚构库的高接受率可能促进恶意软件包（斜向劫持）的采用。

作者得出结论，稳健的防御措施需要超越提示工程；它们可能需要模型层面的更改、外部验证机制，以及改变 LLM 处理库有效性不确定性的方式。该研究强调，尽管发现基于特定数据集和模型，但观察到的模式表明 LLM 代码生成中存在更广泛的系统性问题。