Resumo Técnico: Diretrizes para Estudos Empíricos em Engenharia de Software Envolvendo Grandes Modelos de Linguagem (LLMs)

1. Problema e Contexto

Desde o lançamento do ChatGPT em 2022, os Grandes Modelos de Linguagem (LLMs) tornaram-se ubíquos na pesquisa e prática de Engenharia de Software (ES). No entanto, a reprodutibilidade e replicabilidade dos estudos empíricos que envolvem LLMs estão sob ameaça devido a três características intrínsecas desses modelos:

1. Não-determinismo: Pequenas variações em prompts ou configurações podem gerar resultados significativamente diferentes, mesmo com o mesmo modelo.
2. Dados de Treinamento Opacos: Modelos comerciais evoluem além de identificadores de versão fixos, e os detalhes de treinamento (dados, fine-tuning) frequentemente permanecem secretos, tornando difícil a reprodução exata.
3. Evolução Rápida: O desempenho relatado pode mudar rapidamente ao longo do tempo, tornando os achados de estudos obsoletos.

Além disso, as diretrizes existentes para estudos empíricos em ES (como experimentos controlados) não abordam essas especificidades dos LLMs, criando uma lacuna crítica na validação científica da área.

2. Metodologia

Este trabalho foi desenvolvido de forma colaborativa por 22 pesquisadores internacionais, seguindo um processo similar ao de outras diretrizes de relatórios em ciências (ex: CONSORT, TRIPOD-LLM). O processo incluiu:

• Início: Discussões na reunião da ISERN (2024) e no simposio CHASEAI (2024).
• Iteração: Reuniões quinzenais para definir a taxonomia de tipos de estudo e as diretrizes.
• Revisão por Pares: Cada seção foi refinada por pelo menos dois co-autores, seguida por revisões internas e externas por especialistas em ES empírica.
• Validação: Os autores realizaram uma autoavaliação contra as dimensões de qualidade dos SIGSOFT Empirical Standards.
• Recursos: As diretrizes são mantidas como um recurso "vivo" online (llm-guidelines.org).

3. Principais Contribuições

O artigo apresenta duas contribuições fundamentais para a comunidade de Engenharia de Software:

A. Taxonomia de 7 Tipos de Estudo

Os autores categorizaram o envolvimento de LLMs na pesquisa empírica em sete tipos distintos, cada um com desafios únicos:

1. LLMs como Anotadores (S1): Uso para codificar dados qualitativos (ex: entrevistas, requisitos) automaticamente.
2. LLMs como Juízes (S2): Uso para avaliar a qualidade de artefatos de software (ex: legibilidade de código, aderência a padrões).
3. LLMs para Síntese (S3): Integração e interpretação de informações de múltiplas fontes para gerar insights ou criar conjuntos de dados sintéticos.
4. LLMs como Sujeitos (S4): Simulação de comportamento humano em estudos (ex: simulação de usuários em testes de usabilidade).
5. Estudando o Uso de LLMs (S5): Pesquisa observacional sobre como engenheiros de software utilizam ferramentas baseadas em LLMs na prática.
6. LLMs para Novas Ferramentas de ES (S6): Desenvolvimento e avaliação de novas ferramentas que integram LLMs (ex: agentes autônomos, assistentes de código).
7. Benchmarking de LLMs (S7): Avaliação de desempenho de modelos em tarefas padronizadas de ES.

B. 8 Diretrizes de Relato (Must vs. Should)

O núcleo do artigo são oito diretrizes que distinguem requisitos obrigatórios (Must) de práticas recomendadas (Should). Cada diretriz é contextualizada pela taxonomia acima.

1. G1: Declarar Uso e Papel do LLM:

   • Obrigatório: Revelar explicitamente onde, como e qual LLM foi usado (ex: anotador, gerador de código).
   • Objetivo: Transparência para avaliação de viés e escopo.

2. G2: Reportar Versão, Configuração e Customizações:

   • Obrigatório: Reportar nome exato do modelo, versão, data do experimento, parâmetros (temperatura, seed), e detalhes de fine-tuning (dataset, hiperparâmetros).
   • Recomendado: Compartilhar pesos do modelo e dados de fine-tuning (se possível) ou justificar a não divulgação.

3. G3: Reportar Arquitetura da Ferramenta Além do Modelo:

   • Obrigatório: Descrever a arquitetura completa de ferramentas desenvolvidas (pré-processamento, RAG, agentes, lógica de orquestração).
   • Recomendado: Incluir diagramas arquitetônicos e detalhes de infraestrutura (hospedagem, latência).

4. G4: Reportar Prompts, Desenvolvimento e Logs de Interação:

   • Obrigatório: Publicar todos os prompts (ou templates com instâncias representativas) e estratégias de desenvolvimento.
   • Recomendado: Compartilhar logs completos de interação (prompts e respostas) como material suplementar para permitir a verificação da não-determinismo.

5. G5: Usar Validação Humana para Saídas de LLM:

   • Obrigatório: Quando métricas automáticas não capturam a validade de constructos subjetivos, validar com juízes humanos.
   • Recomendado: Reportar concordância inter-avaliadores (ex: Krippendorff's $\alpha$) e descrever instrumentos de medição.

6. G6: Usar um LLM Aberto como Baseline:

   • Recomendado: Incluir um modelo de código aberto (ex: Llama, Mistral) como linha de base para comparação com modelos comerciais, facilitando a replicação independente.

7. G7: Usar Baselines, Benchmarks e Métricas Adequadas:

   • Obrigatório: Justificar a escolha de métricas e benchmarks, discutindo sua validade de constructo.
   • Recomendado: Repetir experimentos devido à não-determinismo e reportar estatísticas descritivas (médias, intervalos de confiança) e testes inferenciais.

8. G8: Reportar Limitações e Mitigações:

   • Obrigatório: Discutir ameaças à validade (interna, externa, de constructo), não-determinismo, viés de dados e impactos ambientais.
   • Recomendado: Empregar estratégias de mitigação como replication packages, triangulação e análise de sensibilidade.

4. Resultados e Impacto Esperado

O artigo não apresenta resultados experimentais empíricos, mas sim um framework normativo para a comunidade. As principais implicações são:

• Padronização: Estabelece um padrão mínimo para relatórios de estudos envolvendo LLMs, permitindo comparações justas entre estudos.
• Reprodutibilidade: Ao exigir a divulgação de prompts, configurações e logs, reduz-se o "efeito caixa preta" dos modelos comerciais.
• Validade: A ênfase na validação humana e na discussão de viés (G5 e G8) protege a pesquisa contra conclusões errôneas baseadas apenas em métricas automáticas falhas.
• Ferramentas de Apoio: O artigo fornece uma Matriz de Aplicabilidade (mapeando quais diretrizes se aplicam a quais tipos de estudo) e uma Lista de Verificação (Checklist) para autores e revisores.

5. Significância

Este trabalho é fundamental para a maturidade da Engenharia de Software na era da IA Generativa. Sem essas diretrizes, a literatura de ES corre o risco de acumular resultados não replicáveis e não comparáveis devido à volatilidade dos LLMs. Ao tratar os LLMs não apenas como ferramentas, mas como componentes metodológicos que exigem rigor científico específico, os autores fornecem um caminho para garantir que a pesquisa em ES permaneça empírica, transparente e cumulativa.

O documento serve como um ponto de partida para revisores avaliarem manuscritos e para pesquisadores planejarem estudos robustos, equilibrando a eficiência dos LLMs com a necessidade de rigor científico.