A Global Author-Identity Map for the World of Code:62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits
本文为 World of Code (V2604) 引入了一个经过人工精选、高精度的全球作者身份映射，该映射通过优先考虑防止错误的“聚类”而非单纯追求召回率，将 1.068 亿个作者字符串解析为 58.7 亿次提交中的 6270 万个规范身份，从而显著提升了大规模软件仓库分析和学术作者图谱关联的可靠性。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，整个软件开发的历史就像一座巨大的、混乱的图书馆，其中包含了近 60 亿本书（代码提交）。在这座图书馆里，每当有人写下一页内容时，都会签上自己的名字。但问题在于，这些签名非常混乱。
一个人可能会签名为“Jane Doe”、“j.doe”、“jane.doe@work.com”，随后又用“jane@personal.org”签名。与此同时，成千上万个陌生人可能会都把名字签为“root”、“user”或“Your Name”。
如果你试图仅通过观察这些签名来统计有多少位独特的作者，你得到的答案会错得离谱。你会认为那里有更多的人（因为一个人看起来像十个人），或者你会漏掉某些“人”其实只是机器人或自动化程序。
这篇论文展示了一个巨型身份映射图（Giant Identity Map），它清理了这座图书馆。它将 1.06 亿个混乱的签名整理成了 6,270 万个真实的人。
以下是他们是如何做到的，使用了简单的类比：
1. 问题所在：“超级簇”陷阱 (The "Mega-Cluster" Trap)
作者解释说，以往尝试解决这个问题的方法就像是仅凭颜色就把拼图碎片粘在一起。如果你只是简单地说，“如果两个名字共享一个字母或电子邮件，那他们就是同一个人”，你最终会将数百万个互不相关的人粘成一个巨大的、怪异的团块。
他们称之为**“超级簇”（Mega-Cluster）**。想象一下，在一座图书馆里，因为所有人的书名里都用了“The”这个词，图书管理员便判定这本书库里的每一本书都是由同一个人写的。这就是之前的映射图所发生的情况：他们意外地将 300 万名互不相关的开发者融合成了同一个巨大的“超级作者”。
2. 解决方案：六步侦探流水线
为了解决这个问题，作者构建了一个六阶段的侦探流程，在进行分类的同时避免犯下那个巨大的错误：
- 第 1 步：初步线索： 他们首先通过链接那些拥有明显共同点（如完全相同的电子邮件地址）的签名来开始工作。
- 第 2 步：“不良行为者”过滤器： 他们忽略那些明显是通用名称（如“root”或“admin”）或属于机器人的名称。这些是图书馆里的“幽灵”；它们不应该被用来连接真实的人。
- 第 3 步：结构性切割（魔术技巧）： 这是最重要的一步。他们像观察桥梁地图一样观察这些连接。他们发现了一些特定的“桥梁”签名，这些签名将巨大的、互不相关的群体连接在了一起。他们切断了这些桥梁。这一举动瞬间让巨大的“超级簇”消解成了更小、更易管理的群体。
- 第 4 步：智能分类器： 他们使用了一个计算机程序（基于数百万个真实案例进行训练）来判断两个听起来相似的名字究竟是同一个人，还是仅仅是巧合（例如两个都叫“John Smith”的人）。
- 第 5 步：召回恢复： 在切断了错误的连接后，他们使用另一种方法（观察名字在片段上的拼写方式）仔细地找回了一些之前被忽略的连接，以确保没有遗漏真正的朋友。
- 第 6 步：最终标记： 他们挑选出每个名字的“最佳”版本（通常是带有真实姓名和真实电子邮件的版本）作为该人的官方 ID。
3. 为什么这很重要：“公交系数”与生产力
论文表明，如果你不修正这些名字，你的数学计算就会出错。他们进行了多项实验，展示了修正前后的差异：
- 统计人数： 如果不修正名字，这座图书馆看起来比实际拥有的作者多出 66%。这就像是因为一个人用了 10 种不同的签名方式，你就把他数成了 10 个人。
- 团队安全性（公交系数/Bus Factor）： 想象一个项目，你需要知道：“如果一个人被车撞了（意指某人突然离职/无法工作），这个项目会瘫痪吗？”
- 如果不修正名字： 项目看起来很安全，因为工作似乎分散在 10 个不同的“名字”之下。
- 如果修正了名字： 你会意识到这 10 个名字其实都属于同一个人。项目实际上处于巨大的危险之中。
- 结果： 论文发现，96% 的项目实际上依赖于单个人（即“单点故障”），而混乱的数据让原本看起来只有 90% 的项目存在此类风险。
- 中心度（“最重要的”人）： 在混乱的数据中，网络中“最重要”的人往往是机器人或通用账号（如“root”）。一旦修正了名字，那些“最重要”的人就变成了真实的开发者。
4. “金标准”校验
作者并非仅仅靠猜测；他们通过两个不同的“标准答案”测试了他们的映射图：
- 人工审核： 一小组人类检查了该映射图是否正确。
- GitHub 数据： 他们利用 GitHub 账号的数据来查看是否找到了所有的别名。
他们发现，新的映射图具有 88% 的精确度（很少混淆陌生人）和 70% 的完整度（找到了大部分别名）。至关重要的是，他们证明了旧的映射图之所以看起来完美（精确度达 95%），是因为它们忽略了错误隐藏其中的巨大“超级簇”。
5. 连接代码与科学
最后，论文指出，这张映射图可以作为连接软件开发者与学术研究人员的“通用钥匙”。由于许多人既编写代码又撰写科学论文，这张映射图可以帮助将开发者的代码与其研究论文联系起来。然而，他们也警告说，由于名字非常普遍（例如，代码中的“John Smith”和论文中的“John Smith”），这非常困难，并且你必须极其小心，以免误将不同的人联系在一起。
总结
这篇论文是一本关于如何清理大规模、混乱的软件作者数据库的指南。它证明了忽视混乱会导致错误的结论——关于谁在工作、他们的生产力如何，以及项目有多安全。他们的新映射图是第一个成功避免了将数百万陌生人粘合成一个巨大虚假身份的映射图。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。