LLM-as-a-Judge: como testar seu sistema LLM

Uma resposta de LLM pode soar segura, completa e profissional mesmo quando inventa fatos, ignora o contexto ou usa a ferramenta errada. Por isso, testar apenas o modelo ou usar um benchmark genérico não basta. Como mostram as discussões sobre LLMs e sistemas baseados em modelos, a qualidade precisa ser medida no caso de uso real.

Neste guia, você vai montar uma avaliação prática para sistemas LLM. O caminho combina testes determinísticos, comparação com referências, julgamento sem referência e revisão humana. A sequência é direta: definir o que significa funcionar, criar casos representativos, escrever uma rubrica, validar o juiz e acompanhar regressões.

Um sistema baseado em LLM funciona corretamente quando atende ao objetivo do caso de uso, dentro dos limites definidos para segurança, qualidade e operação. Isso raramente cabe em uma nota única. Uma resposta pode ser factual, mas incompleta; educada, mas inútil; ou correta, porém produzida com custo e latência inviáveis.

Comece separando as dimensões que realmente importam. Elas podem incluir exatidão factual, aderência ao contexto, relevância, completude, segurança, tom, idioma, uso correto de ferramentas e formato estruturado. Em um sistema RAG, por exemplo, a resposta precisa usar o contexto recuperado sem inventar informação ausente.

A avaliação de Grandes Modelos de Linguagem da UFSCar diferencia métricas tradicionais, benchmarks, avaliação humana e avaliação baseada em modelos. O material também alerta que é fácil construir um teste enviesado, que não representa as limitações reais do sistema.

A unidade de análise também muda o resultado. Testar o modelo isolado mede uma capacidade potencial. Testar o sistema mede o comportamento que chega ao usuário, incluindo prompt, recuperação, memória, ferramentas, filtros, guardrails, pós-processamento e tratamento de erros. A falha pode estar no modelo ou na integração entre essas camadas.

Para sistemas de pesquisa, uma rubrica útil pode separar factualidade, cobertura dos pontos esperados, qualidade das fontes e eficiência das ferramentas. A Anthropic descreve uma abordagem semelhante em seus sistemas de pesquisa, combinando verificações de fundamentação, cobertura e autoridade das fontes em vez de usar apenas uma nota geral. Veja o exemplo de avaliação de agentes de pesquisa.

Transforme cada dimensão em uma pergunta observável. “A resposta é boa?” é vago. “Cada afirmação factual importante está apoiada pelo contexto recuperado?” é testável. “O sistema chamou a ferramenta de faturamento somente quando a intenção exigia?” também é testável. Uma rubrica precisa orientar o avaliador para evidências, não para impressões.

Monte o conjunto de testes a partir de consultas reais, organizadas por intenção, dificuldade e modo de falha. Comece com uma amostra pequena, leia todas as respostas e expanda onde surgirem problemas. A Anthropic recomenda começar com poucos casos, porque essa leitura inicial revela rapidamente se o teste mede o comportamento desejado.

Uma matriz simples ajuda a evitar uma suíte formada apenas por perguntas fáceis. Separe casos normais, bordas, entradas ambíguas, solicitações sem resposta, idiomas relevantes, tentativas de prompt injection e cenários adversariais. Inclua também consultas longas, contexto contraditório, dados ausentes e pedidos que exigem recusa.

Não misture todos os conjuntos. O dataset de desenvolvimento serve para criar prompts e ajustar a arquitetura. O conjunto de regressão guarda falhas já corrigidas e casos que não podem voltar. O conjunto final deve permanecer protegido durante decisões importantes, para reduzir o risco de otimização acidental.

Registre mais do que entrada e saída. Cada exemplo deve carregar a intenção, o contexto esperado, a resposta de referência quando existir, a versão do prompt, o modelo, as ferramentas acionadas, a latência, o custo e os resultados por critério. Esse histórico permite explicar uma mudança, não apenas observar que a nota caiu.

Poucas consultas representativas já detectam alterações grandes. Porém, uma conclusão precisa sobre diferenças pequenas exige volume e desenho estatístico. A Anthropic recomenda reportar erro padrão, intervalos de confiança, diferenças pareadas e análise de poder. Em avaliações com perguntas relacionadas, erros padrão agrupados podem ser mais de três vezes maiores que os cálculos ingênuos. Confira as recomendações estatísticas da Anthropic.

Na prática, use a mesma consulta para comparar versões. Assim, a dificuldade do exemplo é compartilhada entre os candidatos. Depois, examine as diferenças por intenção. Uma média melhor pode esconder uma piora justamente na classe de perguntas mais importante para o produto.

Uma boa rubrica define critérios observáveis, escala curta, âncoras por faixa, evidência exigida e tratamento para informação insuficiente. Em vez de pedir “dê uma nota de qualidade”, descreva o que distingue uma resposta 1, 3 ou 5. Quanto menos espaço houver para interpretação, mais útil será o julgamento.

Escolha o tipo de avaliação conforme a pergunta. A avaliação pontual atribui uma nota a cada resposta. A comparação pareada escolhe entre resposta A, resposta B ou empate. A avaliação baseada em referência verifica se a saída contém fatos, campos ou passos esperados. Nenhuma abordagem resolve todos os critérios.

Use testes determinísticos para o que pode ser verificado por regra. Schema JSON, presença de campos, correspondência de identificadores, execução de código, limites numéricos e chamadas de ferramenta não precisam de outro LLM. A documentação de Graders da OpenAI descreve avaliadores baseados em modelo e avaliadores determinísticos, que podem ser combinados.

Para critérios abertos, peça uma saída estruturada com nota, justificativa curta, evidência e categoria da falha. A justificativa melhora a depuração, mas não prova que o julgamento está correto. Um juiz pode explicar muito bem uma decisão errada. Valide a nota contra exemplos ancorados e, quando possível, contra rótulos humanos.

Randomize a ordem das respostas e oculte a identidade dos modelos. O estudo Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena encontrou vieses de posição, verbosidade e autopreferência. Ainda assim, juízes fortes alcançaram mais de 80% de concordância com preferências humanas em seus experimentos, aproximadamente o mesmo nível de concordância observado entre humanos.

Uma rubrica curta pode ter esta forma:

Para cada item, inclua exemplos de aprovação, falha parcial e falha grave. Também diga o que fazer quando o contexto não permite concluir. Uma resposta que admite insuficiência pode ser melhor que uma resposta confiante e inventada.

Valide o juiz contra um conjunto independente, ancorado por avaliadores humanos treinados. Compare o resultado conforme o tipo de tarefa: concordância e correlação para notas, acurácia e F1 para classes, ou taxa de escolha correta em comparações pareadas. O número certo depende da decisão que a avaliação precisa apoiar.

Monte o conjunto humano com especialistas no domínio quando o risco exigir. Defina critérios de desempate, registre desacordos e faça uma rodada de calibração antes da anotação principal. A avaliação humana também tem variabilidade. O objetivo não é produzir uma verdade perfeita, mas uma referência suficientemente consistente para testar o juiz.

Meça mais que concordância. Verifique consistência em repetições, sensibilidade a diferenças reais de qualidade, robustez a paráfrases, estabilidade quando a ordem é invertida, aderência à rubrica e taxa de saída inválida. Um juiz que concorda com humanos em casos fáceis pode falhar justamente nos casos ambíguos.

Concordância entre dois LLMs não equivale a alinhamento com humanos. Dois modelos podem repetir o mesmo viés de estilo, preferir respostas mais longas ou premiar uma forma de escrita que não ajuda o usuário. Por isso, a validação precisa incluir avaliações humanas e análise qualitativa dos desacordos.

Faça calibração periódica. Separe uma amostra de casos novos, revise exemplos de alto risco e atualize as âncoras quando a rubrica mudar. Se o modelo juiz, seu prompt ou os critérios forem alterados, trate a mudança como uma nova versão do instrumento de medição.

A estatística evita conclusões exageradas. A Anthropic recomenda usar diferenças pareadas, intervalos de confiança e análise de poder para distinguir melhora real de sorte na amostra. Se duas versões diferem por poucos pontos, o resultado precisa mostrar a incerteza dessa diferença, não apenas o placar final. Leia a abordagem estatística completa.

Uma boa análise de desacordo pergunta qual evidência o humano usou, qual evidência o juiz ignorou e qual parte da rubrica permitiu interpretações diferentes. Esse processo costuma melhorar a avaliação mais do que trocar imediatamente o modelo juiz.

Os riscos se dividem em quatro grupos: viés do juiz, falha da rubrica, falha de cobertura e falha operacional. Cada grupo exige um teste próprio. Sem essa separação, a equipe pode atribuir ao modelo avaliado um problema que nasceu no instrumento de medição.

O viés do juiz inclui posição, estilo, comprimento, autopreferência e familiaridade. Uma resposta pode receber nota maior por parecer mais detalhada. Outra pode ser penalizada por usar uma estrutura diferente, mesmo entregando a informação correta. O estudo sistemático sobre position bias em LLM-as-a-Judge analisou mais de 100 mil instâncias com 12 juízes e confirmou que a posição da resposta influencia comparações.

Para reduzir esse risco, compare as respostas nas duas ordens, faça a média dos resultados e investigue inversões. Oculte nomes de modelos, provedores e versões. Use pares de respostas com comprimentos semelhantes durante a validação. Se o resultado depender da posição, a nota não está medindo apenas qualidade.

A falha da rubrica aparece quando critérios vagos recompensam aparência. “Profissional”, “natural” e “inteligente” precisam de definição operacional. Prefira sinais verificáveis, como fatos apoiados, campos presentes, instruções seguidas, ferramenta correta e recusa adequada.

A falha de cobertura ocorre quando os testes são fáceis demais ou repetem uma única intenção. Inclua consultas de produção, casos sem resposta, contextos conflitantes, ataques de injeção, erros de ferramenta e idiomas realmente usados. A UFSCar destaca a necessidade de ir além do placar de benchmarks, especialmente em factualidade, robustez e segurança.

A falha operacional envolve saídas inválidas, aleatoriedade, mudanças de modelo, custo e latência. Execute repetições quando a geração for não determinística. Valide o schema antes do juiz. Registre tokens, tempo, chamadas de ferramenta e falhas de infraestrutura. Uma resposta excelente que chega tarde demais também pode ser uma falha do produto.

Separe o juiz do modelo avaliado quando possível. Use checagens determinísticas para regras. Encaminhe exceções e decisões de alto impacto para humanos. Monitore drift por intenção, idioma, fonte, versão do modelo e tipo de usuário. A confiabilidade surge da combinação desses controles, não de uma instrução dizendo ao juiz para ser imparcial.

Transforme a avaliação em uma barreira antes do deploy. Execute a suíte contra a versão candidata, compare com uma baseline fixa e bloqueie mudanças que violem thresholds críticos. Depois do lançamento, amostre tráfego real, encaminhe desacordos para revisão humana e incorpore novas falhas ao conjunto de regressão.

Separe gates por dimensão. Um sistema pode melhorar relevância e piorar segurança. Outro pode manter a qualidade, mas ultrapassar o limite de latência. Uma média única esconde essas trocas. Defina limites para factualidade, schema, recusas, completude, custo e tempo de resposta conforme o risco do produto.

Registre a versão do juiz, a rubrica, os parâmetros de geração, o dataset, o modelo avaliado e os resultados brutos. Guarde também as evidências usadas na decisão. Esse registro permite reproduzir uma avaliação, auditar uma aprovação e entender por que uma versão foi bloqueada.

Uma política prática combina três camadas. Use métricas determinísticas para schema, regras, identificadores e execução. Use LLM-as-a-Judge para qualidades abertas, como relevância, tom e completude. Use humanos para alto impacto, ambiguidade, desacordo persistente e casos fora da distribuição.

A suíte também precisa evoluir. Toda falha observada em produção deve ser classificada, reproduzida e adicionada ao conjunto adequado. Nem todo incidente vira um caso público de regressão, mas todo incidente relevante deve deixar um teste que impeça sua repetição silenciosa.

A experiência da Anthropic com sistemas de múltiplos agentes mostra por que a avaliação precisa acompanhar a arquitetura completa. Em um sistema de pesquisa, agentes coordenam busca, síntese e uso de ferramentas. A empresa relatou ganho de 90,2% em uma avaliação interna ao comparar uma configuração multiagente com um agente único, mas esse resultado depende do conjunto e da tarefa avaliados. Veja o relato técnico da Anthropic.

LLM-as-a-Judge é o uso de um modelo de linguagem para avaliar respostas geradas por outro modelo ou sistema. Ele pode atribuir notas, escolher entre duas respostas, verificar critérios ou apontar falhas. A técnica escala tarefas abertas, mas precisa de rubrica, exemplos calibrados e validação humana. Estudos com MT-Bench relataram mais de 80% de concordância em certos cenários, não uma garantia universal. Consulte o estudo original.

Defina o objetivo do caso de uso e transforme-o em dimensões observáveis. Teste consultas reais, bordas, ataques, entradas ambíguas e casos sem resposta. Combine verificações determinísticas, referências, juiz LLM e humanos. Avalie também ferramentas, recuperação, memória, latência, custo e formato. O sistema funciona quando atende ao objetivo completo, não apenas quando produz texto convincente.

Pode ser confiável para tarefas específicas, depois de calibrado contra humanos e testado contra vieses. A confiabilidade varia com domínio, rubrica, modelo juiz, ordem das respostas e diferença de qualidade entre candidatos. Position bias foi observado em mais de 100 mil instâncias de avaliações sistemáticas. Em aplicações críticas, mantenha revisão humana e não trate a nota como verdade absoluta. Veja o estudo sobre position bias.

A comparação pareada costuma ser útil quando a decisão é escolher entre duas versões. Ela reduz a exigência de definir uma escala absoluta e facilita comparar respostas na mesma consulta. A nota é melhor quando existem thresholds por critério ou quando você precisa acompanhar uma versão ao longo do tempo. Use ambas quando possível e verifique a estabilidade em ordens invertidas.

Nem sempre. Critérios de schema, regras e fatos conhecidos podem usar verificações determinísticas. Para tarefas abertas, o juiz pode avaliar relevância, tom ou completude sem uma resposta única. Ainda assim, referências parciais, fatos obrigatórios e exemplos de alta qualidade tornam o julgamento mais consistente. Quando não houver informação suficiente, a rubrica deve aceitar explicitamente a resposta “não é possível determinar”.

Não em decisões de alto impacto, casos ambíguos ou critérios que exigem conhecimento especializado. O juiz LLM reduz custo e aumenta cobertura, mas também reproduz vieses e pode justificar decisões erradas. Use humanos para criar e revisar o conjunto ancorado, investigar desacordos e recalibrar o instrumento. A avaliação híbrida oferece escala sem abandonar responsabilidade.

Antes de confiar em um LLM-as-a-Judge, confirme se a avaliação mede a qualidade que importa para o usuário e para o negócio. Uma nota alta pode refletir verbosidade, estilo ou familiaridade com o juiz. O teste decisivo é saber se o resultado prevê, de forma estável, o comportamento observado no uso real.

Use este checklist:

A pergunta central não é se o juiz deu uma nota alta. É se essa nota acompanha, com incerteza conhecida, a qualidade que o produto precisa entregar. Para continuar esse trabalho, leia também o guia do Data Hackers sobre como tornar agentes de IA mais previsíveis.

Avaliações melhores começam pequenas, ficam mais específicas a cada falha e nunca são tratadas como um placar definitivo. Se você trabalha com dados, IA ou engenharia de produto, assine a newsletter do Data Hackers para acompanhar novos guias sobre sistemas LLM, agentes e avaliação.