Avaliação RAG: Teste de Recuperação Antes de Ajustar o LLM

A avaliação RAG deve começar com a recuperação. Se a evidência correta nunca chega ao modelo, o ajuste do prompt e as atualizações do modelo apenas tornam o contexto errado mais convincente. Teste a recuperação, a geração e as operações como estágios separados. Mantenha um pequeno conjunto de regressão versionado que falhe quando qualquer estágio piorar.

Nível do leitor: Intermediário. Este guia assume que você sabe que a geração aumentada por recuperação, ou RAG, encontra documentos antes de pedir a um modelo de linguagem para responder.

Neste guia

A avaliação RAG tem três superfícies de falha separadas

Uma aplicação RAG é um pipeline. Uma pontuação para a resposta final oculta qual componente precisa de trabalho.

A ordem importa. A recuperação é a montante. Um gerador não pode citar um parágrafo de política que nunca entrou em seu contexto, e uma resposta fluente não prova que o recuperador funcionou.

A atual documentação do avaliador RAG da Microsoft faz a mesma separação em termos de implementação. Ela fornece medidas de recuperação de documentos para evidências classificadas, e então avalia a fundamentação, relevância e completude da resposta na camada de resposta. O avaliador de recuperação de documentos inclui fidelidade, NDCG, XDCG, relevância máxima e julgamentos de relevância ausente.

_Um útil placar RAG mantém a recuperação, a geração e as verificações operacionais visíveis como camadas separadas._

Por que uma pontuação de ponta a ponta fornece evidências de depuração fracas

Vários frameworks de pesquisa chegam à mesma conclusão prática a partir de direções diferentes.

RAGChecker avalia o comportamento do recuperador e do gerador separadamente. Seus autores compararam oito sistemas RAG em dez domínios. Suas métricas incluem recall de reivindicações e precisão de contexto para recuperação, além de utilização de contexto, sensibilidade ao ruído, alucinação e fidelidade para geração. Em uma meta-avaliação de 280 pares, a pontuação de avaliação geral do RAGChecker teve uma correlação de Spearman de 0.609 com a preferência humana. Os dois anotadores humanos alcançaram 0.689. A avaliação automatizada foi útil, mas não eliminou a lacuna humana.

Ragas propôs medidas sem referência para fidelidade, relevância da resposta e relevância do contexto. Em suas comparações WikiEval, o acordo com as preferências humanas foi de 0.95 para fidelidade, 0.78 para relevância da resposta e 0.70 para relevância do contexto. Os autores acharam a relevância do contexto a mais difícil de julgar. Trate esses números como resultados daquele estudo, não como taxas de precisão universais para cada juiz, conjunto de dados ou domínio.

Um framework mais recente, RAGe, adiciona seleção de componentes e telemetria de hardware. Ele avalia configurações de pipeline em chunking, embedding, recuperação, armazenamento e geração, enquanto poda combinações que excedem limites de latência ou VRAM. O artigo usa Natural Questions, NewsQA e TriviaQA por padrão e suporta conjuntos de dados CSV ou JSON personalizados. Sua principal contribuição é uma maneira de comparar qualidade com restrições de recursos; não estabelece uma configuração que vença em todos os domínios.

Juntos, esses artigos apoiam uma abordagem diagnóstica. Eles não provam que uma métrica ou biblioteca específica é suficiente para produção.

Construa um conjunto de testes antes de escolher métricas

Comece com 40 a 60 perguntas do domínio que você atende. Esse intervalo é um ponto de partida prático, em vez de uma lei estatística. É grande o suficiente para expor vários tipos de falha e pequeno o suficiente para que um humano revise após cada mudança material.

Inclua pelo menos cinco classes de consulta:

Logs de produção podem sugerir perguntas, mas remova dados pessoais e segredos antes de adicionar exemplos a um conjunto de avaliação. Uma recente discussão de praticantes sobre avaliação RAG em produção também enfatiza consultas fixas, configurações versionadas e verificações separadas de recuperação e geração. Essa discussão é uma evidência anedótica sobre a dor do fluxo de trabalho, não uma prova de que a abordagem funciona em todos os sistemas.

Armazene julgamentos contra IDs de documentos estáveis ao lado de qualquer texto copiado. Os limites de chunk mudam quando você ajusta um divisor. Um ID de fonte canônica permite que o mesmo teste sobreviva a essa mudança.

{ "query_id": "refund-window-01", "query": "Quanto tempo um cliente tem para devolver um item não aberto?", "relevant_document_ids": ["returns-policy-v4"], "required_claims": ["Itens não abertos podem ser devolvidos dentro de 30 dias."], "must_abstain": false, "allowed_roles": ["customer", "support"], "as_of": "2026-07-01" }

Para um caso inrespondível, defina `relevant_document_ids` como uma lista vazia e `must_abstain` como `true`. Para um caso restrito, execute a mesma consulta sob dois papéis. O usuário autorizado deve recuperar o documento; o usuário não autorizado não deve aprender o conteúdo desse documento.

Equipes que constroem seu próprio corpus e camada de aplicação devem versionar o contrato de conteúdo junto com o conjunto de testes. A mesma regra se aplica a sistemas de dados personalizados construídos com Next.js e AI: uma mudança de esquema ou conteúdo pode alterar a recuperação sem tocar no prompt.

Passo 1: avalie a recuperação sem gerar uma resposta

Execute cada consulta através do recuperador e salve os IDs de resultados classificados, pontuações, timestamps e decisões de acesso. Não chame o modelo de linguagem ainda.

Escolha métricas que correspondam à forma da evidência

Use taxa de acerto@k quando um documento correto é suficiente. Pergunta se pelo menos uma fonte relevante aparece nos primeiros `k` resultados.

Use recall@k quando a resposta requer várias fontes. Mede quantos documentos relevantes conhecidos apareceram nos primeiros `k`.

Use precisão@k quando o contexto irrelevante é caro ou distrativo. Alto recall com baixa precisão pode inundar o gerador com ruído.

Use MRR quando o primeiro resultado relevante é o mais importante. Use NDCG quando vários resultados classificados devem aparecer em uma ordem útil. A Microsoft documenta NDCG e medidas de recuperação classificadas relacionadas em seu avaliador, enquanto o RAGChecker usa recall de reivindicações e precisão de contexto para conectar a evidência recuperada às reivindicações que uma resposta precisa.

Não colete todas as métricas por padrão. Escolha uma medida de cobertura e uma medida de classificação ou ruído. Adicione uma métrica apenas quando ela mudar uma decisão.

Classifique as falhas antes de mudar o modelo

Falhas de recuperação geralmente se enquadram em um pequeno conjunto:

Cada falha tem um proprietário diferente. Re-embedding não pode reparar um documento ausente. Um modelo de linguagem maior não pode reparar um filtro de permissões. Um reranker pode ajudar quando a evidência está presente, mas mal ordenada.

Para aplicações conectadas a ferramentas, preserve a solicitação de recuperação, filtros, IDs de resultados e resposta da ferramenta na trilha. Isso se encaixa no padrão de controle mais amplo descrito em fluxos de trabalho de desenvolvedor MCP: inspecione o contrato, a transição de estado e a prosa final.

Passo 2: avalie a geração sobre evidências fixas

Uma vez que a recuperação atinge seu limite, congele os contextos recuperados e reproduza-os contra o gerador. Isso isola mudanças de prompt ou modelo de mudanças de índice.

Meça quatro comportamentos:

Uma resposta de referência pode ajudar com a completude. É menos útil como a única fonte de verdade porque várias redações podem estar corretas. Armazene reivindicações necessárias e IDs de documentos de apoio quando possível.

Execute um segundo teste de geração com contexto deliberadamente incompleto. Um sistema confiável deve expor incerteza em vez de preencher lacunas da memória do modelo. Isso é importante quando o corpus contém fatos privados, em mudança ou específicos de domínio.

A escolha do modelo ainda afeta a qualidade da resposta, latência e custo, mas vem após a evidência de recuperação. Se o mesmo contexto fixo falhar em geradores, compare compromissos de modelo e API. Se o próprio contexto estiver errado, mudar o gerador é um movimento desperdiçado.

Adicione casos de segurança e conflito ao conjunto de recuperação

Testes de relevância ordinários perdem evidências adversariais ou conflitantes.

Um artigo de julho de 2026 sobre envenenamento síbil polimórfico em RAG testou grupos de passagens lexicamente diferentes que apoiavam a mesma resposta selecionada pelo atacante. Sob a configuração de exposição forçada do artigo, passagens polimórficas produziram uma taxa de sequestro de 22.8% em comparação com 4.0% para passagens monomórficas repetidas. A filtragem por sobreposição de tokens capturou todos os clusters monomórficos e nenhum dos clusters polimórficos.

O resultado não mede com que frequência esse ataque tem sucesso em produção. Os autores fixaram a mistura recuperada em seis passagens de ataque, duas passagens de ouro e dois preenchimentos para isolar o comportamento do leitor. Eles também relatam limitações em torno de uma classe de ataque, risco de contaminação do conjunto de dados, uma ablação de 500 perguntas e verificação baseada em LLM.

A lição de avaliação útil é mais estreita: classifique mais do que “correto” e “alvo do atacante”. O artigo rastreia quatro resultados:

Adicione casos de conflito ao seu próprio conjunto. Inclua reivindicações duplicadas com redações diferentes, uma fonte desatualizada que contradiz a política atual e uma fonte de menor confiança que conflita com uma autoritária. Registre se o sistema responde, se abstém ou desvia.

Calibre juízes LLM antes de confiar em suas pontuações

Juízes LLM tornam os testes de regressão mais baratos, especialmente para fundamentação e cobertura de reivindicações. Eles permanecem dependências de software com prompts, versões de modelo, comportamento de análise e pontos cegos conhecidos.

Use quatro controles:

Os estudos Ragas e RAGChecker mostram por que a calibração é importante. O acordo varia por dimensão, e as correlações automatizadas permanecem abaixo do acordo humano. Uma pontuação numérica deve acionar uma inspeção, não encerrá-la.

As atuais versões de código aberto também mostram trabalho ativo em torno de avaliadores. DeepEval 4.1.3, lançada em 12 de julho de 2026, adicionou verificações determinísticas para loops de agentes e permissões de ferramentas, enquanto corrigia a integração do Ragas. TruLens 2.9.0, lançada em 23 de julho, adicionou conjuntos de juízes, testes de critérios A/B, análise de distribuição de pontuação e geração de conjuntos de ouro. A atividade de lançamento é evidência de trabalho de engenharia mantido, não evidência de que qualquer biblioteca é a escolha certa para sua pilha.

Um fluxo de trabalho de regressão RAG minimalista

Use a mesma sequência para cada mudança material no pipeline:

Um registro de resultado compacto pode parecer assim:

{ "run_id": "rag-2026-07-26-b", "test_set": "support-v7", "corpus_snapshot": "2026-07-25T22:00:00Z", "retrieval": { "recall_at_5": 0.91, "ndcg_at_5": 0.84, "unauthorized_hits": 0 }, "generation": { "grounded_pass_rate": 0.94, "complete_pass_rate": 0.87, "abstention_pass_rate": 0.90 }, "operations": { "p95_ms": 1380, "cost_per_query_usd": 0.0042 } }

Esses números são ilustrativos. Defina limites a partir do seu risco, baseline e custo de erro. Um assistente de conhecimento médico e um ajudante de busca de produtos não devem compartilhar o mesmo portão de lançamento.

Decida a correção a partir da camada falha

Esta tabela é o ponto da avaliação RAG: uma pontuação falha deve identificar o próximo experimento. Se não puder, a métrica está muito distante do componente que você precisa mudar.

O que a evidência suporta

Os artigos mediram sistemas e conjuntos de dados específicos. O RAGChecker descobriu que métricas modulares podem correlacionar com preferências humanas e expor compromissos entre recuperador e gerador. O Ragas descobriu que o acordo entre juízes variou entre fidelidade, relevância da resposta e relevância do contexto. O RAGe demonstrou um framework que combina métricas de qualidade com restrições de latência e memória. O benchmark de envenenamento mostrou que uma configuração de ataque restrita produziu padrões distintos de sequestro, abstenção e desvio.

A evidência não estabelece limites universais, um avaliador universalmente melhor ou prevalência de ataques em produção. Minha interpretação prática é separar os estágios, manter uma fatia calibrada por humanos e exigir que cada métrica aponte para uma ação de engenharia.

Verificações de reivindicações

Fontes