Think Harder and Don't Overlook Your Options: Revisiting Issue-Commit Linking with LLM-Assisted Retrieval

1. Declaración del Problema

La trazabilidad del software depende de vincular los informes de problemas (por ejemplo, informes de errores, solicitudes de características) a los commits de código específicos que los resuelven. Aunque los desarrolladores suelen incluir manualmente identificadores de problemas en los mensajes de commit, esta práctica es inconsistente, lo que genera una brecha significativa en la trazabilidad. La Recuperación Automatizada de Vinculaciones Problema-Commit es esencial para el mantenimiento, la depuración y el análisis de la evolución.

Las técnicas automatizadas existentes van desde heurísticas simples hasta enfoques complejos de Aprendizaje Profundo (DL) y Modelos de Lenguaje Grande (LLM). Sin embargo, estudios recientes (por ejemplo, EasyLink) han introducido pipelines de dos etapas (recuperación + reordenamiento) utilizando LLMs y ventanas de tiempo específicas (por ejemplo, una ventana de un año posterior a la creación del problema) sin validar rigurosamente:

1. La universalidad de las ventanas de tiempo seleccionadas en diferentes conjuntos de datos.
2. Los métodos de recuperación óptimos (dispersos vs. densos) para reducir el espacio de búsqueda.
3. Si el costo computacional de los LLM está justificado en comparación con modelos de aprendizaje automático (ML) más simples y tradicionales para la etapa de reordenamiento.

2. Metodología

Los autores realizaron un estudio empírico exhaustivo que involucró tres conjuntos de datos distintos y un pipeline de dos etapas (Recuperación $\rightarrow$ Reordenamiento).

A. Conjuntos de Datos

El estudio utilizó y construyó tres conjuntos de datos para garantizar la generalización:

1. Conjunto de datos BTLink: 13 proyectos de Apache + 1 proyecto de GitHub (39k enlaces reales).
2. Conjunto de datos EasyLink: 20 proyectos de código abierto (159k enlaces reales). Nota: Apache Airflow fue excluido debido a problemas de migración de Jira a GitHub.
3. Conjunto de datos Apache (Nuevo): 10 proyectos populares de Apache (Spark, Hadoop, Solr, etc.) que utilizan Jira, recopilados de 2006 a 2025 (208k enlaces reales).
   Limpieza de datos: Los commits se filtraron para eliminar fusiones y cambios que no eran de código. Una validación manual de 400 enlaces confirmó un alto acuerdo entre evaluadores (kappa de Cohen = 0.93).

B. Pipeline Experimental

El estudio evaluó el pipeline en tres fases correspondientes a tres Preguntas de Investigación (PI):

• Fase 1: Optimización de la Ventana de Tiempo (PI1)

  • Se probaron diversos límites temporales: 1 año posterior a la creación, márgenes de 7 días/30 días alrededor del cierre del problema y combinaciones híbridas.
  • Objetivo: Determinar la ventana que capture el máximo número de enlaces reales sin introducir ruido excesivo.

• Fase 2: Evaluación del Método de Recuperación (PI2)

  • Recuperadores Dispersos: BM25, BM25L.
  • Recuperadores Densos: Búsqueda Semántica SBERT (SBERT-SS), HNSW, ANNOY, LSH.
  • Híbrido: Fusión de Rangos Recíprocos (RRF) combinando resultados dispersos y densos.
  • Métrica: Recall@K (para asegurar que el commit real esté en el conjunto de candidatos) y Precision@K.

• Fase 3: Evaluación de la Técnica de Reordenamiento (PI3)

  • Entrada: Los 20 mejores candidatos recuperados por el método de recuperación de mejor rendimiento (RRF).
  • Modelos Evaluados:
    • ML Tradicional: FRLink (TF-IDF), RCLinker (Random Forest con metadatos/texto), Hybrid-Linker.
    • Aprendizaje Profundo: BTLink (Bi-codificadores), Cross-Encoder (ms-marco-MiniLM).
    • LLM: GPT-5.1 (API), Llama-3.1-8B, Gemma-7B, Qwen3-32B (Local).
  • Restricción: Las claves de los problemas se eliminaron de los mensajes de commit para evitar la fuga de datos y forzar la comprensión semántica.

3. Contribuciones y Hallazgos Clave

PI1: Selección de Ventana de Tiempo

• Hallazgo: Una ventana rígida de "un año posterior a la creación" no es universalmente óptima. Aunque capturó el 97% de los enlaces en el conjunto de datos EasyLink, solo capturó ~91-94% en los conjuntos de datos BTLink y Apache.
• Insight: Existe una fuerte correlación entre los enlaces reales y la fecha de cierre del problema.
• Solución: Se propuso una heurística temporal híbrida (1 año posterior a la creación + 30 días antes/después del cierre del problema). Esto capturó >97% de los enlaces reales en los tres conjuntos de datos, equilibrando un alto recall con un espacio de búsqueda manejable.

PI2: Selección del Método de Recuperación

• Hallazgo: Los métodos de recuperación densa (incrustaciones semánticas) superan significativamente a los métodos dispersos (coincidencia de palabras clave) en el vinculado de Problema-Commit.
  • SBERT-SS logró el Recall@10 más alto (~82-88%).
  • Los métodos ANN (HNSW, ANNOY) ofrecieron un buen equilibrio, logrando un rendimiento cercano a SBERT-SS con mayor eficiencia.
  • Los métodos dispersos (BM25) tuvieron dificultades debido a la discrepancia de vocabulario entre las descripciones de los problemas y los mensajes de commit.
• Éxito Híbrido: Combinar métodos densos y dispersos mediante Fusión de Rangos Recíprocos (RRF) produjo el Recall más alto, aprovechando las fortalezas complementarias de ambos enfoques (comprensión semántica + coincidencia exacta de palabras clave).

PI3: Selección de la Técnica de Reordenamiento

• Hallazgo: Los modelos más simples a menudo superan o igualan a los LLM complejos.
  • RCLinker (un modelo Random Forest que utiliza metadatos y características textuales) logró el mejor rendimiento en todos los conjuntos de datos (por ejemplo, P@1 de 94.9% en Apache), superando tanto a los enfoques de Aprendizaje Profundo como a los de LLM.
  • LLM: El rendimiento fue mixto. Modelos grandes como GPT-5.1 y Qwen3-32B funcionaron bien (comparables a los Cross-Encoders), pero los modelos más pequeños (Llama, Gemma) fueron menos efectivos.
  • Relación Costo-Beneficio: RCLinker y los Cross-Encoders son computacionalmente económicos (minutos para entrenar/ejecutar, sin costos de API). En contraste, ejecutar GPT-5.1 en todo el conjunto de pruebas costó ~128 USD, escalando linealmente con el tamaño de los datos.
• Conclusión: El aumento de la complejidad del modelo no garantiza mejores resultados. Los modelos de ML tradicionales que aprovechan los metadatos del repositorio (solapamiento de desarrolladores, distancia temporal) siguen siendo altamente competitivos.

4. Significado e Implicaciones

• Revisión de Suposiciones: El artículo desafía la suposición de que "más grande es mejor" en el vinculado de Problema-Commit. Demuestra que los LLMs más avanzados no son estrictamente necesarios para un reordenamiento de alta precisión si se utiliza un pipeline de recuperación robusto y modelos tradicionales ricos en metadatos.
• Pipeline Práctico: Los autores proponen un pipeline práctico y rentable:
  1. Filtrar: Usar la ventana de tiempo híbrida (1 año + 30 días de cierre).
  2. Recuperar: Usar RRF (Denso + Disperso) para obtener los mejores candidatos.
  3. Reordenar: Usar un modelo ligero como RCLinker o un Cross-Encoder.
• Eficiencia de Recursos: Para aplicaciones industriales a gran escala, el pipeline propuesto evita los altos costos financieros y de hardware asociados a la inferencia de LLM, manteniendo una precisión superior o comparable.
• Trabajo Futuro: Los autores sugieren explorar prompts específicos de tareas para LLMs de código abierto más pequeños e investigar estrategias de fusión aprendidas para la recuperación.

Tabla Resumen de Resultados Clave

Componente	Mejor Desempeño	Insight Clave
Ventana de Tiempo	Híbrida (1 año + 30 días de cierre)	La ventana universal de 1 año falla; la fecha de cierre es crítica.
Recuperación	RRF (Denso + Disperso)	Denso > Disperso; La fusión maximiza el Recall.
Reordenamiento	RCLinker (Random Forest)	ML simple > LLM complejos; Los metadatos son cruciales.
Rendimiento LLM	GPT-5.1 / Qwen3-32B	Bueno, pero costoso; los LLM más pequeños tienen un rendimiento inferior.

Este estudio sirve como un "chequeo de realidad" crítico para la comunidad de ingeniería de software, abogando por un enfoque equilibrado que priorice la calidad de los datos, la estrategia de recuperación y la rentabilidad sobre la adopción ciega de LLMs costosos.