Avaliação de agentes com LLM-as-a-judge

Na engenharia de software tradicional, o output é previsível. No mundo dos Large Language Models (LLMs), a resposta pode ser semanticamente perfeita, mas escrita com palavras totalmente diferentes a cada execução.

Para colocar sistemas de IA em produção industrial de verdade, precisamos dar o passo definitivo: implementar a estratégia de LLM-as-a-judge (usar um LLM como juiz). Em suma, precisamos de uma IA para avaliar outra IA.

Vamos dissecar a mecânica, as métricas e os vieses que você precisa dominar para arquitetar esse pipeline de avaliação com maestria.

As configurações de julgamento

A pesquisa fundamental da indústria (como o framework do MT-Bench) consolida três formas principais de estruturar o fluxo de um LLM juiz:

Pairwise comparison (comparação em pares): O LLM juiz recebe a pergunta original do usuário e duas respostas candidatas (geradas pelo Modelo A e pelo Modelo B). O juiz deve determinar qual resposta é superior e justificar o voto. É a abordagem ideal para testes A/B de prompts ou para validar se uma atualização de modelo degradou o sistema.
Single answer grading (pontuação de resposta única): O juiz avalia uma única resposta de forma isolada, atribuindo uma nota (ex: de 1 a 5) ou um score booleano com base em critérios explícitos, como relevância, toxicidade ou completude.
Reference-backed grading (julgamento baseado em referência): O juiz recebe a pergunta, a resposta do agente e uma “resposta gabarito” (ground truth) escrita por especialistas humanos. O papel do juiz é pontuar o agente baseando-se no alinhamento conceitual com o gabarito, tolerando variações de vocabulário ou estilo.

Métricas de avaliação

Para que o seu juiz sintético seja confiável, o output dele precisa estar matematicamente alinhado com o bom senso de especialistas humanos. Medimos esse alinhamento calculando o Coeficiente de Correlação de Spearman ($\rho$) ou o Kappa de Fleiss, avaliando a taxa de concordância entre os vereditos dos engenheiros e as notas dadas pela IA avaliadora.

O mercado organiza essa validação através do framework RAG Triad, focando em três métricas principais:

Fidelidade (Faithfulness): Avalia se a resposta do agente foi baseada estritamente nos documentos recuperados pelo banco de vetores. É a ferramenta primária para detecção de alucinações.
Relevância da resposta (Answer relevance): Garante que o agente realmente sanou a dúvida do usuário, em vez de gerar um texto prolixo que desvia do assunto principal.
Relevância do contexto (Context relevance): Mede a qualidade do motor de busca (RAG). Os documentos que o sistema pescou no banco de dados eram de fato úteis e necessários para responder à pergunta?

Os vieses ocultos do juiz

Um LLM não é um árbitro 100% neutro. Modelos de linguagem sofrem de vieses matemáticos e estruturais estritos. Se você não mitigar esses fatores via engenharia, suas métricas de avaliação serão perigosamente maquiadas.

Viés de posição

Em avaliações de comparação em pares (pairwise), os LLMs tendem estatisticamente a favorecer a resposta que aparece primeiro no prompt (Modelo A).

Mitigação: Você deve rodar a avaliação duas vezes para o mesmo par de respostas, invertendo a ordem de exibição (A/B e depois B/A). Se o LLM mudar de opinião puramente por causa da posição do texto, o julgamento é inconsistente e deve ser descartado pelo pipeline.

Viés de verbosidade

Modelos adoram respostas longas, cheias de tópicos e bem formatadas. O juiz tende a dar notas maiores para outputs prolixos, mesmo que uma alternativa curta e direta seja cirurgicamente mais precisa.

Mitigação: Instrua explicitamente o prompt do juiz a penalizar o “blá-blá-blá”, orientando-o a avaliar a densidade de informação e a concisão.

Viés de auto-preferência

Se você utilizar o GPT-4 como juiz, ele tenderá a dar notas sistematicamente maiores para outputs que foram gerados pelo próprio GPT-4, demonstrando uma preferência oculta pelo seu próprio estilo de escrita em comparação ao Claude ou Llama.

Mitigação: Utilize prompts de avaliação agnósticos ou adote modelos de juízes que não participaram da geração das respostas candidatas.

Implementação no pipeline

Em produção de nível enterprise, você não escreve esses prompts de juiz do zero. Nós integramos frameworks consolidados como Ragas (Retrieval Augmented Generation Assessment) ou TruLens diretamente no pipeline de CI/CD ou em loops de monitoramento assíncrono.

Sempre que um desenvolvedor altera um prompt do sistema ou atualiza o modelo do agente, o pipeline dispara um teste em lote (batch) contra um dataset padrão ouro. Se os scores de qualidade caírem, o deploy é bloqueado automaticamente.

Análise de caso em produção

Imagine o seguinte cenário prático: seu time acabou de rodar uma atualização no agente de IA. O pipeline de monitoramento assíncrono acende uma luz vermelha e mostra que a métrica de Fidelidade (Faithfulness) despencou de $0.95$ para $0.60$, indicando um pico severo de alucinações.

Onde você deve abrir a investigação primeiro? Na estratégia de chunking/embedding do banco de dados ou na estrutura do prompt e temperatura do LLM do agente?

A resposta correta é na estrutura do prompt e na temperatura do LLM.

Por quê? Porque a métrica afetada foi a Fidelidade. A fidelidade mede especificamente se a resposta gerada pelo agente está ancorada no contexto que foi entregue a ele. Se o score caiu para $0.60$, significa que o banco de dados provavelmente buscou as informações certas (o contexto foi injetado), mas o LLM do agente decidiu ignorar o documento recebido, agindo por conta própria e alucinando dados que vieram do seu treinamento interno.

A investigação imediata deve focar em reduzir a temperatura do modelo do agente para torná-lo mais determinístico e em enrijecer o prompt do sistema com diretrizes claras, tais como: “Responda utilizando única e exclusivamente as informações contidas no contexto fornecido. Se a resposta não estiver presente, diga que não sabe”.

Portfólio, code e blog