Bastano 3,8 minuti di calcolo e un singolo prompt per portare un agente AI aziendale da una precisione di routing incerta a un F1 del 79,2%, eguagliando in tutto e per tutto l’esito di ore di rifinitura manuale. È quanto emerge da un ampio test in produzione su un agente conversazionale per gruppi di lavoro, che ha messo a confronto la classica messa a punto artigianale con una pipeline automatizzata di ottimizzazione delle descrizioni delle skill. Lo studio, condotto su 9 competenze e 372 casi di regressione, offre lezioni concrete su come accelerare il ciclo di manutenzione senza sacrificare l’accuratezza.

La natura del problema: collisioni tra skill

Negli agenti enterprise, il router basato su LLM indirizza la domanda dell’utente alla skill giusta confrontandone la descrizione testuale. Quando due skill condividono descrizioni sovrapposte, il router sbaglia instradamento, fenomeno chiamato skill collision. Con l’aumentare del numero di skill – decine in scenari reali – il tuning manuale diventa un collo di bottiglia ingegneristico: ogni modifica richiede verifiche incrociate e re-testing, con tempi che lievitano rapidamente.

L’esperimento in produzione: 9 skill, 372 casi

Il team ha predisposto una pipeline automatica per riscrivere le descrizioni. A partire da un set di regressione con veri positivi e falsi positivi già disponibili, un LLM produce nuove descrizioni mirate a ridurre le collisioni. Applicata all’agente di gruppo reale, la pipeline ha raggiunto un F1 medio del 79,2%, contro il 79,4% delle descrizioni accordate a mano. La differenza per singola skill (–0,20% in media) ricade all’interno del rumore multi-seed (0,78%), confermando l’equivalenza pratica. Il vero guadagno sta nell’efficienza: il lavoro per skill è passato da 120 minuti a 3,8 minuti, con uno speedup di 32 volte.

Cosa conta davvero: lo studio di ablazione

L’aspetto più sorprendente arriva smontando la pipeline. L’ablazione sistematica, condotta sia sul sistema di produzione sia sul benchmark ToolBench (16.000 tool), rivela che una singola riscrittura del LLM, che utilizzi tutti i falsi positivi e falsi negativi disponibili, cattura quasi tutto il miglioramento possibile. Altri fattori di design – budget di iterazione, composizione del segnale di feedback, editing duale delle coppie confuse, dimensione del training set – incidono ciascuno per meno dello 0,5% sul F1 finale. In pratica, iterare più volte o aggiungere meccanismi di feedback complessi non porta benefici misurabili.

Oltre l’ottimizzazione testuale: il confine architetturale

La pipeline risolve solo le collisioni causate da descrizioni testuali ambigue. Quando l’ambito funzionale di due skill si sovrappone realmente, nessuna riscrittura può evitare gli errori di routing. Lo studio individua un diagnostico chiaro: un ampio divario tra F1 di training e validazione. Quel gap segnala casi in cui serve un intervento architetturale – separare o ripensare le skill – piuttosto che continuare ad affinare le descrizioni.

Prospettiva AI-RADAR: l’impatto su deployment e TCO

Per chi gestisce agenti in configurazione on-premise o self-hosted, la lezione è netta: ridurre il tuning manuale significa abbassare il costo operativo e la dipendenza da competenze di nicchia. Una pipeline così snella, basata su un unico rewrite e un set di casi di errore, può essere eseguita localmente senza necessità di servizi cloud esterni, rispettando vincoli di sovranità dei dati. Inoltre, la scoperta che iterazioni e segnali aggiuntivi non migliorano il risultato semplifica l’infrastruttura software: non servono cicli di ottimizzazione multi-step né strumenti di orchestrazione complessi. Il vero patrimonio, però, rimane il set di regressione; investire nella cura di quei casi di test è la precondizione perché il rewrite automatico funzioni. Sul fronte opposto, il diagnostico del divario train-validazione offre un criterio oggettivo per decidere quando fermare la messa a punto e affrontare il problema alla radice, riprogettando le skill.