Neste artigo
- O que é avaliação de RAG e por que ela não é opcional
- Os dois pontos onde o RAG quebra e como distinguir
- As métricas de avaliação de RAG que realmente importam
- LLM como juiz: o que funciona e onde está o risco
- Como montar um ciclo de avaliação sem dataset rotulado
- Avaliação offline vs. monitoramento em produção
- O impacto de não avaliar o RAG em produção
- Dúvidas comuns sobre avaliação de RAG
- Próximo passo: defina sua métrica antes da próxima mudança
Você colocou o RAG em produção. O demo foi convincente, os colegas aprovaram, o primeiro feedback foi positivo. Três semanas depois, um usuário envia uma screenshot de uma resposta claramente errada e pergunta se o sistema foi atualizado. Você não sabe o que mudou. Pior: não sabe se alguma coisa mudou.
Esse é o padrão mais comum em implementações de avaliação de RAG que acompanhei. Não que o sistema não funcione. É que ninguém definiu como saber quando ele para de funcionar.
Não é culpa de ninguém ter chegado aqui. A maioria dos tutoriais de RAG termina quando o modelo retorna a primeira resposta coerente. Avaliação fica de fora, e essa lacuna custa caro em produção.
Trabalhei num projeto numa fintech onde o RAG respondia perguntas sobre contratos. Funcionava nos testes. Em produção, descobrimos que em cerca de 30% das perguntas o modelo estava ancorado no contexto errado, às vezes de um contrato completamente diferente. Levamos semanas para perceber porque não havia nenhuma métrica rastreando isso.
O que vou te mostrar são as métricas que importam para avaliação de RAG, como aplicá-las sem precisar de um dataset rotulado do zero e como distinguir se o problema está na recuperação ou na geração, porque esses são dois bugs completamente diferentes que pedem correções completamente diferentes.
O que é avaliação de RAG e por que ela não é opcional
RAG tem duas etapas distintas: recuperação (buscar os trechos relevantes nos seus dados) e geração (o modelo criar a resposta com base nesses trechos). Avaliar avaliação de RAG significa medir se as duas estão funcionando, de forma separada e em conjunto.
A avaliação não é opcional porque as duas etapas falham de formas independentes. O retriever pode retornar contexto irrelevante e o modelo vai gerar uma resposta coerente baseada em informação errada. O retriever pode funcionar bem e o modelo ignorar o contexto recuperado, inventando detalhes que não existem nos documentos. Sem métrica para cada etapa, você não sabe o que consertar.
Os dois pontos onde o RAG quebra e como distinguir
Quando o problema está na recuperação
O retriever falha quando os chunks retornados não contêm a informação necessária para responder à pergunta. Isso acontece por chunking mal planejado, embeddings inadequados para o domínio ou porque a pergunta usa vocabulário diferente do documento.
O sinal aqui é a relevância do contexto: os trechos recuperados tinham alguma relação com a pergunta? Se não tinham, o modelo vai gerar com o que tem, e o que tem não serve.
Quando o problema está na geração
O modelo falha mesmo quando recebe contexto relevante. Isso acontece quando ele ignora o contexto e usa seu conhecimento interno para responder, quando alucina detalhes periféricos que não estavam nos trechos ou quando combina informações de múltiplos trechos de forma incorreta.
O sinal aqui é faithfulness: a resposta está ancorada no contexto fornecido ou o modelo saiu dos trilhos? São dois diagnósticos completamente diferentes, e confundir um com o outro é o erro mais caro que você pode cometer numa iteração de melhoria.
As métricas de avaliação de RAG que realmente importam
Faithfulness: o modelo inventou alguma coisa?
Faithfulness mede se cada afirmação na resposta pode ser rastreada a algum trecho do contexto recuperado. É a métrica mais crítica porque captura alucinação contextual, diferente de alucinação genérica. O modelo não inventou algo do nada, ele pegou informação do contexto e distorceu ou expandiu além do que estava escrito.
Uma resposta com faithfulness baixo é perigosa porque parece certa para quem não conhece os documentos de origem.
Relevância da resposta
Mede se a resposta realmente endereça a pergunta feita. Parece óbvio, mas RAG falha aqui com frequência quando o contexto recuperado é tangencialmente relacionado. O modelo escreve algo plausível e conectado ao contexto, mas não responde o que o usuário perguntou de fato.
Relevância do contexto recuperado
Mede se os trechos que o retriever buscou têm relação com a pergunta. É a métrica que isola o problema de recuperação do problema de geração. Se essa métrica estiver baixa, você tem um problema de retriever. Se estiver alta mas a resposta estiver ruim, você tem um problema de modelo ou de prompt.
LLM como juiz: o que funciona e onde está o risco
Uma abordagem prática para avaliação de RAG sem dataset rotulado é usar um modelo forte para avaliar as saídas do seu pipeline. Você instrui o modelo a analisar se a resposta está baseada no contexto, se ela endereça a pergunta e se o contexto recuperado era relevante para o que foi perguntado.
Funciona melhor do que parece, especialmente para faithfulness. Na minha experiência, modelos fortes identificam contradições entre resposta e contexto com boa precisão quando o prompt de avaliação está bem estruturado.
O risco real é viés de auto-confirmação: o mesmo modelo que gerou a resposta vai ter dificuldade de criticá-la. Usar modelos diferentes para geração e avaliação reduz esse problema. Outro risco é confiar no número sem calibrar: compare as avaliações automáticas com avaliações humanas em uma amostra pequena antes de usar como métrica de produção. Na prática, 50 avaliações humanas são suficientes para você saber se o juiz automático está alinhado com o julgamento real.
Como montar um ciclo de avaliação sem dataset rotulado
Você não precisa rotular mil pares de pergunta e resposta para começar. O ponto de entrada mais prático é criar um conjunto pequeno de perguntas representativas do seu domínio, entre 30 e 60, com as respostas esperadas que você mesmo valida.
Esse conjunto vai ser o seu benchmark mínimo. Toda mudança significativa no pipeline, trocar o modelo de embedding, ajustar o tamanho dos chunks, mudar a estratégia de retrieval, deve ser avaliada contra esse conjunto antes de ir para produção.
Acontece que 40 perguntas bem escolhidas revelam mais sobre o comportamento do sistema do que 400 perguntas aleatórias. O critério de seleção importa: inclua perguntas que o sistema atual erra, perguntas de alta importância para o negócio e perguntas com respostas que dependem de contexto muito específico nos documentos. Aquelas que parecem simples mas envolvem ambiguidade de domínio são candidatas certas.
Avaliação offline vs. monitoramento em produção
Avaliação offline é o que você faz antes do deploy: rodar o benchmark, medir as métricas, comparar com a versão anterior. É um portão de qualidade, não uma garantia.
Monitoramento em produção é diferente. Você não consegue avaliar 100% das perguntas dos usuários em tempo real, mas pode fazer amostragem. Um percentual das conversas reais, entre 5% e 10%, é avaliado automaticamente e as métricas são agregadas por semana.
O que você está procurando é tendência, não número absoluto. Se a faithfulness média cai de 0,85 para 0,72 ao longo de duas semanas, você tem um sinal claro de que algo mudou, mesmo que os usuários ainda não tenham reclamado. Pode ser que os documentos de origem foram atualizados e os embeddings estão desatualizados. Pode ser que um novo tipo de pergunta começou a aparecer fora da distribuição original.
Detalhe importante: monitoramento sem alerta não vale nada. Defina um threshold mínimo aceitável para cada métrica e configure algum tipo de notificação quando ele for violado. Métrica que ninguém olha não existe.
O impacto de não avaliar o RAG em produção
Sem avaliação de RAG, você perde a capacidade de distinguir melhora de regressão. Toda mudança no pipeline vira um ato de fé.
Mais concreto: sem faithfulness monitorada, você não sabe quantas vezes por dia o modelo está inventando detalhes que não estão nos documentos. Esse número pode ser pequeno e aceitável, ou pode estar corroendo a confiança dos usuários silenciosamente.
E quando a confiança vai, ela demora para voltar. Um sistema que errou de forma visível três vezes vai ter os usuários questionando todas as respostas, inclusive as corretas. Pois é, o custo não é só a resposta errada em si.
Dúvidas comuns sobre avaliação de RAG
O que é faithfulness e por que é diferente de acurácia?
Acurácia compara a resposta com uma resposta de referência conhecida. Faithfulness compara a resposta com o contexto que o modelo recebeu, independente de qual seja a resposta ‘correta’. Um modelo pode ter alta fidelidade ao contexto e ainda assim estar errado se o contexto recuperado estava errado desde o início. São problemas diferentes.
Preciso de um dataset rotulado para começar a avaliar?
Não. LLM-as-judge permite avaliar métricas como faithfulness e relevância sem referências anotadas. Um conjunto pequeno de 30 a 50 perguntas representativas é suficiente para começar. Rotulação humana intensiva é útil para calibrar o avaliador automático, não como pré-requisito para sair do zero.
Com que frequência devo rodar a avaliação?
Em desenvolvimento, a cada mudança significativa no pipeline. Em produção, a avaliação amostral pode rodar continuamente. O benchmark offline completo vale revisar quando você muda embeddings, retriever, modelo de geração ou a base de documentos.
Qual métrica monitorar primeiro se só puder escolher uma?
Faithfulness. É o sinal mais direto de que o modelo está saindo dos limites do que foi recuperado. Uma queda de faithfulness é sempre um alerta vermelho, independente de como a resposta soa para quem lê sem conhecer os documentos de origem.
Próximo passo: defina sua métrica antes da próxima mudança
Avaliação de RAG não é detalhe de implementação. É o que separa um sistema que você consegue evoluir com confiança de um que você torce para que esteja funcionando.
O próximo passo concreto é definir pelo menos uma métrica para medir antes de qualquer alteração no seu pipeline. Se você ainda não tem um conjunto de avaliação, crie 30 perguntas representativas do seu domínio esta semana e passe a comparar versões contra esse benchmark antes de subir qualquer mudança.
- Escolha uma métrica primária: faithfulness é a melhor candidata para começar.
- Monte um conjunto pequeno de perguntas representativas com respostas esperadas validadas por você.
- Decida o threshold mínimo aceitável antes de subir qualquer nova versão do pipeline.
- Configure monitoramento amostral em produção, mesmo que simples, para capturar degradação antes do usuário.
Se quiser aprofundar no lado de observabilidade depois do deploy, o artigo sobre observabilidade para LLMs em produção cobre o que rastrear além de custo e latência. E se você ainda está montando a base do seu pipeline, o artigo sobre RAG na prática é o ponto de partida certo. Para entender os embeddings que alimentam o retriever, veja também o artigo sobre embeddings para busca semântica.
