Do Code LLMs Do Static Analysis?

Título: Do Code LLMs Do Static Analysis?

Autores: Chia-Yi Su e Collin McMillan (Universidade de Notre Dame)
Publicação: Aceito na Empirical Software Engineering (arXiv:2505.12118v2)

---

1. Problema e Motivação

O artigo investiga uma questão fundamental sobre a natureza cognitiva dos Modelos de Linguagem de Grande Escala (LLMs) especializados em código: os LLMs realizam análise estática da mesma forma que os programadores humanos?

• Contexto: A cultura popular e a literatura científica frequentemente atribuem características antropomórficas aos LLMs, como "raciocínio" e "criatividade". Programadores humanos utilizam a análise estática (examinar o código sem executá-lo) como parte central do processo de compreensão de software, construindo modelos mentais baseados em:
  1. Grafos de chamada (call graphs).
  2. Fluxo de dados (data flow).
  3. Árvores de Sintaxe Abstrata (AST).
• Hipótese: Se os LLMs seguissem um processo semelhante ao humano, esperar-se-ia que:
  1. Eles tivessem um desempenho forte em tarefas de análise estática.
  2. O treinamento em tarefas de análise estática melhorasse o desempenho em tarefas de inteligência de código (geração, resumo, tradução).
  3. O treinamento em tarefas de código resultasse na capacidade de realizar análise estática como um subproduto.
• Objetivo: O estudo visa determinar se os LLMs realmente "pensam" através da análise estática ou se apenas aprendem padrões superficiais (forma) sem compreender a semântica profunda.

2. Metodologia

Os autores conduziram experimentos abrangentes envolvendo quatro modelos (dois de código aberto e dois fechados) e duas linguagens de programação (Java e C/C++).

Modelos Utilizados:

• Código Aberto: JAM (350M parâmetros, focado em Java) e CodeLlama-Instruct (13B parâmetros).
• Código Fechado (Comerciais): GPT-4o e Gemini.

Tarefas de Análise Estática (Entrada/Saída):

1. Geração de AST: Produzir a representação XML (srcML) da estrutura sintática.
2. Geração de Grafo de Chamada: Identificar quais métodos chamam outros.
3. Geração de Grafo de Fluxo de Dados: Rastrear como os dados fluem entre variáveis e métodos.

Tarefas de Inteligência de Código (Desempenho):

1. Resumo de Código: Gerar descrições em linguagem natural.
2. Tradução de Código: Converter código entre linguagens.
3. Geração de Código: Criar código a partir de prompts em linguagem natural.

Configuração Experimental (Perguntas de Pesquisa - RQs):

• RQ1: Desempenho de modelos fechados em tarefas de análise estática (sem fine-tuning).
• RQ2: Desempenho de modelos abertos em análise estática após fine-tuning específico para essas tarefas.
• RQ3: O fine-tuning em análise estática melhora o desempenho em tarefas de desenvolvimento de código?
• RQ4: O fine-tuning em tarefas de código melhora o desempenho em tarefas de análise estática (subproduto)?
• RQ5: Quais são os tipos de erros mais comuns cometidos pelos LLMs?

Métricas de Avaliação:

• Distância de Levenshtein (para AST).
• Similaridade de Jaccard, Precisão de Pares e Precisão de Cadeia (para grafos).
• METEOR, USE, BLEU e CodeBERTScore (para tarefas de código).
• Pass@k e Taxa de Compilação (para execução).

3. Resultados Principais

Desempenho em Análise Estática (RQ1 e RQ2)

• Desempenho Geral: Os LLMs apresentaram desempenho pobre em tarefas de análise estática complexas (grafos de chamada e fluxo de dados), mesmo com in-context learning (ICL).
• AST: A geração de AST foi a única tarefa onde o ICL e o fine-tuning mostraram melhorias significativas. Isso sugere que os modelos conseguem aprender a "forma" (tags XML) mais facilmente do que a semântica.
• Grafos de Chamada e Fluxo de Dados:
  • Modelos fechados (GPT-4o, Gemini) tiveram desempenho muito baixo (ex: precisão de cadeia próxima de zero).
  • O fine-tuning em modelos abertos melhorou ligeiramente a precisão de pares e similaridade de Jaccard, mas não melhorou a precisão de cadeia (a estrutura completa do grafo).
  • O uso de prompts de raciocínio ("Let's think step by step") não melhorou os resultados.

Transferência de Aprendizado (RQ3 e RQ4)

• Análise Estática $\rightarrow$ Código: O fine-tuning em tarefas de análise estática não melhorou significativamente o desempenho em tarefas de resumo, geração ou tradução de código.
  • Exemplo: Modelos pré-treinados em AST ainda geravam resumos que copiavam jargões técnicos sem compreender a lógica, e cometiam os mesmos erros lógicos em tarefas de geração de código.
• Código $\rightarrow$ Análise Estática: O fine-tuning em tarefas de inteligência de código não resultou na capacidade de realizar análise estática. Os modelos treinados para gerar código falharam drasticamente ao tentar gerar grafos de chamada ou fluxo de dados.

Análise de Erros (RQ5)

• Tipos de Erros Comuns:
  • Grafos de Chamada: Erros frequentes incluem chamadas diretas extras (extra direct calls) e a previsão incorreta de ciclos (cycles) onde não existem.
  • Fluxo de Dados: Predominância de arestas diretas extras e indiretas extras.
  • AST: Erros de incompatibilidade de tags (tag mismatch) e nós faltantes.
• Conclusão sobre Erros: Os modelos tendem a alucinar conexões que são semanticamente plausíveis, mas estruturalmente incorretas, indicando falta de compreensão do contexto global e das dependências reais.

4. Contribuições Chave

1. Evidência Empírica Contra o "Raciocínio" Humano: O estudo fornece evidências robustas de que os LLMs atuais não utilizam análise estática como um processo intermediário de pensamento para realizar tarefas de programação, diferentemente dos humanos.
2. Separação entre Forma e Semântica: Demonstra que os LLMs aprendem eficazmente a "forma" (sintaxe, tags, padrões superficiais) dos dados de treinamento, mas falham em internalizar a "semântica" (lógica de execução, fluxo de dados, dependências reais).
3. Falta de Generalização: Mostra que o treinamento em uma área (análise estática) não se generaliza para melhorar a outra (desenvolvimento de código) e vice-versa, sugerindo que essas habilidades são aprendidas de forma isolada e não integrada.
4. Limitações de In-Context Learning e Chain-of-Thought: Evidencia que técnicas populares de prompt engineering (como ICL e raciocínio passo a passo) são insuficientes para superar a falta de capacidade de raciocínio semântico profundo em tarefas complexas de análise de código.

5. Significância e Implicações

• Para Pesquisa em Engenharia de Software: O artigo desafia a suposição de que aumentar o tamanho do modelo ou o volume de dados de treinamento levará automaticamente a uma compreensão semântica mais profunda. Sugere que novas arquiteturas de modelos ou procedimentos de treinamento são necessários para mimetizar o raciocínio humano baseado em modelos mentais de software.
• Para Ferramentas de IA: Desenvolvedores de ferramentas de IA para código devem ter cautela ao confiar em LLMs para tarefas que exigem compreensão profunda de dependências (como refatoração segura, detecção de bugs complexos ou análise de impacto), pois o modelo pode parecer correto sintaticamente, mas falhar semanticamente.
• Para o Futuro dos LLMs: A pesquisa aponta para a necessidade de integrar explicitamente ferramentas de análise estática tradicionais (como compiladores e analisadores de fluxo de dados) no processo de inferência dos LLMs, em vez de depender puramente da capacidade interna do modelo de "raciocinar" sobre o código.

Em resumo, o artigo conclui que, embora os LLMs sejam excelentes em tarefas de superfície e geração de código sintaticamente válido, eles não realizam análise estática da maneira que os humanos o fazem, carecendo de um entendimento real da semântica e das relações estruturais complexas do código.