Code Roulette: How Prompt Variability Affects LLM Code Generation

Este artigo propõe um pipeline de avaliação agnóstico para quantificar a sensibilidade da geração de código por Modelos de Linguagem de Grande Escala (LLMs) a variações nos prompts, fornecendo evidências experimentais e código aberto para a comunidade.

O essencial

Imagine que você pediu para um cozinheiro de elite (o Modelo de Linguagem ou LLM) preparar um prato específico, como uma "torta de maçã".

Se você disser: "Faça uma torta de maçã com canela", o cozinheiro faz uma torta.
Se você disser: "Faça uma torta de maçã com um toque de canela", ele faz outra torta.
Se você digitar errado e escrever: "Faça uma torte de maçã com cnela", o cozinheiro pode ficar confuso e fazer algo que nem parece uma torta, ou talvez uma torta de banana.

O artigo "Code Roulette" (Roleta de Código) investiga exatamente isso: o quão sensível é o "cozinheiro" (a Inteligência Artificial) quando mudamos levemente o pedido?

Aqui está a explicação do estudo, traduzida para o dia a dia:

1. O Problema: A "Roleta" do Pedido

Hoje em dia, qualquer pessoa pode pedir para uma IA escrever código de computador. O problema é que as pessoas falam de formas diferentes.

• Um programador experiente pode ser muito técnico.
• Um iniciante pode ser muito vago.
• Alguém cansado pode digitar errado (um "tipe" ou erro de digitação).
• Alguém pode usar sinônimos (dizer "criar" em vez de "fazer").

O estudo quer saber: Se eu mudar apenas uma palavra ou cometer um pequeno erro no meu pedido, a IA vai me entregar um código totalmente diferente?

2. A Metodologia: O Experimento da "Roleta"

Os pesquisadores criaram um "laboratório" para testar isso. Eles pegaram 4 IAs famosas (como GPT-4, Claude, Gemini e Llama) e deram a elas a mesma tarefa de programação.

Depois, eles começaram a "perturbar" o pedido de três formas, como se estivessem jogando roleta:

1. Erros de Digitação (Typos): Como se você estivesse com pressa e apertasse a tecla errada no teclado.
2. Sinônimos: Trocar palavras por outras com o mesmo significado (ex: "casa" por "lar").
3. Paráfrase: Reescrever o pedido inteiro com outras palavras, mantendo o mesmo sentido.

Para cada nível de "bagunça" no pedido, eles pediram para a IA gerar o código várias vezes e mediram o quanto o resultado final mudou.

3. As Descobertas Principais

A. O Efeito "Erro de Digitação" é Devastador

Quando os pesquisadores introduziram erros de digitação (como trocar uma letra por outra próxima no teclado), a IA ficou muito confusa.

• Analogia: É como se você dissesse "Faça uma pizza" e, por engano, escrevesse "Faça uma piza". A IA pode interpretar isso como algo totalmente diferente.
• Resultado: Mesmo com poucos erros, o código gerado mudou drasticamente. A estrutura do código ficou muito diferente da original.

B. Sinônimos e Paráfrases são Mais Seguros

Quando eles apenas trocaram palavras por sinônimos ou reescreveram a frase, a IA foi mais estável.

• Analogia: É como pedir "uma bebida gelada" em vez de "um refrigerante frio". O cozinheiro entende que é a mesma coisa e faz a mesma bebida.
• Resultado: A IA conseguiu manter a estrutura do código mais parecida, mesmo com as mudanças nas palavras.

C. O Segredo Sujo: "Contaminação de Dados"

O estudo revelou algo crucial sobre os testes que usamos para medir IAs.

• O Cenário: Eles usaram problemas famosos de um site de programação (LeetCode).
• O Problema: Como essas IAs foram treinadas com milhões de dados da internet, elas já viram esses problemas antes.
• A Analogia: É como dar um teste de matemática para um aluno que já decorou a resposta do livro. Ele vai acertar mesmo se você mudar um pouco a pergunta, porque ele "decorou" o padrão.
• A Conclusão: Quando os pesquisadores usaram problemas novos (que a IA nunca viu), a sensibilidade aumentou muito. A IA ficou muito mais instável com tarefas novas. Isso mostra que muitos testes atuais podem estar superestimando a inteligência da IA.

4. Por que isso importa para você?

Imagine que você está construindo uma casa.

• Se você pedir ao arquiteto (IA) para colocar "janelas grandes" e ele colocar "janelas gigantes", a casa pode ficar bonita.
• Mas, se você digitar errado e ele colocar "janelas de vidro" em vez de "janelas de madeira", e você não perceber, a estrutura da casa pode ficar frágil.

O estudo nos ensina que:

1. Não podemos confiar cegamente: Pequenas mudanças no que escrevemos podem gerar códigos muito diferentes.
2. Precisamos de mais cuidado: Se você usa IA para programar, precisa revisar o código com atenção, pois a IA pode ter entendido algo diferente só porque você usou uma palavra diferente.
3. O futuro: Precisamos criar IAs que entendam melhor a intenção do usuário, e não apenas as palavras exatas, para que a "Roleta" pare de girar e o resultado seja sempre confiável.

Em resumo: A IA é um gênio, mas é um gênio que se distrai facilmente com erros de digitação e depende muito de ter visto o problema antes. O estudo nos avisa para não achar que a IA é infalível só porque ela parece inteligente.

Resumo técnico

1. O Problema

A geração de código por Modelos de Linguagem Grandes (LLMs) é uma aplicação crescente que democratiza o desenvolvimento de software. No entanto, a qualidade e a funcionalidade do código gerado dependem criticamente da qualidade do prompt (entrada) fornecido pelo usuário.

O problema central identificado pelos autores é a sensibilidade dos LLMs a variações no prompt. Usuários com diferentes backgrounds, níveis de experiência e modelos mentais de programação tendem a formular os mesmos requisitos de maneiras textuais distintas (erros de digitação, uso de sinônimos, paráfrases). A incerteza sobre como pequenas alterações no texto de entrada afetam a saída do código cria uma barreira para a confiança no uso de LLMs, especialmente em cenários onde a consistência e a manutenibilidade do código são cruciais. O artigo busca quantificar essa sensibilidade para entender o quão estável é o código gerado diante de flutuações naturais na entrada.

2. Metodologia

Os autores propõem um pipeline de avaliação agnóstico a tarefas específicas e a modelos, focado em medir a sensibilidade do código gerado a aumentações (perturbações) no prompt.

• Definição Formal:
  • Seja $P$ o conjunto de prompts e $M$ o modelo LLM que mapeia $P \to C$ (código).
  • Uma função de aumento $F: P \times [0, 1] \to P$ perturba o prompt com uma taxa $r$.
  • Uma função de distância $D: C \times C \to [0, 1]$ quantifica a dissimilaridade entre dois trechos de código.
• Processo de Avaliação:
  1. Gera-se um conjunto de referência ($C_{ref}$) a partir do prompt original (não perturbado).
  2. Aplica-se a função de aumento $F$ ao prompt com taxas crescentes ($r$ de 0 a 1).
  3. Para cada taxa, gera-se um conjunto de códigos aumentados ($C_{aug}$).
  4. Calcula-se a distância média entre todos os pares de códigos em $C_{ref}$ e $C_{aug}$.
• Métodos de Aumento (Perturbação):
  1. Erros de Digitação (Typos): Substituição aleatória de caracteres por teclas adjacentes no teclado QWERTY.
  2. Sinônimos: Substituição aleatória de palavras por seus sinônimos (baseado no WordNet).
  3. Paráfrase: Reescrita do prompt usando a capacidade de tradução/paráfrase de outro LLM (Gemini), mantendo o significado semântico mas alterando o vocabulário.
• Métrica de Distância (TSED):
  • Utiliza-se a Tree Similarity of Edit Distance (TSED). Diferente de métricas textuais genéricas (como BLEU ou BERT Score), que falharam em capturar nuances de código (mostrando teto de efeito e alto custo computacional), o TSED mede a similaridade estrutural baseada na árvore de sintaxe (AST).
  • O foco é a consistência estrutural, não necessariamente a correção funcional, pois variações estruturais impactam a revisão e manutenção do código.
• Conjunto de Dados:
  • LeetCode (Old): 20 tarefas antigas (suspeitas de contaminação nos dados de treino).
  • LeetCode (New): 20 tarefas de março de 2025 (fora do corte de treino dos modelos).
  • Our Dataset: 22 tarefas criadas manualmente, abertas e variadas (simulações, jogos, ciência de dados), projetadas para não ter uma única resposta correta e evitar contaminação.

3. Principais Contribuições

1. Procedimento de Avaliação: Um pipeline sistemático para medir a sensibilidade de LLMs na geração de código frente a variações de entrada.
2. Análise de Sensibilidade: Uma avaliação empírica extensa de quatro LLMs populares (GPT-4o mini, Claude 3 Haiku, Gemini 2.0 Flash, Llama 3.3 70B) sob diferentes tipos de perturbação.
3. Recurso Aberto: Disponibilização pública do código e do conjunto de dados (tarefas abertas) para permitir a replicação e extensão do trabalho pela comunidade.
4. Insights sobre Contaminação de Dados: Evidência clara de como a contaminação de dados de treino (LeetCode Old) mascara a sensibilidade real dos modelos.

4. Resultados Chave

• Impacto dos Tipos de Perturbação:
  • Erros de Digitação: Causam a maior degradação na similaridade do código. A similaridade cai rapidamente entre as taxas 0.0 e 0.6, estabilizando em um valor baixo (~0.3 TSED), indicando que modelos são extremamente sensíveis a erros de digitação.
  • Sinônimos e Paráfrases: São métodos de perturbação mais fracos. O código mantém maior estabilidade, com quedas mais graduais na similaridade. O Gemini 2.0 Flash mostrou-se o mais robusto a sinônimos, mantendo similaridade acima de 0.6 mesmo com perturbações significativas.
• Estabilidade do Modelo (Temperatura 0):
  • GPT-4o mini e Gemini 2.0 Flash geraram códigos quase idênticos para prompts não alterados (similaridade ~0.9).
  • Llama 3.3 e Claude 3 Haiku exibiram maior instabilidade mesmo sem perturbação, gerando variações estruturais significativas.
• Efeito de Contaminação de Dados:
  • No conjunto LeetCode (Old), os modelos mostraram baixa sensibilidade (alta robustez) a todas as perturbações, provavelmente porque memorizaram as soluções durante o treino.
  • No conjunto LeetCode (New), a sensibilidade aumentou, mas ainda houve estabilidade razoável.
  • No conjunto "Our Dataset" (tarefas abertas e originais), a sensibilidade foi máxima. A similaridade do código caiu abaixo de 0.5 após apenas 10% de alteração no prompt, e houve alta variância mesmo nos prompts originais.
• Validação Estatística: Testes de Friedman e Kruskal-Wallis confirmaram que a taxa de aumento tem um efeito estatisticamente significativo na similaridade do código e que a sensibilidade varia significativamente entre os diferentes conjuntos de dados.

5. Significado e Implicações

• Construção de Confiança: O estudo demonstra que a "sorte" do prompt (como o usuário formula a frase) pode levar a implementações drasticamente diferentes, mesmo para a mesma tarefa. Isso é crítico para a adoção de LLMs em ambientes profissionais onde a consistência é vital.
• Necessidade de Novos Benchmarks: Os resultados reforçam que benchmarks tradicionais (como LeetCode clássico) são inadequados para avaliar a robustez de LLMs modernos devido à contaminação de dados. É urgente o uso de tarefas novas e abertas.
• Diretrizes para Desenvolvimento: Sugere que pipelines de desenvolvimento com LLMs devem incluir mecanismos para lidar com essa variabilidade, como:
  • Perguntas de acompanhamento para esclarecer requisitos.
  • Técnicas de regularização (gerar múltiplas variações e agregar).
  • Validação funcional rigorosa, pois a similaridade estrutural não garante equivalência funcional.
• Futuro da Pesquisa: O trabalho abre caminho para investigar como diferenças nos modelos mentais de usuários (iniciantes vs. especialistas) afetam a interação com LLMs e a necessidade de pipelines que suportem diálogos iterativos em vez de interações de um único passo.

Em suma, o artigo alerta que a variabilidade no prompt não é apenas um detalhe estético, mas um fator determinante na estabilidade e confiabilidade do código gerado por IA, exigindo novas métricas e abordagens de avaliação focadas na robustez estrutural.