Framework RAG: LangChain vs LangGraph vs LlamaIndex

Abbiamo effettuato un benchmark su 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 permette di isolare il vero overhead e l'efficienza in termini di token di ciascun framework.

Risultati del benchmark dei framework RAG

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

• Token medi : Token totali consumati in tutte le chiamate LLM (router, valutatore di documenti, valutatore di risposte e generatore), inclusi sia i prompt (con contesto recuperato) che i completamenti. Un valore inferiore corrisponde a un costo API inferiore.
• Overhead del framework : tempo di orchestrazione puro (ms), ovvero l'elaborazione interna del framework (logica di routing, gestione dello stato, ecc.), escluse le chiamate API e agli strumenti LLM. Un valore inferiore indica un framework più snello.

Tutte le implementazioni hanno raggiunto una precisione del 100% sul set di test. Sono stati utilizzati gli stessi modelli, temperature, provider di recupero, strumento di ricerca web e un limite condiviso per i token di contesto.

Principali risultati

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 di routing (euristica + modello), ritorno anticipato della calcolatrice, limite di token di contesto condiviso, rubrica di valutazione identica, strumentazione unificata. Questo riduce sostanzialmente i principali fattori confondenti nelle nostre misurazioni.
2. L'overhead del framework è misurabile ma ridotto : abbiamo osservato circa 3-14 ms per query dalla logica di orchestrazione. Queste differenze sono reali, ma non sono la causa principale dei gap di latenza superiori a 1 secondo; la maggior parte del tempo viene impiegata nelle operazioni di I/O con modelli/strumenti esterni.
3. Le prestazioni dei tracker dei token (sotto questi vincoli) : DSPy mostra il sovraccarico del framework più basso (~3,53 ms). Seguono Haystack (~5,9 ms) e LlamaIndex (~6 ms), mentre LangChain (~10 ms) e LangGraph (~14 ms) sono più elevati. L'utilizzo dei token è più basso per Haystack (~1,57k), poi LlamaIndex (~1,60k); DSPy e LangGraph sono ~2,03k e LangChain ~2,40k.
4. Il percorso/strumento è importante : lievi variazioni nel percorso iniziale (retriever vs. web vs. calcolatrice) e nel comportamento di fallback influiscono sia sui token che sui tempi, anche quando i prompt e i budget sono allineati.

Perché le differenze persistono? Il “DNA del quadro di riferimento”

Nonostante la standardizzazione, permangono piccole variazioni nel numero di token e nella latenza. Queste sono attribuibili ai comportamenti intrinseci 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 all'LLM, creando piccole ma coerenti differenze nei token.
• Assemblaggio del contesto: l'ordine preciso e l'inclusione dei metadati all'interno del contesto concatenato possono variare leggermente a seconda del framework, influenzando il conteggio finale dei token.
• Criteri di spareggio per il routing: nei casi limite, sottili differenze nel modo in cui un framework analizza l'output JSON del router possono portare a una diversa scelta iniziale dello strumento.

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

L'architettura RAG agentica condivisa

Per garantire un confronto equo, tutte e cinque le implementazioni sono state realizzate seguendo lo stesso flusso di controllo:

• Router: un nodo ibrido modello-euristico che sceglie retriever, web_search o calculator.
• Recupera documenti: recupera i 5 documenti principali da Qdrant utilizzando gli embedding BGE-small normalizzati.
• Valutazione dei documenti: un giudice LLM valuta la pertinenza dei documenti. Se non pertinenti, viene attivata una ricerca sul web come alternativa.
• Genera risposta: utilizza un LLM con temperatura=0,0 e un limite di token di contesto condiviso per generare una bozza di risposta.
• Risposta alla valutazione: Un secondo giudice LLM valuta la bozza in termini di fondatezza, contraddizioni (allucinazioni) e completezza.
• Fallback e restituzione anticipata: se il punteggio della risposta è insufficiente, viene attivata una ricerca sul web. I risultati della calcolatrice, invece, vengono restituiti direttamente, saltando le fasi di generazione e valutazione.

Esempi di flusso di lavoro

Scenario A — Accesso diretto dal database:

Scenario B — Strumento web attivato da un evento recente:

Scenario C — La calcolatrice consente un ritorno anticipato:

Scenario D — Database vettoriale insufficiente, si ricorre alla ricerca sul web:

metodologia dei framework RAG

Tutte e cinque le implementazioni hanno raggiunto un'accuratezza del 100% sul nostro set di test di 100 query, corrispondendo alle risposte reali. Questo era il requisito fondamentale, per garantire 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 OpenRouter.
  • Determinismo: la temperatura è stata impostata a 0,0 per tutte le chiamate LLM per garantire la massima coerenza nell'instradamento, nella generazione e nella valutazione.
  • Limiti dei token: sono stati imposti limiti rigorosi per il numero massimo di token: 256 per il router e i valutatori, e 512 per il generatore. Ciò impedisce differenze di latenza causate da un framework che genera risposte eccessivamente lunghe.
• Modello di incorporamento e recupero:
  • Modello: Tutti i framework utilizzati sono BAAI/bge-small-en-v1.5 di 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; DSPy retriever normalizzato.)
  • Recupero: Il database vettoriale Qdrant è stato interrogato per ak=5 (i 5 documenti principali) in tutte le implementazioni.
• Attrezzatura:
  • Ricerca sul web: il benchmark è stato limitato ai soli dati di Tavily (max_results=3).
  • Calcolatrice: tutte e cinque le implementazioni hanno utilizzato la libreria sympy per l'analisi e la valutazione delle espressioni matematiche, garantendo funzionalità identiche.

2. Flusso di controllo e politica RAG

Il processo decisionale dell'agente è stato esplicitamente replicato su tutta la linea.

• Logica di routing: in tutti e cinque gli script è stata implementata una strategia di routing ibrida per bilanciare l'intelligenza del modello con le regole deterministiche:
  1. Un percorso euristico basato su espressioni regolari verifica innanzitutto la presenza di schemi evidenti di calcolatrice o ricerca sul web (ad esempio, simboli matematici, anni come "2024").
  2. Un router_node LLM prende quindi la propria decisione.
  3. La decisione finale privilegia l'euristica per i calcolatori, altrimenti si affida alla scelta del LLM.
• Gestione del budget contestuale: 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 esattamente della stessa dimensione, impedendo che un singolo framework sia avvantaggiato o svantaggiato dalla verbosità del contesto recuperato.
• Criteri di valutazione delle risposte:
  • Rubrica indulgente: il nodo grade_answer utilizza una richiesta identica e indulgente in tutti i framework, istruendo il giudice LLM ad accettare risposte semanticamente simili e ragionevolmente complete.
  • Gestione degli errori: la logica per la gestione di un errore di analisi JSON da parte del valutatore è stata standardizzata. Se l'output del valutatore non è un JSON valido, il sistema imposta di default un voto permissivo (grounded=True, complete=True), simulando uno scenario reale in cui non si vorrebbe che un parser fragile scartasse una risposta altrimenti valida. I campi strutturati di DSPy restituiscono (nessun'analisi JSON), questo viene registrato come una differenza di robustezza, non come un vantaggio in termini di prestazioni.
• Ritorno anticipato della calcolatrice: come si può vedere nel codice, una chiamata riuscita al nodo della calcolatrice imposta direttamente la risposta finale e termina il flusso di lavoro in anticipo. Questa è un'ottimizzazione significativa che viene applicata in modo coerente, impedendo al percorso della calcolatrice di invocare inutilmente i LLM generate e grade_answer.
• Allineamento DSPy. Per mantenere l'equità con le baseline non CoT, DSPy utilizza dspy.Predict (senza CoT) per Router e AnswerGenerator. Le firme rispecchiano i contratti dei nodi di altri framework; ove disponibili, il conteggio dei token utilizza l'utilizzo riportato dal modello, altrimenti si ricorre al fallback di tiktoken.

3. Strumentazione e metriche

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

• Latenza: per tutti i calcoli di temporizzazione è stato utilizzato il metodo time.perf_counter() ad alta precisione. L'overhead del framework viene calcolato in modo coerente come Latenza totale – Latenza delle chiamate esterne.
• Tokenizzazione: Tutti i conteggi dei token per i prompt e i completamenti sono stati calcolati utilizzando tiktoken, con 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 set di chiavi (domanda, documenti, risultati web, ecc.) tra i nodi, garantendo che la logica di controllo del flusso operi sulle stesse informazioni.

Imponendo queste rigorose standardizzazioni a livello di codice, questo benchmark mira ad andare oltre i confronti superficiali e a offrire un'analisi replicabile delle prestazioni del framework in base a una politica RAG fissa.

Interpretazione dei risultati:

• Si può concludere: in questa specifica configurazione altamente controllata, il sovraccarico di orchestrazione tende ad essere minimo; le differenze sono determinate principalmente dal numero di token e dai percorsi degli strumenti.
  • In questa specifica configurazione altamente controllata, il sovraccarico del framework è trascurabile.
  • Le differenze di prestazioni erano determinate dal numero di token e dalle variazioni del percorso utensile.
• Non si possono generalizzare: i risultati sono specifici per questa architettura, questi modelli, questi prompt, questo sistema di recupero dati e questo provider web; la modifica di questi elementi può alterare le classifiche.

Esperienza degli sviluppatori: un confronto qualitativo

Le prestazioni non sono l'unico fattore; anche la sensazione che si prova a utilizzare un framework durante lo sviluppo è altrettanto importante.

• LangGraph: Il grafo dichiarativo
  Utilizza un paradigma "grafo-prima". Si definiscono i nodi e li si collega con gli archi (inclusi add_conditional_edges), quindi 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 ramificazioni, tentativi e cicli multipli; la sua struttura si adatta in termini di robustezza e manutenibilità man mano che il numero di agenti aumenta.
• LlamaIndex: Orchestrazione imperativa
  Uno script procedurale in cui il flusso di controllo è il classico if/else di Python; il "grafo" risiede nel tuo 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, basati su un singolo file, in cui apprezzi una logica procedurale chiara e un debug semplice.
• 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à presenti 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 in puro Python (if/else). Facile sostituzione dei backend LLM/retriever/web, oltre a una strumentazione di prim'ordine per ogni passaggio (tempo esterno vs. tempo del framework).
  • Scegli Haystack per: pipeline pronte per la produzione, testabili, con contratti chiari e controllo granulare.
• DSPy: Programmi con firma in primo piano (meno righe di codice)
  Definisci un'attività tramite una firma (input/output + intento), quindi implementala con moduli che incapsulano le richieste e le chiamate LLM. Centralizza la gestione delle richieste/dell'utilizzo ed elimina il codice di collegamento; lo scambio di componenti interni (ad esempio, Predict ↔ CoT ) non modifica il contratto.
  • Scegli DSPY per: codice ripetitivo ridotto al minimo, flussi di lavoro leggibili a file singolo, sviluppo guidato da contratti (con ottimizzatori opzionali).

Scambiare le prestazioni ottimali con la comparabilità

• LangGraph potrebbe eccellere grazie alle sue ottimizzazioni native per i grafi, se gli fosse consentito di utilizzare l'esecuzione parallela, la memorizzazione nella cache dello stato e il suo sistema di archi condizionali per la gestione di logiche di ramificazione complesse.
• DSPy potrebbe mostrare risultati drasticamente diversi quando si utilizzano i suoi ottimizzatori di firma (come MIPROv2) e il prompt Chain-of-Thought, che possono migliorare significativamente la qualità delle risposte.
• Haystack potrebbe sfruttare le sue funzionalità di caching, batching e ottimizzazione a livello di componente, già pronte per la produzione, che abbiamo disabilitato per garantire l'equità.
• LlamaIndex potrebbe trarre vantaggio dalle sue strategie di indicizzazione avanzate, dai motori di query e dalle funzionalità multimodali che non sono state sfruttate in questo benchmark.
• LangChain potrebbe brillare grazie al suo vasto ecosistema di strumenti e alle ottimizzazioni LCEL (LangChain Expression Language) se non fosse vincolato al nostro set di strumenti standardizzato.

Il framework "migliore" dipende dal fatto che si voglia ottimizzare per: velocità di sviluppo, manutenibilità, prestazioni o specifici modelli architetturali.

Per approfondire

Esplora altri parametri di riferimento RAG, come ad esempio:

• Modelli di embedding: OpenAI vs Gemini vs Cohere
• Principale database vettoriale per RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark RAG Agentico: routing multi-database e generazione di query
• RAG ibrido: miglioramento della precisione del RAG

Cem Dilmegani

Analista principale

Segui

Cem è analista principale presso AIMultiple dal 2017. AIMultiple fornisce informazioni a centinaia di migliaia di aziende (secondo SimilarWeb), tra cui il 55% delle aziende Fortune 500, ogni mese. Il lavoro di Cem è stato citato da importanti pubblicazioni globali come Business Insider, Forbes, Washington Post, società globali come Deloitte e HPE, ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione Europea. È possibile consultare l'elenco di altre aziende e risorse autorevoli che hanno citato AIMultiple. Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, responsabile acquisti tecnologici e imprenditore nel settore tecnologico. Ha fornito consulenza alle aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un report di McKinsey sulla digitalizzazione. Ha guidato la strategia tecnologica e gli acquisti di un'azienda di telecomunicazioni, riportando direttamente al CEO. Ha inoltre 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 zero in soli 2 anni. Il lavoro di Cem in Hypatos è stato oggetto di articoli su importanti pubblicazioni tecnologiche come TechCrunch e Business Insider. Cem partecipa regolarmente come relatore a conferenze internazionali di settore. Si è laureato in ingegneria informatica presso l'Università di Bogazici e ha conseguito un MBA presso la Columbia Business School.

Visualizza il profilo completo

Ricercato da

Ekrem Sarı

Ricercatore di intelligenza artificiale

Segui

Ekrem è un ricercatore di intelligenza artificiale presso AIMultiple, specializzato in automazione intelligente, GPU, agenti di intelligenza artificiale e framework RAG.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento