💻 computer science

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

Este artículo presenta una metodología escalable para la desambiguación de la identidad de autores en el Mundo del Código que resuelve la sobre-fusión de millones de identidades en "mega-clústeres" mediante la combinación de cortes de grafos estructurales con un clasificador por arista entrenado con identificadores no-reply de GitHub, logrando una precisión y exhaustividad de vanguardia mientras documenta lecciones clave sobre el escalado de la resolución de identidad.

Autores originales: Audris Mockus

Publicado 2026-07-09

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Audris Mockus

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás intentando crear un directorio de "Quién es Quién" para toda la historia del software de código abierto. Hay miles de millones de commits de código, pero los nombres asociados a ellos son un desastre. Una persona podría aparecer como "John Smith", "J. Smith", "john.smith@work.com" y "john.doe@personal.com". A veces, diferentes personas usan accidentalmente el mismo nombre genérico como "admin" o "test".

El objetivo de este artículo es resolver un rompecabezas masivo: ¿Cómo agrupamos correctamente todos estos nombres desordenados en la persona correcta sin pegar accidentalmente a extraños?

Los investigadores abordaron esto para el "World of Code", un conjunto de datos que contiene unos 6 mil millones de commits y 107 millones de cadenas de autor únicas.

Esta es la historia de cómo lo resolvieron, utilizando analogías sencillas.

El Problema: El Monstruo del "Mega-Clúster"

En proyectos más pequeños, la principal preocupación es perder conexiones (no darse cuenta de que dos nombres pertenecen a la misma persona). Pero a esta escala masiva, el problema se invierte. El peligro es la sobre-unión (over-merging).

Imagina una fiesta donde todos intentan encontrar a sus amigos. Si una persona, llamémosla "Bob el Puente", es amiga de todos, y le dices a todos que se tomen de la mano con cualquiera que conozcan, pronto todos en la fiesta estarán tomados de la mano en un círculo gigante y enredado.

En el mundo del código, "Bob el Puente" es una dirección de correo electrónico genérica (como noreply@github.com o un marcador de posición como test@test.com) o una cuenta de bot que miles de personas diferentes usan. Si el sistema no tiene cuidado, ve que "Alice" usó test@test.com y "Bob" usó test@test.com, por lo que asume que Alice y Bob son la misma persona. Luego, los vincula con todos los demás que usaron ese correo electrónico.

El resultado es un "Mega-Clúster" que contiene a millones de personas no relacionadas fusionadas en un solo bloque gigante. En su primer intento, los investigadores crearon un clúster con 170,000 personas (y en una versión anterior, un clúster de 3 millones). Esto es como decir que toda la población de una ciudad pequeña es en realidad una sola persona.

Los Intentos Fallidos: Intentando Cortar el Nudo

El equipo probó muchas formas de evitar que se formara este bloque gigante, pero la mayoría falló:

La Puerta de la "Rareza": Intentaron bloquear correos electrónicos que fueran demasiado comunes. Pero esto fue como un martillo contundente; bloqueó a demasiadas personas reales que simplemente usaban un nombre común.
La Puerta de la "Dispersión de Proyectos": Intentaron bloquear a personas que trabajaban en demasiados proyectos diferentes (pensando que eran bots). Pero algunos desarrolladores reales trabajan en muchos proyectos, y algunos bots solo trabajan en uno. Esto no funcionó lo suficientemente bien.
La Puerta del "Grado": Intentaron bloquear a personas que estaban conectadas con demasiadas otras. Esto ayudó, pero fue como pelar una cebolla capa por capa. Eliminas la capa superior de enlaces malos, pero la siguiente capa de enlaces malos está justo debajo, y el bloque gigante permanece mayormente intacto.

Se dieron cuenta de que simplemente bloquear "malos" nombres no era suficiente porque los malos nombres estaban tejidos en una malla redundante. Incluso si cortabas un hilo, los otros mantenían el nudo unido.

La Solución: Una Cirugía de Dos Pasos

Los investigadores se dieron cuenta de que necesitaban cambiar su enfoque de "bloquear malas personas" a "cortar los nos específicos".

Paso 1: El Corte Estructural (Encontrando los Pilares de Carga)

En lugar de mirar quiénes eran las personas, miraron la forma de las conexiones. Trataron los datos como un puente.

La Metáfora: Imagina un puente colgante. Si quitas una piedra al azar de la carretera, el puente se mantiene en pie. Si quitas un cable de soporte principal, el puente colapsa.
La Acción: Utilizaron una herramienta matemática llamada Centralidad de Intermediación (Betweenness Centrality) para encontrar los "cables de soporte principales" del bloque gigante. Estos eran identidades específicas que, si se eliminaban, destrozarían el clúster gigante en piezas pequeñas e inofensivas.
El Resultado: Identificaron solo 2,000 identidades "puente" específicas (de entre millones) que mantenían unido al bloque gigante. Eliminar estos 2,000 nodos destrozó al monstruo de 170,000 personas en miles de grupos pequeños y manejables.

Paso 2: El Filtro Inteligente (El Clasificador de Aristas)

Incluso después del gran corte, todavía quedaban algunos grupos de tamaño medio de personas que se parecían (como un grupo de personas llamadas todas "David" o "Kim").

La Metáfora: Imagina que tienes un montón de piezas de rompecabezas mezcladas. Has separado los grandes montones, pero ahora tienes montones pequeños de piezas que todas parecen de "color azul cielo". Necesitas un ojo inteligente para distinguir si dos piezas "azul cielo" realmente encajan o si son solo colores similares de diferentes imágenes.
La Acción: Construyeron un clasificador de aprendizaje automático (machine learning classifier) (un filtro inteligente) entrenado con millones de ejemplos. Utilizaron un truco ingenioso: minaron los correos electrónicos de "GitHub No-Reply". Estos correos electrónicos contienen un número oculto que demuestra que dos nombres diferentes pertenecen en realidad a la misma cuenta de GitHub. Esto les dio 2.6 millones de ejemplos gratuitos y perfectos de "misma persona" y "persona diferente" sin necesidad de que humanos los etiquetaran.
El Resultado: Este filtro miró los grupos pequeños restantes y cortó solo los enlaces específicos que estaban mal, manteniendo los correctos.

El Resultado Final: Un Mapa Limpio

Al combinar el Corte Estructural (romper el bloque gigante) y el Filtro Inteligente (limpiar los grupos pequeños), lograron una mejora masiva:

Antes: El grupo más grande tenía 170,431 personas.
Después: El grupo más grande tiene menos de 7,000 personas.
Precisión: Identificaron correctamente más conexiones reales (el Recall pasó del 44% al 70%) mientras cometían menos errores (la Precisión aumentó).

También añadieron un paso final: observar las firmas criptográficas. Al igual que una firma digital en un documento prueba quién firmó, verificaron si diferentes commits de código estaban firmados por la misma clave privada. Esto actuó como un "estándar de oro" de anclaje para verificar su trabajo.

Las Grandes Lecciones

El artículo concluye con algunas lecciones clave para cualquiera que intente resolver enormes acertijos de datos:

No te limites a bloquear cosas malas; corta la estructura. A veces no puedes solucionar un problema bloqueando elementos "malos"; tienes que encontrar los puntos débiles estructurales específicos que mantienen unido el desastre.
El contexto importa. Un correo electrónico "malo" puede ser una elección de privacidad para una persona y un error para otra. Tienes que entender por qué existe un enlace.
Los benchmarks pueden ser complicados. Si solo mides cuántas conexiones encontraste (Recall), podrías crear accidentalmente monstruos gigantes. Si solo mides cuántos errores cometiste (Precision), podrías perder conexiones reales. Tienes que medir ambos al mismo tiempo.

En resumen, los investigadores tomaron una red caótica y enredada de 6 mil millones de commits de código y utilizaron una mezcla de matemáticas estructurales y filtrado inteligente para desenredarla, convirtiendo un monstruo gigante y confuso en un mapa limpio y utilizable de los desarrolladores del mundo.

Resumen Técnico: Escalar la Desambiguación de Identidad de Autor al Mundo del Código

Planteamiento del Problema
El artículo aborda el desafío de la desambiguación de identidad de autor (de-aliasing) a la escala de la colección "World of Code" (WoC), versión V2604. Este conjunto de datos comprende aproximadamente 107 millones de cadenas de autor distintas a través de cerca de 6 mil millones de commits. A diferencia de esfuerzos previos que se centraron en maximizar el recall (evitar la pérdida de uniones), el modo de falla dominante a esta escala es el sobre-merge (sobre-unión). Un pequeño número de "identidades puente" —como bots, cuentas de rol, correos electrónicos de marcador de posición y campos de commit con múltiples autores— sueldan de forma transitiva clusters no relacionados en "mega-clusters" que contienen millones de personas distintas. Por ejemplo, una unión inicial no condicionada de V2604 produjo un único cluster de 170,431 miembros que abarcaba 857,853 proyectos, mientras que un mapa predecesor contenía un cluster de 3 millones de miembros. El desafío de ingeniería central es disolver estos mega-clusters sin sacrificar las uniones legítimas ni destruir el recall.

Metodología y Registro Experimental
El artículo documenta un registro experimental completo de veinte experimentos, incluyendo fallos, que condujeron al diseño desplegado. La metodología evolucionó a través de tres fases distintas:

Control de Nivel de Nodo y Neutralización de Atributos (Experimentos 1–10):
- Los intentos iniciales utilizaron puertas a nivel de nodo basadas en puntuaciones de información, dispersión de proyectos y grado de enlace. Si bien esto preservó el recall, no logró disolver los mega-clusters de manera eficiente; actuaron como mecanismos de "pelado lento" donde el endurecimiento de los umbrales simplemente exponía el siguiente puente moderado.
- Los Experimentos 8–10 intentaron neutralizar "atributos de alta calidad pero malos" (valores que son lo suficientemente raros como para parecer identificativos pero carecen de valor semántico, como hashes de relay de Cloudflare o plantillas de git no configuradas). Aunque neutralizar estos atributos en la fuente era seguro para el recall, resultó insuficiente. Los mega-clusters estaban mantenidos por una malla redundante de muchos valores moderadamente malos; eliminar una soldadura permitía que la malla se cerrara nuevamente alrededor de ella.
- Hallazgo Clave: Ninguna señal de nivel de nodo o lista de bloqueo de atributos pudo disolver el mega-cluster sin sacrificar el recall. El problema requería un cambio en el objeto de análisis.
Análisis Estructural y a Nivel de Arista (Experimentos 11–12):
- Corte Estructural (Exp. 11): Los autores reconstruyeron el grafo de unión exacto y aplicaron centralidad de intermediación (betweenness centrality) para identificar nodos de carga. Esto reveló que el mega-cluster estaba sostenido por un conjunto disperso de nodos "puente" (por ejemplo, cadenas de plantillas específicas, cuentas de servicio y cadenas de homónimos) que eran mayormente invisibles para las reglas basadas en atributos (el 98.4% de los puentes principales no tenían atributos bloqueados). Eliminar los 2,000 nodos de mayor intermediación fragmentó el mega-cluster de 170,431 miembros a 7,268, sin pérdida de recall legítimo.
- Clasificación a Nivel de Arista (Exp. 12): Quedaron fragmentos residuales (clusters de 1k–10k), consistentes principalmente en bloques de homónimos (nombres comunes como "Kim" o "David"). Se utilizó un clasificador logístico por arista, entrenado con 2.6 millones de pares etiquetados obtenidos gratuitamente de los IDs no-reply de GitHub (donde los IDs numéricos coincidentes indican una coincidencia real y los IDs conflictivos indican un vínculo falso), para podar las aristas dentro de estos fragmentos específicos. Este enfoque apuntó solo a las aristas que el clasificador consideraba improbables, preservando el recall mientras rompía los fragmentos restantes.
Recuperación de Recall y Validación Externa (Experimentos 13–18):
- Una vez establecido el mecanismo de precisión (corte estructural + poda de aristas), el sistema expandió de forma segura la capa de shingles Rule-3 latente (shingles de nombres entre proyectos). Una expansión filtrada por clasificador añadió 30.8 millones de aristas, recuperando un recall significativo sin reintroducir mega-clusters.
- Benchmarks Externos: El mapa final fue evaluado contra dos benchmarks:
  - Set de Oro ALFAA: Un conjunto de 469k pares adjudicados por humanos. El modelo desplegado alcanzó un AUC de 0.987 en etiquetas humanas, transfiriendo desde las etiquetas de ID de GitHub.
  - Verdad de Terreno de GitHub: Un benchmark de solo recall de 21.4 millones de alias de repositorios de un solo autor. El mapa final superó tanto a sus predecesores como al estado del arte publicado (GitAuthority) en este contexto global de preservación de la privacidad.
- Composición Final: El mapa de producción combina un corte de centralidad de intermediación, una poda de fragmentos residuales por arista, una expansión de shingles filtrada por clasificador y las aserciones de cuenta de GitHub (aristas de mismo-ghid). También incluye una capa dentro del proyecto para resolver IDs de baja calidad (nombres genéricos, direcciones locales de máquinas) que son ambiguos globalmente pero unívocos dentro de un solo proyecto.

Contribuciones Clave

Metodología como Registro: El artículo reporta todos los veinte experimentos, incluyendo fallos, demostrando que los cortes estructurales y los clasificadores de aristas son necesarios porque los controles de nivel de nodo y las listas de bloqueo de atributos no pueden resolver el problema del sobre-merge.
Diagnóstico del Sobre-merge: Los autores identifican que el sobre-merge es impulsado por "atributos de alta calidad pero malos" e identidades puente que son estructuralmente de carga pero limpias de atributos. Distinguen entre máscaras de privacidad (anonimato intencional, nunca deben fusionarse) y valores por defecto de homónimos (colisiones accidentales, potencialmente re-vinculables).
Etiquetas Gratuitas a Escala: El artículo demuestra cómo extraer 2.6 millones de pares de identidad etiquetados de cadenas de correo electrónico no-reply de GitHub (extrayendo IDs numéricos) a costo cero de anotación, permitiendo el entrenamiento de un clasificador por arista que se transfiere a la adjudicación humana con alta precisión (AUC 0.987).
Diseño Compuesto: La resolución exitosa implica una secuencia específica: reconstrucción de un grafo de unión exacto, un corte de nodos de carga por centralidad de intermediación, poda de fragmentos de homónimos por arista y expansión de grupos entre proyectos filtrada por clasificador.
Evaluación Externa: El mapa final alcanza un gold recall de 0.70 (frente a 0.44) y una precisión de 0.88, superando al resolvedor global anterior en un ground truth de GitHub de 21M de alias.

Resultos y Significado
El mapa desplegado para WoC V2604 resuelve 106.8 millones de IDs de autor. Las métricas clave incluyen:

Tamaño de Cluster: El cluster más grande se reduce de 170,431 (sin control) a 6,910 (una identidad no-reply).
Recall/Precisión: El gold recall aumenta de 0.44 a 0.70, y la precisión aumenta de 0.873 a 0.879.
Cobertura: El mapa aumenta la cobertura ponderada por commits de IDs humanos (no-bots) del 96.49% al 98.17%.

El artículo sostiene que, a la escala de $10^8$ identidades, la desambiguación requiere resolver dos problemas distintos en un orden específico: primero, la precisión (disolver mega-clusters mediante análisis estructural y de aristas) y segundo, el recall (recuperar uniones legítimas mediante expansión filtrada por clasificador). Los autores enfatizan que los certificados estructurales no se transfieren a nuevos conjuntos de aristas, y que los benchmarks deben leerse conjuntamente (precisión y recall) para evitar invertir los veredictos. El trabajo sirve como un catálogo de lecciones de escala, destacando cómo el gradient boosting puede "aprender atajos" de los artefactos de construcción de etiquetas (llevando a una transferencia pobre) mientras que los modelos lineales pueden sobrevivir, y cómo los benchmarks de solo recall pueden ocultar fallas de precisión.

El diseño es ahora la capa de identidad de producción para el World of Code V2604, proporcionando una base para afirmaciones cuantitativas sobre la productividad de los desarrolladores, la salud de los proyectos y la seguridad de la cadena de suministro.