Melhores ferramentas de avaliação de RAG em 2026: Ragas, DeepEval, TruLens

Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Uma única pontuação não consegue explicar se um sistema de geração aumentada por recuperação (RAG) funciona. Pode falhar ao analisar documentos, dividi-los em chunks, recuperar ou fazer reranking das evidências, gerar uma resposta, associar citações ou aplicar filtros. Meça cada fase separadamente, para que uma regressão aponte para uma parte específica do pipeline.

Comece com métricas de retrieval num pequeno dataset anotado. Adicione Ragas para métricas RAG standard, DeepEval para verificações de CI e TruLens quando precisar de feedback associado a execuções individuais. Use LangSmith se os seus traces e datasets já estiverem lá. Escreva métricas personalizadas para falhas específicas do produto.

Última revisão: 2026-08-10. O ranking privilegia a cobertura das fases, verificações determinísticas, calibração do judge, integração com CI, suporte para traces e o custo de manutenção dos dados de avaliação.

Tabela de decisão

NecessidadeMelhor ponto de partidaMotivo
Verificações económicas de regressão do retrievalMétricas locaisRecall@k, MRR, nDCG, exclusão incorreta por filtros e suporte de citações podem ser determinísticos.
Métricas de qualidade RAG sem referênciaRagasDisponibiliza context precision, context recall, response relevancy, faithfulness e métricas relacionadas.
Gates de CI para aplicações com LLMsDeepEvalA interface baseada em casos de teste funciona bem quando as avaliações devem fazer falhar um PR ou deployment.
Feedback explicável sobre a aplicaçãoTruLensA tríade RAG separa a relevância do contexto, a groundedness e a relevância da resposta.
Avaliações de produto centradas em tracesLangSmithDatasets, evaluators, anotações, traces e fluxos de regressão coexistem no mesmo local.
Qualidade específica do domínioAvaliações personalizadasAs métricas genéricas raramente conhecem a sua ontologia, filtros, política de citações, restrições do parser ou regras de recusa.

Métricas por fase do pipeline

FasePrimeiras métricas a adicionarMotivo
Parsingcompletude da extração, preservação de tabelas, cobertura de páginasUma ingestão incorreta torna todas as métricas posteriores enganadoras.
Chunkingcapacidade de resposta do chunk, perda de fronteiras, taxa de duplicaçãoO retriever não consegue recuperar factos divididos por fronteiras incorretas.
RetrievalRecall@k, MRR, nDCG@k, context precision, context recallPermite detetar evidências em falta antes de o generator ocultar o problema.
RerankingPrecision@1, variação do nDCG, uplift do reranker, variação da latênciaOs rerankers devem melhorar suficientemente a ordenação para justificar a latência.
Generationfaithfulness, groundedness, relevância da respostaMedem se a resposta utilizou o contexto recuperado.
Citaçõescobertura de claims, suporte das citações, taxa de claims sem suporteUma resposta grounded sem citações úteis pode, ainda assim, falhar no produto.
Produçãotaxa de fallback, taxa de correção, latência p95, custo por respostaA qualidade offline fica incompleta sem telemetria operacional.

Notas sobre as ferramentas

Ragas é a forma mais simples de obter um vocabulário comum para avaliação de RAG. É útil quando uma equipa precisa rapidamente de context precision, context recall, faithfulness e relevância da resposta. O principal cuidado é a calibração: as métricas baseadas em LLM-as-a-judge podem parecer precisas, embora ocultem os prompts do judge, os exemplos, a escolha do modelo e os custos.

DeepEval adapta-se a fluxos de engenharia em que a avaliação deve comportar-se como testes. É útil para verificações de regressão em CI, sobretudo em torno de casos de falha conhecidos. O cuidado é que as avaliações no estilo de testes só são tão boas quanto os casos que mantém.

TruLens funciona bem quando pretende associar feedback a registos da aplicação. A tríade RAG é útil porque mantém separadas a relevância do contexto, a groundedness e a relevância da resposta, em vez de as comprimir numa única métrica opaca.

LangSmith é uma opção prática quando os seus traces, runs, datasets e fluxo de revisão já estão no ecossistema LangChain/LangGraph. É menos atrativo se quiser um harness de avaliação local e independente de frameworks.

As avaliações personalizadas não são opcionais em produção. Se o seu sistema RAG filtrar documentos por permissões, jurisdição, data, linha de produto ou ontologia, meça diretamente as exclusões incorretas e os erros de política.

Uma primeira stack razoável

  1. Crie um golden set que cubra slices de queries importantes e os IDs das fontes esperadas. Algumas dezenas de casos podem revelar regressões iniciais; expanda-o até que os intervalos de confiança e a cobertura das falhas sustentem a decisão de release.
  2. Acompanhe localmente as métricas determinísticas de retrieval antes de adicionar LLM judges.
  3. Adicione uma métrica de groundedness ou faithfulness de Ragas ou TruLens.
  4. Adicione verificações DeepEval para os casos de falha que nunca podem regredir.
  5. Armazene traces e amostras de revisão humana em LangSmith, OpenTelemetry ou nas suas próprias tabelas.
  6. Adicione métricas personalizadas para filtros, citações, qualidade do parser e comportamento de recusa.

Um erro comum

Muitas equipas medem a faithfulness e ficam por aí. A faithfulness coloca uma questão específica: a resposta está de acordo com o contexto recuperado? Não consegue dizer se o retriever encontrou a fonte certa. Também não deteta tabelas perdidas, filtros de permissões incorretos nem citações que apontam para a passagem errada.

Leitura adicional

Referências