RubberDuckBench横空出世！20个LLM编码助手大测评，幻觉率竟高达58.3%

论文信息

• 原标题：RubberDuckBench: A Benchmark for AI Coding Assistants
• 主要作者及研究机构：
  • Ferida Mohammad（布林莫尔学院，美国）
  • Fatma Ayad（布林莫尔学院，美国）
  • Petros Maniatis（谷歌DeepMind，美国）
  • Satish Chandra（元宇宙平台公司，美国）
  • Elizabeth Dinella（布林莫尔学院，美国）
• 引文格式（GB/T 7714）：
  Mohammad F, Ayad F, Maniatis P, et al. RubberDuckBench: A Benchmark for AI Coding Assistants[C]//3rd International Workshop on Large Language Models For Code (LLM4Code ’26). Rio de Janeiro, Brazil: ACM, 2026: 1-8. https://doi.org/10.1145/3786181.3788710

研究背景

如今，程序员用AI编码助手（比如GitHub Copilot）已经不是新鲜事了。Stack Overflow 2025年开发者调查显示，“找代码问题答案”是AI编码助手最常用的功能——就像写代码时身边多了个“答疑小助手”，遇到项目里具体的代码逻辑、API用法疑问，随手就能问。

但问题来了：这些AI助手的答疑水平到底怎么样？之前的评估基准要么只关注“根据文字描述写代码”，要么是些通用的编程语法问题（比如“Java接口里的私有实例方法该什么时候用”），完全不涉及具体项目的上下文。就像考试只考课本例题，却不管实际工作中遇到的复杂场景——程序员问的往往是“这个项目里这段代码为啥用std::map::at而不用[]”这种绑定具体文件、具体逻辑的问题，现有基准根本覆盖不到。

没有合适的评估标准，开发者选AI助手只能“盲猜”，研究人员也没法针对性优化模型。于是，RubberDuckBench这个专门评估“上下文代码问答”的基准就应运而生了。

1. 一段话总结

本文介绍了RubberDuckBench这一针对AI编码助手的多语言基准测试，其包含15个源自GitHub拉取请求评论的上下文相关代码问题（均匀分布于Java、Python、C++），并配有详细评估准则；通过对20个LLM（含专有和开源模型）的测试发现，顶尖模型平均得分仅60.17%，Grok 4（69.29%）、Claude Opus 4（68.53%）和GPT-5（67.80%）表现最佳但未显著优于后续9个模型，模型仅能完全正确回答最多2个问题，且平均58.3%的响应存在幻觉，同时成本（API定价或参数数量）与性能无相关性，该基准旨在为可信且正确的AI编码助手研究提供目标。

---

2. 思维导图

---

3. 详细总结

一、项目背景与目标

1. 行业现状：AI编码助手（如GitHub Copilot）的上下文聊天功能被广泛用于代码问答（Stack Overflow 2025调查显示为最常见用途），但缺乏针对性评估基准。
2. 现有基准局限：主流基准（如HumanEval、MBPP）侧重代码生成，其他基准覆盖翻译、修复等任务，均未评估“上下文相关代码问答”；类似基准（如StackEval）源自Stack Overflow，为通用问题，无需项目特定代码推理。
3. 研究目标：构建真实场景的基准测试，评估LLM回答上下文相关代码问题的准确性、幻觉率及资源性价比。

二、RubberDuckBench基准构建

构建环节	关键细节
数据来源	GitHub拉取请求评论（CodeReview数据集），聚焦“代码推理类评论”（需控制流/值传播推理）
语言分布	Java、Python、C++各5个问题，共15个
项目背景	源自13个高星开源项目（平均25.3k星），包括Mozilla/Thunderbird-android、PyTorch等
问题类型	4类：项目行为（代码功能）、库行为（API在项目中的作用）、变量值（传播逻辑）、性能考量
构建流程	1. LLM（Claude Opus 4.1）辅助筛选+重写评论为简洁问题（精度0.78）；2. 3名作者人工审核确认；3. 制定详细评估准则（平均12人时/准则，负分制，严惩幻觉）

三、测试方案

1. 测试模型：20个LLM，涵盖8大提供商，包括：
   • 专有模型：Grok 4、Claude Opus 4、GPT-5等12个
   • 开源模型：Gpt-oss-20B、Llama 3.3 70B等8个（参数8B-123B）
   • 类型划分：11个推理型、4个低成本型
2. 实验设置：
   • 提示工程：开发者角色设定+思维链（CoT）提示+标准化格式
   • 运行环境：开源模型本地（NVIDIA H100），专有模型调用API，温度0.01（近确定性）
   • 评估方式：3名作者独立应用准则评估，组内相关系数ICC3=0.991（可靠性高）

四、核心测试结果

1. 性能表现（RQ1）

• 整体水平：平均得分60.17%，中位数61.30%
• 顶尖模型排名（前5）：Grok 4（69.29%）、Claude Opus 4（68.53%）、GPT-5（67.80%）、Claude Opus 4.1（67.02%）、o3（64.93%）
• 关键发现：
  • 顶尖模型未显著优于后续12个模型（p>0.05），个体问题上低排名模型可能反超
  • 完全正确回答率极低：严格标准（3次测试均满分）下，顶尖模型最多仅2个问题完全正确
  • 语言差异：Java表现最佳（66.86%），Python最差（50.44%），19/20模型Python得分低于自身平均
  • 问题类型差异：库行为问题表现最好（63.7%），项目行为问题最差（55.0%）

2. 资源与性能权衡（RQ2）

维度	关键发现
成本相关性	无显著关联：Claude Opus 4成本（$0.597）是Grok 4（$0.05）的12倍，性能仅差0.76个百分点
性价比Top3	Gemini 2.5 Flash（成本比0.033）、GPT-5（0.044）、o3（0.060）
模型规模相关性	无关联：开源模型中，20B参数的Gpt-oss-20（63.63%）表现优于120B参数的Gpt-oss-120（59.54%）
低成本模型表现	Gemini 2.5 Flash（低成本）性能（64.30%）优于高成本的Gemini 2.5 Pro（64.01%）

3. 幻觉率（RQ3）

• 整体幻觉水平：58.3%的响应存在幻觉（错误/虚构信息）
• 高幻觉模型：o3（67%，10/15问题）、Claude Sonnet 4（16.1%扣分来自幻觉）
• 低幻觉模型：Grok 4（40%，6/15问题）、DeepSeek-R1（46%）
• 扣分规则：幻觉扣分权重高于信息遗漏（例：虚构API行为扣2分，遗漏关键信息扣1分）

五、项目贡献

1. 提出首个针对“上下文相关代码问答”的多语言真实基准RubberDuckBench；
2. 完成20个LLM的全面评估，揭示性能、幻觉率、成本的关键规律；
3. 提供可复现的评估工具包（https://cs.brynmawr.edu/RubberDuckBench）。

4. 关键问题

问题1：RubberDuckBench与现有编码基准的核心区别是什么？

答案：核心区别在于聚焦“上下文相关代码问答”场景。现有基准（如HumanEval、MBPP）侧重“自然语言到代码生成”，StackEval等源自Stack Overflow的基准为通用语言问题（无需项目特定代码推理）；而RubberDuckBench的问题源自GitHub拉取请求评论，绑定具体项目、文件及代码行，需基于项目上下文进行代码推理（如API在项目中的作用、变量传播逻辑），更贴近开发者使用AI编码助手的真实场景。

问题2：顶尖LLM在RubberDuckBench中的表现存在哪些关键局限？

答案：主要有三大局限：1. 完全正确性不足，即使表现最优的Grok 4，在严格标准（3次测试均满分）下仅能完全正确回答2个问题，多数模型为0-1个；2. 无显著优势，Grok 4、Claude Opus 4等顶尖模型与后续12个模型无统计学上的显著差异（p>0.05），个体问题上低排名模型可能反超；3. 幻觉问题严重，平均58.3%的响应存在幻觉，即使高表现的o3模型幻觉率达67%，且幻觉扣分权重高于信息遗漏，影响回答可信度。

问题3：模型的成本、参数规模与RubberDuckBench中的性能是否存在相关性？有何实践启示？

答案：无相关性。具体表现：1. 成本方面，Claude Opus 4的API成本是Grok 4的12倍，但性能仅差0.76个百分点，GPT-5以更低成本实现接近Claude Opus 4的性能；2. 参数规模方面，开源模型中20B参数的Gpt-oss-20表现优于120B参数的Gpt-oss-120。实践启示：企业或开发者选择AI编码助手时，无需盲目追求高成本专有模型或大参数开源模型，可优先考虑性价比更高的选项（如Gemini 2.5 Flash、GPT-5），同时需重视幻觉率（如优先选择Grok 4等低幻觉模型）。

创新点

1. 聚焦“上下文相关”场景：区别于以往通用编程问题，所有题目都源自GitHub真实项目的拉取请求评论，绑定具体项目、文件和代码行，还原开发者真实答疑需求。
2. 多语言+精细化评估：覆盖Java、Python、C++三大主流语言，每个问题都配套详细评分准则，采用“负分制”严惩幻觉，比简单对比“是否正确”更精准。
3. 兼顾实用性与可复现性：不仅提供15个高质量问题，还开源了完整的评估工具包，方便后续研究复用和扩展。

研究方法和思路

整个研究过程可以拆解为三大核心步骤，逻辑清晰又扎实：

第一步：筛选并重构问题（从真实评论到基准题目）

1. 数据源：选取CodeReview数据集里的GitHub拉取请求评论，这些评论都是开发者真实讨论代码的内容，自带项目上下文。
2. 筛选分类：人工分析100条评论，分成“代码推理”“需求讨论”“简单编辑建议”三类，只保留需要深度推理的“代码推理类”评论（比如讨论变量传播、API使用逻辑的内容）。
3. 重构优化：用LLM（Claude Opus 4.1）把评论重写成简洁明确的问题，再经3名研究者人工审核确认，最终选出15个问题（三种语言各5个）。

第二步：制定精细化评分准则

1. 因为问题没有唯一标准答案（比如“两个API的区别”可以从不同角度正确回答），所以放弃“标准答案对比”，转而制定多维度评分准则。
2. 准则特点：采用负分制，满分起步，遗漏关键信息扣少量分，出现幻觉（虚构API功能、项目逻辑）扣重分。
3. 打磨过程：每个准则平均耗时12人时，经过“独立起草→小组讨论→根据模型回答迭代优化”三个阶段，确保公平且全面。

第三步：大规模模型评估

1. 模型选择：涵盖8大厂商的20个LLM，包括12个专有模型（如GPT-5、Claude Opus 4）和8个开源模型（如Llama 3.3 70B），覆盖推理型、低成本型等不同类型。
2. 实验设置：统一用“开发者角色+思维链提示”优化提问方式，每个模型对每个问题测试3次（避免随机性），由3名研究者独立评分（一致性高达0.991）。
3. 分析维度：不仅看整体得分，还重点分析“完全正确答题数”“不同语言表现”“成本性价比”“幻觉率”四个核心维度。

主要成果和贡献

核心成果（用大白话讲透）

研究问题（RQ）	关键发现
RQ1：LLM在上下文代码问答中表现如何？	1. 平均得分仅60.17%，顶尖模型Grok 4（69.29%）、Claude Opus 4（68.53%）、GPT-5（67.80%）领跑，但和后续模型无显著差距； 2. 完全正确答题极少：最厉害的模型也只在2个问题上做到三次测试全满分； 3. Python表现拉胯：所有模型里19个在Python题目上得分低于自身平均（仅50.44%）。
RQ2：模型成本/规模和性能有关吗？	1. 无关！Claude Opus 4成本是Grok 4的12倍，性能仅差0.76个百分点； 2. 开源模型“小而精”更吃香：20B参数的Gpt-oss-20表现（63.63%）优于120B参数的Gpt-oss-120（59.54%）； 3. 低成本模型有惊喜：Gemini 2.5 Flash比高价的Gemini 2.5 Pro表现更好。
RQ3：模型幻觉问题严重吗？	非常严重！平均58.3%的回答存在幻觉，连顶尖的o3模型幻觉率都达67%（15题里10题说谎）；只有Grok 4幻觉率较低（40%）。

领域贡献

1. 填补空白：首个专门评估“上下文代码问答”的多语言基准，解决了现有基准不贴近真实开发场景的问题。
2. 揭示真相：打破“贵的、参数多的模型就好”的误区，为开发者选择AI助手提供了数据支撑。
3. 提供工具：开源评估工具包（https://cs.brynmawr.edu/RubberDuckBench），为后续研究打下基础。

总结

这篇论文通过扎实的实验，推出了RubberDuckBench这个高质量基准，第一次全面揭示了顶尖LLM在上下文代码问答场景中的真实表现——它们虽然能拿到六成左右的分数，但完全正确答题率低、幻觉问题突出，且性能和成本、参数规模无关联。

对于开发者来说，这意味着选AI编码助手不用盲目追高价、追大模型；对于研究人员来说，这个基准为优化“可信代码问答”指明了方向：未来需要重点提升模型的逻辑严谨性和幻觉抑制能力。