Multi-stage Dynamic Selection for Cross-Project Defect Prediction

Imagina que eres un detective intentando resolver un misterio, pero nunca has visto la escena del crimen antes. Solo tienes una pila de viejos expedientes de ciudades completamente diferentes, escritos por diferentes fuerzas policiales con diferentes jergas y hábitos. Tu trabajo es predecir dónde golpeará el próximo criminal en tu nueva ciudad. Este es el lucha diaria de los ingenieros de software que intentan mantener sus programas libres de errores. Quieren encontrar "defectos" (bugs) en su código antes de que el software falle, pero muchos proyectos nuevos son como lienzos en blanco: no han estado funcionando el tiempo suficiente como para construir un historial de errores. Así que los ingenieros intentan aprender de otros proyectos, con la esperanza de que lo que funcionó en una empresa de videojuegos ayude a arreglar una aplicación bancaria. Esto se llama Predicción de Defectos entre Proyectos (Cross-Project Defect Prediction). El problema es que cada proyecto es único; un modelo que funciona perfectamente en uno puede fallar estrepitosamente en otro porque las "escenas del crimen" (el código) se ven muy diferentes.

Entra un nuevo equipo de detectives digitales llamado Multi-DES. En lugar de contratar a un solo detective para resolver cada caso en la nueva ciudad, o forzar a un "superdetective" a intentar comprender todos los vecindarios a la vez, este equipo utiliza una estrategia inteligente de dos pasos. Primero, audicionan a una multitud masiva de diferentes detectives, cada uno con su propio estilo y caja de herramientas, para ver qué grupo de expertos trabaja mejor al observar viejos expedientes de casos. Luego, cuando llega un nuevo caso, no solo eligen a un detective. En su lugar, observan los detalles específicos de ese nuevo caso e invocan instantáneamente al mejor experto para esa situación específica. Es como tener un equipo de especialistas donde un policía de tránsito se encarga de un accidente de coche, un contador forense se encarga de un caso de fraude y un negociador se encarga de una situación de rehenes, todos elegidos sobre la marcha. Los investigadores descubrieron que este enfoque de "el experto adecuado para el momento adecuado" es mucho mejor para encontrar errores en nuevos proyectos desconocidos que los métodos antiguos que intentaban usar la misma solución única para todo.

La Agencia de Detectives: Cómo funciona Multi-DES

En el mundo del software, un "defecto" es un bug: un error en el código que podría causar que el programa falle o se comporte de manera extraña. Predecir estos errores es crucial porque encontrarlos temprano ahorra tiempo y dinero. Pero aquí está el truco: para enseñar a una computadora cómo detectar un error, normalmente necesitas muchos ejemplos pasados de errores. Los proyectos nuevos aún no tienen estos ejemplos. Por eso, los ingenieros intentan tomar prestado el conocimiento de otros proyectos más antiguos. Esta es la parte de "Entre Proyectos" (Cross-Project).

Sin embargo, hay un gran obstáculo: el Desplazamiento de Distribución (Distribution Shift). Piensa en esto como intentar aprender a conducir en un país donde todos conducen por la izquierda, usando solo un manual escrito para un país donde todos conducen por la derecha. Las reglas son similares, pero los detalles están invertidos. En el software, un proyecto puede usar un estilo de codificación específico, mientras que otro usa uno completamente diferente. Los métodos tradicionales intentan construir un modelo gigante que intente entender todas estas diferencias a la vez. Los autores de este artículo argumentan que esto es como intentar usar un mapa genérico único para cada ciudad del mundo; es demasiado amplio y pierde de vista las calles locales.

El artículo propone Multi-DES (Selección de Conjuntos Dinámicos Multietapa), que es un poco como una agencia de contratación inteligente y adaptativa para detectives de software. Opera en dos etapas principales:

Etapa 1: La Gran Audición (Nivel de Proyecto)
Antes de que el sistema vea el nuevo proyecto, pasa por una fase de "sobreproducción" masiva. Imagina una convocatoria de casting donde prueban cada combinación posible de:

• Clasificadores Base: Diferentes tipos de algoritmos (como Árboles de Decisión, Bosques Aleatorios, etc.). Piensa en ellos como diferentes tipos de detectives (el observador, el lógico, el que detecta patrones).
• Técnicas de Selección Dinámica: Diferentes formas de decidir en qué detective confiar.
• Tamaños de Pool: Cuántos detectives hay en la sala.

Prueban todas estas combinaciones (4 algoritmos base × 8 técnicas de selección × 10 tamaños de pool = 320 configuraciones diferentes) en un conjunto de proyectos de "entrenamiento". Pero no solo eligen la que obtuvo la puntuación más alta en una sola prueba. En su lugar, utilizan una estrategia llamada Minimización de Rango Agregado (ARM).

La Estrategia ARM: El Juez "Todoterreno"
Imagina un concurso de talentos donde tienes que elegir a un ganador basado en el canto, el baile y la actuación. Si solo eliges a la persona con la mejor voz para cantar, podrían ser terribles actuando. ARM es como un juez que clasifica a cada concursante en todas las habilidades, luego suma sus rangos para encontrar a la persona que es el todoterreno más consistente. El artículo sugiere que, al observar múltiples métricas de rendimiento (como el F1-score, AUC y Falsas Alarmas) juntas, el sistema encuentra una configuración que es robusta y no fallará cuando el nuevo proyecto sea diferente de los anteriores.

Etapa 2: La Selección Sobre la Marcha (Nivel de Módulo)
Una vez que se elige la mejor configuración de la "audición", el sistema está listo para el nuevo proyecto. Pero aquí está la magia: no aplica un solo modelo a todo el proyecto. El software está hecho de muchos "módulos" (como habitaciones individuales en una casa o capítulos en un libro).

Cuando el sistema observa un módulo específico en el nuevo proyecto, pregunta: "¿Qué detective entrenado es mejor para detectar errores en este tipo específico de código?". Selecciona dinámicamente los clasificadores más competentes para esa pieza de código en particular. Si un módulo parece una aplicación bancaria, elige al "experto en finanzas" de su pool. Si otro módulo parece un motor de juego, elige al "experto en gráficos". Esto sucede en tiempo real, para cada pieza de código.

Lo que Encontraron

Los investigadores probaron esta idea en 82 proyectos de software de cuatro conjuntos de datos públicos diferentes (PROMISE, RELINK, NASA y AEEEM). Utilizaron un método de prueba estricto llamado "dejar un proyecto fuera" (leave-one-project-out), lo que significa que entrenaron en 81 proyectos e intentaron predecir los errores en el 82º, y luego repitieron esto para cada proyecto.

Los resultados fueron bastante prometedores:

• Mejor que lo Mejor: Multi-DES superó o igualó a los mejores métodos existentes en la mayoría de los escenarios. Específicamente, logró los mejores resultados para las métricas de AUC (una medida de qué tan bien el modelo distingue entre código con errores y código limpio) y Falsa Alarma (qué tan seguido da falsas alarmas) en la mayoría de los conjuntos de datos.
• Los Números: En el conjunto de datos AEEEM, Multi-DES obtuvo un AUC de 0.755, superando al siguiente mejor método (EASC-NB) que obtuvo 0.692. En el conjunto de datos NASA, obtuvo 0.737 en comparación con 0.666.
• Robustez: El sistema fue particularmente bueno manteniendo bajas las "Falsas Alarmas", lo que significa que no hizo perder el tiempo a los ingenieros revisando código que en realidad estaba bien.
• Sin Trampas: Crucialmente, el sistema hizo esto sin mirar ningún dato del nuevo proyecto objetivo durante la fase de entrenamiento. Dependió enteramente de los proyectos antiguos, demostrando que no necesitas espiar los secretos del nuevo proyecto para construir un buen predictor.

Lo que Descartaron

El artículo argumenta explícitamente contra la idea de que un modelo único y estático (un conjunto fijo de reglas aplicadas a todo el proyecto) es la mejor solución. Demuestran que, debido a que diferentes partes de un proyecto de software tienen diferentes características, un enfoque de "talla única" no generaliza bien cuando el nuevo proyecto es diferente de los datos de entrenamiento. También descartaron la idea de que necesites conocer la distribución de datos del proyecto objetivo de antemano para hacer buenas predicciones; su método funciona incluso cuando el proyecto objetivo es un misterio total.

¿Qué tan Seguros Están?

Los autores están seguros de sus hallazgos basándose en los datos que recolectaron. No solo simularon; realizaron experimentos extensos en 82 proyectos reales utilizando métricas estándar y ampliamente aceptadas. Utilizaron pruebas estadísticas (la prueba de rango con signo de Wilcoxon) para confirmar que sus resultados no fueron solo cuestión de suerte. El artículo afirma que Multi-DES es "estadísticamente superior" en la mayoría de las comparaciones por pares, particularmente para AUC y Falsa Alarma. Sin embargo, señalan una pequeña excepción: en el conjunto de datos PROMISE, su método no fue el absolutamente mejor para la métrica de "Falsa Alarma", mostrando que, aunque el método es fuerte, no es una solución mágica que gane siempre en cada escenario.

En resumen, Multi-DES sugiere que la mejor manera de predecir errores en un nuevo proyecto desconocido es tener un equipo diverso de expertos listos para ser llamados, y elegir al experto adecuado para el trabajo específico, en lugar de intentar forzar a un generalista a hacerlo todo.