Resumen Técnico: Inestabilidad de Modelos en la Optimización de la Ingeniería de Software

1. Planteamiento del Problema

En la analítica de software, volver a ejecutar el mismo análisis sobre datos idénticos suele producir modelos y conclusiones diferentes. Este fenómeno, denominado inestabilidad de modelos, socava la confianza en las herramientas de ingeniería de software (SE) y limita su adopción práctica. Aunque la literatura previa ha reconocido la inestabilidad en dominios específicos (por ejemplo, predicción de defectos, minería de textos, descubrimiento causal), a menudo se trata como un "error" que debe corregirse con más datos o ensamble, o se descarta como ruido inevitable.

Este artículo argumenta que la inestabilidad no es simplemente ruido que deba tolerarse, sino una propiedad que puede medirse y gestionarse. Los autores distinguen entre dos tipos de inestabilidad:

• Inestabilidad Estructural: Variación en la forma del modelo, las características utilizadas y la topología del árbol (por ejemplo, diferentes árboles de decisión generados a partir de los mismos datos).
• Inestabilidad de Rendimiento: Variación en los resultados o recomendaciones producidos por los modelos (por ejemplo, diferentes configuraciones óptimas predichas).

El artículo postula que la inestabilidad estructural es a menudo una propiedad fundamental de los datos (el "Efecto Rashomon", donde muchos modelos estructuralmente diferentes se ajustan a los datos de igual manera) y puede ser irreducible. Sin embargo, la inestabilidad de rendimiento es el problema crítico para los profesionales, ya que determina si se puede confiar en una única ejecución de un optimizador para proporcionar recomendaciones consistentes.

2. Metodología

El estudio emplea un enfoque empírico a gran escala utilizando el repositorio MOOT, una colección de 127 problemas de optimización de software multiobjetivo.

Datos y Alcance

• Conjuntos de datos: 127 conjuntos de datos que abarcan configuraciones de software, salud del proyecto, predicción de defectos, pruebas y análisis de comportamiento.
• Escala: 12.700 casos de prueba retenidos en todos los conjuntos de datos.
• Aprendiz: El aprendiz principal es EZR, un optimizador de aprendizaje activo de vanguardia que construye árboles de decisión a partir de un presupuesto limitado de etiquetado.
• Diseño Experimental: Cada configuración se repite 20 veces con diferentes semillas aleatorias para medir la varianza.

Métricas

1. Estabilidad de Rendimiento: Medida mediante la tasa de acuerdo (porcentaje de casos de prueba donde 20 ejecuciones repetidas producen predicciones suficientemente similares) y la desviación estándar del error de optimización (distancia al cielo o distance-to-heaven).
2. Estabilidad Estructural: Medida utilizando la similitud de Jaccard ponderada de los conjuntos de características a través de los árboles de decisión, ponderando las características por su profundidad en el árbol.
3. Calidad de Optimización: Evaluada mediante la "distancia al cielo" (d2h) y el recuento estadístico de rangos superiores (top-rank counts) en todos los conjuntos de datos.

Intervenciones

Los autores probaron sistemáticamente seis factores para determinar su impacto en la inestabilidad:

1. Presupuesto de Etiquetado: El número de ejemplos etiquetados disponibles (10 a 200).
2. Estrategia de Adquisición: Reglas para seleccionar qué datos etiquetar a continuación (por ejemplo, near, Xplor, Xploit, adapt).
3. Complejidad del Modelo: Tamaño mínimo de la hoja en los árboles de decisión.
4. Criterio de División: Entropía frente a impureza de Gini.
5. Intervenciones Inspiradas en la Causalidad: Filtrado de confundidores y división por razón de ganancia (Gain-Ratio).
6. Localidad de los Datos: Uso de agrupamiento (clustering) (KMeans, HDBSCAM, CURE) para particionar datos heterogéneos antes del modelado.

3. Contribuciones Clave y Resultados

RQ0: Prevalencia de la Inestabilidad de Rendimiento

Bajo la configuración por defecto, las ejecuciones repetidas del optimizador estuvieron de acuerdo en solo el 2,9% de los casos de prueba (364 de 12.700). Incluso con un umbral muy permisivo, el acuerdo rara vez superó el 31,7%. Esto confirma que la inestabilidad de rendimiento es la norma, no la excepción, lo que hace que las recomendaciones de una sola ejecución no sean fiables.

RQ1: Naturaleza de la Inestabilidad (Estructural vs. Rendimiento)

El estudio encontró que la inestabilidad estructural y la de rendimiento están desacopladas.

• Hallazgo: Los cambios de configuración que mejoraron drásticamente la estabilidad de rendimiento (aumentando el acuerdo del 2,9% al 13,7%) casi no tuvieron efecto en la similitud estructural. Los árboles siguieron siendo estructuralmente diversos.
• Implicación: Los profesionales no deben esperar la misma estructura de modelo cada vez. La confianza debe basarse en recomendaciones consistentes, no en formas de modelo idénticas. La inestabilidad estructural es en gran medida irreducible debido al efecto Rashomon.

RQ2: Impulsores y Soluciones

Los autores identificaron cuatro factores de configuración clave que impulsan la inestabilidad de rendimiento y propusieron una configuración refinada que mejora la estabilidad sin sacrificar la calidad:

1. Presupuesto de Etiquetado: Aumentar de 20 a 50 etiquetas mejoró la estabilidad, pero las ganancias se saturaron más allá de 50.
2. Estrategia de Adquisición: Cambiar de Xploit (voraz/greedy) a near (selección de candidatos más cercanos al centroide actual más óptimo) produjo las ganancias de estabilidad más significativas (la estabilidad de rango superior aumentó de <50% a >80%) sin coste alguno.
3. Complejidad del Modelo: Un tamaño mínimo de hoja de 3 ofreció el mejor equilibrio entre estabilidad, rendimiento e interpretabilidad.
4. Criterio de División: Cambiar de Entropía a impureza de Gini proporcionó una victoria "gratuita" en estabilidad, ya que la Entropía es altamente sensible a eventos raros bajo presupuestos ajustados.

Resultados de la Configuración Refinada:

• Acuerdo: Aumentó del 2,9% al 13,7% (una mejora de 4,8 veces).
• Varianza del Error: Redujo la desviación estándar del error de optimización en un 22% (la media de la desviación estándar pasó de 17,4 a 13,6).
• Calidad: Los ajustes refinados lograron una calidad de optimización de rango superior estadístico en 119 de 127 conjuntos de datos, comparado con 74 para los valores por defecto.

RQ3: Límites de la Estabilidad

El estudio investigó si la inestabilidad restante se debía al aprendiz o a los datos.

• Intervenciones Causales: Añadir filtros de confundidores y razonamiento causal ayudó solo en conjuntos de datos específicos donde las características confundidas impulsaban la inestabilidad, pero no ofreció una mejora global significativa.
• Localidad de los Datos: Los métodos de agrupamiento (las familias de modelos más estables) estuvieron de acuerdo en menos del 51% de los casos de prueba.
• Conclusión: Existe un "suelo de estabilidad" determinado por los datos mismos (ruido, etiquetas escasas, objetivos proxy y la existencia de muchos modelos casi equivalentes). Ninguna intervención por parte del aprendiz puede eliminar completamente esta inestabilidad residual.

4. Significado y Reivindicaciones

El artículo sostiene que la inestabilidad de los modelos debe tratarse como un eje de evaluación estándar en la Ingeniería de Software Basada en Búsqueda (SBSE), medido y reportado rutinariamente junto con las métricas de rendimiento.

• Reencuadre del Objetivo: El objetivo no es forzar a que las ejecuciones repetidas produzcan árboles idénticos (lo cual es a menudo imposible debido al efecto Rashomon), sino asegurar que produzcan recomendaciones consistentes.
• Línea Base Accionable: Los ajustes refinados propuestos (50 etiquetas, adquisición near, hoja mín=3, división Gini) proporcionan una línea base contra la cual se pueden juzgar los futuros esfuerzos para reducir la inestabilidad en SBSE.
• Guía Práctica:
  1. Las herramientas de SE deben alejarse de los valores por defecto inestables (división por Entropía, adquisición voraz).
  2. Los artículos empíricos deben reportar tasas de acuerdo, no solo el rendimiento medio, para revelar el desacuerdo entre ejecuciones.
  3. Los investigadores deben evitar perseguir la estabilidad estructural por sí misma y reconocer que la inestabilidad tiene múltiples causas que requieren soluciones compuestas en lugar de una única "solución mágica".

Los autores concluyen que, si bien la inestabilidad no puede eliminarse por completo, puede gestionarse a un nivel que permita a los profesionales calibrar su confianza en cualquier ejecución individual de una herramienta de optimización.