Resumo Técnico: LANGCHOICEBENCH

Declaração do Problema

Grandes Modelos de Linguagem (LLMs) estão sendo cada vez mais implantados em fluxos de trabalho de desenvolvimento de software autônomos, onde tomam decisões de design de alto nível, incluindo a seleção de linguagens de programação e ecossistemas. Embora trabalhos anteriores tenham estabelecido que os LLMs exibem uma forte preferência por Python, não existe atualmente um benchmark sistemático para medir esse comportamento em diversos contextos de projeto, particularmente em cenários onde o Python é suboptimal.

As avaliações existentes focam amplamente na correção funcional ou na geração de código de função única. Elas frequentemente falham em capturar escolhas de design de nível superior, como se um modelo recomenda uma linguagem apropriada para um domínio específico (por exemplo, sistemas embarcados ou negociação de baixa latência) e então a implementa nessa linguagem. Além disso, estudos anteriores não investigaram profundamente os rastros de raciocínio por trás dessas escolhas para determinar se os modelos estão tomando decisões deliberadas e conscientes do contexto ou se estão simplesmente recorrendo a padrões familiares. Essa lacuna deixa os designers de software inconscientes dos vieses implícitos e das potenciais inconsistências nas estruturas de projetos geradas por LLMs.

Metodologia

Construção do LANGCHOICEBENCH

Para abordar essas lacunas, os autores introduzem o LANGCHOICEBENCH, um benchmark de geração de código em nível de projeto projetado para medir a preferência por Python, a consistência entre recomendação e implementação, e a diversidade de linguagens.

• Escopo: O benchmark cobre 28 tarefas de projeto em sete áreas de software onde o Python é frequentemente uma escolha padrão ruim:
  1. Embarcados: Sistemas de borda com recursos limitados.
  2. Enterprise: Serviços financeiros de larga escala que exigem segurança de tipos.
  3. Frontend: Extensões de navegador e aplicações web.
  4. Jogos: Física e renderização em tempo real.
  5. Baixa Latência: Plataformas de negociação de alta frequência.
  6. Mobile: Aplicações nativas para iOS/Android.
  7. Sistemas: Daemons com restrição de memória.
• Design de Tarefas: Para cada área, foram criadas quatro descrições de projeto realistas e agnósticas à linguagem. Cada tarefa foi revisada manualmente por dois desenvolvedores de software experientes para confirmar que o Python é uma escolha "fraca" para as restrições específicas (ex: requisitos de tempo real, dependências de SDK nativo).
• Variantes de Prompt: Cada tarefa é apresentada em dois formatos:
  • Prompts de Implementação: Solicitações diretas para "Escreva o código para [tarefa]".
  • Prompts de Recomendação: Solicitações para "Quais são as melhores linguagens de programação para [tarefa]?" com instruções para etiquetar nomes de linguagens.
• Protocolo de Avaliação: O benchmark avalia 25 LLMs diversos (variando de modelos de fronteira a modelos menores de pesos abertos) usando configurações de decodificação padrão. Para cada modelo, 20 amostras são geradas por variante de prompt de implementação, e 5 amostras por variante de prompt de recomendação, totalizando 2.100 respostas por modelo.

Métricas

O estudo define cinco métricas para quantificar o comportamento do modelo:

1. Taxa de Implementação em Python (PyIR): A proporção de implementações onde Python é a linguagem principal.
2. Taxa de Recomendação de Python (PyRR): A proporção de recomendações onde Python aparece entre as três principais linguagens sugeridas.
3. Taxa de Recomendação–Implementação (RIR): A proporção de implementações que utilizam uma das três principais linguagens recomendadas pelo próprio modelo para aquela tarefa específica.
4. Alinhamento de Recomendação–Implementação (RIA): A correlação de Spearman entre o ranking de recomendação do modelo e o ranking de frequência de implementação.
5. Diversidade Efetiva de Linguagem (ELD): Baseada no Vendi Score, mede o número efetivo de linguagens distintas utilizadas por um modelo dentro de uma área de projeto específica.

Análise de Rastro de Raciocínio

Para os 15 modelos que expõem rastros de raciocínio brutos, os autores analisaram 9.826 implementações em Python. Um juiz de LLM validado (GPT-5.4 Mini) classificou os rastros em cinco categorias mutuamente exclusivas:

• Evidência Fantasma: O modelo fabrica suporte contextual (ex: alegar que o prompt exigia Python) para justificar a escolha.
• Incompatibilidade de Linguagem: O raciocínio seleciona explicitamente uma linguagem que não seja Python, mas a saída final é em Python.
• Python por Facilidade: A escolha é impulsionada pela simplicidade, familiaridade ou velocidade de prototipagem.
• Python Automático: O modelo seleciona Python sem consideração significativa de alternativas.
• Inconclusivo/Outros: Casos que não se encaixam nas categorias acima.

Principais Resultados

Preferência por Python e Inconsistência

• Sobre-seleção: Em todos os modelos, o Python foi implementado em 35,3% das respostas, apesar de ser suboptimal para as tarefas. Isso é significativamente maior do que a taxa de 10,7% na qual os modelos explicitamente recomendam Python.
• Correlação com o Tamanho do Modelo: Modelos menores de pesos abertos geralmente exibiram preferências mais fortes por Python e menor diversidade de linguagem. Por exemplo, o modelo Nemotron 7B implementou projetos em Python 66,5% das vezes, mas o recomendou apenas 6,2% das vezes.
• Modelos Especializados em Código: Mesmo modelos especializados em geração de código (ex: Codestral, Code Nemotron) mostraram fortes vieses de Python, com taxas de implementação frequentemente excedendo 50%.

Consistência de Recomendação–Implementação

• Baixo Alinhamento: Em média, apenas 48,8% das implementações utilizaram uma das três principais linguagens recomendadas pelo próprio modelo (RIR).
• Desalinhamento Distribucional: A correlação de Spearman (RIA) entre recomendações e implementações foi baixa (média de 0,17), indicando que os modelos frequentemente expressam preferências relativas diferentes ao aconselhar versus ao codificar. Alguns modelos, como o Gemma 4 26B, mostraram alinhamento negativo (-0,10), o que significa que suas linguagens mais recomendadas foram as menos utilizadas.

Diversidade de Linguagem

• Variabilidade: A Diversidade Efetiva de Linguagem (ELD) variou significativamente. Modelos DeepSeek alcançaram a maior diversidade (ELD ≈ 4), enquanto Nemotron 7B e Code Nemotron 7B mostraram a menor (ELD ≈ 1,7), indicando um colapso sobre um conjunto estreito de linguagens.

Achados de Rastro de Raciocínio

A análise de 9.826 rastros revelou que a maioria das escolhas de Python não foi resultado de deliberação:

• Automático/Impulsionado por Conveniência: 69,8% dos rastros foram classificados como "Python Automático" (sem consideração significativa) e 20,5% foram "Python por Facilidade". Juntos, estes representam 90,3% dos casos.
• Falhas de Raciocínio:
  • Evidência Fantasma: Ocorreu em 7,8% dos rastros, onde os modelos fabricaram instruções ou contexto para justificar o Python. Isso foi particularmente prevalente em modelos menores de pesos abertos (ex: OLMo 32B em 16,4%).
  • Incompatibilidade de Linguagem: Ocorreu em 1,9% dos rastros, onde o raciocínio selecionou uma linguagem diferente, mas a saída mudou para Python. Isso se concentrou na família Nemotron (até 8,8%).

Significância e Alegações

O artigo afirma que a escolha da linguagem de programação continua sendo um processo de tomada de decisão não confiável para os LLMs modernos, mesmo para modelos de raciocínio avançado. As principais contribuições são:

1. Introdução de Benchmark: O lançamento do LANGCHOICEBENCH como o primeiro benchmark dedicado para avaliar a escolha de linguagem em nível de projeto, fornecendo prompts, dados e ferramentas para avaliação reprodutível.
2. Evidência Empírica de Viés: Demonstrar que os LLMs selecionam sistematicamente o Python em contextos onde ele é tecnicamente suboptimal, muitas vezes contradizendo suas próprias recomendações explícitas.
3. Identificação de Modos de Falha: Revelar que a causa raiz da má escolha de linguagem é frequentemente a falta de deliberação (padrões automáticos) ou falhas específicas de raciocínio (evidências fabricadas e inconsistência entre o pensamento e a saída).

Os autores concluem que, até que essas falhas sejam abordadas, as escolhas de linguagem e ecossistema não devem ser deixadas implícitas no desenvolvimento agêntico. Eles argumentam que essas decisões devem ser tornadas explícitas, avaliadas junto com o código gerado e tratadas como um alvo concreto para a melhoria dos modelos. O artigo não propõe correções arquiteturais específicas, mas faz um apelo para estratégias de treinamento e avaliação que penalizem alegações não suportadas e imponham consistência entre o raciocínio e a saída.