Cosa può essere andato storto nei primi test di Amazon Go?

Chi si occupa di Retail ha certamente sentito parlare del nuovo supermercato senza cassieri di piccolo formato che Amazon sta testando a Seattle. Avrà anche sentito che l’apertura al pubblico è stata rinviata per problemi tecnici quando nel negozio sono presenti più di 20 clienti https://www.wsj.com/articles/amazon-delays-convenience-store-opening-to-work-out-kinks-1490616133.

Qualche commentatore ha parlato di problemi con i sensori RFID, ma Amazon dichiara di usare “computer vision, sensor fusion and deep learning” cioè le stesse tecnologie basate sull’Intelligenza Artificiale alla base delle auto che si guidano da sole https://www.amazon.com/b?node=16008589011.

Se Amazon avesse usato dei tag RFID su ogni prodotto e dotato i varchi d’uscita con appositi lettori contactless, avrebbe certamente evitato i problemi di “affollamento” ma avrebbe aumentato in modo insostenibile i costi di gestione per applicare i tag a prodotti con basso margine unitario. Il settore Grocery viaggia da decenni su bassi margini e alta rotazione e il costo non trascurabile dei tag RFID relega questa tecnologia a merceologie con più elevati margini unitari.

Le tecniche di computer vision possono invece condividere efficienti servizi Cloud e anche i costi iniziali di impianto sono limitati perché basati su normali telecamere. Le soluzioni software sono costose da sviluppare, ma economiche da riprodurre e, con il Cloud, anche da gestire. Per questo “il software sta mangiando il mondo” ed Amazon è in prima linea.

L’eclatante acquisizione della catena Whole Foods del mese scorso indica che gli esperimenti con il format Amazon Go non sono esplorazioni di possibili nuovi territori, ma parte di una strategia a lungo termine destinata a spostare i termini di paragone per tutti i consumatori.

Cosa può essere andato storto?

Credo si possa escludere che ci siano stati problemi di banda oppure scarsità di risorse sul Cloud. La mia ipotesi è che potrebbero essere state utilizzate periferiche semplici, forse per ridurre all’osso i costi di impianto, e che l’intelligenza sia stata concentrata solo sul Cloud.

Un’architettura centralizzata ha il vantaggio della semplicità tecnica e architetturale, ma si scontra con i problemi di latenza che, specialmente con le soluzioni Cloud, non sono affatto trascurabili. La latenza è il tempo necessario per lo scambio dati tra due sistemi. Pur viaggiando alla velocità della luce, elevata ma non infinita, i segnali elettrici devono attraversare anche diversi dispositivi di instradamento, sia in andata che in ritorno. Ritardi di decine di millisecondi possono sembrare trascurabili, ma se sono necessarie decine di scambi dati con il Cloud per capire se il cliente sta prelevando il prodotto, oppure lo sta rimettendo sullo scaffale, allora si capisce perché possono sorgere problemi. La banda può essere facilmente allargata, ma ridurre la latenza è un’impresa molto più ardua e scendere sotto a certi limiti, impossibile.

Intelligent Cloud & Intelligent Edges

Le architetture distribuite, quelle in cui una certa dose di intelligenza è presente anche in periferia, sono più complesse da progettare e da gestire, ma hanno diversi vantaggi.

Una App è più efficiente di un’applicazione basata su browser perché opera a diretto contatto con l’hardware, con latenze trascurabili verso il processore locale. Questo è uno dei motivi per cui si sta imponendo un movimento di pensiero denominato “Off-line first”, cioè progettare le Applicazioni in modo da sfruttare le risorse locali per un’esperienza dell’utente più fluida e reattiva, riducendo al tempo stesso il volume di dati scambiati via Internet e assicurando alcune funzionalità anche in caso di guasti esterni. Per un POS (punto cassa) questa non è un’opzione, ma una necessità.

Questo orientamento segue di qualche anno e amplifica il “Cloud First”, cioè progettare espressamente per il Cloud con tecniche di condivisione stretta delle risorse tra utenti diversi, di esposizione di servizi basati su API standard e di sfruttamento dell’elasticità rapida offerta dalle moderne piattaforme Cloud. Da qui il recente slogan “Intelligent Cloud & Intelligent Edges”.

Quasi sempre le periferiche, siano esse uno smartphone o una videocamera, hanno capacità di elaborazione locale che consentono di risparmiare risorse sul Cloud, inviando dati “raffinati” invece che “grezzi”. Inoltre quando i millisecondi contano, le operazioni locali hanno una latenza trascurabile e reazioni praticamente istantanee, anche con processori poco potenti.

Portare dentro alle periferiche locali degli algoritmi che prima stavano sul Cloud consente di ottenere dei veri e propri salti di qualità. Lo ha dimostrato Microsoft alla conferenza mondiale per gli sviluppatori Build, tenuta a Seattle lo scorso Maggio https://news.microsoft.com/features/microsoft-aims-empower-every-developer-new-era-intelligent-cloud-intelligent-edge.

Il trasferimento di alcuni algoritmi (anche di Intelligenza Artificiale) dal Cloud alle apparecchiature locali, ha ridotto i tempi di reazione ai malfunzionamenti di un complesso macchinario da 2 a 0,1 secondi, con un miglioramento di ben 20 volte.

La gestione di grossi volumi di dati e il training di un algoritmo di Intelligenza Artificiale non possono che avvenire sul Cloud. Ma una volta sintetizzato, l’algoritmo può essere spostato in periferia a diretto contatto dei fenomeni da controllare o delle immagini da riconoscere. Ad un livello più basso, semplici algoritmi di filtraggio dei dati consentono di inviare in rete solo quelli rilevanti, riducendo lo spreco di risorse su Internet, sul Cloud e, in definitiva, i costi diretti e indiretti.