Frameworks de avaliação para RAG: o que muda na prática

TL;DR

A avaliação de RAG deixou de ser um exercício informal e passou a exigir métricas separadas para recuperação e geração. Frameworks como RAGAS, DeepEval e Open RAG Eval ajudam a transformar esse processo em algo repetível, comparável e mais próximo do que times realmente precisam medir em produção.

Isso importa porque, em RAG, uma resposta pode soar correta e ainda assim depender de contexto ruim, top-k inadequado ou geração com claims não sustentados. Para equipes no Brasil, isso ganha peso quando o custo de inferência, a latência para us-east-1 e a exigência de conformidade com a LGPD entram na conta.

Por que avaliar RAG é diferente de avaliar um chatbot comum

Em um chatbot tradicional, você costuma olhar para qualidade textual, utilidade e segurança. Em RAG, existe uma divisão clara entre o que o sistema recupera e o que o modelo gera a partir disso. É exatamente essa separação que motivou a proposta do RAGAS, que descreve avaliação dos componentes do pipeline em vez de tratar saída final como um bloco único.

Na prática, isso evita um erro comum: considerar “boa resposta” um sinal suficiente de bom sistema. Se o retriever trouxe documentos fracos, a resposta pode parecer convincente só porque o LLM preencheu lacunas. Para RAG, isso é um problema central, porque o sistema pode até responder fluentemente, mas sem sustentação no contexto recuperado.

O que medir primeiro

Os frameworks de referência convergem em algumas dimensões recorrentes: relevância da resposta, fidelidade ao contexto, precisão da recuperação e cobertura dos trechos úteis. A lista de métricas do RAGAS deixa isso explícito ao organizar métricas como context precision, context recall, faithfulness e answer relevancy.

Esse recorte é útil porque ajuda a apontar o gargalo certo. Se a faithfulness cai, o problema pode estar na geração. Se context recall é baixo, o problema pode estar no chunking, no embedding ou na busca vetorial. Se answer relevancy cai apesar de bons contextos, o prompt ou o modelo de resposta podem estar mal calibrados.

RAGAS: foco em métricas separadas e avaliação sem referência

O RAGAS, descrito no paper Automated Evaluation of Retrieval Augmented Generation, é uma das referências mais citadas quando o objetivo é medir RAG sem depender sempre de golden answers. O ponto forte aqui é o desenho de métricas que tentam decompor o comportamento do sistema em partes observáveis do pipeline.

Essa abordagem é interessante para times que ainda não têm um conjunto robusto de respostas rotuladas. Em ambientes de negócio, isso é comum: o time quer validar um buscador interno, um assistente para jurídico ou um copiloto para suporte, mas ainda não existe um dataset de referência completo. O RAGAS permite começar com menos dependência de anotação humana.

Quando faz sentido usar

O RAGAS é útil quando você quer comparar experimentos de chunk size, top-k, modelo de embedding e prompt de geração. Como as métricas são mais ligadas ao comportamento do pipeline do que ao texto final isolado, ele ajuda a enxergar se a mudança realmente melhorou o sistema ou apenas mudou o estilo da resposta.

Outro ponto prático é que a documentação do RAGAS organiza um catálogo claro de métricas, o que facilita montar uma suíte de validação contínua. Isso conversa bem com times que querem colocar avaliação automática em CI, antes que uma alteração de prompt ou índice chegue em produção.

DeepEval: avaliação como suíte de testes

O DeepEval se apresenta como um framework de avaliação de LLMs com métricas que também cobrem RAG, como relevância e faithfulness. A diferença de ênfase é importante: em vez de só pensar em métrica, o foco é transformar avaliação em algo próximo de teste automatizado.

O guia oficial de RAG evaluation do DeepEval enfatiza a separação entre retrieval e generation e incentiva testar variáveis como top-K, prompt, embeddings e LLM. Isso é valioso para equipes que já trabalham com testes automatizados e querem trazer avaliação de RAG para o mesmo fluxo de engenharia.

Como isso ajuda no dia a dia

Se você tem um pipeline de RAG em produção, o ganho vem da repetibilidade. Ao codificar casos de teste e critérios de avaliação, fica mais fácil detectar regressão quando alguém muda o indexador, troca de modelo ou ajusta o template do prompt. Em vez de depender de inspeção manual, o time passa a ter uma régua estável para comparar versões.

Esse formato também facilita colaboração entre engenharia e produto. Um caso de uso interno em português, por exemplo, pode ser testado com perguntas reais de atendimento ou compliance, e os resultados viram evidência objetiva para decidir se um experimento vale a pena.

Open RAG Eval: comparabilidade e benchmark

O Open RAG Eval, da Vectara, foi apresentado como um framework open-source para comparar soluções de RAG. A proposta dele é reforçar comparabilidade entre configurações e alinhar a avaliação a métricas inspiradas no ecossistema TREC-RAG.

O anúncio oficial da Vectara em Introducing Open RAG Eval reforça esse posicionamento. Isso é útil quando você precisa sair da discussão vaga de “funcionou” e entrar em uma comparação reprodutível entre duas arquiteturas, dois conjuntos de embeddings ou duas estratégias de recuperação.

Onde ele se encaixa

O Open RAG Eval faz mais sentido para experimentação comparativa e para times que querem uma trilha de avaliação mais próxima de benchmark. O próprio projeto aponta conexão com o TREC RAG, o que ajuda a reduzir a ambiguidade na definição da pontuação quando há múltiplas implementações em disputa.

Na prática, ele mede melhor a diferença entre configurações e menos a experiência de teste contínuo do pipeline inteiro. Por isso, pode ser complementar a RAGAS e DeepEval em vez de substituí-los.

Como escolher entre os três sem complicar a operação

Se o objetivo é começar rápido e medir componentes do pipeline com menos dependência de resposta dourada, RAGAS é um bom ponto de partida. Se o time já opera com testes automatizados e quer avaliar RAG como parte do fluxo de engenharia, DeepEval tende a encaixar melhor. Se a meta é comparação entre soluções e alinhamento com benchmark, Open RAG Eval oferece um caminho mais voltado à experimentação comparativa.

Na realidade de um time brasileiro, o critério não é só técnico. Muitas vezes o orçamento em BRL limita o volume de chamadas ao LLM, a latência até uma região fora do país afeta a experiência, e a LGPD exige cuidado com dados sensíveis em documentos e logs. Avaliar RAG sem olhar para esses fatores pode levar a uma solução que parece boa no notebook, mas não fecha a conta no ambiente real.

Se o seu caso envolve dados pessoais, documentos internos de RH ou suporte com conteúdo sensível, trate avaliação de RAG como parte da governança de dados. No contexto da LGPD, tanto o conteúdo recuperado quanto o que é registrado em logs precisam ser pensados desde o desenho do teste.

Por que importa pro dev brasileiro

No Brasil, o custo de experimentar é diferente de muitos cenários de referência internacionais. Um ciclo com embeddings, busca vetorial e múltiplas chamadas de LLM pode ficar caro rápido quando a cobrança vem em dólar e o orçamento do time é fechado em real. Por isso, medir cedo qual parte do pipeline está degradando ajuda a evitar gasto com retentativas cegas.

Há também um fator operacional concreto: muitas empresas brasileiras ainda concentram workloads em regiões como us-east-1 por maturidade de serviços e disponibilidade de integrações. Isso pode adicionar latência perceptível para usuários no Brasil, então uma avaliação de RAG precisa olhar não só precisão, mas também tempo de resposta por configuração. Em casos com dados pessoais, a LGPD exige ainda mais disciplina sobre o que entra no contexto e no histórico de consultas.

Conclusão

Se você está montando ou revisando um pipeline de RAG, a principal mudança de mentalidade é parar de avaliar apenas o texto final. RAGAS ajuda a decompor o sistema em métricas específicas, DeepEval coloca a avaliação dentro do fluxo de testes, e Open RAG Eval ajuda na comparação orientada a benchmark.

Minha recomendação prática é começar pequeno: escolha um conjunto com 20 a 50 perguntas reais do seu domínio, defina uma métrica de retrieval e uma de geração, e compare duas configurações de chunking ou top-K. Em menos de uma hora, você consegue rodar um primeiro experimento com base no guia oficial do DeepEval ou na documentação de métricas do RAGAS.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.