技术摘要：当大语言模型虚构 Rust Crate 时

问题陈述

大语言模型（LLMs）正越来越多地被用于代码生成，但它们仍然容易出现“幻觉”——即产生看似合理但事实错误或虚构的输出。其中一个关键的子集是包幻觉（package hallucination），即 LLM 推荐或导入了不存在的依赖项。在 Python 和 JavaScript 等语言中，这构成了严重的供应链安全风险，因为攻击者可以预先注册具有幻觉名称的恶意包。

尽管先前的研究已广泛研究了流行生态系统（Python、JavaScript）中的包幻觉问题，但在 Rust 领域仍存在显著的研究空白。Rust 被广泛应用于安全性要求极高的系统级编程（如操作系统、区块链）。虽然 Rust 的依赖管理（通过 Cargo.toml）与其他语言不同——要求在下载前进行显式声明——但在源代码中出现的幻觉 crate 引用仍然是一个直接的可靠性问题。它们会导致构建失败、导入无法解析以及命名空间混乱。此外，在许多 LLM 辅助的工作流中，生成的源代码片段往往不包含完整的项目清单，使得源代码层面的 crate 引用成为观察到依赖相关错误的早期信号。

研究方法

为了解决缺乏 Rust 经验性数据的问题，作者对 LLM 生成的 Rust 代码中的 crate 幻觉进行了首次大规模研究。

1. 数据集构建

作者构建了一个包含 2,794 个编程任务的多源数据集，这些任务源自三个渠道：

• Stack Overflow： 1,001 个独特的、高票数的 Rust 问题，代表了现实世界的开发者查询。
• GitHub： 从排名前 100 的 Rust 仓库（按星数排序）中提取的 793 个任务，并经过质量过滤以排除编译器内部实现、模糊任务和特定平台的约束。
• LLM 生成的任务： 通过使用 Qwen2.5-32B 模型，将流行 crate（来自 lib.rs 和 crates.io）的描述转化为实现请求而创建的 1,000 个任务。

2. 模型评估

研究评估了 14 个模型，涵盖 六个家族，包括：

• 商业模型： GPT-5, Gemini 2.5 Pro, Claude 4 Opus。
• 开源模型： Qwen2.5-Coder（各种尺寸）, DeepSeek-Coder-V2, OpenCoder。
  模型在默认配置和各种解码温度（0 到 5）下进行了测试。

3. 检测机制

作者通过抓取 crates.io、Rust 标准库以及 rustc 编译器 crate 构建了一个完整的有效 Rust crate 清单。作者还挖掘了仓库的 Cargo.toml 文件以捕获 crate 别名。

• 提取： 系统使用三种模式从生成的代码中提取 crate 名称：use 声明、直接路径前缀以及 extern crate 声明。
• 指标： Crate 幻觉率（CHR） 计算为从提取的名称中缺失于有效清单的名称与总提取名称的比率。

4. 缓解策略评估

研究测试了两种旨在无需重新训练模型即可减轻幻觉的提示工程策略：

• 自我修正（Self-Refinement）： 一个多轮过程，模型审查其自身的输出，检查标准库的使用情况，并在最终确定前验证 crate 名称。
• 检索增强生成（RAG）： 为模型提供一个包含 crates.io 前 10,000 个 crate 以及标准库模块列表的检索索引，以引导其生成过程。

关键结果

RQ1: 普遍性与影响因素

• 高普遍性： 所有模型的整体 CHR 为 20.23%。在所有评估的模型中都观察到了幻觉现象。
• 模型敏感性： 虽然特定模型的表现较好（例如 Gemini 2.5 Pro 为 16.18%，而 Claude 4 Opus 为 26.90%），但商业模型与开源模型之间的平均差异在统计学上并不显著。
• 参数无关性： 与 Python/JavaScript 的发现不同，模型规模（参数量）在模型家族内部（例如 Qwen2.5-Coder 变体）与幻觉率之间没有表现出统计学上的显著相关性。
• 温度无关性： 增加解码温度并未导致系统性的幻觉增加。CHR 在不同温度设置（0–5）下保持稳定，这与以往研究中提高温度会增加幻觉率的发现形成对比。

RQ2: 幻觉模式

研究识别了四种不同的、Rust 特有的模式：

1. 模块-Crate 混淆： 超过 45% 的幻觉实际上是有效的 Rust 标准库模块（例如 std::thread, std::io）被错误地引用为外部 crate。模型经常未能使用 std:: 或 core:: 对其进行限定。
2. 跨模型一致性： 模块幻觉在不同模型之间表现出高度重叠（Jaccard 相似度 ≈ 0.44），表明存在共同的训练数据局限性；而非常规模块的幻觉则更具模型特异性。
3. 近似错误变体： 幻觉名称主要是真实 crate 的微小变体。86.48% 的幻觉在编辑距离（Levenshtein distance）为 5 以内。一个显著的模式是 连字符的误用，即模型生成了 camelCase 名称（例如 httpresponse），而非 Rust 的 kebab-case 惯例（例如 http-response）。
4. 跨生态系统迁移： 大约 39% 的频繁幻觉复用了其他生态系统（如 Python 或 Windows API）的名称，表明存在结构化但错位的知识迁移。

RQ3: 缓解效果

• 收益有限： 两种缓解策略都降低了幻觉率，但改进幅度是 微小的。
• 自我修正： 持续降低了 CHR 2–3 个百分点（约 10–15% 的相对降幅）。
• RAG： 提供的改进有限且不稳定；在某些情况下，它甚至略微增加了幻觉率。
• 结论： 简单的提示层干预不足以实质性地消除 crate 幻觉。

重要性与贡献

本文声称以下贡献：

1. 首次实证研究： 它提供了对 LLM 生成的 Rust 代码中 crate 幻觉的首次系统性调查，填补了由 Python 和 JavaScript 研究主导的文献空白。
2. 独特的模式： 研究揭示了 Rust 的幻觉遵循与其它语言截然不同的模式：它们具有高度结构化特征（通常涉及模块混淆和命名规范错误），并且对模型规模和解码温度表现出惊人的不敏感性。
3. 数据集发布： 作者发布了一个包含 2,794 个 Rust 编程任务的数据集，以促进未来的研究。
4. 安全与可靠性影响： 研究强调，虽然 Rust 的依赖模型通过要求更新 Cargo.toml 缓解了直接的供应链攻击，但幻觉引用仍会导致严重的构建失败和可靠性问题。研究表明，未来的缓解措施需要 具备 Rust 感知的护栏（例如命名空间验证、注册表感知检查以及 Cargo.toml 交叉引用），而非通用的提示工程。

作者总结道，虽然轻量级策略能带来边际收益，但稳健的缓解可能需要与工具链级别的验证以及针对 Rust 生态系统的特定训练数据改进进行更紧密的集成。