exp_rle_github_issue-v3

exp_rle_github_issue-v3数据集是laion/exp_rle_github_issue-v2数据集的过滤版本，专门设计用于提高编程任务的可运行性和解决率。该数据集针对文本生成任务，包含264个经过筛选的编程任务实例（从原始v2版本的739个任务中保留35.7%），每个任务包含path（字符串类型）和task_binary（gzipped压缩的任务目录）两个字段。过滤过程基于对v2版本200次试验的重新评估，识别并移除了五类无法正常运行的任务：缺失测试夹具（311个）、损坏的子属性引用（116个）、从tests模块导入问题（36个）、模块级importorskip调用（9个）以及模块级环境/路径操作（2个）。经过过滤后，预计解决率从7.0%提升至20.3%，提升了3倍。该数据集适用于代码生成、程序合成和自动化测试等任务的研究与评估。

原始信息汇总

数据集概述：exp_rle_github_issue-v3

基本信息

• 许可证: Apache-2.0
• 任务类别: 文本生成
• 语言: 英语
• 数据集地址: https://huggingface.co/datasets/laion/exp_rle_github_issue-v3

数据集说明

• 该数据集是 exp_rle_github_issue-v2 的过滤版本。
• 过滤旨在提升任务可运行性，基于对 v2 版本进行 200 次试验的重新分类结果。

过滤背景

• 对 v2 的 200 次试验重新分类显示，在基础设施完全正常的情况下，解决率为 7.0%（14/200）。
• 故障分解发现了五类 v2 修补程序未能处理的不可运行任务：

1. 缺失 fixtures（占 186 个失败中的 84 个）：测试函数引用了 fixtures（如 testdir、client、app、tz_naive_fixture 等），但任务未附带 conftest.py，运行时导致 fixture-not-found 错误。
2. 损坏的子属性（38 个）：测试导入已删除的已白名单包 API，例如 from pandas.compat import lrange、from pandas import Float64Index、pydantic.datetime_parse、pandas.util._test_decorators.skip_if_*、httpx.HTTPProxy 等。
3. from tests.X import Y（7 个）：任务未附带同级的 tests/ 包，仅存在 test_solution.py 模块于 /tests 目录下。
4. 模块级 pytest.importorskip(...)（2 个）：测试在外部依赖缺失时标记为 1 skipped，验证器也会将结果标记为 reward=1。
5. 模块级 os.chdir(...)、os.environ[KEY]、ctypes.CDLL(...)（3 个）：路径或密钥在沙箱环境中不存在。

数据统计

• v2 至 v3 的筛选结果：从 739 个任务降至 264 个任务（保留率为 35.7%）。
• 预计解决率（基于 200 次试验验证）：从 7.0% 提升至 20.3%（提升约 3 倍）。
• 各类原因导致的剔除数量（全数据集）：
  • 缺失 fixtures: 311
  • 损坏的子属性: 116
  • 来自 tests 的导入: 36
  • 模块级 importorskip: 9
  • 模块级环境/ctypes: 2

数据模式

• 与 v2 相同：包含 path（字符串）和 task_binary（任务目录的 gzip 压缩 tar 包）两个字段。

过滤来源

• 过滤代码位于 OpenThoughts-Agent 项目的 data/patchers/patch_exp_rle_github_issue_tasks.py 中（可重入标识：.patcher_marker_exp_rle_github_issue_v3）。

搜集汇总

数据集介绍

构建方式

该数据集源自laion/exp_rle_github_issue-v2，通过精细化的二次筛选构建而成。研究者基于对200个样本的重新评估，识别出原版本中未被捕获的五类不可执行任务漏洞，包括缺失测试固件、损坏的子属性导入、从tests模块的错误引用、模块级条件跳过以及环境依赖问题。针对每一类失败模式，项目开发了专门的修补程序，从原数据集739个任务中剔除475个不可运行样本，最终保留264个高质量任务，构建效率提升三倍。

使用方法

该数据集适用于文本生成任务的微调与评估。使用时可直接加载task_binary字段中的gzip压缩包，解压后获得包含完整测试框架的任务目录。用户需注意验证环境需预先安装pytest及相关依赖库，并确保运行目录包含必要的conftest.py固件配置。为确保结果可复现，建议使用数据源提供的最新补丁版本，并遵循数据集附带的Apache-2.0开源许可协议。

背景与挑战

背景概述

在机器学习与自然语言处理领域，数据集的构建对于模型训练与评估至关重要。由LAION机构主导创建的exp_rle_github_issue-v3数据集，其前身v2版本发布于2026年，旨在解决代码自动生成任务中可执行性验证的难题。该数据集聚焦于GitHub Issue场景下的代码生成问题，核心研究问题在于如何筛选出真正可运行的测试任务，以提升模型在真实环境中的表现。经过对v2版本200次试错的细致回溯分析，研究人员发现仅有7.0%的任务在基础设施完全正常的情况下能够成功执行，这一低解决率凸显了现有数据集过滤机制的不足，进而催生了v3版本的诞生。该数据集通过对不可执行任务的系统性分类与剔除，为代码生成模型的鲁棒性评估提供了更可靠的基准，对推动自动化编码技术的发展具有重要影响力。

当前挑战

该数据集构建面临的核心挑战首先源于领域问题的复杂性：GitHub Issue中的代码任务往往依赖特定执行环境，但现有数据集缺乏对运行时可执行性的严格保障，导致模型生成的代码在实际测试中频繁失败，准确率极低。具体而言，v2版本中高达65%的失败由缺少测试固件（如conftest.py文件）引发，其次为已移除的子属性引用（占20%），以及从tests模块的跨包导入问题等。构建过程中的挑战则体现在对不可运行任务的精细分类与过滤上，例如需要识别模块级别的importorskip语句和环境依赖调用，这要求构建算法具备对Python测试框架及包依赖的深度理解。最终v3版本仅保留了35.7%的原始任务，通过删除大量噪声样本，将验证集解决率提升至20.3%，实现了三倍的增长，但如何进一步缩小剩余任务与实际编码场景间的差距仍是持续难题。

常用场景

经典使用场景

在软件工程与人工智能的交叉研究领域，exp_rle_github_issue-v3 数据集为自动化代码修复任务提供了精心筛选的评测基准。该数据集源自GitHub issues生态，聚焦于可复现、可执行的编程挑战，其核心价值在于构建了一个经过严格过滤的测试用例集合，确保每个任务都具备在隔离沙箱中成功运行的能力。通过剔除因缺失fixture、损坏子属性、跨包导入错误等外部依赖导致的不可运行样本，该数据集使研究者能够专注于评估模型对代码逻辑本身的修复能力，而非被环境配置问题所干扰。作为text-generation任务的标准数据集，它常被用于训练和评测大型语言模型在程序合成、缺陷定位与自动补丁生成等方面的表现。

解决学术问题

该数据集直面自动化程序修复领域的核心学术痛点：现有基准数据集普遍存在大量不可运行或虚假通过的测试样例，严重削弱了评估结果的可靠性。exp_rle_github_issue-v3 通过引入多轮细粒度过滤机制，系统性解决了五个关键问题——缺失测试夹具、损坏的子属性依赖、模块级导入路径错误、以及因外部软件包缺失导致的逃逸性误判。这使得评测的一致性和可信度提升了近三倍（从7%的求解率跃升至20.3%），为学术界提供了一个干净、可复现的标准化测试平台。其意义在于重塑了程序修复研究的评估范式，使模型性能的横向比较更具科学意义，并推动该领域从“能跑通”朝“真修复”的方向演进。

实际应用

在实际应用层面，该数据集为软件开发工具链的智能化升级提供了关键支撑。基于该数据集训练的代码修复模型可以集成到持续集成/持续交付（CI/CD）流水线中，自动处理开发者提交的GitHub issue中描述的缺陷，极大缩短从问题发现到补丁合并的周期。例如，当项目依赖更新导致API不兼容时，模型能够根据数据集中的模式学习如何适配新的接口签名。此外，该数据集还适用于教育场景中的编程训练辅助系统，通过提供典型故障模式与修复方案的对应关系，帮助程序员理解常见错误类型及其解决策略，提升代码审查的效率和质量。

数据集最近研究

最新研究方向

在软件工程与人工智能交叉领域，数据集的质量与任务可复现性是衡量代码生成模型实际效用的关键标尺。exp_rle_github_issue-v3作为经过精细筛选的GitHub Issue补丁执行数据集，代表了前沿研究中对真实软件缺陷修复任务进行严格约束与验证的最新努力。该版本针对前序数据集中突出的测试固件缺失、废弃API引用、模块导入路径错误及环境依赖隐式跳过等五类不可运行问题，通过针对性过滤机制，将任务集从739个精简至264个，同时将可解决率从7.0%大幅提升至20.3%，实现近三倍的跃升。这一工作在数据集层面揭示了以往基于文本匹配或简单语法检查的筛选方法在动态执行环境中的巨大局限性，推动社区从“语法与静态上下文”向“实际运行与依赖完备性”转变，为构建更鲁棒、更真实的自动化编程评估基准提供了重要参照。