LLM as a judge é um método de avaliação em que um modelo de linguagem atribui notas às saídas geradas por outro modelo ou aplicação de IA com base em uma rubrica específica, uma resposta de referência ou uma resposta concorrente. Equipes usam LLM-as-a-judge para avaliar tarefas abertas, como respostas de chatbots, respostas RAG e resumos, nas quais verificações de código por correspondência exata falham.
Ao criar uma aplicação baseada em modelos de linguagem, os testes rapidamente se tornam o maior gargalo. Testes unitários verificam se uma carga JSON pode ser interpretada, e métricas clássicas de linguagem natural como BLEU ou ROUGE contam palavras em comum. Porém, nenhuma dessas abordagens mostra se um resumo realmente faz sentido ou se um bot de atendimento respondeu educadamente. Como mostra o artigo G-Eval de Liu et al. de março de 2023, métricas baseadas em referências como BLEU e ROUGE apresentam correlação relativamente baixa com o julgamento humano em tarefas criativas e abertas.
A revisão humana é o padrão de referência, mas pedir que engenheiros ou especialistas leiam 500 saídas a cada ajuste em um prompt de sistema torna as iterações muito lentas. LLM-as-a-judge preenche a lacuna entre verificações rígidas de strings e a avaliação humana demorada. Ainda assim, avaliadores automáticos têm suas próprias falhas: podem favorecer a primeira resposta ou recompensar texto longo e vazio. Entender como essas configurações funcionam e onde falham faz a diferença entre um pipeline que detecta regressões e outro que gera falsa confiança.
O que é LLM as a judge e por que as equipes o usam?
LLM as a judge é uma técnica de avaliação automatizada que instrui um modelo de linguagem por meio de um prompt a pontuar, classificar ou verificar as saídas de outro modelo ou sistema. Em vez de depender da correspondência exata de strings, o modelo juiz lê o prompt de entrada, a saída gerada e as instruções de avaliação para produzir uma análise estruturada.
Equipes de software adotam LLM-as-a-judge porque aplicações modernas de IA podem produzir respostas válidas de milhares de maneiras. Ao criar um sistema de geração aumentada por recuperação (veja nosso guia sobre o que é RAG e como funciona), dois resumos do mesmo documento podem compartilhar poucas expressões exatas e ainda assim ser completamente corretos. Por outro lado, uma resposta pode compartilhar 90% das palavras de um texto de referência e inverter uma única negação, tornando a afirmação falsa.
Tanto a documentação de Graders da OpenAI quanto o guia de avaliação da Anthropic apresentam a avaliação por modelos, ao lado de verificações determinísticas de código e revisão humana, como um pilar dos testes. Na prática, as equipes usam três métodos principais para avaliar saídas de IA.
| Método de avaliação | Como funciona | Melhores usos | Principais limitações |
|---|---|---|---|
| Verificações por código | Usa correspondência exata, expressões regulares, validação de esquema JSON, verificações de strings ou execução de Python. | Saídas estruturadas, chamadas de ferramentas, validação de sintaxe e fatos determinísticos. | Falha com formulações abertas, tom ou equivalências semânticas sutis. |
| LLM as a judge | Solicita que um modelo avaliador pontue saídas usando uma rubrica, texto de referência ou escolha entre pares. | Resumos, utilidade de chatbots, tom e fidelidade de RAG às fontes fornecidas. | Exige uma chamada extra à API por item e sofre vieses de posição, verbosidade e autopreferência. |
| Revisão humana | Especialistas ou trabalhadores de plataformas avaliam as saídas manualmente. | Criar conjuntos de calibração com referência correta, auditar casos extremos de alto risco e avaliar nuances sutis do domínio. | Lenta, cara e difícil de executar continuamente a cada mudança de prompt ou código. |
Como funciona a avaliação LLM-as-a-judge?
A avaliação LLM-as-a-judge envia o contexto da tarefa, a saída candidata e um prompt de avaliação estruturado a um modelo avaliador, que retorna um raciocínio e uma nota ou preferência final. Dependendo do teste, a configuração geralmente segue um dos três padrões descritos no artigo sobre MT-Bench e Chatbot Arena de Zheng et al. de junho de 2023 e no framework G-Eval de março de 2023.
1. Avaliação de uma resposta (pointwise)
Na avaliação de uma resposta, o juiz examina um prompt e uma resposta do modelo isoladamente e atribui uma nota segundo uma rubrica. A nota pode ser uma decisão binária de aprovação ou reprovação (por exemplo, emitir apenas correct ou incorrect) ou uma escala de 1 a 5. Como observa a documentação de Graders da OpenAI, modelos de pontuação também podem conceder crédito parcial em vez de um estrito 0 ou 1.
No estudo G-Eval, Liu et al. combinaram raciocínio em cadeia de pensamento com um paradigma de preenchimento de formulários para avaliar saídas individuais. Em tarefas de resumo, o G-Eval baseado em GPT-4 alcançou uma correlação de Spearman de 0.514 com as notas humanas, superando métodos anteriores de avaliação automática. A avaliação pointwise é ideal para monitoramento em produção e testes de regressão porque cada caso recebe uma nota independente.
2. Comparação em pares
A comparação em pares fornece ao juiz um prompt e duas respostas candidatas (Answer A e Answer B) e pede que escolha a melhor ou declare empate. Essa configuração espelha a comparação humana de modelos em plataformas como Chatbot Arena, apresentada por Zheng et al. junto com 30,000 conversas com preferências humanas e 3,000 votos de especialistas sobre questões do MT-bench.
A comparação em pares costuma ser mais fácil para um modelo juiz do que atribuir um número abstrato de 1 a 10, sendo adequada para testes A/B de duas versões de prompt ou para decidir como escolher um modelo de IA para sua carga de trabalho. O problema é que comparações em pares não escalam bem para dezenas de candidatos e são muito vulneráveis à ordem das respostas.
3. Avaliação orientada por referência
A avaliação orientada por referência fornece ao juiz uma resposta de referência considerada padrão, uma lista de fatos obrigatórios ou o documento de origem junto da resposta candidata. Um modelo de linguagem não consegue verificar fatos que desconhece e, como explicamos em nossa análise das taxas de alucinação da IA, modelos frequentemente inventam detalhes plausíveis quando avaliam apenas de memória.
Ao fornecer ao juiz a solução correta ou trechos RAG recuperados, você transforma uma prova de conhecimento com consulta em uma verificação de compreensão de leitura muito mais simples. Essa abordagem é essencial para avaliar problemas matemáticos, desafios de raciocínio ou fidelidade factual.
Qual é a precisão dos juízes LLM em comparação com humanos?
Juízes LLM eficientes correspondem às preferências humanas com mais de 80% de concordância em tarefas abertas, o mesmo nível observado entre dois anotadores humanos diferentes. Esse parâmetro vem de Zheng et al. (junho de 2023, arXiv:2306.05685), que testaram GPT-4 como juiz em conversas do MT-bench e Chatbot Arena contra rótulos controlados de especialistas e votos humanos obtidos por crowdsourcing.
Esse resultado explica boa parte do interesse por juízes LLM: rótulos humanos são caros e demorados, e um juiz que concorda com pessoas quase tão frequentemente quanto elas concordam entre si pode assumir grande parte da avaliação rotineira. Porém, a concordância é uma média, e médias escondem onde o juiz falha.
Uma correlação geral alta pode ocultar pontos cegos importantes. Um juiz que concorda com humanos em 80% das conversas gerais ainda pode falhar sistematicamente quando uma resposta tem formatação persuasiva, ocupa uma posição favorável ou exige verificação matemática em várias etapas.
Onde LLM as a judge falha? Vieses comuns
O viés de um juiz LLM ocorre quando um modelo avaliador favorece sistematicamente saídas por características superficiais, como ordem, comprimento ou estilo de escrita, em vez da correção real. Pesquisas em vários benchmarks, resumidas no artigo de revisão A Survey on LLM-as-a-Judge de novembro de 2024 e detalhadas por Zheng et al., Wang et al. e Liu et al., apontam falhas contra as quais é importante se proteger.
Viés de posição e manipulação da ordem
O viés de posição é a tendência de um juiz LLM em comparações em pares a favorecer uma posição, geralmente a primeira resposta apresentada, independentemente da qualidade. No artigo Large Language Models are not Fair Evaluators de maio de 2023, Wang et al. demonstraram a gravidade da falha: ao manipular a ordem das respostas, o modelo menor Vicuna-13B venceu ChatGPT em 66 das 80 perguntas testadas quando o próprio ChatGPT atuava como avaliador. Se as comparações forem feitas apenas na ordem A seguida de B, os resultados do benchmark podem ser invertidos simplesmente mudando qual modelo aparece primeiro.
Viés de verbosidade
O viés de verbosidade ocorre quando um juiz LLM dá notas maiores a respostas mais longas e aparentemente detalhadas, mesmo que o texto adicional seja repetitivo, preenchimento ou um pouco fora do tema. Zheng et al. listam esse viés entre as principais limitações dos juízes LLM. Como modelos de linguagem geram facilmente preenchimento educado e listas com marcadores, um juiz não calibrado costuma recompensar uma resposta divagante de 400 palavras em vez de uma explicação concisa e correta de 80 palavras.
Viés de autopreferência
O viés de autopreferência descreve a tendência dos modelos de linguagem de favorecer saídas geradas por eles mesmos ou por modelos da mesma família. Zheng et al. identificaram esse viés como limitação dos juízes LLM, e Liu et al. apontaram uma possível preferência de avaliadores baseados em LLM por texto gerado por LLM. Se um modelo avaliar uma disputa direta entre ele e um concorrente, pode considerar sua própria redação mais natural e útil.
Capacidade limitada de avaliar raciocínio e matemática
Um modelo juiz não consegue avaliar com confiabilidade um problema de raciocínio ou matemática que ele próprio não consegue resolver. Zheng et al. listam a capacidade limitada de raciocínio como fraqueza dos juízes LLM e propõem medidas para alguns problemas, como fornecer uma resposta de referência. Se a resposta candidata contiver um erro de cálculo apresentado com confiança, o juiz pode ser levado a marcar a resposta errada como correta.
Injeção de prompt em saídas não confiáveis
Quando o juiz avalia texto influenciado por usuários finais ou páginas coletadas da web, a própria saída candidata pode conter instruções adversárias destinadas a sequestrar o avaliador, como uma instrução para ignorar regras anteriores e dar nota máxima. Se seu pipeline avalia entradas não confiáveis, consulte as defesas de nosso guia sobre o que é injeção de prompt para que uma string maliciosa não manipule sua suíte de avaliação.
| Viés ou falha | Causa | Como mitigar |
|---|---|---|
| Viés de posição | Juízes em pares preferem uma posição específica, como a primeira resposta, independentemente da qualidade. | Avaliar cada par nas duas ordens (A/B e B/A) com Balanced Position Calibration e contar apenas vitórias que se mantenham em ambas. |
| Viés de verbosidade | Avaliadores equiparam texto mais longo e formatação elaborada a maior utilidade. | Informar explicitamente na rubrica que comprimento não significa qualidade e comparar saídas de tamanho semelhante. |
| Viés de autopreferência | Modelos preferem texto compatível com sua própria distribuição de treinamento e hábitos de estilo. | Usar um juiz de família diferente da do gerador ou um painel diversificado de juízes. |
| Erros de matemática e raciocínio | O juiz não consegue verificar lógica em várias etapas na hora e é enganado por erros apresentados com confiança. | Fornecer uma resposta de referência verificada, exigir raciocínio antes da nota ou usar avaliadores determinísticos que executam Python. |
| Viés do avaliador em favor do estilo LLM | Avaliadores recompensam demais a redação LLM refinada em detrimento da precisão factual concisa. | Basear a rubrica em critérios concretos e empíricos de aprovação e calibrar notas com amostras rotuladas por humanos. |
Como configurar um juiz LLM confiável?
Para configurar um juiz LLM confiável, é preciso executar primeiro verificações determinísticas, escrever uma rubrica concreta que exija raciocínio antes da nota, controlar vieses de posição e família e calibrar com rótulos humanos. Siga esta lista ao criar sua suíte de avaliação.
- Execute verificações determinísticas antes de chamar um juiz LLM. Não pague um LLM para verificar se uma saída é JSON válido, contém uma palavra-chave obrigatória ou fica abaixo de 280 caracteres. Use primeiro avaliadores por código, como correspondência exata, expressões regulares, validação de esquema JSON e testes unitários, e reserve o juiz LLM para qualidades que o código não mede, como tom, utilidade e fidelidade às fontes.
- Forneça respostas de referência ou documentos de origem para verificar fatos. Quando a correção depender de fatos específicos, matemática ou conhecimento interno, passe diretamente ao prompt do juiz a referência correta ou o contexto RAG recuperado. Se seu fluxo exige verificar afirmações, combine a rubrica com as técnicas do guia sobre como verificar respostas de IA.
- Escreva uma rubrica concreta com escalas pequenas ou binárias. Instruções vagas como “avalie a qualidade de 1 a 100” produzem números ruidosos e inconsistentes. Como recomenda a documentação de avaliação da Anthropic, torne a rubrica específica e empírica: por exemplo, peça apenas
correctouincorrect, ou use uma escala de 1 a 5 bem definida com regras explícitas de aprovação para cada nível. Diga ao juiz que respostas mais longas não são melhores. - Exija raciocínio ou evidências antes da nota final. Tanto Wang et al., por meio de Multiple Evidence Calibration, quanto as diretrizes da Anthropic enfatizam que o modelo deve escrever sua justificativa ou ativar o pensamento antes do veredito. Como modelos autorregressivos geram tokens sequencialmente, apresentar primeiro a análise fundamenta a nota seguinte em evidências específicas do texto.
- Inverta a ordem das respostas em toda avaliação em pares. Para neutralizar o viés de posição, aplique Balanced Position Calibration: avalie
(Answer A, Answer B)em uma chamada e(Answer B, Answer A)em outra. Dê a vitória apenas se o juiz escolher a mesma resposta nas duas posições; caso contrário, registre empate. - Separe a família do juiz da do gerador ou use um painel de juízes LLM. Nunca deixe um modelo avaliar suas próprias saídas ao comparar fornecedores. Melhor ainda, considere substituir um único juiz avançado e caro por um júri. No artigo Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models de abril de 2024, Verga et al. mostraram que um Panel of LLM evaluators (PoLL) formado por vários modelos menores de famílias distintas superou um único juiz grande em três configurações e seis conjuntos de dados, apresentou menos viés intramodelo e custou mais de sete vezes menos. Como cada avaliação adiciona uma chamada à API por item de teste, usar modelos menores ou PoLL também é uma maneira simples de reduzir custos de API de IA.
- Calibre com exemplos rotulados por humanos e verifique periodicamente. Antes de confiar em um juiz automático em produção, crie um pequeno conjunto de calibração rotulado por humanos. Peça à equipe que avalie manualmente uma amostra de entradas reais, como 50 a 100 itens, e meça a frequência com que o juiz LLM concorda com os rótulos humanos. Refine a rubrica onde o juiz discordar dos especialistas e repita a calibração humana periodicamente conforme as consultas dos usuários evoluem.
Perguntas frequentes
Qual é a diferença entre avaliação LLM pointwise e em pares?
A avaliação pointwise avalia uma única saída isolada segundo uma rubrica e retorna aprovação ou reprovação, ou uma nota numérica como de 1 a 5. A avaliação em pares mostra ao juiz duas saídas candidatas lado a lado para o mesmo prompt e pergunta qual é melhor. Pointwise funciona melhor para monitoramento contínuo em produção e controles de regressão, enquanto pares são melhores para testes A/B diretos entre dois prompts ou modelos.
Como corrigir o viés de posição em LLM-as-a-judge?
Execute cada comparação em pares duas vezes com a ordem invertida: primeiro Model A e depois Model B; em seguida Model B e depois Model A. Wang et al. (maio de 2023) chamam isso de Balanced Position Calibration. Conte uma vitória apenas quando o juiz escolher a mesma resposta nas duas execuções; decisões divididas são empate.
Deve-se usar o mesmo LLM para gerar e avaliar respostas?
Não. Usar o mesmo modelo ou família para gerar e avaliar respostas introduz viés de autopreferência, no qual o juiz favorece saídas compatíveis com sua própria redação e distribuição de treinamento. Para manter a avaliação justa, escolha um juiz de família diferente das dos candidatos testados ou agregue votos de um painel diversificado de juízes LLM de famílias distintas.
Um juiz LLM pode substituir totalmente a avaliação humana?
Um juiz LLM não pode substituir totalmente a avaliação humana porque juízes automáticos precisam de rótulos humanos de referência para calibrar suas rubricas e detectar falhas sutis de domínio. Embora Zheng et al. (junho de 2023) tenham observado que juízes eficientes como GPT-4 alcançam mais de 80% de concordância com preferências humanas, pessoas ainda são necessárias para rotular conjuntos iniciais de calibração, auditar casos extremos e verificar raciocínios de alto risco no domínio.
Como reduzir o custo de LLM-as-a-judge em grande escala?
Execute primeiro verificações determinísticas gratuitas de código para que o juiz LLM processe apenas saídas que atendam às regras básicas de sintaxe e comprimento. Além disso, o estudo PoLL de Verga et al. de abril de 2024 constatou que um painel de modelos menores de famílias distintas custou mais de sete vezes menos que um único juiz grande e alcançou maior precisão.
Fontes
- Zheng et al., “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (arXiv:2306.05685, junho de 2023)
- Liu et al., “G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment” (arXiv:2303.16634, março de 2023)
- Wang et al., “Large Language Models are not Fair Evaluators” (arXiv:2305.17926, maio de 2023)
- Verga et al., “Replacing Judges with Juries: Evaluating LLM Generations with a Panel of Diverse Models” (arXiv:2404.18796, abril de 2024)
- Gu et al., “A Survey on LLM-as-a-Judge” (arXiv:2411.15594, novembro de 2024)
- Documentação da Anthropic: definir critérios de sucesso e criar avaliações
- Documentação da API OpenAI: guia de Graders



