主页 › 范文 › 软件工程 › 本文

SWE-Judge: 软件工件的集成评估框架

摘要

文章提出SWE-Judge，首个基于LLM集成评判的软件工件评估指标，用于解决代码生成、程序修复和代码摘要等任务中自动评估与人类判断的差距。该方法创新性地设计五种评估策略（直接评估、反思评估、等价性评估、测试生成评估和参考分析评估），通过动态团队选择机制组合最优策略子集，集成生成最终正确性分数。在六大数据集（CoNaLa、Card2Code等）上的实验表明，SWE-Judge与人类评估的相关性提升5.9%-183.8%，在代码生成和程序修复任务中达到接近人类间评估的一致性水平。

1. 引言

软件工程中自动生成代码片段、补丁和注释等工件的技术日益普及，但评估生成工件的正确性仍面临重大挑战：人工评估准确但缺乏扩展性；基于测试的指标（如Pass@k）依赖精心设计的测试用例；现有自动评估指标常无法准确反映正确性。文章提出SWE-Judge，通过大语言模型（LLM）的集成评判机制，首次实现软件工件正确性的高效自动评估。

2. SWE-Judge 方法框架

2.1 核心设计

受学术同行评审机制启发，SWE-Judge包含三个关键组件：

多样化评估策略：定义五种独立评估策略，每种策略实现为独立“评审员”：
- 策略1（直接评估）：LLM直接输出正确性分数（0-4）
- 策略2（反思评估）：对策略1的结果进行批判性修正
- 策略3（等价性评估）：判断生成工件与参考方案的语义等价性
- 策略4（测试生成评估）：LLM生成测试用例并验证通过率
- 策略5（参考分析评估）：提取参考方案关键属性并验证匹配度
动态团队选择：从6种策略变体（含策略1的两种变体）中筛选最优组合，通过57种可能团队的Kendall τ/Spearman/Pearson相关性测试，选择最佳团队。
分数集成：选定团队对样本独立评分后，采用简单平均集成，并通过线性变换映射到目标量程（如0-4分）。

2.2 技术突破

相比现有SOTA方法ICE-Score（单一直接评估策略），SWE-Judge的创新在于：

\[ \mathcal{E}(x,y,r) = \text{Ensemble}\left( \text{TeamSelect}\left( \bigcup_{i=1}^{5} P_i(x,y,r) \right) \right) \]

其中动态团队选择机制使评估适应不同数据集特性，多策略集成显著提升语义理解深度。

3. 实验验证

3.1 评估基准

在三大软件工程任务上验证：

任务类型	数据集	工件类型	编程语言
代码生成	CoNaLa, Card2Code	代码片段	Python
程序修复	APR-Assess	代码补丁	Java/C++
代码摘要	Summary-Assess	自然语言描述	Java

3.2 关键结果

人类评估相关性：在四个标注数据集上，SWE-Judge的Kendall τ平均提升70.1%，最高达183.8%（Summary-Assess）。
人类-工具一致性：在代码生成（Card2Code）和程序修复（APR-Assess）任务中，Cohen's Kappa分别达35.1和66.7，接近人类间一致性水平（30.5和60.1）。
消融实验：移除团队选择机制导致平均相关性下降9.6%，同时移除策略设计则导致最高52.8%的性能损失。

3.3 跨任务泛化

在基于测试执行的代码生成任务（HumanEval-X/APPS）中，SWE-Judge相关性提升32.1%-1691.7%，证明其从人类评估到测试执行的泛化能力。

4. 结论

SWE-Judge首次实现LLM驱动的软件工件多策略集成评估，显著缩小自动评估与人类判断的差距。未来工作将扩展至非功能性属性（如代码效率）评估，进一步提升软件自动化工具的可靠性。