Predecir la fusión de pull requests de Node.js con aprendizaje automático

En este artículo explicaré un uso sencillo del aprendizaje automático (ML) para evaluar si puede predecirse con precisión la aceptación de un pull request (PR) al crearlo. El experimento busca generar un programa fiable que ayude al integrador a gestionarlos en un proyecto. Como los proyectos grandes reciben PR continuamente, exploramos un modelo replicable para filtrar cuanto antes los no deseados.

Los trabajos de Yu et al.¹ y Gousios et al.² proponen modelos entrenados con varios repositorios para predecir la aceptación incluso en proyectos distintos. Esto reduce la exactitud, especialmente si se entrena con proyectos A y B y se predice en C, cuyos criterios pueden ser diferentes. Nuestro enfoque usa solo datos del mismo proyecto. Predecimos PR de Nodejs con datos disponibles al enviarlos para evaluar inmediatamente si se fusionarán.

Construir el predictor

Debemos crear un predictor y encontrar los parámetros adecuados. Seguimos estos pasos:

1. Definir características relevantes para evaluar un PR.
2. Recopilar datos de las fuentes de GitHub del proyecto.
3. Normalizar los datos en un almacén persistente para los modelos ML.
4. Elegir el modelo que mejor funcione con los datos.
5. Evaluar el predictor en un conjunto separado.

Definir características

En el paso 1 nos basamos en Yu et al. y usamos estas características:

En el futuro podríamos incluir cumplimiento de requisitos de mensajes de commit, pruebas unitarias superadas o cantidad de PR abiertos. También datos cronológicos: los requisitos cambian y un PR antiguo se evalúa con estándares distintos. Clasificar datos temporales es un problema común en ML porque los criterios dependen de cuándo se crearon y clasificaron. Brownlee³ muestra una forma de abordar pronósticos.

Carga ETL

Diagrama del proceso ETL

Los pasos 2 y 3 usan extracción, transformación y carga (ETL), que consume la API de GitHub REST (V3), tanto REST como GraphQL, y guarda características en MongoDB. Recupera datos de los PR mediante la API. Para calcular volumen de cambios y actividad usamos un clon del repositorio y un cliente git para comparar ramas de origen y destino. La API GraphQL (V4) obtiene información de usuarios, incluidas conexiones sociales (social_conn). Permite consultas más ricas entre entidades, como las conexiones de todos los autores, y reduce solicitudes URL. Este código obtiene datos paginados de MergedEvents de un PR para detectar si se fusionó.

{
 repository(owner: nodejs, name: node){
   name,
   pullRequests(first: 100, states: MERGED) {
     nodes {
       id,
       url,
       timeline(last: 100) {
         nodes {
             ... on MergedEvent {
            id,
             actor {
               login
             }
             createdAt,
             url,
           }
         }
       }
     },
     pageInfo {
       hasNextPage,
       hasPreviousPage,
       endCursor,
       startCursor,
     },
     totalCount
   }
  }
}

No pudimos usar GraphQL en todos los casos por límites de solicitudes más bajos que ralentizan la recuperación. Las llamadas complejas también fueron más lentas que sus equivalentes V3. Diseñamos ETL para reanudarse y reiniciarse, pues puede tardar horas. Lo dividimos en estas tareas:

Tareas ETL para cargar y normalizar datos

Construcción y evaluación del predictor

Sobreajuste de precedentes electorales (fuente: XKCD)

Con los datos listos, los pasos 4 y 5 usan scikit-learn. Para evitar sobreajuste, dividimos en entrenamiento y validación: 90% de los PR para entrenar y 10% para validar. Hacemos validación cruzada dividiendo el entrenamiento en 10 grupos con k-fold. Probamos estos predictores:

• Naive Bayes (Bernoulli y gaussiano)
• Árboles de decisión
• K vecinos más cercanos
• Análisis discriminante lineal
• Regresión logística
• Perceptrones multicapa
• Centroides más cercanos
• Análisis discriminante cuadrático
• Regresión Ridge
• Máquinas de vectores de soporte (SVC), con soporte C y lineales
• Descenso de gradiente estocástico (SGD)
• Algoritmos pasivo-agresivos

Diagrama de validación k-fold con 4 grupos (fuente: Wikipedia)

Recopilamos 10,200 PR del repositorio nodejs entre noviembre de 2014 y noviembre de 2017. Los datos brutos tenían esta forma. Cerca del 76% de los MR recuperados se fusionaron; es un conjunto considerable para entrenar la mayoría de los predictores.

Probamos 21 clasificadores y obtuvimos exactitud del 77% al 88% en entrenamiento. Elegimos SVC con soporte C, con una media del 87% en 10 validaciones cruzadas. Es bueno para entrenamiento, pero la evaluación real usa datos de prueba. Allí alcanzó una precisión algo menor, del 78%, todavía aceptable.

Métricas de precisión sobre datos de prueba

Conclusiones y mejoras futuras

Los experimentos muestran que podemos predecir MR con exactitud y aliviar la carga de integradores ante grandes colas. Los datos temporales necesitan tratamiento especial: los criterios cambian y quizá convenga filtrar MR antiguos. Más características mejorarán las predicciones. Extraer datos de GitHub puede llevar mucho tiempo y requiere manejar desconexiones y límites de API para recuperar el proceso. Cada proyecto también tiene mecanismos de fusión distintos, a veces sin la función «merge» de GitHub, y puede exigir CI para aceptar un MR. Hay que considerarlo. No hay una solución universal, pero con las herramientas adecuadas puede crearse una aplicación predictora para cada proyecto con suficientes MR. El código está en https://github.com/sophilabs/pullreq-ml.

Referencias