Frameworks de avaliação para RAG: o que mudou de verdade

TL;DR

Frameworks de avaliação para RAG evoluíram de métricas genéricas para diagnósticos por componente: recuperação, geração e fidelidade ao contexto recuperado. Na prática, isso ajuda a identificar se o problema está no retriever, no prompt ou no modelo gerador, e acelera iterações em equipes que trabalham com aplicações de IA aplicada.

O que mudou na avaliação de RAG

O ponto central não é “medir se a resposta ficou boa” de forma abstrata. As fontes do brief mostram uma transição para avaliação por etapa do pipeline, algo que o guia do DeepEval descreve explicitamente ao separar retrieval e generation. Isso faz diferença porque o mesmo erro aparente pode vir de causas distintas.

Se o contexto veio ruim, ajustar o prompt costuma mascarar o problema. Se o contexto veio certo e a resposta alucinou, a métrica de faithfulness faz mais sentido do que uma métricade precisão genérica. É exatamente esse tipo de leitura que frameworks como Ragas e Phoenix passaram a organizar de forma operacional.

Avaliar retrieval e generation separadamente

A vantagem da avaliação component-level é simples: cada peça do sistema tem um tipo de falha diferente. O retriever pode trazer contexto incompleto, redundante ou fora de escopo; o gerador pode ignorar o contexto, misturá-lo com suposições ou responder com excesso de confiança. O guia de RAG do DeepEval reforça essa leitura ao tratar hiperparâmetros como embedding model, top-K, prompt e temperature como variáveis que precisam ser testadas em conjunto com as métricas.

Isso também muda o desenho dos experimentos. Em vez de olhar apenas a saída final, você passa a observar o contexto recuperado e o texto produzido. O resultado é um ciclo de debugging mais curto, porque a equipe consegue responder perguntas práticas como: “aumentar top-K ajudou ou só trouxe ruído?” e “o contexto estava bom, mas o modelo se perdeu na formulação?”

Exemplo de leitura mais útil de métricas

Quando um teste de RAG falha, o importante é classificar o tipo de falha. Em termos operacionais, vale separar evidências do contexto recuperado da resposta gerada e registrar cada métrica na mesma execução.

undefined

Esse recorte não serve para “bonificar” o modelo; serve para localizar onde a pipeline quebra. É uma abordagem mais alinhada com times que precisam colocar RAG em CI ou em ciclos rápidos de experimentação.

LLM-as-a-judge e fealty ao contexto

Outro ponto do brief é o uso de LLM-as-a-judge. O próprio DeepEval, na métrica de Faithfulness, descreve um fluxo em que o avaliador extrai claims do output e verifica se eles estão suportados pelo contexto recuperado. Isso é relevante porque o problema de ground truth em RAG nem sempre cabe em rótulos binários simples.

Na prática, a métrica observa se a resposta “se apoia” no contexto. Se o sistema inventa detalhes que não aparecem nos documentos recuperados, a falha aparece como falta de fé no contexto, não apenas como “resposta errada”. Essa diferença facilita a priorização do trabalho: primeiro melhorar grounding, depois refinar estilo ou completude.

O Ragas segue a mesma direção em seu framework de avaliação e no artigo RAGAs: Automated Evaluation of Retrieval Augmented Generation. As fontes apontam para um desenho em que a avaliação automatizada não tenta substituir observação humana em tudo, mas cria sinais consistentes para decisões técnicas repetíveis.

Observabilidade, experimentos e tracing

O Phoenix mostra outra camada da mesma história: observability e evaluation andando juntas. Em vez de tratar avaliação como tarefa isolada, o ecossistema propõe tracing, experimentos e medidas de performance como parte do fluxo de engenharia. Isso ajuda quando vários prompts, indexadores e embeddings convivem no mesmo produto.

Esse detalhe importa porque RAG em produção tende a ser um sistema mutável. Mudou o modelo de embedding, alterou o chunking, trocou o reranker, ajustou o prompt e, de repente, a métrica “macro” piora sem que a equipe saiba por quê. Com tracing e experimentos, o time consegue ligar a queda à mudança específica e não apenas registrar a degradação depois do fato.

Por que isso muda o trabalho do time

Na ausência de observabilidade, a avaliação vira um evento pontual. Com observabilidade, ela vira memória técnica do sistema. É isso que frameworks como Phoenix e Ragas ajudam a construir: um histórico consultável de o que mudou, quando mudou e qual componente respondeu mal.

Para times de produto, isso também reduz a tentação de fazer “ajuste no escuro”. Em vez de mover tudo ao mesmo tempo, você cria experimentos pequenos, mede e compara. Em RAG, esse é quase sempre o caminho mais barato.

Por que importa pro dev brasileiro

No Brasil, esse tipo de avaliação pesa ainda mais por dois motivos concretos. Primeiro, muitos times trabalham com orçamento em BRL e precisam controlar custo de chamadas a modelos, embeddings e reprocessamento de índices. Segundo, há pressão de conformidade com a LGPD, o que exige mais cuidado ao manipular contexto, logs e evidências de avaliação quando documentos podem conter dados pessoais ou sensíveis.

Em um cenário brasileiro, isso significa que uma métrica de RAG não é só um número técnico: ela também orienta quanto de contexto pode ser salvo, como registrar traces e o que precisa ser anonimizado antes de virar dado de observabilidade. Para empresas que operam aqui, esse detalhe é prático porque a conta de infraestrutura e as obrigações de privacidade chegam juntas.

Além disso, muitos times no país usam AWS, Azure ou serviços gerenciados com regiões fora do Brasil. Isso torna a disciplina de experimentação ainda mais importante, porque latência, custo de tráfego e tempo de feedback impactam a velocidade de iterar no produto. Avaliar melhor reduz o número de tentativas caras.

Como aplicar isso em um projeto real

Se você está montando um RAG agora, o caminho mais útil é começar simples: defina um conjunto pequeno de perguntas reais, compare o contexto recuperado com a resposta gerada e marque cada falha por categoria. Depois disso, rode experimentos variando top-K, chunk size, prompt e modelo de embeddings, como sugerem os guias do DeepEval e do Ragas.

Se o objetivo é produção, inclua tracing desde o início. O Phoenix é um exemplo de plataforma que ajuda a ligar prompts, avaliações e execução do sistema em uma mesma linha de investigação. Isso vale tanto para aplicações internas quanto para produtos voltados ao usuário final.

Esta abordagem descreve frameworks e práticas que mudam com frequência. APIs, métricas e integrações de avaliação evoluem rápido — confira a documentação oficial antes de padronizar o fluxo em produção.

Conclusão

A principal mudança nos frameworks de avaliação de RAG é sair da métrica única e ir para o diagnóstico por componente. Quando você mede recuperação, geração e fidelidade ao contexto separadamente, descobre mais rápido onde o sistema falha e evita otimizações que só escondem o problema.

Para um time brasileiro, isso também ajuda a equilibrar custo, observabilidade e LGPD, sem transformar avaliação em um processo caro ou improvisado. O próximo passo prático é pegar um conjunto pequeno de perguntas do seu sistema, registrar contexto e resposta em um formato estruturado e comparar os resultados dentro de uma ferramenta de avaliação.

Em até 1 hora, você pode montar uma planilha ou JSON com 10 queries reais do seu produto, salvar o contexto recuperado e classificar manualmente onde o erro acontece: retrieval, generation ou grounding.

Conteúdos da DIO para quem quer aprofundar

• Microsoft AI for Tech - OpenAI Services — Integre serviços da OpenIA em suas soluções criando um sistema AI powered e explore a API do GPT-4 no Azure para construir aplicações de texto e chatbots.
• TQI - Modernização com GenAI — Aprenda boas práticas de arquitetura, microsserviços, cloud e uso de GenAI em cenários de refatoração e modernização de sistemas legados.
• Bradesco - GenAI & Dados — A trilha combina Python, SQL, Power Query e IA generativa para análise e organização de dados, com uma aplicação prática de voz com ChatGPT.
• Aceleração Microsoft AI Agents — Evento prático sobre agentes, GitHub Copilot e Azure IA Foundry para entender automação e construção de sistemas com IA.
• Nexa - Machine Learning e GenAI na Prática — Introduz fundamentos de Machine Learning e IA Generativa com abordagem prática, útil para quem quer começar ou migrar de carreira.

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