Toward Linking Declined Proposals and Source Code: An Exploratory Study on the Go Repository

Aquí presento un resumen técnico detallado del artículo "Toward Linking Declined Proposals and Source Code: An Exploratory Study on the Go Repository", estructurado según los puntos solicitados.

1. El Problema

En el desarrollo de software, las enlaces de trazabilidad (conexiones entre artefactos como propuestas de contribución y el código fuente) son fundamentales para la comprensión del código, la localización de errores y la gestión del mantenimiento. Sin embargo, la investigación previa se ha centrado casi exclusivamente en las propuestas aceptadas e implementadas.

Las propuestas rechazadas (declined proposals) en proyectos de código abierto, como las discusiones en GitHub que no resultan en cambios de código, han sido ignoradas. Esto representa una pérdida de conocimiento valioso, ya que estas discusiones contienen:

• Racionalidad de diseño (por qué se rechazó una idea).
• Criterios implícitos de decisión.
• Alternativas de diseño fallidas.
• Información crucial para contribuyentes futuros (de hecho, el 14.7% de las propuestas rechazadas se reenvían más tarde).

El desafío principal es que, al no haber código implementado asociado a estas propuestas, es difícil establecer enlaces automáticos. Los métodos tradicionales de recuperación de trazabilidad (basados en similitud textual) fallan porque el código discutido no existe en el repositorio, lo que hace que la recuperación basada en embeddings sea ineficaz.

2. Metodología

Los autores proponen un pipeline impulsado por Modelos de Lenguaje Grande (LLM) diseñado específicamente para recuperar trazabilidad entre propuestas rechazadas y el código fuente relevante, incluso cuando el código no ha sido implementado.

El enfoque se basa en el repositorio oficial de Go (golang/go) y utiliza el modelo DeepSeek-V3.1. El pipeline se divide en tres fases principales, inspiradas en técnicas de localización de fallos (como Agentless) y recuperación aumentada por generación (RAG), pero adaptadas para razonamiento contextual:

Fases del Pipeline:

1. Fase 0: Decisión de Granularidad (Granularity Decision)

   • El LLM analiza el texto completo de la propuesta rechazada para determinar el nivel de granularidad del código al que debería vincularse.
   • Se definen tres niveles:
     • Directorio: Cambios en la estructura de paquetes (crear/mover archivos).
     • Archivo: Ediciones dentro de archivos existentes sin cambiar la estructura.
     • Función: Modificación de la lógica interna de funciones o métodos específicos.
   • Esta decisión dicta qué fases subsiguientes se ejecutarán.

2. Fase 1: Localización (Localization)

   • En lugar de usar embeddings vectoriales (que fallan al no haber código implementado), el LLM realiza una localización jerárquica basada en el contexto:
     • Nivel Directorio: Se proporciona al LLM una representación compacta del árbol de archivos del repositorio (similar al comando tree) junto con la propuesta. El modelo identifica los directorios candidatos.
     • Nivel Archivo: Dentro de los directorios seleccionados, el LLM identifica los archivos específicos.
     • Nivel Función: Para archivos seleccionados, el LLM analiza las firmas de funciones/métodos (sin el cuerpo completo del código para ahorrar contexto) y selecciona las funciones relevantes.

3. Fase 2: Decisión de Enlace (Link Decision)

   • El LLM recibe pares (Propuesta, Elemento de Código Localizado) y realiza una clasificación binaria: ¿Es este elemento de código relevante para la propuesta? (Sí/No).
   • Esto genera los enlaces finales de trazabilidad.

3. Contribuciones Clave

• Nueva Tarea de Investigación: Es el primer estudio que intenta establecer enlaces de trazabilidad entre propuestas rechazadas y código fuente, democratizando el acceso al conocimiento de decisiones de diseño fallidas.
• Enfoque Impulsado por LLM: Se diseña y evalúa un pipeline que utiliza LLMs no solo para la decisión de enlace, sino también para la localización y la determinación de granularidad, superando las limitaciones de los métodos basados en IR (Recuperación de Información) tradicionales en este contexto.
• Análisis de Fallos Detallado: Se realiza un análisis exhaustivo de por qué falla el pipeline, identificando patrones específicos en las discusiones de propuestas rechazadas que dificultan la recuperación de enlaces.
• Reproducibilidad: El paquete de replicación (datos, prompts, scripts) está disponible públicamente.

4. Resultados

El estudio se evaluó sobre 341 propuestas rechazadas del repositorio de Go.

• Precisión de Granularidad: El pipeline seleccionó la granularidad correcta (directorio, archivo o función) con una precisión promedio de 0.836.
  • Funcionó mejor a nivel de archivo (0.887) y directorio (0.696), pero tuvo dificultades a nivel de función (0.407).
• Precisión de Enlaces: La precisión media para generar enlaces correctos fue de 0.643.
  • La precisión fue más alta a nivel de archivo (0.688) y directorio (0.529).
  • La precisión a nivel de función fue significativamente baja (0.253), principalmente debido a errores en la selección de granularidad previa.
• Comparación con Baselines: En una prueba preliminar con propuestas aceptadas, el pipeline basado en LLM superó consistentemente a los métodos basados en RAG/Embeddings (como LiSSA) en métricas de F1 y precisión, validando su diseño.
• Análisis de Fallos (RQ2):
  • Longitud del texto: No se encontró correlación entre la longitud de la discusión y el rendimiento.
  • Causas de error:
    1. Falta de guía de implementación: El 42.9% de los fallos se debieron a que la discusión describía qué implementar pero no cómo ni dónde.
    2. Contenido obscuro: Información clave oculta en discusiones largas o confusas, o sugerencias de implementación contradictorias.
    3. Referencias implícitas: Cuando el código no se menciona explícitamente (Nivel 3 de explicitud), la precisión cae drásticamente (de ~0.84 a ~0.41).

5. Significado e Implicaciones

Este trabajo es significativo por varias razones:

1. Preservación del Conocimiento: Permite recuperar y hacer accesible la "razón de ser" de las decisiones de diseño fallidas, lo cual es vital para el mantenimiento a largo plazo y para evitar que los desarrolladores repitan errores.
2. Superación de Limitaciones Técnicas: Demuestra que los LLMs pueden razonar sobre la estructura del repositorio y el contexto de la discusión para inferir relaciones de trazabilidad incluso en ausencia de código implementado, algo donde los métodos tradicionales fallan.
3. Direcciones Futuras: Identifica que para mejorar la trazabilidad en propuestas rechazadas, es necesario:
   • Enriquecimiento de datos: Añadir contexto externo (comentarios de código, propuestas relacionadas) cuando la discusión es insuficiente.
   • Resumen inteligente: Generar resúmenes de las discusiones que destaquen la información clave y eliminen el ruido cuando la información está oculta en textos largos.

En conclusión, el estudio establece una base sólida para la minería de repositorios de software enfocada en el conocimiento no implementado, utilizando la inteligencia artificial para cerrar la brecha entre la discusión teórica y la estructura del código.