48万条GitHub Issue三分类数据集 软件开发缺陷与需求识别 自然语言处理与机器学习训练资源

# 48万条GitHub Issue三分类数据集 软件开发缺陷与需求识别 自然语言处理与机器学习训练资源

## 引言与背景

在当今软件开发领域，GitHub作为全球最大的开源代码托管平台，每天产生大量的Issue反馈数据。这些Issue涵盖了Bug报告、功能请求以及其他类型的讨论，是软件工程研究与智能运维系统开发的宝贵数据资源。然而，海量的Issue数据也给项目维护者带来了严峻的挑战——如何快速、准确地对新提交的Issue进行自动分类，从而实现工单的智能分派与优先级排序，已成为提升软件开发协作效率的关键问题。

本数据集源自Kaggle举办的Embold竞赛，汇集了来自真实开源项目的GitHub Issue数据，共计48万条记录。其中，训练集部分包含45万条已标注数据（embold_train.json的15万条与embold_train_extra.json的30万条），测试集部分包含3万条待预测数据（embold_test.json）。每条记录均包含Issue标题（title）与正文描述（body）两个核心文本字段，已标注数据还提供三分类标签（label）。数据集的标签体系采用业界通用的Issue分类标准：标签0代表Bug报告（bug report），标签1代表功能请求（feature request），标签2代表其他类型（other，如使用咨询、技术讨论等）。

该数据集的建设具有重要的研究价值与应用价值。在学术研究层面，它为自然语言处理（NLP）领域的文本分类算法、预训练语言模型（如BERT、RoBERTa）的微调优化、以及软件工程中的自动化工单处理研究提供了大规模、高质量的实证基础。在产业应用层面，基于该数据训练的分类模型可直接部署于企业内部的工单系统、开源项目的Issue管理机器人、以及智能运维平台中，实现Issue的自动分类、路由与优先级评估，显著降低人工成本，提升项目响应效率。

## 数据基本信息

### 数据规模与构成

本数据集由三个JSON格式文件构成，总数据规模达48万条记录，具体分布如下：

| 数据集文件 | 记录数量 | 数据字段 | 文件大小 | 用途说明 |
|---|---|---|---|---|
| embold_train.json | 150,000 | title, body, label | 93.7 MB | 核心训练集 |
| embold_train_extra.json | 300,000 | title, body, label | 186.6 MB | 扩展训练集 |
| embold_test.json | 30,000 | title, body | 18.4 MB | 测试集（无标签） |
| 合计 | 480,000 | — | 298.7 MB | — |

### 数据字段说明

| 字段名称 | 字段类型 | 字段含义 | 数据示例 | 完整性 |
|---|---|---|---|---|
| title | String | GitHub Issue的标题文本，简要描述问题或需求 | "buggy behavior in selection" | 100%完整，无缺失 |
| body | String | GitHub Issue的正文详细描述，包含复现步骤、预期行为、代码片段等 | "Expected behavior: alarm actions PID on and PID off should enable/disable hardware PID..." | 100%完整，无缺失 |
| label | Integer | 分类标签，取值为0（Bug）、1（功能请求）、2（其他） | 0 | 标注数据100%完整 |
| label（测试集） | — | 测试集无此字段，需由模型预测 | — | 不适用 |

### 标签分布情况

基于全量45万条标注数据分析，数据集的三类标签分布如下：

| 标签编号 | 标签含义 | 记录数量 | 占比 | 累计占比 |
|---|---|---|---|---|
| 1 | 功能请求（Feature Request） | 207,318 | 46.07% | 46.07% |
| 0 | Bug报告（Bug Report） | 200,481 | 44.55% | 90.62% |
| 2 | 其他类型（Other） | 42,201 | 9.38% | 100.00% |

标签分布呈现出功能请求与Bug报告两大类别相对均衡、其他类型占比较低的特点。这种分布特征对于分类模型的训练是有利的——两大主要类别的样本量充足且比例接近，有利于模型学习到稳定的判别特征；而"其他"类虽然样本量较少，但仍具有足够的数据多样性以支持模型学习其特征边界。

### 正文长度分布情况

基于全量数据分析，Issue正文的文本长度（字符数）分布情况如下：

| 正文长度区间 | 记录数量 | 占比 | 累计占比 |
|---|---|---|---|
| 0-50字符 | 14,756 | 3.28% | 3.28% |
| 50-100字符 | 53,639 | 11.92% | 15.20% |
| 100-200字符 | 94,229 | 20.94% | 36.14% |
| 200-500字符 | 145,807 | 32.40% | 68.54% |
| 500-1000字符 | 79,723 | 17.72% | 86.26% |
| 1000-2000字符 | 41,105 | 9.13% | 95.39% |
| 2000-5000字符 | 18,126 | 4.03% | 99.42% |
| 5000字符以上 | 2,615 | 0.58% | 100.00% |

正文长度的中位数区间为200-500字符，该区间集中了近三分之一的记录。数据同时覆盖了极短文本（最短仅9字符）与超长文本（最长达126,372字符），展现出丰富的文本多样性。不同标签类别的正文长度特征也有所差异：标签2（其他类型）的平均正文长度最长（723.6字符），标签0（Bug报告）次之（701.8字符），标签1（功能请求）最短（381.3字符）。这一特征符合直觉——Bug报告通常包含详细的复现步骤与日志信息，而功能请求往往表达更为简洁。

### 文本特征分布

| 特征类型 | 说明 | 记录数量 | 占比 |
|---|---|---|---|
| 包含URL链接 | 正文含外部链接（如日志附件、参考文档） | 144,697 | 32.15% |
| 包含图片引用 | 正文含GitHub图片引用链接 | 40,661 | 9.04% |
| 标题平均长度 | 标题字符数均值 | — | 45.3字符 |
| 正文平均长度 | 正文字符数均值 | — | 556.2字符 |
| 主要语言 | 英文 | 全部记录 | ~100% |

### 各类别高频关键词

通过对各标签类别Issue标题的高频词汇分析，可以窥见不同类别Issue的语义特征：

| 排名 | 词汇 | 出现次数 | 语义特征 |
|---|---|---|---|
| 1 | error | 13,437 | 错误提示相关 |
| 2 | bug | 6,230 | 明确提及缺陷 |
| 3 | fails | 4,989 | 功能失效描述 |
| 4 | broken | 4,008 | 功能异常状态 |
| 5 | wrong | 3,962 | 不正确行为 |
| 6 | missing | 3,780 | 缺失功能或数据 |
| 7 | cannot | 3,708 | 无法执行操作 |
| 8 | fix | 4,814 | 修复诉求 |

| 排名 | 词汇 | 出现次数 | 语义特征 |
|---|---|---|---|
| 1 | support | 13,606 | 请求支持新功能 |
| 2 | create | 6,570 | 新建功能需求 |
| 3 | allow | 5,518 | 请求开放操作 |
| 4 | feature | 5,468 | 明确功能请求 |
| 5 | request | 5,108 | 请求标识 |
| 6 | implement | 4,638 | 请求实现 |
| 7 | update | 4,544 | 请求更新 |
| 8 | option | 4,008 | 请求选项 |

| 排名 | 词汇 | 出现次数 | 语义特征 |
|---|---|---|---|
| 1 | how | 3,993 | 使用咨询 |
| 2 | question | 1,756 | 明确提问 |
| 3 | what | 824 | 信息询问 |
| 4 | data | 931 | 数据相关讨论 |
| 5 | api | 673 | 接口讨论 |

## 数据优势

| 优势特征 | 具体表现 | 应用价值 |
|---|---|---|
| 大规模高质量标注 | 45万条已标注数据，三分类体系清晰，无缺失值 | 支持深度学习模型训练，避免小样本导致的过拟合问题 |
| 真实场景数据 | 数据来自真实开源项目的GitHub Issue，非人工构造 | 模型学习到的特征更贴近实际应用场景，部署效果更佳 |
| 丰富文本多样性 | 正文长度跨度大（9字符至12.6万字符），含URL、图片、代码等多种元素 | 训练出的模型具备强泛化能力，适应不同长度与格式的输入 |
| 类别均衡分布 | Bug与功能请求两大类别占比分别为44.55%和46.07%，相对均衡 | 减少模型偏置，提升分类精度，避免对少数类的预测偏差 |
| 语义特征明确 | 各类别高频词汇特征显著（Bug类含error/fails，功能类含support/feature） | 便于模型有效捕捉类别间的语义差异，提升分类可解释性 |
| 完整数据闭环 | 提供训练集（含标签）与测试集（待预测），支持竞赛评估流程 | 便于模型性能的标准化评估，支持横向对比研究 |
| 多模态信息丰富 | 32.15%记录含URL链接，9.04%记录含图片引用 | 支持多模态学习方法的探索，如结合截图分析的Bug识别 |
| 编程领域覆盖广 | 涉及多种编程语言与项目类型（含PHP、JavaScript、Python、Scala等代码片段） | 训练出的模型具备跨项目、跨语言的迁移能力 |

## 数据样例

以下展示数据集中具有代表性的样例，涵盖不同标签类别、文本长度、正文特征的多样性。

### 元数据与文本样例

| 字段 | 内容 |
|---|---|
| title | buggy behavior in selection |
| body | Screenshot from 2016-02-23 21 27 40，包含截图链接https://cloud.githubusercontent.com/assets/9442944/13260424/cf086b72-da74-11e5-8584-68534b3fd9a0.png |
| label | 0 |

| 字段 | 内容 |
|---|---|
| title | enable PID on / PID off alarm actions for arduino/tc4 |
| body | Expected behavior: alarm actions PID on and PID off should enable/disable hardware PID on arduino/tc4 platform. Actual behavior: PID state on arduino/tc4 does not change when alarm activates. Steps to reproduce... |
| label | 0 |

| 字段 | 内容 |
|---|---|
| title | app breaks when changing months after the actual |
| body | I can browse months from before the actual. Changing from June to July works normal. If I try to advance to September, the app freezes. Log file: https://github.com/simplemobiletools/simple-calendar/files/421272/logcat.txt |
| label | 0 |

| 字段 | 内容 |
|---|---|
| title | y-zoom piano roll |
| body | A y-zoom on the piano roll would be useful. |
| label | 1 |

| 字段 | 内容 |
|---|---|
| title | filter out noisy endpoints in logs |
| body | I think we should stop logging requests to: /__health, /__gtg, /favicon.ico |
| label | 1 |

| 字段 | 内容 |
|---|---|
| title | add the translations of v3.1.0-beta.4 |
| body | Release Electron v3.1.0-beta.4 - electron/electron https://github.com/electron/electron/releases/tag/v3.1.0-beta.4 |
| label | 1 |

| 字段 | 内容 |
|---|---|
| title | implement IAP (in-app purchase) subscription on iOS |
| body | This functionality has been stubbed on iOS since IAP launched. |
| label | 1 |

| 字段 | 内容 |
|---|---|
| title | proposal: loadTranslation to lazy load ScopeWithTranslation |
| body | PHP代码示例：public function loadTranslation() { return $this->load('translations' => function(Relation $query) { if ($this->useFallback) { $locale = $this->locale; ... } }); } |
| label | 2 |

| 字段 | 内容 |
|---|---|
| title | null or empty in JsonExporter |
| body | JSON结构定义：rows: { left: { boolArrayTest: { column: { name: boolArrayTest, ordinal_position: 16, type: 14, not_null: false, auto_increment: false... } } } } |
| label | 2 |

| 字段 | 内容 |
|---|---|
| title | CollectionProvider support pagination |
| body | It would be very helpful if support for pagination could be added. https://laravel.com/docs/5.2/pagination We'd like to be able to use Eloquent models without needing to load the full dataset from the table. |
| label | 2 |

### 测试集样例（无标签，用于模型预测）

| 字段 | 内容 |
|---|---|
| title | config question: path-specific environment variables |
| body | Issue description or question: Hey @artemgovorov! Thanks for your previous help with the module aliasing in my Lerna repo. Is there any way to... |

| 字段 | 内容 |
|---|---|
| title | crash indien vol |
| body | De simulator crasht als hij vol zit.（荷兰语：模拟器在满载时崩溃） |

| 字段 | 内容 |
|---|---|
| title | unable to mine rocks |
| body | Starting today, when I hit enter/action on a rock, my avatar freezes for about 15 seconds and then unfreezes, but the action menu never shows up and I don't get to mine any rocks. |

| 字段 | 内容 |
|---|---|
| title | not all whitelists are processed |
| body | Create following rules (order of creation is important): 1. Pattern: any, types: image, action: filter, filter url: off... |

| 字段 | 内容 |
|---|---|
| title | add ctx menu for idafree 70 and idafree 5 |
| body | Associated with .dll, .dll_, .exe, .exe_, .sc, .shellcode. |

## 应用场景

### GitHub Issue智能分类与路由系统

基于本数据集训练的分类模型可直接应用于GitHub Issue的自动化处理流程中。当新项目提交Issue时，系统可利用预训练模型对标题与正文进行实时分析，自动判断其属于Bug报告、功能请求或其他类型，并将其分派给相应的负责人或团队。例如，Bug报告可自动路由至开发团队，功能请求则提交至产品规划团队，技术咨询类问题则分派至支持团队。这种智能路由机制能够显著缩短Issue的响应时间，避免因人工分类延迟导致的问题积压。此外，结合项目历史数据，系统还可进一步预测Issue的优先级，帮助团队合理分配资源。该场景适用于大型开源项目维护、企业内部工单管理平台、以及SaaS产品的客户反馈处理系统。

### 软件开发中的自动化缺陷预测与质量保障

软件质量保障是软件工程中的核心环节。基于本数据集训练的分类模型可嵌入到CI/CD流程中，对开发过程中产生的缺陷报告进行自动识别与分类。当代码提交触发自动化测试时，系统可同步分析关联的Issue内容，自动识别潜在的Bug报告并标记优先级，帮助质量保障团队快速定位需要关注的缺陷类型。同时，通过对功能请求类Issue的趋势分析，团队可洞察用户需求变化，辅助产品规划决策。该应用场景可集成到Jenkins、GitLab CI等主流CI/CD工具链中，实现从缺陷发现到分派处理的全流程自动化，有效提升软件交付质量与效率。

### 自然语言处理模型训练与预训练研究

本数据集的45万条高质量标注数据为NLP模型的训练提供了丰富的语料资源。研究者可基于该数据集进行多种模型架构的对比实验，包括传统机器学习方法（如TF-IDF配合SVM）、深度学习模型（如TextCNN、BiLSTM）、以及预训练语言模型（如BERT、RoBERTa、DeBERTa）的微调优化。数据集的三大类别标签体系简洁明确，适合作为文本分类任务的基准数据集。此外，数据中包含的URL链接、图片引用、代码片段等多模态信息，也为多模态学习研究提供了有趣的切入点。研究者可探索结合外部知识源的分类方法，或将本数据集与其他软件工程语料结合，训练面向软件开发场景的专用预训练模型。

### 智能运维平台的工单自动化处理

在企业智能运维（AIOps）平台中，工单的自动分类与分派是提升运维效率的关键环节。基于本数据集训练的模型可应用于企业内部的运维工单系统，对来自监控告警、用户反馈、系统日志等渠道的工单进行自动分类。Bug报告类工单可自动关联至相应的技术团队并标记处理优先级，功能请求类工单则提交至产品管理流程进行需求评估，咨询类工单则自动匹配知识库中的相关文档，为用户提供自助服务选项。这种自动化处理机制能够将运维工程师从重复性的分类工作中解放出来，使其专注于更具创造性的问题解决工作，同时显著提升工单的首次响应率与处理效率。

### 开源项目管理平台的智能助手开发

开源社区的维护者面临着大量的Issue处理压力。基于本数据集的分类模型可被集成为开源项目管理平台的智能助手功能，为维护者提供实时的Issue分类建议。当新Issue提交时，助手可自动展示其预测的类别标签与置信度，维护者仅需确认或修正即可完成分类。此外，助手还可基于历史分类数据，为维护者提供标签推荐与模板建议，标准化Issue的标签体系。对于大型开源项目（如Kubernetes、TensorFlow等拥有数万Issue的项目），该功能可极大减轻维护者的工作负担，提升项目管理的规范性与效率。

### 代码审查与缺陷追溯系统

在代码审查（Code Review）过程中，本数据集训练的模型可辅助审查人员快速关联相关的历史Issue。当审查新的代码变更时，系统可自动检索相似的历史Bug报告与功能请求，帮助审查人员快速了解该变更的背景与历史上下文。同时，模型还可对代码变更的风险进行评估——若变更关联的历史Issue以Bug报告为主，则系统可标记该变更为高风险，提醒审查人员重点关注。这种智能追溯机制有助于提升代码审查的深度与质量，减少重复问题的出现，同时为新加入项目的开发者提供宝贵的上下文信息。

## 结尾

本数据集作为源自真实GitHub开源项目的大规模Issue分类数据集，以其48万条数据规模、三分类标签体系、丰富的文本多样性和真实的应用场景，为软件开发领域的自动化分类研究与应用提供了宝贵的数据资源。其核心价值在于，通过大规模真实数据的训练，使NLP模型能够精准识别软件工程场景下的Bug报告、功能请求与其他类型Issue，为从开源项目管理到企业智能运维的多个应用场景提供可靠的自动化解决方案。

数据集的标签体系清晰规范，Bug报告与功能请求两大类别分布均衡，文本内容涵盖了从简短描述到长篇技术文档的多样格式，且包含URL链接、图片引用等多模态信息，这些特征共同保证了模型训练效果的泛化能力与实际部署价值。

有需要可私信获取更多信息。