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

1. Declaração do Problema

A rastreabilidade de software depende da vinculação de relatórios de problemas (por exemplo, relatórios de bugs, solicitações de recursos) aos commits de código específicos que os resolvem. Embora os desenvolvedores frequentemente incluam manualmente identificadores de problemas nas mensagens de commit, essa prática é inconsistente, levando a uma lacuna significativa na rastreabilidade. A Recuperação de Vinculação Issue-Commit automatizada é essencial para manutenção, depuração e análise de evolução.

As técnicas automatizadas existentes variam de heurísticas simples a abordagens complexas de Aprendizado Profundo (DL) e Modelos de Linguagem de Grande Escala (LLM). No entanto, estudos recentes (por exemplo, EasyLink) introduziram pipelines de dois estágios (recuperação + reclassificação) usando LLMs e janelas de tempo específicas (por exemplo, uma janela de um ano após a criação do problema) sem validar rigorosamente:

1. A universalidade das janelas de tempo selecionadas em diferentes conjuntos de dados.
2. Os métodos de recuperação ótimos (esparso vs. denso) para estreitar o espaço de busca.
3. Se o custo computacional dos LLMs é justificado em comparação com modelos de aprendizado de máquina (ML) mais simples e tradicionais para o estágio de reclassificação.

2. Metodologia

Os autores conduziram um estudo empírico abrangente envolvendo três conjuntos de dados distintos e um pipeline de dois estágios (Recuperação → Reclassificação).

A. Conjuntos de Dados

O estudo utilizou e construiu três conjuntos de dados para garantir generalizabilidade:

1. Conjunto de Dados BTLink: 13 projetos Apache + 1 projeto GitHub (39k links verdadeiros).
2. Conjunto de Dados EasyLink: 20 projetos de código aberto (159k links verdadeiros). Nota: O Apache Airflow foi excluído devido a problemas de migração do Jira para o GitHub.
3. Conjunto de Dados Apache (Novo): 10 projetos Apache populares (Spark, Hadoop, Solr, etc.) usando Jira, coletados de 2006 a 2025 (208k links verdadeiros).
   Limpeza de Dados: Os commits foram filtrados para remover mesclagens e alterações não relacionadas a código. Uma validação manual de 400 links confirmou um alto acordo entre avaliadores (kappa de Cohen = 0,93).

B. Pipeline Experimental

O estudo avaliou o pipeline em três fases correspondentes a três Questões de Pesquisa (RQs):

• Fase 1: Otimização da Janela de Tempo (RQ1)

  • Testou vários limites temporais: 1 ano após a criação, buffers de 7 dias/30 dias ao redor do fechamento do problema e combinações híbridas.
  • Objetivo: Determinar a janela que captura o máximo número de links verdadeiros sem introduzir ruído excessivo.

• Fase 2: Avaliação do Método de Recuperação (RQ2)

  • Recuperadores Esparsos: BM25, BM25L.
  • Recuperadores Densos: SBERT-Busca Semântica (SBERT-SS), HNSW, ANNOY, LSH.
  • Híbrido: Reciprocal Rank Fusion (RRF) combinando resultados esparsos e densos.
  • Métrica: Recall@K (para garantir que o commit verdadeiro esteja no conjunto de candidatos) e Precision@K.

• Fase 3: Avaliação da Técnica de Reclassificação (RQ3)

  • Entrada: Top 20 candidatos recuperados pelo método de recuperação de melhor desempenho (RRF).
  • Modelos Avaliados:
    • ML Tradicional: FRLink (TF-IDF), RCLinker (Random Forest com metadados/texto), Hybrid-Linker.
    • Aprendizado Profundo: BTLink (Bi-encoders), Cross-Encoder (ms-marco-MiniLM).
    • LLMs: GPT-5.1 (API), Llama-3.1-8B, Gemma-7B, Qwen3-32B (Local).
  • Restrição: As chaves dos problemas foram removidas das mensagens de commit para evitar vazamento de dados e forçar a compreensão semântica.

3. Contribuições e Descobertas Principais

RQ1: Seleção de Janela de Tempo

• Descoberta: Uma janela rígida de "um ano após a criação" não é universalmente ótima. Embora tenha capturado 97% dos links no conjunto de dados EasyLink, capturou apenas ~91-94% nos conjuntos de dados BTLink e Apache.
• Insight: Há uma forte correlação entre links verdadeiros e a data de fechamento do problema.
• Solução: Foi proposta uma heurística temporal híbrida (1 ano após a criação + 30 dias antes/depois do fechamento do problema). Isso capturou >97% dos links verdadeiros em todos os três conjuntos de dados, equilibrando alto recall com um espaço de busca gerenciável.

RQ2: Seleção do Método de Recuperação

• Descoberta: Os métodos de recuperação densa (embeddings semânticos) superam significativamente os métodos esparsos (correspondência de palavras-chave) no vinculamento Issue-Commit.
  • SBERT-SS alcançou o maior Recall@10 (~82-88%).
  • Métodos ANN (HNSW, ANNOY) ofereceram um forte compromisso, alcançando desempenho próximo ao SBERT-SS com melhor eficiência.
  • Métodos esparsos (BM25) lutaram devido à incompatibilidade de vocabulário entre descrições de problemas e mensagens de commit.
• Sucesso Híbrido: Combinar métodos densos e esparsos via Reciprocal Rank Fusion (RRF) produziu o maior Recall, aproveitando as forças complementares de ambas as abordagens (compreensão semântica + correspondência exata de palavras-chave).

RQ3: Seleção da Técnica de Reclassificação

• Descoberta: Modelos mais simples frequentemente superam ou igualam LLMs complexos.
  • RCLinker (um modelo Random Forest usando metadados e recursos textuais) alcançou o maior desempenho em todos os conjuntos de dados (por exemplo, P@1 de 94,9% no Apache), superando tanto as abordagens de Aprendizado Profundo quanto de LLM.
  • LLMs: O desempenho foi misto. Modelos grandes como GPT-5.1 e Qwen3-32B performaram bem (comparáveis aos Cross-Encoders), mas modelos menores (Llama, Gemma) foram menos eficazes.
  • Custo-Benefício: RCLinker e Cross-Encoders são computacionalmente baratos (minutos para treinar/executar, sem custos de API). Em contraste, executar o GPT-5.1 no conjunto de testes completo custou ~128 USD, escalando linearmente com o tamanho dos dados.
• Conclusão: O aumento da complexidade do modelo não garante melhores resultados. Modelos de ML tradicionais que aproveitam metadados do repositório (sobreposição de desenvolvedores, distância temporal) permanecem altamente competitivos.

4. Significado e Implicações

• Revisão de Suposições: O artigo desafia a suposição de que "maior é melhor" no vinculamento Issue-Commit. Demonstra que LLMs de última geração não são estritamente necessários para reclassificação de alta precisão se um pipeline de recuperação robusto e modelos tradicionais ricos em metadados forem utilizados.
• Pipeline Prático: Os autores propõem um pipeline prático e econômico:
  1. Filtrar: Use a janela de tempo híbrida (1 ano + 30 dias de fechamento).
  2. Recuperar: Use RRF (Denso + Esparso) para obter os principais candidatos.
  3. Reclassificar: Use um modelo leve como RCLinker ou um Cross-Encoder.
• Eficiência de Recursos: Para aplicações industriais em grande escala, o pipeline proposto evita os altos custos financeiros e de hardware associados à inferência de LLMs, mantendo precisão superior ou comparável.
• Trabalho Futuro: Os autores sugerem explorar prompts específicos para tarefas em LLMs de código aberto menores e investigar estratégias de fusão aprendidas para recuperação.

Tabela Resumo dos Resultados Principais

Componente	Melhor Desempenho	Insight Chave
Janela de Tempo	Híbrida (1 ano + 30 dias de fechamento)	Janela universal de 1 ano falha; data de fechamento é crítica.
Recuperação	RRF (Denso + Esparso)	Denso > Esparso; Fusão maximiza o Recall.
Reclassificação	RCLinker (Random Forest)	ML Simples > LLMs Complexos; Metadados são cruciais.
Desempenho LLM	GPT-5.1 / Qwen3-32B	Bom, mas caro; LLMs menores performam pior.

Este estudo serve como um "teste de realidade" crítico para a comunidade de engenharia de software, defendendo uma abordagem equilibrada que prioriza a qualidade dos dados, a estratégia de recuperação e o custo-benefício em detrimento da adoção cega de LLMs caros.