LLM como juiz: guia completo com exemplo prático de RAG

Comparando abordagens de LLM como juiz

Na prática, as equipes costumam adotar uma destas abordagens, dependendo do que querem medir:

1. Pontuação direta faz o juiz avaliar uma única saída em uma escala numérica (1 a 5, 1 a 10, conforme sua rubrica). Você recebe um número e, se tiver pedido, uma explicação escrita do raciocínio. É o ponto de partida mais comum, mas tem um problema de calibração ao qual voltarei.
2. Comparação em pares coloca duas respostas lado a lado e pede ao juiz para escolher a melhor. Isso contorna totalmente a questão da calibração numérica, porque o juiz só precisa fazer uma escolha relativa, não atribuir um número absoluto. Equipes usam muito quando comparam variantes de prompt ou versões de modelos entre si.
3. Avaliação com referência fornece ao juiz tanto a saída do modelo quanto uma resposta de referência (padrão-ouro) e pergunta quão bem a saída corresponde. Funciona melhor para Q&A factual e saídas estruturadas, quando você já tem ground truth rotulada para comparar.
4. Classificação binária reduz o julgamento a aprovado ou reprovado em uma propriedade específica. Esta resposta é fiel ao contexto? Contém informações pessoais identificáveis? É positiva? Esses checks binários são mais rápidos, mais baratos por avaliação e tendem a produzir resultados mais consistentes do que abordagens numéricas.

Imagem do autor. Quatro abordagens de LLM como juiz. 

Para uma visão direta de forças, casos de uso e limitações, comparei as quatro abordagens na tabela a seguir:

Para uma visão mais ampla de abordagens de avaliação além do padrão de juiz, LLM Benchmarks Explained cobre o panorama completo.

Como funciona um LLM juiz?

Na prática, é uma chamada de API simples: você empacota o conteúdo que quer avaliar (a saída do modelo, a pergunta original do usuário e qualquer contexto recuperado usado na geração) e envolve em um prompt que diz ao modelo-juiz o que importa para você e como quer os resultados formatados. 

O juiz processa isso e retorna uma resposta estruturada, geralmente uma nota acompanhada de um raciocínio escrito explicando por que atribuiu aquela nota. A qualidade da sua avaliação depende quase inteiramente de quão bem você escreve a rubrica. Não dá para enfatizar isso o suficiente. 

Um prompt simples que diz "avalie esta resposta de 1 a 5" vai gerar notas por toda parte, porque o juiz não tem um entendimento compartilhado do que significa um 3 versus um 4. Por isso você precisa detalhar, concretamente, como é cada nível de nota e incluir exemplos, se puder.

Implementando LLM como juiz

Agora, indo para a prática: vamos construir um pipeline de avaliação completo do zero — um sistema de retrieval augmented generation (RAG) que responde perguntas a partir de uma base de conhecimento pequena, um conjunto de consultas de teste projetadas para acionar diferentes modos de falha e um LLM juiz que pontua as saídas em fidelidade e relevância da resposta.

Configurando o ambiente

Você vai precisar de Python 3.9+ e uma API key da OpenAI, que pode ser obtida no console da OpenAI. Instale as dependências:

pip install openai chromadb langchain langchain-openai langchain-community deepeval

Defina sua chave de API:

import os
os.environ["OPENAI_API_KEY"] = "your-key-here"

Vamos usar OpenAI tanto para o gerador do RAG quanto para o LLM juiz, embora sejam modelos diferentes (GPT-4o-mini para geração, GPT-4o para avaliação). Para embeddings, text-embedding-3-small dá conta do recado para um tutorial. Em produção, vale a pena avaliar alguns modelos de embedding nos seus dados de domínio antes de decidir.

Se você quiser reforçar a base de RAG antes de entrar no código de avaliação, nosso curso Retrieval Augmented Generation (RAG) with LangChain passa pelos fundamentos.

Preparando dados e o vetor store

Precisamos de uma base de conhecimento pequena para o sistema RAG recuperar. Vou usar um conjunto de trechos de texto sobre a política de devolução de uma empresa fictícia. O conteúdo em si não é o foco aqui, mas ter um conjunto contido de documentos facilita ver exatamente quando o modelo extrapola além do contexto fornecido (que é o modo de falha que queremos que o juiz detecte).

from langchain_openai import OpenAIEmbeddings
from langchain_chroma import Chroma
from langchain.schema import Document

# Sample knowledge base
documents = [
    Document(
        page_content="All customers are eligible for a full refund within 30 days of purchase. "
        "The item must be in its original packaging and unused condition. Refunds are "
        "processed to the original payment method within 5-7 business days.",
        metadata={"source": "return_policy.pdf", "section": "refund_eligibility"}
    ),
    Document(
        page_content="Exchanges can be requested within 45 days of purchase for items of "
        "equal or lesser value. Size exchanges on clothing are free of charge. "
        "For items of greater value, the customer pays the difference.",
        metadata={"source": "return_policy.pdf", "section": "exchanges"}
    ),
    Document(
        page_content="Electronics have a 15-day return window due to rapid depreciation. "
        "Opened software and digital downloads are non-refundable. Defective electronics "
        "can be returned within 90 days with proof of defect from an authorized service center.",
        metadata={"source": "return_policy.pdf", "section": "electronics"}
    ),
    Document(
        page_content="Shipping costs for returns are covered by the company for defective items. "
        "For non-defective returns, the customer is responsible for return shipping. "
        "Free return shipping labels are available for loyalty program members regardless of reason.",
        metadata={"source": "return_policy.pdf", "section": "shipping"}
    ),
    Document(
        page_content="Gift purchases can be returned with the gift receipt for store credit only. "
        "Without a gift receipt, returns are processed at the lowest sale price in the last 90 days. "
        "Gift cards and prepaid cards are non-refundable and cannot be exchanged.",
        metadata={"source": "return_policy.pdf", "section": "gifts"}
    ),
]

# Create vector store
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(documents, embeddings, persist_directory="./chroma_db")

print(f"Indexed {len(documents)} documents")

Cinco documentos sobre políticas de devolução — não é muito, mas é suficiente para demonstrar os problemas de recuperação que importam: contexto incompleto, trechos irrelevantes puxados e oportunidades de alucinação quando o modelo sente pressão para dar uma resposta completa mesmo sem suporte total do contexto.

Construindo um pipeline RAG básico

O pipeline RAG recupera trechos relevantes e gera uma resposta. Nada de mais aqui: é o padrão recuperar-depois-gerar.

from openai import OpenAI

client = OpenAI()

def rag_query(question: str, top_k: int = 2) -> dict:
    """Run a RAG query: retrieve context, generate answer."""
    
    # Retrieve
    results = vectorstore.similarity_search(question, k=top_k)
    context = "\n\n".join([doc.page_content for doc in results])
    
    # Generate
    system_prompt = """You are a helpful customer support assistant. Answer the 
    customer's question based ONLY on the provided context. If the context doesn't 
    contain enough information to answer fully, say so."""
    
    user_prompt = f"""
      Context: {context}

      Question: {question}

      Answer:
    """
    
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt}
        ],
        temperature=0.3
    )
    
    answer = response.choices[0].message.content
    
    return {
        "question": question,
        "context": context,
        "answer": answer,
        "sources": [doc.metadata for doc in results]
    }

Escolhi GPT-4o-mini como gerador porque é barato e rápido — queremos que o foco seja a avaliação. A temperatura está em 0,3, o que reduz a aleatoriedade sem eliminá-la. 

E o system prompt instrui explicitamente o modelo a usar apenas o contexto fornecido, prática padrão em RAG, embora os modelos ainda escapem do contexto mais do que você imagina. É exatamente isso que queremos que o juiz sinalize.

Vamos testar:

result = rag_query("Can I return opened software?")
print(f"Question: {result['question']}")
print(f"Answer: {result['answer']}")
print(f"Sources: {result['sources']}")

Gerando um dataset de avaliação

Você precisa de casos de teste que exercitem diferentes partes do pipeline. Em produção, você coletaria a partir de consultas reais. Para este tutorial, montei um mix que inclui de propósito os tipos de perguntas em que sistemas RAG costumam tropeçar.

eval_questions = [
    # Straightforward questions (should be easy)
    "What is the refund window for regular purchases?",
    "Are exchanges free for clothing size changes?",
    
    # Questions requiring synthesis across chunks
    "What are my options if I received a defective laptop 60 days ago?",
    
    # Edge cases likely to cause hallucination
    "Can I get a refund for a digital download I purchased yesterday?",
    "What happens if I return a gift without the gift receipt?",
    
    # Questions where context might be incomplete
    "Do you offer refunds for international orders?",
    "Can I return an item I bought on sale?",
    
    # Adversarial or tricky questions
    "If I'm a loyalty member, do I get free return shipping even for electronics?",
]

# Generate RAG responses for all questions
eval_results = []
for q in eval_questions:
    result = rag_query(q)
    eval_results.append(result)
    print(f"Q: {q}")
    print(f"A: {result['answer'][:150]}...")
    print()

A mistura importa. Algumas perguntas têm respostas diretas e limpas nos documentos; outras exigem que o modelo combine informações de múltiplos trechos recuperados (o caso do laptop defeituoso precisa da política geral de reembolso em 30 dias e da cláusula de defeito em eletrônicos — 90 dias com comprovação).

E algumas, como a de pedidos internacionais, perguntam sobre temas que a base simplesmente não cobre. Essas últimas são onde você mais verá alucinações, porque o modelo quer ajudar e preenche lacunas com informação plausível, mas sem ancoragem no contexto real.

Para saber mais sobre como construir e testar sistemas RAG, nossa seleção de top 30 perguntas e respostas de entrevista sobre RAG é uma boa referência.

Configurando o LLM juiz

Agora a parte interessante. Vamos construir dois juízes separados: 

• Juiz de fidelidade: a resposta fica dentro dos limites do contexto recuperado?
• Juiz de relevância: a resposta de fato aborda o que foi perguntado?

def judge_faithfulness(question: str, context: str, answer: str) -> dict:
    """Judge whether the answer is faithful to the retrieved context."""
    
    eval_prompt = f"""
      You are an impartial judge evaluating whether an AI assistant's 
      answer is faithful to the provided context. 

      Faithfulness means every claim in the answer can be traced back to 
      information in the context. The answer should not contain information 
      that isn't supported by or inferable from the context.

      Score on a scale of 1 to 5:
      1 - The answer contains multiple claims not supported by the context
      2 - The answer contains at least one significant unsupported claim
      3 - The answer is mostly faithful but includes minor unsupported details
      4 - The answer is faithful with only trivial extrapolations
      5 - Every claim in the answer is directly supported by the context

      Context: {context}

      Question: {question}

      Answer to evaluate: {answer}

      Respond in this exact JSON format: {{"score": <int 1-5>, "reason": "<one paragraph explanation>"}}
    """

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": eval_prompt}],
        temperature=0.0,
        response_format={"type": "json_object"}
    )
    
    import json
    return json.loads(response.choices[0].message.content)


def judge_relevance(question: str, answer: str) -> dict:
    """Judge whether the answer is relevant to the question."""
    
    eval_prompt = f"""
      You are an impartial judge evaluating whether an AI assistant's answer 
      is relevant to the user's question.

      Relevance means the answer directly addresses what the user asked. 
      A relevant answer may acknowledge limitations in available information, 
      but it should not go off-topic or provide unrelated information.

      Score on a scale of 1 to 5:
      1 - The answer does not address the question at all
      2 - The answer partially addresses the question but misses the main point
      3 - The answer addresses the question but includes significant irrelevant content
      4 - The answer addresses the question well with minor tangents
      5 - The answer directly and completely addresses the question

      Question: {question}

      Answer to evaluate: {answer}

      Respond in this exact JSON format: {{"score": <int 1-5>, "reason": "<one paragraph explanation>"}}
    """

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": eval_prompt}],
        temperature=0.0,
        response_format={"type": "json_object"}
    )
    
    import json
    return json.loads(response.choices[0].message.content)

Algumas escolhas de design aqui. A temperature está em 0.0 para máxima consistência entre execuções. Estamos usando response_format={"type": "json_object"} para garantir saída parseável sempre.

A rubrica descreve cada nível de nota de forma concreta, em vez de rótulos vagos como "boa" ou "ruim". Sem essa especificidade, o juiz tende a dar tudo como 3 ou 4 — o que não ajuda em nada.

Note que o GPT-4o faz a avaliação enquanto o GPT-4o-mini faz a geração. Ter o juiz mais capaz que o gerador é comum, pois o juiz precisa seguir instruções com firmeza para aplicar a rubrica com consistência. 

Se você usa o mesmo modelo para os dois papéis, também introduz um viés conhecido de autopreferência, em que o modelo avalia melhor as próprias saídas.

Rodando o loop de avaliação

Hora de rodar tudo e coletar os resultados.

import json

evaluation_report = []

for result in eval_results:
    # Run both judges
    faithfulness = judge_faithfulness(
        result["question"], result["context"], result["answer"]
    )
    relevance = judge_relevance(
        result["question"], result["answer"]
    )
    
    evaluation_report.append({
        "question": result["question"],
        "answer": result["answer"][:200],
        "faithfulness_score": faithfulness["score"],
        "faithfulness_reason": faithfulness["reason"],
        "relevance_score": relevance["score"],
        "relevance_reason": relevance["reason"],
    })
    
    print(f"Q: {result['question']}")
    print(f"  Faithfulness: {faithfulness['score']}/5 | Relevance: {relevance['score']}/5")
    print(f"  Faith reason: {faithfulness['reason'][:100]}...")
    print()

# Summary statistics
faith_scores = [r["faithfulness_score"] for r in evaluation_report]
rel_scores = [r["relevance_score"] for r in evaluation_report]
print(f"Average faithfulness: {sum(faith_scores)/len(faith_scores):.2f}")
print(f"Average relevance: {sum(rel_scores)/len(rel_scores):.2f}")
print(f"Questions with faithfulness < 3: {sum(1 for s in faith_scores if s < 3)}")

Cada pergunta aciona duas chamadas de API ao GPT-4o, uma por juiz. Para nossas oito questões, são 16 avaliações ao todo — tranquilo. Em produção, com milhares de consultas diárias, você vai querer fazer lotes, rodar de forma assíncrona e, provavelmente, avaliar só uma amostra em vez de cada resposta.

Analisando resultados e iterando

As notas dão uma visão geral, mas é o raciocínio que mostra o que precisa ser corrigido.

# Find problematic responses
print("=== LOW FAITHFULNESS (score < 4) ===")
for r in evaluation_report:
    if r["faithfulness_score"] < 4:
        print(f"\nQ: {r['question']}")
        print(f"Score: {r['faithfulness_score']}")
        print(f"Reason: {r['faithfulness_reason']}")
        print(f"Answer preview: {r['answer'][:150]}...")

print("\n=== LOW RELEVANCE (score < 4) ===")
for r in evaluation_report:
    if r["relevance_score"] < 4:
        print(f"\nQ: {r['question']}")
        print(f"Score: {r['relevance_score']}")
        print(f"Reason: {r['relevance_reason']}")

A pergunta sobre pedidos internacionais e a de itens em promoção provavelmente terão notas baixas em fidelidade, porque a base não aborda esses tópicos — e o modelo tende a improvisar uma resposta. 

A do laptop defeituoso também é interessante, pois exige sintetizar a política geral de reembolso (30 dias) com a cláusula de defeito em eletrônicos (90 dias com comprovação) e, dependendo de quais trechos forem recuperados, o modelo pode ou não ter o quadro completo.

O que fazer com os resultados depende do que você encontrar. Baixa fidelidade em certas categorias de perguntas geralmente aponta para duas coisas: ou o recuperador está trazendo os trechos errados (problema de recuperação) ou o gerador está indo além do contexto dado (problema de geração). 

Olhar o contexto recuperado junto com a resposta diz qual é o caso. Já notas baixas de relevância, em geral, indicam que o system prompt precisa de ajuste — ou que o contexto recuperado está tão fora do tema que o modelo não tem material útil.

Para o lado operacional de rodar avaliações como parte do seu pipeline de deployment, o curso LLMOps Concepts cobre infraestrutura e padrões de workflow.

Usando DeepEval para avaliação estruturada

Escrever funções de juiz personalizadas funciona, mas, para produção, você provavelmente vai querer um framework que cuide do boilerplate. O DeepEval é uma das opções mais maduras e traz métricas bem testadas que cobrem os critérios mais comuns de avaliação.

from deepeval import evaluate
from deepeval.test_case import LLMTestCase
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric

# Configure metrics
faithfulness_metric = FaithfulnessMetric(
    threshold=0.7,
    model="gpt-4o",
    include_reason=True
)

relevance_metric = AnswerRelevancyMetric(
    threshold=0.7,
    model="gpt-4o",
    include_reason=True
)

# Create test cases from our RAG results
test_cases = []
for result in eval_results:
    test_case = LLMTestCase(
        input=result["question"],
        actual_output=result["answer"],
        retrieval_context=[result["context"]]
    )
    test_cases.append(test_case)

# Run evaluation
evaluate(
    test_cases=test_cases,
    metrics=[faithfulness_metric, relevance_metric]
)

O que o DeepEval oferece e é trabalhoso construir por conta própria: 

• Lógica de retry quando o juiz retorna JSON malformado (acontece mais do que você imagina)
• Cache de resultados para reexecutar a avaliação sem dobrar a conta da API
• Integração com Pytest, permitindo ligar avaliações com LLM direto no seu pipeline de CI/CD. 

Cada métrica também gera uma autoexplicação, ou seja, toda nota vem acompanhada de um detalhamento do raciocínio do juiz — útil para inspecionar quando algo parece fora do lugar.

Para um olhar mais profundo sobre as capacidades do DeepEval, veja Evaluate LLMs Effectively Using DeepEval.

Boas práticas de LLM como juiz

Fazer um LLM juiz devolver números é simples. Fazer esses números realmente significarem algo útil para sua equipe exige mais cuidado do que a maioria espera.

Frameworks e métricas de avaliação

Além do DeepEval, há vários frameworks para escolher — e o cenário só cresce. Eis uma comparação prática baseada em onde cada um se encaixa melhor:

Para sistemas RAG, quatro métricas cobrem a maioria das necessidades na prática.

1. Fidelidade indica se a resposta gerada permanece ancorada no contexto recuperado. Se a nota volta 0,6, significa que cerca de 40% das afirmações na resposta não têm suporte nos documentos. É seu principal detector de alucinação e, na minha experiência, a métrica mais importante para acompanhar continuamente.
2. Relevância da resposta captura se a resposta realmente aborda o que foi perguntado — uma questão totalmente diferente. Uma resposta pode ser perfeitamente fiel ao contexto (tudo confere) e ainda assim perder o ponto central da pergunta.
3. Precisão do contexto olha para o lado da recuperação: os documentos relevantes estão ranqueados no topo? Se o documento com a resposta aparece na posição 5 de 5, sua recuperação funciona, mas o ranking é ruim — e isso afeta a geração, porque os modelos prestam mais atenção ao que aparece primeiro na janela de contexto.
4. Recall do contexto vai no sentido oposto e verifica quanto da informação necessária para responder foi de fato recuperada. Recall baixo é problema de infraestrutura de recuperação; nenhum prompt engineering na geração compensa a falta de contexto.

Rode essas métricas em conjunto, porque diferentes combinações de notas altas/baixas apontam para causas-raiz distintas.

• Alta fidelidade com baixa relevância: o modelo reflete bem o contexto, mas o contexto não era relevante para a pergunta. 
• Baixa fidelidade com alta relevância: o modelo entendeu a pergunta, mas extrapolou além do contexto fornecido para respondê-la. 

Cada combinação indica onde agir.

Para prática hands-on com acompanhamento de avaliação no MLflow, Evaluating LLMs with MLflow mostra a integração.

Boas práticas de deployment em produção

Levar para produção exige mais do que rodar avaliações no notebook. Na prática, os problemas em escala caem em cinco frentes que valem ser endereçadas antes de você adotar a abordagem.

1. Planeje em torno de vieses conhecidos. Juízes com LLMs consistentemente avaliam melhor respostas mais longas (viés de verbosidade) e tendem a favorecer levemente a resposta que aparece primeiro em comparações em pares (viés de posição). A mitigação padrão para posição é rodar cada comparação nas duas ordens e contar o resultado só quando o juiz for consistente em ambas. Para verbosidade, adicione linguagem explícita na rubrica de que concisão é aceitável — ou até preferível. Isso reduz o efeito, mas não elimina.
2. Calibre com julgamento humano antes de confiar nas notas. Junte de 50 a 100 exemplos já avaliados por humanos no seu domínio, rode no juiz e verifique a taxa de concordância; menos de 75% indica que a rubrica precisa de mais refinamento. Repita periodicamente, porque tanto o modelo juiz quanto sua aplicação evoluem — ou seja, o que estava bom há seis meses pode ter mudado conforme prompts, dados ou versões de modelo.
3. Cheque consistência separadamente da precisão. Rode as mesmas entradas duas vezes no juiz e compare as saídas. Se uma resposta leva 3 em uma execução e 5 na seguinte, sua rubrica abre margem demais para interpretação. Nesse caso, avaliações binárias (passa/falha) tendem a ser mais confiáveis do que escalas de 5 pontos para monitoramento em produção; considere colapsar as notas em binário para operação e deixar a granularidade para análises offline.
4. Gerencie custo em escala. Prompts de avaliação são bem mais longos do que de geração, pois incluem a pergunta original, o contexto completo recuperado, a resposta gerada e a rubrica com critérios. Em sistemas de alto volume, um padrão econômico é rodar avaliações detalhadas em uma amostra aleatória de 10% das consultas e aplicar checks automatizados mais simples (tamanho, conformidade de formato, presença de palavras-chave) nos outros 90%.
5. Mantenha humanos no loop. Mesmo com o juiz operando bem, estabeleça uma revisão regular em que alguém do time examina uma amostra aleatória das avaliações do juiz toda semana. Dê atenção especial às respostas com nota máxima (5/5), pois são justamente os casos em que um erro despercebido gera mais confiança indevida.

Para mais sobre operacionalizar fluxos com LLM de ponta a ponta, a trilha Associate AI Engineer for Data Scientists cobre o quadro completo de deployment.

Conclusão

LLM-como-juiz atende a uma necessidade prática que nem métricas automatizadas tradicionais nem revisão humana conseguem cobrir, em escala, sozinhas. Métricas automatizadas deixam passar o que realmente importa para apps com LLM; já a avaliação humana pega o que importa, mas não acompanha o volume de um sistema em produção. 

Um LLM juiz no meio oferece uma forma de monitorar continuamente a qualidade das saídas, com nuances que métricas simples não alcançam.

Neste tutorial, construímos um pipeline completo: um sistema RAG com uma base pequena, consultas de teste feitas para acionar diferentes modos de falha, juízes personalizados para fidelidade e relevância, e uma abordagem com framework usando o DeepEval — mais próxima do que você rodaria em produção.

Se há uma lição principal aqui, é que a rubrica é tudo. Invista tempo em escrever critérios específicos e concretos, com exemplos claros para cada nível de nota. Uma rubrica bem desenhada com um modelo mediano supera uma rubrica vaga com o modelo mais capaz — sempre.

Se você quiser continuar a partir daqui:

• Building a RAG System with LangChain and FastAPI leva o pipeline RAG do notebook para um serviço de produção.
• Developing LLM Applications with LangChain cobre o workflow de desenvolvimento mais amplo, incluindo chains, agents e memory.
• Introduction to LLMs in Python vale a revisão se você quiser solidificar os fundamentos antes de avançar.
• 12 LLM Projects For All Levels traz mais ideias de projetos para praticar.
• What is Retrieval Augmented Generation (RAG)? aprofunda o conceito de RAG.