Avaliar a qualidade de um sistema de Geração Aumentada por Recuperação (RAG) exige substituir impressões subjetivas por métricas numéricas automatizadas. Como um pipeline RAG reúne duas etapas interdependentes (a recuperação de documentos em um banco vetorial e a geração da resposta pelo modelo de linguagem), uma falha final pode decorrer tanto de um contexto truncado quanto de uma alucinação do gerador.
Frameworks de código aberto como Ragas e TruLens resolvem esse desafio ao introduzir medições programáticas para cada elo dessa cadeia. Por meio de modelos juízes (LLM-as-a-judge) e similaridade semântica com embeddings, essas ferramentas permitem monitorar a fidelidade factual da resposta, a relevância do conteúdo e a precisão do contexto recuperado, integrando testes de regressão diretamente às esteiras de software corporativo.
Resumo rápido
- A avaliação de RAG divide-se entre a eficácia do recuperador (retriever) e a precisão do gerador (LLM).
- A tríade RAG mensura três dimensões críticas: fidelidade (ausência de alucinação), relevância da resposta e relevância do contexto.
- Ragas foca em testes baseados em conjuntos de referência (ground truth) e métricas sintéticas automatizadas.
- TruLens implementa funções de feedback contínuo com instrumentação em tempo real para custo, latência e aderência lógica.
- Modelos juízes calibrados com temperatura zero auditam grandes volumes de consultas sem intervenção manual exaustiva.
- A integração dessas métricas em esteiras de integração contínua (CI/CD) impede o envio de alterações que degradem respostas.
Por que sistemas RAG exigem métricas quantitativas de avaliação
A arquitetura RAG consolidou-se como o padrão técnico para alimentar assistentes virtuais com dados proprietários de empresas, evitando o re-treinamento constante de pesos. No entanto, quando um usuário relata uma resposta incorreta, identificar a origem do erro em um fluxo complexo pode demandar horas de depuração manual.
Uma resposta insatisfatória pode ser provocada por causas distintas: o banco vetorial não encontrou os trechos pertinentes, o algoritmo de recuperação trouxe fragmentos com excesso de ruído, o modelo de linguagem ignorou os dados e inventou informações, ou o comando original foi ambíguo. Sem instrumentação detalhada, testes pontuais não oferecem garantias para a produção.
Ao estruturar um projeto com orquestradores modernos como LangChain, a manutenção de um pipeline confiável exige monitoramento contínuo. Em nosso guia prático de RAG com bancos vetoriais, detalhamos como a seleção de estratégias de fragmentação (chunking) e funções de distância geométrica determina a assertividade da busca por similaridade.
A tríade RAG e as métricas essenciais de qualidade
Para decompor o comportamento de uma aplicação RAG, a indústria estabeleceu o conceito da tríade de avaliação. Esse modelo avalia separadamente a relação entre pergunta, contexto recuperado e resposta final.
1. Fidelidade (Faithfulness ou Groundedness)
A fidelidade avalia se todas as afirmações contidas na resposta gerada podem ser inferidas diretamente a partir do contexto fornecido pelo recuperador. O framework decompõe a resposta em sentenças atômicas. Em seguida, um modelo juiz analisa cada afirmação contra os chunks recuperados, atribuindo nota 1 se a sentença for suportada pelas fontes e 0 se for inferência externa. O índice de fidelidade é a proporção de sentenças fundamentadas sobre o total de afirmações, servindo como a principal métrica contra alucinações factuais.
2. Relevância da resposta (Answer Relevance)
A relevância da resposta quantifica o quanto a resposta atende à dúvida manifestada pelo usuário, penalizando rodeios ou explicações supérfluas. A resposta gerada é submetida a um modelo para formular retroativamente perguntas hipotéticas. Em seguida, calcula-se a similaridade de cosseno entre o vetor de embedding da pergunta original e os vetores das perguntas simuladas. Pontuações elevadas indicam que a resposta permaneceu estritamente focada no objetivo inicial.
3. Relevância e precisão do contexto (Context Relevance e Context Precision)
Essa dimensão avalia a qualidade do estágio de busca. A precisão do contexto verifica se os fragmentos recuperados no banco relacional ou vetorial, como uma tabela indexada no Supabase com pgvector, contêm apenas as informações indispensáveis para formular a resposta, recompensando pipelines que posicionam os trechos mais importantes nas primeiras posições do ranking.
4. Cobertura de contexto (Context Recall)
Quando existe um conjunto de dados de referência com respostas ideais (ground truth) elaboradas por especialistas, o Context Recall mede se todos os fatos necessários presentes no gabarito foram devidamente resgatados pelos mecanismos de busca vetorial e textual.
Ragas e TruLens: comparação técnica dos dois principais frameworks
Dois ecossistemas de código aberto destacam-se na automação dessas medições em ambientes corporativos: Ragas e TruLens. Embora compartilhem objetivos complementares, cada ferramenta adota premissas arquiteturais próprias.
O framework Ragas (Retrieval Augmented Generation Assessment) é desenhado para avaliação orientada a conjuntos de dados. Ele permite criar dados sintéticos de teste a partir dos próprios documentos da empresa, gerando pares de perguntas e respostas com variados graus de dificuldade para exercitar o sistema. O Ragas é amplamente utilizado em suítes de teste de regressão antes de cada atualização de software.
Por outro lado, o TruLens adota uma abordagem centrada em telemetria e observabilidade operacional em tempo real. Ele se conecta aos componentes do aplicativo por meio de wrappers (como TruChain ou TruCustom) e registra cada chamada a LLMs e bancos vetoriais, mensurando custo em dólares, latência de execução e funções de feedback personalizadas via painel visual interativo.
Ambos os ecossistemas oferecem suporte nativo a frameworks de indexação e recuperação como o LlamaIndex, facilitando a instrumentação de motores de busca híbrida e nós de documentos complexos.
| Característica | Ragas | TruLens |
|---|---|---|
| Foco primário | Avaliação em lote e testes de regressão | Observabilidade e telemetria contínua |
| Geração de dados sintéticos | Nativa a partir de documentos | Dependente de fluxos externos |
| Visualização de métricas | DataFrames, relatórios e exportação CI/CD | Dashboard local interativo (TruLens UI) |
| Rastreamento de custos e latência | Básico / focado em métricas de qualidade | Detalhado por chamada e por sessão |
| Integrações principais | LangChain, LlamaIndex, Hugging Face | LangChain, LlamaIndex, APIs personalizadas |
Quando avaliar com RAG versus quando optar por Fine-Tuning
A escolha entre aprimorar um fluxo de recuperação ou treinar novos pesos de um modelo depende dos gargalos detectados pelas ferramentas de medição. No artigo sobre fine-tuning ou RAG e quando treinar um modelo, abordamos os custos e limites de cada abordagem.
Quando as métricas do Ragas apontam que o contexto recuperado contém todas as respostas necessárias (alto Context Recall), mas o índice de fidelidade permanece baixo devido a alucinações sistemáticas, o problema costuma ser o modelo de linguagem gerador, que pode requerer um prompt mais restritivo ou um modelo com maior capacidade analítica.
Por outro lado, se a aplicação exige que o modelo adote linguagem estritamente padronizada ou memorize gramática interna sem enviar milhares de tokens de contexto a cada requisição, o fine-tuning apresenta-se como alternativa viável. Para a maioria das bases corporativas em constante atualização, contudo, manter um RAG calibrado com monitoramento contínuo de fidelidade é mais barato e gerenciável.
Exemplo: avaliação de RAG em uma cooperativa de crédito em Ribeirão Preto
Para visualizar a aplicação prática dessa infraestrutura, considere o caso de uma cooperativa de crédito sediada na cidade de Ribeirão Preto, polo do agronegócio paulista. A instituição disponibiliza crédito rural para produtores de cana-de-açúcar, soja e café em mais de vinte cidades da região.
Com manuais de crédito agrícola, resoluções do Banco Central e diretrizes do Programa Nacional de Fortalecimento da Agricultura Familiar (Pronaf) atualizadas a cada safra, os gerentes de conta enfrentavam lentidão para conferir exigências documentais e limites de financiamento.
A equipe de tecnologia desenvolveu um assistente interno de busca semântica baseado em LangChain e PostgreSQL com extensão pgvector. Nos primeiros testes internos, os gerentes elogiaram a rapidez, mas logo notaram inconsistências: em consultas sobre carência de juros para custeio agrícola, o assistente fornecia prazos que não constavam nas circulares oficiais.
Para sanar o problema com rigor técnico, a cooperativa montou uma suíte de avaliação com Ragas contendo 80 cenários de consulta elaborados junto aos analistas seniores de crédito. A auditoria automatizada revelou o motivo exato das falhas: o índice de fidelidade estava em 0,71 e a precisão de contexto em apenas 0,64.
Ao inspecionar os registros de telemetria, os engenheiros constataram que a fragmentação original de 256 tokens dividia tabelas de taxas de juros no meio, separando condições financeiras dos prazos de carência correspondentes. O recuperador trazia apenas metade da tabela e o modelo preenchia a lacuna deduzindo valores genéricos.
A cooperativa reestruturou a indexação, adotando janelas de 600 tokens com preservação de blocos tabulares em Markdown e busca híbrida combinando BM25 com vetores densos. A nova rodada da suíte de testes no Ragas demonstrou salto imediato: a precisão de contexto subiu para 0,91 e o índice de fidelidade atingiu 0,97. O ajuste evitou a concessão indevida de prazos de financiamento que poderiam acarretar penalidades em auditorias do Banco Central.
Como estruturar um pipeline de avaliação contínua em CI/CD
Implementar a avaliação de RAG como parte do ciclo de desenvolvimento previne surpresas desagradáveis antes de enviar novas versões para os usuários finais. Essa arquitetura operacional organiza-se nas seguintes etapas:
1. Repositório do conjunto de validação: mantenha no repositório de código um arquivo de teste versionado (JSON ou CSV) com perguntas representativas, contextos de referência e respostas validadas por especialistas de negócio.
2. Execução automatizada de testes (GitHub Actions ou GitLab CI): crie um fluxo de trabalho que, a cada pull request envolvendo alterações em prompts, parâmetros de chunking ou versões de modelos, execute automaticamente uma rotina de teste utilizando a biblioteca Ragas ou TruLens.
3. Critérios de bloqueio de deploy (Quality Gates): defina limiares mínimos para aprovação do código. Exija, por exemplo, que o score de fidelidade permaneça acima de 0,90 e a precisão de contexto acima de 0,85. Caso uma alteração de prompt reduza esses valores, o pipeline falha e bloqueia a integração até que a divergência seja corrigida.
4. Gerenciamento de custos de avaliação: como a execução de modelos juízes gera consumo de tokens de API, utilize modelos menores e rápidos para testes rápidos em branches de trabalho e reserve modelos de fronteira com raciocínio apurado para a validação final antes da publicação em produção.
Erros comuns
Ao implementar fluxos de medição de qualidade em sistemas de busca e geração aumentada, evite os seguintes equívocos comuns:
- Avaliar apenas a resposta final sem auditar a recuperação: analisar somente o texto gerado oculta a causa raiz de respostas ruins, impedindo saber se o erro veio da busca vetorial ou do raciocínio do modelo.
- Utilizar temperatura diferente de zero no modelo avaliador: modelos juízes devem operar com temperatura nula e instruções determinísticas para garantir consistência e reprodutibilidade nas notas atribuídas.
- Trabalhar sem um conjunto de referência aprovado por humanos: confiar exclusivamente em perguntas geradas automaticamente sem conferência periódica de especialistas de domínio cria métricas descoladas da prática comercial.
- Ignorar latência e custo financeiro dos testes contínuos: rodar centenas de avaliações profundas a cada commit simples pode tornar a esteira de desenvolvimento lenta e financeiramente inviável sem controle de cache.
- Não registrar as consultas reais dos usuários em produção: deixar de alimentar a base de testes com as dúvidas e frustrações reais dos clientes impede a melhoria contínua da base de conhecimento da empresa.
Perguntas frequentes
O que é a tríade RAG e por que ela é indispensável?
A tríade RAG avalia a interação entre pergunta, contexto recuperado e resposta final por meio de três pilares: relevância do contexto, fidelidade da resposta (ausência de alucinações) e relevância da resposta para o usuário. Ela identifica com precisão qual componente do pipeline gerou o erro.
Como o Ragas calcula a métrica de fidelidade (Faithfulness)?
O framework quebra a resposta gerada em afirmações atômicas e submete cada uma delas a um modelo juiz para checar se a informação está suportada pelo contexto dos documentos. A nota final é a proporção de afirmações sustentadas pelas fontes sobre o total de frases geradas.
É necessário ter respostas ideais (ground truth) para usar o TruLens?
Não. Tanto o TruLens quanto o Ragas oferecem métricas que operam sem gabarito prévio, avaliando a coerência interna entre pergunta, chunks recuperados e resposta por meio de embeddings e modelos de linguagem como juízes neutros.
Qual é a diferença de propósito entre Ragas e TruLens?
O Ragas foca principalmente em testes em lote e criação de datasets sintéticos para validação de código em esteiras de teste. O TruLens prioriza a instrumentação contínua da aplicação em tempo de execução com monitoramento de custo, latência e feedback visual.
Qual modelo deve ser escolhido como juiz (LLM-as-a-judge)?
Recomenda-se utilizar modelos com alta capacidade de seguimento de instruções lógicas e baixa taxa de alucinação, configurados com temperatura zero. Modelos de grande porte garantem notas mais consistentes e alinhadas ao julgamento humano.
