Avaliando a Geração Aumentada por Recuperação (RAG): Tudo o que Você Deve Saber
Introdução
Retrieval Augmented Generation (RAG) tornou-se uma abordagem amplamente adotada para implementar aplicações de IA generativa impulsionadas por Large Language Models (LLMs). Ao integrar fontes externas de conhecimento, o RAG aprimora a capacidade do modelo de fornecer respostas mais precisas e contextualmente relevantes a consultas específicas. Apesar de seu potencial, as respostas geradas por RAG nem sempre são totalmente precisas ou consistentes com o conhecimento recuperado.
Em um webinar recente, Stefan Webb, Developer Advocate na Zilliz, explorou estratégias de avaliação para aplicações RAG, concentrando-se em métodos para avaliar o desempenho de LLMs e abordando desafios e limitações atuais no campo.
Neste blog, recapitularemos os principais insights de Stefan, incluindo uma visão geral de várias arquiteturas de pipeline RAG, frameworks de recuperação e avaliação, e exemplos de vieses e falhas em LLMs.
Arquitetura RAG
Stefan iniciou a palestra introduzindo o conceito fundamental de busca semântica, um componente crítico das aplicações RAG. A busca semântica aproveita bancos de dados vetoriais, como Milvus ou Zilliz, como sistemas de armazenamento de base de conhecimento para embeddings vetoriais. Esses bancos de dados permitem buscas eficientes em dados não estruturados para recuperar contextos semanticamente semelhantes relevantes à consulta de um usuário. Essa capacidade forma a espinha dorsal dos sistemas RAG, garantindo que o conhecimento recuperado esteja estreitamente alinhado com a pergunta de entrada, aprimorando assim a qualidade das respostas geradas.
A Figura 1 abaixo ilustra uma arquitetura RAG básica e ingênua. Nessa configuração, o sistema recupera os documentos mais relevantes com base em sua similaridade semântica com a pergunta do usuário. As informações recuperadas são então formatadas em um prompt estruturado, completo com instruções, e passadas para o LLM. O modelo usa esse contexto para gerar uma resposta bem informada.
Figura 1: RAG ingênuo
Figura 1: RAG ingênuo
Embora o pipeline RAG básico possa recuperar documentos relevantes e gerar respostas, seu desempenho nem sempre é ideal. Algumas saídas podem carecer de precisão ou relevância. Para enfrentar esses desafios, uma abordagem modular para construir o pipeline RAG permite melhorias incrementais em cada etapa.
Abaixo (como ilustrado na Figura 2) estão técnicas-chave que podem aumentar a eficácia do pipeline.
Figura 2: Arquitetura Modular RAG
Figura 2: Arquitetura Modular RAG (Fonte)
Tradução de Consulta
Esta etapa concentra-se em garantir que a consulta do usuário seja devidamente compreendida pelo sistema. Ela traduz consultas para um formato ou representação que se alinha ao mecanismo de recuperação subjacente.
Multi-query: Divide a consulta principal em várias subconsultas focadas para recuperar informações diversas, mas relevantes.
Step-back: Revisa etapas anteriores no pipeline quando resultados insuficientes são encontrados, refinando a consulta para uma melhor recuperação.
Fusão RAG: Mescla resultados de múltiplas consultas para fornecer um contexto coeso e abrangente para o LLM.
Documentos Hipotéticos (HyDE): Envolve a geração de documentos sintéticos ou contextos hipotéticos que podem ajudar a recuperar documentos semanticamente semelhantes da base de conhecimento, melhorando a recuperação para consultas abstratas ou mal formuladas.
Roteamento de Consultas
A abordagem de Roteamento de Consultas direciona a consulta para o mecanismo de recuperação ou fonte de conhecimento mais adequado.
Roteamento Lógico: Roteia consultas com base em regras predefinidas ou operadores lógicos, como filtragem por metadados ou domínio.
Roteamento Semântico: Direciona consultas com base em suas características semânticas para o banco de dados ou sistema mais adequado para lidar com elas.
Construção de Consultas
A Construção de Consultas refina como as consultas são formuladas para corresponder à estrutura dos bancos de dados subjacentes.
BD Relacional: Constrói consultas semelhantes a SQL para bancos de dados relacionais tradicionais.
BD de Grafos: Usa consultas Cypher de travessia de grafos para explorar nós e relacionamentos em bancos de dados de grafos.
BD Vetorial: Aproveita embeddings para criar consultas vetorizadas para buscas por similaridade semântica.
Indexação
A indexação melhora a organização e a acessibilidade da base de conhecimento.
Otimização de Chunks: Divide documentos em chunks significativos e recuperáveis, preservando o contexto.
Indexação de Múltiplas Representações: Cria múltiplas representações (por exemplo, semântica, sintática) dos dados para diversas necessidades de recuperação.
Embeddings Especializados: Usa embeddings específicos de domínio para aprimorar a recuperação de informações altamente especializadas ou técnicas.
Indexação Hierárquica: Estrutura o índice hierarquicamente para buscas mais rápidas e precisas.
Recuperação
Recupera os documentos ou contextos mais relevantes para uma determinada consulta usando técnicas avançadas.
Ranquemento: Atribui pontuações aos documentos recuperados com base na relevância, garantindo que as melhores correspondências sejam priorizadas.
RAG Corretivo: Ajusta o ranqueamento com base em feedback ou critérios adicionais para melhorar os resultados dinamicamente.
Re-recuperação: Recupera documentos iterativamente se os resultados iniciais não atenderem às expectativas de qualidade, refinando o processo até que um resultado aceitável seja encontrado.
Essa abordagem modular para construir um pipeline RAG ajusta cada componente de forma independente. Ao abordar desafios específicos em cada etapa, o pipeline se torna mais robusto, preciso e adaptável, aprimorando, em última análise, a qualidade das saídas geradas.
Avaliação de Modelos de Fundação
Seja usada uma abordagem RAG ingênua ou avançada, avaliar o desempenho de cada aplicação RAG é essencial. Essa avaliação ajuda a identificar pontos fortes e fracos, garantindo a confiabilidade e a relevância do sistema. Todos os LLMs, independentemente da sofisticação, exigem avaliação rigorosa de desempenho para abordar possíveis limitações, vieses e imprecisões.
Avaliação de Desempenho
Mas como medimos e avaliamos o desempenho do modelo? Medir o desempenho de uma aplicação RAG requer uma abordagem com nuances, pois diferentes aspectos do pipeline precisam ser avaliados. Abaixo estão as principais considerações e métodos para uma medição eficaz de desempenho:
Avaliação em uma Tarefa vs. Avaliação em Si Mesmo
Avaliação de Tarefa: Mede o desempenho do modelo em um conjunto predefinido de tarefas, que frequentemente incluem cenários de múltiplas interações (por exemplo, MT-Bench) ou multitarefa (por exemplo, MMLU). Cada tarefa está associada a perguntas de verdade fundamental específicas e respostas de referência.
Autoavaliação: Concentra-se em métricas internas de desempenho, como a eficácia com que o modelo recupera e processa informações sem necessariamente vinculá-las a um caso de uso prático. Isso é útil para diagnosticar o desempenho do pipeline.
Comparação de Respostas com a Verdade Fundamental vs. Contexto
Comparação com a Verdade Fundamental: Avalia o quão próxima a resposta gerada está de uma resposta predefinida e precisa (verdade fundamental). Essa abordagem funciona bem para tarefas objetivas, como consultas baseadas em fatos.
Comparação Contextual: Examina o quão bem a resposta se alinha ao contexto fornecido por documentos recuperados. Isso é particularmente importante para tarefas em que a verdade fundamental não está disponível ou é subjetiva, enfatizando coerência e relevância.
Avaliação da Recuperação vs. Avaliação da Saída do LLM
Avaliação da Recuperação: Concentra-se na qualidade dos documentos recuperados pelo pipeline. As métricas podem incluir recall e precisão entre os documentos recuperados e a consulta.
Avaliação da Saída do LLM: Examina a qualidade da saída final gerada pelo modelo de linguagem, considerando fatores como consistência factual e relevância para a consulta e o contexto recuperado.
Avaliação Humana como o “Padrão-Ouro”
- A avaliação humana continua sendo o método mais confiável para avaliar o desempenho, especialmente para tarefas subjetivas ou complexas. Humanos podem avaliar aspectos sutis, como consistência lógica, tom e criatividade. No entanto, essa abordagem não escala bem devido aos seus requisitos de tempo e recursos.
Uso de LLMs para Avaliar LLMs (LLM-as-a-Judge)
- LLMs mais avançados e eficientes (LLM-as-a-Judge) podem ser empregados para avaliar as saídas de outros LLMs, particularmente quando a verdade fundamental não está disponível. Esses modelos podem pontuar respostas com base em critérios predefinidos, como relevância e correção, oferecendo uma alternativa escalável à avaliação humana. No entanto, é preciso ter cuidado para evitar a introdução de vieses do próprio modelo avaliador.
Stefan continuou a discussão abordando duas abordagens de avaliação: avaliação baseada em tarefas e autoavaliação. A avaliação baseada em tarefas normalmente se apoia em benchmarks disponíveis publicamente, enquanto a autoavaliação se concentra mais em medidas internas ou introspecção, como examinar a qualidade das respostas geradas e a relevância das informações recuperadas.
Avaliação Baseada em Tarefas: A Abordagem de Benchmark
A avaliação baseada em tarefas se baseia no uso de benchmarks padrão, disponíveis publicamente, que avaliam o desempenho do modelo em uma variedade de tarefas. Esses benchmarks frequentemente abrangem diferentes domínios do conhecimento, capacidades de resposta a perguntas e habilidades conversacionais. Alguns exemplos incluem:
Benchmarks baseados em conhecimento: Esses benchmarks se concentram em conhecimento geral e respostas a perguntas baseadas em fatos.
MMLU: Um benchmark diversificado que testa modelos de linguagem em vários domínios, incluindo matemática, ciência e história.
HellaSwag: Um benchmark projetado para medir raciocínio de senso comum.
ARC: Um benchmark focado em respostas a perguntas com capacidades de raciocínio.
Benchmarks de Seguimento de Instruções: Esses benchmarks avaliam a capacidade do modelo de seguir instruções e gerar respostas relevantes.
Flan: Uma série de tarefas que avaliam habilidades de seguimento de instruções em LLMs.
Self-instruct: Avalia a capacidade do modelo de gerar e seguir instruções autogeradas.
NaturalInstructions: Um benchmark em larga escala focado na capacidade do modelo de seguir instruções em linguagem natural.
Benchmarks Conversacionais: Esses benchmarks avaliam a capacidade do modelo de se envolver em diálogos coerentes e relevantes.
CoQA: Um conjunto de dados de perguntas e respostas conversacionais que testa modelos em diálogos de múltiplos turnos.
MMDialog: Um benchmark conversacional que se concentra na qualidade do diálogo em vários cenários.
OpenAssistant: Um benchmark de IA conversacional que avalia a capacidade do modelo de manter conversas naturais.
Embora os benchmarks forneçam critérios de avaliação padronizados, eles muitas vezes não conseguem capturar as nuances da interação humana, como inteligência emocional, fluxo conversacional e sensibilidade ao contexto. Por exemplo, uma resposta pode estar factualmente correta de acordo com um benchmark, mas ainda assim ficar aquém em termos de naturalidade ou empatia, elementos-chave que os humanos valorizam em conversas do mundo real. Além disso, os benchmarks nem sempre refletem a complexidade das preferências humanas, que podem variar com base no contexto, na intenção do usuário e no tom emocional. É por isso que a avaliação humana continua sendo um "padrão-ouro" na avaliação de IA conversacional, pois leva em conta preferências humanas que os benchmarks muitas vezes ignoram. No entanto, devido ao custo e à natureza intensiva em recursos da avaliação humana, métodos alternativos, como a avaliação baseada em introspecção, podem ser considerados opções mais escaláveis.
Avaliação baseada em introspecção
A avaliação baseada em introspecção concentra-se em avaliar a qualidade das respostas geradas pelo modelo e seu alinhamento com o contexto, com o objetivo de medir quão bem as saídas do modelo aderem às expectativas definidas pela entrada. Esse tipo de avaliação pode ser dividido em duas categorias principais: Avaliação baseada em geração e Avaliação baseada em recuperação. Abaixo estão alguns exemplos de métricas relevantes:
Avaliação baseada em geração
Fidelidade (Fundamentação): Esta métrica mede a consistência factual da resposta gerada em relação ao contexto fornecido. Se o modelo gerar afirmações que não podem ser sustentadas pelo contexto recuperado, essas afirmações são penalizadas. A fidelidade garante que a saída do modelo seja consistente e fundamentada nas informações fornecidas.
Relevância da resposta: Esta métrica avalia quão bem a resposta aborda diretamente a pergunta do usuário ou o contexto fornecido. Uma resposta altamente relevante será tanto precisa quanto contextualmente apropriada, fornecendo a resposta mais útil para a consulta.
Avaliação baseada em recuperação
Relevância do contexto: Mede quão relevantes os documentos ou contextos recuperados são para a consulta. Idealmente, o contexto recuperado deve conter apenas as informações necessárias para responder à pergunta. Informações irrelevantes ou supérfluas podem reduzir a qualidade da resposta gerada.
Recall do contexto: Esta métrica avalia quão bem o contexto recuperado se alinha com a verdade de referência, frequentemente usando respostas anotadas como referência. Ela ajuda a avaliar se os documentos relevantes foram recuperados em primeiro lugar, garantindo que o modelo tenha informações suficientes para gerar uma resposta significativa.
Para as métricas de Fidelidade, Relevância da resposta e Relevância do contexto, a falta de verdade de referência apresenta um desafio para a avaliação direta. No entanto, na ausência de verdade de referência, um método alternativo é empregar um LLM-como-Juiz. Um LLM forte pode ser usado para pontuar esses aspectos analisando a coerência, relevância e fundamentação factual da resposta. Ao comparar as respostas geradas com sua própria compreensão de contexto e relevância, o modelo pode fornecer uma avaliação automatizada.
Desafios e limitações do LLM-como-Juiz
Embora usar um LLM-como-Juiz possa ser uma alternativa útil para avaliar métricas quando a verdade de referência não está disponível, essa abordagem introduz certos desafios e limitações, que devem ser abordados. O próprio modelo avaliador pode introduzir vieses, o que pode afetar a qualidade e a justiça da avaliação. Abaixo estão alguns vieses e desafios comuns que devem ser considerados.
Viés de posição
Viés de posição refere-se à tendência do modelo avaliador de favorecer respostas com base em sua posição no ranking ou na ordem em que aparecem. Em muitos casos, o modelo pode assumir que a primeira resposta ou a resposta mais bem classificada é mais relevante ou precisa, independentemente de sua qualidade real. Isso pode levar a avaliações imprecisas, especialmente em casos em que a resposta correta é classificada em uma posição inferior devido ao viés do modelo em favor das posições mais altas no ranking.
Figura 3: Viés de Posição
Figura 3: Viés de Posição (Fonte)
Viés de Verbosidade
O viés de verbosidade ocorre quando o modelo avaliador tende a favorecer respostas mais longas e detalhadas, mesmo que elas não sejam necessariamente mais precisas ou relevantes. Em alguns casos, o modelo pode equiparar incorretamente verbosidade com qualidade, atribuindo pontuações mais altas a respostas mais longas que contêm informações desnecessárias. Isso pode distorcer o processo de avaliação, especialmente em contextos em que respostas concisas e claras são mais desejáveis.
Figura 4: Viés de Verbosidade
Figura 4: Viés de Verbosidade (Fonte)
Julgamento Incorreto
Outra limitação é a possibilidade de julgamentos incorretos. Um LLM-as-a-Judge, como qualquer modelo, pode cometer erros ao avaliar a qualidade ou relevância de uma resposta. Por exemplo, ele pode interpretar mal o contexto, ignorar detalhes sutis ou deixar de reconhecer nuances na resposta, levando a resultados de avaliação incorretos ou enganosos
Figura 5: Julgamento Incorreto
Figura 5: Julgamento Incorreto (Fonte)
Julgamento Incorreto com Chain-of-Thought
O raciocínio Chain-of-Thought (CoT) na avaliação baseada em LLM introduz mecanismos complexos de propagação de erros que podem comprometer significativamente a precisão da avaliação. Cada etapa intermediária de raciocínio atua como um ponto potencial de falha, em que até mesmo uma pequena interpretação equivocada ou inconsistência lógica pode se transformar em erros cada vez mais substanciais no julgamento final. Por exemplo, se uma etapa inicial na cadeia de raciocínio interpretar mal uma nuance contextual importante ou ponderar incorretamente um aspecto específico da resposta, as etapas subsequentes de raciocínio serão construídas sobre essa base falha, amplificando exponencialmente o erro inicial.
Figura 6: Julgamento Incorreto com Chain-of-thought
Figura 6: Julgamento Incorreto com Chain-of-thought (Fonte)
Esses vieses destacam a importância de adotar estratégias de avaliação que abordem as limitações das abordagens LLM-as-a-Judge. Uma solução é usar modelos LLM especificamente ajustados para fins de avaliação, como GroundedAI, ou Flow-Judge-v0.1. Outra estratégia é combinar avaliações LLM-as-a-Judge com avaliações humanas sempre que possível. Avaliadores humanos trazem compreensão nuanceada e consciência contextual que modelos automatizados podem não ter. Auditorias regulares e melhorias iterativas nos modelos avaliadores também são essenciais para minimizar vieses e aumentar a confiabilidade.
Frameworks de Avaliação Open-Source
Além das técnicas LLM-as-a-Judge, vários frameworks de avaliação open-source são amplamente usados no mercado para avaliar aplicações RAG. Esses frameworks fornecem metodologias e ferramentas estruturadas para avaliar efetivamente o desempenho de recuperação e geração:
RAGAS: Um framework para avaliar sistemas RAG com métricas adaptadas a aplicações RAG.
DeepEval: Uma ferramenta flexível e robusta para avaliar sistemas RAG ou de ajuste fino em múltiplas métricas de avaliação.
ARES: Projetado para avaliação de modelos RAG, enfatizando relevância do contexto, fidelidade da resposta e relevância da resposta.
HuggingFace Lighteval: Fornece ferramentas leves e extensíveis para avaliar aplicações RAG em vários backends (por exemplo, transformers, tgi, vllm ou nanotron).
Esses frameworks simplificam o processo de avaliação e ajudam a padronizar métricas de desempenho entre diferentes sistemas, promovendo comparabilidade e melhoria.
Conclusão
Geração Aumentada por Recuperação (RAG) é uma abordagem transformadora para aprimorar as capacidades dos Grandes Modelos de Linguagem (LLMs). No entanto, seu sucesso depende de uma avaliação robusta e de refinamento contínuo. Como Stefan destacou no webinar, o pipeline de RAG é complexo, abrangendo múltiplas etapas, da tradução de consultas à geração da resposta final. Os desafios são significativos—variando desde mitigar vieses em avaliações LLM-as-a-Judge até garantir recuperação precisa e gerar respostas que atendam às expectativas dos usuários.
A principal conclusão é que não existe uma solução única para avaliação de RAG. Alcançar o sucesso requer uma abordagem sutil e multifacetada que combine diversas técnicas de avaliação: benchmarks baseados em tarefas, métricas introspectivas, frameworks de avaliação de código aberto e—quando viável—avaliação humana. Ferramentas como RAGAS, DeepEval e ARES oferecem suporte valioso, mas não são respostas definitivas. Em vez disso, representam ferramentas em evolução no cenário em constante avanço da IA generativa.
Olhando para o futuro, o futuro do RAG está em sua adaptabilidade e refinamento contínuo. À medida que os sistemas de IA se tornam mais sofisticados, a capacidade de avaliar e aprimorar seu desempenho será essencial para desbloquear todo o seu potencial. Ao abordar as limitações atuais e adotar métodos inovadores de avaliação, as aplicações RAG podem entregar consistentemente informações precisas, contextualmente relevantes e confiáveis, impulsionando o progresso no campo da IA.
Leitura adicional
Continue lendo
3 Easiest Ways to Use Claude Code on Your Mobile Phone
Run Claude Code from your phone with Remote Control, Happy Coder, or SSH + Tailscale. Comparison table, setup steps, and tools for typing, memory, and parallel tasks.
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.