[论文阅读] 人工智能 + 软件工程 | LLM当“裁判”靠谱吗？——解析代码生成与总结任务中的LLM评判能力

LLM当“裁判”靠谱吗？——解析代码生成与总结任务中的LLM评判能力

论文：On the Effectiveness of LLM-as-a-judge for Code Generation and Summarization

arXiv:2507.16587
On the Effectiveness of LLM-as-a-judge for Code Generation and Summarization
Giuseppe Crupi, Rosalia Tufano, Alejandro Velasco, Antonio Mastropaolo, Denys Poshyvanyk, Gabriele Bavota
Comments: Accepted at TSE. IEEE Transactions on Software Engineering
Subjects: Software Engineering (cs.SE)

一段话总结

本文研究了LLM-as-a-judge在代码生成和代码总结两个任务中的有效性，选取了8个不同参数规模的LLM（如GPT-4-turbo、CodeLlama、DeepSeek Coder等）进行实验。在代码生成任务中，评估了它们对1405个Java方法和1281个Python函数正确性的判断；在代码总结任务中，将5个LLM的判断与9名人类对约1.2k摘要的评价进行对比。结果显示，GPT-4-turbo是两个任务中表现最好的法官，但仍频繁误判代码正确性（错误率约50%）和摘要质量；参数规模较小的LLM（数十亿参数）难以胜任判断任务。

研究背景：给代码“打分”的难题

想象一下，如果你是一名编程老师，每天要批改上百份学生的代码作业：有的代码逻辑对了但写法啰嗦，有的代码和“标准答案”长得不一样却能完美运行，有的注释写得像天书根本看不懂……你该怎么高效又准确地打分？

在软件工程领域，类似的难题一直存在。随着大语言模型（LLM）越来越多地用于代码生成（比如让AI写一个排序函数）和代码总结（比如让AI给一段代码写注释），人们迫切需要给这些AI生成的结果“打分”——但传统方法要么不靠谱，要么太费劲：

• 定量指标的局限：以前常用BLEU、ROUGE等指标，就像用“字数匹配度”给作文打分，完全抓不住重点。比如一段代码总结写得清清楚楚，但和“参考注释”用词不一样，就会被这些指标判为“差”。
• 人工评估的痛点：让程序员手动打分最准，但成本极高。评估1000段代码可能需要几个专家忙一周，更别说大规模应用了。

于是，研究者们想到：既然LLM能写代码、写总结，能不能让它们来当“裁判”，给同类任务的结果打分？这篇论文就聚焦这个问题，测试了不同LLM当“裁判”的靠谱程度。

主要作者及单位信息

本文作者来自瑞士和美国的研究机构，包括：

• Giuseppe Crupi、Rosalia Tufano、Gabriele Bavota：瑞士意大利语区大学（Università della Svizzera italiana）SEART实验室
• Alejandro Velasco、Antonio Mastropaolo、Denys Poshyvanyk：威廉与玛丽学院（W&M）

创新点：给LLM“裁判”做一次全面“体检”

这篇论文的独特之处在于，它不是简单地说“LLM能当裁判”或“不能”，而是做了一次系统的“体检”：

1. 双任务测试：同时测试了LLM在代码生成（判断代码是否正确）和代码总结（判断注释质量）两个任务中的评判能力，覆盖了代码领域的核心生成任务。

2. 多模型对比：选了8个不同“体型”的LLM（从13亿参数的“小个子”到千亿参数的“大块头”），包括DeepSeek Coder、CodeLlama、GPT-3.5-turbo、GPT-4-turbo等，看看“体型”是否影响“裁判水平”。

3. 深入挖原因：不仅看LLM判得对不对，还分析了误判的原因（比如是没看懂代码，还是“脑补”了不存在的错误），甚至检查了LLM是否会“偏心”（给自己生成的代码打高分）。

研究方法：给LLM“裁判”出的“考题”

为了测试LLM的评判能力，研究者设计了一套严格的“考试流程”，拆解开来其实很简单：

步骤1：确定“考题”——选数据集

• 代码生成任务：用CoderEval基准（包含230个Java和230个Python编程题），每个题有明确的需求（比如“写一个计算斐波那契数列的函数”）和测试用例（用来验证代码是否正确）。但先对数据集“打假”：剔除了测试用例不靠谱的题（比如空函数都能通过测试的），最后保留184个Java题和190个Python题。

• 代码总结任务：自建数据集，选了99个Java和99个Python复杂函数（代码越长，注释越重要），收集了两类摘要：一是人类写的注释，二是5个LLM生成的注释，共1163条。同时让9名有经验的程序员给这些摘要打分（从“内容是否准确”“是否简洁”“是否好懂”三个维度），作为“标准答案”。

步骤2：给“裁判”发“评分标准”——设计提示词

为了让LLM明白怎么打分，研究者试了4种提示词，比如：

• “零样本”提示：直接说“请判断这段代码是否正确，用0（错）或1（对）回答，并说明理由”。
• “思维链”提示：先让LLM一步步分析“这段代码哪里对/哪里错”，再下结论。

最后选了对GPT-4-turbo效果最好的提示词来分析结果。

步骤3：批改“答卷”——评估LLM的判断

• 代码生成：对比LLM的判断和测试用例结果（代码跑过测试就是对，否则是错），用“混淆矩阵”看LLM多少时候判对（真阳性/真阴性）、多少时候判错（假阳性/假阴性），用Cohen’s Kappa值衡量一致性。

• 代码总结：对比LLM的打分和人类打分，用Krippendorff’s α值衡量一致性（值越高，和人类想法越像）。

主要贡献：LLM“裁判”的成绩单

经过一系列测试，研究者得出了几个关键结论，直接告诉你LLM当裁判靠不靠谱：

1. “体型”很重要，GPT-4-turbo是“最佳裁判”
   小参数LLM（比如13亿参数的DeepSeek Coder）基本不靠谱，打分和瞎猜差不多；而GPT-4-turbo在两个任务中都是表现最好的。比如在代码总结任务中，它对“内容准确性”的判断和人类的一致性达到0.58（Java）和0.63（Python），属于“中等一致”。

2. 代码生成任务：GPT-4-turbo也常“看走眼”
   虽然是最佳，但GPT-4-turbo在判断代码正确性时，错误率不低：50%的错误代码会被它判为“正确”（假阳性），尤其在Java中表现更明显。原因包括没发现代码里的bug，或者误解了编程需求。

3. 代码总结任务：GPT-4-turbo更靠谱
   在判断注释质量时，GPT-4-turbo对“内容是否准确”“是否简洁”的把握和人类比较接近，尤其对“内容准确性”的判断一致性较高，说明它能理解代码和注释的语义关联。

4. LLM可能“低估人类，高估同类”
   所有LLM都倾向于给人类写的代码/注释打低分，给其他LLM生成的打高分，有点“抱团”倾向；但GPT-4-turbo的“偏心”程度最轻。

---

2. 思维导图

---

3. 详细总结

3.1 研究背景与目的

• 背景：LLM在软件工程中广泛应用于代码生成、总结等生成式任务，但现有定量指标（如BLEU）存在局限，人工评估成本高。LLM-as-a-judge被提议作为替代方案，但在代码相关任务中的有效性尚未明确。
• 目的：探究LLM作为法官在代码生成（判断函数正确性） 和代码总结（评估摘要质量） 任务中的表现。

3.2 实验设计

维度	详情
选取的LLM	8个模型，涵盖不同参数规模： - DeepSeek Coder（1.3B、6.7B、33B） - CodeLlama（7B、13B、34B） - GPT-3.5-turbo、GPT-4-turbo
数据集处理	- 代码生成：基于CoderEval基准，经质量校验（排除弱测试用例）后保留184Java+190Python问题 - 代码总结：自建1163个摘要（含99Java+99Python函数的人类及LLM生成摘要）
评估指标	- 代码生成：Cohen’s Kappa（衡量与测试结果一致性）、混淆矩阵（TP/TN/FP/FN） - 代码总结：Krippendorff’s α（衡量与人类评价一致性）
提示词设计	每种任务测试4种提示词（如零样本、自动化思维链），最终选取对GPT-4-turbo效果最优的提示词

3.3 代码生成任务结果

• LLM表现差异：

  • GPT-4-turbo表现最佳，Java的Cohen’s Kappa为0.21（公平一致），Python为0.10（弱一致）；小模型（如DeepSeek Coder 1.3B）一致性接近随机甚至为负。
  • 混淆矩阵显示：GPT-4-turbo正确识别72%的正确Java代码，但误判50%的错误Java代码为正确；Python中正确识别46%的正确代码，误判35%的错误代码。

• 误判原因：

  • 假阳性（错误代码被判为正确）：37%因未发现bug，32%因缺乏编码上下文理解。
  • 假阴性（正确代码被判为错误）：33%因幻觉（提及不存在的错误），19%因误解代码语句。

• 自我偏见：仅GPT-4-turbo存在轻微自我偏见（高估自己生成的代码），但影响可忽略；所有LLM普遍低估人类编写代码的正确性。

3.4 代码总结任务结果

• LLM表现差异：

  • 排除无法完成任务的DeepSeek Coder后，GPT-4-turbo与人类评价一致性最高：内容充分性（Java α=0.58，Python α=0.63）、简洁性（Java α=0.40，Python α=0.36），均达中等一致。
  • 小模型（如CodeLlama 7B）与人类评价一致性极低（甚至为负）。

• 自我偏见：GPT-4-turbo无显著自我偏见；CodeLlama系列存在对自身生成摘要的过度高估，但因判断能力差，不视为有效偏见。

3.5 结论与未来工作

• 结论：GPT-4-turbo是最优LLM法官，但代码生成任务中误判率高，代码总结任务中表现更可靠；小模型难以胜任。
• 未来工作：微调小模型用于代码相关判断任务，扩展研究至漏洞修复等更多任务。

---

4. 关键问题

1. 为什么参数规模较小的LLM（如CodeLlama 7B）在判断任务中表现远差于GPT-4-turbo？
   答案：主要原因包括参数规模限制（小模型推理能力弱）、训练数据差异（GPT-4-turbo训练数据更丰富，含更多代码和文本）、任务复杂度（判断需深度理解代码逻辑和自然语言要求，小模型难以处理）。

2. 在代码生成任务中，GPT-4-turbo对错误代码的误判率较高（50%），这一现象对其实际应用（如自动化代码审查）有何影响？
   答案：严重限制实际应用，可能导致错误代码被误判为正确，引入软件漏洞；需结合测试用例或人工审查辅助，无法单独依赖其判断。

3. 代码总结任务中，GPT-4-turbo与人类评价的一致性高于传统指标（如BLEU），这是否意味着LLM-as-a-judge可替代传统指标？
   答案：有潜力替代，但需谨慎。GPT-4-turbo在内容充分性等维度与人类一致性较高，且能捕捉传统指标忽略的语义质量；但仍需验证其在更多场景的稳定性，未来可探索与传统指标的互补性。

总结：LLM当裁判，能用但别乱用

这篇论文通过系统实验，搞清楚了一个关键问题：LLM能当代码领域的“裁判”，但能力有明显边界。

• 解决的问题：明确了不同LLM在代码生成和总结任务中的评判能力，打破了“LLM万能”的幻想，也指出了可行的应用场景。
• 主要成果：GPT-4-turbo是目前最靠谱的LLM“裁判”，但在代码生成任务中误判率高，适合辅助人工；在代码总结任务中表现更稳定，有潜力替代部分人工评估。小参数LLM暂时不适合当裁判。

未来，研究者计划通过微调让小LLM更擅长评判，拓展到漏洞修复等更多任务——或许不久后，AI不仅能写代码，还能当好“阅卷老师”。