Costruire un sistema AI che risponde sempre bene è semplice finché gli input sono tutti uguali. Appena iniziano a variare in modo significativo, trattarli con la stessa logica produce risultati mediocri su tutta la linea.
Il routing parte da qui: invece di scrivere un unico prompt che prova a gestire tutto, si separa il momento in cui si capisce che tipo di input è arrivato dal momento in cui lo si tratta. Ogni tipo di input ha il suo percorso, costruito appositamente.
In questo post vediamo cos’è il routing, come funziona tecnicamente, e perché in certi contesti è la scelta più sensata rispetto ad altri approcci. Il video qui sotto mostra il sistema in azione su un caso reale: la classificazione automatica delle lead commerciali.
Cos’è il routing come design pattern AI
L’idea dei design pattern nel software non è nuova. Nel 1994 la cosiddetta Gang of Four pubblica Design Patterns: Elements of Reusable Object-Oriented Software, un libro che raccoglie soluzioni a problemi ricorrenti nello sviluppo. Il ragionamento è semplice: certi problemi si ripresentano sempre, in contesti diversi ma con la stessa struttura. Ha senso documentare le soluzioni che funzionano e renderle riutilizzabili.
Lo stesso principio si applica oggi ai sistemi basati su modelli linguistici. Anche lì esistono problemi ricorrenti, e chi lavora su questi sistemi in modo strutturato finisce per ritrovarsi sempre davanti agli stessi nodi. Avere schemi collaudati per affrontarli evita di reinventare ogni volta le stesse soluzioni.
Il routing AI è uno di questi schemi. Si usa quando un sistema riceve input eterogenei, tipo messaggi, richieste o documenti di natura diversa, e trattarli tutti con la stessa logica non funziona.
Come funziona il routing AI: i tre componenti
Il routing funziona con tre componenti, ognuno con un ruolo preciso e separato dagli altri.
Il primo è il classificatore. Riceve l’input grezzo, capisce di che tipo si tratta e gli assegna un’etichetta. Restituisce tipicamente un oggetto strutturato con la categoria assegnata, un indice di fiducia e alcune note di contesto. Quell’indice di fiducia torna utile sui casi ambigui: se il valore è basso, si può dirottare l’input verso una revisione umana invece di procedere in automatico. Il prompt del classificatore va curato con attenzione, perché da quella singola decisione dipende tutto il comportamento successivo del sistema.
Il secondo componente è il router, deliberatamente semplice. Prende l’etichetta prodotta dal classificatore e attiva il percorso corrispondente, come uno switch in cui ogni categoria ha la sua uscita.
Il terzo componente, in realtà un insieme di componenti, sono le pipeline specializzate. Una per ogni categoria riconoscibile. Ogni pipeline lavora su un contesto pulito, progettata specificatamente per quel tipo di input. Può essere un singolo prompt, una sequenza di operazioni, o anche una serie di azioni che non coinvolgono affatto l’AI: una notifica, un aggiornamento su un CRM, un ticket di supporto. La cosa interessante è che ogni pipeline può essere progettata e migliorata in modo indipendente dalle altre. Se, ad esempio, la gestione delle lead calde non funziona come dovrebbe, si interviene su quella pipeline senza toccare il resto.
L’analogia del centralinista rende l’idea bene. Risponde, fa due domande, capisce di che si tratta, e passa la chiamata al reparto giusto. Il commerciale non riceve le chiamate del supporto tecnico. Ognuno lavora sul suo dominio.
Perché non basta un prompt unico con molte condizioni
La domanda che viene naturale è: perché costruire tutta questa struttura quando si potrebbe scrivere un unico prompt con una serie di istruzioni condizionali? In fondo sembra più semplice: scrivi tutte le regole in un unico posto, il modello le segue. Un’azienda che riceve richieste di contatto via form potrebbe pensare di scrivere qualcosa del tipo: “se il messaggio parla di un preventivo rispondi così, se parla di assistenza tecnica rispondi così, se sembra uno spam ignora”.
I modelli linguistici lavorano meglio quando il contesto è pulito e focalizzato. Un prompt che deve gestire tanti casi diversi chiede al modello di fare due cose insieme: capire cosa sta succedendo e rispondere in modo appropriato. Spesso privilegia una delle due. L’output diventa meno stabile, cambia leggermente ogni volta che lo stesso input viene processato, e quando si modifica una condizione si ottengono comportamenti diversi anche su tutti gli altri casi.
C’è anche un problema di manutenzione che emerge col tempo. Un prompt con molte condizioni ramificate cresce velocemente e ogni modifica diventa rischiosa: toccare una regola può alterare il comportamento su casi apparentemente non correlati. Chi ha gestito sistemi di questo tipo in produzione lo conosce bene.
Con il routing AI, ogni pipeline vede solo il tipo di input per cui è stata progettata. Il modello lavora in un contesto ristretto e pertinente, senza dover tenere a mente le regole per gli altri casi, e le risposte diventano più coerenti, specialmente sui casi ai margini.
C’è anche un vantaggio pratico nel debug. Con il routing si sa sempre quale percorso ha preso ogni input. Se qualcosa va storto, si guarda il log, si vede la categoria assegnata, e si capisce immediatamente se il problema sta nel classificatore o nella pipeline specifica. In un sistema monolitico, isolare il punto di rottura richiede molto più lavoro.
Il caso delle lead commerciali
Nel video qui sopra vi facciamo vedere come abbiamo costruito questo sistema usando uno strumento open source, Rivet, per la creazione visuale di workflow AI. L’obiettivo è automatizzare la gestione delle lead che arrivano dal form di contatto del sito.
Le richieste che arrivano sono di tipo molto diverso: potenziali clienti con un bisogno concreto, persone che stanno esplorando, candidati che cercano lavoro, messaggi generici. Trattarle tutte allo stesso modo significa sprecare tempo del team commerciale, oppure perdere una lead calda sepolta in mezzo alle altre.
Il classificatore legge il messaggio e assegna una categoria: lead calda, lead da nutrire, richiesta di lavoro, spam. Restituisce un oggetto JSON con categoria, indice di fiducia, priorità suggerita e note di contesto.
Il router legge la categoria e attiva il percorso corrispondente. Una lead calda attiva un percorso con notifica immediata al team commerciale. Una lead da nutrire attiva una sequenza diversa. Spam e candidature vengono gestiti con logiche ancora diverse.
L’input non attraversa una sequenza di step: viene smistato verso un solo percorso, costruito appositamente per quel tipo di contenuto. Gli altri rimangono inattivi.
Routing AI: cosa tenere bene a mente
Il classificatore è il componente più critico. Un’etichetta sbagliata manda l’input sul percorso sbagliato, e da lì in poi il sistema lavora correttamente su un contenuto che non doveva ricevere. Vale la pena testarlo con casi reali, compresi i borderline, e prevedere sempre una categoria residuale per gli input che non rientrano in nessuna di quelle definite.
Le categorie devono essere mutuamente esclusive. Se un input può ragionevolmente finire in due posti diversi, il classificatore andrà in difficoltà. Meglio chiarire i criteri prima di costruire il prompt.
Un aspetto da non sottovalutare è la scelta del modello per il classificatore. Per un compito di classificazione ben definito, un modello più leggero spesso basta, e i costi si riducono sensibilmente. Il modello più capace può essere riservato alle pipeline che richiedono ragionamento più complesso.
Le pipeline specializzate non devono necessariamente usare l’AI. Un percorso può mandare un’email, aggiornare un gestionale, creare un ticket. Il pattern di routing coordina componenti di tipo diverso, e costruirlo in questo modo lo rende più semplice da modificare nel tempo: si interviene su una pipeline senza toccare le altre.
Se stai costruendo un sistema AI che deve rispondere a input di natura diversa, e ti ritrovi a combattere con prompt sempre più lunghi e sempre meno stabili, il routing è probabilmente l’approccio che stavi cercando.
