L’utilizzo del canale vocale per interagire con gli oggetti e i servizi di uso quotidiano ha fatto sì che l’Internet of Things sia entrato in maniera concreta nelle nostre case, scrollandosi di dosso quella definizione di “visione” astratta. I diversi modelli di home assistant – quali quelli basati sui servizi Google Assistant e Amazon Alexa – oggetto dal 2018 di un vero boom commerciale, rendendoci tutti un po’ più “power user” dell’IoT. Ma oltre a chiedere di accendere e spegnere le luci in salotto, o di cercare una ricetta senza latte e uova, quali sono le opportunità offerte da questi dispositivi? Possono rappresentare un nuovo canale della customer care? Qual è il costo e quali sono le difficoltà dell’introduzione del voice – e in generale del Natural Language Processing (NLP) – in ottica multicanale? Come può l’esperienza IoT aiutare nella system integration? Cambiando punto di vista, si potrebbero considerare gli home assistant come dei sensori, perché “sentono” (è proprio il caso di dirlo) una caratteristica ambientale, cioè le frequenze dell’udibile umano. Allo stesso modo, possono anche essere visti come degli attuatori, poiché agiscono sull’ambiente diffondendo dei suoni sulla base dei comandi impartiti. In questo senso ben si presterebbero a essere interconnessi a dei middleware IoT.
Indice degli argomenti
Perché gli home assistant sono dispositivi IoT?
Partiamo anzitutto dalle basi: Google Home e Amazon Echo sono davvero da considerarsi dei device IoT? La domanda è lecita, in fin dei conti questi dispositivi sembrano proprio degli smartphone senza display e con un audio di qualità superiore. Ci si possono perfino “installare” le app (il virgolettato è d’obbligo, dato che le app – o meglio le skill su Alexa e le actions su Assistant – non finiscono fisicamente nel dispositivo ma vengono abilitate nel Cloud). Insomma non ci sembrano proprio degli smart-meter o dei reader RFID. Sembrano tutt’al più degli end-user device che possono anche fungere da hub IoT per dispositivi terzi compatibili.]
Perché collegare gli home assistant ai middleware IoT?
Semplificando, un middleware è un layer di una architettura software preposto a veicolare messaggi fra componenti hardware e software eterogenei, in tipologia e in numero. Le architetture client-server non vanno bene per l’IoT: per far parlare n dispositivi fra di loro si dovrebbero creare link diretti (es. per 100 dispositivi servono quasi 5.000 connessioni…). Le architetture client-server hanno anche un altro grosso problema per l’IoT: sono sincrone. A ogni richiesta corrisponde immediatamente una risposta. I middleware IoT veicolano invece scambi di messaggi fra più peer in maniera asincrona. Vale a dire che una richiesta inviata da una applicazione o un dispositivo può essere accontentata anche molto tempo dopo il suo arrivo, con un messaggio che questa volta arriva spontaneamente (leggi: in maniera asincrona) a chi ne aveva fatto richiesta. Un po’ come succede per le push notification sui nostri smartphone.
Per fare tutto questo, i middleware hanno bisogno di astrarre la specifica complessità tecnologica, definendo una lingua franca che viene parlata da tutti i dispositivi interconnessi. In questo caso si parla di middleware model-driven, e ci sono alcuni esempi di aziende e start-up anche nel mercato italiano che ne forniscono di propri (es. www.woxplatform.com ).
Quindi, a che pro collegare gli home assistant sui middleware IoT? Grazie al forte livello di astrazione, è possibile fornire servizi a interazione vocale in maniera trasparente rispetto al client utilizzato: poco importa qual è il client che ha originato la richiesta, all’applicazione interessa solo conoscerne il contenuto e confezionare la risposta. Anche aggiungere altri canali diventa immediato: oggi sviluppo per Assistant e Alexa, domani per chatbot Web, centralino VoIP, Telegram, Whatsapp, ecc. Probabilmente le applicazioni backend nemmeno se ne accorgeranno. Si raggiunge la multicanalità.
I punti critici
Tutto così semplice? Ovviamente no. Perché di mezzo ci sono Big G e Amazon. Anzitutto – come già citato – bisogna sviluppare le action e le skill, da pubblicare sui rispettivi store. Chiaramente, se l’applicazione “non piace” (perché vìola le policy di sviluppo), questa non sarà mai pubblicata. Ad esempio, su Alexa in Europa non è possibile fornire informazioni finanziarie personali all’utente che le richiede, neanche garantendo l’utilizzo delle più articolate tecniche di identificazione e autorizzazione. Su Assistant invece è obbligatorio implementare il flusso delle Google Orders API per implementare scenari di pagamento.
Un secondo scoglio è dato dalla tecnologia AI dietro ai servizi citati. Dietro alle nostre voice app ci sono dei sistemi intermedi proprietari che fanno 2 cose:
- effettuano la conversione di un file wave in una stringa, il cosiddetto statement, tramite opportune tecniche di speech-to-text;
- fanno l’intent matching, cioè a partire da un’analisi semantica della stringa cercano di capire cosa l’utente stia chiedendo fra un insieme finito di casi che il progettista della app ha previsto a monte.
Questi due servizi sono forniti ovviamente in casa dai proprietari degli ecosistemi voice, e se per lo speech-to-text non ci sono particolari problemi, l’intent matching invece ci causa qualche grattacapo.
Anzitutto, non è assolutamente detto che, allo stesso statement, Google (tramite DialogFlow) e Amazon (tramite Alexa Skills Kit) rispondano allo stesso modo. Parliamo di intelligenza artificiale, è normale che diverse implementazioni di diversi algoritmi fuzzy possano dare risultati oscillanti (alle volte, anche la stessa implementazione dà risultati diversi, sic!). Si arriva al paradosso che la stessa domanda può ricevere risposte diverse a seconda del client utilizzato.
In seconda battuta, il modo in cui ci viene permesso di modellare gli intent (cioè le possibili richieste esprimibili dagli utenti) è diverso. Google ad esempio ci permette di prendere l’intera frase pronunciata dall’utente e farne quello che vogliamo (es. mandarla a un middleware IoT), Amazon ci dà invece qualche limitazione.
Per non parlare poi della manutenzione: per aggiungere o modificare degli intent bisogna fare la medesima operazione su ciascuna delle piattaforme Cloud. Immaginate di dover caricare 2.000 intent con 5 frasi di training ognuno per 2 client. O magari 3, 4, 5, 6 client. Il costo esplode e l’errore umano è dietro l’angolo.
La multicanalità perde pezzi.
Soluzione: posizionare i moduli di intent matching “dietro” ai middleware
Quello che insegna l’ingegneria del software da ormai alcune decadi (si legga il volume del 1995 “Design Patterns: Elements of Reusable Object-Oriented Software” della gang of four) è di mettere a fattor comune gli elementi software condivisi da più componenti architetturali.
In sostanza il consiglio è quello di “instupidire” i client, rinunciando ad alcune delle loro features native a beneficio della multicanalità. Lo si fa attraverso la creazione di un modulo AI centralizzato che ascolta i client – ops, i sensori di voce – e gli impartisce degli ordini («Pronuncia questa frase: “…”»). Tale modulo non potrà che essere uno dei tanti nodi della rete IoT, la cui sola differenza sarà quella di essere un agente virtuale al 100% (o quasi, su qualche bare metal questo componente dovrà pur girare!). In fin dei conti, che cos’è un modulo AI se non un attuatore di decisioni?
L’intent matching messo a fattor comune dietro al middleware IoT garantirà uniformità della risposta, semplicità di manutenzione, UX omogenea, integrazione facilitata con dispositivi IoT terzi, e, ovviamente, la multicanalità.
Cosa si perde? Ogni home assistant è chiaramente un universo a sé, con un ecosistema di servizi e di integrazioni che arricchiscono l’offerta cercando di attrarre gli sviluppatori come le… API col miele. Per queste aggiunte non si può che intervenire per differenze, agendo direttamente sulle voice skills nei Cloud di riferimento.
Video Google Assistant Developer 2020 (in inglese)
L’Internet of Everything
L’approccio model-driven dei middleware si sposa perfettamente con la nuova vision dell’Internet of Everything (IoE) dove tutto sarà un sensore – persone, dati, processi e oggetti – e tutto sarà integrato. Se l’esercizio di astrazione svolto in questo articolo vi è sembrato complicato o innaturale, immaginate quanto lo potrà essere nel 2025 collegare 8,2 miliardi di persone, ognuna con quasi 10 device connessi a testa. E fra le tante cose che la pandemia da COVID-19 ha insegnato c’è quella che bisogna curare i canali di vendita e assistenza digitali almeno quanto quelli fisici, perché sono gli unici che scalano e che non hanno bisogno di mascherine per funzionare. I clienti, oramai power user, si aspettano che alcuni servizi siano fruibili in ottica multicanale e magari senza dover avere le mani occupate, perché, si sa, andiamo sempre tutti di fretta. Per ottenere un vantaggio competitivo, le aziende, già impegnate a sviluppare i propri prodotti, possono intelligentemente scegliere di dare in outsource quantomeno l’infrastruttura della propria customer service e consolidare delle partnership con IoT provider virtuosi e lungimiranti.
