💬 NLP

Comparing Developer and LLM Biases in Code Evaluation

O artigo apresenta o framework TRACE, que demonstra que os modelos de linguagem (LLMs) atuando como juízes de código apresentam desalinhamentos significativos e vieses sistemáticos em relação às preferências humanas em diversos cenários de programação, subperformando os anotadores humanos em 12-23%.

Autores originais: Aditya Mittal, Ryan Shar, Zichu Wu, Shyam Agarwal, Tongshuang Wu, Chris Donahue, Ameet Talwalkar, Wayne Chi, Valerie Chen

Publicado 2026-03-26

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Aditya Mittal, Ryan Shar, Zichu Wu, Shyam Agarwal, Tongshuang Wu, Chris Donahue, Ameet Talwalkar, Wayne Chi, Valerie Chen

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está construindo uma casa. Você tem um arquiteto humano experiente (o Desenvolvedor) e um assistente de IA muito inteligente, mas inexperiente (o Modelo de Linguagem ou LLM).

O problema é: quem decide se o trabalho do assistente está bom? Antigamente, era o arquiteto humano. Mas, como há tanta obra acontecendo, os construtores começaram a usar um Juiz de IA para avaliar o trabalho do assistente e dizer: "Isso aqui está ótimo, pode usar!" ou "Isso está ruim, jogue fora".

A pergunta do artigo é: Esse Juiz de IA está julgando da mesma forma que o Arquiteto Humano?

A resposta curta é: Não. E isso é um problema.

Os autores criaram uma ferramenta chamada TRACE (pense nela como um "detector de mentiras" ou um "raio-x" para ver como os juízes pensam) para investigar isso. Eles olharam para três situações diferentes onde programadores usam IA:

Autocompletar: Quando a IA sugere a próxima linha de código enquanto você digita (como o GPS sugerindo o próximo caminho).
Editar: Quando você pede para a IA mudar algo específico no código.
Chat: Quando você conversa com a IA para pedir ajuda em um problema complexo.

Aqui está o que eles descobriram, usando analogias do dia a dia:

1. O Juiz está "cegado" pela posição (Viés de Posição)

Imagine que você está provando dois pratos de macarrão. O Juiz de IA, às vezes, não está julgando o sabor, mas sim qual prato chegou primeiro na mesa. Se o prato A estiver à esquerda, ele gosta mais. Se você trocar e colocar o prato B à esquerda, ele muda de opinião, mesmo que o prato seja o mesmo.

O que o paper diz: Os modelos de IA têm um viés enorme dependendo da ordem em que as opções são apresentadas. Humanos não fazem isso.

2. O Juiz ama "explicações longas", o Humano ama "direto ao ponto"

Pense em um professor de escola.

O Juiz de IA acha que uma resposta é melhor se o aluno escrever um livro inteiro explicando por que fez a conta. Ele valoriza o "barulho" e a explicação detalhada.
O Programador Humano (o Arquiteto) quer apenas a resposta certa, rápida e limpa. Ele não quer ler um romance para entender uma linha de código.
O Resultado: O Juiz escolhe a resposta "enrolada" e o Humano prefere a resposta "seca e eficiente". Eles estão julgando coisas diferentes!

3. O Juiz ignora o "contexto da sala"

Imagine que você está consertando um motor de carro.

O Juiz de IA olha apenas para a peça que você trocou e diz: "Essa peça parece nova e brilhante, ótimo!".
O Humano olha para a peça e pensa: "Essa peça é brilhante, mas ela não vai encaixar no modelo de carro de 2010 que estamos consertando".
O que acontece: Em tarefas de edição de código, o Juiz foca apenas se a instrução foi seguida tecnicamente, mas ignora se o código ficou legível ou se faz sentido dentro do projeto maior. O Humano quer que o código seja limpo e fácil de entender para quem vai ler depois.

4. A "Lista de Critérios" (O Rubric)

Para descobrir por que eles discordam, os autores criaram uma Lista de Critérios (como uma rubrica de prova escolar). Eles pediram para a IA e para Humanos avaliarem códigos baseados em coisas como:

"O código tem erros?"
"O código é claro?"
"O código é criativo?"
"O código é robusto (aguenta erros)?"

A descoberta chocante:
Mesmo quando ambos concordam que "código sem erros é bom", eles dão pesos diferentes para outras coisas.

Em Chat, o Juiz gosta de explicações genéricas. O Humano quer soluções que entendam o contexto específico do problema dele.
Em Autocompletar, o Juiz foca se o código funciona. O Humano foca se o código é fácil de ler e manter.

O Veredito Final

O estudo mostra que, embora os Juízes de IA sejam úteis, eles ainda não são bons o suficiente para substituir humanos na avaliação de código no mundo real.

O Desempenho: Os melhores Juízes de IA erram de 12% a 23% mais do que um grupo de programadores humanos.
O Problema: Não é apenas uma questão de "treinar mais". Mesmo modelos especializados em julgar falham em capturar as nuances sutis que um desenvolvedor humano sente no dia a dia.

Em resumo: Estamos tentando usar um "robô juiz" para avaliar o trabalho de um "artesão humano", mas o robô está usando uma régua diferente. Ele mede o tamanho do tijolo, enquanto o artesão quer saber se a parede vai ficar reta e bonita. O artigo nos avisa que precisamos consertar essa régua (o treinamento da IA) para que ela aprenda a julgar como um humano, e não como um robô obcecado por regras rígidas.

1. Problema e Motivação

O uso de Grandes Modelos de Linguagem (LLMs) como "juízes" para avaliar a qualidade de código gerado por IA tem crescido rapidamente, substituindo ou complementando a avaliação humana. No entanto, a literatura existente tende a focar em cenários estáticos (código polido de repositórios GitHub ou tarefas de programação competitiva), que não capturam a realidade do desenvolvimento de software: contextos parciais, intenções ambíguas e fluxos de trabalho interativos.

O problema central identificado é que os juízes LLM não refletem fielmente as preferências e critérios implícitos dos desenvolvedores humanos em cenários reais. Há uma lacuna de alinhamento (misalignment) entre o que os modelos consideram "bom código" e o que os desenvolvedores valorizam na prática, o que pode levar a avaliações enviesadas e ineficazes em ferramentas de assistência à programação.

2. Metodologia: O Framework TRACE

Os autores propõem o TRACE (Tool for Rubric Analysis in Code Evaluation), um framework projetado para avaliar e interpretar juízes baseados em LLMs em fluxos de trabalho realistas. O TRACE opera em três etapas principais:

Medição de Alinhamento: O framework coleta pares de respostas de código e compara as decisões de vários juízes LLM com as preferências humanas (rótulos de preferência binária). Para mitigar viés de posição, cada amostra é avaliada duas vezes (ordem original e invertida).
Descoberta Automática de Rubricas (Critérios): Em vez de usar critérios pré-definidos, o TRACE extrai automaticamente itens de rubrica (critérios de avaliação) que explicam as diferenças entre as respostas. Isso é feito combinando:
- Rubricas Geradas por LLM: Um modelo analisa as diferenças entre pares de respostas e gera eixos de variação comportamental.
- Rubricas Anotadas por Humanos: Engenheiros fornecem justificativas para suas escolhas, que são abstraídas em critérios gerais.
- Esses critérios são agregados para formar um conjunto final de rubricas interpretáveis (ex: "Tratamento de Erros", "Clareza", "Alinhamento Lógico").
Análise de Viés (Comparação de Coeficientes): O sistema treina modelos de regressão logística separados para humanos e para cada juízes LLM, usando as pontuações das rubricas como características de entrada. Ao comparar os coeficientes aprendidos ( $\beta_H$ para humanos e $\beta_J$ para juízes), o TRACE identifica onde os juízes atribuem pesos excessivos ou insuficientes a critérios específicos em relação aos humanos.

3. Configuração Experimental

O estudo foi aplicado em três modalidades de interação distintas, cobrindo mais de 500 amostras cada:

Autocompletar no IDE (Code Completion): Preenchimento de código no meio de um arquivo (baseado no Copilot Arena).
Edição de Código Instruída (Instructed Code Edits): Usuários selecionam um trecho e dão instruções para modificação (baseado no EDIT-Bench).
Programação Baseada em Chat (Chat-based Coding): Diálogos abertos para resolução de problemas (filtrado do Chatbot Arena).

Foram avaliados 13 modelos diferentes, incluindo:

Modelos de Terceiros (GPT-4o, GPT-5, Claude Sonnet 4, DeepSeek-R1, Llama-3.1).
Modelos Especializados em Julgamento (Prometheus 2, Atla Selene, Skywork Critic).
Modelos de Recompensa (PairRM, GRM).

4. Resultados Principais

Desempenho Geral

Subdesempenho Consistente: Os melhores juízes LLM subdesempenham os desenvolvedores humanos em 12% a 23% de precisão de acordo com a preferência majoritária.
Falta de Dominância: Nenhum modelo único domina consistentemente em todas as modalidades. Curiosamente, modelos especializados em julgamento (fine-tuned) não superam consistentemente os modelos de propósito geral, sugerindo que o problema não é apenas falta de dados de treinamento específicos.
Viés de Posição: Os modelos de linguagem exibem um viés significativo baseado na ordem de apresentação das respostas, enquanto modelos de recompensa (que geram pontuações escalares) são invariantes à ordem.

Alinhamento e Viés nas Rubricas

O TRACE identificou 35 fontes significativas de desalinhamento entre humanos e juízes. Os padrões variam conforme a modalidade:

Autocompletar (Completion): Os juízes superestimam a funcionalidade e alinhamento lógico (código que funciona imediatamente), mas subestimam a clareza e explicitidade. Humanos preferem código mais explícito e legível, mesmo que seja ligeiramente mais verboso.
Edição (Edits): Os juízes tratam edições como tarefas de satisfação de restrições (focando se a instrução foi seguida), subestimando a clareza e estrutura. Humanos veem edições como oportunidades para melhorar a qualidade do código (refatoração implícita).
Chat: Os juízes tendem a recompensar explicações genéricas e claras, enquanto humanos preferem soluções conscientes do domínio e adaptadas ao contexto específico do problema, penalizando explicações excessivas.

Critérios de Engenharia de Software

O framework mapeou 16 temas de rubrica, dos quais 11 correspondem a critérios estabelecidos de engenharia de software (ex: correção sintática, robustez, formatação).
Mesmo em critérios "clássicos" como Robustez e Tratamento de Erros, os juízes mostram desalinhamento significativo. Por exemplo, em chat, juízes podem preferir explicações longas sobre tratamento de erros, enquanto humanos preferem soluções concisas e diretas.

5. Contribuições e Significância

Novo Framework de Avaliação (TRACE): Apresenta uma metodologia robusta para ir além da métrica de "acurácia bruta", permitindo a interpretação por que e onde os juízes falham, através da extração automática de rubricas.
Evidência de Viés Sistêmico: Demonstra que o desalinhamento não é aleatório, mas estrutural e dependente do contexto (modalidade). Os juízes atuais não capturam as nuances do "bom código" que os desenvolvedores aplicam implicitamente.
Crítica aos Benchmarks Atuais: Mostra que benchmarks de julgamento existentes (como JudgeBench ou RewardBench) têm correlação fraca com o desempenho em cenários reais de interação de código, indicando que a comunidade precisa de avaliações mais realistas.
Direções Futuras: Sugere que melhorar a avaliação automatizada exigirá calibração consciente de rubricas ou treinamento direcionado de juízes para alinhar seus pesos de decisão com os critérios humanos, em vez de apenas aumentar a capacidade do modelo.

Conclusão

O artigo conclui que, embora os LLMs sejam ferramentas poderosas, eles ainda não são substitutos confiáveis para a avaliação humana em tarefas de engenharia de software complexas e interativas. A lacuna de alinhamento revela que os modelos priorizam métricas superficiais ou verificáveis (como sintaxe e lógica imediata) em detrimento de qualidades mais sutis e contextuais (como clareza, adaptabilidade e adequação ao domínio) que os desenvolvedores valorizam. O TRACE oferece as ferramentas necessárias para diagnosticar e, potencialmente, corrigir esses viéses.