Como avaliar RAG com rigor sem depender de “achismo”

TL;DR

Se você está montando ou operando um sistema RAG com vetor database, o ponto crítico não é só recuperar documentos: é provar, de forma repetível, que a resposta usa as evidências certas e não alucina. O material do brief aponta três linhas úteis para isso: ARES para avaliação automática com judges e PPI, RAGEval para geração de datasets de avaliação por cenário, e BenchmarkQED para benchmarking automatizado em escala.

Na prática, a lição é simples: avaliar RAG como se avalia modelo de linguagem puro costuma esconder falhas de retrieval, grounding e cobertura. Para times no Brasil, isso pesa mais ainda quando o custo de processamento e a janela de latência em us-east-1 afetam o orçamento, a operação e a experiência real do usuário.

Por que RAG precisa de avaliação própria

RAG não falha só no texto final. Ele pode recuperar contexto irrelevante, deixar de buscar a evidência correta, ou até responder de forma plausível sem estar fiel ao que foi recuperado. Por isso, medir apenas “resposta boa ou ruim” é pouco: você precisa separar o que veio do retriever, o que veio do gerador e o que foi herdado do contexto. O próprio ARES foi desenhado para avaliar dimensões como context relevance, answer faithfulness e answer relevance, com base no paper ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems.

Esse recorte é importante porque muda a engenharia do sistema. Se o retrieval está ruim, trocar o LLM não resolve. Se a fidelidade está ruim, talvez o problema seja prompt, chunking, reranking ou a forma como o contexto é montado. Avaliação de RAG serve exatamente para localizar esse tipo de gargalo.

ARES: judges leves e inferência com mais disciplina

ARES aparece no brief como um framework que treina judges leves com dados sintéticos e usa Prediction-Powered Inference para reduzir a dependência de anotações extensas. Em outras palavras: ele tenta tornar a avaliação menos manual e mais estatisticamente controlada. O paper oficial descreve a ideia no arXiv em ARES, e o repositório está em stanford-futuredata/ARES.

O valor prático aqui é separar componentes. Você pode manter o retriever fixo e trocar o gerador, ou fazer o inverso, e observar como as notas mudam. Isso ajuda a responder perguntas que realmente importam em produção: a base vetorial está trazendo contexto útil? O prompt está forçando a resposta a usar esse contexto? O score melhora quando o chunking muda?

Onde ARES ajuda no dia a dia

O framework é interessante quando você quer rodar benchmarks recorrentes, não apenas uma bateria manual pontual. Em squads com pouco tempo, isso evita que cada experimento vire uma discussão subjetiva sobre “a resposta parece melhor”. Você ganha uma régua para comparar versões do pipeline ao longo do tempo.

Isso também é útil quando o corpus muda muito. Em repositórios internos, documentação de produto e bases de suporte, o conteúdo envelhece rápido. Um judge consistente ajuda a detectar regressões depois de um reindex, de uma troca de embeddings ou de uma alteração no retriever.

RAGEval: avaliação orientada por cenário

O RAGEval segue uma linha complementar. Em vez de focar só na pontuação da resposta, ele gera datasets de avaliação pensados para cenários específicos, usando documentos-semente e configurações de geração. A descrição do paper está em RAGEval: Scenario Specific RAG Evaluation Dataset Generation Framework, com projeto em OpenBMB/RAGEval.

Esse tipo de abordagem é útil quando você trabalha com domínios verticais. Um sistema de atendimento bancário, por exemplo, não pode ser avaliado só com perguntas genéricas. Ele precisa ser testado com casos que reflitam política de crédito, limites operacionais, prazos, exceções de produto e linguagem do suporte. O RAGEval entra justamente nessa necessidade de contexto, ajudando a montar datasets mais próximos do uso real.

Do documento-semente ao caso de teste

O brief resume o fluxo como uma sequência de geração baseada em schema/config: pegar documentos iniciais, derivar estrutura, gerar variações e produzir pares pergunta e resposta com referências. Isso é útil porque tira a avaliação da mão do “caso famoso” e leva para um conjunto ampliado de situações. Em vez de depender de meia dúzia de exemplos bonitos, você testa o sistema contra um cenário mais próximo da operação.

O ganho técnico é o mesmo que se busca em qualquer boa suíte de testes: reduzir cegueira de cobertura. Se o seu RAG atende bem perguntas curtas, mas falha em perguntas compostas por múltiplos trechos, o problema aparece mais cedo. Se o corpus tem partes ambíguas, você descobre isso antes de levar uma versão para usuários finais.

BenchmarkQED: benchmarking automatizado em escala

BenchmarkQED entra mais como uma suíte de benchmarking do que como um ponto único de métrica. O anúncio oficial da Microsoft Research está em BenchmarkQED: Automated benchmarking of Retrieval-Augmented Generation (RAG) systems, e o repositório é microsoft/benchmark-qed.

Segundo o brief, o kit organiza geração de queries, avaliação e preparação de datasets. O componente AutoQ sintetiza consultas com escopo variável, indo de local queries a global queries, enquanto o AutoD traz utilitários para amostragem e sumarização. Isso ajuda a medir sistemas em níveis diferentes de dificuldade, o que é importante para saber se a falha está em recuperação pontual ou em raciocínio sobre um conjunto maior.

Por que isso importa para a engenharia do produto

Em produto real, nem toda pergunta é igual. Algumas têm resposta em um único trecho; outras exigem juntar várias evidências. Se a sua suíte de avaliação só mede perguntas simples, você cria um falso conforto. O BenchmarkQED força uma visão mais variada do comportamento do sistema, o que conversa bem com times que fazem rollout gradual, A/B testing e monitoramento contínuo.

Para equipes que trabalham com dados internos e documentação viva, isso também é um antídoto contra regressão silenciosa. Uma mudança pequena no chunk size, no top-k ou no reranker pode melhorar um tipo de pergunta e piorar outro. Sem benchmark com variedade, esse efeito passa batido.

Como escolher entre eles na prática

Se o objetivo é medir componentes do RAG com judges e inferência mais disciplinada, ARES é um bom ponto de partida. Se você quer construir um conjunto de teste mais aderente ao seu domínio, RAGEval é mais direto. Se a meta é padronizar benchmarking automatizado com geração de queries e datasets em escala, BenchmarkQED faz mais sentido.

Na prática, os três podem coexistir no mesmo fluxo. Um time pode usar RAGEval para criar cenários, ARES para pontuar componentes e BenchmarkQED para rodar bateria de regressão. Isso é mais útil do que procurar um único score mágico, porque o comportamento de RAG é multidimensional.

Por que importa pro dev brasileiro

No Brasil, esse tema bate em dois pontos concretos. Primeiro, o custo: muitas equipes rodam parte do stack em nuvem com cobrança em dólar, então cada benchmark manual repetido em embeddings, reranking e geração vira custo real em BRL quando o câmbio sobe. Segundo, a operação: sistemas voltados a usuários brasileiros frequentemente ficam em regiões como us-east-1 por disponibilidade e ecossistema, o que adiciona latência e faz cada ida e volta do RAG pesar mais na experiência.

Há também um fator regulatório. Em fluxos com dados pessoais, muito comuns em atendimento, saúde e financeiro, a LGPD exige cuidado redobrado com tratamento, retenção e minimização de dados. Avaliação bem feita ajuda a detectar quando o sistema está puxando contexto mais sensível do que deveria, antes que isso vire incidente.

Um fluxo prático para começar em até uma hora

Se você quiser transformar esse assunto em ação imediata, comece pequeno. Pegue 20 a 30 perguntas reais do seu produto, separe quais exigem evidência local e quais exigem síntese global, e rode a primeira bateria com um dos frameworks do briefing. O objetivo não é fechar um benchmark perfeito; é criar um ponto de comparação para a próxima alteração do pipeline.

Esta seção descreve a versão atual dos frameworks citados no brief. APIs e fluxos de avaliação mudam rápido — confira o changelog oficial antes de adotar em produção.

Depois, compare pelo menos três versões do seu pipeline: chunking atual, top-k alternativo e, se existir, reranker. Veja onde a recuperação perde contexto útil e onde a resposta escapa da evidência. Esse exercício costuma revelar muito mais do que uma simples revisão subjetiva de respostas.

Conclusão

A leitura mais prática do brief é esta: avaliação de RAG não deve ser tratada como uma etapa final decorativa. Ela faz parte da arquitetura, porque influencia retrieval, grounding, qualidade da resposta e custo de iterar. ARES, RAGEval e BenchmarkQED mostram três maneiras complementares de tornar isso mensurável.

Se você está trabalhando com vector database e RAG hoje, escolha um corpus real, monte um conjunto pequeno de casos e rode uma primeira comparação entre duas configurações do pipeline ainda hoje. Em menos de uma hora, você já terá sinais úteis para decidir o próximo ajuste.

Conteúdos da DIO para quem quer aprofundar

• Santander - RAG com ChromaDB, LlamaIndex e Python — conteúdo prático sobre como tornar uma aplicação RAG mais eficiente usando persistência de dados, ChromaDB e LlamaIndex.
• Database Experience — bootcamp para reforçar fundamentos de banco de dados SQL e NoSQL, úteis para quem precisa entender a camada de armazenamento por trás de RAG.
• Formação SQL Database Specialist — formação para aprofundar modelagem, DML, DDL e boas práticas de dados, base importante para pipelines que indexam informação estruturada.

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