Sequência de Avaliação de LLMs em Tarefas de Engenharia de Software

Para conduzir este estudo, utilizamos o benchmark SWE-bench como base de avaliação, evitando a reprodução do processo de benchmarking do zero. Os pesquisadores responsáveis pelo projeto mantêm uma tabela de classificação (leaderboard) pública do SWE-bench, atualizada regularmente à medida que novos modelos são lançados. Neste estudo, utilizamos esse leaderboard como referência: SWE-bench Leaderboard.

---

Fase 1: Coleta de Baseline e Materialização de Artefatos

Etapa 01 — Seleção do Repositório

Para a avaliação de benchmark, selecionamos a configuração RAG (Retrieval-Augmented Generation) GPT-4.0 de 02/04/2024 (20240402), conforme descrito no repositório de experimentos do SWE-bench:

🔗 shawnlewis/swebench-experiments

Nesse repositório e em seus forks associados, buscamos os dados brutos de previsão gerados pelos LLMs, bem como os artefatos produzidos durante a avaliação de benchmark. O repositório shawnlewis/swebench-experiments é um fork do repositório oficial SWE-bench/experiments e fornece acesso aos dados de avaliação e aos resultados associados aos experimentos do SWE-bench.

Dentro do diretório de avaliação, o repositório está organizado em subdiretórios correspondentes às diferentes variantes do benchmark, incluindo lite/, test/, verified/ e multimodal/. Nesses diretórios, as configurações de avaliação estão organizadas em pastas identificadas por uma data e por um modelo (ou configuração de avaliação). Para este estudo, selecionamos a configuração 20240402_rag_gpt4 dentro do diretório verified/.

O diretório 20240402_rag_gpt4 contém os arquivos e dados necessários para recuperar as previsões do modelo e avaliar os resultados do benchmark:

• all_preds.jsonl — contém as previsões geradas para as instâncias do SWE-bench;
• metadata.yaml — fornece os metadados associados à avaliação.

O arquivo README anexo identifica essa configuração como a linha de base (baseline) RAG do SWE-bench, na qual o BM25 é utilizado para recuperar trechos de código relevantes antes de serem fornecidos ao modelo de linguagem para a geração de um patch.

O arquivo all_preds.jsonl consiste em objetos JSON, com um objeto de previsão por linha. O código-fonte gerado pelo LLM é armazenado no campo model_patch, que contém o patch exato (ou diff string) proposto pelo modelo como solução para a issue correspondente no GitHub.

No contexto do SWE-bench, o modelo recebe uma issue de software juntamente com a base de código correspondente e deve gerar um patch que resolva o problema. Portanto, o campo model_patch fornece as alterações de código geradas pelo modelo no formato diff, e não o código-fonte completo dos arquivos modificados.

Etapa 02 — Extração dos Patches

⬆️ Voltar ao topo

Esta etapa envolve a extração das alterações de código geradas pelo LLM durante o benchmark SWE-bench Verified, para posterior análise estática com o SonarQube.

O arquivo all_preds.jsonl foi renomeado para all_preds-Verified-rag-gpt4.jsonl. Ele não contém arquivos de código-fonte completos e diretamente executáveis; em vez disso, contém os patches gerados pelo modelo no campo model_patch, representados no formato Unified Diff. Um patch descreve as alterações propostas pelo modelo, incluindo os arquivos afetados, as linhas adicionadas e removidas e as coordenadas de linha correspondentes. Portanto, o conteúdo do campo model_patch não pode ser submetido diretamente ao SonarQube como arquivo de código-fonte completo para análise estática.

Para calcular métricas de engenharia de software — como a Complexidade Ciclomática de McCabe, as Métricas de Halstead e a Complexidade Cognitiva —, o código-fonte precisa, primeiro, ser reconstruído em um estado sintaticamente válido. Ferramentas de análise estática dependem do parsing de arquivos-fonte reconhecidos pela linguagem e, conforme a ferramenta, constroem representações internas — como uma Árvore de Sintaxe Abstrata (AST) — para identificar estruturas do programa e calcular as métricas correspondentes. Conteúdo bruto de diff, contendo marcadores como +, - e @@, não constitui um arquivo-fonte válido e, portanto, não pode ser analisado como o programa resultante.

Consequentemente, a etapa de pré-processamento exige a reconstrução do estado do repositório após a aplicação das alterações geradas pelo LLM. O fluxo de processamento obrigatório baseia-se na extração dos patches, na sua aplicação aos repositórios correspondentes do SWE-bench e na geração dos arquivos-fonte modificados, que serão posteriormente submetidos às ferramentas de análise estática.

O script Python 1extracao01.py executa a primeira etapa desse fluxo: processa os patches contidos em all_preds-Verified-rag-gpt4.jsonl e extrai os patches aplicáveis para o diretório /patches_extraidos. Esses patches extraídos são então utilizados na etapa subsequente para reconstruir o estado modificado do repositório.

📄 Script de execução: 1extracao01.py 📄 Artefato gerado(saída): mapeamento_commits.json

Etapa 03 — Obtenção do Base Commit

⬆️ Voltar ao topo

O conjunto de dados Verified avaliado neste estudo, correspondente às previsões contidas em all_preds-Verified-rag-gpt4.jsonl, está associado ao dataset SWE-bench/SWE-bench_Verified, hospedado no Hugging Face.

Para recuperar o base_commit associado a cada instância do SWE-bench, foi utilizada a biblioteca Python datasets para acessar os registros correspondentes. O script 2mapear_base_commit.py foi desenvolvido para mapear cada instance_id ao seu respectivo base_commit. O mapeamento resultante é usado para reconstruir o estado do repositório existente antes da resolução da issue.

O fluxo de trabalho de reconstrução e análise do repositório consiste nas seguintes etapas:

1. Extração do Patch — extrair cada model_patch do arquivo JSONL e salvá-lo como um arquivo .patch individual.
2. Checkout do Repositório Base — utilizar o instance_id (ex.: django_django-16116) para identificar o repositório correspondente e realizar o checkout no base_commit exato, representando o estado do repositório anterior à aplicação da correção proposta.
3. Aplicação do Patch — aplicar o arquivo .patch gerado pela IA ao repositório base correspondente, utilizando um mecanismo como git apply. Isso gera o estado modificado do repositório contendo as alterações propostas pelo LLM.
4. Isolamento da Análise — configurar o arquivo sonar-project.properties utilizando o parâmetro sonar.inclusions para restringir a análise aos arquivos modificados pelo patch, evitando que os resultados sejam dominados por código pré-existente no repositório.

Como o diretório contendo os patches extraídos já existe — com cada patch nomeado segundo a convenção <instance_id>.patch (ex.: django_django-16116.patch) —, a automação subsequente pode ser realizada diretamente a partir desse diretório.

O script 2mapear_base_commit.py automatiza esse processo: lê os patches extraídos do diretório /patches_extraidos, deriva o instance_id de cada nome de arquivo, recupera as informações da instância correspondente no dataset do Hugging Face e gera o arquivo mapeamento_commits.json. Esse arquivo serve como índice mestre para a etapa subsequente de reconstrução do repositório e análise estática.

📄 Script de execução: 2mapear_base_commit.py 📄 Artefato gerado(saída): Criação da pasta/downloads patches = "./patches_extraidos"

---

Fase 2: Processamento Estático em Lote

Etapa 04 — Orquestração e Análise Estática com SonarQube

⬆️ Voltar ao topo

Para processar as 500 instâncias e enviá-las ao SonarQube, foi necessário orquestrar as etapas de clonagem do repositório, checkout do commit-base, aplicação do patch e invocação do SonarScanner. Antes da execução do script de automação (DT02-Sonar.py), foram identificados dois pré-requisitos técnicos obrigatórios relacionados à infraestrutura do SonarQube:

1. SonarScanner CLI — a ferramenta de linha de comando sonar-scanner foi instalada na máquina e configurada nas variáveis de ambiente (PATH). O script depende da chamada direta desse executável para iniciar as análises de cada instância.
2. Token de autenticação — por padrão, o SonarQube não permite submissões anônimas. A autenticação foi realizada via interface web (http://localhost:9000), no menu My Account > Security, onde foi gerado um token do tipo User Token. Esse token é injetado dinamicamente pelo script para autorizar a criação automática dos projetos e o envio dos resultados. Para executar o procedimento em outro ambiente, é necessário gerar um novo token e atualizar a variável correspondente no script.

O script de execução lê o arquivo de mapeamento (mapeamento_commits.json), provisiona os repositórios localmente — criando, quando necessário, o diretório /workspace_repos — e aciona a varredura via SonarScanner.

Em concordância com a metodologia estabelecida na Etapa 03, o parâmetro -Dsonar.inclusions é configurado para restringir o escopo da análise exclusivamente aos arquivos modificados pelo patch, evitando que os resultados sejam dominados por código pré-existente. De forma complementar, diretivas -Dsonar.exclusions são aplicadas aos arquivos de teste, garantindo que as métricas de Complexidade Ciclomática e Cognitiva não sejam artificialmente diluídas ou infladas pela presença de código de teste eventualmente alterado. O objetivo dessa configuração combinada é isolar o impacto das modificações estritamente no código de produção afetado pela IA.

Os resultados das análises são processados e armazenados pelo SonarQube no PostgreSQL. Após a conclusão da execução, os 500 projetos ficam disponíveis individualmente no dashboard local do SonarQube, permitindo a consulta e a extração das métricas de cada instância de forma independente.

📄 Script de execução: DT02-Sonar.py 📄 Artefato de saída: folder "./workspace_repos" 📄 Artefato de saída: folder "./cache_repos_mirror" 📄 Artefato de saída: progresso_sonar.json"

⏱️ Nota de desempenho: na primeira versão do script DT02-Sonar.py, a análise das 500 instâncias consumiu aproximadamente 125 horas de processamento contínuo. Esse tempo pode variar conforme o hardware utilizado e a velocidade da conexão de rede (acesso à internet).

Etapa 05 — Exportação das Métricas do SonarQube

⬆️ Voltar ao topo

Após a conclusão das análises das 500 instâncias, o script DT03-Export.py é responsável pela consolidação e exportação das métricas obtidas.

O script utiliza a Web API do SonarQube para consultar os resultados armazenados na instância local. Inicialmente, realiza a paginação dos projetos para recuperar as chaves (project keys) correspondentes às 500 instâncias analisadas. Em seguida, executa consultas individuais ao endpoint api/measures/component, obtendo as métricas associadas a cada projeto.

Os dados extraídos são consolidados em estruturas tabulares e exportados em dois formatos:

• CSV — arquivo principal destinado à análise e ao processamento posterior dos dados;
• JSON — arquivo de backup que preserva os dados retornados pela API em estrutura hierárquica, facilitando a auditoria e o eventual reprocessamento da extração.

Os arquivos resultantes são armazenados na unidade G:, mantendo uma cópia estruturada das métricas produzidas pelo SonarQube e permitindo que os resultados das 500 instâncias sejam posteriormente utilizados nas etapas de análise estatística e correlação com os demais dados do experimento.

Arquivos gerados:

• metricas_completas_swebench.csv
• metricas_completas_swebench.json
• erros_extracao_completa.log

📄 Script de execução: DT03-Export.py

---

Fase 3: Execução do LLM-as-a-Judge

Etapa 06 — Preparação dos Prompts para Avaliação LLM-as-a-Judge

⬆️ Voltar ao topo

Após a análise estática realizada pelo SonarQube, inicia-se a etapa de avaliação semântica dos patches gerados pelas LLMs. O script concatenar04-claude.py é responsável por preparar os dados e construir os prompts que serão utilizados posteriormente pelo LLM-as-a-Judge.

O script integra, em um único fluxo, o problema original registrado no dataset SWE-bench Verified (problem_statement) e o patch gerado pela LLM (model_patch), por meio das seguintes etapas:

1. Carregamento do dataset — o script carrega o dataset oficial princeton-nlp/SWE-bench_Verified, disponível no Hugging Face, utilizando a biblioteca datasets e a divisão test.
2. Indexação das instâncias — os registros do dataset são organizados em um dicionário indexado pelo campo instance_id. Para cada instância, é armazenado o respectivo problem_statement, permitindo sua recuperação direta durante o processamento.
3. Leitura das predições — o arquivo all_preds-Verified-rag-gpt4.jsonl é aberto e processado linha a linha; de cada registro são extraídos o instance_id e o model_patch gerado pela LLM.
4. Associação entre problema e patch — para cada instance_id, o script recupera o problem_statement correspondente no dataset. Em seguida, o problema original e o patch gerado são inseridos no template de prompt definido no próprio script.
5. Geração do payload de avaliação — para cada instância válida, é criado um registro contendo o instance_id, o system_prompt e o user_prompt. Esses registros são gravados em evaluation_payload.jsonl, que constitui a entrada estruturada para a etapa subsequente de avaliação pelo LLM-as-a-Judge.

O system_prompt estabelece os critérios utilizados na avaliação, incluindo correção semântica, efeitos colaterais e completude da solução. O juiz também deve produzir uma decisão (resolve_issue) e um nível de confiança (score_confianca) entre 1 e 5.

O script também realiza uma validação de correspondência entre as predições e o dataset: instâncias cujo instance_id não seja encontrado são ignoradas e contabilizadas no relatório final, junto com o número total de linhas processadas e de payloads efetivamente gerados. Dessa forma, o concatenar04-claude.py não executa diretamente a avaliação pelo LLM — sua função é preparar e estruturar, de maneira reproduzível, o conjunto de entradas que será submetido ao modelo avaliador na etapa seguinte.

📄 Script de execução: concatenar04-claude.py 📄 Artefato de saída: evaluation_payload.jsonl'

Nota de transparência metodológica: o texto do system_prompt utilizado na avaliação LLM-as-a-Judge foi refinado com o auxílio do modelo de linguagem Claude (Anthropic), utilizado como ferramenta de apoio à redação e à clareza dos critérios de avaliação. A definição dos critérios de julgamento, a validação do prompt final e a interpretação dos resultados permaneceram sob responsabilidade dos pesquisadores.

Etapa 07 — Avaliação Semântica com LLM-as-a-Judge

⬆️ Voltar ao topo

I. Estrutura de Persistência e Retomada da Execução

O run3_evaluation.py foi estruturado para realizar o processamento incremental utilizando arquivos no formato JSONL (JSON Lines).

O arquivo evaluation_payload.jsonl, produzido na etapa anterior, é processado linha a linha. Após cada avaliação bem-sucedida, o resultado é imediatamente serializado e gravado em evaluation_results.jsonl, seguido de outfile.flush(). Em caso de falha, a instância também é registrada no arquivo como um registro estruturado de erro.

No início da execução, o script verifica os resultados já persistidos e identifica as instâncias concluídas com sucesso, evitando seu reprocessamento. Instâncias associadas a erros permanecem elegíveis para nova tentativa.

Essa estratégia reduz a perda de processamento em execuções prolongadas e permite a retomada do processo após interrupções.

II. Configuração de Autenticação e Modelo

A execução requer uma chave de acesso à API do Google Gemini, disponibilizada por meio da variável de ambiente GEMINI_API_KEY. O script utiliza load_dotenv() para carregar as variáveis e verifica explicitamente a existência da credencial, interrompendo a execução caso ela não esteja disponível.

A chave não é armazenada no código-fonte. Exemplos de configuração:

# PowerShell
$env:GEMINI_API_KEY="sua_chave_aqui"

:: CMD
set GEMINI_API_KEY=sua_chave_aqui

A avaliação utiliza o modelo gemini-2.5-flash, com temperatura 0.0, buscando reduzir a variabilidade das respostas entre as instâncias.

III. Geração de Saída Estruturada

A função call_llm_judge() envia à API do Gemini o system_prompt e o user_prompt preparados na etapa anterior. O system_prompt define o papel do modelo como juiz de qualidade e os critérios de avaliação, enquanto o user_prompt fornece o contexto específico da instância.

A configuração response_mime_type="application/json" solicita uma resposta estruturada em JSON. O retorno é validado e convertido com json.loads(). Respostas vazias ou inválidas são tratadas como falhas e submetidas ao mecanismo de repetição.

O mecanismo de retry permite até cinco tentativas, utilizando espera exponencial entre as chamadas. Na implementação atual, as tentativas são acionadas de forma ampla diante de exceções, não estando restritas a tipos específicos de erro da API.

IV. Execução da Avaliação

Os caminhos de entrada e saída são definidos a partir da localização do próprio script. Para cada instância de evaluation_payload.jsonl, o run3_evaluation.py recupera os prompts, realiza a chamada ao modelo avaliador e associa a resposta ao respectivo instance_id.

Após o processamento, o resultado é persistido em evaluation_results.jsonl. Caso todas as tentativas falhem, a instância é mantida no arquivo com seu instance_id e a descrição do erro, permitindo posterior identificação e reprocessamento.

V. Natureza da Avaliação Realizada

Esta etapa realiza a avaliação semântica dos patches por meio de um LLM-as-a-Judge. Diferentemente da análise estática realizada pelo SonarQube — que avalia propriedades estruturais do código —, o juiz recebe o problema original e o patch gerado e verifica se a alteração atende semanticamente ao requisito.

Os critérios definidos no system_prompt abrangem correção semântica, efeitos colaterais e completude, produzindo um veredito (resolve_issue) e um nível de confiança (score_confianca).

Assim, o arquivo evaluation_results.jsonl representa a saída desta etapa, contendo os julgamentos estruturados do LLM associados aos respectivos instance_id.

📄 Script de execução: run3_evaluation.py 📄 Artefato gerado(saída): evaluation_results.jsonl

---

Fase 4: Análise Estatística Multidimensional

Etapa 08 — Traduzindo a Análise Semântica em Dados Estatísticos

⬆️ Voltar ao topo

Análise Semântica

Após a avaliação semântica realizada pelo LLM-as-a-Judge, os resultados foram persistidos em evaluation_results.jsonl. Cada registro contém o raciocinio_analitico, o veredito resolve_issue e o nível de confiança score_confianca.

O raciocinio_analitico é produzido a partir da análise do patch em relação à issue, considerando três critérios:

• Correção semântica — verifica se o patch implementa a lógica requerida e trata a causa-raiz do problema.
• Efeitos colaterais — verifica regressões, violações de contratos, invariantes e comportamentos inesperados.
• Completude — verifica o tratamento dos casos explicitamente descritos na issue e de edge cases críticos.

Extração das Métricas Semânticas

Uma segunda etapa de processamento utiliza o raciocinio_analitico como entrada para extrair três métricas ordinais de qualidade:

Métrica	Descrição
Índice de Profundidade da Correção (M_profundidade)	Avalia se a solução trata a causa-raiz ou apenas o sintoma.
Grau de Integridade Arquitetural (M_integridade)	Avalia a preservação da integridade do sistema e a ocorrência de regressões ou efeitos colaterais.
Índice de Cobertura Defensiva (M_defesa)	Avalia a completude da solução e sua capacidade de tratar casos de borda.

Cada métrica utiliza uma escala de 1 a 3. A classificação segue regras de inferência restrita: o avaliador deve utilizar exclusivamente as informações presentes no raciocinio_analitico. Quando não houver evidência suficiente para uma classificação superior, aplica-se o respectivo valor de fallback definido no critério.

O processamento também produz uma justificativa curta (just_*) para cada métrica, permitindo a auditoria por amostragem e a verificação da aderência do processo de julgamento aos critérios definidos.

Métrica de Consistência

Além das três métricas ordinais mencionadas anteriormente, o script calcula M_coerencia localmente, sem a necessidade de uma chamada de API adicional. Essa métrica avalia a consistência interna da saída do avaliador original, sinalizando qualquer contradição entre o veredicto de resolução do problema (resolve_issue) e o nível de confiança atribuído a ele (score_confianca). Ela é utilizada para fins de auditoria e não integra o conjunto de métricas de qualidade extraídas do raciocinio_analitico.

A métrica M_coerencia é binária (0 ou 1), conforme definido pela função calcular_m_coerencia(resolve_issue, score_confianca):

Valor	Classificação	Condição
0	Inconsistente	O problema é marcado como resolvido (resolve_issue é True) e o nível de confiança atribuído é baixo (score_confianca <= 2).
1	Consistente	Todos os demais casos.

Prompt de Extração

O prompt utilizado para a extração estabelece inferência restrita e saída estruturada, conforme apresentado abaixo:

[INÍCIO DO PROMPT]

Você atua como um avaliador de engenharia de software. A partir
exclusivamente do texto `raciocinio_analitico`, extraia três métricas
ordinais de qualidade.

Regra de inferência: não deduza informações que não estejam
explicitamente presentes no texto. Quando um critério for omisso,
utilize obrigatoriamente o valor de fallback correspondente.

M_profundidade — Índice de Profundidade da Correção
* 1: tratamento de sintoma, workaround ou ausência de correção da causa-raiz.
* 2: correção funcional do caso específico, sem evidência de tratamento da causa-raiz.
* 3: evidência explícita de correção ou tratamento da causa-raiz.

M_integridade — Grau de Integridade Arquitetural
* 1: regressões, violações de contratos, invariantes ou falhas arquiteturais.
* 2: degradação estrutural sem quebra funcional, como redundâncias ou lógica desnecessária.
* 3: ausência de efeitos colaterais negativos ou omissão de evidências de problemas.

M_defesa — Índice de Cobertura Defensiva
* 1: solução explicitamente incompleta ou incapaz de tratar cenários relevantes.
* 2: tratamento do caso específico da issue, sem evidência de cobertura adicional.
* 3: tratamento explícito de casos implícitos críticos ou adoção de mecanismos adicionais de robustez.

Retorne exclusivamente um objeto JSON válido:

{
  "M_profundidade": <inteiro de 1 a 3>,
  "just_profundidade": "<citação ou resumo de no máximo 15 palavras>",
  "M_integridade": <inteiro de 1 a 3>,
  "just_integridade": "<citação ou resumo de no máximo 15 palavras>",
  "M_defesa": <inteiro de 1 a 3>,
  "just_defesa": "<citação ou resumo de no máximo 15 palavras>"
}

Entrada:
Raciocínio Analítico: `{raciocinio_analitico}`

[FIM DO PROMPT]

Estrutura de Saída

O arquivo JSONL final contém dois blocos de dados distintos:

• LLM_Judge_Metrics — armazena as métricas ordinais (M_profundidade, M_integridade, M_defesa) e suas respectivas justificativas resumidas;
• Metadata_Metrics — armazena o resultado de M_coerencia juntamente com os campos originais (resolve_issue_original e score_confianca_original).

Processamento das Métricas

O script responsável pelo processamento percorre as 500 instâncias de evaluation_results.jsonl, insere o raciocinio_analitico no prompt e envia a solicitação ao modelo. A implementação utiliza:

• System Instructions — regras de avaliação e formato de saída isolados das entradas individuais;
• Saída estruturada — response_mime_type="application/json" para solicitar respostas JSON diretamente, dispensando processamento por expressões regulares;
• Resiliência — blocos try/except e backoff progressivo para tratar falhas e limites de taxa da API durante o processamento;
• Cálculo local — a Métrica 4 (M_coerencia) é calculada localmente pelo script, sem nova chamada à API.

O resultado desse processamento constitui a base para a consolidação das métricas semânticas e da análise multidimensional dos patches gerados pelas LLMs.

📄 Script de execução: processar_metricas.py 📄 Artefato gerado(saída): `metricas_estruturais_extraidas.jsonl´

Etapa 09: Processamento e Consolidação de Métricas

⬆️ Voltar ao topo

Este script atua como um pipeline de integração (ETL), consolidando as métricas provenientes de três dimensões de avaliação distintas — estrutural, semântica e funcional — em uma matriz tabular padronizada e otimizada para análise estatística multivariada.

Fluxo de Execução (Pipeline)

1. Ingestão de Dados Estruturais (SonarQube)

• Carrega métricas de análise estática de código (e.g., complexidade cognitiva, bugs, code smells).
• Entrada: metricas_completas_swebench.csv

2. Extração de Dados Semânticos (Avaliação via LLM)

• Realiza o parsing das inferências geradas, isolando as pontuações numéricas associadas às métricas heurísticas M_profundidade, M_integridade e M_defesa.
• Entrada: metricas_estruturais_extraidas.jsonl

3. Mapeamento de Dados Funcionais (pass@1)

• Processa o artefato de validação dos testes funcionais. Aplica codificação binária (boolean encoding) para o status de resolução: 1 (resolvido com sucesso) e 0 (falha). O arquivo (results.json) de referência foi extraído em: https://github.com/shawnlewis/swebench-experiments/blob/main/evaluation/verified/20240402_rag_gpt4/results/results.json. Ele foi renomeado para "results-20240402_rag_gpt4.json".
• Entrada: Arquivo JSON de resultados de execução.

4. Junção (Merge) e Sanitização

• Executa um inner join entre os três conjuntos de dados utilizando instance_id como chave primária.
• Promove a limpeza da base: retém exclusivamente as features numéricas de interesse do projeto e descarta registros incompletos ou inconsistentes (remoção de NAs).

5. Exportação (Output)

• Realiza o casting final para padronização dos tipos numéricos (inteiros e pontos flutuantes) e persiste o dataset unificado.
• Saída: matriz_consolidada.csv

📄 Script de execução: consolidar_valor.py 📄 Artefato gerado(saída): `matriz_consolidada.csv´

Etapa 10 - Testes de Normalidade (Shapiro-Wilk) e Estatísticos

⬆️ Voltar ao topo

Este script aplica os testes estatísticos na matriz de dados consolidada. Sua função no pipeline é avaliar a distribuição dos dados e computar a correlação das métricas independentes (estruturais e semânticas) com a variável dependente binária que indica o sucesso funcional do patch (pass@1).

1. Validação e Log de Desbalanceamento da Amostra:

• O código calcula a proporção exata de sucesso dividindo as instâncias resolvidas pelo total avaliado (n_resolvidas / n_total).
• Como mecanismo de controle, o script emite um alerta no console ([Nota de limitação]) informando o desbalanceamento das classes (sucesso vs. falha). Este passo serve para balizar as parametrizações da modelagem preditiva futura, com referência direta à seção 4.6 do artigo.

2. Seleção e Filtro de Features:

• O script sanitiza o dataframe para manter apenas as variáveis de interesse para o teste estatístico.
• Inclusões: Isola as três métricas semânticas (M_profundidade, M_integridade e M_defesa) e as métricas estruturais sqale_index e violations (utilizadas tecnicamente como proxies no experimento).
• Exclusões: Remove as colunas de code_smells e bugs da estrutura de dados antes do processamento matemático.

3. Execução dos Testes Matemáticos:

• Teste de Shapiro-Wilk: O algoritmo aplica o teste de Shapiro para aferir a normalidade da distribuição dos dados de cada métrica selecionada.
• Análise de Correlação e Valor-p: O script cruza cada métrica individualmente com o identificador pass@1. O objetivo da rotina é calcular a correlação e extrair o valor-p ((p-value)) de cada variável, estruturando a base numérica que será exportada ou plotada para a análise final do experimento (identificação de (p < 0.05)).

📄 Script de execução: CalcNormal-Spearma.py 📄 Artefato gerado(saída): matriz_correlação_spearman.csv´, matriz_p_values_spearman.csv´ e `figura heatmap.png´

Etapa 11: Análise Multidimensional e Modelagem Preditiva

⬆️ Voltar ao topo

Este script atua como um validador confirmatório. Sua função no pipeline é implementar um modelo de Regressão Logística Binária para estimar a probabilidade de sucesso funcional do patch gerado pela IA (pass@1), baseando-se em um subconjunto otimizado de variáveis independentes.

1. Transformação e Engenharia de Features:

• Aplica a transformação matemática log1p sobre os vetores das variáveis contínuas (cognitive_complexity e ncloc). Esta etapa é necessária para comprimir a escala dos dados, atenuar a assimetria (impacto de outliers) e mitigar efeitos de multicolinearidade antes da regressão.

2. Seleção de Variáveis e Definição do Modelo:

• O algoritmo parametriza o modelo preditivo com exatamente 4 features: M_profundidade, M_defesa, cognitive_complexity_log e ncloc_log.
• Realiza o descarte programático de variáveis que apresentam alta redundância estrutural ou que induzem à separação quase-perfeita (quasi-complete separation) dos dados (ex: M_integridade), garantindo a convergência do estimador de Máxima Verossimilhança.

3. Avaliação Estatística e Ajuste Logístico:

• Processa o cálculo do Fator de Inflação da Variância (VIF) nas variáveis preditoras para validar matematicamente a ausência de colinearidade severa.
• Instancia e ajusta o estimador da regressão logística (via módulo estatístico sm.Logit) e computa a matriz de Razão de Chances (Odds Ratio).

Saídas Padrão (Console Output)

Durante a execução, o script compila e exibe quatro blocos analíticos na saída padrão:

• Validação da Amostra (EPV): Reporta a proporção exata de resoluções (pass@1) no dataset e computa o indicador Events Per Variable (EPV). Este cálculo avalia tecnicamente se o volume de instâncias da classe minoritária suporta o número de variáveis inseridas no modelo, sinalizando limites de confiabilidade.
• Diagnóstico de Colinearidade (Matriz VIF): Renderiza uma tabela de VIF para cada preditor, classificando os índices em thresholds pré-definidos: OK (<5), Atenção (5–10) ou Problemático (≥10). O algoritmo anexa um laudo textual automático a esta saída.
• Sumário Estatístico (resultado.summary()): Imprime o dump completo do modelo de regressão, expondo os coeficientes ajustados ($\beta$), o erro padrão, as estatísticas z e os p-valores (p-values) associados a cada variável do modelo.
• Matriz de Razão de Chances (Odds Ratio): Exibe a inferência final sobre o peso de cada variável na resolução da issue, tabulando:
• Odds Ratio: O exponencial do coeficiente computado ($e^\beta$);
• Intervalo de Confiança (95%): Os limites probabilísticos inferior (2,5%) e superior (97,5%);
• P-valor: O índice de significância isolado de cada feature.

📄 Script de execução: Final2-3Analis-semant.py