Como criar RAG confiável: análise aprofundada de sete pontos de falha e frameworks de avaliação

Geração Aumentada por Recuperação (RAG) é fundamental para a arquitetura de IA moderna, servindo como uma estrutura essencial para a construção de agentes conscientes do contexto.

Mas passar de um protótipo básico para um sistema pronto para produção envolve navegar por obstáculos significativos na recuperação de dados, consolidação de contexto e síntese de respostas.

Este artigo fornece uma análise aprofundada de sete pontos de falha típicos de RAG e das métricas de avaliação com exemplos práticos de codificação.

A Anatomia das Falhas de RAG – 7 Pontos de Falha (FPs)

De acordo com os pesquisadores Barnett e colegas, sistemas de Geração Aumentada por Recuperação (RAG) encontram sete pontos de falha (FPs) específicos ao longo do pipeline.

O diagrama abaixo ilustra essas etapas:

Figura A. Processos de Indexação e Consulta necessários para criar um sistema RAG. O processo de indexação é feito durante o desenvolvimento e as consultas durante a execução. Os pontos de falha identificados neste estudo são mostrados em caixas vermelhas (fonte)

Vamos explorar cada FP organizado de acordo com a sequência do pipeline, seguindo a progressão do canto superior esquerdo ao canto inferior direito mostrada na Figura A.

FP1. Conteúdo Ausente

Conteúdo ausente ocorre quando o sistema é questionado sobre algo que não pode ser respondido porque a informação relevante não está presente no repositório de vetores disponível.

A falha ocorre quando um LLM fornece uma resposta plausível, mas incorreta, em vez de admitir que não sabe.

FP2. Documento fora das primeiras posições

Essa é uma situação em que um documento correto existe no repositório de vetores, mas o recuperador falha em posicioná-lo suficientemente bem para incluí-lo nos top-k documentos fornecidos a um LLM como contexto.

Em consequência, a informação correta nunca alcança o LLM.

FP3. Não Está no Contexto (Limitações da Estratégia de Consolidação)

Essa é uma situação em que um documento correto existe e é recuperado do repositório de vetores, mas é excluído durante o processo de consolidação.

Isso acontece quando muitos documentos são retornados e o sistema deve filtrá-los para se ajustar à janela de contexto de um LLM, aos limites de tokens ou aos limites de requisições.

FP4. Não Extraído

Essa é uma situação em que um LLM falha em identificar a informação correta no contexto, mesmo que a informação correta estivesse no repositório de vetores e tenha sido recuperada e consolidada com sucesso.

Isso acontece quando o contexto é excessivamente ruidoso ou contém informações contraditórias que confundem o LLM.

FP5. Formato Errado

Essa é uma situação em que o armazenamento, recuperação, consolidação e interpretação do LLM são tratados com sucesso, mas o LLM falha em seguir instruções de formatação específicas fornecidas no prompt, como uma tabela, uma lista com marcadores ou um esquema JSON.

FP6. Especificidade Incorreta

A saída do LLM está tecnicamente presente, mas ou muito geral ou muito complexa em comparação com as necessidades do usuário.

Por exemplo, um LLM gera respostas simples para uma consulta do usuário com um objetivo profissional complexo.

FP7. Respostas Incompletas

Essa é uma situação em que um LLM gera uma saída que não está necessariamente errada, mas omite informações essenciais que estavam disponíveis no contexto.

Por exemplo, quando um usuário faz uma pergunta complexa como “Quais são os pontos principais nos documentos A, B e C?”, o LLM aborda apenas uma ou duas das fontes.

Como os FPs Comprometem o Desempenho do Pipeline RAG

Cada um desses FPs impacta o desempenho dos pipelines RAG:

Falhas de Integridade e Confiança dos Dados

Quando faltam informações ou elas estão incorretas, o sistema não é mais uma fonte confiável de informações. Os principais FPs incluem:

• FP1 (Conteúdo Ausente): A resposta não está no documento desde o início.
• FP4 (Não Extraído): O LLM decide ignorar a resposta correta no documento.
• FP7 (Incompleto): O LLM fornece meias-verdades, omitindo informações importantes.

Gargalos de Recuperação e Eficiência

O pipeline RAG pode ser ineficiente quando perde informações-chave nas etapas de recuperação e consolidação. Os principais FPs incluem:

• FP2 (Documento fora das primeiras posições): O modelo de embeddings falha em selecionar os top-k embeddings.
• FP3 (Estratégia de Consolidação): O script para cortar documentos para se ajustar aos limites do LLM descarta as partes mais importantes.

Erros de Experiência do Usuário e Formatação

Embora correta, uma saída com baixa legibilidade ou no formato errado pode comprometer a experiência do usuário. Os principais FPs incluem:

• FP5 (Formato Errado): O LLM falha em seguir o formato de saída específico, como JSON.
• FP6 (Especificidade Incorreta): O LLM gera uma saída longa para uma pergunta simples de sim/não, ou vice-versa (resposta muito breve para uma pergunta complexa).

A Pilha de Avaliação: Estruturas para Mitigar FPs

As métricas de avaliação são projetadas para mitigar sistematicamente esses FPs.

Esta seção explora as principais métricas de avaliação com casos práticos.

Principais Métricas de Avaliação RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – O Teste de Unidade antes da Implantação

DeepEval calcula uma pontuação ponderada com base nos critérios.

Um LLM como juiz (por exemplo, GPT-4o) avalia cada critério contra a saída do LLM:

DeepEval aproveita G-eval, um framework de cadeia de pensamento (CoT) que adota uma abordagem em várias etapas para avaliar a saída:

1. Definir um critério para medir (por exemplo, “coerência”, “fluência” ou “relevância”).
2. Gerar etapas de avaliação (usando um LLM avaliador).
3. Siga as etapas de avaliação e analise a entrada e a saída do LLM.
4. Calcule uma soma ponderada esperada da pontuação de cada critério.

Cenário Comum na Prática

• Situação: Um assistente de documentação técnica (bot) para um produto de software complexo parece funcionar a cada vez que a equipe de engenharia atualiza a base de código.
• Problema: Não há prova quantitativa de que o bot ainda possa responder à consulta do usuário (você apenas “acha” que está funcionando…).
• Solução: Integre uma função PyTest como suíte de regressão CI/CD no GitHub Actions, onde DeepEval executa G-Eval e outras métricas sobre um caso de teste:

• Resultados Esperados: Se alguma pontuação das métricas cair abaixo do limite (0,85), o PyTest lança AssertionError – fazendo o build de CI falhar imediatamente, impedindo que a regressão silenciosa alcance a produção.

Nota do Desenvolvedor – O Caso de Teste para DeepEval
Um conjunto de objetos LLMTestCase define o caso de teste que DeepEval executa.

Na prática, esse caso de teste deve conter as consultas mais importantes dos usuários e saídas rotuladas com o contexto recuperado.

Esses podem ser recuperados de um arquivo JSON ou CSV.

RAGAS – O Otimizador da Agulha no Palheiro

Avaliação de Geração Aumentada por Recuperação (RAGAS) visa avaliar RAG sem um conjunto de dados anotado por humanos, gerando conjuntos de teste sintéticos.

Em seguida, calcula as principais métricas:

Figura B. O diagrama da tríade de avaliação RAGAS conectando Pergunta, Contexto e Resposta por meio de métricas de Precisão, Revocação, Fidelidade e Relevância (criado por Kuriko IWAI)

As principais métricas são categorizadas em três grupos:

• Pipeline de recuperação (linha preta, contínua, Figura B): Precisão do contexto, revocação do contexto.
• Pipeline de geração (linha preta, tracejada, Figura B): Fidelidade, relevância da resposta.
• Dados de referência (caixa vermelha, Figura B): Semelhança semântica da resposta, correção da resposta.

Cenário Comum na Prática

• Situação: O sistema RAG para contratos jurídicos está omitindo cláusulas essenciais. Você não tem certeza se o problema está na Pesquisa (Recuperador) ou na Leitura (Gerador).
• Problema: Não há ideia sobre o top-k ótimo (número de fragmentos recuperados).
• Solução: Use RAGAS para criar um conjunto de teste sintético com 100 pares de perguntas e evidências. Em seguida, execute o pipeline RAG no conjunto de teste para calcular a revocação do contexto e a precisão do contexto:
• Resultado Esperado: Dependendo dos resultados das métricas, o plano de ação pode ser o seguinte:

Tabela 1. Matriz de Diagnóstico e Plano de Ação RAGAS – Mapeando Pontuações para Ajustes do Sistema.

TruLens – O Especialista em Laços de Feedback

TruLens se concentra na mecânica interna do processo RAG, em vez de apenas na saída final, usando funções de feedback.

Ele também usa uma pontuação baseada em LLM que reflete quão bem a resposta atende à intenção da pergunta, usando uma escala Likert de 4 pontos (0-3), tornando-o superior para classificar a qualidade de diferentes resultados de pesquisa.

Cenário Comum na Prática

• Situação: Um bot de aconselhamento médico responde corretamente a uma pergunta do usuário, mas adiciona uma dica que não está na base de PDF verificada.
• Problema: A dica adicionada pode ser útil, mas não está fundamentada nessas fontes.
• Solução: Use TruLens para implementar uma função de feedback de fundamentação com um limite como score > 0.8.

• Resultados Esperados: Quando o LLM gera uma resposta que contém informações não presentes nos fragmentos recuperados, TruLens sinaliza o registro no seu painel.

Arize Phoenix – O Mapa de Falhas

Arize Phoenix é uma ferramenta de observabilidade e avaliação de código aberto para avaliar saídas de LLM, incluindo sistemas RAG complexos.

Construído sobre OpenTelemetry pela Arize AI, ele se concentra na observabilidade, tratando a avaliação do LLM como um subconjunto de MLOps.

No contexto da avaliação RAG, Phoenix se destaca na análise de embeddings, usando Uniform Manifold Approximation and Projection (UMAP) para reduzir embeddings de vetores de alta dimensionalidade para espaço 2D/3D.

Essa análise de embeddings revela matematicamente se as consultas com falha estão agrupadas semanticamente, indicando uma lacuna no banco de dados de vetores.

Cenário Comum na Prática

• Situação: Um bot de suporte ao cliente funciona bem para reembolsos, mas fornece respostas sem sentido para reclamações de garantia.
• Problema: Lacuna de dados no banco de dados de vetores (que não pode ser encontrada nos logs).
• Solução: Use Arize Phoenix para gerar uma Visualização de Embedding UMAP (UEV), um mapa 3D para o banco de dados de vetores – para sobrepor consultas de usuário nos fragmentos de documentos.
• Resultados Esperados: Veja visualmente um cluster de consultas de usuário aterrissando na zona escura onde nenhum documento existe, indicando que o carregamento de alguns documentos foi esquecido no repositório de vetores.

Braintrust – A Rede de Segurança de Regressão de Prompt

Braintrust é projetado para ciclos de iteração de alta frequência usando comparação entre modelos.

Cenário Comum na Prática

• Situação: Uma equipe de engenheiros atualiza o prompt de “Responda à pergunta” (Caso A) para uma instrução de sistema mais complexa de 500 palavras (Caso B).
• Problema: Melhorar o prompt para o Caso B pode quebrar acidentalmente o Caso A.
• Solução: Use Braintrust para criar um conjunto de dados de referência com um conjunto de N exemplos perfeitos (por exemplo, N = 50). Deixe Braintrust executar uma comparação lado a lado (SxS) a cada vez que a equipe atualiza uma palavra no prompt:

• Resultado Esperado: Um relatório de diferenças que mostra exatamente quais dos N = 50 casos de referência melhoraram ou pioraram.

Conclusão

Com estruturas de avaliação adequadas, o RAG pode ser uma ferramenta competitiva para fornecer ao LLM o contexto mais relevante para a consulta do usuário.

Estratégia de Implementação: Mapeando Métricas para Pontos de Falha

Embora não haja uma solução que se ajuste a todos, a Tabela 2 mostra quais métricas de avaliação aplicar para cada FP abordado neste artigo:

Tabela 2. A Matriz de Mitigação de Pontos de Falha – Qual Ferramenta Resolve Qual FP?

DeepEval e RAGAS podem aproveitar suas métricas de fidelidade para medir falhas de integridade de dados (FP1, FP4, FP7).

TruLens aproveita sua precisão e revocação do contexto para medir a relevância do contexto para a saída – avaliando efetivamente FP2.

Arize Phoenix fornece um rastreamento visual do processo de recuperação, facilitando a visualização de se o documento recuperado foi perdido durante a consolidação (FP3).

Para falhas de UX, DeepEval cria métricas personalizadas para avaliar falhas de UX, enquanto Braintrust se destaca na comparação de conjuntos de dados de referência.