RAG Frameworks: LangChain vs LangGraph vs LlamaIndex

Avaliamos 5 frameworks de RAG: LangChain, LangGraph, LlamaIndex, Haystack e DSPy, construindo o mesmo fluxo de trabalho agênico de RAG com componentes padronizados: modelos idênticos (GPT-4.1-mini), embeddings (BGE-small), retriever (Qdrant) e ferramentas (pesquisa na web Tavily). Isso isola a sobrecarga real e a eficiência de tokens de cada framework.

Resultados do benchmark de frameworks de RAG

O benchmark consistiu em 100 consultas, com cada framework executando o conjunto completo 100 vezes para fornecer médias estáveis.

• Média de Tokens: Total de tokens consumidos em todas as chamadas de LLM (roteador, avaliador de documentos, avaliador de respostas e gerador), inclui tanto prompts (com contexto recuperado) quanto conclusões. Menor = menor custo de API.
• Sobrecarga do Framework: Tempo puro de orquestração (ms), o processamento interno do framework (lógica de roteamento, gerenciamento de estado, etc.), excluindo chamadas de LLM API e ferramentas. Menor = framework mais enxuto.

Todas as implementações alcançaram 100% de precisão no conjunto de testes. Foram usados os mesmos modelos, temperaturas, provedor de recuperação, ferramenta de pesquisa na web e um limite compartilhado de tokens de contexto.

Principais descobertas

1. Focamos em controlar o que é controlável: Mesma família de modelos e temperaturas, max_tokens no nível do nó, retriever (Qdrant + BGE-small, k=5, normalização ativada), provedor da web (apenas Tavily), política de roteador (heurística + modelo), retorno antecipado da calculadora, limite compartilhado de tokens de contexto, rubrica de avaliação idêntica, instrumentação unificada. Isso reduz substancialmente os principais fatores de confusão em nossas medições.
2. A sobrecarga do framework é mensurável, mas pequena: Observamos ~3–14 ms por consulta da lógica de orquestração. Essas diferenças são reais, mas não são a principal fonte das lacunas de latência de >1 s; a maior parte do tempo é gasta em E/S com modelos/ferramentas externas.
3. O desempenho segue os tokens (sob essas restrições): DSPy mostra a menor sobrecarga do framework (~3,53 ms). Haystack (~5,9 ms) e LlamaIndex (~6 ms) seguem, enquanto LangChain (~10 ms) e LangGraph (~14 ms) são mais altos. O uso de tokens é mais baixo para Haystack (~1,57k), seguido por LlamaIndex (~1,60k); DSPy e LangGraph são ~2,03k, e LangChain ~2,40k.
4. O caminho de roteamento/ferramenta importa: Pequenas mudanças no roteamento inicial (retriever vs. web vs. calculadora) e no comportamento de fallback afetam tanto tokens quanto tempo, mesmo quando prompts e orçamentos estão alinhados.

Por que as diferenças persistem? O “DNA do Framework”

Apesar da padronização, pequenas variações nos contagens de tokens e latência permanecem. Estas são atribuíveis aos comportamentos inerentes e de baixo nível de cada framework, seu “DNA”.

• Serialização de prompts e mensagens: Cada framework envolve o mesmo conteúdo lógico com formatação ligeiramente diferente antes de enviá-lo ao LLM, criando deltas de tokens pequenos, mas consistentes.
• Montagem de contexto: A ordem precisa e a inclusão de metadados dentro do contexto concatenado podem diferir ligeiramente por framework, afetando a contagem final de tokens.
• Desempates de roteamento: Em casos limítrofes, diferenças sutis na forma como um framework analisa a saída JSON do roteador podem levar a uma escolha inicial de ferramenta diferente.

Nesta configuração, a pegada de tokens parece ser o principal motor, mais do que o tempo de execução do framework.

A arquitetura agênica compartilhada de RAG

Para alcançar uma comparação justa, todas as cinco implementações foram construídas sobre o mesmo fluxo de controle:

• Roteador: Um nó híbrido de modelo e heurística que escolhe retriever, web_search ou calculadora.
• Recuperar Documentos: Busca os 5 principais documentos do Qdrant usando embeddings normalizados BGE-small.
• Avaliar Documentos: Um juiz LLM avalia a relevância do documento. Se irrelevante, aciona um fallback de pesquisa na web.
• Gerar Resposta: Usa um LLM com temperatura=0,0 e um limite compartilhado de tokens de contexto para gerar uma resposta preliminar.
• Avaliar Resposta: Um segundo juiz LLM avalia o rascunho quanto à fundamentação, contradições (alucinações) e completude.
• Fallback e Retorno Antecipado: Uma pesquisa na web é acionada se a avaliação da resposta for insuficiente. No entanto, os resultados da calculadora são retornados diretamente, pulando as etapas de geração e avaliação.

Exemplos de fluxo de trabalho

Cenário A — Acerto direto no banco de dados:

Cenário B — Evento recente aciona ferramenta da web:

Cenário C — Calculadora fornece um retorno antecipado:

Cenário D — Banco de dados vetorial insuficiente, recua para pesquisa na web:

Metodologia de frameworks de RAG

Todas as cinco implementações alcançaram 100% de precisão em nosso conjunto de testes de 100 consultas, correspondendo às respostas da verdade fundamental. Este foi o requisito fundamental, garantindo que cada framework pudesse executar com sucesso o mesmo fluxo de trabalho agênico de RAG antes de medir as diferenças de desempenho.

1. Componentes principais e configuração

As ferramentas fundamentais foram padronizadas para eliminar variáveis de desempenho na fonte.

• LLMs:
  • Modelo: Todos os nós (roteador, gerador, avaliador) usaram o modelo openai/gpt-4.1-mini via OpenRouter API.
  • Determinismo: a temperatura foi definida como 0,0 para todas as chamadas de LLM para garantir consistência máxima no roteamento, geração e avaliação.
  • Limites de tokens: Limites estritos de max_tokens foram aplicados: 256 para o roteador e avaliadores, e 512 para o gerador. Isso evita diferenças de latência causadas por um framework gerando respostas excessivamente longas.
• Modelo de embedding e recuperação:
  • Modelo: Todos os frameworks usaram BAAI/bge-small-en-v1.5 do HuggingFace.
  • Normalização: Uma etapa crítica para o desempenho, normalize_embeddings foi definido como True em todos os cinco frameworks. (LangChain/LangGraph via encode_kwargs; LlamaIndex via normalize=True; Haystack via normalize_embeddings; retriever DSPy normalizado.)
  • Recuperação: O armazenamento vetorial Qdrant foi consultado para um k=5 (top 5 documentos) em todas as implementações.
• Ferramentas:
  • Pesquisa na web: O benchmark foi restrito a apenas Tavily (max_results=3).
  • Calculadora: Todas as cinco implementações usaram a biblioteca sympy para análise e avaliação de expressões matemáticas, garantindo capacidades idênticas.

2. Fluxo de controle e política de RAG

O processo de “tomada de decisão” do agente foi explicitamente espelhado em toda a extensão.

• Lógica de roteamento: Uma estratégia de roteamento híbrida foi implementada em todos os cinco scripts para equilibrar a inteligência do modelo com regras determinísticas:
  1. Uma heurística baseada em regex primeiro verifica padrões óbvios de calculadora ou pesquisa na web (por exemplo, símbolos matemáticos, anos como “2024”).
  2. Um nó LLM router_node então toma sua própria decisão.
  3. A decisão final prioriza a heurística para calculadoras, caso contrário, delegando à escolha do LLM.
• Orçamento de contexto: Esta é uma das padronizações mais críticas. Antes que o nó generate_answer seja chamado, todo o contexto de documento recuperado e os resultados da pesquisa na web são concatenados e depois truncados para um limite compartilhado de 2000 tokens usando um utilitário comum truncate_to_token_budget. Isso garante que o gerador LLM em cada framework receba uma entrada do tamanho exato, impedindo que qualquer framework único seja favorecido ou prejudicado pela verbosidade de seu contexto recuperado.
• Política de avaliação de resposta:
  • Rubrica permissiva: O nó grade_answer usa um prompt idêntico e permissivo em todos os frameworks, instruindo o juiz LLM a aceitar respostas semanticamente semelhantes e razoavelmente completas.
  • Tratamento de falhas: A lógica para lidar com uma análise JSON falha do avaliador foi padronizada. Se a saída do avaliador não for JSON válida, o sistema padrão para uma avaliação permissiva (grounded=True, complete=True), imitando um cenário do mundo real onde você não gostaria que um analisador frágil falhasse uma resposta de outra forma boa. Campos estruturados do DSPy retornam (sem análise JSON), isso é registrado como uma diferença de robustez, não uma vantagem de desempenho.
• Retorno antecipado da calculadora: Como visto no código, uma chamada bem-sucedida ao calculator_node define diretamente o final_answer e encerra o fluxo de trabalho antecipadamente. Esta é uma otimização significativa que é aplicada consistentemente, impedindo que o caminho da calculadora invoque desnecessariamente os LLMs de geração e grade_answer.
• Alinhamento do DSPy. Para manter a justiça com as linhas de base não-CoT, o DSPy usa dspy.Predict (sem CoT) para Router e AnswerGenerator. As assinaturas espelham os contratos de nó de outros frameworks; onde disponível, as contagens de tokens usam o uso relatado pelo modelo, caso contrário, fallback tiktoken.

3. Instrumentação e métricas

O processo de medição foi idêntico, usando utilitários e princípios compartilhados.

• Latência: O tempo.perf_counter() de alta precisão foi usado para todo o cronometragem. A Sobrecarga do Framework é consistentemente calculada como Latência Total – Latência de Chamadas Externas.
• Tokenização: Todas as contagens de tokens para prompts e conclusões foram calculadas usando tiktoken, a codificação cl100k_base, garantindo uma única fonte da verdade para métricas de tokens. A métrica “Média de Tokens” relatada nos resultados representa a soma cumulativa de todos os tokens de entrada (prompt) e saída (conclusão) para cada chamada de LLM (por exemplo, roteador, avaliadores, gerador) dentro de um único fluxo de trabalho de consulta.
• Gerenciamento de estado: Embora a sintaxe de implementação varie (TypedDict do LangGraph, classe do LlamaIndex, dicionário do LangChain), a estrutura de estado é funcionalmente idêntica. Cada framework passa o mesmo conjunto de chaves (pergunta, documentos, web_results, etc.) entre os nós, garantindo que a lógica de fluxo de controle opere nas mesmas informações.

Ao impor essas padronizações rigorosas em nível de código, este benchmark visa ir além de comparações superficiais e oferecer uma análise replicável do desempenho do framework sob uma política fixa de RAG.

Interpretando os resultados:

• Você pode concluir: Nesta configuração específica e altamente controlada, a sobrecarga de orquestração tende a ser pequena; as diferenças são impulsionadas principalmente pelas contagens de tokens e caminhos de ferramenta.
  • Nesta configuração específica e altamente controlada, a sobrecarga do framework é insignificante.
  • As diferenças de desempenho foram impulsionadas pela contagem de tokens e variações no caminho da ferramenta.
• Você não pode generalizar: Os resultados são específicos desta arquitetura, modelos, prompts, retriever e provedor da web; alterar esses pode alterar as classificações.

Veja mais dos nossos benchmarks e insights baseados em dados na Pesquisa Google.

Adicionar como fonte preferencial

Experiência do desenvolvedor: Uma comparação qualitativa

O desempenho não é o único fator; como um framework se sente para construir é igualmente importante.

• LangGraph: O grafo declarativo
  Usa um paradigma primeiro de grafo. Você define nós e os conecta com arestas (incluindo add_conditional_edges), então o fluxo de controle faz parte da arquitetura. O estado é tipado via um TypedDict com atualizações no estilo redutor (Annotated[…, add]).
  • Escolha LangGraph para: fluxos de trabalho complexos com múltiplos ramos, retries e ciclos; sua estrutura escala em robustez e manutenibilidade à medida que os agentes crescem.
• LlamaIndex: Orquestração imperativa
  Um script procedural onde o fluxo de controle é Python padrão if/else; o “grafo” vive no seu código. O estado é uma classe PipelineState dedicada, e o framework fornece primitivas de recuperação limpas (VectorStoreIndex → .as_retriever(k=5)).
  • Escolha LlamaIndex para: fluxos de trabalho legíveis de arquivo único onde você valoriza lógica procedural clara e depuração fácil.
• LangChain: Imperativo com componentes declarativos
  A orquestração permanece um script Python, mas tarefas individuais são pequenas, composáveis chains usando o operador | (por exemplo, prompt | llm | parser). O estado é um dicionário Python flexível e sem tipo.
  • Escolha LangChain para: Prototipagem rápida ou equipes já no ecossistema LangChain que preferem compor pequenas unidades declarativas dentro de um driver imperativo maior.
• Haystack: Baseado em componentes, orquestração manual Componentes tipados e reutilizáveis (@component) com I/O explícito, enquanto o fluxo de controle permanece Python simples (if/else). Fácil de trocar backends de LLM/retriever/web, além de instrumentação de nível por etapa de primeira classe (tempo externo vs. framework).
  • Escolha Haystack para: pipelines prontos para produção, testáveis com contratos claros e controle fino.
• DSPy: Programas primeiro de assinatura (menos linhas de código)
  Defina uma tarefa via uma assinatura (entradas/saídas + intenção), depois implemente-a com Módulos que encapsulam prompts e chamadas de LLM. Centraliza o tratamento de prompt/uso e remove código de cola; trocar internos (por exemplo, Predict ↔ CoT) não muda o contrato.
  • Escolha DSPy para: boilerplate mínimo, fluxos de arquivo único legíveis, desenvolvimento orientado a contrato (com otimizadores opcionais).

Trocar desempenho ótimo por comparabilidade

• LangGraph pode se destacar com suas otimizações nativas de grafo quando permitido usar execução paralela, cache de estado e seu sistema de aresta condicional para lógica de ramificação complexa.
• DSPy pode mostrar resultados dramaticamente diferentes ao usar seus otimizadores de assinatura (como MIPROv2) e prompts de Chain-of-Thought, o que pode melhorar significativamente a qualidade da resposta.
• Haystack pode aproveitar seu cache pronto para produção, recursos de batching e otimizações em nível de componente que desativamos para justiça.
• LlamaIndex pode se beneficiar de suas estratégias avançadas de indexação, motores de consulta e capacidades multimodais que não foram exercidas neste benchmark.
• LangChain pode brilhar com seu extenso ecossistema de ferramentas e otimizações LCEL (LangChain Expression Language) quando não restrito ao nosso conjunto de ferramentas padronizado.

O framework “melhor” depende de se você otimiza para: velocidade de desenvolvimento, manutenibilidade, desempenho ou padrões arquitetônicos específicos.

Leitura adicional

Explore outros benchmarks de RAG, como:

• Modelos de Embedding: OpenAI vs Gemini vs Cohere
• Top Banco de Dados Vetorial para RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark de RAG agênico: roteamento de banco de dados múltiplo e geração de consulta
• RAG Híbrido: Aumentando a Precisão do RAG

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{dilmegani2026,
  author = {Dilmegani, Cem and Sarı, Ekrem},
  title  = {{RAG Frameworks: LangChain vs LangGraph vs LlamaIndex}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Acessado em 3 Junho 2026}
}

Cem Dilmegani

Analista Principal

Siga-nos

Cem é o analista principal da AIMultiple desde 2017. A AIMultiple fornece informações para centenas de milhares de empresas (segundo o SimilarWeb), incluindo 55% das empresas da Fortune 500, todos os meses. O trabalho de Cem foi citado por importantes publicações globais, como Business Insider, Forbes e Washington Post, além de empresas globais como Deloitte e HPE, ONGs como o Fórum Econômico Mundial e organizações supranacionais como a Comissão Europeia. Você pode ver mais empresas e recursos renomados que mencionaram a AIMultiple. Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor na área. Ele assessorou empresas em suas decisões tecnológicas na McKinsey & Company e na Altman Solon por mais de uma década. Também publicou um relatório da McKinsey sobre digitalização. Liderou a estratégia de tecnologia e a área de compras de uma empresa de telecomunicações, reportando-se diretamente ao CEO. Além disso, liderou o crescimento comercial da empresa de tecnologia avançada Hypatos, que atingiu uma receita recorrente anual de sete dígitos e uma avaliação de nove dígitos, partindo de zero, em apenas dois anos. O trabalho de Cem no Hypatos foi noticiado por importantes publicações de tecnologia, como TechCrunch e Business Insider. Cem participa regularmente como palestrante em conferências internacionais de tecnologia. Ele se formou em engenharia da computação pela Universidade Bogazici e possui um MBA pela Columbia Business School.

Ver perfil completo

Pesquisado por

Ekrem Sarı

Pesquisador de IA

Siga-nos

Ekrem é pesquisador de IA na AIMultiple, com foco em automação inteligente, GPUs, agentes de IA e frameworks RAG.

Ver perfil completo

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.

Nome

Endereço de email

Comentário

0/450

Postar comentário