Leveraging Language Models to Discover Evidence-Based Actions for OSS Sustainability

Título: Aproveitando Modelos de Linguagem para Descobrir Ações Baseadas em Evidências para a Sustentabilidade de Software de Código Aberto (OSS)

1. O Problema: A Lacuna entre Previsão e Ação

O Software de Código Aberto (OSS) é fundamental para a infraestrutura tecnológica global, mas enfrenta um desafio crítico de sustentabilidade: estudos indicam que mais de 90% dos projetos OSS são eventualmente descontinuados.

• Previsão vs. Ação: Existe um corpo substancial de pesquisas que utiliza modelos de aprendizado de máquina para prever a sustentabilidade de projetos com base em sinais socio-técnicos (ex: atividade de desenvolvedores, frequência de lançamentos). No entanto, esses modelos raramente orientam os mantenedores sobre o que fazer quando um risco é identificado.
• A Lacuna: As características usadas para previsão são frequentemente abstratas (ex: centralidade na rede de desenvolvedores) e não oferecem recomendações acionáveis concretas. Há uma desconexão entre a previsão de risco e a intervenção prática baseada em evidências.
• Oportunidade: A literatura de engenharia de software (SE) acumula décadas de evidências empíricas sobre práticas que melhoram a saúde do projeto, mas essas descobertas estão dispersas e subutilizadas.

2. Metodologia: Pipeline de Extração com LLMs e RAG

Os autores propõem um pipeline automatizado e escalável para extrair ReACTs (Researched Actionables): recomendações concisas, orientadas à prática e ligadas a evidências empíricas de artigos científicos.

Etapas Principais:

1. Seleção do Corpus:
   • Foram analisados 829 artigos das principais conferências de Engenharia de Software (ICSE e FSE) publicados entre 2000 e 2025, filtrados por termos como "Open Source" ou "OSS".
2. Definição de ReACT:
   • Uma ReACT consiste em três componentes: Ação (prática implementável), Impacto (efeito nos resultados do projeto) e Evidência (base empírica do estudo original).
3. Pipeline de Processamento (RAG + Duas Camadas de Refinamento):
   • Arquitetura RAG (Retrieval-Augmented Generation): Utilizado para garantir que o LLM tenha acesso ao texto completo do artigo, evitando alucinações e garantindo contexto. O pipeline processa um artigo por vez, criando um único "chunk" de texto por documento para manter o contexto integral.
   • Camada 1: Extração e Seleção de Modelo:
     • Avaliação de 4 modelos de código aberto (Llama3-8B, Mixtral-8x7B, MistralLite-7B, Mistral-Nemo-12B) combinados com 3 técnicas de prompting (Zero-Shot, Chain-of-Thought, Reason+Action).
     • Um subconjunto de 10 artigos foi anotado manualmente para treinar/validar a seleção.
     • Resultado: A combinação Mixtral-8x7B com Chain-of-Thought (CoT) foi selecionada como a melhor para extração inicial.
   • Camada 2: Refinamento e Validação de Confiabilidade:
     • Um processo de follow-up prompting (perguntas subsequentes) foi aplicado aos ReACTs candidatos para:
       1. Filtrar Alucinações: Verificar se a ação foi explicitamente mencionada no artigo.
       2. Extrair Impacto e Evidência: Solicitar declarações explícitas de impacto e dados empíricos de suporte.
       3. Avaliar Qualidade: Classificar cada ReACT quanto à Solvidez (consistência lógica, sem contradições) e Precisão (clareza e especificidade da ação).

3. Contribuições Principais

1. Extração em Escala Corporal: A primeira aplicação de LLMs com RAG para extrair recomendações acionáveis de um corpus de 829 artigos de topo em SE, superando trabalhos anteriores que eram manuais e limitados a 186 artigos.
2. Pipeline de Validação em Duas Camadas: Introdução de um processo automatizado rigoroso que filtra alucinações e valida a solidez lógica e a precisão das recomendações geradas.
3. Categorização Orientada à Prática: Organização dos ReACTs em 8 categorias (ex: Onboarding de Novos Contribuidores, Padrões de Código, Testes Automatizados, Colaboração Comunitária), permitindo mapeamento direto para ações de mantenedores.
4. Integração Operacional (Estudos de Caso): Demonstração prática de como usar o catálogo de ReACTs em conjunto com a ferramenta APEX (Apache Project Explorer) para identificar pontos de virada em projetos e selecionar intervenções baseadas em evidências.

4. Resultados Quantitativos e Qualitativos

• Volume de Dados:
  • Extraídos 2.023 ReACTs candidatos.
  • Após filtragem de alucinações (101 removidos), restaram 1.922 ReACTs validados.
  • 1.312 ReACTs (68%) atenderam a todos os critérios de qualidade rigorosos (Solvidez + Precisão + Impacto explícito + Evidência explícita).
• Desempenho do Modelo:
  • O modelo Mixtral-8x7B com Chain-of-Thought superou significativamente os outros modelos em métricas de similaridade de texto (BLEU, ROUGE, BERTScore) e semântica.
• Validação Humana:
  • Uma amostra estratificada de 100 ReACTs foi validada manualmente.
  • A concordância entre anotadores humanos e o LLM foi alta: 98% para impacto, 87% para evidência, 96% para solvidez e 98% para precisão.
• Distribuição por Categoria:
  • A categoria Testes Automatizados e Garantia de Qualidade teve o maior número de ReACTs (31,6%).
  • A categoria Colaboração Comunitária teve a menor taxa de ReACTs "completos" (54%), sugerindo que a pesquisa sobre aspectos sociais é menos direta ou baseada em evidências quantitativas do que a pesquisa técnica.

5. Significado e Aplicações Práticas

O estudo demonstra como transformar achados acadêmicos dispersos em um catálogo estruturado e acionável.

• Fluxo de Trabalho para Mantenedores: Os autores propõem um fluxo de 5 passos para uso prático:
  1. Identificar pontos de virada (downturns) usando ferramentas como APEX.
  2. Analisar sinais socio-técnicos (ex: baixa contribuição, falta de colaboração).
  3. Mapear esses sinais para as categorias de ReACTs.
  4. Selecionar ReACTs baseados em evidências (priorizando os completos).
  5. Implementar e monitorar os resultados.
• Estudos de Caso: Foram apresentados dois casos do Apache Software Foundation Incubator (CommonsRDF e Tamaya). O estudo mostra como, se os mantenedores tivessem usado o catálogo de ReACTs durante fases de crise (identificadas pelo APEX), poderiam ter aplicado intervenções específicas (ex: melhorar o onboarding, reduzir conflitos de merge, diversificar contribuidores) para tentar reverter o declínio do projeto.

6. Conclusão

O trabalho preenche a lacuna crítica entre a previsão de sustentabilidade de OSS e a intervenção prática. Ao criar um catálogo de 1.312 ações baseadas em evidências, os autores fornecem uma ponte escalável e reprodutível entre a pesquisa acadêmica de décadas e a prática diária de manutenção de software. A abordagem valida que LLMs, quando combinados com pipelines de verificação rigorosos (RAG + prompts em camadas), podem minerar literatura científica complexa para gerar orientações acionáveis e confiáveis.