A Study of LLMs' Preferences for Libraries and Programming Languages

Título: Um Estudo das Preferências de LLMs por Bibliotecas e Linguagens de Programação

1. Problema e Motivação

Apesar dos avanços rápidos dos Grandes Modelos de Linguagem (LLMs) na geração de código, as avaliações existentes concentram-se quase exclusivamente na correção funcional ou validade sintática. Existe uma lacuna crítica no entendimento de como os LLMs tomam decisões de design fundamentais, especificamente:

• Qual biblioteca escolher para uma tarefa.
• Qual linguagem de programação utilizar.

Essas preferências não são neutras; elas impactam diretamente o desempenho do software, a eficiência, a manutenibilidade e a diversidade do ecossistema. Se os LLMs tendem a favorecer tecnologias dominantes (como Python e bibliotecas estabelecidas) em detrimento de alternativas mais adequadas ao contexto (como Rust para alta performance), isso pode criar ciclos de feedback que estagnam a inovação e reforçam vieses no desenvolvimento de software. O estudo visa investigar se esses modelos exibem vieses sistemáticos que priorizam a familiaridade em vez da adequação técnica.

2. Metodologia

Os autores realizaram o primeiro estudo empírico sistemático cobrindo 8 LLMs de produção (incluindo GPT-4o-mini, GPT-3.5-turbo, Claude-3.5 Sonnet/Haiku, Llama-3.2-3B, Mistral-7B, Qwen-2.5-Coder e DeepSeek-LLM).

O estudo foi dividido em três experimentos principais, aplicados em dois cenários: Tarefas de Benchmarks (BigCodeBench, Multi-HumanEval, etc.) e Inicialização de Projetos (descrições de projetos abertos).

• Experimento 1: Preferências por Bibliotecas

  • Foco: Python.
  • Método: Os modelos foram instruídos a gerar código para tarefas do BigCodeBench (sem especificar bibliotecas no prompt) e para a inicialização de 5 tipos de projetos (banco de dados, deep learning, computação distribuída, web scraper, servidor web).
  • Objetivo: Medir quais bibliotecas externas são escolhidas quando não há diretrizes explícitas.

• Experimento 2: Preferências por Linguagens de Programação

  • Foco: Escolha de linguagem sem restrição no prompt.
  • Método: Uso de datasets agnósticos a linguagem (Multi-HumanEval, MBXP, AixBench, CoNaLa, APPS, CodeContests).
  • Desafio Específico: Para tarefas de inicialização de projetos onde o Python é subótimo (ex: servidores web concorrentes, interfaces gráficas, trading de baixa latência), os prompts pediam código inicial, testando se os modelos abandonariam o Python em favor de linguagens compiladas (C++, Rust).

• Experimento 3: Consistência entre Recomendação e Uso

  • Método: Os LLMs foram solicitados a listar, em ordem, as melhores bibliotecas ou linguagens para cada tarefa (resposta em linguagem natural).
  • Análise: Comparação entre a classificação das recomendações (NL) e a classificação do uso real (código gerado) usando o coeficiente de correlação de postos de Kendall ($\tau_b$).

3. Principais Resultados

A. Viés por Bibliotecas Estabelecidas (Overuse)

• Dominância de "Big Three": Todos os LLMs mostraram uma preferência esmagadora por NumPy, pandas e Matplotlib, mesmo quando a solução "ground-truth" não as exigia.
• Uso Desnecessário: Em até 45% dos casos de benchmarks, o uso do NumPy desviava da solução ideal, indicando uma tendência de usar bibliotecas pesadas para tarefas simples.
• Falta de Diversidade: Os modelos ignoraram bibliotecas modernas e de alto momentum (ex: Polars em vez de pandas, FastAPI em vez de Flask, Ray em vez de Dask). A diferença na taxa de uso entre bibliotecas estabelecidas e alternativas modernas variou de 36% a 79%.
• Consistência: Mesmo em prompts que não exigiam bibliotecas externas, os modelos continuaram a escolhê-las, sugerindo que a preferência é intrínseca ao modelo e não apenas uma resposta ao prompt.

B. Viés Fortíssimo por Python

• Padrão Geral: Em tarefas de benchmark, o Python foi usado em 90-97% das soluções, mesmo em datasets multilíngues.
• Cenários de Alta Performance: Em tarefas de inicialização de projetos onde o Python é tecnicamente subótimo (ex: baixa latência, concorrência massiva), o Python permaneceu como a escolha dominante em 58% dos casos.
• Ausência de Alternativas: Linguagens como Rust não foram utilizadas nenhuma vez em certas categorias de tarefas de inicialização, apesar de serem a escolha ideal para segurança de memória e desempenho.

C. Inconsistência entre Recomendação e Prática

• Sinal Fraco: As recomendações em linguagem natural (NL) dos LLMs são um indicador muito fraco do que eles realmente codificarão.
• Correlação Baixa: A correlação entre o que o modelo recomenda e o que ele usa é baixa e frequentemente não estatisticamente significativa.
• Exemplo: Em tarefas de inicialização de projetos, os LLMs contradisseram suas próprias recomendações de linguagem em 83% das vezes (ex: recomendando Rust ou C++, mas gerando Python).

4. Contribuições Principais

1. Primeiro Estudo Empírico: Estabelece a base para a análise de vieses de seleção de tecnologia (linguagem e biblioteca) em LLMs de código.
2. Quantificação do Viés: Demonstra quantitativamente a preferência por Python e bibliotecas antigas, mesmo quando contraproducente para a tarefa.
3. Revelação de Inconsistência: Mostra que a capacidade de "raciocínio" em linguagem natural não se traduz em coerência na geração de código.
4. Recursos Abertos: Os autores liberaram o código, datasets e resultados completos no repositório GitHub para fomentar pesquisas futuras.

5. Significado e Implicações

• Riscos para o Ecossistema: A tendência de homogeneização pode reduzir a diversidade de ferramentas, criar ciclos de feedback onde LLMs treinam-se em dados gerados por LLMs (model collapse), e desincentivar a adoção de tecnologias mais seguras ou eficientes.
• Impacto na Segurança e Desempenho: Usuários não especialistas podem confiar cegamente nas escolhas padrão dos modelos, resultando em sistemas com desempenho inferior ou vulnerabilidades de segurança (ex: uso de Python em sistemas de trading de alta frequência).
• Direções Futuras: O estudo sugere a necessidade urgente de:
  • Fine-tuning direcionado para equilibrar as preferências.
  • Diversificação dos dados de treinamento para incluir mais linguagens e bibliotecas emergentes.
  • Novos benchmarks que avaliem não apenas a correção, mas a adequação da escolha tecnológica.
  • Estratégias de Prompting: O estudo mostrou que técnicas de "Chain-of-Thought" (pensar passo a passo) podem melhorar ligeiramente a consistência, mas não eliminam o viés fundamental.

Em resumo, o paper alerta que, embora os LLMs sejam ferramentas poderosas para geração de código, eles carregam vieses sistêmicos que favorecem o status quo tecnológico, exigindo intervenção humana e ajustes no treinamento para garantir que o futuro do desenvolvimento de software seja diversificado e tecnicamente otimizado.