Resposta certa não basta: como avaliar a qualidade de um sistema RAG

Em 17 de outubro de 2026, a mesma publicação apareceu em comunidades como r/Rag, r/LangChain, r/mlops, r/AI_Agents e r/learnAIAgents, com a pergunta: qual é a parte mais difícil de verificar se uma mudança no RAG realmente ajudou? O autor, que diz trabalhar com avaliações independentes de recuperação, relata uma checagem pequena que revelou algo útil: a aplicação respondeu corretamente, mas as citações e os logs disponíveis não eram suficientes para verificar quais trechos sustentavam as afirmações.

Segundo o autor, essa distinção importa na hora de decidir se uma alteração na recuperação melhorou o sistema ou se uma resposta correta está escondendo uma lacuna de evidência. É exatamente o tipo de problema que uma empresa só descobre tarde, quando o assistente erra em uma decisão importante.

Por que acertar a resposta não é suficiente

RAG (geração aumentada por recuperação) combina uma busca nos documentos da empresa com um modelo que redige a resposta. Se você avalia apenas o texto final, mistura duas perguntas diferentes:

• A busca trouxe os trechos certos? Se não trouxe, o acerto pode ter vindo do conhecimento geral do modelo, ou da sorte;
• A resposta se apoia nesses trechos? Sem essa ligação, ninguém consegue conferir a afirmação nem corrigir a fonte quando houver erro.

Uma resposta certa sem evidência rastreável é frágil: ao mudar o índice, o modelo ou a forma de dividir os documentos, ela pode piorar sem que ninguém perceba.

O que o assistente precisa deixar registrado

Para que a equipe consiga auditar qualquer resposta, estruture o registro (log) de cada consulta:

• Pergunta original e, se houver, a pergunta reescrita pelo sistema;
• Trechos recuperados, com identificador do documento, versão e posição no documento;
• Ordem e pontuação da recuperação, para entender por que um trecho foi escolhido;
• Resposta gerada e a lista de citações, com cada afirmação ligada ao trecho que a sustenta;
• Versão da configuração: modelo, prompt, índice e parâmetros de busca vigentes naquele momento;
• Feedback humano, quando o usuário marcar a resposta como útil ou incorreta.

Cuide da privacidade: se as perguntas ou os documentos contêm dados pessoais ou sigilosos, defina quem pode ler os logs e por quanto tempo eles são guardados.

Como estruturar citações que dá para verificar

Uma citação útil não é só o nome do arquivo. Ela deve permitir que uma pessoa abra a fonte e confirme a afirmação em poucos segundos. Prefira citações no nível do trecho (documento, seção ou página), mostradas ao usuário junto da resposta. Quando o sistema não encontrar evidência suficiente, o comportamento desejado é dizer isso, em vez de responder com segurança sem base.

Passo a passo para testar uma mudança antes de produção

1. Monte um conjunto fixo de perguntas. Reúna perguntas reais do negócio, incluindo as difíceis e as que não têm resposta nos documentos.
2. Defina a evidência esperada. Para cada pergunta, anote quais documentos ou trechos deveriam sustentar a resposta.
3. Meça a recuperação separadamente. Verifique se os trechos esperados apareceram entre os recuperados, antes de olhar a resposta.
4. Verifique a sustentação. Confira se cada afirmação da resposta está de fato apoiada nos trechos citados.
5. Compare antes e depois. Rode o mesmo conjunto na versão atual e na alterada e examine as perguntas que mudaram de resultado, tanto as que melhoraram quanto as que pioraram.
6. Revise casos de acerto sem evidência. São os que mais indicam lacunas escondidas.
7. Libere aos poucos. Se possível, ative a mudança para um grupo pequeno e acompanhe os logs antes de ampliar.
8. Atualize o conjunto de testes. Cada erro encontrado em produção vira uma nova pergunta de teste.

O que a empresa deve fazer agora

• Se já tem um assistente com RAG, pegue dez respostas recentes e tente descobrir, só pelos logs, quais trechos as sustentaram. Se não for possível, falta rastreabilidade;
• Exija citações verificáveis em qualquer assistente que apoie decisões de atendimento, jurídico, financeiro ou operação;
• Trate toda mudança de índice, modelo ou prompt como uma alteração a testar, não como um ajuste informal;
• Defina um responsável pela qualidade da base de documentos, já que respostas ruins muitas vezes vêm de fontes desatualizadas ou duplicadas.

Vale lembrar que a fonte é uma discussão de comunidade, baseada em uma checagem pequena e relatada pelo próprio autor, sem números publicados. Use-a como um alerta de boas práticas, não como medição de desempenho de qualquer ferramenta.

Para aprofundar, veja como criar memória para agentes de IA, o exemplo de segundo cérebro da empresa sobre organização do conhecimento e o roteiro de como implementar agentes de IA com segurança. Se o seu objetivo é começar, leia também como implementar IA na empresa.

Conclusão

Avaliar a qualidade de um sistema RAG significa olhar além da resposta final: é preciso saber quais trechos a sustentaram. Com logs completos, citações verificáveis e um conjunto fixo de testes comparado antes e depois de cada mudança, a empresa corrige erros na origem e protege decisões importantes. Se quiser apoio para montar um assistente de IA auditável, conheça nosso serviço de agentes de IA ou fale com a Yggra.

Fontes

• r/Rag, What’s the hardest part of checking whether a RAG change actually helped?.
• r/LangChain, What’s the hardest part of checking whether a RAG change actually helped?.
• r/mlops, What’s the hardest part of checking whether a RAG change actually helped?.
• r/AI_Agents, What’s the hardest part of checking whether a RAG change actually helped?.
• r/learnAIAgents, What’s the hardest part of checking whether a RAG change actually helped?.

Perguntas frequentes