加速研究人员和开发者使用新开放数据集构建多语言AI（7分钟阅读）

# 通过新开放数据集加速研究人员和开发者构建多语言AI 来源：https://github.blog/ai-and-ml/llms/accelerating-researchers-and-developers-building-multilingual-ai-with-a-new-open-dataset 软件可能由编程语言编写，但人类语言是开发者协作的核心。开发者通过README解释项目运作方式，在问题（issues）中寻求帮助，在拉取请求（pull requests）中审查、讨论和优化代码。这种协作通常使用英语——但并非总是如此。随着AI在软件构建中扮演越来越重要的角色，多语言开发者内容变得比以往更加关键。 今天，GitHub 发布 **GitHub Multilingual Repositories Dataset**，这是一个仓库级元数据集，旨在帮助研究人员和开发者发现包含非英语自然语言内容的公开GitHub仓库。在构建该数据集时，我们发现不同语言在README、问题（issues）和拉取请求（pull requests）中的分布存在差异：韩语是问题文本中最常见的非英语语言，但在README中仅排名第五。葡萄牙语以超过300万个仓库位居非英语README语言之首。 该数据集现已可在GitHub (https://github.com/github/multilingual-repositories) 上获取，采用CC0-1.0协议。这是对我们在2025年作为Microsoft's European Digital Commitments (https://blogs.microsoft.com/on-the-issues/2025/07/20/eudigitalunlock/) 一部分所做出承诺的落实——让多语言数据（包括对开源AI开发者）更加可及。 ## 数据集内容 GitHub Multilingual Repositories Dataset 有意不包含仓库内容的原始转储。相反，它是一个元数据集，帮助开发者和研究人员发现可能存在多语言协作的仓库。该数据集覆盖 **超过4000万个仓库的8000多万条分类记录**。对于每个公开仓库，我们提供： - 对README、评论最多的问题（issue）和评论最多的拉取请求（pull request）的语言分类，每个分类使用前150个字符作为输入样本。我们排除了少于20个字符的文本。 - 每个文本来源的分类结果来自 fastText (https://fasttext.cc/)、gcld3 (https://github.com/google/cld3) 和 lingua-py (https://github.com/pemistahl/lingua-py)，每个都附有置信度分数。数据集仅包含置信度 >0.5 的分类。 - 仓库元数据：创建时间戳、磁盘使用量、星标、复刻数、主要编程语言、SPDX许可证、问题和拉取请求数量以及快照日期。 我们有意没有将三个分类器合并为一个标签。不同的分类器在覆盖范围和置信度校准上存在差异，尤其对于资源较少的语言。通过暴露所有三个分类结果，我们让您自行决定严格程度。想要高精度的希腊语子集？要求三个分类器在某个置信度阈值以上达成一致。想要对罗曼语族进行探索性研究的高召回率？一个分类器可能就足够了。 ## 可以用它构建什么 该数据集专为那些难以用通用网页文本完成的工作而设计： - **发现** 可能包含特定语言开发者文档或协作的仓库。 - **研究** 非英语开发者社区如何使用问题（issues）、拉取请求（pull requests）和README。 - **构建** 用于AI编码工具、文档生成器或审查助手的评估集，这些工具需要在多种语言中表现良好。 - **鼓励** 决策者利用基于数据的关于开发者丰富多语言多样性的论据，为新的开发者工具和AI功能扩展语言覆盖范围。 - **衡量** 欧洲及其他代表性不足的语言在开源中的表现。 ## 一些注意事项 语言识别很困难，尤其是在软件仓库中。仓库文本通常很短，可能包含徽章、模板、安装命令、代码片段、用户名或混合语言内容。150个字符的样本可能无法代表整个仓库。分类器在覆盖范围和校准上也有差异，尤其是对于资源较少的语言。 因此，该数据集不应被视为语言识别的真实基准。相反，它被设计为一个透明的发现工具。用户可以检查分类结果、置信度分数和来源，然后根据自己的研究或开发工作流程选择精度和召回率的权衡方案。 该数据集也不应用于推断仓库所有者、贡献者或社区的敏感属性。这些信号是仓库级元数据，而非个人级属性。 ## 开放多语言数据为何重要 如今，许多欧洲语言在用于构建和评估AI系统的在线文本中仍然代表性不足。这带来了风险：AI工具可能对某些开发者、语言和社区表现良好，而将其他群体抛在后面。开放数据有助于缩小这一差距。我们构建这个数据集是因为开发者内容与通用网页文本不同。README、问题（issues）和拉取请求（pull requests）包含软件协作的语言：安装说明、错误报告、功能请求、审查评论和社区规范。这种上下文有助于构建更理解开发者实际工作方式的AI系统。 通过让多语言开发者内容信号更易于查找和分析，该数据集为研究人员、开源开发者和模型构建者提供了另一种研究软件开发中语言表示的工具。它有助于识别差距、支持更好的评估，并为欧洲及其他地区的开发者提供更具包容性的AI工具。这也反映了一个更广泛的原则：为开发者构建AI应该涵盖开发者实际使用的社区、语言和工作流程。 ## 下一步计划 我们将于6月16日在斯特拉斯堡的 Open Innovation Dialogue Hub (https://www.microsoft.com/en-eu/european-policy/events/open-innovation-dialogue-hub/default.aspx) 讨论该数据集以及开放数据对多语言AI的更广泛重要性。该活动由微软开放创新中心、欧洲委员会和GitHub共同组织，将汇聚政策制定者、研究人员、文化机构和开放创新领袖，共同探讨AI、语言多样性、文化遗产和开放数据。 多语言AI需要多语言开发者社区。我们希望这个数据集能帮助更多人研究、支持并为这些社区构建工具。通过在GitHub上以CC0-1.0协议发布，我们邀请研究人员、开源维护者和模型构建者使用、批判、扩展它，并基于它构建评估集和工具。 如果您用这个数据集做出了有趣的东西，我们很乐意听到您的分享 (https://github.com/github/multilingual-repositories/discussions)。 ## 作者 Kevin Xu 员工软件工程师，CELA ## 探索更多来自GitHub的内容 文档 ### 文档 掌握GitHub所需的一切，尽在一处。 前往文档 (https://docs.github.com/) GitHub ### GitHub 在GitHub上构建下一个未来，这里是任何地方任何人都可以构建任何东西的地方。 开始构建 (https://github.com/) 客户案例 ### 客户案例 了解使用GitHub构建的公司和工程团队。 了解更多 (https://github.com/customer-stories) GitHub Universe 2026 ### GitHub Universe 2026 欢迎于10月28-29日前往旧金山或在线参加GitHub Universe，我们的旗舰开发者活动，汇聚人、智能体和世界代码。 立即注册 (https://githubuniverse.com/?utm_source=Blog&utm_medium=GitHub&utm_campaign=module_uni_26)