CodeAssistBench (CAB): Dataset & Benchmarking for Multi-turn Chat-Based Code Assistance¶

会议: NeurIPS 2025
arXiv: 2507.10646
代码: amazon-science/CodeAssistBench
领域: LLM/NLP
关键词: 代码助手, 多轮对话, Benchmark, 编程辅助, GitHub Issues, 项目级评估, LLM Agent

一句话总结¶

提出 CodeAssistBench (CAB)，第一个评估多轮、项目级编程辅助的全自动 Benchmark，从 GitHub Issues 自动构建 3,286 个真实编程求助场景，涵盖 7 种语言 214 个仓库，揭示 SOTA 模型在 StackOverflow 问题上 70-83% 但在 post-cutoff 仓库上仅 7-16% 的巨大鸿沟。

研究背景与动机¶

领域现状：LLM 编程助手评估已从孤立代码合成（HumanEval、MBPP）进化到仓库级维护（SWE-Bench、BigCodeBench），但现有 benchmark 要么是单轮的（InfiBench、StackEval），要么局限于代码合成的多轮对话（ConvCodeWorld、MINT、TICODER），缺少对真实多轮编程求助场景的系统评估。
开发者真实需求被忽视：2024 年 Stack Overflow 调查（34,168 名开发者）显示——77.9% 需要 AI "搜索答案"、77.3% 需要"调试排错"、73.6% 需要"理解陌生代码库"，这些任务需要迭代澄清、环境感知推理、项目特定细节整合，远超当前 benchmark 的覆盖范围。
单轮评估的根本局限：真实编程求助是多轮交互的。例如一个 Docker 端口映射问题，助手需要 (1) 理解仓库网络结构，(2) 解释代理端口是内部硬编码的，(3) 向用户保证无需额外映射——每一步回答都影响下一个问题。单轮正确性评估无法捕捉这种推理轨迹。
手动策展不可扩展：InfiBench/StackEval 依赖人工策展 StackOverflow 数据，不仅成本高昂，且随 LLM 训练数据更新会逐渐失去区分度。需要一种可自动、持续扩展的 benchmark 构建范式。
核心矛盾：现有 benchmark 衡量的是"给定明确 spec 生成代码的能力"，而开发者真正需要的是"在模糊问题描述、具体项目上下文中解决实际问题的能力"。
本文切入点：利用 GitHub 上标记为 question/help-wanted 的 closed issue 及其多轮解决对话，自动构建可执行、可评判的多轮编程辅助 benchmark，用 User-Maintainer-Judge 三 agent 框架模拟并评估 LLM 的真实辅助能力。

方法详解¶

整体框架¶

CAB 包含两个核心组件：

(1) 自动化数据集构建流水线：GitHub 仓库收集 → Issue 过滤与结构化 → 三要素准备（Docker 环境 + 满足条件 + 用户回复参考）
(2) 环境感知多 Agent 评估系统：User Agent 提问 → Maintainer Agent（被测 LLM）在容器化环境中回答 → 对话终止后 Judge Agent 基于满足条件评判

整个流水线端到端全自动化，共执行 44,628 次 Sonnet 3.7 调用，零人工干预。

关键设计1：仓库收集与 Issue 双层过滤¶

做什么：从 GitHub 海量公开仓库中筛选有活跃社区的高质量仓库，并从中提取结构化的多轮求助对话
核心思路：定义仓库筛选条件 \(R = \{r \in \mathcal{R}_{GH} \mid s(r) > S_{\min},\; t(r) > t_0,\; \ell(r) \in \mathcal{L}\}\)，其中 \(s(r)\) 为星标数（阈值如10）、\(t(r)\) 为创建日期、\(\ell(r)\) 为许可证。进一步定义社区评分 \(CS(r) = Q(r) + H(r)\)（question + help-wanted issue 数量），选 top-N 仓库。Issue 过滤采用双层架构：第一层正则规则去除媒体内容和单人 issue；第二层 LLM 分类器评估 issue 的解决状态、技术特异性、安全性等七项指标。消息级别还用 LLM 过滤无价值评论（"+1"、"Thanks" 等）
结构化处理：将连续同角色消息合并为逻辑段，配对形成 turn 结构 \(\text{turn}_{i,k} = (m_{i,k}^{\text{author}}, m_{i,k}^{\text{maintainer}})\)
设计动机：双层过滤在保持全自动化的同时确保数据质量——正则快速去噪，LLM 精准判断语义质量

关键设计2：数据准备三要素¶

做什么：为每个过滤后的 issue 准备可执行环境、评判标准和用户模拟参考
Docker 环境生成：用 Sonnet 3.7 分析仓库 artifacts（README、Dockerfile、GitHub workflows、文件结构），在 issue 创建时间最近的 commit \(sha_i\) 上自动生成并测试 Docker 构建脚本，直到找到成功配置
满足条件提取：用 LLM 从完整对话中提取具体的解决标准集合 \(s_i = \{s_{i,1}, \ldots, s_{i,K}\}\)，作为客观评估依据。人工验证 86.3% 精确率、65.7% 完整率
用户回复参考：在历史维护者-用户消息对上构建 BM25 索引，为每个 issue 检索 top-N 相似交互作为模拟用户行为的参考
设计动机：三管齐下让每个 benchmark 实例具备可执行性（Docker）、可评判性（满足条件）和可模拟性（参考回复）

关键设计3：三角色多 Agent 评估框架¶

做什么：模拟真实的开发者-维护者求助交互，系统评估 LLM 的项目级辅助能力
User Agent：以 GitHub issue 发起编程问题，根据满足条件评估模型回复，提供现实的后续澄清或追问，检测到 issue 解决时发出终止信号。观察执行结果但不直接操作环境
Maintainer Agent（被测模型）：在容器化环境中分析问题、执行命令、生成回复、根据用户反馈调整策略
Judge Agent：对话结束后（用户满意或达到 10 轮上限），从三个维度评判——技术正确性、满足条件完整性、交互质量。有 Docker 环境的 issue 将执行成功作为硬性要求
设计动机：比单轮正确性评估更全面地捕捉 LLM 在多轮交互中的推理能力、上下文理解和沟通质量

训练/评估策略¶

采用分层采样避免计算瓶颈：每种语言最多 5 个 Docker issue + 每个 turn 长度桶（1/2/3/4/5+）10 个 issue，不足的桶向前分配
最终评估集：All-Time 350 个 + Recent 194 个
两个仓库群组：All-Time（无时间限制的 700 个高星仓库）和 Recent（2024-11-01 后创建的 3,500 个仓库），后者用于检测模型对训练截止后知识的泛化能力

实验关键数据¶

模型正确率与对话轮数¶

模型	Recent 正确率	All-Time 正确率	Recent 错误率	正确时平均轮数	错误时平均轮数
ChatGPT 4.1 Mini	16.49%	29.14%	53.09%	2.94 / 2.35	5.70 / 4.28
DeepSeek R1	11.34%	27.14%	55.15%	2.82 / 2.24	4.50 / 4.28
Sonnet 3.7 (Think)	13.40%	27.43%	59.28%	2.50 / 2.20	4.95 / 4.26
Sonnet 3.7	11.34%	25.71%	57.73%	2.36 / 2.30	5.71 / 4.21
Llama 3.3 70B	9.33%	13.58%	64.77%	3.22 / 2.68	4.67 / 4.50
Haiku 3.5	7.22%	16.86%	61.86%	3.86 / 2.73	6.76 / 5.63

轮数格式：Recent / All-Time。正确回答平均 2-3 轮（接近真实 GitHub 对话），错误回答多 1-2 轮。

数据集构建统计¶

指标	数值
原始 GitHub Issues	25,656
过滤后 Issues	3,342
最终保留 Issues	3,286（56 个因 Docker 构建失败排除）
贡献仓库数	214 / 770（通过过滤的仓库）
编程语言	7 (Python, Java, C++, C#, JS, TS, C)
成功 Docker 构建	238 (Recent 97.6% vs All-Time 78.2%)
LLM 调用次数	44,628 (Sonnet 3.7，全自动零人工)

关键发现¶

性能鸿沟惊人：模型在 StackOverflow 式问题上达 70-83% 准确率，但在 CAB 的 Recent 仓库上仅 7-16%。ChatGPT 4.1 Mini 最佳（16.49%），Haiku 3.5 最低（7.22%）
时间性差距显著：Recent 比 All-Time 普遍低 10-15 个百分点。合成消融实验表明，这主要源于 post-cutoff 的框架/API 变化而非 AI 生成代码的特性（合成仓库上 Sonnet 3.7 达 74% vs 真实 Recent 仅 11.34%）
语言差异明显：静态类型语言（C#、C++、Java）在 Recent 集上正确率普遍 <13%，动态语言（JS、Python）相对较好但仍很低
冗余倾向：40-60% 的回复被判定为冗余（Verbose），Sonnet 3.7 Think 最均衡，Haiku 3.5 和 Llama 3.3 最冗余
人工评估验证：Judge 与人类一致率 65.92%（人类间一致率 78.28% 的 84.2%，Cohen's κ=0.68）；满足条件精确率 86.3%、完整率 65.7%

亮点与洞察¶

全自动化 Benchmark 构建范式：从仓库收集到 Docker 环境构建到评估判定，全链条自动化（44,628 次 LLM 调用零人工），可持续更新跟踪模型进步。这不仅是一个 benchmark，更是一套 benchmark 建设方法论
执行验证 > 文本评估：Docker 容器化让评估不仅判断"说得对不对"还检验"做得对不对"——有 Docker 的 issue 必须实际执行成功，比纯文本匹配更严格可靠
满足条件提取的精巧设计：从原始 issue 解决对话中自动提取多条具体满足条件（而非二元正确/错误），既支持 partial credit 又提供细粒度的失败诊断
揭示了 LLM "知识幻觉"的新维度：模型不是不懂编程，而是不懂"这个项目"——在合成仓库上达 74% 而真实 Recent 仓库仅 11%，说明项目上下文理解是核心瓶颈

局限性 / 可改进方向¶

满足条件提取偏保守——精确率 86.3% 但完整率仅 65.7%，可能漏掉解决 issue 的关键条件，导致评估偏宽松
用户模拟基于模板 + BM25 检索，无法完全模拟真人开发者的复杂追问策略和情绪变化
仅覆盖 7 种语言，缺少 Rust、Go、Kotlin 等日益流行的语言
Judge LLM 与人类一致率 65.92%（在多轮场景下），比单轮评估更具挑战性
Docker 环境构建成功率在 All-Time 仓库上仅 78.2%，部分包含 Docker 需求的 issue 被排除
评估样本经过分层采样（544/3286），未涵盖所有 issue

评分¶

新颖性: ⭐⭐⭐⭐⭐ 第一个多轮项目级编程辅助 benchmark，全自动化流水线设计具有开创性
实验充分度: ⭐⭐⭐⭐ 6 个 SOTA 模型、7 种语言、合成消融、人工评估三重验证，较全面
写作质量: ⭐⭐⭐⭐ 逻辑清晰、体系完整，附录极其详尽（含所有 prompt 模板和人工标注协议）
价值: ⭐⭐⭐⭐⭐ 揭示 LLM 编程辅助的真实能力边界（项目上下文理解是核心瓶颈），对 coding agent 研发有重要指导意义