Confronto tra framework di intelligenza artificiale agentica nei flussi di lavoro di analisi
I framework per la creazione di flussi di lavoro basati su agenti differiscono sostanzialmente nel modo in cui gestiscono le decisioni e gli errori, eppure le loro prestazioni su dati reali imperfetti rimangono in gran parte non testate.
Per valutare le loro prestazioni su flussi di lavoro analitici reali, abbiamo trascorso 3 giorni a eseguire il benchmarking di LangGraph, LangChain, CrewAI e Swarm utilizzando un dataset di e-commerce di 100 record con incoerenze di dati controllate come ID mancanti, valori nulli e formati di data incoerenti.
benchmark di analisi agentica
Ciascun framework è stato valutato in termini di accuratezza ed efficienza decisionale , prestazioni di integrazione degli strumenti e prestazioni di esecuzione (tempo e utilizzo dei token).
accuratezza ed efficienza decisionale
- L'accuratezza delle decisioni misura l'efficacia con cui ciascun framework ha risolto i problemi relativi ai dati, inclusi i valori nulli, le assegnazioni predefinite, le mappature dei campi e il ripristino in caso di errore.
- L'efficienza decisionale rappresenta la proporzione di problemi critici risolti rispetto al totale delle decisioni. Un punteggio del 100% indica una risoluzione ottimale in un solo passaggio, mentre valori inferiori indicano tentativi aggiuntivi o cicli decisionali ridondanti che aumentano il carico computazionale. È possibile consultare la metodologia di benchmark qui .
Sciame
Elevata efficienza, elevata precisione (60%, 90%)
Swarm ha raggiunto un'elevata precisione mantenendo al contempo un'esecuzione efficiente nei flussi di lavoro analitici.
Le metriche di performance hanno mostrato un numero di decisioni costantemente basso e un numero minimo di tentativi. Questo risultato riflette l'architettura modulare e specifica per attività di Swarm, in cui i singoli agenti gestiscono funzioni analitiche definite, come l'analisi dei KPI o la ricerca sulla concorrenza.
Swarm combina quindi un forte coordinamento con un'efficiente distribuzione dei compiti , risultando quindi adatto ad ambienti analitici multi-agente che richiedono sia velocità che precisione.
LangGraph
Elevata efficienza, elevata precisione (60%, 100%)
LangGraph ha raggiunto un'elevata precisione e un'esecuzione efficiente, completando i flussi di lavoro analitici con un numero ridotto di eventi decisionali.
Le metriche ricavate da ripetute esecuzioni di test hanno mostrato percorsi di esecuzione costantemente diretti e un numero minimo di tentativi. Questo schema riflette l'architettura basata sui grafi di LangGraph, che predefinisce le dipendenze di esecuzione e riduce le operazioni ridondanti.
LangGraph offre quindi prestazioni precise, coerenti ed efficienti , risultando ideale per flussi di lavoro analitici strutturati .
CrewAI
Bassa efficienza, alta precisione (21%, 87%)
CrewAI ha raggiunto un'elevata precisione, ma ha richiesto un numero di decisioni sostanzialmente maggiore per completare ciascun flusso di lavoro.
I dati registrati da DecisionTracker e AccuracyLatencyTracker hanno mostrato che si sono verificati numerosi eventi decisionali aggiuntivi in seguito a guasti degli strumenti.
Questo schema indica una forte tolleranza ai guasti che ha garantito risultati finali affidabili, ma ha comportato un aumento del carico computazionale e dei tempi di esecuzione.
CrewAI, pertanto, privilegia la completezza e l'affidabilità dei risultati rispetto all'efficienza dell'esecuzione.
LangChain
Efficienza media, bassa precisione (42%, 78%)
LangChain ha dimostrato un'efficienza moderata ma una precisione inferiore rispetto ad altri framework.
Le metriche registrate hanno mostrato ripetute iterazioni decisionali a seguito di guasti degli strumenti, poiché il framework ritentava operazioni identiche invece di adattarsi a strategie alternative. Questo schema di esecuzione sequenziale ha limitato l'efficacia del ripristino e ha portato al completamento parziale delle attività.
LangChain offre quindi una velocità di elaborazione ragionevole ma una scarsa tolleranza ai guasti , risultando più adatto a flussi di lavoro analitici più semplici e a basso rischio .
Prestazioni di integrazione degli strumenti
Sciame
(Tasso di successo del coordinamento degli strumenti pari al 100%)
Swarm ha mantenuto un tasso di successo del 100% nell'utilizzo degli strumenti grazie alla sua architettura basata su agenti specializzati. Agenti distinti gestivano attività analitiche come l'analisi dei KPI, il confronto con la concorrenza e la conversione di valuta, consentendo passaggi di consegne fluidi e un utilizzo efficiente degli strumenti .
LangGraph
(Tasso di successo del coordinamento degli strumenti pari al 100%)
LangGraph ha raggiunto un tasso di successo del 100% nell'esecuzione degli strumenti. La sua orchestrazione basata su grafi ha mappato efficacemente le dipendenze tra gli strumenti e l'ordine di esecuzione, prevenendo chiamate ridondanti o in conflitto. Il framework ha dimostrato un'elevata affidabilità e un coordinamento coerente tra tutti i moduli.
CrewAI
(Tasso di successo del coordinamento degli strumenti pari al 37%)
CrewAI ha mostrato un basso tasso di esecuzioni riuscite dello strumento, in particolare nei moduli KPI e di convalida. Nonostante ciò, tutte le attività sono state completate attraverso ulteriori cicli di ragionamento e ripristino, indicando una forte tolleranza ai guasti con un maggiore sovraccarico computazionale .
LangChain
(Tasso di successo del coordinamento degli strumenti pari al 51%)
LangChain ha ottenuto un discreto successo nell'esecuzione degli strumenti, ma è risultato carente in termini di recupero adattivo. Quando le chiamate agli strumenti fallivano, ripeteva la stessa sequenza di operazioni, con conseguente elaborazione ridondante e output incompleti .
Tempo di esecuzione e token di completamento
Sciame
Il più veloce ed efficiente
Swarm ha completato tutti i flussi di lavoro in circa 20 secondi utilizzando circa 1.000 token , il valore più basso tra tutti i framework. I tempi di completamento costanti e il consumo minimo di token indicano un'esecuzione stabile ed efficiente in tutte le iterazioni .
LangGraph
Prestazioni equilibrate
Swarm ha completato tutti i flussi di lavoro in circa 20 secondi utilizzando circa 1.000 token , il valore più basso tra tutti i framework. I tempi di completamento costanti e il consumo minimo di token indicano un'esecuzione stabile ed efficiente in tutte le iterazioni .
CrewAI
Richiede molte risorse ma è affidabile
CrewAI ha richiesto circa 32 secondi e 4.500 token per ogni esecuzione, il consumo di risorse più elevato nel benchmark. I cicli di ragionamento e convalida estesi hanno comportato tempi di esecuzione più lunghi, ma un completamento costante delle attività, indicando un'elevata affidabilità a fronte di costi maggiori .
LangChain
Il più lento e il meno efficiente
LangChain ha completato le esecuzioni in circa 48 secondi , consumando circa 2.100 token . I ripetuti tentativi dopo le esecuzioni fallite dello strumento hanno contribuito a tempi di esecuzione più lunghi e a un utilizzo inefficiente delle risorse .
Approcci alla gestione degli errori
Per valutare la gestione nativa degli errori, ciascun framework è stato valutato utilizzando la propria logica di elaborazione dei dati anziché una pipeline di pre-elaborazione condivisa. Questo confronto ha evidenziato le principali differenze tra i framework che privilegiano l'integrità dei dati e quelli che enfatizzano la completezza dell'elaborazione .
LangGraph e Swarm hanno dato priorità all'accuratezza e all'integrità dei dati attraverso la convalida e l'esclusione, mentre CrewAI e LangChain hanno privilegiato la completezza, mantenendo i dati incompleti o imputando i valori mancanti, il che ha portato a una maggiore variabilità nella precisione analitica.
Ecco una ripartizione dettagliata:
Sciame
Swarm ha applicato una logica di salto precisa, escludendo i record non validi o incompleti e mantenendo al contempo la continuità complessiva del flusso di lavoro. Dopo aver risolto alcuni problemi minori di compatibilità delle API, il framework ha elaborato in modo coerente i record verificati senza interrompere il flusso di esecuzione.
LangGraph
LangGraph ha imposto una rigorosa validazione dei dati, omettendo le voci con valori nulli o incompleti. Questo approccio prudente ha garantito l'accuratezza analitica elaborando solo i record che superavano i controlli di integrità, mantenendo risultati coerenti tra le diverse esecuzioni dei test.
CrewAI
CrewAI operava secondo il principio di "zero perdita di dati", conservando tutti i record, compresi quelli con campi mancanti o non validi. Sebbene questo approccio preservasse la completezza del set di dati, riduceva la precisione dei calcoli a causa dell'inclusione di punti dati non verificati.
LangChain
LangChain ha utilizzato tecniche di imputazione dei dati per dedurre i valori mancanti dai campi esistenti. Ad esempio, quando Final_Price era nullo, ha calcolato i valori sostitutivi dai campi Price e Discount . Sebbene adattivo, questo ha introdotto delle deviazioni dai risultati attesi, influenzando la precisione dei risultati.
Quando utilizzare ciascun framework?
- CrewAI: Quando è probabile che si verifichino problemi imprevisti ed è necessaria una risoluzione autonoma dei problemi.
- LangGraph: Per un ragionamento e una struttura equilibrati. Ideale per casi d'uso generici.
- Swarm: Ideale per ambienti di produzione in cui velocità e affidabilità sono fondamentali. Offre la massima velocità e uniformità.
- LangChain: ideale quando sono necessarie tracciabilità dettagliata e trasparenza. Registra ogni passaggio, ma è più lento rispetto alle alternative.
Esperienza di sviluppo
Prestazioni di integrazione tra framework e LLM: diversi framework dimostrano livelli variabili di compatibilità e prestazioni con specifici provider LLM. Ad esempio, LangChain offre un'integrazione e una precisione superiori se abbinato ai modelli ChatGPT di OpenAI, fornendo risultati più precisi grazie a una gestione ottimizzata dei prompt.
Coerenza comportamentale guidata dall'architettura: sebbene i framework possano utilizzare diversi LLM con efficienza variabile, le loro caratteristiche comportamentali principali sono rimaste ampiamente coerenti tra i modelli. I comportamenti caratteristici che abbiamo osservato, come i modelli decisionali, la gestione del recupero e le capacità di ragionamento alternativo, dipendono principalmente dalla progettazione architetturale sottostante piuttosto che dallo specifico LLM impiegato.
Ciò suggerisce che le combinazioni framework-LLM possono influenzare le metriche di prestazione, ma i modelli comportamentali fondamentali, come l'approccio "a qualunque costo" di CrewAI o il coordinamento specializzato degli agenti di Swarm, rimangono costanti indipendentemente dal modello linguistico utilizzato.
Problemi di integrazione: Abbiamo riscontrato notevoli problemi di integrazione nel tentativo di connettere CrewAI con i modelli Claude di Anthropic. Nonostante diversi tentativi di configurazione, persistenti errori di configurazione dell'ambiente hanno impedito la corretta implementazione.
La nostra ricerca indica che non si tratta di un problema isolato: numerosi sviluppatori della community hanno segnalato difficoltà di integrazione simili tra CrewAI e i servizi Anthropic, suggerendo potenziali incompatibilità architetturali o limitazioni nella gestione delle API.
Raccomandazioni per l'abbinamento framework-LLM: Sulla base di questi risultati, raccomandiamo di valutare diverse combinazioni framework-LLM quando si selezionano i framework più adatti al proprio caso d'uso specifico.
Come gli agenti gestiscono le attività di analisi
L'analisi agentiva sposta il ruolo dell'IA da strumento passivo a esecuzione autonoma. Anziché attendere istruzioni esplicite a ogni passaggio, gli agenti analitici percepiscono lo stato attuale dei dati, decidono quali azioni intraprendere e adattano il loro approccio in base ai risultati intermedi.
Competenze chiave in contesti analitici:
- Preparazione autonoma dei dati: gli agenti rilevano i valori mancanti, identificano gli outlier, standardizzano i formati e convalidano i risultati ripuliti senza richiedere la configurazione manuale per ogni trasformazione.
- Generazione dinamica di query: le richieste in linguaggio naturale vengono tradotte in query eseguibili, con agenti che ottimizzano e adattano la sintassi in base al database di destinazione.
- Verifica iterativa delle ipotesi: quando l'analisi iniziale non è conclusiva, gli agenti possono riformulare il loro approccio, testare ipotesi alternative o richiedere fonti di dati aggiuntive.
- Rilevamento delle anomalie in tempo reale: il monitoraggio continuo delle metriche consente agli agenti di individuare modelli inattesi e di avvisare le parti interessate prima che i problemi si aggravino.
Limitazioni pratiche:
- Problemi di determinismo: il comportamento del modello probabilistico implica che query identiche possano produrre risultati leggermente diversi tra le varie esecuzioni, il che complica i requisiti di riproducibilità.
- Precisione numerica: gli agenti basati su LLM possono interpretare erroneamente i formati numerici o introdurre errori di calcolo, rendendo necessari livelli di validazione per le metriche critiche.
Metodologia di benchmarking
Obiettivo : Il nostro obiettivo era confrontare oggettivamente quattro framework di agenti di intelligenza artificiale (LangGraph, LangChain, CrewAI, Swarm) utilizzando set di dati e sistemi di misurazione identici. Abbiamo valutato l'accuratezza del processo decisionale, l'efficienza delle risorse e le capacità di integrazione degli strumenti dei framework in condizioni di errore realistiche.
Descrizione del dataset Abbiamo garantito condizioni di test identiche per ogni framework. Abbiamo utilizzato lo stesso dataset JSON, gli stessi KPI di riferimento, le stesse API di simulazione e gli stessi ritardi temporali per tutti i framework.
Abbiamo utilizzato un dataset di 100 record, sufficiente per osservare le capacità decisionali. Abbiamo reimpostato i sistemi di tracciamento prima di ogni test (decision_tracker, perf_tracker reset). Abbiamo utilizzato le stesse funzioni degli strumenti in tutti i framework, adattando però le convenzioni di denominazione a ciascuno di essi (_swarm_tool, crewai tool).
Alterazioni dei dati : sono stati utilizzati dati relativi agli acquisti online. Il dataset contiene i seguenti campi:
- ID utente (identificativo cliente),
- ID_prodotto (identificativo del prodotto),
- Categoria (Categoria di prodotto),
- Prezzo (Rs.) (Prezzo originale),
- Sconto (%) (Percentuale di sconto),
- Prezzo_finale (Rs.) (Prezzo finale dopo lo sconto),
- Metodo di pagamento (Payment_Method),
- Data_acquisto (Data di acquisto).
Abbiamo utilizzato dati di e-commerce volutamente alterati:
- Valori nulli
- Campi vuoti – “Product_ID”: “”, “User_ID”: “”, “Categoria”: “”
- Nomi di campo misti: “costo”: 1200,0, “ricavo”: 150,0
- Incoerenza dei dati: variazioni nel formato della data ("07/01/2024" rispetto a "gg-mm-aaaa")
- valori zero/negativi
Definizione dei compiti : a ciascun framework sono stati assegnati 5 compiti identici:
- Elaborazione dei dati – Elaborazione dei dati potenziata con esecuzione specifica del framework per la pulizia e la trasformazione
- Calcolo dei KPI – Applicare algoritmi di calcolo dei KPI identici utilizzando lo strumento enhanced_kpi_calculator
- Analisi della concorrenza : esegui un'analisi della concorrenza per i 3 prodotti principali utilizzando CompetitorAPI.
- Conversione di valuta : converti il ricavo totale in USD utilizzando CurrencyAPI.
- Gestione degli errori : implementare strategie native di gestione degli errori per le incongruenze dei dati.
Punti chiave previsti per la decisione:
- Decisione sulla gestione dei valori nulli – Come gestire i valori nulli di Final_Price
- Decisione predefinita per i campi vuoti : come compilare i campi vuoti
- Decisione di mappatura del campo – Trasformazioni del campo
- Decisione sull'incoerenza dei dati – Normalizzazione del formato
- Decisione di salto per i valori zero : includere/escludere i valori zero
- Decisioni sull'utilizzo degli strumenti : quale strumento utilizzare e quando? Avrà successo? Cosa fare in caso di errore? Come gestire i guasti degli strumenti e le strategie di ripiego?
Abbiamo eseguito ciascuna pipeline del framework 10 volte e abbiamo calcolato il valore mediano per tutte le metriche.
Coerenza nell'esecuzione: abbiamo implementato la stessa infrastruttura di misurazione in tutti i framework:
- AccuratezzaLatenzaTracker per la misurazione dei tempi (timer di inizio/timer di fine),
- DecisionTracker per la registrazione delle decisioni con categorizzazione,
- Processore dati analitico avanzato per una logica di pulizia dei dati identica,
- API di prova, inclusa CompetitorAPI (ritardo di 0,05 secondi)
- API valuta (ritardo di 0,1 secondi)
Abbiamo mantenuto configurazioni specifiche per ciascun framework: LangGraph utilizzava un'orchestrazione basata su grafi con punteggio di affidabilità e routing intelligente. LangChain impiegava un agente ReAct sequenziale con ConversationBufferMemory e registrazione dettagliata. CrewAI si avvaleva della collaborazione multi-agente con risoluzione autonoma dei problemi.
Tutti i framework (CrewAI, LangGraph, LangChain e Swarm) sono stati testati utilizzando GPT-4.1 per garantire prestazioni del modello coerenti e un confronto equo tra le metriche di valutazione.
metriche di valutazione
La precisione decisionale misura l'affidabilità con cui un framework risolve i problemi critici relativi ai dati e viene calcolata come segue:
L'accuratezza è stata determinata confrontando le decisioni di ciascun framework con criteri di logica aziendale predefiniti.
Ciascuna decisione è stata valutata in modo binario (corretta/sbagliata) sulla base di:
- Ripristino in caso di guasto dello strumento : se le operazioni non riuscite sono state risolte con successo utilizzando un ragionamento alternativo.
- Gestione dei valori nulli : indica se i record non validi sono stati correttamente ignorati.
- Valori predefiniti per i campi vuoti : indica se i valori mancanti sono stati sostituiti correttamente (ad esempio, "SCONOSCIUTO").
L'efficienza decisionale valuta l'efficacia con cui un framework affronta le problematiche critiche relative ai dati e viene calcolata come segue:
I punti critici sono stati definiti come i passaggi decisionali minimi richiesti (ad esempio, gestione dei valori nulli, valori predefiniti per i campi vuoti, mappatura dei campi). Un punteggio del 100% indica una decisione per ogni punto critico, mentre decisioni aggiuntive segnalano inefficienza o sovra-elaborazione.
Le prestazioni dello strumento sono state misurate utilizzando il tasso di successo primario , che rappresenta la proporzione di chiamate dirette allo strumento completate con successo:
La capacità di ripristino misura la capacità di un framework di ripristinare con successo il funzionamento dopo chiamate di strumenti non riuscite e viene calcolata come segue:
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.