Avaliação de RAG: como testar o sistema completo

Uma resposta ruim pode nascer em quatro lugares diferentes

Um agente responde com segurança, cita um manual verdadeiro e entrega uma orientação incompleta. A equipe troca o modelo de linguagem. O erro continua.

Ao reconstruir a execução, descobre que a busca encontrou o procedimento correto, mas a seleção final retirou a página que continha a exceção. O gerador nunca recebeu a condição necessária.

Avaliar RAG exige separar as etapas que transformam uma pergunta em resposta: recuperação inicial, seleção de contexto, geração e ligação com as fontes. Medir apenas o texto final mostra que houve um problema, mas raramente indica onde corrigir.

O objetivo da avaliação é apoiar uma decisão de produção. A empresa precisa saber qual configuração funciona para quais perguntas, onde estão os erros impeditivos e se a melhora reduz revisão sem criar risco de acesso, versão ou confiança indevida.

O que precisa ser avaliado num sistema RAG

RAG combina recuperação de conteúdo e geração de resposta. Cada camada possui entradas, saídas e falhas próprias.

Recuperação inicial

A busca deve localizar os documentos e trechos necessários dentro do universo autorizado. Falhas podem nascer na extração, divisão dos documentos, modelo de embeddings, índice textual, filtros, reformulação da consulta ou quantidade de candidatos.

Seleção do contexto

Nem todo candidato recuperado chega ao modelo. Fusão, deduplicação, reranking, limites de tokens e regras de montagem escolhem o pacote final. Uma evidência encontrada pode ser descartada, truncada ou separada de sua ressalva.

Geração

O modelo precisa usar o contexto, preservar condições, distinguir ausência de evidência e responder no formato exigido. Ele pode ignorar uma fonte correta, combinar regras incompatíveis ou preencher uma lacuna.

Citações

Referências precisam apontar para trechos reais e sustentar as afirmações materiais. A página sobre citações verificáveis em RAG detalha existência, suporte, aplicabilidade, versão e acesso.

Resultado operacional

Uma resposta tecnicamente correta ainda pode chegar tarde, exigir revisão extensa ou produzir uma próxima ação inválida. A avaliação deve alcançar o trabalho que a resposta prepara, dentro do escopo autorizado para o agente.

Defina a pergunta de decisão antes das métricas

"Melhorar o RAG" é amplo demais para orientar um teste. Escolha uma decisão concreta:

trocar busca vetorial por busca híbrida;
adotar um novo modelo de embeddings;
mudar o tamanho dos trechos;
incluir reranking;
reduzir a quantidade de contexto;
atualizar o modelo gerador;
liberar uma nova coleção documental;
diminuir revisão humana numa classe de perguntas.

Cada experimento deve alterar uma hipótese principal. Trocar embeddings, chunking, prompt e gerador na mesma rodada pode elevar a nota e apagar a causa do ganho.

Registre a configuração completa da linha de base e da candidata. Inclua fontes, versões, índice, filtros, representação da consulta, recuperação, fusão, reranking, limite de contexto, instruções, modelo, parâmetros e política de recusa.

Monte um dataset centrado em evidência

A unidade de teste precisa ligar pergunta, escopo permitido, evidência esperada e resposta aceitável.

Um registro pode conter:

pergunta: consulta apresentada pelo usuário
identidade: perfil e escopo de acesso
fontes_disponiveis: versão congelada da coleção
evidencias_obrigatorias: trechos ou fatos necessários
evidencias_proibidas: conteúdo fora do cliente, vigência ou finalidade
resposta_aceitavel: critérios que precisam ser atendidos
condicao_de_recusa: quando a base não permite concluir
erros_impeditivos: falhas que bloqueiam a configuração
classe: comum, exceção, conflito, sem resposta ou segurança

Use perguntas reais anonimizadas para preservar linguagem e ambiguidades do trabalho. Complete as lacunas com casos dirigidos. Uma amostra formada apenas por dúvidas frequentes tende a excluir documentos revogados, conflitos, códigos raros e tentativas de acesso indevido.

O guia sobre dataset de avaliação para agentes explica separação entre desenvolvimento, validação e teste reservado. Para RAG, o rótulo também precisa marcar quais passagens sustentam a resposta. Uma referência textual única pode ser insuficiente quando a conclusão depende de regra, exceção e definição.

Separe métricas de recuperação e de resposta

A AWS documenta dois tipos de avaliação para RAG no Amazon Bedrock: uma voltada somente à recuperação e outra que inclui recuperação e geração. A lista oficial de métricas distingue relevância e cobertura do contexto de critérios como correção, completude, fidelidade e cobertura de citações.

Essa separação ajuda no diagnóstico, mesmo que a empresa use outra plataforma ou implemente seus próprios testes.

Métricas de recuperação

Observe se a evidência esperada aparece entre os candidatos e em qual posição. Dependendo do rótulo disponível, use:

presença de todas as passagens obrigatórias no conjunto recuperado;
cobertura de perguntas com evidência suficiente;
precisão entre os primeiros resultados;
posição do primeiro trecho relevante;
qualidade da ordenação quando existem graus de relevância;
recuperação de versão correta;
ausência de conteúdo inelegível;
taxa de resultado vazio quando deveria haver fonte.

Recall@k mede quantas evidências relevantes apareceram até a posição k. Precision@k mede quanto do conjunto até k era relevante. MRR observa a posição do primeiro resultado relevante. NDCG ajuda quando os candidatos possuem graus de relevância diferentes.

Nenhuma dessas métricas resolve sozinha perguntas que exigem várias passagens. Se uma política depende de regra e exceção, encontrar apenas uma delas deve ser classificado como contexto incompleto.

Métricas de seleção de contexto

Compare candidatos recuperados com o pacote entregue ao gerador:

evidências obrigatórias preservadas;
trechos úteis retirados por limite;
duplicação que consumiu contexto;
dependências separadas;
conteúdo truncado;
documento indevido promovido pelo reranker;
ordem final das passagens.

Essa etapa isola problemas de fusão, reranking, deduplicação e orçamento de tokens.

Métricas de resposta

Avalie a resposta contra os fatos e condições esperados:

correção factual;
completude das condições necessárias;
aderência ao contexto recebido;
reconhecimento de falta de evidência;
preservação de negações e exceções;
clareza para a tarefa;
formato válido;
ação ou encaminhamento compatível com a política.

Não use semelhança de redação como critério principal quando várias respostas são válidas. Separe conteúdo obrigatório, conteúdo proibido e elementos que podem variar.

Métricas de citação

Meça cobertura das afirmações que exigem fonte, suporte real da passagem citada e capacidade de abrir a localização correta. Verifique também versão, vigência e autorização do destinatário.

Uma resposta pode citar todas as frases e continuar errada se os trechos não sustentarem as conclusões. Cobertura sem suporte produz uma interface convincente com pouca segurança.

Use regras, julgamento semântico e revisão humana

Parte da avaliação aceita verificação determinística:

identificador do documento;
versão e data;
permissão;
presença de passagem obrigatória;
campo ou schema da resposta;
cálculo;
link de citação;
ausência de conteúdo de outro cliente.

Qualidade da síntese, suficiência de uma justificativa e suporte semântico podem exigir rubrica e especialista. Um LLM avaliador ajuda a escalar essa leitura, mas precisa ser calibrado contra casos revisados por pessoas.

A página sobre LLM como juiz cobre ordem, estabilidade, viés e concordância. No RAG, peça ao avaliador que cite a evidência usada no julgamento e devolva dimensões separadas. Uma nota geral reduz a capacidade de investigar.

Decisões sensíveis devem manter revisão por alguém que conheça a regra e possua autoridade. O avaliador automatizado pode priorizar casos e encontrar padrões. Ele não cria a política que define qual cláusula, procedimento ou registro governa o trabalho.

Inclua casos sem resposta e conflitos

Um índice sempre consegue devolver itens próximos. O sistema precisa demonstrar que sabe interromper a conclusão quando falta base suficiente.

Teste perguntas em que:

o assunto não existe na coleção;
o documento existe, mas está fora da vigência;
duas fontes autorizadas divergem;
falta uma condição necessária;
o usuário pede um dado de outro cliente;
o código informado não existe;
a resposta exige um sistema estruturado que o RAG não consulta;
a única fonte está revogada;
há instrução maliciosa dentro do documento.

A resposta correta pode ser pedir um dado, declarar a limitação ou encaminhar o caso. Premiar qualquer recusa também cria um atalho ruim. O sistema precisa recusar quando a evidência não autoriza a conclusão e responder quando ela existe.

Trate segurança como gate, não como média

Uma configuração pode melhorar relevância em muitas perguntas e recuperar um documento de outro cliente em um caso. A média sobe enquanto a arquitetura se torna imprópria para produção.

Defina erros impeditivos antes do experimento:

vazamento entre clientes ou unidades;
uso de fonte proibida;
versão revogada tratada como vigente;
condição material inventada;
cálculo ou compromisso sem base;
citação que expõe conteúdo sem autorização;
ausência de recusa diante de instrução maliciosa;
ação recomendada fora da alçada.

Os filtros de metadados em RAG precisam ser testados com identidades de baixo privilégio. Conta administrativa costuma mascarar falhas de isolamento.

Abra os resultados por classe. Perguntas comuns, exceções, conflitos, ausência de resposta e segurança possuem funções diferentes. Uma única taxa de acerto impede que a equipe saiba qual alcance a evidência sustenta.

Compare versões de forma reproduzível

Congele o dataset e as fontes durante o experimento. Rode a linha de base e a candidata sobre as mesmas unidades. Quando uma dependência externa não puder ser congelada, registre seu estado e separe as variações causadas por ela.

Um ciclo útil segue esta ordem:

executar a linha de base;
localizar falhas por etapa;
escolher uma hipótese de correção;
alterar um componente principal;
executar a candidata;
comparar por classe e erro;
revisar amostra e divergências;
decidir por gate;
guardar falhas corrigidas na regressão;
observar produção em alcance limitado.

Repita perguntas quando estabilidade importar. Uma única execução pode esconder variação do gerador ou do avaliador. Preserve o mesmo número de repetições entre candidatas e reporte a distribuição, não somente o melhor resultado.

Ligue avaliação offline ao resultado em produção

O teste offline prova comportamento num conjunto conhecido. A operação recebe documentos novos, perguntas diferentes e permissões alteradas.

Acompanhe em produção:

perguntas sem evidência suficiente;
respostas encaminhadas para revisão;
correções por causa identificada;
tempo de conferência;
citações abertas pelo usuário;
uso de versões vencidas;
consultas bloqueadas por acesso;
latência e custo por classe;
reclamações ligadas a respostas;
resultado confirmado no processo.

Não transforme clique na citação em prova de correção. Ele indica uso da interface. A validação precisa ligar a resposta ao desfecho que a operação reconhece, como resolução de chamado, decisão contratual confirmada ou redução de retrabalho de pesquisa.

Casos novos de falha devem entrar na regressão com fonte, classe e regra aplicável. Evite alimentar automaticamente o conjunto com toda conversa. Isso acumula dados sem critério e pode misturar informação pessoal ou confidencial fora da finalidade.

Checklist para avaliar um sistema RAG

[ ] A decisão do experimento está definida?
[ ] Linha de base e candidata possuem configuração versionada?
[ ] O dataset liga pergunta, acesso, evidência e resposta aceitável?
[ ] Casos comuns, exceções, conflitos e ausência de resposta estão cobertos?
[ ] Recuperação, seleção, geração e citação são medidas separadamente?
[ ] Passagens obrigatórias e proibidas possuem rótulo?
[ ] Métricas de ranking usam o mesmo valor de k entre versões?
[ ] Regras determinísticas validam identidade, versão e permissão?
[ ] Avaliadores semânticos foram comparados com revisão humana?
[ ] Erros de segurança e compromisso bloqueiam a candidata?
[ ] O teste reservado ficou fora dos ajustes?
[ ] Repetições e variação são registradas?
[ ] Falhas corrigidas entram na suíte de regressão?
[ ] Produção liga qualidade ao esforço e ao desfecho operacional?
[ ] Existe um responsável por aprovar, restringir ou rejeitar a versão?

A avaliação deve mostrar onde agir

Um placar único informa que a configuração mudou. Ele não explica se a empresa precisa corrigir documentos, metadados, busca, seleção de contexto, instruções ou modelo.

Uma avaliação útil preserva a trajetória da evidência. A equipe consegue verificar o que estava disponível, o que foi recuperado, o que chegou ao gerador, o que sustentou a resposta e qual efeito apareceu no processo.

Comece com uma responsabilidade delimitada e um conjunto pequeno de perguntas representativas. Separe as etapas, declare erros impeditivos e compare uma mudança por vez. Essa disciplina reduz compras por demonstração e transforma o RAG em capacidade operacional mensurável.