RAG melhora as respostas dos LLM ao fundamentá-las em dados externos, em vez de apenas no que o modelo memorizou no treinamento. Nós avaliamos os componentes de um sistema RAG e reunimos os resultados em um só lugar, com um guia prático para escolher cada parte da pilha.
Veja nossos resultados de benchmark para cada componente RAG, nosso guia para escolher uma pilha RAG, ou os fundamentos do RAG: o que é, como funciona e onde se encaixa.
Resultados de benchmark RAG
Modelos de embedding
O modelo de embedding converte tanto os seus documentos quanto a consulta do usuário em vetores, estabelecendo assim o limite máximo da qualidade de recuperação.
Avaliamos 15 modelos de embedding densos, além de uma linha de base lexical BM25, em três domínios (contratos legais/CUAD, suporte ao cliente/TechQA e saúde/MedRAG), pontuando cada um em nDCG@3.
O voyage-3.5 ocupa o primeiro lugar com 0.9429 e supera o próprio carro-chefe voyage-4-large da Voyage, custando metade do preço ($0.060 contra $0.120 por 1M de tokens). O modelo mais novo e maior não é automaticamente a melhor compra. Para pilhas que priorizam o custo, o pplx-embed-v1-0.6b da perplexity oferece cerca de 92% da qualidade do voyage-3.5 (0.8604) por aproximadamente um quinze avos do preço ($0.004/1M). Para uma visão da relação precisão versus preço, consulte o gráfico de custos no benchmark completo de modelos de embedding, que também inclui a divisão por domínio e a metodologia.
Além dos embeddings densos de vetor único, os recuperadores de interação tardia (multi-vetor), como o ColBERT (e ColPali/ColQwen para recuperação de documentos visuais e PDFs), mantêm um vetor por token para um casamento mais refinado e uma generalização mais forte para fora do domínio, com um índice muito maior (o ColPali armazena aproximadamente 1.000× mais vetores por item; veja nosso benchmark de embedding multimodal).
Se o seu corpus for multilíngue ou visual, a escolha do embedding muda: nosso benchmark de embedding multilíngue descobriu que um modelo de 110M de parâmetros (e5_base) liderou em todos os seis idiomas e superou modelos até 70× maiores, e nosso benchmark multimodal colocou o DFN5B-H da Apple no topo com 50,1% de Recall@1 texto-imagem. Para equipes que não podem enviar dados para uma API, nosso benchmark de embedding de código aberto classifica o Nemotron-8B da NVIDIA em primeiro lugar (0.9249 nDCG@3), com o Harrier-oss de 0.6B com licença MIT da Microsoft sendo a opção mais forte sem restrições comerciais.
Reranking
Um recuperador bi-encoder é rápido, mas aproximado. Um reranker é um cross-encoder que reavalia os principais candidatos retornados pelo recuperador, lendo cada par consulta–documento em conjunto para levar os fragmentos realmente relevantes ao topo antes que cheguem ao LLM. O pipeline canônico de 2026 é recuperar um conjunto amplo, reordená-lo e, em seguida, enviar de 3 a 5 fragmentos para o modelo.1
Avaliamos 8 rerankers em recuperação em inglês (top 100 candidatos, 300 consultas):
Adicionar um reranker aumentou a precisão no top-1 (Hit@1) de 62.67% para 83,00%, um salto de 20,33 pontos com apenas um estágio extra. O resultado que deve mudar uma decisão de compra: um modelo de 149M de parâmetros (gte-reranker-modernbert-base) igualou um modelo de 1,2B no topo, portanto o maior reranker não é o que se deve buscar. O benchmark completo de reranker cobre a latência e o teto de Hit@10.
Bancos de dados vetoriais
O banco de dados vetorial armazena seus embeddings e realiza a busca de vizinhos mais próximos no momento da consulta, portanto define o piso de latência e uma grande parte do custo operacional. Avaliamos seis serviços gerenciados em um conjunto de dados de 1 milhão de vetores e 768 dimensões, medindo a latência média de consulta e o custo mensal.
Não há um vencedor único, apenas uma fronteira de latência/custo. Zilliz Cloud foi o mais rápido (26 ms) e Qdrant logo atrás (39 ms), enquanto Pinecone foi o mais barato a $60/100GB, mas também o mais lento (102 ms), e o MongoDB Atlas foi o mais caro com grande diferença ($1.440/100GB). Todos os seis agora oferecem suporte nativo à busca híbrida (vetores densos mais correspondência por palavra-chave BM25), com Reciprocal Rank Fusion (RRF) como a forma padrão de mesclar as duas listas de resultados. O benchmark completo de banco de dados vetorial inclui a matriz de suporte híbrido e uma calculadora de armazenamento.
Como escolher sua pilha RAG
Os benchmarks acima respondem “Qual componente é melhor isoladamente?” Esta seção responde “Como eu os monto?” Percorra o pipeline em ordem e escolha cada estágio por caso de uso, escala e orçamento:
- Chunking: divida os documentos em trechos de token de ~300–500 com 10–20% de sobreposição; prefira a divisão semântica/consciente da estrutura em vez de tamanhos fixos para documentos heterogêneos.
- Modelo de embedding: voyage-3.5 para a melhor qualidade por dólar em uma API; qwen3-embedding-8b ou NVIDIA Nemotron-8B se você precisar hospedar internamente; escolha um modelo multilíngue ou multimodal se o seu corpus exigir.
- Banco de dados vetorial: Zilliz/Qdrant quando a latência domina; Pinecone ou Elasticsearch quando o custo domina; qualquer um dos seis se você precisar de busca híbrida nativa.
- Recuperação híbrida: combine denso + BM25 com RRF; é o padrão de 2026 porque a recuperação lexical e semântica falham em consultas diferentes, portanto fundi-las é mais confiável do que qualquer uma sozinha.
- Reranking: adicione um cross-encoder (um modelo de 149M é suficiente) para recuperar os ~20 pontos de precisão top-1 que um bi-encoder deixa na mesa.
- Geração: use um modelo com suporte a citações fundamentadas, para que as respostas sejam atribuíveis à fonte.
- Avaliação: integre métricas de recuperação, geração e ponta a ponta antes de colocar em produção.
Governança empresarial
Para implantações empresariais, a qualidade da recuperação é necessária, mas não suficiente; a camada de recuperação também precisa ser governada. Espera-se que o RAG em produção imponha recuperação com consciência de permissão (os resultados respeitam os controles de acesso do sistema de origem, de modo que um usuário nunca recupere um documento que não poderia abrir diretamente), sincronize com provedores de identidade (Okta, Azure AD, Auth0) para que as alterações de permissão se propaguem quase em tempo real, registre cada recuperação para auditoria, execute barreiras de proteção de entrada/saída e respeite as restrições de residência de dados. Trate esses itens como requisitos básicos, não como complementos, para qualquer sistema RAG que lida com dados internos.2
RAG vs. contexto longo
Com janelas de contexto atingindo milhões de tokens, uma pergunta justa é se o RAG ainda é necessário. Em 2026, a resposta não é um ou outro: o RAG recupera a evidência relevante, uma janela de contexto longo pode refiná-la, e uma camada de roteamento decide qual caminho cada consulta toma.
A decisão geralmente se resume ao custo. Como um LLM cobra por cada token de entrada em cada requisição, encher o contexto com um corpus inteiro é caro em escala. Para grandes bases de conhecimento com carga de consulta constante, o RAG pode ser cerca de 1.250× mais barato por consulta do que o preenchimento de contexto longo, pois paga por alguns milhares de tokens recuperados em vez de todo o arquivo a cada vez.3
Essa vantagem é condicional e vale a pena declarar honestamente: o RAG vence em custo acima de aproximadamente 500K tokens de corpus e alguns milhares de consultas por dia, enquanto abaixo de ~200K tokens e algumas centenas de consultas por dia, o contexto longo com cache de prompt geralmente vence de forma absoluta, porque o custo fixo de hospedagem do banco de dados vetorial por si só pode exceder toda a conta do contexto longo.4 A precisão ainda favorece a recuperação para buscas de agulha no palheiro, em que filtrar texto irrelevante reduz a deriva de atenção do “perdido no meio” que degrada a recuperação de contexto longo.
Quais são os modelos e ferramentas RAG disponíveis?
As ferramentas RAG se dividem em três grupos: LLMs e APIs com fundamentação integrada, frameworks de orquestração e os componentes de recuperação subjacentes (modelos de embedding, bancos de dados vetoriais, rerankers).
LLMs e APIs com fundamentação integrada
Vários provedores de modelo agora oferecem recursos de geração fundamentada para que você possa anexar conhecimento externo com atribuição de fonte:
- Anthropic Claude: uma API de Citações que fundamenta as respostas nos documentos que você fornece e retorna referências às passagens exatas usadas.5
- Google Gemini: uma ferramenta integrada de Pesquisa de Arquivos que cuida do RAG para você (faça upload de documentos e o Gemini divide em fragmentos, gera embeddings e os recupera no momento da consulta), além do Vertex IA RAG Engine para recuperação empresarial gerenciada. Seu recurso separado de “fundamentação com o Google Search” extrai dados da web ao vivo, não dos seus próprios dados.6
- Cohere Command: modelos ajustados para RAG (Command R/R+ e o mais recente Command A) que retornam citações inline prontas para uso, combinados com um endpoint Rerank dedicado.7
- OpenAI: uma ferramenta de recuperação de pesquisa de arquivos nas APIs de Assistants e Responses.8
RAG bibliotecas e frameworks
Estes conectam a recuperação e a geração em um pipeline:
- LangChain / LangGraph: orquestração de propósito geral; o LangGraph adiciona loops com estado e agentivos de recuperar-refletir-verificar.
- LlamaIndex: ingestão de dados, indexação e mecanismos de consulta.
- Haystack: pipelines ponta a ponta para busca e resposta a perguntas.
- DSPy: programas declarativos de prompt/recuperação orientados por otimizador.
Para uma comparação mais aprofundada, veja nossa análise de frameworks RAG.
O que é geração aumentada por recuperação?
A geração aumentada por recuperação é uma técnica que dá a um modelo de linguagem grande acesso a uma fonte externa de conhecimento no momento da consulta. Em vez de responder apenas a partir de parâmetros fixos durante o treinamento, o modelo recupera passagens relevantes de um repositório de documentos e condiciona sua resposta a elas. Isso mantém as respostas atualizadas, fundamenta-as em fontes citáveis e reduz a alucinação em tarefas intensivas em conhecimento, sem a necessidade de retreinar o modelo.
Como funcionam os modelos RAG?
Em sua essência, o RAG opera em duas fases: recuperação (encontrar as passagens relevantes para a consulta) e geração (escrever uma resposta condicionada a essas passagens). Em sistemas de produção, esse loop central é envolvido em um pipeline mais completo:
- Reescrita/decomposição da consulta: reformule ou divida a pergunta para recuperar melhor, especialmente para consultas de múltiplos turnos ou múltiplos saltos.
- Recuperação híbrida: execute buscas densas (vetoriais) e esparsas (BM25) e combine os resultados com RRF.
- Reranking: um cross-encoder reavalia os candidatos e mantém os melhores.
- Montagem de contexto: construa o prompt a partir dos fragmentos selecionados com citações.
- Geração: o LLM responde a partir do contexto montado.
- Avaliação: pontue a qualidade da recuperação e da resposta, idealmente em CI.
O loop de duas fases ainda é o modelo mental; os estágios extras são o que separa uma demonstração de um sistema de produção.
Quais são os diferentes tipos de RAG?
Além do pipeline linear, várias variantes do RAG visam modos de falha específicos: RAG especulativo (rascunhar e verificar para velocidade), Retrieval-Augmented Fine-Tuning (RAFT) (treinar o modelo para usar o contexto recuperado), Self-RAG e RAG corretivo (CRAG) (o modelo critica e recupera novamente quando a evidência é fraca). Eles se sobrepõem às arquiteturas avançadas abaixo.
Arquiteturas avançadas de RAG
RAG baseado em grafos (GraphRAG)
O GraphRAG constrói um grafo de conhecimento sobre o corpus, geralmente em um banco de dados de grafos dedicado, como Neo4j ou FalkorDB, para que o sistema possa responder a perguntas de múltiplos saltos e de agregação global que a busca vetorial plana não alcança. Sua vantagem nessas perguntas vem em grande parte da pré-computação de relacionamentos em todo o corpus, e não de uma melhor recuperação de passagens, portanto a busca vetorial ainda tende a vencer em buscas de documentos específicos. A conclusão prática: recorra a um grafo quando as consultas exigirem raciocínio global em muitos documentos, e não como um substituto direto da recuperação vetorial.
RAG agentivo
O RAG agentivo coloca um agente LLM no comando da recuperação: decidindo o que buscar, qual fonte ou ferramenta chamar e quando refletir e tentar novamente, em loop até que a resposta seja fundamentada. Em nosso benchmark de RAG agentivo, que testa um agente que deve rotear cada pergunta para o banco de dados correto e, em seguida, escrever SQL contra ele, os modelos mais fortes agora roteiam quase perfeitamente (Claude Opus 4.8 com 100%, Fable 5 com 98%), enquanto escrever SQL correto contra o esquema escolhido continua sendo o teto mais difícil, chegando a cerca de 90%. O roteamento está quase resolvido; a execução fundamentada é onde o RAG agentivo ainda se diferencia.
RAG híbrido, iterativo e ativo
A recuperação híbrida (densa + esparsa, abordada acima) agora é o padrão, em vez de uma opção avançada. As variantes iterativas e ativas (por exemplo, FLARE) permitem que o modelo recupere repetidamente enquanto gera, buscando novas evidências quando sua confiança cai.
Como avaliar sistemas RAG
A avaliação do RAG agora é estruturada em ciclo de vida em três camadas: recuperação (precisão, recall, MRR, nDCG, hit@k: buscamos os fragmentos certos?), geração (fundamentação, fidelidade: a resposta é apoiada pelo contexto recuperado?) e ponta a ponta (a resposta final está correta?).
As ferramentas se dividem nas mesmas linhas: RAGAS para iteração rápida e livre de referência durante o desenvolvimento; DeepEval como um portão de aprovação/reprovação no estilo pytest em CI para que uma regressão bloqueie a compilação; e TruLens ou Phoenix para rastreamento e monitoramento em produção. TREC-RAG e ARES são referências externas úteis para calibração de juízes.9
Tamanho do fragmento
O tamanho do fragmento controla como os documentos são divididos antes do embedding.
As diretrizes de 2026 foram além de um único tamanho fixo: prefira divisão semântica/consciente da estrutura (inicie um novo fragmento onde as frases adjacentes divergem em significado), mantenha fragmentos em torno de 300–500 tokens com 10–20% de sobreposição e considere a recuperação contextual: a técnica da Anthropic de preceder cada fragmento com uma frase de contexto gerada por LLM antes do embedding e da indexação BM25. Nos testes da Anthropic, embeddings contextuais reduziram a taxa de falha de recuperação no top-20 em 35%, embeddings contextuais mais BM25 contextual em 49%, e adicionar um reranker em cima em 67%.10
Fine-Tuning vs. Geração Aumentada por Recuperação
O RAG e o fine-tuning resolvem problemas diferentes e, em 2026, são cada vez mais usados juntos, em vez de como alternativas.
Para a maioria das equipes, a resposta é “RAG primeiro, faça o fine-tuning do comportamento se necessário”, e o RAFT formaliza fazer ambos.
Benefícios da geração aumentada por recuperação
As vantagens do RAG se agrupam em algumas que realmente impulsionam a adoção: precisão e atualidade (as respostas refletem dados atuais e fundamentados na fonte, não um corte de treinamento congelado), transparência (as respostas citam as passagens que usaram, portanto são auditáveis), custo mais baixo do que o contexto longo em escala e adaptabilidade (atualize a base de conhecimento em vez de retreinar o modelo). O RAG multimodal estende esses benefícios a imagens, PDFs e tabelas.
Leituras adicionais
- Benchmark de modelos de embedding
- Benchmark de reranker
- Banco de dados vetorial para RAG
- Modelos de embedding de código aberto
- Modelos de embedding multilíngues
- Embeddings multimodais
- Frameworks de RAG agentivo
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{sar2026,
author = {Sarı, Ekrem},
title = {{Melhores RAG ferramentas, frameworks e bibliotecas}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/retrieval-augmented-generation}},
note = {AIMultiple. Acessado em 30 Junho 2026}
}
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.