RAG 5: avaliar melhorias sem fabricar evidência
Como eu compararia dois sistemas com perguntas reais e evidências revisadas, sem contar trechos relacionados como provas independentes.
Neste artigo
O estudo Taesa ensinou que milhares de trechos não garantem milhares de observações independentes. Na próxima avaliação existe outro risco: substituir chunks por perguntas sintéticas muito parecidas e preservar o mesmo erro estatístico. Antes de calcular um intervalo, preciso definir qual população quero representar e quais unidades geraram essas perguntas.
Construir uma referência que possa ser discutida
Eu começaria com perguntas de usuários e especialistas, registrando tarefa, data de referência, permissões e evidências necessárias. Algumas perguntas admitem várias fontes equivalentes; outras exigem duas ou mais passagens. Incluiria ausência de informação, contradições, versões antigas e consultas fora do acesso do usuário. Uma resposta de referência não deve se reduzir a uma única string quando existem alternativas corretas.
Dois revisores podem examinar uma amostra e resolver divergências, preservando o histórico das decisões. Eu separaria desenvolvimento e teste por famílias ou casos e, quando a aplicação exigir, por tempo. Não afirmaria que essa divisão representa toda a empresa se as perguntas forem de conveniência. A avaliação pode ser útil e ainda ter alcance limitado.
Medir cada etapa e a resposta completa
Na recuperação eu mediria recall das evidências e, se houver relevância graduada, nDCG. Na geração revisaria correção, completude, suporte das afirmações e citações. Uma citação que existe pode não sustentar a frase. Também reportaria respostas indevidas quando falta evidência, recusas desnecessárias, violações de acesso, custo e latência p95. A média não deve esconder uma falha grave em um tipo documental.
EnterpriseRAG-Bench acrescenta conflitos e duplicatas a um corpus empresarial sintético; seus documentos achatados não reproduzem as perdas de um parser de PDF. EnterpriseRAG, outro trabalho de 2026, combina ruído, lacunas e restrições de resposta. São benchmarks diferentes. Ambos ajudam a desenhar casos difíceis, mas nenhum substitui documentos reais nem demonstra que um juiz LLM seja suficiente para nossa avaliação.
EnterpriseRAG-Bench: corpus sintético e limites
EnterpriseRAG: restrições e evidência insuficiente
Comparar diferenças, respeitar grupos
Eu executaria as variantes sobre as mesmas perguntas e calcularia diferenças pareadas. Se foram amostrados casos independentes com várias perguntas dentro, reamostraria casos preservando todas as suas perguntas e ambos os sistemas. Se uma pergunta conecta vários documentos, agrupar por documento pode ser insuficiente: é necessário definir casos, famílias ou um desenho que represente essa dependência. O bootstrap não corrige sozinho uma amostragem enviesada.
# Design pseudocode: independently sampled cases
for b in range(B):
sampled_cases = sample_cases_with_replacement(case_ids)
# Preserve multiplicity; keep questions and systems paired.
delta[b] = metric(B_system, sampled_cases) - metric(A_system, sampled_cases)
# Declare weighting, interval method and degenerate-replicate policy.Eu não usaria percentis automaticamente com poucos grupos: o caso Taesa já mostrou subcobertura. Reportaria tamanho e composição da amostra, intervalo, método e limites de calibração. Antes do teste definiria a melhoria mínima útil e regressões inaceitáveis. Se um reranker ganha pouco e dobra a latência, manter o sistema simples pode ser a decisão correta.
Caso Taesa: unidade de reamostragem e limitações