技术速递｜通过全新开放数据集，加速研究人员和开发者构建多语言 AI
作者：Kevin Xu
排版：Alan Wang
一项全新的仓库级数据集现已在 GitHub 上以 CC0-1.0 协议开放发布，帮助研究人员和开发者从 README、Issue 和 Pull Request 中发现丰富的多语言开发者内容，为构建和训练多语言 AI 提供高质量的数据支持。
软件可以使用编程语言编写，但自然语言才是开发者协作的核心。开发者会在 README 中介绍项目如何使用，在 Issue 中寻求帮助，在 Pull Request 中审查、讨论并改进代码。这种协作通常使用英语进行，但并非总是如此。随着 AI 日益成为软件开发的重要组成部分，多语言开发者内容的重要性也愈发凸显。
GitHub 正式发布GitHub Multilingual Repositories Dataset（GitHub 多语言仓库数据集）。这是一个仓库级元数据数据集，旨在帮助研究人员和开发者发现那些包含非英语自然语言内容的公开 GitHub 仓库。在构建该数据集的过程中，我们发现，不同类型开发者内容中的语言分布存在明显差异：在 Issue 文本中，韩语是最常见的非英语语言；而在 README 中，韩语仅排名第五。相比之下，葡萄牙语则位居非英语 README 榜首，覆盖超过 300 万个仓库。
该数据集现已在 GitHub 上以 CC0-1.0 协议开放发布。这也是 GitHub 对 2025 年所作承诺的进一步落实——作为微软欧洲数字承诺（European Digital Commitments）的一部分，GitHub 致力于让多语言数据更加开放、更加易于获取，包括为开源 AI 开发者提供支持。
数据集包含哪些内容
GitHub 多语言仓库数据集并非直接提供仓库内容的完整副本，而是一个元数据数据集，旨在帮助开发者和研究人员发现可能存在多语言协作的 GitHub 仓库。该数据集涵盖了超过 4,000 万个公开仓库，包含8,000 多万条语言分类记录。对于每一个公开仓库，数据集提供以下信息：
README、评论数最多的 Issue，以及评论数最多的 Pull Request 的语言分类结果。语言识别基于每段文本的前 150 个字符进行分析，长度不足 20 个字符的文本将被排除。
来自三种语言识别工具的分类结果：fastText、gcld3 和 lingua-py，并附带各自的置信度评分。数据集中仅保留置信度大于 0.5 的分类结果。
仓库元数据，包括：创建时间、磁盘占用大小、Star 数、Fork 数、主要编程语言、SPDX 开源许可证、Issue 和 Pull Request 数量，以及数据快照日期。
我们有意没有将这三种语言分类器的结果合并为一个最终标签。原因在于，不同分类器在不同语言上的覆盖范围和置信度校准存在差异，尤其是在低资源语言上的表现更为明显。因此，我们将三种分类结果全部公开，由研究人员和开发者根据自己的需求选择使用方式。例如：
如果你希望获得一个高精度的希腊语仓库子集，可以要求三种分类器在超过某个置信度阈值的情况下全部达成一致。
如果你只是想对罗曼语系进行探索性研究，更关注覆盖率而非绝对准确率，那么仅采用其中一种分类器的结果可能就已经足够。
可以利用数据集构建什么
该数据集专为那些难以通过通用网页文本完成的研究和应用场景而设计，例如：
发现特定语言的开发者仓库，快速定位包含特定语言开发文档或多语言协作内容的 GitHub 仓库。
研究非英语开发者社区的协作方式，分析不同语言社区如何使用 Issue、Pull Request 和 README 进行交流与协作。
构建 AI 开发工具的评测数据集，为 AI 编程助手、文档生成工具、代码审查助手等提供跨语言评测基准，帮助这些工具在不同语言环境下实现更好的表现。
为开发者工具和 AI 功能扩展语言支持提供数据依据，借助数据集中展现出的开发者社区丰富的多语言分布，帮助决策者以数据驱动的方式推进更多语言的支持。
衡量开源生态中的语言代表性，评估欧洲语言及其他代表性不足语言在开源社区中的覆盖情况和发展现状。
一些需要注意的事项
语言识别并非易事，尤其是在软件仓库中更是如此。仓库中的文本通常较短，可能包含徽章、模板、安装命令、代码片段、用户名，或多种语言混杂的内容。此外，仅使用前 150 个字符作为分析样本，也未必能够代表整个仓库的语言特征。不同语言识别模型在覆盖范围和置信度校准方面也存在差异，尤其是在低资源语言上的表现更为明显。
因此，这一数据集不应被视为语言识别的“标准答案”或权威基准。相反，它更适合作为一个透明的发现工具。用户可以结合语言分类结果、置信度评分以及分类来源，自主选择适合自身研究或开发场景的准确率与召回率之间的权衡。
此外，该数据集不应用于推断仓库所有者、贡献者或开发者社区的任何敏感属性。数据集提供的是仓库层面的元数据信号，而非针对个人层面的属性信息。
为什么开放多语言数据如此重要
如今，许多欧洲语言在用于构建和评估 AI 系统的在线文本中仍然代表性不足。这意味着 AI 工具可能对某些开发者、语言和社区表现出色，却无法很好地服务于其他群体。开放数据能够帮助缩小这一差距。我们构建这一数据集，是因为开发者内容与通用网页文本有着本质区别。README、Issue 和 Pull Request 中包含的是软件协作的真实语言，例如安装说明、缺陷报告、功能请求、代码审查意见以及社区协作规范。这些内容能够帮助 AI 系统更准确地理解开发者的实际工作方式，而不仅仅是理解自然语言本身。
通过让多语言开发者内容的相关信号更容易被发现和分析，这一数据集为研究人员、开源开发者以及模型构建者提供了新的工具，用于研究软件开发领域中的语言覆盖情况。它能够帮助识别语言支持上的空白、提升 AI 系统的评测质量，并推动构建更加包容、更好服务于欧洲及全球开发者的 AI 工具。这也体现了一个更广泛的理念：面向开发者构建 AI，不仅要关注代码，更要关注开发者真正使用的语言、社区以及协作方式。
展望未来
多语言 AI 的发展，离不开多语言开发者社区。 我们希望这一数据集能够帮助更多研究人员、开发者和社区深入研究、支持并构建面向多语言开发者的 AI 能力。通过以 CC0-1.0 协议在 GitHub 上开放发布这一数据集，我们诚邀研究人员、开源项目维护者以及 AI 模型开发者积极使用、评估、改进和扩展它，并基于此构建更多评测数据集和开发工具。
如果你基于这一数据集开展了有趣的研究或构建了创新应用，我们也非常期待与你分享和交流。