Como o teste foi configurado

O autor construiu um pequeno sistema de geração aumentada por recuperação (RAG) baseado em dois documentos de manuais de regras de pagamento e realizou duas verificações:

  • Teste de recall – a página correta apareceu entre os cinco primeiros resultados? Resultado: 60%.
  • Teste de resposta – a resposta final produzida pelo gerador estava correta? Resultado: 90%.

Uma lacuna de 40% parecia impossível. Se o recuperador (retriever) errou a página correta quatro em cada dez vezes, como o modelo ainda poderia responder corretamente nove em cada dez vezes?

Primeiras tentativas de “corrigir” o recuperador

O desenvolvedor tentou dois truques comuns:

  • Busca híbrida – misturando sinais lexicais e vetoriais. O recall permaneceu o mesmo.
  • Reranker – reordenando as cinco páginas recuperadas. O recall subiu para 70%, mas ainda ficou muito atrás da precisão de resposta de 90%.

Ambas as ferramentas apenas reorganizam o que já foi recuperado; elas não podem conjurar uma página que nunca entrou no conjunto de candidatos. O problema estava em outro lugar.

A métrica, não o modelo, estava quebrada

Em vez de julgar o sucesso pelo rótulo da página, o autor inspecionou os fatos reais nos trechos (chunks) recuperados. Em três de quatro “falhas”, o fato correto estava presente, mas estava em uma página diferente da esperada pelo script de teste. A avaliação penalizou o recuperador por encontrar uma resposta correta em uma página inesperada.

Quando a métrica mudou para “algum trecho recuperado contém o fato necessário?”, o recall saltou para 90%, igualando a precisão da resposta. O recuperador funcionou; a estrutura de avaliação não.

Por que o recall tradicional pode ser enganoso

  • A rotulagem ao nível de página cria falhas fantasmas. Um único fato pode aparecer em várias páginas. Marcar apenas uma página como ground truth trata todos os outros acertos corretos como erros.
  • Corpora pequenos amplificam o efeito. Com poucos documentos, uma única página rotulada incorretamente pode alterar o recall drasticamente, enquanto a precisão da resposta permanece estável.
  • O ruído de embedding esconde fatos. Vetores pontuam páginas inteiras; o texto jurídico ou técnico ao redor dilui o sinal de relevância da frase alvo, empurrando a página para baixo no ranking, mesmo que o fato esteja presente.

Lições práticas para profissionais de RAG

  • Separe o ranking das falhas de recuperação. Rerankers corrigem apenas o primeiro; se o trecho correto nunca entrar no conjunto de candidatos, a reordenação não ajuda em nada.
  • Rotule os dados de teste ao nível do fato. Vincule cada consulta à informação específica de que ela precisa, não a um único identificador de documento.
  • Não confie em benchmarks de larga escala para conjuntos de dados minúsculos. Corpora pequenos e específicos de um domínio comportam-se de forma diferente, e pontuações de recall genéricas podem ser enganosas.
  • Fique atento à granularidade do embedding. Um trecho do tamanho de uma página contém muitas palavras, e o texto jurídico ao redor pode diminuir o ranking do fato que você procura.

Resumo: uma pontuação alta de precisão de resposta pode coexistir com um valor de recall tradicional baixo quando a avaliação não está alinhada com a tarefa. Corrigir a métrica, e não o modelo, economiza tempo, reduz alarmes falsos e gera implementações de RAG mais confiáveis.