Avaliar as respostas de um sistema RAG

Você alterou a divisão em chunks, trocou o modelo de embeddings e adicionou um reranker. O sistema parece melhor. Um usuário relata uma regressão em uma pergunta que funcionava na semana passada. Você não consegue confirmar nem descartar, porque seu único método de validação consiste em digitar quatro perguntas que você sabe de cor e achar as respostas satisfatórias. Você não sabe qual das três alterações ajudou, qual prejudicou, nem se a média melhorou.

Essa é a situação padrão de quase todos os projetos RAG, e é o que os faz estagnar. Um sistema RAG tem dois estágios que falham por razões diferentes e se corrigem por meios diferentes: a recuperação e a geração. Uma métrica global única mistura os dois, então nunca diz o que corrigir. A disciplina mínima consiste em medir os dois separadamente, sobre um conjunto de perguntas fixo, antes de cada mudança.

Construir o conjunto de referência

Mire em 50 a 150 perguntas. Abaixo de 40, o ruído estatístico supera as diferenças que você procura medir. Acima de 200, o custo de anotação se torna proibitivo sem ganho proporcional.