RAG Framework: LangChain vs LangGraph vs LlamaIndex

Abbiamo confrontato 5 RAG framework: LangChain, LangGraph, LlamaIndex, Haystack e DSPy, costruendo lo stesso flusso di lavoro RAG agentico con componenti standardizzati: modelli identici (GPT-4.1-mini), embedding (BGE-small), retriever (Qdrant) e strumenti (ricerca web Tavily). Questo isola il vero overhead e l'efficienza dei token di ciascun framework.

RAG framework: risultati del benchmark

Il benchmark era composto da 100 query, e ciascun framework ha eseguito l'intero set 100 volte per fornire medie stabili.

• Media token: Totale dei token consumati in tutte le chiamate LLM (router, valutatore dei documenti, valutatore delle risposte e generatore), include sia i prompt (con contesto recuperato) sia i completamenti. Meno token = minore costo API.
• Overhead del framework: Tempo di orchestrazione puro (ms), l'elaborazione interna del framework (logica di routing, gestione dello stato, ecc.), escluse le chiamate LLM API e agli strumenti. Più basso = framework più snello.

Tutte le implementazioni hanno raggiunto un'accuratezza del 100% sul set di test. Hanno utilizzato gli stessi modelli, temperature, provider di retrieval, strumento di ricerca web e un limite condiviso di token di contesto.

Risultati principali

1. Ci concentriamo sul controllo di ciò che è controllabile: stessa famiglia di modelli e temperature, max_tokens a livello di nodo, retriever (Qdrant + BGE-small, k=5, normalizzazione attiva), provider web (solo Tavily), policy del router (euristica + modello), ritorno anticipato della calcolatrice, limite condiviso di token di contesto, rubrica di valutazione identica, strumentazione unificata. Ciò riduce sostanzialmente i principali fattori confondenti nelle nostre misurazioni.
2. L'overhead del framework è misurabile ma contenuto: abbiamo osservato circa 3–14 ms per query dalla logica di orchestrazione. Queste differenze sono reali, ma non sono la principale fonte dei divari di latenza superiori a 1 s; la maggior parte del tempo è impiegata in I/O con modelli e strumenti esterni.
3. Le prestazioni seguono i token (in base a questi vincoli): DSPy mostra l'overhead del framework più basso (~3.53 ms). Haystack (~5.9 ms) e LlamaIndex (~6 ms) seguono, mentre LangChain (~10 ms) e LangGraph (~14 ms) sono più alti. L'utilizzo di token è più basso per Haystack (~1.57k), poi LlamaIndex (~1.60k); DSPy e LangGraph sono circa 2.03k, e LangChain circa 2.40k.
4. Il routing e il percorso degli strumenti contano: piccoli cambiamenti nel routing iniziale (retriever vs web vs calcolatrice) e nel comportamento di fallback influenzano sia i token sia i tempi, anche quando prompt e budget sono allineati.

Perché le differenze persistono? Il “DNA del framework”

Nonostante la standardizzazione, restano piccole variazioni nel numero di token e nella latenza. Queste sono attribuibili ai comportamenti intrinseci e di basso livello di ciascun framework, al loro “DNA”.

• Serializzazione di prompt e messaggi: ogni framework incapsula lo stesso contenuto logico con una formattazione leggermente diversa prima di inviarlo al LLM, creando piccole ma costanti differenze di token.
• Assemblaggio del contesto: l'ordine preciso e l'inclusione dei metadati nel contesto concatenato possono variare leggermente in base al framework, influenzando il conteggio finale dei token.
• Spareggio nel routing: nei casi limite, sottili differenze nel modo in cui un framework analizza l'output JSON del router possono portare a una scelta iniziale diversa dello strumento.

In questa configurazione, l'impronta dei token sembra essere il fattore principale, più del tempo di esecuzione del framework.

L'architettura RAG agentica condivisa

Per ottenere un confronto equo, tutte e cinque le implementazioni sono state costruite sullo stesso flusso di controllo:

• Router: un nodo ibrido modello-euristica che sceglie tra retriever, web_search o calcolatrice.
• Recupera documenti: recupera i primi 5 documenti da Qdrant usando embedding BGE-small normalizzati.
• Valuta documenti: un giudice LLM valuta la pertinenza dei documenti. Se non pertinenti, attiva un fallback di ricerca web.
• Genera risposta: utilizza un temperature=0.0 LLM con un limite condiviso di token di contesto per generare una bozza di risposta.
• Valuta risposta: un secondo giudice LLM valuta la bozza per fondatezza, contraddizioni (allucinazioni) e completezza.
• Fallback e ritorno anticipato: viene attivata una ricerca web se la valutazione della risposta è insufficiente. I risultati della calcolatrice, invece, vengono restituiti direttamente, saltando i passaggi di generazione e valutazione.

Esempi di flusso di lavoro

Scenario A — Riscontro diretto dal database:

Scenario B — Un evento recente attiva lo strumento web:

Scenario C — La calcolatrice fornisce un ritorno anticipato:

Scenario D — Database vettoriale insufficiente, ripiega sulla ricerca web:

RAG framework: metodologia

Tutte e cinque le implementazioni hanno raggiunto un'accuratezza del 100% sul nostro set di test di 100 query, corrispondenti alle risposte di riferimento. Questo era il requisito fondamentale, garantendo che ogni framework potesse eseguire correttamente lo stesso flusso di lavoro RAG agentico prima di misurare le differenze di prestazioni.

1. Componenti principali e configurazione

Gli strumenti fondamentali sono stati standardizzati per eliminare le variabili di prestazione alla fonte.

• LLM:
  • Modello: tutti i nodi (router, generatore, valutatore) hanno usato il modello openai/gpt-4.1-mini tramite OpenRouter API.
  • Determinismo: la temperature è stata impostata a 0.0 per tutte le chiamate LLM per garantire la massima coerenza in routing, generazione e valutazione.
  • Limiti di token: sono stati applicati limiti rigorosi di max_tokens: 256 per router e valutatori, e 512 per il generatore. Ciò previene differenze di latenza causate da un framework che genera risposte eccessivamente lunghe.
• Modello di embedding e retrieval:
  • Modello: tutti i framework hanno usato BAAI/bge-small-en-v1.5 da HuggingFace.
  • Normalizzazione: un passaggio critico per le prestazioni, normalize_embeddings è stato impostato a True in tutti e cinque i framework. (LangChain/LangGraph tramite encode_kwargs; LlamaIndex tramite normalize=True; Haystack tramite normalize_embeddings; retriever DSPy normalizzato.)
  • Retrieval: il vector store Qdrant è stato interrogato con k=5 (primi 5 documenti) in tutte le implementazioni.
• Strumenti:
  • Ricerca web: il benchmark è stato limitato a solo Tavily (max_results=3).
  • Calcolatrice: tutte e cinque le implementazioni hanno usato la libreria sympy per l'analisi e la valutazione delle espressioni matematiche, garantendo capacità identiche.

2. Controllo del flusso RAG e policy

Il processo decisionale dell'agente è stato replicato esplicitamente in modo uniforme.

• Logica di routing: una strategia di routing ibrida è stata implementata in tutti e cinque gli script per bilanciare l'intelligenza del modello con regole deterministiche:
  1. Un heuristic_route basato su regex controlla prima la presenza di modelli evidenti di calcolatrice o ricerca web (ad esempio simboli matematici, anni come “2024”).
  2. Un LLM router_node prende quindi la propria decisione.
  3. La decisione finale dà priorità all'euristica per le calcolatrici, altrimenti si affida alla scelta del LLM.
• Gestione del budget di contesto: questa è una delle standardizzazioni più critiche. Prima che venga chiamato il nodo generate_answer, tutto il contesto dei documenti recuperati e i risultati della ricerca web vengono concatenati e quindi troncati a un limite condiviso di 2000 token usando un'utilità comune truncate_to_token_budget. Ciò garantisce che il LLM generatore in ciascun framework riceva un input della stessa identica dimensione, impedendo che un singolo framework venga avvantaggiato o svantaggiato dalla verbosità del contesto recuperato.
• Policy di valutazione delle risposte:
  • Rubrica permissiva: il nodo grade_answer usa un prompt identico e permissivo in tutti i framework, istruendo il giudice LLM ad accettare risposte semanticamente simili e ragionevolmente complete.
  • Gestione degli errori: la logica per gestire un parsing JSON fallito da parte del valutatore è stata standardizzata. Se l'output del valutatore non è JSON valido, il sistema ricorre a una valutazione permissiva (grounded=True, complete=True), imitando uno scenario reale in cui non si vorrebbe che un parser fragile respinga una risposta altrimenti valida. I campi strutturati di DSPy restituiscono (nessun parsing JSON); questo viene registrato come differenza di robustezza, non come vantaggio prestazionale.
• Ritorno anticipato della calcolatrice: come si vede nel codice, una chiamata riuscita al nodo calculator_node imposta direttamente final_answer e termina anticipatamente il flusso di lavoro. Si tratta di un'ottimizzazione significativa applicata in modo coerente, che impedisce al percorso della calcolatrice di invocare inutilmente i modelli LLM di generate e grade_answer.
• Allineamento di DSPy. Per mantenere l'equità con le baseline non-CoT, DSPy usa dspy.Predict (no CoT) per Router e AnswerGenerator. Le firme rispecchiano i contratti dei nodi degli altri framework; dove disponibili, i conteggi dei token usano l'utilizzo riportato dal modello, altrimenti il fallback tiktoken.

3. Strumentazione e metriche

Il processo di misurazione era identico, utilizzando utilità e principi condivisi.

• Latenza: è stato usato time.perf_counter() ad alta precisione per tutte le misurazioni dei tempi. L'overhead del framework viene calcolato in modo coerente come Latenza totale – Latenza delle chiamate esterne.
• Tokenizzazione: tutti i conteggi dei token per prompt e completamenti sono stati calcolati usando tiktoken, la codifica cl100k_base, garantendo un'unica fonte di verità per le metriche dei token. La metrica "Media token" riportata nei risultati rappresenta la somma cumulativa di tutti i token di input (prompt) e output (completamento) per ogni chiamata LLM (ad esempio router, valutatori, generatore) all'interno di un singolo flusso di query.
• Gestione dello stato: sebbene la sintassi di implementazione vari (TypedDict di LangGraph, classe di LlamaIndex, dizionario di LangChain), la struttura dello stato è funzionalmente identica. Ogni framework passa lo stesso insieme di chiavi (question, documents, web_results, ecc.) tra i nodi, garantendo che la logica del flusso di controllo operi sulle stesse informazioni.

Applicando queste rigorose standardizzazioni a livello di codice, questo benchmark mira ad andare oltre i confronti superficiali e offrire un'analisi replicabile delle prestazioni dei framework con una policy RAG fissa.

Interpretazione dei risultati:

• Puoi concludere: in questa configurazione specifica e altamente controllata, l'overhead di orchestrazione tende a essere minore; le differenze sono determinate principalmente dai conteggi dei token e dai percorsi degli strumenti.
  • In questa configurazione specifica e altamente controllata, l'overhead del framework è trascurabile.
  • Le differenze di prestazioni sono state determinate dal conteggio dei token e dalle variazioni nei percorsi degli strumenti.
• Non puoi generalizzare: i risultati sono specifici per questa architettura, modelli, prompt, retriever e provider web; modificarli può alterare le classifiche.

Esperienza dello sviluppatore: un confronto qualitativo

Le prestazioni non sono l'unico fattore; è altrettanto importante come ci si trova a sviluppare con un framework.

• LangGraph: il grafo dichiarativo
  Usa un paradigma graph-first. Si definiscono i nodi e li si collegano con archi (incluso add_conditional_edges), così il flusso di controllo fa parte dell'architettura. Lo stato è tipizzato tramite un TypedDict con aggiornamenti in stile reducer (Annotated[…, add]).
  • Scegli LangGraph per: flussi di lavoro complessi con più rami, tentativi e cicli; la sua struttura scala in robustezza e manutenibilità man mano che gli agenti crescono.
• LlamaIndex: orchestrazione imperativa
  Uno script procedurale in cui il flusso di controllo è un normale if/else Python; il “grafo” vive nel codice. Lo stato è una classe dedicata PipelineState e il framework fornisce primitive di retrieval pulite (VectorStoreIndex → .as_retriever(k=5)).
  • Scegli LlamaIndex per: flussi di lavoro leggibili in un singolo file, dove apprezzi una logica procedurale chiara e un facile debugging.
• LangChain: imperativo con componenti dichiarative
  L'orchestrazione rimane uno script Python, ma le singole attività sono piccole, componibili chain con l'operatore | (ad es. prompt | llm | parser). Lo stato è un dizionario Python flessibile e non tipizzato.
  • Scegli LangChain per: prototipazione rapida o team già nell'ecosistema LangChain che preferiscono comporre piccole unità dichiarative all'interno di un driver imperativo più ampio.
• Haystack: orchestrazione manuale basata su componenti Componenti tipizzati e riutilizzabili (@component) con I/O esplicito, mentre il flusso di controllo rimane Python semplice (if/else). È facile sostituire i backend LLM/retriever/web, oltre a una strumentazione di prima classe per ogni passaggio (tempo esterno vs tempo del framework).
  • Scegli Haystack per: pipeline pronte per la produzione, testabili e con contratti chiari e controllo a grana fine.
• DSPy: programmi signature-first (meno righe di codice)
  Si definisce un'attività tramite una signature (input/output + intento), poi la si implementa con Moduli che incapsulano prompting e chiamate LLM. Centralizza la gestione di prompt e utilizzo ed elimina il glue code; sostituire gli interni (ad esempio Predict ↔ CoT) non cambia il contratto.
  • Scegli DSPy per: boilerplate minimo, flussi leggibili in un singolo file, sviluppo guidato dai contratti (con ottimizzatori opzionali).

Rinunciare alle prestazioni ottimali per la comparabilità

• LangGraph potrebbe eccellere con le sue ottimizzazioni native dei grafi quando è possibile utilizzare l'esecuzione parallela, la cache dello stato e il suo sistema di archi condizionali per logiche di ramificazione complesse.
• DSPy potrebbe mostrare risultati notevolmente diversi utilizzando i suoi ottimizzatori di signature (come MIPROv2) e il prompt Chain-of-Thought, che possono migliorare significativamente la qualità delle risposte.
• Haystack potrebbe sfruttare caching pronto per la produzione, funzionalità di batching e ottimizzazioni a livello di componenti che abbiamo disabilitato per equità.
• LlamaIndex potrebbe beneficiare delle sue strategie di indicizzazione avanzate, dei motori di query e delle capacità multimodali che non sono state esercitate in questo benchmark.
• LangChain potrebbe brillare con il suo vasto ecosistema di strumenti e le ottimizzazioni LCEL (LangChain Expression Language) quando non è vincolato al nostro set di strumenti standardizzato.

Il framework “migliore” dipende dall'obiettivo che si ottimizza: velocità di sviluppo, manutenibilità, prestazioni o specifici pattern architetturali.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Per approfondire

Esplora altri RAG benchmark, come:

• Modelli di embedding: OpenAI vs Gemini vs Cohere
• I migliori database vettoriali per RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark RAG agentico: routing multi-database e generazione di query

Cita questo benchmark

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Sarı, Ekrem},
  title  = {{RAG Framework: LangChain vs LangGraph vs LlamaIndex}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Consultato il 31 Agosto 2026}
}

Registro delle modifiche

7 aggiornamenti

Tutte7Generale5Metodologia2

1. 202629 Gen

   Aggiunto il numero di query e di esecuzioni alla metodologia di benchmark.

2. 27 Gen

   Aggiornati i risultati e la metodologia del benchmark dei framework RAG.

3. 202510 Nov

   Aggiunta la definizione di token medi e overhead del framework ai risultati del benchmark dei framework RAG.

4. 1 Nov

   Dati sulle prestazioni sostituiti nella sezione Risultati Chiave.

5. 1 Nov

   Sostituita la descrizione della metodologia nella sezione dei framework RAG.

6. 31 Ott

   Aggiunti Haystack e DSPy al confronto dei framework RAG.

7. 31 Ott

   Aggiornato il numero di implementazioni nella sezione metodologia.

Cem Dilmegani

Analista principale

Segui

Cem è analista principale presso AIMultiple dal 2017.

Il lavoro di Cem presso AIMultiple è stato citato da importanti testate internazionali tra cui Business Insider, Forbes, Morning Brew e Washington Post, da aziende globali come Deloitte e HPE, da ONG come il World Economic Forum e da organizzazioni sovranazionali come la Commissione europea. [1], [2], [3], [4], [5]

Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, acquirente tecnologico e imprenditore tecnologico. Ha consigliato le aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per più di un decennio. Ha inoltre pubblicato un report McKinsey sulla digitalizzazione.

Ha guidato la strategia tecnologica e gli approvvigionamenti di una società di telecomunicazioni rispondendo direttamente al CEO. Ha inoltre guidato la crescita commerciale dell'azienda deep tech Hypatos, che ha raggiunto ricavi ricorrenti annuali a 7 cifre e una valutazione a 9 cifre partendo da zero in 2 anni. Il lavoro di Cem in Hypatos è stato ripreso da importanti testate tecnologiche come TechCrunch e Business Insider.

Cem interviene regolarmente a conferenze tecnologiche internazionali. Si è laureato come ingegnere informatico presso l'Università di Bogazici e possiede un MBA della Columbia Business School.

Visualizza il profilo completo

Ricercato da

Ekrem Sarı

Ricercatore IA

Segui

Ekrem è un Ricercatore IA e Data Scientist presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di IA e LLM.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento