Molti progetti di intelligenza artificiale nelle banche iniziano oggi con un'idea semplice: si prende un grande modello linguistico, lo si collega a un'interfaccia di chat e si ottiene un assistente intelligente. Per i copilot basati su testo, questo approccio funziona sorprendentemente bene – ma non per i sistemi vocali in tempo reale. Chi vuole utilizzare l'IA vocale in modo produttivo deve ripensare completamente l'architettura di sistema sottostante.

L'attuale approccio standard per l'IA generativa si basa sulla classica architettura copilot: un utente formula una richiesta, un grande modello linguistico elabora il prompt e il sistema fornisce una risposta. Per le applicazioni basate su testo, questo modello funziona sorprendentemente bene. Tuttavia, per l'IA vocale, questa architettura è strutturalmente inadatta.

Il problema inizia con la latenza. Nei sistemi LLM classici, l'intero prompt viene elaborato prima che venga generata una risposta. Anche i modelli ottimizzati richiedono diverse centinaia di millisecondi o addirittura secondi per questo. Per un'interazione vocale naturale, questo è troppo lento. Gli esseri umani si aspettano risposte conversazionali nell'intervallo di 200-400 millisecondi. Tutto ciò che supera questo limite sembra già artificiale. Inoltre, i sistemi vocali generano flussi di dati completamente diversi rispetto alle interfacce basate su testo. Un singolo dialogo vocale può contenere rapidamente da 30 a 60 secondi di audio. Dopo la trascrizione, questo genera diverse migliaia di token di contesto. Se questo contesto viene passato integralmente a un modello linguistico, sia i costi che la latenza esplodono.

Molti dei sistemi copilot attualmente in fase di test ignorano questo problema. Trattano la voce semplicemente come un ulteriore strato di input: l'audio viene trascritto, inviato come prompt testuale a un LLM e quindi nuovamente sintetizzato in uscita. Tecnicamente funziona, ma l'architettura non scala bene.

Un'IA vocale produttiva richiede una pipeline che sia molto più vicina ai sistemi in tempo reale classici che ai chatbot.

Tipicamente, una tale pipeline è composta da diverse componenti specializzate:

Input audio
Speech-to-Text in streaming
Strato di intenzione (Intent Layer)
Memoria di sessione (Session Memory)
Modello linguistico
Text-to-Speech

Cruciale è l'elaborazione in streaming. Mentre l'utente parla, il sistema deve già iniziare l'elaborazione. I moderni sistemi Speech-to-Text forniscono frammenti di trascrizione continui. Questi possono essere analizzati in parallelo prima che l'intera frase sia terminata.

Altrettanto importante è una memoria di sessione esplicita. Gli approcci LLM classici memorizzano il contesto esclusivamente nel prompt. Nelle conversazioni più lunghe, questo contesto cresce rapidamente fino a diverse migliaia di token. Per i sistemi vocali, questo è inefficiente. Invece, il contesto viene memorizzato in una struttura di memoria separata e integrato selettivamente nelle chiamate del modello.

Orchestrazione dei prompt e strato di conoscenza

Il ruolo della struttura di controllo dell'agente

Una componente spesso sottovalutata dei moderni sistemi di agenti è il livello di controllo del modello stesso. In molti progetti proof-of-concept, il prompt consiste semplicemente in un'istruzione di sistema statica. Per le applicazioni produttive, questo è insufficiente.

In pratica, ogni agente specializzato richiede una struttura di controllo definita, composta da diverse componenti:

System Prompt: descrive il ruolo, il comportamento e la logica decisionale dell'agente.
Strato di contesto (Context Layer): contiene informazioni sulla sessione, la cronologia dell'utente e lo stato della conversazione.
Strato di conoscenza (Knowledge Layer): fornisce competenze specifiche del dominio.

Questo strato di conoscenza viene tipicamente realizzato tramite meccanismi di recupero, come database vettoriali o basi di conoscenza strutturate. Invece di memorizzare l'intera conoscenza specialistica nel prompt, i frammenti di informazione rilevanti vengono recuperati dinamicamente durante l'esecuzione e integrati nel contesto del modello.

Questa separazione è cruciale, specialmente nei settori regolamentati. La conoscenza specialistica può essere versionata, verificata e sottoposta a audit senza modificare la logica del modello stesso. Allo stesso tempo, si evita che grandi quantità di conoscenza statica siano permanentemente contenute nel prompt, il che aumenta i costi dei token e la latenza.

In pratica, questo porta a un'architettura a tre livelli:

Livello di controllo (Orchestrazione dei prompt): definisce il ruolo e il comportamento dell'agente.
Livello di conoscenza (Retrieval / Base di conoscenza): fornisce contenuti specialistici.
Livello del modello (LLM): genera la risposta.

Questa separazione consente di gestire agenti specializzati per diverse attività senza dover sostituire il modello sottostante. Per le aziende, ciò significa un controllo significativamente migliore sul comportamento, sui costi e sulla conformità dei sistemi di intelligenza artificiale.

Costi e conformità: sfide cruciali

Un altro punto critico è il modello di costo. Mentre un chatbot risponde spesso solo a singole domande, i sistemi vocali possono generare minuti di interazione continua. Ognuna di queste interazioni genera continue chiamate al modello, costi di trascrizione e generazione TTS. Senza una gestione dei token e una limitazione delle sessioni, i costi operativi possono diventare rapidamente incontrollabili.

Per banche e assicurazioni si aggiunge un ulteriore fattore: i requisiti normativi. Negli ambienti regolamentati da BaFin o FINMA, i sistemi devono essere tracciabili. Ciò riguarda la registrazione (logging), l'auditabilità e, in parte, anche la riproducibilità delle decisioni. Le architetture copilot classiche offrono poche soluzioni in questo senso. Molti modelli operano in modo probabilistico senza riproducibilità deterministica.

Per i processi rilevanti per la conformità, devono quindi essere implementati strati aggiuntivi, come il logging degli eventi, meccanismi di replay o alberi decisionali strutturati prima delle chiamate del modello. L'IA vocale non emergerà quindi a lungo termine come un'estensione dei chatbot esistenti, ma come una classe di architettura a sé stante. I sistemi saranno maggiormente orientati verso architetture di streaming, bus di eventi e sistemi di stato di sessione dedicati.

Perché i modelli di base generici non sono sufficienti

Un altro malinteso in molti progetti di intelligenza artificiale è che i grandi modelli di base (Foundation Models) siano considerati una soluzione completa. In pratica, tuttavia, questi modelli assumono solo una parte dell'architettura complessiva.

I modelli di base sono eccellenti nel generare linguaggio e nel riconoscere le relazioni semantiche. Tuttavia, non possiedono una conoscenza di dominio strutturata sui processi aziendali specifici o sui requisiti normativi.

Senza componenti architetturali aggiuntivi, si creano quindi sistemi che, sebbene linguisticamente convincenti, reagiscono in modo impreciso o inconsistente dal punto di vista tecnico. Nell'economia finanziaria, questo è particolarmente problematico. Le risposte non devono essere solo plausibili, ma tecnicamente corrette, tracciabili e verificabili.

Per questo motivo, stanno emergendo sempre più architetture in cui i modelli di base rappresentano solo una componente all'interno di un sistema più ampio.

La conoscenza specialistica viene integrata tramite meccanismi di recupero, basi di conoscenza strutturate o strati decisionali basati su regole. In tali architetture, il modello linguistico assume principalmente il compito della comunicazione naturale. La logica specialistica, la gestione del contesto e l'accesso alla conoscenza sono invece controllati da componenti di sistema specializzate.

Per i dipartimenti IT, questo significa un'importante intuizione strategica: il vantaggio competitivo non deriva dal modello di base utilizzato, ma dall'architettura di sistema che controlla questo modello e lo collega alla conoscenza specifica del dominio.

Horst Christian Wagner

Horst Christian Wagner lavora da oltre 30 anni su architetture di piattaforme e sistemi digitali. Si concentra su sistemi di agenti IA, interazione vocale e architetture di conoscenza per applicazioni ad alta intensità di dati. In vari progetti, sta attualmente ricercando architetture scalabili per l'IA vocale in tempo reale e agenti IA personalizzati.