Benchmark

Melhores RAG Ferramentas, Frameworks e Bibliotecas

atualizado em 18 jul. 2026

RAG melhora as respostas dos LLMs ao fundamentá-las em dados externos, em vez de apenas o que o modelo memorizou durante o treinamento. Avaliamos os componentes a partir dos quais um sistema RAG é construído e reunimos os resultados em um só lugar, com um guia prático para escolher cada parte da stack.

Veja nossos resultados de benchmark para cada componente RAG, nosso guia para escolher uma stack RAG, ou os RAG fundamentos: o que é, como funciona e onde se encaixa.

RAG resultados de benchmark

Modelos de embedding

O modelo de embedding converte tanto seus documentos quanto a consulta do usuário em vetores, então ele define o teto da qualidade de recuperação.

Loading Chart

Avaliamos 15 modelos de embedding densos mais uma baseline lexical BM25 em três domínios (contratos legais/CUAD, suporte ao cliente/TechQA e saúde/MedRAG), pontuando cada um no nDCG@3.

voyage-3.5 ocupa o primeiro lugar com 0.9429 e supera o próprio modelo flagship voyage-4-large da Voyage, custando metade do preço ($0.060 vs $0.120 por 1M tokens). O modelo mais novo e maior não é automaticamente a melhor compra. Para stacks com foco em 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 a visão de precisão versus preço, veja o gráfico de custo no benchmark completo de modelos de embedding, que também contém a divisão por domínio e a metodologia.

Além dos embeddings densos de vetor único, recuperadores de interação tardia (multi-vetor) como ColBERT (e ColPali/ColQwen para documentos visuais e recuperação de PDF) mantêm um vetor por token para correspondência mais refinada e generalização mais forte fora do domínio, com um índice muito maior (ColPali armazena aproximadamente 1,000× mais vetores por item; veja nosso benchmark de embeddings multimodais).

Se seu corpus for multilíngue ou visual, a escolha de embedding muda: nosso benchmark de embeddings multilíngues descobriu que um modelo de 110M parâmetros (e5_base) liderou 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 embeddings open-source classifica o Nemotron-8B da NVIDIA em primeiro lugar (0.9249 nDCG@3), com o Harrier-oss de 0.6B da Microsoft com licença MIT sendo a opção comercial irrestrita mais forte.

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 colocar os trechos verdadeiramente relevantes no topo antes que cheguem ao LLM. O pipeline canônico de 2026 é recuperar um conjunto amplo, rerank reduzi-lo e, em seguida, enviar 3 a 5 trechos para o modelo. ¹

Avaliamos 8 rerankers na recuperação em inglês (top-100 candidatos, 300 consultas):

Adicionar um reranker elevou a precisão do top-1 (Hit@1) de 62.67% para 83.00%, um salto de 20.33 pontos vindo de uma única etapa extra. O resultado que deveria mudar uma decisão de compra: um modelo de 149M parâmetros (gte-reranker-modernbert-base) igualou um modelo de 1.2B no topo, então o maior reranker não é a escolha a se fazer. O benchmark completo de rerankers cobre latência e o teto de Hit@10.

Bancos de dados vetoriais

O banco de dados vetorial armazena seus embeddings e realiza a busca por vizinho mais próximo no momento da consulta, portanto ele define o piso de latência e uma grande parcela do custo de operação. Avaliamos sete engines open-source auto-hospedadas com embeddings bge-m3 idênticos, cada uma lida em um Recall@10 igualado de 0.95 para que o índice fosse a única variável.

As sete empatam em precisão de recuperação. O nDCG@10 fica entre 0.803 e 0.817, uma dispersão de 0.014, contra uma dispersão de 10x na vazão single-thread (Redis 764 QPS, LanceDB 70) e uma dispersão de 3.7x na memória de pico com 2.25M vetores (Milvus 17.0 GB, Chroma 62.4 GB). A engine é uma decisão de velocidade, memória e carga de trabalho, e não de precisão, porque o modelo de embedding define o teto de qualidade nesse ponto de operação.

Qual engine se adequa depende da carga de trabalho. O Redis registrou 1.7 ms p95 com 559 MB de RAM, com persistência desligada. O Weaviate atingiu 8,330 QPS com 32 processos worker, onde o Redis saturou em 1,642. O Milvus manteve 17.0 GB com 2.25M vetores, contra 62.4 GB do Chroma, e manteve o maior recall de pior caso sob filtros de metadados (0.984). O Qdrant registrou um ganho de +0.067 no nDCG híbrido com fusion nativa. Duas engines apresentam limites rígidos: o Chroma não inclui busca por palavra-chave em sua versão auto-hospedada e retorna um p99 de 13 segundos com 512 clientes concorrentes, e o LanceDB suporta apenas 2.6 escritas de linha única por segundo, o que o descarta para uma base de conhecimento continuamente atualizada. O benchmark completo de bancos de dados vetoriais open-source cobre busca filtrada, custo de construção e rotatividade ao vivo, e a calculadora de dimensionamento de banco de dados vetorial transforma esses limites em um veredito por engine para um servidor específico.

Como escolher sua stack RAG

Os benchmarks acima respondem “Qual componente é o melhor isoladamente?” Esta seção responde “Como eu os monto?” Percorra o pipeline em ordem e escolha cada etapa por caso de uso, escala e orçamento:

Chunking: divida os documentos em trechos de ~300 a 500 tokens com sobreposição de 10 a 20%; prefira divisão semântica/estrutural em vez de tamanhos fixos para documentos heterogêneos.
Modelo de embedding: voyage-3.5 para a melhor qualidade por custo em uma API; qwen3-embedding-8b ou NVIDIA Nemotron-8B se precisar self-hospedar; escolha um modelo multilíngue ou multimodal se seu corpus exigir.
Banco de dados vetorial: Redis quando a latência de consulta única domina, Weaviate ou Milvus para concorrência sustentada, Milvus quando a memória é a restrição em escala, pgvector quando a stack já está em Postgres; quatro dos sete (Qdrant, Milvus, Weaviate, LanceDB) fundem resultados híbridos nativamente. Dimensione o índice em relação ao servidor primeiro, já que um servidor de 16 GB comporta cerca de 1.5M vetores no Redis e 3.7M no Qdrant com 1024 dimensões.
Recuperação híbrida: combine denso + BM25 com RRF, o que elevou o nDCG@10 em 0.030 a 0.067 entre as engines que possuem braço de palavra-chave em nosso benchmark de bancos de dados vetoriais; o ganho supera zero com 95% de confiança para Qdrant, LanceDB, Redis e Milvus, e não para pgvector ou Weaviate.
Reranking: adicione um cross-encoder (um modelo de 149M é suficiente) para recuperar os ~20 pontos de precisão do top-1 que um bi-encoder deixa na mesa.
Geração: use um modelo com suporte a citação fundamentada, para que as respostas sejam atribuíveis à fonte.
Avaliação: integre métricas de recuperação, geração e ponta a ponta antes de publicar.

Governança corporativa

Para implantações corporativas, a qualidade de recuperação é necessária, mas não suficiente; a camada de recuperação também precisa ser governada. Espera-se que um RAG de produção imponha recuperação ciente de permissões (os resultados respeitam os controles de acesso do sistema de origem, para 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 em tempo quase real, registre cada recuperação para auditoria, execute guardrails de entrada/saída e honre as restrições de residência de dados. Trate isso como pré-requisitos, não complementos, para qualquer sistema RAG que toque dados internos. ² Esses controles precisam ser mantidos na camada de recuperação, não apenas na aplicação acima dela, e as engines open-source diferem no que podem impor: das sete que avaliamos, apenas o pgvector oferece recuperação point-in-time e segurança em nível de linha, o Qdrant, Milvus e Weaviate fornecem replicação e RBAC em suas versões open-source, o Chroma 1.x não fornece autenticação alguma, e nenhum dos sete criptografa dados em repouso nativamente, o que deixa isso para criptografia de disco ou volume.

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 as evidências relevantes, uma janela de contexto longo pode refiná-las, 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, colocar um corpus inteiro no contexto é caro em escala. Para grandes bases de conhecimento sob carga constante de consultas, o RAG pode ser da ordem de 1,250× mais barato por consulta do que o enchimento de contexto longo, já que ele paga por alguns milhares de tokens recuperados em vez do arquivo inteiro a cada vez. ³

Essa vantagem é condicional e vale a pena afirmar 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 frequentemente 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. ⁴ Nosso modelo de dimensionamento expressa esse piso em termos concretos. Um corpus de 2 GB em trechos de 512 tokens se torna cerca de 1.15M vetores, o que requer 5.1 GB de RAM no Qdrant ou 6.9 GB no Milvus, um servidor que custa o mesmo quer chegue uma consulta ou não. A precisão ainda favorece a recuperação para buscas do tipo agulha no palheiro, onde filtrar texto irrelevante reduz o desvio de atenção “perdido no meio” que degrada o recall 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 grounding integrado, frameworks de orquestração e os componentes de recuperação subjacentes (modelos de embedding, bancos de dados vetoriais, rerankers).

LLMs e APIs com grounding integrado

Vários provedores de modelos agora oferecem recursos de geração fundamentada para que você possa anexar conhecimento externo com atribuição de fonte:

Anthropic Claude: uma API de Citations que fundamenta as respostas nos documentos fornecidos e retorna referências às passagens exatas usadas. ⁵
Google Gemini: uma ferramenta integrada de File Search que cuida do RAG para você (faça upload de documentos e o Gemini os divide, gera embeddings e os recupera no momento da consulta), além do Vertex IA RAG Engine para recuperação corporativa gerenciada. O recurso separado “grounding com Google Search” busca na web ao vivo, não nos seus próprios dados. ⁶
Cohere Command: modelos ajustados para RAG (Command R/R+ e o mais novo Command A) que retornam citações em linha prontas para uso, combinados com um endpoint dedicado de Rerank. ⁷
OpenAI: uma ferramenta de recuperação de busca em arquivos nas APIs Assistants e Responses. ⁸

Bibliotecas e frameworks RAG

Estes conectam recuperação e geração em um pipeline:

LangChain / LangGraph: orquestração de propósito geral; o LangGraph adiciona loops stateful e agentivos de recuperar-refletir-verificar.
LlamaIndex: ingestão de dados, indexação e engines 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 RAG frameworks.

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 de conhecimento externa no momento da consulta. Em vez de responder apenas a partir de parâmetros fixados 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 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 de consulta: reformule ou divida a pergunta para recuperar melhor, especialmente para consultas multi-turno ou multi-hop.
Recuperação híbrida: execute buscas densas (vetoriais) e esparsas (BM25) e funda os resultados com RRF.
Reranking: um cross-encoder reavalia os candidatos e mantém os poucos melhores.
Montagem de contexto: construa o prompt a partir dos trechos 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; as etapas extras são o que separa uma demonstração de um sistema de produção.

Deixe nossa equipe automatizar um dos seus processos de negócio com agentes de IA, gratuitamente.

Automatizar um processo

Quais são os diferentes tipos de RAG?

Além do pipeline linear, várias variantes de RAG visam modos de falha específicos: RAG especulativo (esboço e verificação para velocidade), Ajuste Fino com Recuperação Aumentada (RAFT) (treinar o modelo para usar contexto recuperado), Self-RAG e RAG corretivo (CRAG) (o modelo critica e recupera novamente quando as evidências são fracas). Estes 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 multi-hop e de agregação global que a busca vetorial plana perde. Sua vantagem nessas perguntas vem principalmente da pré-computação de relacionamentos em todo o corpus, em vez de uma melhor recuperação de passagens, portanto a busca vetorial ainda tende a vencer em buscas de documentos específicos. A lição prática: recorra a um grafo quando as consultas exigirem raciocínio global entre muitos documentos, não como um substituto direto para a recuperação vetorial.

RAG agêntico

O RAG agêntico coloca um agente LLM no comando da recuperação: decidindo o que buscar, qual fonte ou ferramenta chamar e quando refletir e tentar novamente, repetindo até que a resposta esteja fundamentada. Em nosso benchmark de RAG agêntico, 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 permanece o teto mais difícil, atingindo cerca de 90%. O roteamento está quase resolvido; a execução fundamentada é onde o RAG agêntico 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.

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.

Adicionar como fonte preferencial

Como avaliar sistemas RAG

A avaliação de RAG agora é estruturada no ciclo de vida em três camadas: recuperação (precisão, recall, MRR, nDCG, hit@k: buscamos os trechos 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 gratuito durante o desenvolvimento; DeepEval como um gate de aprovação/reprovação estilo pytest em CI para que uma regressão bloqueie a build; 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. ⁹

As métricas de recuperação se dividem em duas uma vez que um banco de dados vetorial entra no circuito, e as metades podem se mover em direções opostas. O recall ANN pergunta se o índice retornou os verdadeiros vetores mais próximos, o que isola o banco de dados; nDCG e MRR contra rótulos humanos perguntam se esses documentos são relevantes, o que é principalmente uma propriedade do modelo de embedding. Escalar um corpus de 50k para 2.25M vetores em nosso benchmark de bancos de dados vetoriais reduziu o nDCG@10 de cerca de 0.81 para 0.56, enquanto todas as engines ainda reportaram Recall@10 acima de 0.973, e o oráculo exato de kNN caiu para os mesmos 0.572. Um benchmark puramente geométrico teria reportado um índice saudável sobre um corpus que havia perdido um terço de sua qualidade de resposta.

Categoria da métrica	Métrica chave	O que mede
Recuperação	MRR / nDCG	O trecho mais relevante está classificado em primeiro lugar?
Recuperação	Recall@k	Perdemos algum documento crucial?
Recuperação	ANN Recall@10	O índice retornou os verdadeiros vetores mais próximos?
Geração	Fidelidade	A resposta está gratuito de alucinação?
Segurança	Rejeição negativa	O modelo se recusa quando a evidência está ausente?
Framework	RAGAS / DeepEval / TruLens	Iteração de desenvolvimento / gate de CI / rastreamento de produção

Tamanho do chunk

O tamanho do chunk controla como os documentos são divididos antes do embedding.

A orientação de 2026 foi além de um único tamanho fixo: prefira chunking semântico / estrutural (iniciar um novo chunk onde frases adjacentes divergem em significado), mantenha chunks em torno de 300 a 500 tokens com sobreposição de 10 a 20%, e considere a recuperação contextual: a técnica da Anthropic de preceder cada chunk com uma frase de contexto gerada por LLM antes do embedding e da indexação BM25. Nos testes da Anthropic, os 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%. ¹⁰ O tamanho do chunk também define o tamanho do índice, já que decide em quantos vetores o corpus se transforma. Nossa calculadora de dimensionamento de banco de dados vetorial explicita o vínculo: com o chunk padrão de 512 tokens e sobreposição de 15%, o corpus avança 435 tokens por chunk, portanto, reduzir o chunk pela metade aproximadamente dobra tanto a contagem de vetores quanto a memória que o banco de dados precisa manter.

Ajuste Fino vs. Geração Aumentada por Recuperação

RAG e ajuste fino resolvem problemas diferentes, e em 2026 eles são cada vez mais usados juntos, em vez de como alternativas.

Categoria	RAG	Ajuste Fino
Acesso ao conhecimento	Recupera informações externas e atualizáveis no momento da consulta	Incorpora conhecimento nos pesos; estático até ser retreinado
Dados atualizados	Incorpora os dados mais recentes sem retreinamento	Requer retreinamento para atualizar
Transparência	As respostas citam as fontes recuperadas	O processo de decisão é opaco
Melhor para	Domínios intensivos em conhecimento e de rápida mudança	Estilo, formato ou comportamento de tarefa fixo
Combinar ambos	N/A	O RAFT treina o modelo para usar o contexto recuperado, obtendo o comportamento do ajuste fino com a atualização do RAG

Para a maioria das equipes, a resposta é “RAG primeiro, ajuste fino 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 atualização (as respostas refletem dados atuais e fundamentados em fontes, não um corte de treinamento congelado), transparência (as respostas citam as passagens que usaram, portanto são auditáveis), custo menor que o contexto longo em escala e adaptabilidade (atualize a base de conhecimento em vez de retreinar o modelo). O RAG multimodal estende isso a imagens, PDFs e tabelas.

Leitura adicional

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.

Ekrem Sarı (2026) - "Melhores RAG Ferramentas, Frameworks e Bibliotecas". Publicado on-line em AIMultiple.com. Acessado em 18 Julho 2026, em: https://aimultiple.com/retrieval-augmented-generation [Recurso on-line]

Sarı, E. (2026, 18 Julho). Melhores RAG Ferramentas, Frameworks e Bibliotecas. AIMultiple. https://aimultiple.com/retrieval-augmented-generation

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Melhores RAG Ferramentas, Frameworks e Bibliotecas}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/retrieval-augmented-generation}},
  note   = {AIMultiple. Acessado em 18 Julho 2026}
}