[Paper] 探索大语言模型在初学者程序错误定位中的潜力与局限性

Source: arXiv - 2512.03421v1

概览

本文研究了大型语言模型（LLM）在帮助新手程序员定位代码错误方面的效果。通过将一系列商业和开源 LLM 与传统的错误定位技术进行比较，作者展示了现代 LLM 能提供更具上下文感知的提示——尤其是当模型具备推理能力时——同时也暴露了如过度解释和高计算成本等新挑战。

主要贡献

• 全面基准：在三个错误定位数据集上评估了 13 种 LLM（6 种闭源，7 种开源），其中包括新构建的 “BugT” 数据集，消除了数据泄漏的顾虑。
• 实证证据：具备推理能力的模型（如 OpenAI o3、DeepSeek‑R1）在几乎不需要提示工程的情况下，优于传统的 SBFL/MBFL 工具以及不具备推理的 LLM（如 GPT‑4）。
• 以人为本的评估：新人开发者（≈1 年经验）对 LLM 生成的解释评分很高，验证了其在教学中的价值。
• 失败模式识别：如 “过度推理”（解释冗长且噪声多）以及在更难的错误上性能下降。
• 成本分析：量化了在实时调试工作流中运行 LLM 的计算开销。

方法论

1. 数据集 – 作者使用了三个公开的错误集合：
   • Codeflaws（带有合成缺陷的 C 程序）
   • Condefects（Java 程序）
   • BugT – 基于真实学生提交构建的新数据集，经过严格筛选以避免与 LLM 训练数据重叠。
2. LLM 选择 – 评估了六种专有模型（如 OpenAI o3、GPT‑4）和七种开源替代模型（如 Llama‑2、DeepSeek‑R1）。
3. 提示设计 – 比较了两种提示策略：基线提示（简单的 “找出错误”）和 推理提示（要求模型一步步解释思路）。
4. 指标 – 错误定位准确率（top‑1、top‑3、top‑5）、解释有用性（通过对新人程序员的 Likert 量表调查）以及推理延迟/成本。
5. 统计分析 – 使用配对 t 检验和效应量计算，评估不同模型和数据集之间的显著性。

结果与发现

• 推理提示 能显著提升支持链式思考的模型性能；非推理模型则需要精心设计的提示才能缩小差距。
• 随着错误难度提升，准确率会下降，但最佳的推理模型在最难的 BugT 案例中仍保持 >70 % 的 top‑1 成功率。
• 大约 15 % 的 GPT‑4 输出出现 过度推理，解释冗长且掩盖了真实错误位置。
• 用户研究：48 位新人程序员对 LLM 解释的清晰度和帮助程度平均评分为 4.3/5，而 SBFL 工具的输出仅为 2.9/5。
• 计算成本：在交互式 IDE 中部署高性能 LLM 会为每次查询增加约 2 秒的延迟，并产生不小的云费用，限制了大团队的可行性。

实际意义

• IDE 插件：嵌入支持推理的 LLM（如 OpenAI o3）可以为初学者提供即时、上下文丰富的提示，减少反复试错的时间。
• 教育平台：自动化辅导系统可利用 LLM 的解释能力教授调试策略，而不仅仅指出错误行。
• 混合流水线：将廉价、快速的静态分析（SBFL）用于粗粒度定位，再用 LLM 提供细粒度、自然语言解释，以平衡成本和准确性。
• 团队入职：新成员可使用 LLM 驱动的助手加速熟悉遗留代码库，尤其在文档稀缺的情况下。
• 成本感知部署：实时使用时，可通过缓存常见查询、批量请求或在本地运行更小的开源模型（并进行微调）来降低延迟和费用。

局限性与未来工作

• 数据集偏差：尽管 BugT 减少了泄漏风险，但基准仍主要聚焦学术练习；在大型工业代码库上的表现尚未验证。
• 模型透明度：LLM 推理的 “黑箱” 特性使得难以验证所建议的修复是否真正可靠，存在信任问题。
• 可扩展性：当前的推理成本限制了大规模采用；未来工作应探索模型蒸馏、量化或端侧推理。
• 提示鲁棒性：研究显示非推理模型对提示措辞敏感；制定标准化提示模板或能提升一致性。
• 用户交互设计：仍需进一步研究如何呈现解释（如行内注释 vs. 独立面板），以在不让新人感到负担的前提下最大化理解。

作者

• 徐和翔
• 刘恒源
• 吴永浩
• 康晓兰
• 陈翔
• 刘勇

论文信息

• arXiv ID: 2512.03421v1
• 分类: cs.SE
• 发布日期: 2025 年 12 月 3 日
• PDF: Download PDF