Uma resposta bem escrita não prova que o RAG encontrou a fonte certa. O sistema pode recuperar documento irrelevante, ignorar um trecho importante ou inventar uma ligação entre fatos verdadeiros. A avaliação precisa separar busca, contexto entregue ao modelo, resposta e citação.
O conjunto de teste deve nascer das perguntas da operação e conter casos em que a resposta correta é “não há informação suficiente”. Sem recusa, o sistema aprende que sempre deve produzir uma frase, mesmo quando a fonte não sustenta.
Em uma frase
Meça se o sistema recupera a evidência certa, responde somente com base nela e aponta a origem que realmente sustenta cada afirmação.
Uma nota média esconde tipos diferentes de falha
Se o documento correto não foi recuperado, melhorar o prompt de resposta não resolve. Se foi recuperado e ignorado, a falha está na geração ou no contexto. Se a resposta está correta por conhecimento prévio, mas a fonte citada não contém a informação, ela não é auditável.
Medir somente similaridade com uma resposta de referência pune paráfrases úteis e pode aceitar frases parecidas sem fundamento. Por outro lado, usar apenas um modelo como juiz introduz variabilidade. Combine métricas, revisão humana e casos determinísticos.
Groundedness não é sinônimo de correção
O guia de avaliação de RAG da Microsoft Architecture Center recomenda combinar groundedness, completude, utilização, relevância e correção. A fonte observa que uma resposta pode estar baseada no contexto e ainda tirar uma conclusão incorreta.
O mesmo guia recomenda usar faixas, porque respostas de modelos são não determinísticas, e manter parâmetros e resultados ao longo do tempo. Os graders da OpenAI oferecem verificações de string, similaridade e julgamento por modelo, que devem ser escolhidos conforme o tipo de resposta.
Exemplo composto: política com duas condições
A pergunta fictícia é “posso devolver o equipamento após 20 dias?”. A resposta esperada depende de categoria e condição. O RAG recupera o prazo correto, mas omite a exceção. A resposta está grounded no trecho citado, porém incompleta e potencialmente errada para aquele caso.
O conjunto de avaliação marca documentos e trechos esperados, condições obrigatórias, resposta aceitável e casos de recusa. O time revê falhas por categoria: recuperação, autorização, extração, citação, raciocínio ou formulação. O cenário é didático.
Avalie o pipeline em camadas
Na recuperação, meça se trechos relevantes aparecem e em qual posição, com filtros corretos. No contexto, verifique cobertura e ruído. Na geração, avalie groundedness, correção, completude e relevância. Na citação, confirme que o localizador contém a afirmação. Na segurança, teste acesso indevido e instrução maliciosa.
Inclua perguntas curtas, compostas, ambíguas, fora do acervo, com versão antiga e com conflito. Rode novamente após trocar documento, chunking, embedding, ranking, prompt ou modelo. A avaliação é um ativo versionado da operação.
Um conjunto mínimo de avaliação
- Pergunta real, resposta esperada, fonte, versão e trechos relevantes.
- Casos sem resposta, ambíguos, conflitantes e fora da permissão.
- Métricas separadas para recuperação, resposta, citação e latência.
- Revisão humana por especialistas nas falhas de maior consequência.
- Histórico de configuração para comparar regressões após mudanças.
Como a Uiless ajuda
A Uiless preserva versão, hash e localizador dos documentos e pode apresentar citações em página, planilha ou slide. Filtros de empresa e acesso acontecem antes da busca; uma resposta sem fonte suficiente pode ser recusada.
Como conhecimento e execução são separados, a empresa mede RAG sem confundir documento com dado transacional. Quando a pergunta exige ação, a ferramenta correspondente ainda passa por permissão, aprovação e evidência.
Escolha a arquitetura em RAG, busca ou fine-tuning e proteja o acervo em RAG multiempresa.
