syntaxsynth/swe-bench-opus-logs

该数据集是一个问答任务数据集，专注于代码相关问题。数据集大小介于1K到10K之间，包含两个主要设置：Oracle检索和BM25检索。每个设置都有对应的测试数据文件，且每个子集包含一个额外的`log_last_line`属性，记录评估步骤中生成的日志文件的最后一行。数据集提供了不同模型在两种检索方法下的问题解决率，并存储了完整的日志文件供进一步分析。

原始信息汇总

数据集概述

任务类别

• 问答（question-answering）

标签

• 代码（code）

数据集大小

• 1K<n<10K

配置详情

• 配置名称: opus-20240229-oracle-full

  • 数据文件:
    • 分割: 测试
    • 路径: claude-3-opus-20240229__SWE-bench_oracle__test.jsonl

• 配置名称: opus-20240229-bm25-50k

  • 数据文件:
    • 分割: 测试
    • 路径: claude-3-opus-20240229__SWE-bench_bm25_50k_llama__test.jsonl

数据集内容

• 包含SWE-bench在两种设置下的提示响应：
  • Oracle检索
  • BM25检索
• 每个子集包含一个额外的log_last_line属性，记录评估步骤中生成的日志文件的最后一行。

结果

模型	BM25检索解决率(%)	Oracle检索解决率(%)
GPT-4*	0	1.74
Claude-2	1.96	4.80
Claude-3 Opus (20240229)	3.24	6.42

搜集汇总

数据集介绍

构建方式

该数据集源自SWE-bench评估框架，旨在系统性地评测大型语言模型在真实GitHub问题解决场景中的表现。构建过程基于Claude 3 Opus模型（20240229版本）在两种检索策略下的推理日志：Oracle检索（提供精确上下文）与BM25检索（基于关键词的稀疏检索）。每条数据保留了推理过程中的完整日志，并额外提取了评估阶段的最后一行输出作为关键属性，从而形成结构化的问答对集合。数据集分为两个配置，分别对应上述两种检索方式，并以JSONL格式存储，便于高效读取与处理。

特点

数据集的核心特色在于其双重检索对比机制，能够深入剖析模型在不同信息获取条件下的表现差异。相较于GPT-4与Claude-2，Claude 3 Opus在Oracle检索下达到6.42%的解决率，在BM25检索下为3.24%，均展现出显著优势。此外，每条样本均包含完整的日志文件路径与最后一行输出，为错误分析与归因提供了详实的原始素材。这种设计不仅支持宏观性能比较，更允许研究者深入挖掘模型在具体问题上的推理过程与失败模式。

使用方法

使用者可通过HuggingFace的datasets库便捷加载数据，指定配置名称（如opus-20240229-oracle-full或opus-20240229-bm25-50k）即可获取对应检索策略下的测试集。每条样本包含模型输入、输出及日志关键信息，适用于评估语言模型的代码修复能力、比较不同检索策略的影响，或作为微调数据集的验证基准。推荐结合SWE-bench官方评估脚本，以标准化指标衡量模型性能，同时利用日志字段进行深入的错误分析与行为研究。

背景与挑战

背景概述

该数据集由SyntaxSynth团队于2024年发布，旨在评估大型语言模型（LLM）在真实软件工程任务中的能力，特别是解决GitHub问题（issue）的自动化程度。其核心研究问题聚焦于模型能否通过检索相关代码上下文并生成补丁来解决实际代码库中的缺陷或功能请求。数据集基于SWE-bench基准测试，由普林斯顿大学等机构的研究人员提出（Jimenez等人，2023），其影响力在于推动了LLM在代码修复和自动化编程领域的量化评估。通过引入Oracle检索（精确上下文）和BM25检索（稀疏检索）两种设置，该数据集为研究检索策略对模型性能的影响提供了关键资源，尤其Claude-3 Opus模型在Oracle检索下达到6.42%的解决率，显著优于GPT-4和Claude-2，凸显了当前模型在复杂软件维护中的潜力与局限。

当前挑战

该数据集面临的核心挑战在于LLM对真实世界软件工程问题的解决能力仍十分有限，例如在BM25检索设置下，最佳模型Claude-3 Opus仅解决3.24%的问题，远低于人类专家水平，反映出模型在理解复杂代码库、跨文件依赖及精确补丁生成上的根本性不足。构建过程中，数据集的挑战包括：1) 从GitHub Issue中筛选可复现且具有明确解决方案的问题，需人工验证避免模糊或不可测试的案例；2) 设计Oracle和BM25检索机制时，需平衡上下文相关性与噪声干扰，以确保评估的公平性；3) 记录完整执行日志（如`log_last_line`属性）以追溯错误原因，但日志解析和错误分类仍需大量手工分析。这些挑战限制了数据集的规模扩展和跨领域泛化，也揭示了当前LLM在软件工程自动化中从“辅助”到“自主”的鸿沟。

常用场景

经典使用场景

在软件工程与人工智能的交叉领域中，syntaxsynth/swe-bench-opus-logs数据集为评估大型语言模型在真实世界代码修复任务中的表现提供了标准化基准。该数据集基于SWE-bench框架，收录了Claude-3 Opus模型在Oracle检索与BM25检索两种设置下的推理日志与结果，典型应用于评测模型从GitHub issue到代码补丁生成的端到端能力。研究者常利用该数据集对比不同检索策略对模型修复效率的影响，或分析模型在复杂代码库中定位缺陷的准确性，从而推动智能编程助手的性能优化。

解决学术问题

该数据集系统性地回应了学术界关于‘语言模型能否自主解决真实软件缺陷’的核心疑问。通过提供Oracle检索（理想信息获取）与BM25检索（实际信息检索）的对比数据，它揭示了模型在信息完备与受限条件下的性能差异，量化了检索质量对修复成功率的贡献。研究指出，Claude-3 Opus在Oracle设置下达到6.42%的解决率，显著高于GPT-4的1.74%，这为理解模型推理能力与代码理解的边界提供了实证依据，并激励后续工作探索更优的上下文检索机制。

衍生相关工作

该数据集衍生了一系列探索语言模型代码修复能力的经典工作。SWE-bench原始论文（Jimenez et al., 2023）通过此数据集建立了首个多模型对比基线，激励了后续如‘Agent-based Repair’（基于代理的修复）与‘Retrieval-Augmented Code Generation’（检索增强代码生成）等研究方向。相关研究进一步利用该日志数据，分析模型在‘log_last_line’属性中暴露的运行时错误模式，从而提出分层修复策略或动态上下文筛选方法，显著推动了自动化软件工程领域从理论到实践的演进。