EN·ES·PT
Guia de campo · avaliação de RAG

Como de fato testar um sistema RAG.

A maioria das demos de geração aumentada por recuperação é avaliada no achismo: alguém lê três respostas, elas parecem plausíveis, entra em produção. Isso não é avaliação — é otimismo. Um sistema RAG falha de maneiras específicas e testáveis: cita o trecho errado, inventa um fato que o contexto recuperado nunca disse ou responde com confiança quando deveria ter dito "não tenho essa informação". Cada um desses modos de falha tem uma verificação que o pega. Este é o checklist, e ele está fundamentado em um painel que construí no qual a cobertura de citações é 100% por construção — não existe caminho de código capaz de gerar uma frase sem citação.

Prova: o build 100% citado → Experimente a demo de avaliação ao vivo → Certificado: ISTQB CT-AI
5
dimensões que toda avaliação de RAG precisa cobrir
100%
cobertura de citações no build de referência
0
caminhos de geração sem citação (por construção)
1
demo ao vivo que você pode avaliar por conta própria

O número de 100% é estrutural, não uma pontuação de benchmark: o pipeline não consegue emitir uma frase de resposta que não esteja atrelada a uma fonte recuperada. Verifique no build em case-studies.html.

O checklist · o que uma avaliação de RAG de verdade mede

Cinco coisas, ou você está chutando.

Uma bateria de avaliação de RAG com resultado aprovado/reprovado precisa pontuar todas as cinco em um conjunto fixo de perguntas — idealmente um golden set com fontes corretas conhecidas — e bloquear a release com base nos resultados. Pule uma e você deixou uma classe inteira de falhas sem teste.

  • 01Cobertura de citações. Que fração das afirmações da resposta carrega uma citação que realmente as sustenta? Não "tem uma nota de rodapé" — o trecho citado precisa conter a afirmação. Meta: toda frase que sustenta a resposta é rastreável até uma fonte recuperada.
  • 02Precisão e recall de recuperação. O retriever trouxe os trechos que contêm a resposta (recall) e quanto ruído veio junto (precisão)? Um gerador perfeito não salva um retriever que nunca buscou a passagem certa.
  • 03Fundamentação / fidelidade. Cada afirmação é acarretada pelo contexto recuperado, ou o modelo acrescentou "conhecimento" do pré-treinamento que não está nas fontes? É aqui que a alucinação se esconde mesmo quando há citações presentes.
  • 04Abster-se quando não há evidência. Quando o corpus genuinamente não contém a resposta, o sistema diz isso — ou inventa? Teste com perguntas fora do corpus e exija uma resposta explícita de "evidência insuficiente".
  • 05Latência e custo por consulta. Recuperação + rerank + geração somam milissegundos e tokens cada um. Meça a latência p50/p95 e o custo por consulta, porque um sistema preciso que ninguém consegue pagar para rodar ainda é um sistema que falhou.
Fluxo de avaliação de RAG Uma consulta de usuário flui para a recuperação, que retorna trechos ranqueados. Um portão de fundamentação então produz uma resposta fundamentada e citada quando a evidência é suficiente, ou se abstém quando não é. Consulta pergunta do usuário Recuperação embed + busca Trechos ranqueados rerank top-k Portão de evidência Fundamentada + citada Abstém-se sem evidência suficiente insuficiente

O portão é o jogo todo. Respostas só entram em produção quando a evidência recuperada sustenta cada afirmação; caso contrário, o sistema se abstém em vez de inventar. Remover o ramo de abstenção é a causa mais comum de RAG "confiantemente errado".

A matriz · modo de falha → a verificação que o pega

Toda forma de o RAG quebrar, e seu teste.

Modos de falha de RAG mapeados para a verificação de avaliação que pega cada um
Modo de falhaO que o usuário vêA verificação que o pega
Afirmação sem citaçãoUma frase confiante sem fonte que você possa verificar.Cobertura de citações
Citação do trecho erradoUma nota de rodapé que aponta para uma passagem que não sustenta a afirmação.Acarretamento citação → afirmação
Recuperação falha"Não sei" quando a resposta estava no corpus o tempo todo.Recall de recuperação
Recuperação ruidosaA resposta desvia porque trechos irrelevantes lotaram a janela de contexto.Precisão de recuperação
Fato alucinadoUm detalhe plausível que as fontes nunca de fato continham.Fundamentação / fidelidade
Fabulação confianteUma resposta completa a uma pergunta que o corpus não consegue sustentar.Abster-se quando não há evidência
Índice desatualizadoA resposta de ontem para o documento de hoje.Verificação de frescor / reindexação
Precisão inviávelRespostas corretas que levam 8 segundos e custam dinheiro de verdade cada uma.Latência e custo por consulta

Uma bateria séria roda toda essa matriz em um golden set fixo a cada mudança e reprova o build quando qualquer linha regride — a mesma disciplina de barrar o build na regressão que está por trás do meu trabalho de QA.

A prova · cobertura de citações por construção

100% citado, porque não há outro caminho.

A decisão de design

Em vez de gerar o texto e torcer para que as citações se encaixem depois, o pipeline vincula cada trecho de resposta que emite à passagem recuperada de onde ele veio. Se uma afirmação não tem trecho de apoio, ela não é escrita — o sistema se abstém nesse ponto em vez de inventar um.

Por que é estrutural

Cobertura de citações não é uma pontuação que ajustei — é uma propriedade do caminho de código. Não há rota de geração sem citação para regredir. Essa é a diferença entre "geralmente citamos" e "não conseguimos não citar".

Veja rodando

O estudo de caso do painel de pesquisa percorre o build. E a própria demo de avaliação ao vivo do site permite colar uma resposta de IA e vê-la ser avaliada contra o mesmo tipo de verificações em tempo real.

▸ veja o build 100% citado ▸ experimente a demo de avaliação ao vivo a cobertura é estrutural · verifique você mesmo
Por que aceitar este checklist de mim

Eu bloqueio minhas próprias releases com base em evidências.

A disciplina de abster-se e citar descrita acima não é teoria. Meu QA OS pegou 15 CVEs altas/críticas em seu próprio conjunto de dependências, bloqueou sua própria release e foi corrigido no mesmo dia para 3.759 testes passando em 13 de 13 portões. Minha suíte de regressão SDET roda 37 de 37 specs, zero flakes, em 15,3 segundos. Este site inteiro roda seu próprio QA — mais de 100 verificações, limpo no axe — e traz uma demo de avaliação ao vivo que você mesmo pode quebrar.

15 CVEs pegas, release bloqueada 3.759 testes · 13/13 portões 37/37 specs · 0 flakes · 15,3s ISTQB CT-AI ISTQB Test Automation Engineer
▸ as CVEs pegas ▸ a correção no mesmo dia ▸ a suíte 37/37 ↗
Relacionado · mais sobre testar IA
Contrate um Engenheiro de QA de IA →Consultor de Avaliação de LLM →Teste de Agentes de IA →Reduza Flakiness de Testes →

Preocupado que seu sistema RAG esteja chutando?

Agende uma chamada e eu construo para você uma bateria de avaliação que pontua todas as cinco dimensões e bloqueia suas releases — ou avalie a resposta da sua IA ao vivo, agora mesmo.

Agendar uma chamada → experimente a demo de avaliação ao vivo → veja o build 100% citado →
exemplo prático

O que o portão de fato pega.

Uma falha real de RAG não é um crash — é uma resposta confiante e errada que parece boa. Aqui está uma que a avaliação pega:

Consulta

"Qual é a nossa janela de reembolso para planos enterprise?"

✕ recuperou o trecho errado

A melhor correspondência foi a política de consumidor ("30 dias com garantia de reembolso"). O modelo respondeu "Sim — 30 dias" — fluente, confiante e errado para enterprise. Um humano dá uma olhada e coloca em produção.

✓ o portão pega, e então corrige

A pontuação de fidelidade sinaliza que a resposta não está fundamentada em uma fonte enterprise — reprova no portão de citação. A recuperação é ajustada para buscar os termos do formulário de pedido; a resposta corrigida cita a cláusula certa.

O ponto: a resposta errada parecia idêntica em qualidade à certa. Só uma verificação de fundamentação as distinguiu.

perguntas frequentes

Perguntas, respondidas.

Como testar RAG é diferente de testar um LLM puro?
RAG tem duas superfícies de falha: recuperação (buscou o contexto certo?) e geração (respondeu com fidelidade e citou a fonte?). Você precisa medir ambas — uma resposta confiante a partir do trecho errado continua errada.
Como você mede fidelidade e alucinação?
Cada resposta é pontuada contra o contexto recuperado com LLM-as-judge mais verificações determinísticas de citação, de modo que uma resposta que não esteja fundamentada em uma fonte real falha mesmo quando parece bem escrita.
A avaliação de RAG pode rodar em CI?
Sim. A suíte bloqueia merges — uma mudança de recuperação ou de prompt que reduza a cobertura de citações fica vermelha antes de entrar em produção.
O que recebemos no final?
Uma suíte de avaliação de RAG classificada no seu repositório, um painel com pontuações, um portão de CI e um runbook que sua equipe pode operar.
Qual é a diferença entre cobertura de citações e fundamentação?
Cobertura de citações pergunta se a resposta cita suas fontes; fundamentação pergunta se essas fontes citadas realmente sustentam cada afirmação. Uma resposta pode citar um trecho e ainda assim interpretá-lo mal — por isso os dois são pontuados separadamente.
Quais métricas de recuperação você mede — precisão e recall de contexto?
Precisão de contexto (os trechos recuperados eram pertinentes?) e recall de contexto (a recuperação deixou de fora um trecho que a resposta precisava?). Ambas rodam contra um conjunto de perguntas rotulado, de modo que uma mudança no retriever muda um número em vez de uma impressão.
Você conserta o pipeline de recuperação ou só o mede?
A medição vem primeiro, mas a avaliação aponta direto para a correção — chunking, embeddings, reranking ou o prompt. Posso implementar essas mudanças e rodar a suíte novamente para comprovar o ganho.
Como você impede o modelo de inventar fatos?
Cada afirmação é verificada contra o contexto recuperado, e respostas sem nenhuma fonte de apoio falham na avaliação. Combinado com um teste de abstenção, o sistema é pontuado por dizer “não sei” em vez de chutar.
Isso funciona com meu banco de dados vetorial e meu modelo de embedding?
Sim — a avaliação fica acima da sua stack e trata a recuperação como caixa-preta, então qualquer banco de dados vetorial ou modelo de embedding funciona. Trocar qualquer um deles vira um experimento mensurável em vez de uma mudança às cegas.
Quais entregáveis eu recebo de uma avaliação de RAG?
Uma suíte de avaliação classificada no seu repositório, um painel com pontuações cobrindo recuperação e fundamentação, um portão de CI que bloqueia regressões e um runbook que sua equipe pode operar sem mim.