LangChain o LlamaIndex: il benchmark dipende dal test

Per un progetto RAG o con agenti, LangChain e LlamaIndex si distinguono anzitutto per il percorso di sviluppo che offrono. Un benchmark può misurare qualità, token e latenza delle implementazioni provate, ma il risultato dipende anche da modello, prompt, memoria, strumenti e dati. Il nome del framework, da solo, non basta a prevedere la prestazione sul proprio progetto.

Se l’esigenza principale è governare passaggi e decisioni di un agente, il percorso LangChain e LangGraph merita attenzione. Se il lavoro parte da documenti da acquisire, indicizzare e recuperare, LlamaIndex offre un’impostazione centrata sui dati. Le capacità si sovrappongono: la scelta finale richiede di confrontare lo stesso compito con configurazioni dichiarate e misure adatte al carico previsto.

Architettura: dove inizia il lavoro

La documentazione LangChain propone agenti per casi semplici e primitive LangGraph per workflow RAG che richiedono un controllo più granulare; presenta anche schemi multiagente che combinano i due strumenti. Questo percorso è pertinente quando occorre rendere espliciti i passaggi fra strumenti, stati o agenti. Il maggior controllo è una capacità architetturale, non una misura di accuratezza o velocità.

Il framework LlamaIndex si presenta come un toolkit Python per agenti che usano i dati dell’utente come contesto. Comprende connettori, indici, motori di interrogazione, strumenti per agenti e workflow con diramazioni, tentativi successivi e intervento umano. È quindi riduttivo riservargli il solo retrieval, così come sarebbe riduttivo escludere LangChain da un’applicazione documentale: cambia il punto da cui è più naturale comporre la soluzione.

Nel RAG, il risultato attraversa più fasi

La guida LlamaIndex alle interrogazioni distingue recupero dei contenuti, eventuale riordinamento o filtro e sintesi della risposta. Questa separazione chiarisce perché due sistemi che usano lo stesso modello possano rispondere diversamente: possono consegnargli passaggi differenti, in un ordine diverso o con una diversa quantità di contesto. Anche la preparazione dei documenti e la costruzione dell’indice incidono su ciò che potrà essere recuperato.

Per attribuire un errore serve osservare sia i passaggi trovati sia la risposta. Se manca il contenuto pertinente, il problema è a monte della sintesi; se il contenuto c’è ma viene interpretato male, vanno esaminati prompt e generazione. Pertinenza del retrieval e correttezza della risposta sono quindi misure distinte. Anche il tempo di indicizzazione va tenuto separato dalla latenza delle interrogazioni: pesa in modo diverso per un archivio aggiornato spesso e per uno quasi statico.

Che cosa mostrano i numeri di AgentRace

Nel test RAG su MMLU, il paper AgentRace riporta un’accuratezza di 0,820 per LangChain 0.3.22 e di 0,745 per LlamaIndex 0.12.30; GPT-4o è il modello predefinito del protocollo. Il confronto riguarda quelle versioni e quelle implementazioni: i ricercatori mantengono in genere i prompt predefiniti dei rispettivi framework. Il divario misura dunque anche le scelte incorporate nel test, non un vantaggio invariabile di una libreria sull’altra.

Lo studio rileva che l’inferenza del modello occupa spesso la maggior parte del tempo e che token consumati e correttezza non hanno una relazione forte. Una cronologia più lunga o più passaggi di ragionamento possono aumentare il consumo senza migliorare la risposta. Sono meccanismi utili da cercare nei propri agenti, soprattutto quando la memoria viene aggiunta ripetutamente al prompt o uno strumento restituisce molto contenuto.

C’è un limite nella lettura delle medie di efficienza: il protocollo le calcola normalmente sui casi conclusi correttamente. Un tempo basso su quel gruppo non descrive, da solo, la frequenza dei fallimenti. Accuratezza, completamento, token e latenza vanno letti insieme, con il dataset, il modello, i prompt e gli strumenti che hanno prodotto ciascun risultato.

La matrice per confrontare le implementazioni

Le funzioni disponibili restringono la scelta architetturale; le misure dicono se il sistema ottenuto rispetta i vincoli del progetto. Le dimensioni cambiano secondo il compito:

RAG: valutare acquisizione dei documenti, indice, recupero e selezione del contesto. Misurare separatamente la pertinenza dei passaggi e la correttezza delle risposte.
Agenti: valutare strumenti, stato, memoria e passaggi fra agenti. Registrare completamenti, fallimenti, chiamate al modello e invocazioni degli strumenti.
Controllo del flusso: verificare quanto siano esprimibili diramazioni, tentativi successivi e intervento umano. Conta quando il percorso deve seguire regole esplicite.
Token: distinguere input e output, annotando istruzioni, documenti recuperati e cronologia. Il totale può crescere per ragioni estranee alla difficoltà della domanda.
Latenza: misurare il tempo percepito dall’utente e quello di retrieval, modello e strumenti. Ripetere la prova al carico previsto, includendo richieste simultanee se il servizio dovrà gestirle.

Quando il benchmark è trasferibile al proprio carico

Un risultato esterno è più utile quando il suo compito somiglia a quello da svolgere: tipo di documenti, lingua delle domande, modello, strumenti e vincoli di risposta devono essere riconoscibili. MMLU in un workflow RAG, per esempio, dà informazioni su quel protocollo; un archivio aziendale in italiano può porre problemi diversi di estrazione del testo, terminologia e aggiornamento. L’accuratezza pubblicata resta un dato concreto, ma non è una previsione della propria applicazione.

Per isolare il contributo dell’orchestrazione, le due versioni dovrebbero ricevere gli stessi file e le stesse domande, partire dalla stessa estrazione e usare modello, segmentazione, indice e parametri di generazione equivalenti. Prompt, regole della memoria, accesso agli strumenti e criteri di valutazione vanno fissati prima della prova. Se si lascia a ciascun framework il proprio prompt predefinito, il confronto resta legittimo, purché sia presentato come confronto fra configurazioni complete.

Il resoconto più utile conserva anche le versioni dei componenti, il numero di passaggi recuperati, i token in ingresso e in uscita e la distribuzione dei tempi, oltre a risposte corrette e fallimenti. Dopo una prova a condizioni condivise, si possono ottimizzare separatamente retrieval e prompt: quella seconda misura risponde a un’altra domanda, quale soluzione configurata soddisfa meglio i vincoli reali. Nella decisione entra infine il lavoro necessario a modificare e diagnosticare il flusso, una proprietà che i punteggi di accuratezza non misurano.