Como Construir RAG Confiável: Uma Análise Profunda em 7 Pontos de Falha e Estruturas de Avaliação

Geração Aumentada por Recuperação (RAG) é fundamental para a arquitetura de IA moderna, servindo como um quadro 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 profunda em sete pontos de falha típicos de RAG e as métricas de avaliação com exemplos práticos de codificação.

A Anatomia da Quebra de RAG – 7 Pontos de Falha (FPs)

De acordo com os pesquisadores Barnett et al., sistemas de Geração Aumentada por Recuperação (RAG) encontram sete pontos de falha 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 no tempo de desenvolvimento e as consultas no tempo de 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 da esquerda para a direita 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 dizer não sabe.

FP2. Perdeu os Documentos Classificados

Essa é uma situação em que um documento correto existe no repositório de vetores, mas o recuperador falha em classificá-lo com alta prioridade o suficiente para incluí-lo nos principais 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 taxa.

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 barulhento 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 falta peças-chave de informação que estavam disponíveis no contexto.

Por exemplo, quando um usuário pergunta 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 informações ausentes ou incorretas estão presentes, 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 em primeiro lugar.
• FP4 (Não Extraído): O LLM decide ignorar a resposta correta no documento.
• FP7 (Incompleto): O LLM fornece meias-verdades, faltando peças 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 (Perdeu os Documentos Classificados): O modelo de embeddings falha em selecionar os principais 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/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 do Desenvolvimento

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 quadro 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 a etapa de avaliação e analise a entrada e a saída do LLM.
4. Calcula 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 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 Action, 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 eleva AssertionError – falhando imediatamente na construção do CI, 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 a maioria das consultas de usuário importantes 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 de triagem de avaliação RAGAS conectando Pergunta, Contexto e Resposta por meio de métricas de Precisão, Recuperaçã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, recuperação do contexto.
• Pipeline de geração (linha preta, tracejada, Figura B): Fidelidade, relevância da resposta.
• Verdade fundamental (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 legais está faltando cláusulas-chave. 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 recuperaçã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 consultor 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.
• Solução: Use TruLens para implementar uma função de feedback de fundamentação com um limite como pontuação > 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 Falha Silencioso

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: Buraco de dados no banco de dados de vetores (não encontrado 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 alguns documentos foram esquecidos ao serem carregados 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 dourado 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 mostrando exatamente quais casos melhoraram ou pioraram para cada um dos conjuntos de dados dourado (N = 50).

Conclusão

Quando tratados com as estruturas de avaliação adequadas, RAG pode ser uma ferramenta competitiva para fornecer contexto de LLM 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 recuperaçã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 verdade.