💻 computer science

Scaling Author Identity Disambiguation to the World of Code: A Methodology

Cet article présente une méthodologie évolutive pour la désambiguïsation de l'identité des auteurs dans le World of Code qui résout le sur-regroupement de millions d'identités en « méga-clusters » en combinant des coupes de graphes structurelles avec un classifieur par arête entraîné sur les identifiants no-reply de GitHub, atteignant ainsi un état de l'art en termes de précision et de rappel tout en documentant les leçons clés sur le passage à l'échelle de la résolution d'identité.

Auteurs originaux : Audris Mockus

Publié 2026-07-09

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Audris Mockus

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez de créer un annuaire « Qui est qui » pour toute l'histoire du logiciel libre. Il existe des milliards de commits de code, mais les noms qui y sont associés sont un désordre total. Une même personne peut être répertoriée sous le nom de « John Smith », « J. Smith », « john.smith@work.com » ou « john.doe@personal.com ». Parfois, différentes personnes utilisent accidentellement le même nom générique comme « admin » ou « test ».

L'objectif de ce document est de résoudre un puzzle massif : Comment regrouper correctement tous ces noms désordonnés pour qu'ils correspondent à la bonne personne unique sans pour autant coller des inconnus ensemble ?

Les chercheurs ont abordé ce problème pour le « World of Code », un ensemble de données contenant environ 6 milliards de commits et 107 millions de chaînes d'auteurs uniques.

Voici l'histoire de la façon dont ils ont résolu cela, en utilisant des analogies simples.

Le Problème : Le Monstre du « Méga-Cluster »

Dans les projets de plus petite taille, la principale préoccupation est de manquer des connexions (ne pas réaliser que deux noms appartiennent à la même personne). Mais à cette échelle massive, le problème s'inverse. Le danger est le sur-regroupement (over-merging).

Imaginez une fête où tout le monde essaie de retrouver ses amis. Si une personne, appelons-la « Bob le Pont », est amie avec tout le monde, et que vous dites à tout le monde de se tenir la main avec quiconque ils connaissent, bientôt tout le monde à la fête se retrouvera à se tenir la main dans un immense cercle emmêlé.

Dans le monde du code, « Bob le Pont » est une adresse e-mail générique (comme noreply@github.com ou un espace réservé comme test@test.com) ou un compte de bot que des milliers de personnes différentes utilisent. Si le système n'est pas prudent, il voit qu'« Alice » a utilisé test@test.com et que « Bob » a utilisé test@test.com, il suppose alors qu'Alice et Bob sont la même personne. Il les lie ensuite à tous ceux qui ont utilisé cet e-mail.

Le résultat ? Un « Méga-Cluster » contenant des millions de personnes sans lien entre elles, fusionnées en un seul énorme bloc. Lors de leur première tentative, les chercheurs ont créé un cluster de 170 000 personnes (et dans une version précédente, un cluster de 3 millions). C'est comme dire que toute la population d'une petite ville n'est en fait qu'une seule et même personne.

Les Tentatives Ratées : Essayer de Couper le Nœud

L'équipe a essayé de nombreuses façons d'empêcher la formation de ce bloc géant, mais la plupart ont échoué :

La Porte de la « Rareté » : Ils ont essayé de bloquer les e-mails trop courants. Mais c'était comme un marteau contondant ; cela bloquait trop de vraies personnes qui se trouvaient simplement utiliser un nom commun.
La Porte de la « Dispersion par Projet » : Ils ont essayé de bloquer les personnes qui travaillaient sur trop de projets différents (pensant qu'il s'agissait de bots). Mais certains développeurs réels travaillent sur de nombreux projets, et certains bots ne travaillent que sur un seul. Cela ne fonctionnait pas assez bien.
La Porte du « Degré » : Ils ont essayé de bloquer les personnes qui étaient connectées à trop d'autres. Cela a aidé, mais c'était comme éplucher un oignon couche par couche. Vous retirez la couche supérieure de mauvais liens, mais la couche suivante de mauvais liens se trouve juste en dessous, et le bloc géant reste largement intact.

Ils ont réalisé que simplement bloquer les « mauvais » noms ne suffisait pas car les mauvais noms étaient tissés dans un maillage redondant. Même si vous coupiez un fil, les autres maintenaient le nœud ensemble.

La Solution : Une Chirurgie en Deux Étapes

Les chercheurs ont réalisé qu'ils devaient changer d'approche, passant de « bloquer les mauvaises personnes » à « couper les nœuds spécifiques ».

Étape 1 : La Coupe Structurelle (Trouver les Piliers Porteurs)

Au lieu de regarder qui étaient les personnes, ils ont regardé la forme des connexions. Ils ont traité les données comme un pont.

La Métaphore : Imaginez un pont suspendu. Si vous retirez un caillou au hasard sur la route, le pont tient debout. Si vous retirez un câble de support principal, le pont s'effondre.
L'Action : Ils ont utilisé un outil mathématique appelé Centralité d'Intermédiarité (Betweenness Centrality) pour trouver les « câbles de support principaux » du bloc géant. Il s'agissait d'identités spécifiques qui, si elles étaient supprimées, briseraient le cluster géant en petits morceaux inoffensifs.
Le Résultat : Ils ont identifié seulement 2 000 identités « ponts » spécifiques (sur des millions) qui maintenaient le bloc géant ensemble. La suppression de ces 2 000 nœuds a fragmenté le monstre de 170 000 personnes en milliers de petits groupes gérables.

Étape 2 : Le Filtre Intelligent (Le Classificateur d'Arêtes)

Même après la grande coupe, il restait encore des groupes de personnes de taille moyenne qui se ressemblaient (comme un groupe de personnes nommées toutes « David » ou « Kim »).

La Métaphore : Imaginez que vous avez un tas de pièces de puzzle mélangées. Vous avez séparé les gros tas, mais maintenant vous avez de petits tas de pièces qui ont toutes la même couleur « bleu ciel ». Vous avez besoin d'un œil intelligent pour dire si deux pièces « bleu ciel » s'assemblent réellement ou si elles sont juste de couleurs similaires provenant de tableaux différents.
L'Action : Ils ont construit un classificateur par apprentissage automatique (un filtre intelligent) entraîné sur des millions d'exemples. Ils ont utilisé une astuce ingénieuse : ils ont exploité les e-mails « GitHub No-Reply ». Ces e-mails contiennent un nombre caché qui prouve que deux noms différents appartiennent en réalité au même compte GitHub. Cela leur a donné 2,6 millions d'exemples parfaits et gratuits de « même personne » et de « personne différente » sans avoir besoin de l'intervention humaine pour les étiqueter.
Le Résultat : Ce filtre a examiné les petits groupes restants et a coupé uniquement les liens spécifiques qui étaient erronés, tout en conservant les liens corrects.

Le Résultat Final : Une Carte Propre

En combinant la Coupe Structurelle (briser le bloc géant) et le Filtre Intelligent (nettoyer les petits groupes), ils ont obtenu une amélioration massive :

Avant : Le groupe le plus grand comptait 170 431 personnes.
Après : Le groupe le plus grand compte moins de 7 000 personnes.
Précision : Ils ont correctement identifié plus de connexions réelles (le Rappel est passé de 44 % à 70 %) tout en faisant moins d'erreurs (la Précision a augmenté).

Ils ont également ajouté une étape finale : l'examen des signatures cryptographiques. Tout comme une signature numérique sur un document prouve qui l'a signé, ils ont vérifié si différents commits de code étaient signés par la même clé privée. Cela a servi d'ancre de « référence absolue » pour vérifier leur travail.

Les Grandes Leçons

Le document conclut avec quelques enseignements clés pour quiconque tente de résoudre de grands puzzles de données :

Ne vous contentez pas de bloquer les mauvaises choses ; coupez la structure. Parfois, on ne peut pas résoudre un problème en bloquant les éléments « mauvais » ; il faut trouver les points faibles structurels spécifiques qui maintiennent le désordre ensemble.
Le contexte compte. Un « mauvais » e-mail peut être un choix de confidentialité pour une personne et une erreur pour une autre. Il faut comprendre pourquoi un lien existe.
Les benchmarks peuvent être trompeurs. Si vous ne mesurez que le nombre de connexions trouvées (Rappel), vous risquez de créer accidentellement des monstres géants. Si vous ne mesurez que le nombre d'erreurs commises (Précision), vous risquez de manquer des connexions réelles. Vous devez mesurer les deux en même temps.

En résumé, les chercheurs ont pris un réseau chaotique et emmêlé de 6 milliards de commits de code et ont utilisé un mélange de mathématiques structurelles et de filtrage intelligent pour le démêler, transformant un monstre géant et confus en une carte propre et utilisable des développeurs du monde entier.

Résumé Technique : Mise à l'échelle de la désambiguïsation de l'identité des auteurs pour le monde du code

Énoncé du problème
Le document traite du défi de la désambiguïsation de l'identité des auteurs (dé-aliasing) à l'échelle de la collection « World of Code » (WoC), version V2604. Ce jeu de données comprend environ 107 millions de chaînes d'auteurs distinctes à travers environ 6 milliards de commits. Contrairement aux efforts précédents qui se concentraient sur la maximisation du rappel (prévenir les manques de fusion), le mode de défaillance dominant à cette échelle est le sur-regroupement (over-merge). Un petit nombre d'« identités-ponts » — telles que des bots, des comptes de rôle, des adresses e-mail génériques ou des champs de commit multi-auteurs — soudent de manière transitive des clusters sans rapport en « méga-clusters » contenant des millions de personnes distinctes. Par exemple, une union non conditionnée initiale de V2604 a produit un cluster unique de 170 431 membres couvrant 857 853 projets, tandis qu'une carte précédente contenait un cluster de 3 millions de membres. Le défi d'ingénierie central consiste à dissoudre ces méga-clusters sans sacrifier les fusions légitimes ni détruire le rappel.

Méthodologie et dossier expérimental
Le document documente un dossier expérimental complet de vingt expériences, incluant les échecs, menant au design déployé. La méthodologie a évolué à travers trois phases distinctes :

Filtrage au niveau des nœuds et neutralisation des attributs (Expériences 1–10) :
- Les tentatives initiales utilisaient des portes au niveau des nœuds basées sur des scores d'information, l'étendue des projets et le degré de lien. Bien que cela ait préservé le rappel, ces méthodes ont échoué à dissoudre efficacement les méga-clusters ; elles agissaient comme des mécanismes de « pelage lent » où le resserrement des seuils ne faisait qu'exposer le pont modéré suivant.
- Les expériences 8–10 ont tenté de neutraliser les « mauvais attributs de haute qualité » (des valeurs suffisamment rares pour paraître identifiantes mais sémantiquement vides, telles que des hashs de relais Cloudflare ou des templates git non configurés). Bien que la neutralisation de ces attributs à la source soit sans risque pour le rappel, elle s'est avérée insuffisante. Les méga-clusters étaient maintenus par un maillage redondant de nombreuses valeurs modérément mauvaises ; supprimer une soud permettait au maillage de se refermer autour d'elle.
- Résultat clé : Aucun signal au niveau du nœud ou aucune liste noire d'attributs ne pouvait dissoudre le méga-cluster sans sacrifier le rappel. Le problème nécessitait un changement dans l'objet d'analyse.
Analyse structurelle et au niveau des arêtes (Expériences 11–12) :
- Coupe structurelle (Exp. 11) : Les auteurs ont reconstruit le graphe d'union exact et ont appliqué la centralité d'intermédiarité (betweenness centrality) pour identifier les nœuds porteurs de charge. Cela a révélé que le méga-cluster était maintenu par un ensemble épars de « nœuds ponts » (ex: chaînes de caractères de templates spécifiques, comptes de service et chaînes d'homonymes) qui étaient largement invisibles pour les règles basées sur les attributs (98,4 % des ponts principaux n'avaient aucun attribut bloqué). La suppression des 2 000 premiers nœuds d'intermédiarité a brisé le méga-cluster, passant de 170 431 membres à 7 268, sans perte de rappel légitime.
- Classification au niveau des arêtes (Exp. 12) : Des fragments résiduels (clusters de 1k à 10k) restaient, principalement constitués de blocs d'homonymes (noms communs comme « Kim » ou « David »). Un classificateur logistique par arête, entraîné sur 2,6 millions de paires étiquetées extraites gratuitement des ID no-reply de GitHub (où des ID numériques concordants indiquent une véritable correspondance et des ID conflictuels indiquent un faux lien), a été utilisé pour élaguer les arêtes au sein de ces fragments spécifiques. Cette approche ciblait uniquement les arêtes que le classificateur jugeait improbables, préservant le rappel tout en brisant les fragments restants.
Récupération du rappel et validation externe (Expériences 13–18) :
- Une fois la machinerie de précision (coupe structurelle + élagage des arêtes) établie, le système a déployé en toute sécurité la couche de shingles dormant Rule-3 (shingles de noms inter-projets). Une expansion filtrée par classificateur a ajouté 30,8 millions d'arêtes, récupérant un rappel significatif sans réintroduire de méga-clusters.
- Benchmarks externes : La carte finale a été évaluée contre deux benchmarks :
  - Set d'or ALFAA : Un ensemble de 469k paires jugées par des humains. Le modèle déployé a atteint un AUC de 0,987 sur les labels humains, transféré des labels GitHub-ID gratuits.
  - Vérité terrain GitHub : Un benchmark de rappel pur de 21,4 millions d'alias provenant de dépôts à auteur unique. La carte finale surpasse ses prédécesseurs ainsi que l'état de l'art publié (GitAuthority) dans ce contexte mondial respectant la vie privée.
- Composition finale : La carte de production combine une coupe par centralité d'intermédiarité, un élagage par arête des fragments résiduels, une expansion de shingles filtrée par classificateur, et les assertions de comptes de GitHub (arêtes same-ghid). Elle inclut également une couche intra-projet pour résoudre les ID de faible qualité (noms génériques, adresses locales de machines) qui sont ambigus globalement mais univoques au sein d'un même projet.

Contributions clés

La méthodologie comme registre : Le document rapporte les vingt expériences, y compris les échecs, démontrant que les coupes structurelles et les classificateurs d'arêtes sont nécessaires car les portes au niveau des nœuds et les listes noires d'attributs ne peuvent pas résoudre le problème de sur-regroupement à cette échelle.
Diagnostic du sur-regroupement : Les auteurs identifient que le sur-regroupement est piloté par des « mauvais attributs de haute qualité » et des identités-ponts qui sont structurellement porteurs de charge mais exempts d'attributs problématiques. Ils distinguent les masques de confidentialité (anonymat intentionnel, ne doivent jamais fusionner) des défauts d'homonymie (collisions accidentelles, potentiellement reliables).
Labels gratuits à grande échelle : Le document démontre comment extraire 2,6 millions de paires d'identités étiquetées à partir de chaînes d'e-mails no-reply brutes de GitHub (en extrayant les ID numériques) sans coût d'annotation, permettant l'entraînement d'un classificateur par arête qui se transfère avec une grande précision (AUC 0,987) à l'adjudication humaine.
Design composé : La résolution réussie implique une séquence spécifique : reconstruction d'un graphe d'union exact, coupe par échantillonnage de l'intermédiarité des nœuds porteurs de charge, élagage par arête des fragments d'homonymes résiduels, et expansion de groupes inter-projets filtrée par classificateur.
Évaluation externe : La carte finale atteint un rappel d'or de 0,70 (contre 0,44) et une précision de 0,88, réduisant le plus grand cluster de 170 431 à moins de 7 000. Elle surpasse les résolveurs mondiaux précédents sur un terrain de vérité de 21M d'alias GitHub.

Résultats et importance
La carte déployée pour WoC V2604 résout 106,8 millions d'ID d'auteurs. Les indicateurs clés incluent :

Taille des clusters : Le plus grand cluster est réduit de 170 431 (non filtré) à 6 910 (une identité no-reply).
Rappel/Précision : Le rappel d'or passe de 0,44 à 0,70, et la précision augmente de 0,873 à 0,879.
Couverture : La carte augmente la couverture pondérée par commit des ID humains (non-bots) de 96,49 % à 98,17 %.

Le document affirme qu'à l'échelle de $10^8$ identités, la désambiguïsation nécessite de résoudre deux problèmes distincts dans un ordre précis : d'abord, la précision (dissoudre les méga-clusters via l'analyse structurelle et par arête), puis le rappel (récupérer les fusions légitimes via l'expansion filtrée par classificateur). Les auteurs soulignent que les certificats structurels ne se transfèrent pas à de nouveaux ensembles d'arêtes, et que les benchmarks doivent être lus conjointement (précision et rappel) pour éviter d'inverser les verdicts. Ce travail sert de catalogue de leçons d'échelle, soulignant que le gradient boosting peut « apprendre par raccourci » les artefacts de construction de labels (menant à un mauvais transfert) tandis que les modèles linéaires peuvent survivre, et que les benchmarks de rappel pur peuvent masquer des échecs de précision.

Le design est désormais la couche d'identité de production pour le World of Code V2604, fournissant une base pour les affirmations quantitatives sur la productivité des développeurs, la santé des projets et la sécurité de la chaîne d'approvisionnement.