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

Imagine que você está tentando criar um diretório "Quem é Quem" para toda a história do software de código aberto. Existem bilhões de commits de código, mas os nomes associados a eles são uma bagunça. Uma pessoa pode estar listada como "John Smith", "J. Smith", "john.smith@work.com" e "john.doe@personal.com". Às vezes, pessoas diferentes usam acidentalmente o mesmo nome genérico como "admin" ou "test".

O objetivo deste artigo é resolver um quebra-cabeça massivo: Como agrupamos corretamente todos esses nomes bagunçados na pessoa certa sem colar estranhos por acidente?

Os pesquisadores abordaram isso para o "World of Code", um conjunto de dados contendo cerca de 6 bilhões de commits e 107 milhões de strings de autor únicas.

Aqui está a história de como eles resolveram isso, usando analogias simples.

O Problema: O Monstro do "Mega-Cluster"

Em projetos menores, a principal preocupação é perder conexões (não perceber que dois nomes pertencem à mesma pessoa). Mas, nesta escala massiva, o problema se inverte. O perigo é o sobre-agrupamento (over-merging).

Imagine uma festa onde todos estão tentando encontrar seus amigos. Se uma pessoa, vamos chamá-la de "Bob da Ponte", é amiga de todo mundo, e você diz para todos darem as mãos para qualquer pessoa que conheçam, logo todos na festa estarão dando as mãos em um círculo gigante e emaranhado.

No mundo do código, o "Bob da a Ponte" é um endereço de e-mail genérico (como noreply@github.com ou um marcador como test@test.com) ou uma conta de bot que milhares de pessoas diferentes usam. Se o sistema não for cuidadoso, ele vê que "Alice" usou test@test.com e "Bob" usou test@test.com, então assume que Alice e Bob são a mesma pessoa. Então, ele os liga a todos os outros que usaram esse e-mail.

O resultado é um "Mega-Cluster" contendo milhões de pessoas não relacionadas fundidas em um único bloco gigante. Em sua primeira tentativa, os pesquisadores criaram um cluster com 170.000 pessoas (e, em uma versão anterior, um cluster de 3 milhões). Isso é como dizer que a população inteira de uma pequena cidade é, na verdade, apenas uma pessoa.

As Tentativas Falhas: Tentando Cortar o Nó

A equipe tentou muitas formas de impedir que esse bloco gigante se formasse, mas a maioria falhou:

1. O Portão da "Raridade": Eles tentaram bloquear e-mails que eram muito comuns. Mas isso foi como um martelo bruto; bloqueou muitas pessoas reais que apenas por acaso usavam um nome comum.
2. O Portão da "Dispersão de Projetos": Eles tentaram bloquear pessoas que trabalhavam em muitos projetos diferentes (pensando que eram bots). Mas desenvolvedores reais trabalham em muitos projetos, e alguns bots trabalham em apenas um. Isso não funcionou bem o suficiente.
3. O Portão do "Grau": Eles tentaram bloquear pessoas que estavam conectadas a muitas outras. Isso ajudou, mas foi como descascar uma cebola camada por camada. Você remove a camada superior de links ruins, mas a próxima camada de links ruins está logo abaixo, e o bloco gigante permanece quase intacto.

Eles perceberam que simplesmente bloquear "nomes ruins" não era suficiente porque os nomes ruins estavam tecidos em uma malha redundante. Mesmo que você cortasse um fio, os outros mantinham o nó unido.

A Solução: Uma Cirurgia de Dois Passos

Os pesquisadores perceberam que precisavam mudar sua abordagem de "bloquear pessoas ruins" para "cortar os nós específicos".

Passo 1: O Corte Estrutural (Encontrando os Pilares de Sustentação)

Em vez de olhar para quem as pessoas eram, eles olharam para a forma das conexões. Eles trataram os dados como uma ponte.

• A Metáfora: Imagine uma ponte suspensa. Se você remover uma pedra aleatória da estrada, a ponte permanece de pé. Se você remover um cabo de suporte principal, a ponte desaba.
• A Ação: Eles usaram uma ferramenta matemática chamada Centralidade de Intermediação (Betweenness Centrality) para encontrar os "cabos de suporte principais" do bloco gigante. Estes eram identidades específicas que, se removidas, despedaçariam o cluster gigante em pedaços minúsculos e inofensivos.
• O Resultado: Eles identificaram apenas 2.000 identidades "ponte" específicas (de milhões) que estavam mantendo o bloco gigante unido. Remover esses 2.000 nós despedaçou o monstro de 170.000 pessoas em milhares de grupos pequenos e gerenciáveis.

Passo 2: O Filtro Inteligente (O Classificador de Arestas)

Mesmo após o grande corte, ainda havia alguns grupos de tamanho médio de pessoas que pareciam semelhantes (como um grupo de pessoas todas chamadas "David" ou "Kim").

• A Metáfora: Imagine que você tem uma pilha de peças de quebra-cabeça misturadas. Você separou as grandes pilhas, mas agora tem pequenas pilhas de peças que todas parecem "azul céu". Você precisa de um olho inteligente para dizer se duas peças "azul céu" realmente se encaixam ou se são apenas cores semelhantes de imagens diferentes.
• A Ação: Eles construíram um classificador de aprendizado de máquina (um filtro inteligente) treinado em milhões de exemplos. Eles usaram um truque inteligente: mineraram e-mails "GitHub No-Reply". Esses e-mails contêm um número oculto que prova que dois nomes diferentes pertencem, na verdade, à mesma conta do GitHub. Isso lhes deu 2,6 milhões de exemplos gratuitos e perfeitos de "mesma pessoa" e "pessoa diferente" sem a necessidade de humanos para rotulá-los.
• O Resultado: Esse filtro olhou para os pequenos grupos restantes e cortou apenas os links específicos que estavam errados, mantendo os corretos.

O Resultado Final: Um Mapa Limpo

Ao combinar o Corte Estrutural (quebrando o bloco gigante) e o Filtro Inteligente (limpando os pequenos grupos), eles alcançaram uma melhoria massiva:

• Antes: O maior grupo tinha 170.431 pessoas.
• Depois: O maior grupo tem menos de 7.000 pessoas.
• Precisão: Eles identificaram corretamente mais conexões reais (o Recall subiu de 44% para 70%) enquanto cometiam menos erros (a Precisão aumentou).

Eles também adicionaram um passo final: observar assinaturas criptográficas. Assim como uma assinatura digital em um documento prova quem o assinou, eles verificaram se diferentes commits de código foram assinados pela mesma chave privada. Isso atuou como uma âncora de "padrão ouro" para verificar o trabalho deles.

As Grandes Lições

O artigo conclui com algumas lições fundamentais para quem tenta resolver grandes enigmas de dados:

1. Não apenas bloqueie coisas ruins; corte a estrutura. Às vezes você não consegue consertar um problema bloqueando "itens ruins"; você tem que encontrar os pontos fracos estruturais específicos que mantêm a bagunça unida.
2. O contexto importa. Um e-mail "ruim" pode ser uma escolha de privacidade para uma pessoa e um erro para outra. Você tem que entender por que um link existe.
3. Benchmarks podem ser traiçoeiros. Se você medir apenas quantas conexões encontrou (Recall), pode acabar criando monstros gigantes. Se medir apenas quantos erros cometeu (Precisão), pode perder conexões reais. Você tem que medir ambos ao mesmo tempo.

Em resumo, os pesquisadores pegaram uma teia caótica e emaranhada de 6 bilhões de commits de código e usaram uma mistura de matemática estrutural e filtragem inteligente para desenredá-la, transformando um monstro gigante e confuso em um mapa limpo e utilizável dos desenvolvedores do mundo.