L’adozione aziendale dei modelli linguistici di grandi dimensioni (Large Language Model, LLM) incontra un problema centrale: integrarli in un sistema enterprise senza comprometterne l’affidabilità. Un LLM è flessibile ma probabilistico: allucina, sbaglia l’instradamento e produce risposte difficili da tracciare. Il contesto aziendale richiede invece decisioni deterministiche e verificabili. Per conciliare le due esigenze presentiamo Agentic Platform, un’architettura multi-agente realizzata durante il tirocinio presso E4 Analytics. Lo sviluppo procede per quattro fasi incrementali, sulla stessa infrastruttura cloud-native Kubernetes. La prima è un prototipo sulla piattaforma low-code n8n, dove fissiamo il principio dell’architettura, la separazione tra reasoning ed execution: l’LLM pianifica e sintetizza, una logica deterministica esegue. Il prototipo presenta però sei criticità operative. Nella seconda fase riscriviamo l’intera architettura in Python con LangGraph. Il piano di workflow è tipizzato: la validazione lo respinge prima dell’esecuzione se richiama un agente inesistente. Nella terza fase migriamo sul framework agentico dichiarativo OpenCode; nella quarta sostituiamo il recupero vettoriale con la Direct Corpus Interaction, che espone il corpus all’agente come un file system da percorrere. Le prove sperimentali procedono su due fronti. Il primo è un benchmark di routing su 100 query stratificate, di cui 11 avversarie. L’accuratezza di instradamento sale da 0,76 con LangGraph a 0,94 con OpenCode. Le due misure provengono da esecuzioni separate: il confronto è longitudinale e non appaiato. Il secondo fronte confronta tre sistemi di recupero: un RAG classico, uno avanzato e un agente su file system. Li misuriamo con Ragas su SciFact, HotpotQA e MultiHop-RAG. Come giudice impieghiamo un modello di famiglia diversa da quella del generatore, per attenuare il self-evaluation bias. L’agente ottiene la qualità di recupero e sintesi migliore, a un costo per query quasi cinque volte superiore. Il RAG avanzato mantiene il vantaggio sulla copertura esaustiva. Ne deriva un principio progettuale. Un percorso incrementale, guidato dalle misure, rende ispezionabile ogni passo del sistema: il piano è un oggetto tipizzato, validato prima dell’esecuzione e registrato insieme alla traccia. Sul risultato finale pesa più la disciplina con cui separiamo pianificazione ed esecuzione che la potenza del singolo modello.
Testing e Validazione di Workflow Agentico a livello Enterprise
ZANNI, DAVIDE
2025/2026
Abstract
L’adozione aziendale dei modelli linguistici di grandi dimensioni (Large Language Model, LLM) incontra un problema centrale: integrarli in un sistema enterprise senza comprometterne l’affidabilità. Un LLM è flessibile ma probabilistico: allucina, sbaglia l’instradamento e produce risposte difficili da tracciare. Il contesto aziendale richiede invece decisioni deterministiche e verificabili. Per conciliare le due esigenze presentiamo Agentic Platform, un’architettura multi-agente realizzata durante il tirocinio presso E4 Analytics. Lo sviluppo procede per quattro fasi incrementali, sulla stessa infrastruttura cloud-native Kubernetes. La prima è un prototipo sulla piattaforma low-code n8n, dove fissiamo il principio dell’architettura, la separazione tra reasoning ed execution: l’LLM pianifica e sintetizza, una logica deterministica esegue. Il prototipo presenta però sei criticità operative. Nella seconda fase riscriviamo l’intera architettura in Python con LangGraph. Il piano di workflow è tipizzato: la validazione lo respinge prima dell’esecuzione se richiama un agente inesistente. Nella terza fase migriamo sul framework agentico dichiarativo OpenCode; nella quarta sostituiamo il recupero vettoriale con la Direct Corpus Interaction, che espone il corpus all’agente come un file system da percorrere. Le prove sperimentali procedono su due fronti. Il primo è un benchmark di routing su 100 query stratificate, di cui 11 avversarie. L’accuratezza di instradamento sale da 0,76 con LangGraph a 0,94 con OpenCode. Le due misure provengono da esecuzioni separate: il confronto è longitudinale e non appaiato. Il secondo fronte confronta tre sistemi di recupero: un RAG classico, uno avanzato e un agente su file system. Li misuriamo con Ragas su SciFact, HotpotQA e MultiHop-RAG. Come giudice impieghiamo un modello di famiglia diversa da quella del generatore, per attenuare il self-evaluation bias. L’agente ottiene la qualità di recupero e sintesi migliore, a un costo per query quasi cinque volte superiore. Il RAG avanzato mantiene il vantaggio sulla copertura esaustiva. Ne deriva un principio progettuale. Un percorso incrementale, guidato dalle misure, rende ispezionabile ogni passo del sistema: il piano è un oggetto tipizzato, validato prima dell’esecuzione e registrato insieme alla traccia. Sul risultato finale pesa più la disciplina con cui separiamo pianificazione ed esecuzione che la potenza del singolo modello.| File | Dimensione | Formato | |
|---|---|---|---|
|
Zanni.Davide.pdf
accesso aperto
Dimensione
3.16 MB
Formato
Adobe PDF
|
3.16 MB | Adobe PDF | Visualizza/Apri |
I documenti in UNITESI sono protetti da copyright e tutti i diritti sono riservati, salvo diversa indicazione.
https://hdl.handle.net/20.500.14251/9865