RAG Frameworks: LangChain vs LangGraph vs LlamaIndex

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

RAG frameworks benchmark resultados

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 LLM (roteador, avaliador de documentos, avaliador de respostas e gerador), inclui tanto prompts (com contexto recuperado) quanto completamentos. 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 teste. Usaram os mesmos modelos, temperaturas, provedor de recuperação, ferramenta de busca na web e um limite de tokens de contexto compartilhado.

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 web (somente Tavily), política do roteador (heurística + modelo), retorno antecipado da calculadora, limite de tokens de contexto compartilhado, 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 >1 s; a maior parte do tempo é gasta em I/O com modelos/ferramentas externos.
3. O desempenho acompanha os tokens (sob essas restrições): DSPy apresenta a menor sobrecarga de framework (~3.53 ms). Haystack (~5.9 ms) e LlamaIndex (~6 ms) vêm em seguida, enquanto LangChain (~10 ms) e LangGraph (~14 ms) são mais altas. O uso de tokens é menor no Haystack (~1.57k), depois LlamaIndex (~1.60k); DSPy e LangGraph ficam em ~2.03k, e LangChain ~2.40k.
4. O caminho de roteamento/ferramentas 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 nas contagens de tokens e na latência permanecem. Elas são atribuíveis aos comportamentos inerentes e de baixo nível de cada framework, seu “DNA”.

• Serialização de prompts & mensagens: Cada framework envolve o mesmo conteúdo lógico com formatação ligeiramente diferente antes de enviá-lo ao LLM, criando pequenas, mas consistentes, diferenças de tokens.
• Montagem do contexto: A ordenação precisa e a inclusão de metadados no contexto concatenado podem variar 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 fator, mais do que o tempo de execução do framework.

A arquitetura agêntica RAG compartilhada

Para obter 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 no Qdrant usando embeddings BGE-small normalizados.
• Avaliar Documentos: Um juiz LLM avalia a relevância dos documentos. Se irrelevantes, aciona um fallback de busca na web.
• Gerar Resposta: Usa uma temperatura=0.0 LLM com um limite de tokens de contexto compartilhado para gerar uma resposta provisória.
• Avaliar Resposta: Um segundo juiz LLM avalia o rascunho quanto à fundamentação, contradições (alucinações) e completude.
• Fallback & Retorno Antecipado: Uma busca na web é acionada se a nota da resposta for insuficiente. Os resultados da calculadora, no entanto, são retornados diretamente, pulando as etapas de geração e avaliação.

Exemplos de Fluxo de Trabalho

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

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

Cenário C — A calculadora fornece um retorno antecipado:

Cenário D — Banco de dados vetorial insuficiente, recorre à busca na web:

RAG frameworks metodologia

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

1. Componentes principais & configuração

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

• LLMs:
  • Modelo: Todos os nós (roteador, gerador, avaliador) usaram o modelo openai/gpt-4.1-mini por meio da OpenRouter API.
  • Determinismo: a temperatura foi definida como 0.0 para todas as chamadas LLM, para garantir a máxima consistência no roteamento, geração e avaliação.
  • Limites de tokens: Limites rigorosos 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 & 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; DSPy retriever normalizado.)
  • Recuperação: O banco de dados vetorial Qdrant foi consultado com k=5 (5 principais documentos) em todas as implementações.
• Ferramentas:
  • Busca na web: O benchmark foi restrito a somente 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. RAG fluxo de controle & política

O processo de “tomada de decisão” do agente foi explicitamente espelhado em todos os aspectos.

• 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 heuristic_route baseada em regex primeiro verifica padrões óbvios de calculadora ou busca na web (por exemplo, símbolos matemáticos, anos como “2024”).
  2. Um 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, segue a 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 dos documentos recuperados e os resultados da busca na web são concatenados e então 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 exatamente do mesmo tamanho, evitando que qualquer framework seja favorecido ou prejudicado pela verbosidade do contexto recuperado.
• Política de avaliação de respostas:
  • Rubrica leniente: O nó grade_answer usa um prompt leniente idêntico 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 falha de análise de JSON do avaliador foi padronizada. Se a saída do avaliador não for JSON válido, o sistema assume uma avaliação permissiva (grounded=True, complete=True), imitando um cenário real em que você não gostaria que um parser frágil reprovasse uma resposta que de outra forma seria boa. Os campos estruturados do DSPy retornam (sem análise de JSON); isso é registrado como uma diferença de robustez, não como uma vantagem de desempenho.
• Retorno antecipado da calculadora: Como visto no código, uma chamada bem-sucedida ao calculator_node define diretamente a final_answer e encerra o fluxo de trabalho antecipadamente. Essa é uma otimização significativa aplicada de forma consistente, evitando que o caminho da calculadora invoque desnecessariamente os LLMs de generate e grade_answer.
• Alinhamento do DSPy. Para manter a justiça com baselines sem CoT, o DSPy usa dspy.Predict (sem CoT) para Router e AnswerGenerator. As assinaturas espelham os contratos de nós de outros frameworks; quando disponíveis, as contagens de tokens usam o uso relatado pelo modelo; caso contrário, fallback do tiktoken.

3. Instrumentação e métricas

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

• Latência: Foi usado time.perf_counter() de alta precisão para todas as medições de tempo. A Sobrecarga do Framework é calculada consistentemente como Latência Total – Latência das Chamadas Externas.
• Tokenização: Todas as contagens de tokens para prompts e completamentos foram calculadas usando tiktoken, a codificação cl100k_base, garantindo uma única fonte de verdade para as 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 (completamento) de cada chamada 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 (question, documents, web_results, etc.) entre os nós, garantindo que a lógica do fluxo de controle opere sobre as mesmas informações.

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

Interpretando os resultados:

• Você pode concluir: Nesta configuração específica e altamente controlada, a sobrecarga de orquestração tende a ser menor; as diferenças são impulsionadas principalmente pelas contagens de tokens e pelos caminhos das ferramentas.
  • 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 pelas variações no caminho das ferramentas.
• Você não pode generalizar: Os resultados são específicos para esta arquitetura, modelos, prompts, retriever e provedor web; alterar esses elementos pode mudar as classificações.

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

O desempenho não é o único fator; como é a sensação de construir com um framework é igualmente importante.

• LangGraph: O grafo declarativo
  Usa um paradigma graph-first. Você define nós e os conecta com arestas (incluindo add_conditional_edges), de modo que o fluxo de controle faz parte da arquitetura. O estado é tipado via um TypedDict com atualizações no estilo reducer (Annotated[…, add]).
  • Escolha o LangGraph para: fluxos de trabalho complexos com múltiplas ramificações, tentativas e ciclos; sua estrutura escala em robustez e manutenibilidade à medida que os agentes crescem.
• LlamaIndex: Orquestração imperativa
  Um script procedural em que o fluxo de controle é o if/else padrão do Python; 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 o LlamaIndex para: fluxos de trabalho legíveis e de arquivo único, quando você valoriza lógica procedural clara e fácil depuração.
• LangChain: Imperativo com componentes declarativos
  Orquestração permanece um script Python, mas tarefas individuais são cadeias pequenas e componíveis usando o operador | (por exemplo, prompt | llm | parser). O estado é um dict Python flexível e não tipado.
  • Escolha o LangChain para: Prototipagem rápida ou equipes que já estão no ecossistema LangChain e preferem compor pequenas unidades declarativas dentro de um driver imperativo maior.
• Haystack: Orquestração manual baseada em componentes Componentes tipados e reutilizáveis (@component) com E/S explícita, enquanto o fluxo de controle permanece Python puro (if/else). Fácil trocar LLM/retriever/backends web, além de instrumentação de primeira classe por etapa (tempo externo vs. framework).
  • Escolha o Haystack para: pipelines prontos para produção, testáveis, com contratos claros e controle refinado.
• DSPy: Programas signature-first (menos linhas de código)
  Defina uma tarefa por meio de uma signature (entradas/saídas + intenção) e implemente-a com Modules que encapsulam prompting e chamadas LLM. Centraliza o tratamento de prompts/uso e remove código de cola; trocar internos (por exemplo, Predict ↔ CoT) não altera o contrato.
  • Escolha o DSPy para: boilerplate mínimo, fluxos legíveis de arquivo único, desenvolvimento orientado a contratos (com otimizadores opcionais).

Trocando desempenho ideal 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 arestas condicionais para lógica de ramificação complexa.
• DSPy pode apresentar resultados drasticamente diferentes ao usar seus otimizadores de signature (como MIPROv2) e prompting Chain-of-Thought, o que pode melhorar significativamente a qualidade das respostas.
• Haystack pode aproveitar seu cache pronto para produção, recursos de lote e otimizações no nível de componentes que desativamos para garantir justiça.
• LlamaIndex poderia se beneficiar de suas estratégias avançadas de indexação, mecanismos de consulta e capacidades multimodais que não foram exercitadas neste benchmark.
• LangChain pode brilhar com seu extenso ecossistema de ferramentas e otimizações de LCEL (LangChain Expression Language) quando não restrito ao nosso conjunto de ferramentas padronizado.

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

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

Leitura adicional

Explore outros RAG benchmarks, como:

• Modelos de Embedding: OpenAI vs Gemini vs Cohere
• Melhor Banco de Dados Vetorial para RAG: Qdrant vs Weaviate vs Pinecone
• Agêntico RAG benchmark: roteamento entre múltiplos bancos de dados e geração de consultas

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  = aug,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Acessado em 31 Agosto 2026}
}

Registro de alterações

7 atualizações

Todas7Geral5Metodologia2

1. 202629 Jan

   Adicionado o número de consultas e execuções à metodologia de benchmark.

2. 27 Jan

   Atualizados os resultados e a metodologia do benchmark de frameworks RAG.

3. 202510 Nov

   Adicionada a definição de tokens médios e sobrecarga da estrutura aos resultados do benchmark de estruturas RAG.

4. 1 Nov

   Dados de desempenho substituídos na seção Principais Descobertas.

5. 1 Nov

   Substituída a descrição da metodologia na seção de estruturas RAG.

6. 31 Out

   Adicionado Haystack e DSPy à comparação de frameworks RAG.

7. 31 Out

   Atualizado o número de implementações na seção de metodologia.

Cem Dilmegani

Analista Principal

Siga-nos

Cem é o analista principal da AIMultiple desde 2017.

O trabalho de Cem na AIMultiple foi citado por publicações globais líderes, incluindo Business Insider, Forbes, Morning Brew e Washington Post, por empresas globais como Deloitte e HPE, ONGs como o World Economic Forum e organizações supranacionais como a European Commission. [1], [2], [3], [4], [5]

Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor de tecnologia. Ele aconselhou empresas sobre suas decisões de tecnologia na McKinsey & Company e na Altman Solon por mais de uma década. Ele também publicou um relatório da McKinsey sobre digitalização.

Ele liderou a estratégia de tecnologia e as compras de uma operadora de telecomunicações, reportando-se ao CEO. Ele também liderou o crescimento comercial da empresa de deep tech Hypatos, que atingiu uma receita recorrente anual de 7 dígitos e uma avaliação de 9 dígitos partindo do zero em 2 anos. O trabalho de Cem na Hypatos foi coberto por publicações de tecnologia líderes como TechCrunch e Business Insider.

Cem fala regularmente em conferências internacionais de tecnologia. Ele se formou como engenheiro da computação pela Bogazici University e possui um MBA pela Columbia Business School.

Ver perfil completo

Pesquisado por

Ekrem Sarı

Pesquisador de IA

Siga-nos

Ekrem é Pesquisador de IA e Cientista de Dados na AIMultiple. Ele projeta e executa benchmarks práticos para sistemas de IA e LLM.

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