RAG Frameworks: LangChain vs LangGraph vs LlamaIndex

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

RAG frameworks: resultados do benchmark

O benchmark consistiu em 100 consultas, com cada framework a executar 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 conclusões. Menor = menor custo de API.
• Sobrecarga da Framework: Tempo puro de orquestração (ms), o processamento interno da framework (lógica de roteamento, gestão de estado, etc.), excluindo chamadas LLM API e ferramentas. Menor = framework mais enxuta.

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

Principais Descobertas

1. Concentramo-nos em controlar o que é controlável: Mesma família de modelos e temperaturas, max_tokens ao nível do nó, recuperador (Qdrant + BGE-small, k=5, normalização ativada), provedor web (apenas Tavily), política de roteamento (heurística + modelo), retorno antecipado da calculadora, limite partilhado de tokens de contexto, rubrica de avaliação idêntica, instrumentação unificada. Isto reduz substancialmente os principais fatores de confusão nas nossas medições.
2. A sobrecarga da framework é mensurável mas pequena: Observámos ~3–14 ms por consulta provenientes da lógica de orquestração. Estas 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 é gasto em I/O com modelos/ferramentas externos.
3. O desempenho acompanha os tokens (sob estas restrições): O DSPy apresenta a menor sobrecarga de framework (~3,53 ms). O Haystack (~5,9 ms) e o LlamaIndex (~6 ms) seguem-se, enquanto o LangChain (~10 ms) e o LangGraph (~14 ms) são mais elevados. O uso de tokens é mais baixo para o Haystack (~1,57k), depois o LlamaIndex (~1,60k); o DSPy e o LangGraph estão ~2,03k, e o LangChain ~2,40k.
4. O caminho de roteamento/ferramenta importa: Pequenas mudanças no roteamento inicial (recuperador vs. web vs. calculadora) e no comportamento de fallback afetam tanto os tokens como o tempo, mesmo quando os prompts e orçamentos estão alinhados.

Por que persistem as diferenças? O "ADN da Framework"

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

• Serialização de prompts e mensagens: Cada framework envolve o mesmo conteúdo lógico com formatação ligeiramente diferente antes de o enviar ao LLM, criando deltas de tokens pequenos mas consistentes.
• Montagem de contexto: A ordenação 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 subtis na forma como uma 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 da framework.

A arquitetura RAG agêntica partilhada

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

• Roteador: Um nó híbrido de modelo e heurística que escolhe entre recuperador, pesquisa web ou calculadora.
• Recuperar Documentos: Obtém os 5 principais documentos do Qdrant usando embeddings BGE-small normalizados.
• Avaliar Documentos: Um juiz LLM avalia a relevância dos documentos. Se irrelevantes, aciona um fallback de pesquisa web.
• Gerar Resposta: Usa um LLM com temperatura=0,0 e um limite partilhado de tokens de contexto para gerar um rascunho de resposta.
• Avaliar Resposta: Um segundo juiz LLM avalia o rascunho quanto a fundamentação, contradições (alucinações) e completude.
• Fallback e Retorno Antecipado: Uma pesquisa web é acionada se a avaliação da resposta for insuficiente. Os resultados da calculadora, no entanto, são devolvidos diretamente, saltando os passos de geração e avaliação.

Exemplos de Fluxo de Trabalho

Cenário A — Acerto direto da base de dados:

Cenário B — Evento recente aciona ferramenta web:

Cenário C — Calculadora proporciona um retorno antecipado:

Cenário D — Base de dados vetorial insuficiente, recorre a pesquisa web:

Metodologia das frameworks RAG

Todas as cinco implementações alcançaram 100% de precisão no nosso conjunto de teste de 100 consultas, correspondendo às respostas de referência. Este foi o requisito fundamental, garantindo que cada framework conseguia executar com sucesso o mesmo fluxo de trabalho RAG agêntico 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 origem.

• LLMs:
  • Modelo: Todos os nós (roteador, gerador, avaliador) usaram o modelo openai/gpt-4.1-mini via API do OpenRouter.
  • 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: Foram aplicados limites rigorosos de max_tokens: 256 para o roteador e avaliadores, e 512 para o gerador. Isto evita diferenças de latência causadas por uma framework gerar respostas excessivamente longas.
• Modelo de embedding e recuperação:
  • Modelo: Todas as frameworks usaram BAAI/bge-small-en-v1.5 do HuggingFace.
  • Normalização: Um passo crítico para o desempenho, normalize_embeddings foi definido como True nas cinco frameworks. (LangChain/LangGraph via encode_kwargs; LlamaIndex via normalize=True; Haystack via normalize_embeddings; recuperador DSPy normalizado.)
  • Recuperação: A base de dados vetorial Qdrant foi consultada com k=5 (5 principais documentos) em todas as implementações.
• Ferramentas:
  • Pesquisa 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 controlo e política RAG

O processo de "tomada de decisão" do agente foi explicitamente espelhado em todos os aspetos.

• Lógica de roteamento: Uma estratégia de roteamento híbrida foi implementada nos cinco scripts para equilibrar a inteligência do modelo com regras determinísticas:
  1. Uma heurística baseada em regex (heuristic_route) verifica primeiro padrões óbvios de calculadora ou pesquisa web (ex.: símbolos matemáticos, anos como "2024").
  2. Um nó roteador LLM (router_node) toma então a 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 de o nó de geração de resposta (generate_answer) ser chamado, todo o contexto de documentos recuperados e resultados de pesquisa web são concatenados e depois truncados para um limite partilhado de 2000 tokens usando um utilitário comum truncate_to_token_budget. Isto garante que o LLM gerador em cada framework recebe uma entrada do mesmo tamanho exato, impedindo que qualquer framework seja beneficiada ou prejudicada pela verbosidade do seu contexto recuperado.
• Política de avaliação de respostas:
  • Rubrica leniente: O nó de avaliação de resposta (grade_answer) usa um prompt leniente idêntico em todas as 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 falhada do avaliador foi padronizada. Se a saída do avaliador não for JSON válido, o sistema assume por defeito uma avaliação permissiva (grounded=True, complete=True), imitando um cenário real onde não se desejaria que um parser frágil reprovasse uma resposta que, de outra forma, seria boa. O DSPy devolve campos estruturados (sem análise JSON), isto é registado 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 nó calculadora (calculator_node) define diretamente a resposta final (final_answer) e termina o fluxo de trabalho antecipadamente. Esta é uma otimização significativa que é aplicada de forma consistente, impedindo que o caminho da calculadora invoque desnecessariamente os LLMs de geração e avaliação de resposta.
• Alinhamento DSPy. Para manter a equidade com as linhas de base sem CoT, o DSPy usa dspy.Predict (sem CoT) para o Roteador e Gerador de Respostas. As assinaturas espelham os contratos dos nós das outras frameworks; quando disponíveis, as contagens de tokens usam o uso reportado 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 partilhados.

• Latência: Foi usado time.perf_counter() de alta precisão para todas as temporizações. A Sobrecarga da Framework é calculada consistentemente 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 de verdade para as métricas de tokens. A métrica "Média de Tokens" reportada nos resultados representa a soma cumulativa de todos os tokens de entrada (prompt) e saída (conclusão) para cada chamada LLM (ex.: roteador, avaliadores, gerador) dentro de um único fluxo de trabalho de consulta.
• Gestão 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 nós, garantindo que a lógica do fluxo de controlo opera sobre a mesma informação.

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

Interpretação dos resultados:

• Pode concluir-se: 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 caminhos de ferramentas.
  • Nesta configuração específica e altamente controlada, a sobrecarga da framework é negligenciável.
  • As diferenças de desempenho foram impulsionadas pela contagem de tokens e variações nos caminhos das ferramentas.
• Não se pode generalizar: Os resultados são específicos para esta arquitetura, modelos, prompts, recuperador e provedor web; alterar estes fatores pode mudar as classificações.

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

O desempenho não é o único fator; a sensação ao construir com uma framework é igualmente importante.

• LangGraph: O grafo declarativo
  Usa um paradigma de grafo em primeiro lugar. Definem-se nós e ligam-se com arestas (incluindo add_conditional_edges), para que o fluxo de controlo faça parte da arquitetura. O estado é tipado via TypedDict com atualizações ao estilo redutor (Annotated[…, add]).
  • Escolha LangGraph para: fluxos de trabalho complexos com múltiplos ramos, repetições e ciclos; a sua estrutura escala em robustez e manutenibilidade à medida que os agentes crescem.
• LlamaIndex: Orquestração imperativa
  Um script procedimental onde o fluxo de controlo é Python padrão if/else; o "grafo" vive no seu código. O estado é uma classe PipelineState dedicada, e a framework fornece primitivas de recuperação limpas (VectorStoreIndex → .as_retriever(k=5)).
  • Escolha LlamaIndex para: fluxos de trabalho legíveis, de ficheiro único, onde valoriza lógica procedimental clara e depuração fácil.
• LangChain: Imperativo com componentes declarativos
  A orquestração continua a ser um script Python, mas as tarefas individuais são pequenas cadeias componíveis usando o operador | (ex.: prompt | llm | parser). O estado é um dicionário Python flexível e não tipado.
  • Escolha LangChain para: Prototipagem rápida ou equipas já no ecossistema LangChain que preferem compor pequenas unidades declarativas dentro de um controlador imperativo maior.
• Haystack: Baseado em componentes, orquestração manual Componentes tipados e reutilizáveis (@component) com I/O explícito, enquanto o fluxo de controlo permanece Python simples (if/else). Fácil de trocar backends de LLM/recuperador/web, além de instrumentação por passo de primeira classe (tempo externo vs. framework).
  • Escolha Haystack para: pipelines prontos para produção, testáveis, com contratos claros e controlo refinado.
• DSPy: Programas com assinaturas em primeiro lugar (menos linhas de código)
  Define uma tarefa através de uma assinatura (entradas/saídas + intenção), depois implementa-a com Módulos que encapsulam prompting e chamadas LLM. Centraliza o tratamento de prompts/uso e elimina código de cola; trocar componentes internos (ex.: Predict ↔ CoT) não altera o contrato.
  • Escolha DSPy para: código boilerplate mínimo, fluxos legíveis de ficheiro único, desenvolvimento orientado por contratos (com otimizadores opcionais).

Trocar desempenho ótimo por comparabilidade

• LangGraph pode destacar-se com as suas otimizações nativas de grafo quando lhe é permitido usar execução paralela, cache de estado e o seu sistema de arestas condicionais para lógica de ramificação complexa.
• DSPy poderia mostrar resultados dramaticamente diferentes ao usar os seus otimizadores de assinatura (como MIPROv2) e prompting Chain-of-Thought, que podem melhorar significativamente a qualidade das respostas.
• Haystack poderia aproveitar as suas funcionalidades de cache e agrupamento prontas para produção, e otimizações ao nível dos componentes que desativámos para equidade.
• LlamaIndex poderia beneficiar das suas estratégias avançadas de indexação, motores de consulta e capacidades multimodais que não foram exercitadas neste benchmark.
• LangChain poderia brilhar com o seu extenso ecossistema de ferramentas e otimizações LCEL (LangChain Expression Language) quando não restringido ao nosso conjunto de ferramentas padronizado.

A "melhor" framework depende se está a otimizar para: velocidade de desenvolvimento, manutenibilidade, desempenho ou padrões arquitetónicos 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 benchmarks RAG, tais como:

• Modelos de Embedding: OpenAI vs Gemini vs Cohere
• Melhor Base de Dados Vetorial para RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark RAG agêntico: roteamento multi-base de dados e geração de consultas
• 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  = aug,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Acessado em 4 Agosto 2026}
}

Cem Dilmegani

Analista Principal

Siga-nos

Cem tem sido o analista principal do AIMultiple desde 2017. O AIMultiple informa centenas de milhares de empresas (de acordo com o similarWeb), incluindo 60% das empresas da Fortune 500 todos os meses.

O trabalho de Cem foi citado por publicações globais de destaque, incluindo Business Insider, Forbes, Washington Post, empresas globais como Deloitte, HPE e ONGs como o Fórum Econômico Mundial e organizações supranacionais como a Comissão Europeia.

Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor de tecnologia. Ele aconselhou empresas em 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 aquisições de uma empresa de telecomunicações, reportando-se ao CEO. Ele também liderou o crescimento comercial da empresa de tecnologia profunda Hypatos, que alcançou 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 de destaque como TechCrunch e Business Insider.

Cem fala regularmente em conferências internacionais de tecnologia. Ele se formou na Universidade Bogazici como engenheiro de computação 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 Analista 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