Como avaliar um RAG: recuperação, fidelidade e fontes citadas
Separe a avaliação da busca da avaliação da resposta e acompanhe poucas métricas simples: recuperação, fidelidade e fontes citadas, sem complicar.
Quer aplicar isso na sua empresa?
Agendar conversa com o Juan →Como avaliar um RAG: recuperação, fidelidade e fontes citadas
Para avaliar um RAG, teste em separado duas etapas: se a busca trouxe os trechos certos e se a resposta usou apenas esses trechos, citando a fonte correta. Comece com um conjunto pequeno de perguntas reais, cada uma com a resposta esperada e o documento que a sustenta. Uma nota única para o sistema inteiro esconde onde está o defeito, e é por isso que a separação importa.
Principais pontos
- Busca e resposta falham por motivos diferentes, então medem-se em separado: recuperação de um lado, fidelidade e citação do outro.
- Um conjunto de perguntas reais, com a resposta esperada e o documento de origem, vale mais do que qualquer métrica sofisticada.
- Três perguntas simples bastam para começar: o trecho certo apareceu, a resposta ficou dentro do trecho, a fonte citada sustenta o que foi dito.
- Perguntas sem resposta nos documentos devem fazer parte do teste, porque o comportamento correto ali é admitir que não sabe.
- A avaliação não termina no lançamento: documentos mudam, e o conjunto de teste precisa ser reexecutado a cada mudança relevante.
Por que avaliar a busca e a resposta separadamente?
Um RAG (geração aumentada por recuperação) funciona em duas etapas. Primeiro, o sistema busca trechos em uma base de conhecimento. Depois, um modelo de linguagem escreve a resposta usando esses trechos como contexto. A documentação da AWS sobre RAG descreve esse desenho: o modelo consulta uma fonte de conhecimento externa antes de gerar a resposta.
O ponto prático é que cada etapa tem seus próprios defeitos. Se a busca não traz o trecho que contém a resposta, nenhum ajuste de instrução vai consertar isso. Se a busca traz o trecho certo e a resposta mesmo assim sai errada, o problema está na geração ou na instrução, e mexer no índice de documentos não ajuda.
Quando a equipe olha só para a resposta final e diz que ela está ruim, não sabe por onde começar. Quando separa as duas avaliações, a conversa muda para algo acionável: a busca está falhando nestas perguntas, ou a resposta está inventando nestas outras.
Como montar o conjunto de perguntas de teste?
O conjunto de teste é o principal ativo da avaliação. Ele não precisa ser grande no início, precisa ser representativo. A melhor fonte são perguntas que clientes ou colegas realmente fizeram: histórico de atendimento, e-mails, mensagens de WhatsApp, dúvidas internas. Antes de usar esse material, remova dados pessoais e confira a base legal conforme a LGPD.
Para cada pergunta, registre quatro coisas: o texto da pergunta, a resposta esperada em linguagem simples, o documento (e a parte dele) que sustenta a resposta, e uma marca indicando se a pergunta deve ser respondida ou recusada.
Um roteiro simples para montar o conjunto:
- Liste os temas em que o assistente será consultado e escolha perguntas de cada tema, não só dos mais fáceis.
- Inclua perguntas escritas do jeito que as pessoas escrevem, com abreviações, erros e frases incompletas.
- Inclua perguntas cuja resposta depende de mais de um documento.
- Inclua perguntas cuja resposta não existe na base, para testar se o sistema admite isso.
- Inclua perguntas sobre informação que mudou, em que um documento antigo e um novo se contradizem.
- Peça a quem conhece o assunto que valide a resposta esperada, e não o contrário.
Essa última regra evita um erro comum: usar o próprio modelo para gerar as respostas esperadas e depois medir o sistema contra elas. O gabarito precisa vir de uma pessoa responsável pelo conteúdo.
Como medir a recuperação?
A pergunta da recuperação é objetiva: para esta pergunta, o trecho que contém a resposta apareceu entre os trechos que a busca entregou ao modelo? Você não precisa olhar a resposta final para isso. Basta executar só a etapa de busca e comparar o resultado com o documento de origem anotado no conjunto de teste.
Três medidas simples cobrem a maior parte do que uma equipe precisa:
- Acerto da recuperação: em quantas perguntas o trecho correto estava entre os devolvidos.
- Posição do trecho certo: ele veio entre os primeiros ou ficou escondido no fim da lista.
- Ruído: quantos trechos irrelevantes acompanharam o correto e ocuparam espaço no contexto.
O ruído importa porque o contexto do modelo é limitado e trechos inúteis podem distrair a resposta. Se esse assunto é novo para a equipe, vale ler sobre a janela de contexto em IA e entender por que mandar mais texto nem sempre melhora o resultado.
Quando o acerto da recuperação é baixo, as causas costumam ser de dados, não de modelo: documentos longos cortados no lugar errado, PDFs com texto mal extraído, nomes internos que a busca não associa ao termo usado pelo cliente, ou versões antigas de um mesmo documento competindo entre si. Em documentos escaneados, a extração merece cuidado próprio, como discutimos em extrair dados de PDF com IA.
Como medir a fidelidade da resposta?
Fidelidade é a pergunta: tudo o que a resposta afirma está sustentado pelos trechos que o sistema recebeu? Uma resposta pode estar correta no mundo e ainda assim infiel, porque o modelo completou com conhecimento próprio algo que a base não diz. Em um assistente corporativo isso é um problema, pois a empresa responde pelo que a base oficial afirma, não pelo que o modelo supõe.
Para avaliar, pegue a resposta e os trechos entregues e verifique afirmação por afirmação. Um método manual funciona bem no começo:
- Separe a resposta em afirmações curtas (um prazo, uma condição, um passo).
- Marque cada afirmação como sustentada, não sustentada ou contraditória em relação aos trechos.
- Classifique a resposta inteira: fiel, parcialmente fiel ou infiel.
- Anote o tipo de falha: invenção, exagero, mistura de duas regras, ou informação de documento desatualizado.
Depois que a equipe entender o padrão, é possível usar um modelo como avaliador para triar volume maior, desde que uma amostra continue sendo revisada por gente. A documentação de evals da OpenAI e o artigo da Anthropic sobre evals para agentes de IA tratam de como estruturar esses testes e por que critérios claros e exemplos revisados importam. Como hipótese de trabalho, e não como fato documentado, recomendamos tratar o avaliador automático como um colega júnior: útil para organizar a fila, não para dar a palavra final.
Não esqueça das perguntas sem resposta na base. Nelas, a resposta fiel é dizer que a informação não foi encontrada e, quando fizer sentido, encaminhar para uma pessoa. Se o sistema responde com confiança algo que não está nos documentos, conte isso como falha de fidelidade, mesmo que a resposta soe plausível.
Como avaliar as fontes citadas?
Citar fonte só ajuda se a citação for verdadeira. Há três verificações distintas, e a equipe costuma fazer só a primeira:
- A fonte citada existe de fato na base (não é um nome inventado).
- A fonte citada contém a informação que a resposta atribui a ela.
- A fonte citada é a versão vigente do documento.
A segunda verificação é a que mais pega problemas. Um sistema pode citar um documento real da base e ainda assim colocar nele uma afirmação que ele não faz. Para o usuário, a citação passa uma falsa sensação de checagem. Por isso, a medida útil é a precisão da citação: das fontes citadas, quantas realmente sustentam a frase em que aparecem.
Uma medida complementar é a cobertura: das afirmações importantes da resposta, quantas trazem fonte. Em respostas sobre prazos, garantias, condições ou valores contratuais, afirmação sem fonte deve ser tratada como pendência.
Se o assistente atende clientes por WhatsApp, pense também no formato: a citação precisa caber numa mensagem curta e ser compreensível para quem recebe, por exemplo o nome do documento e da seção, ou um link para a página oficial. Para quem decide o desenho do fluxo, como integrar IA no WhatsApp da empresa detalha o canal.
Cenário ilustrativo: lendo os resultados juntos
Imagine, como cenário ilustrativo, uma empresa de serviços que montou um assistente interno para consultar políticas de garantia e prazos de atendimento. A equipe roda o conjunto de teste e separa os resultados em quatro grupos.
- Trecho certo recuperado e resposta fiel com citação correta: funcionando, nada a fazer.
- Trecho certo recuperado, mas resposta infiel: o problema está na instrução ou no modelo. Ajustar o texto de instrução para responder só com base nos trechos e testar de novo.
- Trecho certo não recuperado: o problema está na busca ou nos documentos. Revisar a divisão em trechos, os títulos e os sinônimos usados pelos clientes.
- Resposta fiel, mas citação apontando para o documento errado: o problema está na etapa que associa afirmação e fonte. Revisar como os metadados dos documentos chegam ao modelo.
O valor está em que cada grupo leva a uma ação diferente e a um responsável diferente. Quem cuida dos documentos corrige o terceiro grupo, quem cuida da instrução corrige o segundo. Sem a separação, todo mundo discute a resposta final e ninguém muda nada de forma verificável.
Como acompanhar no dia a dia e onde entra o método?
Depois do lançamento, a avaliação vira rotina leve. Reexecute o conjunto de teste sempre que houver mudança em documentos, instruções, modelo ou configuração da busca. Compare com a rodada anterior e registre o que melhorou e o que piorou. Uma piora em perguntas antes acertadas é o sinal mais valioso do processo.
Em produção, registre para cada interação a pergunta, os trechos recuperados, a resposta e as fontes citadas. Esse registro permite revisar amostras reais e alimentar o conjunto de teste com casos novos. Os conceitos de observabilidade da OpenTelemetry ajudam a pensar nesses registros como rastros que explicam o comportamento do sistema. Tenha atenção ao conteúdo registrado: logs de conversa podem conter dados pessoais e precisam de prazo de guarda e controle de acesso. E, como a base de documentos é entrada de texto para o modelo, vale conhecer os riscos descritos em prompt injection em agentes de IA.
O nosso método segue quatro passos que se encaixam bem aqui. Mapear: levantar as perguntas reais, os documentos que respondem a elas e o processo atual como linha de base. Limitar: definir quais documentos o assistente pode consultar e o que ele nunca responde sozinho. Pilotar: rodar um fluxo real com registros e uma métrica de sucesso combinada de antemão. Transferir: entregar o conjunto de teste e a rotina de revisão para a equipe, que decide se expande, ajusta ou para.
Para a equipe de operação, vale começar com um painel pequeno, com poucos indicadores revisados em intervalos regulares:
- Acerto da recuperação no conjunto de teste.
- Proporção de respostas fiéis na amostra revisada.
- Precisão das citações na mesma amostra.
- Casos sem resposta tratados corretamente (recusa ou encaminhamento).
- Pedidos de correção vindos de usuários ou de atendentes humanos.
Se o assistente atende clientes, conecte esses indicadores aos de atendimento, como discutimos em indicadores de atendimento com IA. A qualidade do RAG explica parte do que aparece ali, mas não toda: tom, canal e transferência para humano também pesam.
Perguntas frequentes
Quantas perguntas preciso para começar a avaliar um RAG? Comece com um conjunto pequeno, mas que cubra os principais temas, as formas reais de perguntar e os casos sem resposta na base. É melhor um conjunto modesto e bem revisado por quem conhece o conteúdo do que um grande e gerado sem checagem. Ele cresce com os erros encontrados em produção.
Posso usar um modelo de IA para avaliar as respostas do meu RAG? Pode, principalmente para triar volume e apontar candidatos a erro. Como hipótese de trabalho, trate o resultado como apoio: mantenha uma amostra revisada por uma pessoa e compare as duas avaliações de tempos em tempos. Se divergirem muito, ajuste os critérios antes de confiar na triagem automática.
O que fazer quando a resposta está certa, mas a fonte citada está errada? Trate como falha de citação, não como acerto. A causa costuma estar em como os metadados dos documentos chegam ao modelo ou em trechos duplicados de versões diferentes. Corrija a origem, reexecute o conjunto de teste e confirme que as respostas antes corretas continuam corretas.
Preciso avaliar de novo depois que o RAG entrou em produção? Sim, porque documentos, políticas e modelos mudam, e uma melhoria em um ponto pode piorar outro. Reexecute o conjunto de teste a cada mudança relevante e revise uma amostra de conversas reais, respeitando a LGPD no tratamento desses registros. Se a avaliação mostrar que o sistema não atinge a métrica combinada, parar ou reduzir o escopo também é uma decisão válida.