Como Avaliar Pipelines de RAG para LLMs: Recall, Precisão e Fidelidade

Imagine que você construiu um assistente de IA para a sua empresa. Ele tem acesso a todos os manuais técnicos, mas, quando um cliente pergunta sobre a garantia, a IA inventa um prazo que não existe ou, pior, ignora completamente a seção de trocas. Esse é o problema clássico das alucinações em modelos de linguagem. Para resolver isso, usamos o RAG (Retrieval-Augmented Generation), ou Geração Aumentada por Recuperação, que é uma arquitetura híbrida que combina a busca de documentos externos com a capacidade de geração de texto de um LLM.

Ter um sistema RAG rodando é fácil; o desafio real é saber se ele é confiável. Como você prova que a resposta da IA é baseada em fatos e não em "criatividade"? A resposta está em medir três pilares: a capacidade de encontrar a informação (Recall), a relevância do que foi encontrado (Precisão) e a honestidade da resposta final (Fidelidade). Se você ignorar essas métricas, estará apenas torcendo para que a IA não minta para o seu cliente.

O que realmente acontece dentro de um pipeline RAG?

Para avaliar o sistema, primeiro precisamos entender que ele não é um bloco único, mas sim dois componentes trabalhando juntos. Primeiro, temos o Retriever (Recuperador), que funciona como um bibliotecário: ele vasculha a base de conhecimento e traz os fragmentos de texto mais relevantes. Depois, entra o Generator (Gerador), que é o LLM propriamente dito. Ele lê esses fragmentos e redige a resposta final.

O erro comum é avaliar apenas o resultado final. Se a resposta estiver errada, a culpa foi do bibliotecário que trouxe o livro errado ou do escritor que leu o livro certo, mas interpretou mal? É por isso que a estratégia de rag exige uma avaliação modular. Se o Retriever falha, não há prompt no mundo que salve a resposta. Se o Generator falha, você tem a informação correta na mesa, mas a IA a ignora ou a distorce.

Medindo a eficiência da recuperação: Recall e Precisão

A primeira etapa da avaliação foca no Retriever. Aqui, queremos saber se o sistema consegue achar a "agulha no palheiro". A métrica principal é o Recall@k, que mede a porcentagem de documentos relevantes que foram recuperados dentro dos primeiros k resultados. Se você recupera 5 documentos e a resposta estava no 6º, seu Recall@5 é zero, e a IA jamais encontrará a resposta, independentemente de quão inteligente ela seja.

Mas não basta trazer tudo; trazer lixo prejudica a performance. É aí que entra a precisão. Se o sistema recupera 100 documentos para responder a uma pergunta simples, ele está introduzindo ruído. O ruído consome tokens, aumenta o custo e pode confundir o modelo, levando-o a dar prioridade a informações irrelevantes. Para refinar isso, usamos técnicas como o MMR (Maximum Marginal Relevance), que equilibra a relevância com a diversidade, evitando que o sistema traga cinco documentos que dizem exatamente a mesma coisa.

O conceito de Faithfulness e a luta contra alucinações

Agora entramos na parte mais crítica: a Faithfulness (Fidelidade). Diferente da correção factual (se a resposta é verdade no mundo real), a fidelidade mede se a resposta é verdade de acordo com os documentos recuperados.

Imagine que o documento recuperado diz: "O céu é verde". Se a IA responder "O céu é azul", ela foi factualmente correta para nós, mas infiel ao contexto fornecido. Em cenários corporativos, isso é perigoso. Se o seu manual diz que o prazo de entrega é 10 dias e a IA diz 5 porque "acha" que é melhor, você tem um problema de fidelidade. Para medir isso, usamos o Context Overlap, que analisa quanto da resposta final pode ser mapeado diretamente para as frases dos documentos de origem.

Uma técnica avançada para validar isso é o uso de LLMs como juízes. Você pede a um modelo superior (como o GPT-4o ou Claude 3.5) para analisar a resposta e o contexto, perguntando: "Existe alguma afirmação nesta resposta que NÃO esteja presente nos documentos fornecidos?". Isso cria um loop de feedback automatizado que permite escalar a avaliação sem precisar de humanos lendo cada linha.

Análise Comportamental e a Camada de Atenção

Para quem busca um nível profissional de avaliação, olhar apenas para a resposta final não é suficiente. É preciso analisar o comportamento do modelo durante a geração. Isso é feito através da análise de log probabilities. Quando a IA gera um token (uma palavra ou parte dela), ela atribui uma probabilidade a cada possível próxima palavra.

Se a probabilidade do token escolhido for muito baixa, é um sinal vermelho. Isso indica que o modelo está "hesitante" e as chances de alucinação aumentam drasticamente. Além disso, observar os scores de atenção permite entender em qual parte do documento a IA estava focando no momento em que escreveu a mentira. Se ela escreveu um dado técnico mas a atenção estava focada em um parágrafo irrelevante, você descobriu que o problema está na forma como o modelo processa contextos longos.

Estratégias de Otimização para Pipelines RAG

Depois de medir e encontrar os gargalos, como melhorar a performance? A otimização geralmente começa no corte dos dados. O Semantic Chunking (Fragmentação Semântica) é muito superior ao corte fixo por caracteres. Em vez de cortar o texto a cada 500 caracteres, o sistema identifica onde termina um conceito e começa outro, garantindo que a informação relevante não seja cortada ao meio.

Outro passo fundamental é o ajuste fino do Retriever. Imagine um chatbot de saúde. Se o usuário busca por "AVC" (Acidente Vascular Cerebral), o sistema não pode trazer artigos sobre "AVC" como sigla de alguma empresa de transporte. O ajuste fino com contrastive loss ensina o modelo a aproximar documentos semanticamente similares e afastar os que são apenas semelhantes na escrita, mas diferentes no significado.

Por fim, a implementação de um Reranker (Reclassificador) pode mudar o jogo. O Retriever traz, por exemplo, 20 documentos candidatos. O Reranker, que é um modelo menor e mais lento, mas muito mais preciso, reordena esses 20 para garantir que os 3 mais certeiros fiquem no topo. Isso maximiza a precisão sem sacrificar a velocidade da busca inicial.

A hierarquia de prioridades: Groundedness vs. Correção

Um ponto que confunde muitos desenvolvedores é a diferença entre Groundedness (Fundamentação) e Correctness (Correção). Um sistema pode ser perfeitamente fundamentado (ou seja, ele repete exatamente o que está no documento), mas a resposta ainda ser incorreta porque o documento de origem estava errado.

Qual priorizar? Depende do seu negócio. Se você está criando um sistema para analisar contratos antigos, a fundamentação é tudo: você quer que a IA diga o que está escrito no papel, mesmo que o contrato seja absurdo. Agora, se você está criando um assistente de suporte técnico moderno, a correção factual é a prioridade, e você deve configurar o sistema para alertar quando houver conflito entre o documento e o conhecimento geral do modelo.

Próximos Passos e Solução de Problemas

Se você percebeu que seu sistema está falhando, não tente ajustar o prompt primeiro. Siga este fluxo de diagnóstico:

• Sua IA diz que não sabe a resposta, mas a informação existe? Foque no Retriever. Teste diferentes tamanhos de chunking ou implemente um ajuste fino no embedding do modelo.
• A IA traz a informação certa, mas a resposta final está errada? Foque no Generator. Melhore o prompt de sistema (System Prompt) ou teste um modelo com janela de contexto maior.
• A IA inventa fatos que não estão nos manuais? Foque na Fidelidade. Reduza a "temperatura" do modelo para 0 e implemente a técnica de verificação de citações (exigir que a IA cite a página do documento).

Lembre-se que a avaliação de RAG não é um evento único, mas um ciclo. À medida que você adiciona novos documentos à sua base, a semântica do seu domínio muda, e métricas que funcionavam ontem podem se tornar obsoletas hoje. A chave para um sistema escalável é a monitoração contínua dos logs de probabilidade e o feedback real dos usuários.