How Robustly do LLMs Understand Execution Semantics?

1. Problema e Motivação

Embora os Grandes Modelos de Linguagem (LLMs) demonstrem proficiência impressionante em tarefas de Engenharia de Software (como geração e reparo de código), permanece uma questão aberta: essa performance decorre de uma verdadeira compreensão semântica do código ou apenas de reconhecimento sofisticado de padrões?

A manutenção de software exige que os desenvolvedores prevejam o comportamento do código de forma robusta, independentemente de variações na estrutura do código, nas entradas ou nos caminhos de execução. O artigo investiga se os LLMs possuem essa capacidade de robustez. Especificamente, o estudo questiona se os modelos conseguem prever consistentemente a saída de um programa quando submetido a:

1. Perturbações nas entradas (valores de teste alterados).
2. Transformações no código que preservam o significado (MPTs - Meaning-Preserving Transformations).
3. Aumento na complexidade do fluxo de controle (número de decisões/loops).

Além disso, o estudo foca na capacidade dos modelos de prever exceções em tempo de execução, uma tarefa crítica para a depuração que é frequentemente ignorada em benchmarks padrão.

2. Metodologia

Os autores utilizaram o benchmark CruxEval, que exige que os modelos prevejam a saída exata de funções Python dadas entradas específicas. Para avaliar a robustez, eles introduziram três dimensões de perturbação:

• RQ1: Perturbação de Entrada (Input Perturbation):

  • Utilização de um algoritmo de mutação type-aware para gerar vizinhanças densas de entradas locais para cada programa.
  • Criação de um conjunto de dados estendido (CruxEvalexc) que inclui entradas que causam exceções em tempo de execução (ex: IndexError, TypeError, TimeoutError).
  • Definição de métricas de correção: "Any Match" (prever que alguma exceção ocorre) e "Strict Match" (prever o tipo exato ou mensagem da exceção).

• RQ2: Perturbação de Programa (Program Transformation):

  • Aplicação de Transformações que Preservam o Significado (MPTs): troca de operandos, troca de blocos, substituição de for por while, e inserção de código morto.
  • Renomeação de Variáveis: Substituição de identificadores por nomes genéricos baseados em distribuições de frequência de projetos reais (DyPyBench), testando a dependência do modelo em nomes específicos.

• RQ3: Decisões de Fluxo de Controle:

  • Uso de análise dinâmica (rastreamento/ tracing) para contar o número de decisões (condições if, iterações de loops) encontradas durante a execução.
  • Análise da correlação entre o número de decisões e a precisão do modelo.

• Modelos Avaliados:

  • Um conjunto diversificado de 14 modelos, incluindo modelos de código aberto (Qwen2.5, DeepSeek R1, Llama 3.1, Nemotron) e modelos de fronteira proprietários (GPT-5 Nano, GPT-5.2, Gemini 3 Pro).

3. Contribuições Principais

1. Definição de Métricas de Robustez: Introdução de métricas como Program-level Strict Robustness (PSR) (fração de programas onde o modelo acerta todas as entradas) e Robust Drop (RΔ) (queda de desempenho entre entradas canônicas e perturbadas).
2. Extensão do Benchmark CruxEval: Criação do conjunto CruxEvalexc para avaliar explicitamente a previsão de exceções, algo negligenciado em benchmarks anteriores.
3. Análise de Engenharia de Prompt: Investigação de como instruções explícitas sobre rastreamento de tipos e exceções afetam o desempenho, revelando a tendência de "sycophancy" (subserviência) dos modelos instruídos.
4. Descoberta de Discrepâncias de Robustez: Evidência de que modelos de fronteira, apesar de alta precisão em benchmarks estáticos, podem ser extremamente frágeis frente a perturbações sutis.

4. Resultados Chave

Desempenho Geral e Robustez (RQ1 e RQ2)

• Fragilidade do GPT-5.2: O modelo de fronteira GPT-5.2 obteve 99,12% de precisão no CruxEval original, mas sofreu uma queda drástica (RΔ de -19,52%) em entradas perturbadas e transformações de código, caindo para ~76-79%.
• Surpresa do GPT-5 Nano: O modelo menor (GPT-5 Nano) mostrou-se mais robusto que o GPT-5.2, mantendo alta precisão (~96%) mesmo com perturbações e sofrendo uma queda mínima (RΔ de -0,18%). Os autores hipotetizam que a quantização e o distillation podem atuar como regularizadores, evitando o overfitting.
• Desempenho do Gemini 3 Pro: Demonstrou alta robustez, com quedas mínimas e até ligeiras melhorias em cenários perturbados.
• Modelos Open-Source: Modelos com raciocínio (DeepSeek R1, Qwen2.5) mostraram ganhos significativos sobre suas versões base, mas ainda operam com precisão absoluta (PSR) muito menor que os modelos de fronteira (ex: ~30% vs ~56% para GPT-5.2).

Previsão de Exceções (RQ1)

• Queda Severa: A capacidade de prever exceções é muito inferior à previsão de saídas normais. O GPT-5.2 caiu de ~81% (entrada normal) para apenas 14,77% na previsão estrita de exceções.
• Viés de Prompt: O prompt original do CruxEval não mencionava exceções. Ao adicionar instruções explícitas para rastrear exceções, o desempenho do GPT-5.2 saltou para ~81%, revelando que a falha inicial era devido à falta de instrução, não necessariamente à incapacidade de raciocínio.
• Dificuldade com TypeError: O TypeError foi a exceção mais difícil de prever para todos os modelos, possivelmente devido à sua natureza de "catch-all" no Python.

Complexidade de Decisão (RQ3)

• Existe uma correlação negativa entre o número de decisões (loops, condições) e a precisão do modelo. À medida que o número de decisões aumenta, a acurácia cai.
• O GPT-5.2 e outros modelos mostram dificuldade crescente em raciocinar sobre caminhos de execução complexos, sugerindo deficiências na compreensão de iteração e controle de fluxo profundo.

Efeito das Intervenções de Prompt

• Prompts que instruem o modelo a rastrear tipos e exceções melhoraram drasticamente a previsão de exceções.
• Efeito Colateral Negativo: Para o GPT-5.2, o uso do prompt combinado (Tipos + Exceções) em entradas normais (sem exceções) causou uma queda de ~5% na precisão geral, pois o modelo começou a prever erroneamente exceções onde não havia (falsos positivos), possivelmente devido a uma tendência de "sycophancy" em seguir a instrução de buscar erros.

5. Significado e Conclusão

O estudo conclui que, embora os LLMs de fronteira pareçam dominar benchmarks de código estático, sua compreensão da semântica de execução não é robusta.

• Fragilidade: Pequenas mudanças na sintaxe ou nas entradas podem quebrar a capacidade de previsão do modelo, especialmente em modelos como o GPT-5.2.
• Limitação de "Entendimento": A incapacidade consistente de prever exceções e o declínio de desempenho com o aumento de decisões de controle sugerem que os modelos podem estar dependendo de heurísticas estatísticas superficiais em vez de simular a execução do programa.
• Recomendação: A avaliação de modelos de código deve ir além da precisão em benchmarks canônicos e incluir testes metamórficos (perturbações de entrada e código) e avaliações de previsão de exceções para medir a verdadeira robustez e confiabilidade para tarefas de manutenção de software.

O trabalho destaca que a "robustez" é uma métrica crítica que deve ser considerada ao confiar em LLMs para tarefas críticas de engenharia de software, como depuração e refatoração.