Avaliação de LLMs com DeepEval e Ragas: Guia Prático para 2026

Atualizado: 17 de junho de 2026

A avaliação de LLMs é o processo sistemático de medir a qualidade, precisão e segurança das respostas de modelos de linguagem grande usando métricas objetivas, conjuntos de testes e juízes automatizados, em vez de inspeção manual ad-hoc. Em 2026, dois frameworks open-source dominam o ecossistema Python: DeepEval, focado em testes unitários estilo pytest para qualquer aplicação LLM, e Ragas, especializado em avaliar pipelines RAG (Retrieval-Augmented Generation). Este guia mostra, com código real e métricas concretas, como integrar ambos em sua pipeline de CI/CD e parar de "achar" que seu modelo está bom.

• DeepEval funciona como o pytest para LLMs: cada teste assertEqual vira um assert_test() com métricas como G-Eval, hallucination e bias.
• Ragas calcula quatro métricas centrais para RAG (faithfulness, answer relevancy, context precision e context recall) com versão 0.2+ usando LLM-as-a-Judge por padrão.
• LLM-as-a-Judge usa GPT-4o, Claude Opus 4.7 ou Gemini 2.5 Pro como avaliador; correlação com julgamento humano fica entre 0.7 e 0.85 em benchmarks recentes.
• Ambos os frameworks integram com Langfuse, OpenTelemetry e GitHub Actions, permitindo bloquear PRs que regridem em métricas críticas.
• Conjuntos sintéticos gerados pelo próprio Ragas (testset generator) reduzem custo de criação de golden datasets em até 90%.
• O custo de avaliar 1.000 amostras com GPT-4o como juiz fica em torno de US$ 8–15 dependendo do tamanho do contexto.

O que é avaliação de LLMs e por que importa

Avaliação de LLMs (frequentemente chamada de LLM evals) é a disciplina de transformar julgamento subjetivo sobre respostas de modelos em sinais numéricos reprodutíveis. Sem evals, equipes confiam em "vibes". Alguém roda 10 prompts, acha bom, dá deploy. Já vi isso acontecer mais vezes do que gostaria. Quando o modelo regride após um fine-tune, mudança de prompt ou upgrade de versão (GPT-4o → GPT-5, Claude Sonnet 4.5 → 4.6), ninguém percebe até um usuário reclamar.

O ciclo correto tem quatro etapas: (1) construir um conjunto de avaliação (golden dataset) com 50–500 exemplos representativos; (2) definir métricas que reflitam o que importa para o negócio (fidelidade ao contexto para RAG, ausência de viés para chatbots públicos, formato JSON válido para APIs estruturadas); (3) rodar evals automatizados em cada mudança; (4) bloquear releases quando métricas críticas regridem além de um limiar.

O impacto é mensurável. Segundo o paper original "Judging LLM-as-a-Judge with MT-Bench", juízes GPT-4 atingem 85% de concordância com avaliadores humanos especialistas, taxa equivalente à concordância entre dois humanos. Isso tornou viável escalar avaliação para milhares de amostras sem orçamento de anotação humana proibitivo.

DeepEval vs Ragas: qual escolher

Os dois frameworks resolvem problemas diferentes. DeepEval é genérico e roda como o pytest: você escreve test_*.py com asserts sobre saídas de qualquer LLM. Ragas é especializado em RAG e foca em quatro métricas canônicas que medem se o seu sistema de recuperação está alimentando o gerador com o contexto certo. A tabela abaixo compara as dimensões que realmente diferenciam os dois.

Dimensão	DeepEval	Ragas
Foco principal	Testes unitários para qualquer LLM	Avaliação de pipelines RAG
Modelo de execução	pytest-like (assert_test())	Batch sobre EvaluationDataset
Métricas built-in	14+ (G-Eval, hallucination, bias, toxicity, summarization)	8 (faithfulness, answer relevancy, context precision/recall, noise sensitivity)
Geração de dataset sintético	Sim, via Synthesizer	Sim, via TestsetGenerator (multi-hop)
Integração CI/CD	Nativa (GitHub Actions, plugin pytest)	Via scripts ou Langfuse
Multimodal	Sim (texto + imagem desde 2.0)	Limitado a texto
Custo típico (1k amostras, GPT-4o juiz)	US$ 10–18	US$ 8–15
Curva de aprendizado	Baixa para quem já usa pytest	Média (entender as 4 métricas core)

Regra prática: se você está construindo um chatbot, agente ou classificador, comece com DeepEval. Se você está construindo RAG sobre uma base de documentos, comece com Ragas e adicione DeepEval depois para testes de segurança e formato. Os dois podem coexistir no mesmo projeto — eu uso ambos em produção há cerca de oito meses.

Métricas essenciais para avaliar LLMs em 2026

Antes de escolher framework, é preciso entender o que cada métrica realmente mede. As cinco abaixo cobrem 80% dos casos de uso reais.

Faithfulness (fidelidade)

Mede se a resposta gerada contém apenas afirmações sustentáveis pelo contexto recuperado. Funciona extraindo cada afirmação da resposta com um LLM e verificando se cada uma pode ser inferida do contexto. Pontuação 1.0 = nenhuma afirmação não-suportada. É a métrica anti-alucinação por excelência em RAG.

Answer Relevancy

Avalia quão diretamente a resposta endereça a pergunta. O Ragas gera N perguntas reversas a partir da resposta e calcula similaridade cosseno com a pergunta original. Respostas evasivas ou tangenciais caem para 0.4–0.6.

Context Precision e Context Recall

Precision mede se os documentos recuperados relevantes aparecem nos primeiros postos do ranking (sinal para retriever). Recall mede se TODA informação necessária para responder está presente no contexto (sinal para chunking e índice).

G-Eval

Métrica genérica do DeepEval onde você descreve em linguagem natural o critério ("a resposta deve ser educada e em português brasileiro") e o framework gera automaticamente os steps de avaliação usando chain-of-thought. Ideal para critérios de produto não cobertos por métricas pré-definidas.

Hallucination, Bias e Toxicity

Detectam respostas factualmente erradas (alucinação), enviesadas por gênero/raça/idade (bias) e tóxicas ou ofensivas (toxicity). Essenciais para qualquer LLM com interface pública.

Avaliando um chatbot com DeepEval passo a passo

Vou mostrar como avaliar um chatbot de suporte técnico em Python. Instale DeepEval 2.x e configure a chave do OpenAI (qualquer modelo OpenAI-compatível funciona, incluindo Azure e Ollama local).

pip install -U "deepeval>=2.0.0"
export OPENAI_API_KEY="sk-..."
deepeval set-openai --model="gpt-4o-mini"

Crie um arquivo test_chatbot.py com um teste por caso de uso:

import pytest
from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import (
    AnswerRelevancyMetric,
    HallucinationMetric,
    GEval,
)
from deepeval.test_case import LLMTestCaseParams

# Seu cliente LLM real (OpenAI, Anthropic, vLLM local)
from meu_chatbot import responder

@pytest.mark.parametrize(
    "pergunta,contexto",
    [
        (
            "Como reseto minha senha?",
            ["Para resetar a senha, acesse /conta/senha e clique em 'Esqueci'."],
        ),
        (
            "Qual o horario de atendimento?",
            ["Atendemos de segunda a sexta, das 9h as 18h, horario de Brasilia."],
        ),
    ],
)
def test_chatbot(pergunta, contexto):
    resposta = responder(pergunta, contexto)
    caso = LLMTestCase(
        input=pergunta,
        actual_output=resposta,
        retrieval_context=contexto,
        context=contexto,
    )

    relevancia = AnswerRelevancyMetric(threshold=0.7, model="gpt-4o-mini")
    alucinacao = HallucinationMetric(threshold=0.3, model="gpt-4o-mini")
    tom = GEval(
        name="Tom profissional",
        criteria="A resposta deve ser educada, em PT-BR, e nao usar girias.",
        evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT],
        threshold=0.8,
        model="gpt-4o-mini",
    )

    assert_test(caso, [relevancia, alucinacao, tom])

Rodar é igual ao pytest: deepeval test run test_chatbot.py. O comando exporta um relatório HTML com pontuações por métrica, motivo do juiz (chain-of-thought) e pass/fail por threshold. Eu costumo configurar threshold de 0.7 para relevancy e 0.3 para hallucination. Ou seja, no máximo 30% de afirmações não-suportadas.

Avaliando uma pipeline RAG com Ragas

Para RAG, Ragas é mais ergonômico. Instale a versão 0.2+ e prepare um EvaluationDataset com quatro colunas: user_input, response, retrieved_contexts e reference. Para conectar com nosso conteúdo anterior sobre pipelines RAG em produção, este passo se encaixa após a etapa de geração e antes do deploy.

pip install -U "ragas>=0.2.10" datasets

from ragas import EvaluationDataset, evaluate
from ragas.metrics import (
    Faithfulness,
    ResponseRelevancy,
    LLMContextPrecisionWithReference,
    LLMContextRecall,
)
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI

juiz = LangchainLLMWrapper(ChatOpenAI(model="gpt-4o", temperature=0))

# Cada amostra reflete uma chamada real da sua pipeline
amostras = [
    {
        "user_input": "Qual e a politica de devolucao?",
        "retrieved_contexts": [
            "Devolucoes sao aceitas em ate 30 dias apos a compra...",
            "Produtos perecíveis nao sao elegiveis para devolucao...",
        ],
        "response": "Voce tem 30 dias para devolver, exceto perecíveis.",
        "reference": "30 dias, excluindo perecíveis.",
    },
    # ... mais 49 amostras representativas
]

dataset = EvaluationDataset.from_list(amostras)

resultado = evaluate(
    dataset=dataset,
    metrics=[
        Faithfulness(llm=juiz),
        ResponseRelevancy(llm=juiz),
        LLMContextPrecisionWithReference(llm=juiz),
        LLMContextRecall(llm=juiz),
    ],
)

print(resultado)
df = resultado.to_pandas()
df.to_csv("ragas_run_2026_06_17.csv", index=False)

O retorno é um DataFrame onde cada linha tem as quatro pontuações entre 0 e 1. Em produção, eu rodo Ragas duas vezes por semana sobre 200 amostras amostradas do tráfego real (anonimizadas) e plotando médias móveis no Grafana. Quedas súbitas em context_precision geralmente indicam que mudei o chunking; quedas em faithfulness indicam que o prompt do gerador permitiu mais especulação.

Para gerar um dataset sintético inicial quando você não tem dados de tráfego, use o TestsetGenerator:

from ragas.testset import TestsetGenerator
from langchain_community.document_loaders import DirectoryLoader

docs = DirectoryLoader("./base_conhecimento").load()
gerador = TestsetGenerator.from_langchain(generator_llm=juiz, embedding_model=embeddings)
testset = gerador.generate_with_langchain_docs(docs, testset_size=50)
testset.to_pandas().to_csv("golden_set.csv", index=False)

O que é LLM-as-a-Judge e quando usar

LLM-as-a-Judge é o padrão de usar um modelo (normalmente mais forte que o avaliado) como juiz das respostas. O juiz recebe a pergunta, a resposta candidata e, opcionalmente, uma referência, e retorna uma pontuação numérica com justificativa em chain-of-thought. Substituiu praticamente todas as métricas baseadas em n-grams (BLEU, ROUGE) para tarefas abertas porque correlaciona muito melhor com julgamento humano.

Use LLM-as-a-Judge quando: (1) a tarefa permite múltiplas respostas válidas (resumir, conversar, gerar código, escolher ferramentas em agentes com function calling); (2) você não tem golden answers exatas; (3) precisa avaliar critérios subjetivos como tom, clareza ou utilidade. Evite quando: (1) há uma resposta canônica única e barata de verificar com regex/parsing; (2) custo importa e há milhões de amostras (use modelos menores como juízes ou um destilado fine-tunado).

Para reduzir viés do juiz, três técnicas comprovadas: position swapping (rodar A→B e B→A em comparações pareadas), multi-judge (combinar GPT-4o + Claude Opus 4.7 e usar mediana), e reference-based (sempre que possível, fornecer a referência ao juiz em vez de pedir avaliação absoluta).

Como detectar alucinações em produção

Alucinações em produção exigem uma estratégia de duas camadas: detecção offline (em CI) e detecção online (durante inferência). Offline, use o FaithfulnessMetric do Ragas ou o HallucinationMetric do DeepEval sobre amostras de tráfego real. Online, três técnicas funcionam bem:

1. Self-check via logprobs: peça ao modelo para classificar sua própria resposta como "confiante" ou "incerto"; se a probabilidade do token "confiante" for menor que 0.7, marque a resposta para revisão humana.
2. SelfCheckGPT: gere 3–5 respostas com temperatura alta e meça consistência entre elas. Inconsistência alta = provável alucinação. Custa 3–5x mais por requisição mas detecta 70%+ dos casos.
3. Verificação contra contexto: em RAG, rode um segundo LLM barato (GPT-4o-mini, Haiku 4.5) que extrai cada afirmação da resposta e verifica presença literal ou parafrásica no contexto. Bloqueia respostas com mais de 30% de afirmações não-suportadas.

Para um deep-dive em padrões de prompt que reduzem alucinação na origem, complementa este artigo nosso guia de engenharia de contexto para agentes de IA.

Integrando evals no CI/CD com GitHub Actions

Evals só geram valor se rodarem em cada PR e bloquearem releases ruins. O padrão que uso há um ano:

# .github/workflows/llm-evals.yml
name: LLM Evals
on:
  pull_request:
    paths:
      - "prompts/**"
      - "src/llm/**"
      - "evals/**"

jobs:
  evals:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install -r requirements.txt
      - name: Rodar DeepEval
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: deepeval test run evals/ --junit-xml=eval-results.xml
      - name: Comparar contra baseline
        run: python evals/compare_baseline.py
      - uses: actions/upload-artifact@v4
        with:
          name: eval-report
          path: eval-results.xml

O passo compare_baseline.py compara as pontuações do PR contra as do main armazenadas em S3 e falha o job se qualquer métrica regredir mais que 5%. Isso impede que melhorias em uma dimensão escondam quedas em outra.

Observabilidade com Langfuse e OpenTelemetry

Evals offline em CI não capturam degradação em produção. Para isso, instrumente cada chamada LLM com Langfuse ou OpenTelemetry. Langfuse 3.0 (lançado em março de 2026) tem integração nativa com DeepEval e Ragas: traces enviados durante inferência são automaticamente avaliados em background usando as mesmas métricas do CI.

from langfuse.decorators import observe
from langfuse import Langfuse

langfuse = Langfuse()

@observe()
def responder(pergunta: str, contexto: list[str]) -> str:
    resposta = chamar_openai(pergunta, contexto)
    langfuse.score(
        trace_id=langfuse.get_current_trace_id(),
        name="faithfulness_proxy",
        value=score_simples(resposta, contexto),
    )
    return resposta

Dashboards mostram médias móveis das métricas por modelo, prompt version e segmento de usuário. Para fundamentos de instrumentação distribuída, a especificação Semantic Conventions for GenAI da OpenTelemetry é leitura obrigatória. Define atributos padronizados (gen_ai.system, gen_ai.request.model) que funcionam com qualquer backend (Langfuse, Datadog, Honeycomb).

Para o estado da arte em avaliação de RAG especificamente, a documentação oficial do Ragas mantém uma matriz atualizada de quais métricas fazem sentido para cada arquitetura (clássica, agentic, multi-hop).

Perguntas Frequentes

Qual a diferença entre DeepEval e Ragas?

DeepEval é um framework genérico tipo pytest com 14+ métricas (G-Eval, hallucination, bias) para qualquer LLM. Ragas é especializado em RAG com 8 métricas centradas em retrieval e geração (faithfulness, answer relevancy, context precision/recall). Use DeepEval para chatbots e agentes; use Ragas para pipelines RAG sobre bases de documentos. Os dois podem rodar juntos no mesmo projeto.

Quanto custa avaliar 1.000 respostas com LLM-as-a-Judge?

Usando GPT-4o como juiz, espere US$ 8–15 para 1.000 amostras com contextos de 1–2k tokens. Com GPT-4o-mini ou Claude Haiku 4.5 como juiz, cai para US$ 1–3, mas a correlação com humanos diminui de ~0.85 para ~0.7. Para CI/CD, rode amostras menores (50–100) em cada PR e datasets completos só semanalmente.

Como criar um golden dataset sem ter dados de produção?

Use o TestsetGenerator do Ragas ou o Synthesizer do DeepEval para gerar perguntas sintéticas a partir dos seus documentos. Comece com 50 amostras geradas, revise manualmente por 1–2 horas para remover questões triviais ou ambíguas, e expanda para 200–500 conforme o produto evolui. Sintético + curadoria humana custa ~10% do tempo de criar tudo do zero.

LLM-as-a-Judge tem viés contra respostas curtas?

Sim, e pesquisas de 2024–2025 mostram que GPT-4 e Claude tendem a preferir respostas mais longas e estruturadas, mesmo quando informações curtas são equivalentes. Mitigue usando avaliação pareada com position swapping, multi-judge (combine GPT-4o + Claude Opus + mediana), ou critérios G-Eval explícitos que penalizem verbosidade ("recompense concisão quando a resposta completa cabe em menos de 100 palavras").

Posso rodar Ragas e DeepEval com modelos locais (Ollama, vLLM)?

Sim. Ambos suportam qualquer backend OpenAI-compatível. Para Ollama, aponte OPENAI_BASE_URL para http://localhost:11434/v1. Para vLLM, idem com a porta do servidor. Como juiz, modelos menores que Llama 3.3 70B ou Qwen 2.5 72B costumam ter correlação baixa com humanos. Fique acima desse tamanho ou aceite ruído maior nas métricas.