Negli ultimi anni, abbiamo assistito a un progresso esponenziale dell’IA che lascia davvero stupiti. Dal lancio di ChatGPT nel 2022, cose che in precedenza erano considerate impossibili — come agenti conversazionali davvero intelligenti, capaci di svolgere una grande varietà di compiti — vengono sempre più integrate nei flussi di lavoro aziendali.
Ma che dire della “prima generazione” di AI, ovvero quegli strumenti di Machine Learning (ML) tradizionali come la regressione logistica o i classificatori basati su decision trees? Hanno ancora un ruolo in questo nuovo panorama dominato da agenti super-intelligenti?
In questo approfondimento tecnico, sosteniamo che la risposta sia “sì”. Dimostreremo — attraverso un esempio concreto — come modelli “classici” come XGBoost possano ancora essere utili, in particolare se integrati opportunamente con la nuova ondata di AI Generativa e conversazionale.
Nota Tecnica: Questo post non è un’analisi scientifica rigorosa, bensì un esempio illustrativo di come gli strumenti di ML tradizionale possano essere integrati con i moderni agenti basati su LLM. I risultati sono mostrati su un dataset privato di dimensioni ridotte e devono essere interpretati in tale senso.
Il Caso d’Uso: Agente di Primo Soccorso L1
Il caso d’uso specifico considerato è quello di un agente di primo intervento L1 — un compito che storicamente è stato, e in molti casi è tuttora, svolto da operatori umani. La funzione principale dell’agente è l’apertura e la categorizzazione efficiente dei ticket di supporto basati sulle problematiche segnalate dagli utenti. Data una descrizione in linguaggio naturale, l’agente deve compilare accuratamente una serie di campi chiave — parametri cruciali affinché i team di supporto L2 e L3 possano comprendere e instradare rapidamente il problema.
Descrizione del problema
Affrontiamo il problema della classificazione di ticket di supporto a partire da un dataset privato composto da circa 1.000 tickets. Per via della natura proprietaria dei dati, non è possibile condividere ulteriori dettagli oltre a quelli qui descritti. I dati sono suddivisi in un training set (75%, circa 750 campioni) e un test set (25%, circa 250 campioni).
Ogni ticket è composto da un oggetto e una descrizione in testo libero scritti dall’utente, insieme a un set di campi categoriali strutturati — come Ticket_Type — che vengono tipicamente compilati dall’operatore al momento dell’apertura, non dall’utente finale.
L’obiettivo della classificazione è prevedere quattro categorie gerarchiche — Cat1, Cat2, Cat3 e Cat4 — che determinano la natura e il routing del problema. Si tratta di quattro problemi distinti da risolvere simultaneamente, con ogni livello progressivamente più granulare del precedente.La distinzione tra il testo fornito dall’utente e i campi categoriali inferiti dall’agente è rilevante per comprendere il funzionamento delle tre configurazioni. Nella Configurazione 2 (solo RAG), l’agente inferisce le categorie Cat1–Cat4 direttamente dagli esempi semanticamente simili recuperati dal set di addestramento — non sono necessari campi strutturati. Nella Configurazione 3, invece, introduciamo un classificatore XGBoost che predice Cat1–Cat4 a partire da input categoriali strutturati (come Ticket_Type), anziché dal testo grezzo. Poiché questi campi categoriali non sono forniti dall’utente al momento dell’inferenza, il passaggio RAG (Retrieval-Augmented Generation) nella Configurazione 3 svolge un duplice ruolo: ancorare il LLM alle possibili categorie e fornire il contesto necessario per inferire le feature strutturate richieste dal classificatore. Questa scelta progettuale è descritta in dettaglio nella sezione seguente.
Tre Configurazioni
Abbiamo valutato tre configurazioni progressivamente più ricche dell’agente L1. Tutte condividono lo stesso obiettivo: produrre un oggetto JSON contenente i valori predetti per Cat1, Cat2, Cat3 e Cat4.
Configurazione 1 — Agente LLM Semplice con Contesto Statico
Questa baseline testa la capacità di ragionamento puro dell’LLM, aumentata solo con informazioni statistiche di alto livello derivate dal training set. Prima del deployment, calcoliamo statistiche semplici — la lista dei valori validi per ogni categoria e la loro frequenza — e inseriamo queste informazioni direttamente nel System Prompt. Durante l’inferenza non avviene alcun recupero di dati esterni.
ce, no data retrieval takes place.
System prompt excerpt
You are an L1 support ticket responder. Your task is to classify a support ticket into four hierarchical categories (Cat1, Cat2, Cat3, Cat4) based on the user's description, and produce a final JSON.
You have access to the following statistical summary of historical tickets,extracted from the training data. Use it to guide your predictions: {train_stats}
Steps:
1. Based on the subject and the statistical context above, infer the most likely values for: Cat1, Cat2, Cat3, and Cat4.
2. Explain your reasoning briefly, then call the create_json tool.
Punti di forza e limiti
Il vantaggio principale è la velocità e la semplicità — nessuna chiamata esterna, nessuna latenza di recupero. Il limite è altrettanto chiaro: le statistiche di frequenza da sole non forniscono informazioni sufficienti per disambiguare le categorie. La Configurazione 1 raggiunge un’accuratezza complessiva dello 0% — non riesce mai a indovinare correttamente tutti e quattro i livelli simultaneamente.
Configurazione 2 — Agente LLM con RAG
Questa configurazione arricchisce l’agente con un sistema di Retrieval-Augmented Generation (RAG). Il set di addestramento viene vettorializzato tramite il modello text-embedding-3-large di OpenAI e memorizzato in un vector store ChromaDB. Quando l’agente riceve un ticket, recupera prima i top-N ticket storici semanticamente simili, poi condiziona le proprie previsioni su questi esempi prima di produrre il JSON finale. Cat1–Cat4 vengono inferite direttamente dai pattern osservati negli esempi recuperati.
System prompt excerpt
You are an L1 support ticket responder. Your task is to classify a support ticket into four hierarchical categories (Cat1, Cat2, Cat3, Cat4) based on the user's description, and produce a final JSON.
Steps:
1. The user will provide a short description of their issue.
2. Immediately call the search_vector_database tool using the subject as query to retrieve the most semantically similar historical tickets.
3. Analyze the retrieved tickets carefully. Use the category patterns you observe to infer the most likely values for all fields.
4. Call the create_json tool with all fields filled in.
Punti di forza e limiti
Il RAG fornisce all’agente l’accesso a esempi reali etichettati. Questo è particolarmente efficace per la disambiguazione. Il costo principale è un round-trip aggiuntivo al vector store e un maggiore consumo di token nel context window.
Configuration 3 — LLM Agent with RAG and XGBoost Classifier Tool
Questa configurazione combina il ragionamento contestuale dell’LLM, il grounding basato su RAG e il potere predittivo strutturato di un modello di ML tradizionale.
Vengono addestrati quattro classificatori XGBoost indipendenti — uno per ogni livello di categoria – sul training set di circa 750 tickets. Anziché un unico modello multi-output, ogni classificatore viene addestrato separatamente sul proprio spazio di etichette, consentendogli di specializzarsi in modo indipendente. Sono racchiusi in un’unica classe ClassifierWrapper e distribuiti come un singolo endpoint MLflow, quindi dal punto di vista dell’agente si tratta di un’unica chiamata a uno strumento che restituisce previsioni e scores di confidenza per tutte e quattro le categorie simultaneamente.
Poiché il classificatore richiede Ticket_Type e altre feature categoriche non fornite dall’utente, il RAG gioca un ruolo cruciale: l’LLM utilizza gli esempi recuperati per inferire valori ragionevoli per tali feature, che vengono poi passati al classificatore. L’LLM sintetizza quindi il segnale del classificatore con il contesto RAG — seguendo il classificatore quando la confidenza è alta e affidandosi al RAG quando non lo è.
System prompt excerpt
You are an L1 support ticket responder. Your task is to classify a support ticket into four hierarchical categories (Cat1, Cat2, Cat3, Cat4) based on the user's description, and produce a final JSON.
You have two tools available:
- search_vector_database: retrieves semantically similar historical tickets.
- classify_ticket: an XGBoost classifier that predicts Cat1-Cat4 with a confidence score for each.
Steps:
1. Call search_vector_database to retrieve similar historical tickets.
2. From the retrieved tickets, infer your best guess for the classifier's required features.
3. Call classify_ticket using the ticket subject and the inferred categorical features.
4. Combine both tools: use RAG for context, classifier predictions weighted by confidence to determine final Cat1-Cat4 values.
5. Call create_json with all fields filled in.
Punti di forza e limiti
Questa configurazione è la più efficiente delle tre, ma è importante sottolineare che le sue prestazioni dipendono fortemente dalla qualità dei modelli XGBoost sottostanti. Un classificatore mal addestrato potrebbe peggiorare, anziché migliorare, il sistema complessivo. Il compromesso include anche una maggiore latenza (due chiamate a strumenti esterni) e la necessità di mantenere un servizio di classificazione separato.
Workflow
Tutte e tre le configurazioni condividono un comune ciclo agente costruito con l’API di tool-calling di OpenAI e tracciato tramite LangSmith. La differenza principale risiede nel numero di passaggi di ragionamento e recupero che il LLM orchestra prima di produrre il JSON finale:
- Config 1: messaggio utente → LLM (con statistiche fisse) → create_json
- Config 2: messaggio utente → LLM → search_vector_database → LLM → create_json
- Config 3: messaggio utente → LLM → search_vector_database → LLM → classify_ticket → LLM → create_json
Nella Config 3, il LLM viene invocato tre volte: prima per comprendere il ticket e decidere di recuperare esempi rilevanti, poi per interpretare gli esempi recuperati e inferire le feature categoriali necessarie al classificatore, e infine per sintetizzare l’output del classificatore in una previsione strutturata.
Risultati della valutazione
Abbiamo confrontato le Configurazioni 2 e 3 sul set di test. La Configurazione 1 è stata esclusa dal confronto quantitativo a causa della sua inadeguatezza come baseline significativa.
| Configurazione | Cat1 | Cat2 | Cat3 | Cat4 | Complessiva |
| Config 2 (Solo RAG) | 100% | 66.7% | 66.7% | 33.3% | 33.3% |
| Config 3 (RAG + XGBoost) | 100% | 83.3% | 83.3% | 66.7% | 66.7% |
Entrambe le configurazioni raggiungono un’accuratezza perfetta su Cat1, come atteso dato il piccolo spazio di etichette al livello più grossolano. Il divario di prestazioni si amplia per le categorie più granulari. La Config 3 migliora Cat2 e Cat3 di circa 17 punti percentuali ciascuna, e Cat4 di circa 33 punti. L’accuratezza complessiva raddoppia dal 33,3% al 66,7%.
Questi numeri sono illustrativi. Il dataset è piccolo e privato, e i risultati non devono essere interpretati come un’affermazione generale sulla superiorità di questa architettura.
Discussione
Il divario di prestazioni tra le configurazioni si amplia all’aumentare del livello di categoria — tutti gli agenti gestiscono bene Cat1, ma le differenze diventano marcate a Cat4. Le categorie grossolane possono spesso essere inferite dall’oggetto del ticket da solo; quelle granulari richiedono un contesto più ricco o un modello che abbia esplicitamente appreso la distribuzione delle etichette.
Gli score di confidenza del classificatore XGBoost si rivelano inoltre utili come segnale di routing. Quando la confidenza è alta, il LLM segue il classificatore e ottiene risultati migliori. Quando è bassa, sconta opportunamente il classificatore e si affida maggiormente al RAG.
Infine, le prestazioni della Config 3 sono strettamente legate alla qualità dei modelli XGBoost addestrati. Non si tratta di un’architettura plug-and-play: essa richiede infatti di investire in una pipeline di addestramento ML affidabile come prerequisito. Se questo investimento non viene fatto, il classificatore introdurrà rumore anziché segnale.
Conclusione
I risultati di questo esperimento sostengono la continua rilevanza dei modelli di ML tradizionale nell’era degli agenti basati su LLM. XGBoost non sostituisce l’LLM: piuttosto, i due strumenti sono simbiotici. L’LLM gestisce la trasformazione da dati non strutturati a strutturati, mentre XGBoost apporta una certezza basata sui dati che i puri modelli linguistici faticano a replicare.
Il takeaway per consulenti e architetti IT è semplice: vecchia AI e nuova AI non sono competitor, bensì complementari. Quando sono disponibili dati di training etichettati e la precisione è fondamentale, integrare classificatori affidabili come tool per gli agenti è un pattern potente e ancora poco esplorato.
Autore: Giovanni Vacanti, Data Scientist @ Bitrock