CONCUR: Benchmarking LLMs for Concurrent Code Generation

Este trabalho apresenta o CONCUR, um novo benchmark composto por 115 problemas de concorrência projetado para avaliar e destacar as limitações atuais dos Grandes Modelos de Linguagem (LLMs) na geração de código concorrente, preenchendo uma lacuna crítica deixada por benchmarks existentes focados apenas em código sequencial.

O essencial

Imagine que você está pedindo para um chef de cozinha muito inteligente (a Inteligência Artificial) preparar um prato complexo.

Até hoje, os testes para ver se esse chef é bom focavam em pratos simples, como um bife ou uma salada, onde você cozinha um ingrediente de cada vez, na ordem certa. Isso é o que chamamos de código sequencial.

Mas, no mundo real da tecnologia, os programas modernos são como orquestras ou cozinhas de restaurante lotadas. Múltiplos chefs (chamados de "fios" ou threads) precisam trabalhar ao mesmo tempo na mesma mesa, usando os mesmos ingredientes. Se eles não coordenarem bem, o caos reina: um chef tenta pegar a faca enquanto o outro segura, ou dois tentam usar o mesmo forno ao mesmo tempo. Isso é o código concorrente.

O problema é que os testes antigos não conseguiam ver se a orquestra estava tocando junta ou se cada músico estava tocando sua própria música, bagunçando tudo.

Aqui entra o CONCUR, o novo "exame" criado pelos pesquisadores deste artigo.

O que é o CONCUR?

Pense no CONCUR como um laboratório de testes de trânsito para carros autônomos. Em vez de testar se o carro anda em linha reta (código simples), eles testam se o carro consegue navegar em um cruzamento movimentado, onde outros carros passam por todos os lados, sem bater, sem travar e sem ficar parado para sempre.

O CONCUR é composto por três partes principais:

1. O Manual de Trânsito (O Dataset): Os pesquisadores pegaram 43 problemas clássicos de "trânsito" (problemas de concorrência) de um livro didático famoso. Eles não apenas copiaram o livro; eles reescreveram as perguntas para que a IA entendesse exatamente o que fazer. Depois, criaram 72 variações dessas perguntas (como mudar a cor do carro ou o número de pedestres) para garantir que a IA não estivesse apenas "decoreba" (memorizando a resposta), mas realmente entendendo a lógica. No total, são 115 desafios.
2. O Detetive de Acidentes (JPF - Java PathFinder): Aqui está a mágica. Normalmente, quando você testa um código, você o roda uma vez. Se não der erro, parece bom. Mas em programas concorrentes, o erro pode acontecer apenas se o "trânsito" seguir um caminho muito específico e raro.
   • O CONCUR usa uma ferramenta chamada JPF que age como um simulador de realidade virtual. Ele roda o programa da IA milhares de vezes, tentando todas as combinações possíveis de quem faz o quê e quando. É como se o detetive dissesse: "E se o carro A passar antes do B? E se o B esperar 1 segundo a mais? E se os dois entrarem na curva juntos?".
   • Se o programa travar (deadlock), se dois chefs tentarem usar a mesma faca (race condition) ou se um chef ficar esperando para sempre (starvation), o JPF pega a IA no flagra.
3. O Chefe de Cozinha (A Avaliação): Eles testaram 23 IAs diferentes (desde as mais famosas e caras até as mais simples) para ver quem consegue escrever o código que passa no teste do JPF.

O que eles descobriram?

Os resultados foram reveladores, como descobrir que muitos chefs excelentes em fazer saladas falham miseravelmente em cozinhar um banquete para 50 pessoas ao mesmo tempo:

• A maioria falha: Mesmo as IAs mais inteligentes (como o GPT-5 e o Claude) conseguiram acertar apenas cerca de 60% a 90% dos problemas. Isso significa que, em muitos casos, elas criam códigos que parecem funcionar, mas têm "armadilhas" invisíveis que farão o programa travar na vida real.
• A "Decoreba" não funciona: Quando as IAs tentam apenas memorizar a resposta, elas falham. Mas quando você permite que elas tentem várias vezes (como pedir 3 receitas diferentes e escolher a melhor), a taxa de sucesso sobe muito. Isso mostra que elas precisam de "tentativa e erro" para aprender a coordenar o caos.
• O erro mais comum: Muitas IAs escrevem um código que parece concorrente (usa palavras técnicas como "fio" ou "bloqueio"), mas na verdade, o programa roda tudo em uma única linha, como se fosse um código simples. É como pedir para a orquestra tocar, mas o maestro manda cada músico tocar sozinho em salas separadas. O código não quebra, mas não cumpre o objetivo!
• Medidas antigas não servem: O artigo mostra que métricas antigas (que medem apenas se o código se parece com a resposta certa, como comparar duas receitas de salada) não funcionam para código concorrente. Você pode ter um código que parece perfeito na superfície, mas que explode em mil pedaços quando rodado.

A Conclusão Simples

Este artigo nos diz que, embora as IAs sejam incríveis para escrever código simples, elas ainda estão aprendendo a gerenciar o caos.

O CONCUR é como um novo "motor de teste" que força as IAs a provarem que sabem lidar com múltiplas tarefas ao mesmo tempo sem causar acidentes. É um passo importante para garantir que, no futuro, quando pedirmos para uma IA criar um sistema bancário, um controle de tráfego aéreo ou um servidor de jogos, ela não vai apenas escrever um código bonito, mas um código que funciona de verdade quando tudo acontece ao mesmo tempo.

Em resumo: A IA sabe escrever a música, mas ainda está aprendendo a tocar a orquestra inteira sem desafinar.

Resumo técnico

Aqui está um resumo técnico detalhado do artigo "CONCUR: BENCHMARKING LLMS FOR CONCURRENT CODE GENERATION", apresentado em português:

1. O Problema

O uso de Grandes Modelos de Linguagem (LLMs) para geração de código tornou-se uma prática comum na engenharia de software. No entanto, os benchmarks existentes (como HumanEval ou MBPP) focam quase exclusivamente em código sequencial.

O artigo identifica uma lacuna crítica: o código concorrente apresenta complexidades únicas, como escalonamento não determinístico de threads, requisitos de sincronização e bugs específicos (condições de corrida, deadlocks, starvation) que não ocorrem em código sequencial. Métricas estáticas existentes (como CodeBLEU) falham em capturar a correção semântica do código concorrente, e avaliações baseadas apenas em testes unitários não conseguem explorar sistematicamente todas as intercalações possíveis de threads. Consequentemente, não há uma maneira confiável de avaliar se os LLMs atuais conseguem gerar programas concorrentes corretos.

2. Metodologia

Os autores propõem o CONCUR, o primeiro benchmark dedicado à avaliação de LLMs na geração de código concorrente. A metodologia divide-se em três pilares principais:

A. Construção do Dataset (115 Problemas)

• Problemas Base: 43 problemas de concorrência curados a partir de um livro didático padrão, reformulados para serem autocontidos e executáveis em Java 8.
• Variações Mutantes: 72 variantes validadas dos problemas base, geradas para aumentar a diversidade linguística e estrutural, reduzindo o risco de os modelos memorizarem as soluções.
• Prompt Engineering: Prompts estruturados que definem o idioma (Java 8), a descrição do problema e especificações rigorosas (ex: limites de threads e iterações para evitar explosão de estado).
• Ground Truth: Implementações completas e validadas foram recriadas a partir de snippets do livro, garantindo que todos os threads e interações fossem exercitados.

B. Framework de Avaliação (Compilação + Model Checking)

O CONCUR não depende apenas de testes de caixa-preta, mas utiliza Verificação Formal via Model Checking:

1. Compilação: O código gerado é compilado em um ambiente Java 8 controlado. Erros de sintaxe, imports faltantes ou dependências de bibliotecas de terceiros são detectados aqui.
2. Model Checking com Java PathFinder (JPF): Programas que compilam são submetidos ao JPF.
   • O JPF explora exaustivamente o espaço de estados (dentro de limites definidos) de todas as intercalações de threads possíveis.
   • Listeners Personalizados: O framework utiliza ouvintes específicos para detectar:
     • Deadlocks (bloqueio mútuo).
     • Race Conditions (acesso não sincronizado a variáveis compartilhadas).
     • Starvation (threads nunca escalonadas).
     • Exceções não tratadas (UE).
     • Soluções Não-Concorrentes (ST): Um ponto crucial é a detecção de programas que compilam e não têm erros de execução, mas não criam múltiplas threads (executando apenas na thread principal), violando o requisito de concorrência.

C. Limites de Verificação

Para tornar a verificação viável, o framework aplica limites estritos no número de threads e iterações (definidos no prompt e na solução de referência) e configura o JPF com um limite de profundidade de busca (10x a profundidade da solução de referência) e um tempo de execução máximo.

3. Principais Contribuições

1. Novo Benchmark (CONCUR): Um conjunto de dados de 115 problemas de concorrência com prompts estruturados e implementações ground-truth em Java.
2. Framework de Validação Automatizada: Integração de compilação e model checking (JPF) para detectar bugs de concorrência que métricas estáticas ignoram.
3. Avaliação de 23 LLMs: Análise abrangente de modelos proprietários (ex: GPT-5, Claude) e open-source (ex: Llama, Qwen) na tarefa de geração de código concorrente.
4. Análise de Métricas: Demonstração de que métricas de similaridade estática (CodeBLEU) não correlacionam-se com a correção dinâmica de programas concorrentes.
5. Recursos Públicos: Disponibilização do dataset, ferramentas e um leaderboard público.

4. Resultados Experimentais

Os autores avaliaram 23 LLMs de ponta no conjunto de 115 problemas:

• Desempenho Geral: Mesmo os modelos mais avançados (como GPT-5 e Claude Opus) têm taxas de sucesso limitadas. O GPT-5 alcançou 77,39% de sucesso em pass@1 e 91,30% em pass@3. Modelos menores tiveram desempenho significativamente pior (ex: Mistral-7b em 2,61%).
• Impacto de Múltiplas Gerações: A taxa de sucesso aumenta drasticamente com pass@3, sugerindo que a geração múltipla é essencial para tarefas complexas de concorrência.
• Tipos de Erros:
  • Erros de Compilação: A maioria foi devido a erros de sintaxe (71%) e imports faltantes.
  • Erros de Concorrência: As condições de corrida (Race Conditions) e Deadlocks foram os bugs mais frequentes detectados pelo JPF.
  • Falha de Concorrência (ST): Um erro significativo foi a geração de código que usa estruturas de dados thread-safe (como ConcurrentHashMap) mas executa tudo em uma única thread, falhando em criar a concorrência solicitada.
  • Exceções Não Tratadas: Foi a categoria de erro mais frequente no JPF.
• Ineficácia do CodeBLEU: O estudo mostrou que o CodeBLEU tem uma correlação fraca com a correção real. Modelos com pontuações moderadas de CodeBLEU frequentemente falharam em testes de concorrência, e vice-versa.
• Validação Manual: Uma auditoria manual de 115 programas classificados como "corretos" pelo sistema automatizado confirmou 92% de precisão, validando a confiabilidade do framework.

5. Significado e Conclusão

O trabalho do CONCUR estabelece um novo padrão para a avaliação de LLMs em tarefas de engenharia de software complexas. Ele demonstra que:

• A capacidade de gerar código sequencial não se traduz automaticamente para código concorrente.
• Métricas estáticas são insuficientes para avaliar a correção de sistemas concorrentes; a verificação dinâmica e formal é indispensável.
• Os modelos atuais ainda lutam com a lógica de sincronização e a implementação correta de múltiplos threads, frequentemente produzindo soluções que parecem corretas superficialmente, mas falham semanticamente sob intercalações de execução.

O CONCUR oferece uma base sólida para o desenvolvimento futuro de LLMs mais robustos para programação concorrente e destaca a necessidade de integrar verificação formal nos pipelines de avaliação de IA.