[Paper] 基于LLM的软件工程工具评估：实践、挑战与未来方向

Source: arXiv - 2604.24621v1

概述

大型语言模型（LLMs）如今已成为许多软件工程工具的核心组件——从代码生成器到自动审查工具。本文退一步思考：我们应如何可靠地评估这些由 LLM 驱动的工具？ 作者认为传统的 SE（软件工程）或 ML（机器学习）评估方法不足，因为 LLM 会产生开放式、非确定性且常常带有主观性的输出。他们的分析将这些挑战映射到具体的 SE 任务，并提出了一套研究议程，以实现更可信的评估实践。

关键贡献

• 针对基于 LLM 的 SE 工具的评估空白的关键分类（真实标签不稳定性、主观性、非确定性、碎片化指标）。
• 对当前评估实践的全面调查，涵盖代码生成、代码审查、缺陷分配以及相关的 AI4SE 任务。
• 概念框架，将 LLM 评估视为 任务依赖 的问题，而非“一刀切”的指标集合。
• 未来方向路线图，包括多维质量指标、人机交互协议以及面向 SE 的标准化基准套件。
• 呼吁社区制定统一标准，以减少碎片化并提升 LLM‑SE 研究的可重复性。

方法论

1. 文献映射 – 作者收集并分类了最近（2022‑2024）的 AI4SE 论文，这些论文报告了对 LLM 驱动工具的实证评估。
2. 差距分析 – 通过将报告的评估设置与经典软件工程/机器学习标准（真实标签、确定性输出、单分数正确性）进行比较，他们识别出系统性的错配。
3. 任务层面深度探讨 – 对四个代表性的软件工程任务（代码合成、自动审查、缺陷分配、文档生成），他们检查了评估选择（如 BLEU、人类评分、通过/失败测试）是如何成功或失败的。
4. 专家访谈 – 与 12 位从业者和研究者进行的半结构化访谈帮助验证了已识别的挑战并揭示了真实世界的痛点。
5. 未来方向综合 – 利用差距和访谈洞见，作者起草了一套可操作的研究问题和方法论建议。

结果与发现

论文表明，仅依赖任何单一指标（例如单元测试通过率）可能会大幅高估或低估工具的实际效用。

实际意义

• 工具构建者 应该加入 多次运行测试 并报告方差（例如置信区间），而不是仅给出单一分数。
• 产品团队 可以采用 人机交互 评估流水线，将自动化检查与开发者对可读性、安全性等维度的评分相结合。
• 基准设计者 鼓励创建 任务特定、多面向 数据集（例如带有风格、性能和安全标签的代码片段）。
• CI/CD 集成 – 将 LLM 代码生成器接入流水线时，团队需要将其输出视为 概率性产物，并对多个生成变体执行后续的静态分析和测试套件。
• 供应商透明度 – 发布 LLM‑SE 工具的公司应公开评估协议，包括提示模板、温度设置和样本规模，以建立信任。

限制与未来工作

• 任务范围 – 本研究聚焦于软件工程活动的一个子集；需求工程或架构设计等领域仍未得到充分探索。
• 数据集偏差 – 调查的论文和访谈样本偏向学术原型；工业规模的部署可能呈现不同的评估约束。
• 人工评估成本 – 虽然作者倡导更丰富的人类研究，但他们也承认在实际中扩大此类评估的困难。

未来的研究方向包括：为软件工程开发标准化、版本化的基准套件，为非确定性输出设计稳健的统计协议，以及探索自动化的多维质量估计器，使其更好地与开发者的判断保持一致。

作者

• Utku Boran Torun
• Veli Karakaya
• Ali Babar
• Eray Tüzün

论文信息

• arXiv ID: 2604.24621v1
• 类别: cs.SE
• 出版日期: 2026年4月27日
• PDF: 下载 PDF