L’assistenza che impara dalle proprie risposte

Ogni mattina, in migliaia di aziende che vendono un prodotto e ne curano l'assistenza, un operatore apre la coda dei ticket e riconosce la domanda al primo rigo: è la stessa a cui ha risposto la settimana scorsa, e il mese scorso, e probabilmente ieri. La risposta esiste, è scritta da qualche parte, forse in un manuale, forse in una email di sei mesi fa. Ma tra la domanda e la risposta c'è sempre lui, e il suo tempo costa più di qualunque software.

L'idea ingenua, quella che circola nei consigli di amministrazione da un paio d'anni, è che basti «mettere un chatbot». L'esperienza dice il contrario: un modello linguistico lasciato libero di rispondere ai clienti risponde sempre, anche quando non sa, e un'assistenza che inventa è peggio di un'assistenza lenta. Il problema tecnico interessante non è far rispondere una macchina. È decidere, richiesta per richiesta, se la macchina ha abbastanza elementi per rispondere, e costruire il percorso di riserva quando non li ha. Forge QA, la piattaforma di assistenza tecnica sviluppata da AYXZA, è costruita interamente attorno a questa decisione.

Rispondere quando si può, passare la mano quando si deve

Quando un cliente apre una richiesta su Forge QA, la piattaforma non passa la domanda a un modello generico e non spera nel meglio. La richiesta viene prima classificata da un modello leggero ed economico, poi confrontata con la base di conoscenza del prodotto a cui si riferisce: una knowledge base dedicata, con corpora separati per ciascun prodotto a catalogo, interrogata per similarità semantica tramite embeddings vettoriali su PostgreSQL con estensione pgvector.

Il punto di snodo è il calcolo della confidenza. Ogni risposta generata porta con sé un punteggio che combina la qualità del retrieval (quanto i documenti trovati somigliano davvero alla domanda) con la valutazione del modello. Sopra una soglia configurata, la risposta viene pubblicata come automatica e il cliente la riceve subito. Sotto la soglia, la risposta non sparisce: diventa una bozza a bassa confidenza che finisce nella coda umana, dove un operatore la vede, la corregge o la scarta. E se la base di conoscenza non contiene nulla di pertinente, il sistema lo dichiara: nessun contesto, nessuna risposta inventata, richiesta instradata direttamente a una persona.

È una scelta di architettura prima che di prodotto. Il modello non è mai l'ultima parola: è il primo filtro di una catena in cui l'essere umano resta il garante, con un costo per intervento che scende man mano che la base di conoscenza cresce.

Tre livelli, una sola piattaforma

Forge QA nasce multi-tenant su tre livelli, perché è così che il software si vende davvero in gran parte del mercato: c'è chi produce il software, c'è la rete di rivenditori o partner che lo distribuisce, e ci sono le aziende clienti finali che aprono le richieste. La piattaforma modella esplicitamente questa gerarchia. Il produttore amministra il catalogo prodotti e le basi di conoscenza; ogni rivenditore riceve un tetto di prodotti attivabili e, entro quel tetto, attiva in autonomia i propri clienti; ogni cliente vede soltanto i prodotti per cui è abilitato.

Il motore di entitlement che governa tutto questo è granulare: i diritti effettivi di ciascun cliente sono l'intersezione tra ciò che il rivenditore può offrire e ciò che è stato attivato, e ogni richiesta viene instradata sulla base di conoscenza del prodotto corretto. Per chi vende attraverso una rete, questo significa una cosa concreta: un'unica installazione serve l'intera filiera, con isolamento dei dati tra tenant e permessi che riflettono i contratti reali, non un organigramma teorico.

Il circolo che migliora il sistema a ogni risposta

La parte forse più interessante della piattaforma non è come risponde, ma come impara. Ogni richiesta risolta, che sia stata chiusa da un operatore o ratificata con un clic a partire da una risposta automatica, genera una voce candidata per la base di conoscenza: la domanda del cliente e la risposta che l'ha risolta, già accoppiate. Un responsabile le rivede in una console dedicata, ne modifica il testo se serve, esclude quelle dubbie, e con un'operazione esporta il documento consolidato nella knowledge base, che viene reindicizzata.

Il risultato è un circolo virtuoso misurabile: le domande a cui oggi risponde una persona diventano le risposte che domani il sistema darà da solo. Non c'è un progetto di «popolamento della base di conoscenza» da fare una volta e lasciar invecchiare; c'è un flusso continuo in cui il lavoro ordinario dell'assistenza produce, come sottoprodotto, il materiale che riduce il lavoro futuro. E poiché ogni voce passa da una revisione umana prima di entrare nel corpus, la base di conoscenza cresce senza inquinarsi.

Il cruscotto analitico chiude il cerchio: le richieste sono classificate in categorie disgiunte (risposte automatiche, risposte automatiche ratificate da un operatore, gestione umana, in attesa), così che la direzione veda in ogni momento quanta parte dell'assistenza la macchina sta effettivamente assorbendo, e con quale distribuzione di confidenza.

Sotto il cofano

Qualche dettaglio per chi valuta la sostanza tecnica. Forge QA è un'applicazione server-rendered in Python, su FastAPI con template Jinja2: niente single-page application, niente megabyte di JavaScript, pagine che si caricano e basta. I dati vivono su PostgreSQL, con pgvector per la ricerca semantica e migrazioni versionate. Il livello di intelligenza è separato dal dominio applicativo tramite una libreria interna che astrae i provider: i modelli si scelgono e si sostituiscono per configurazione, non riscrivendo codice.

Questa separazione ha una conseguenza economica diretta. La classificazione delle richieste usa un modello leggero; la generazione delle risposte un modello di fascia intermedia, selezionato dopo verifiche comparative su qualità e rispetto del formato di uscita. Il passaggio dal modello di fascia alta a quello intermedio, misurato internamente sulle chiamate reali della piattaforma, ha ridotto il costo medio per risposta di circa quattro volte, a qualità pari o superiore. Il costo per singola interazione è tracciato per token e visibile: chi amministra la piattaforma sa quanto spende, non lo scopre a fine mese dalla fattura del provider.

Anche i guasti sono progettati. Se il fornitore del modello è temporaneamente indisponibile, la richiesta del cliente non va persa: resta persistita nel suo stato iniziale ed è riprocessabile appena il servizio torna. La piattaforma gira dietro tunnel cifrato, con protezione CSRF su ogni operazione di scrittura e servizi gestiti a livello di sistema operativo. Sono dettagli che non si vedono in demo e si vedono benissimo il giorno in cui qualcosa va storto.

Una nota di cautela

Va detto con onestà ciò che i venditori di chatbot tendono a omettere: l'assistenza automatizzata delude quando viene promessa come sostituzione integrale delle persone. L'esperienza di settore converge su un punto: i modelli linguistici, senza un ancoraggio documentale e senza soglie, producono risposte plausibili anche quando sono sbagliate, e il danno reputazionale di una risposta inventata a un cliente pagante supera di molto il risparmio di qualche minuto di operatore.

Forge QA è costruito assumendo questa critica come vera. Per questo il sistema tace quando non ha contesto, per questo esiste la coda umana, per questo ogni voce che entra nella base di conoscenza passa da una revisione. La promessa non è «zero operatori»: è che gli operatori smettano di rispondere cento volte alla stessa domanda, e che ogni loro risposta lavori anche per le successive. Chi cerca la magia troverà altrove venditori disposti a promettergliela.

A chi serve, e come si prova

Forge QA è pensato per qualunque azienda che fornisca assistenza su prodotti o servizi propri: direttamente ai clienti finali, o attraverso una rete di rivenditori e partner. Serve una base documentale di partenza anche minima, perché il circolo di apprendimento fa il resto; serve la volontà di tenere le persone dentro il processo, perché il sistema è progettato per loro, non contro di loro.

AYXZA, lo studio italiano di sistemi software con intelligenza artificiale che ha progettato e sviluppato la piattaforma, la propone in due forme: come prodotto per aziende che vogliono strutturare la propria assistenza, e in white-label per software house e rivenditori che vogliono offrirla a marchio proprio alla propria rete.

Per una dimostrazione sui vostri dati reali, o semplicemente per capire se il caso d'uso regge, si può scrivere a ping@ayxza.com o partire da ayxza.com. La prima conversazione serve a valutare, non a vendere: se il problema non è adatto, lo si dice.