RAG Frameworks: LangChain vs LangGraph vs LlamaIndex

Abbiamo testato 5 framework RAG: 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 di token di ciascun framework.

Risultati del benchmark dei framework RAG

Il benchmark consisteva in 100 query, con ogni framework che esegue l'intero set 100 volte per fornire medie stabili.

• Token medi: Totale token consumati in tutte le chiamate LLM (router, valutatore documenti, valutatore risposta e generatore), inclusi prompt (con contesto recuperato) e completamenti. Più basso = minor costo API.
• Overhead del framework: Tempo di orchestrazione puro (ms), l'elaborazione interna del framework (logica di routing, gestione dello stato, ecc.), esclusi LLM API e chiamate agli strumenti. Più basso = framework più snello.

Tutte le implementazioni hanno raggiunto il 100% di accuratezza sul set di test. Sono stati utilizzati gli stessi modelli, temperature, provider di recupero, 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), politica del router (euristica + modello), ritorno anticipato della calcolatrice, limite di token di contesto condiviso, 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 gap di latenza >1 s; la maggior parte del tempo è spesa per I/O con modelli/strumenti esterni.
3. Le prestazioni seguono i token (sotto questi vincoli): DSPy mostra l'overhead di 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'uso di token è più basso per Haystack (~1.57k), poi LlamaIndex (~1.60k); DSPy e LangGraph sono ~2.03k, e LangChain ~2.40k.
4. Il percorso di routing/strumenti è importante: Piccoli cambiamenti nel routing iniziale (retriever vs. web vs. calcolatrice) e il comportamento di fallback influenzano sia i token che il tempo, anche quando prompt e budget sono allineati.

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

Nonostante la standardizzazione, permangono piccole variazioni nel conteggio dei token e nella latenza. Queste sono attribuibili ai comportamenti intrinseci di basso livello di ciascun framework, il loro “DNA”.

• Serializzazione di prompt e messaggi: Ogni framework racchiude lo stesso contenuto logico con una formattazione leggermente diversa prima di inviarlo al LLM, creando piccoli ma costanti delta di token.
• Assemblaggio del contesto: L'ordinamento preciso e l'inclusione di metadati all'interno del contesto concatenato possono differire leggermente tra i framework, influenzando il conteggio finale dei token.
• Spareggio del routing: In 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 di 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-euristico che sceglie retriever, web_search o calcolatrice.
• Recupera documenti: Recupera i primi 5 documenti da Qdrant utilizzando embedding BGE-small normalizzati.
• Valuta i documenti: Un giudice LLM valuta la pertinenza del documento. Se irrilevante, attiva un fallback di ricerca web.
• Genera risposta: Utilizza un LLM con temperature=0.0 e un limite di token di contesto condiviso per generare una bozza di risposta.
• Valuta la risposta: Un secondo giudice LLM valuta la bozza per fondatezza, contraddizioni (allucinazioni) e completezza.
• Fallback e ritorno anticipato: Una ricerca web viene attivata se il voto 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, fallback alla ricerca web:

Metodologia dei framework RAG

Tutte e cinque le implementazioni hanno raggiunto il 100% di accuratezza sul nostro set di test di 100 query, corrispondendo alle risposte di riferimento. Questo era il requisito fondamentale, che garantiva che ogni framework potesse eseguire con successo 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 utilizzato il modello openai/gpt-4.1-mini tramite l'API di OpenRouter.
  • Determinismo: La temperature è stata impostata a 0.0 per tutte le chiamate LLM per garantire la massima coerenza nel routing, nella generazione e nella valutazione.
  • Limiti di token: Sono stati applicati limiti rigorosi di max_tokens: 256 per il router e i valutatori, e 512 per il generatore. Ciò impedisce differenze di latenza causate dalla generazione di risposte eccessivamente lunghe da parte di un framework.
• Modello di embedding e recupero:
  • Modello: Tutti i framework hanno utilizzato BAAI/bge-small-en-v1.5 da HuggingFace.
  • Normalizzazione: Un passaggio critico per le prestazioni, normalize_embeddings è stato impostato su True in tutti e cinque i framework. (LangChain/LangGraph tramite encode_kwargs; LlamaIndex tramite normalize=True; Haystack tramite normalize_embeddings; il retriever DSPy è stato normalizzato.)
  • Recupero: Il vector store Qdrant è stato interrogato per k=5 (i 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 utilizzato la libreria sympy per l'analisi e la valutazione di espressioni matematiche, garantendo capacità identiche.

2. Flusso di controllo e politica RAG

Il processo di “decisione” dell'agente è stato esplicitamente replicato in tutti i framework.

• 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 i pattern ovvi della calcolatrice o della ricerca web (ad esempio, simboli matematici, anni come “2024”).
  2. Un LLM router_node prende poi la propria decisione.
  3. La decisione finale dà priorità all'euristica per la calcolatrice, altrimenti si affida alla scelta del LLM.
• Budget di contesto: Questa è una delle standardizzazioni più critiche. Prima che venga chiamato il nodo generate_answer, tutto il contesto del documento recuperato e i risultati della ricerca web vengono concatenati e quindi troncati a un limite condiviso di 2000 token utilizzando un'utilità comune truncate_to_token_budget. Ciò garantisce che il generatore LLM in ogni framework riceva un input della stessa identica dimensione, impedendo che un singolo framework venga avvantaggiato o svantaggiato dalla verbosità del contesto recuperato.
• Politica di valutazione della risposta:
  • Rubrica indulgente: Il nodo grade_answer utilizza un prompt identico e indulgente 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 dal valutatore è stata standardizzata. Se l'output del valutatore non è un JSON valido, il sistema predefinito passa a un voto permissivo (grounded=True, complete=True), simulando uno scenario reale in cui non si vorrebbe che un parser fragile facesse fallire una risposta altrimenti buona. DSPy restituisce campi strutturati (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 calcolatrice imposta direttamente la risposta finale e termina anticipatamente il flusso di lavoro. Questa è un'ottimizzazione significativa applicata in modo coerente, che evita che il percorso della calcolatrice invochi inutilmente i LLM di generazione e valutazione.
• Allineamento DSPy. Per mantenere l'equità con i riferimenti non-CoT, DSPy utilizza dspy.Predict (nessun CoT) per Router e AnswerGenerator. Le firme rispecchiano i contratti di nodo degli altri framework; ove disponibile, i conteggi dei token utilizzano l'uso riportato dal modello, altrimenti fallback tiktoken.

3. Strumentazione e metriche

Il processo di misura è stato identico, utilizzando utilità e principi condivisi.

• Latenza: È stato utilizzato time.perf_counter() ad alta precisione per tutti i tempi. L'overhead del framework è calcolato in modo coerente come Latenza totale – Latenza chiamate esterne.
• Tokenizzazione: Tutti i conteggi dei token per prompt e completamenti sono stati calcolati utilizzando tiktoken, la codifica cl100k_base, garantendo un'unica fonte di verità per le metriche dei token. La metrica “Token medi” 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 lavoro 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 del framework nell'ambito di una politica RAG fissa.

Interpretare i risultati:

• Si può concludere che: In questa configurazione specifica e altamente controllata, l'overhead di orchestrazione tende a essere minore; le differenze sono guidate 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 guidate dal conteggio dei token e dalle variazioni del percorso degli strumenti.
• Non si può 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; l'esperienza di sviluppo con un framework è altrettanto importante.

• LangGraph: Il grafo dichiarativo
  Utilizza un paradigma graph-first. Si definiscono i nodi e li si collegano con archi (inclusi add_conditional_edges), in modo che il flusso di controllo faccia 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 PipelineState dedicata e il framework fornisce primitive di recupero pulite (VectorStoreIndex → .as_retriever(k=5)).
  • Scegli LlamaIndex per: flussi di lavoro leggibili, a file singolo, dove si apprezza una chiara logica procedurale e un facile debugging.
• LangChain: Imperativo con componenti dichiarativi
  L'orchestrazione rimane uno script Python, ma i singoli compiti sono piccole catene componibili che utilizzano l'operatore | (ad esempio, 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: A componenti, orchestrazione manuale Componenti tipizzati e riutilizzabili (@component) con I/O esplicito, mentre il flusso di controllo rimane Python semplice (if/else). Facile scambiare i backend LLM/retriever/web, oltre a una strumentazione di prima classe per passo (tempo esterno vs. framework).
  • Scegli Haystack per: pipeline pronte per la produzione, testabili, con contratti chiari e controllo a grana fine.
• DSPy: Programmi signature-first (meno righe di codice)
  Definisci un compito tramite una firma (input/output + intento), quindi lo implementi con Moduli che incapsulano il prompting e le chiamate LLM. Centralizza la gestione di prompt e utilizzo e rimuove il codice di collante; scambiare gli interni (ad esempio, Predict ↔ CoT) non cambia il contratto.
  • Scegli DSPy per: boilerplate minimo, flussi leggibili a file singolo, sviluppo orientato ai contratti (con ottimizzatori opzionali).

Scambiare le prestazioni ottimali per la confrontabilità

• LangGraph potrebbe eccellere con le sue ottimizzazioni native del grafo quando gli è consentito di utilizzare l'esecuzione parallela, la cache di stato e il suo sistema di archi condizionali per la logica di ramificazione complessa.
• DSPy potrebbe mostrare risultati notevolmente diversi quando si utilizzano i suoi ottimizzatori di firma (come MIPROv2) e il prompting Chain-of-Thought, che possono migliorare significativamente la qualità della risposta.
• Haystack potrebbe sfruttare la sua cache pronta per la produzione, le funzionalità di batching e le ottimizzazioni a livello di componente che abbiamo disabilitato per l'equità.
• LlamaIndex potrebbe beneficiare delle sue strategie di indicizzazione avanzate, dei motori di query e delle capacità multi-modali 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 da cosa si ottimizza: velocità di sviluppo, manutenibilità, prestazioni o modelli architetturali specifici.

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

Ulteriori letture

Esplora altri benchmark RAG, come:

• Modelli di embedding: OpenAI vs Gemini vs Cohere
• Miglior database vettoriale per RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark RAG agentico: routing multi-database e generazione di query
• RAG ibrido: aumentare l'accuratezza del RAG

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 Frameworks: LangChain vs LangGraph vs LlamaIndex}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/rag-frameworks}},
  note   = {AIMultiple. Consultato il 4 Agosto 2026}
}

Cem Dilmegani

Analista principale

Segui

Cem è l'analista principale di AIMultiple dal 2017. AIMultiple informa centinaia di migliaia di aziende (secondo SimilarWeb) compreso il 60% delle Fortune 500 ogni mese.

Il lavoro di Cem è stato citato da importanti pubblicazioni globali tra cui Business Insider, Forbes, Washington Post, aziende globali come Deloitte, HPE e ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione europea.

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

Ha guidato la strategia tecnologica e gli approvvigionamenti di una società di telecomunicazioni rispondendo direttamente al CEO. Ha anche guidato la crescita commerciale dell'azienda deep tech Hypatos che ha raggiunto un fatturato annuo ricorrente a 7 cifre e una valutazione a 9 cifre partendo da 0 in 2 anni. Il lavoro di Cem in Hypatos è stato trattato da importanti pubblicazioni tecnologiche come TechCrunch e Business Insider.

Cem interviene regolarmente a conferenze tecnologiche internazionali. Si è laureato in ingegneria informatica all'Università Bogazici e ha conseguito un MBA presso la Columbia Business School.

Visualizza il profilo completo

Ricercato da

Ekrem Sarı

Ricercatore AI

Segui

Ekrem è Ricercatore AI e analista di dati presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di AI 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