Quando il software gestionale ha la testa piena e… la memoria corta – SECONDA PARTE

Nel numero 10 di Logyn abbiamo presentato alcuni problemi gestionali classici e abbiamo spiegato come esistano soluzioni intelligenti basate, appunto, su tecniche di intelligenza artificiale. Tali soluzioni non sono affatto fantascientifiche, come dimostra la corsa di importanti colossi dell’IT che puntano a dotarsi delle più recenti tecniche di apprendimento automatico. La domanda a cui tenteremo di rispondere in questo articolo è la seguente: “è possibile realizzare oggi soluzioni gestionali intelligenti”?

Riprendiamo la trattazione dello scorso articolo riassumendo i due casi d’uso presentati come classici problemi gestionali normalmente affrontati con tecniche che possiamo osare definire obsolete. Il primo scenario riguardava la compilazione assistita di form di dati, applicato a due casi molto simili, ovvero la “preventivazione a clienti” e l’“approvvigionamento
da fornitori”.

Abbiamo visto come i due problemi di fatto siano del tutto simili, al punto tale da poter essere affrontati da uno stesso sistema in grado di imparare dalle scelte compiute dagli utenti, in termini di relazione tra articoli e quantità, e di conseguenza, di suggerire sempre con maggior affidabilità nuove proposte per i successivi ordini o preventivi da compilare.
Il secondo scenario, invece, riguardava il problema della generazione automatica di configurazioni, sia per i colli di spedizione, sia per i piani di carico dei mezzi di trasporto.
Anche in questo caso i due problemi hanno un comune denominatore e si tratta di problemi affrontati classicamente con tecniche di programmazione vincolata che, però, per loro natura, richiedono tempi di calcolo spesso elevati.

Anche in questo caso possiamo immaginare una soluzione intelligente?

La risposta è sì, come infatti abbiamo accennato nello scorso articolo citando le tre principali famiglie di tecniche di Machine Learning che sono in grado di fornire una soluzione intelligente a ciascun problema presentato: Kernel Methods per il confronto e la ricerca di oggetti come preventivi e ordini; Markov Random Fields per la proposizione di nuove configurazioni di piani di carico a partire dalle precedenti; infine, per simulare le decisioni dell’utente possono essere utili le reti neurali della famiglia delle Feedforward Neural Networks.

ARCHITECTURE & DESIGN
COME REALIZZARE SOLUZIONI GESTIONALI INTELLIGENTI?
Soluzioni teoriche o tecniche implementabili?
Fino a qui abbiamo parlato di tecniche, di approcci teorici e di algoritmi, ma a questo punto ci chiediamo se tutto ciò possa prendere la forma di un software installabile su un nostro server o nel Cloud e integrabile con il software gestionale che un’azienda ha in dotazione. La risposta è un po’ più articolata di un semplice sì o no. Le tecniche presentate possono certamente essere implementate oggi in un software che risolva in modo alternativo i problemi enunciati. Nel seguito dell’articolo, infatti, proporremo un’architettura software adatta allo scopo. Non tutti i software gestionali, tuttavia, sono in grado di interfacciarsi nativamente con questi sistemi intelligenti poiché essi richiedono un “approccio a servizi” (Service Oriented Architecture) e un livello tecnologico di base che non tutti i prodotti gestionali sul mercato possono vantare.

Service Oriented Architecture (SOA) e tecniche di apprendimento automatico: binomio vincente
L’architettura che presentiamo di seguito – potremmo dire – è la naturale implementazione di un sistema incentrato su due cardini fondamentali: architettura orientata ai servizi (SOA) e utilizzo sinergico di algoritmi di apprendimento automatico.

Ma perché SOA? Semplicemente perché questa architettura del software prevede un approccio che prescinde dal problema specifico e si focalizza sul concetto di servizio così come emerge dal dominio che si sta affrontando. Negli scenari descritti, infatti, possiamo immaginare il software gestionale come un consumatore di diversi servizi (ricerca di documenti, calcolo MRP, workflow di acquisizione di un ordine di vendita, ecc.), alcuni dei quali, ad esempio, sono in grado di rispondere in modo intelligente ad una particolare richiesta: “proponi un nuovo preventivo per questo cliente”, oppure, “formula un nuovo ordine fornitore”.
Possiamo immaginare che ci siano quindi diversi servizi di business “intelligenti” con cui il software gestionale si interfaccia, in due fasi distinte:

a. Continuamente esso comunica tutte le azioni e tutte le scelte compiute nel tempo dagli utenti inerenti quel particolare scenario (es. tutte le configurazioni di piano di carico preparate dagli utenti).
b. A ciascun servizio rivolge delle richieste a cui corrisponderanno delle risposte che si definiscono “intelligenti”, poichè frutto di una fase di apprendimento derivata dalla fase a) reiterata nel tempo. Se riprendiamo la descrizione iniziale, è facile verificare che questo modello si adatta a tutti gli scenari presentati.

Nello scenario 1, infatti, il gestionale comunicherà tutte le combinazioni di articolo e quantità che gli utenti opereranno nella compilazione dei preventivi. Quando l’applicazione vorrà suggerire all’utente un nuovo preventivo, sarà sufficiente rivolgere allo specifico servizio intelligente un’opportuna richiesta che chieda, in funzione dell’utente che sta operando e di altri parametri in ingresso (es. il cliente per il quale si sta formulando il preventivo), quale sia la nuova combinazione suggerita di articoli e relative quantità.

Lo scenario 2 è del tutto simile. Il gestionale comunicherà ad un servizio deputato tutti i piani di carico o le composizioni di colli che via via l’utente formulerà manualmente. Successivamente, l’applicazione potrà lei stessa proporre un piano di carico o una composizione di colli di spedizione semplicemente invocando il servizio intelligente con una serie di input, tra cui l’utente operatore, e il servizio risponderà con una lista di risultati corrispondenti ad un piano di carico o ad una composizione di colli. L’utente potrà decidere se il risultato proposto è corretto o non corretto e questo feedback servirà ad addestrare il servizio intelligente (attraverso la fase a) che si reitera) per migliorare le sue prestazioni nelle successive richieste.

Ad ogni problema, quindi, si avrà a disposizione un servizio specifico, la cui implementazione potrebbe essere intelligente, ovvero in grado di apprendere. Ciascuno di questi servizi intelligenti, tuttavia, ha delle caratteristiche comuni e la sua implementazione deve occuparsi di una serie di problematiche che si potrebbero concentrare in un unico server intelligente. Il modello che possiamo immaginare, quindi, è un insieme di servizi di business, alcuni dei quali appunto intelligenti, che basano alcune parti non funzionali della loro implementazione su un Intelligence Server comune.

Un server intelligente per servizi intelligenti
Il modello di Intelligence Server che presentiamo è quello proposto dalla piattaforma open source PredictionIO (https://prediction.io). L’architettura di tale piattaforma può essere schematizzata come in figura.
 

 
In particolare possiamo riconoscere due componenti principali:
1. Event Server: si tratta del componente del sistema intelligente che riceve le notifiche da parte delle applicazioni delle scelte e delle azioni compiute dagli utenti. Questo server raccoglie queste informazioni. Esse costituiscono, analogamente all’esperienza di un bambino, le basi su cui si fonda il processo di apprendimento.
2. Engine: si tratta dell’elemento attivo del sistema che riceve dalle applicazioni richieste specifiche e restituisce i risultati predittivi elaborati in base all’esperienza-conoscenza acquisita nel tempo e immagazzinata dal registro degli eventi.

Entriamo ora maggiormente in dettaglio e cerchiamo di capire: cosa rappresenta, nell’architettura proposta, un Engine?

Come abbiamo già detto, i problemi che abbiamo presentato, anche se diversi nell’esposizione, trovano soluzione in medesime tecniche di intelligenza artificiale. Moltissimi sono i problemi concreti da risolvere, ma poche sono le tecniche che è sufficiente applicare, magari combinate tra loro, per risolverli. Da qui l’idea di realizzare un sistema che abbia innestate al suo interno, come se fosse un sistema componibile, una libreria di moduli, ciascuno dei quali rappresenta un risolutore di una gamma di problemi. Nel caso presentato nello scenario 1, avremo bisogno di un unico risolutore per entrambi i problemi concreti presentati, disponibile però in due rappresentazioni.

Chiameremo Engine Template il risolutore di una stessa gamma di problemi. Chiameremo, invece, Engine Template Gallery la libreria dei risolutori di diverse classi di problemi.

Come abbiamo detto un risolutore (Engine Template) è in grado di risolvere una gamma di problemi. A seconda del problema specifico ciò che sarà in grado di rispondere alle domande che verranno poste dal gestionale saranno delle implementazioni specifiche del risolutore, ovvero degli esemplari specifici nati da uno stesso Engine Template. Per analogia, pensiamo alla relazione che c’è tra un biscotto (l’esemplare di risolutore) e un set di stampi (risolutore) che consente di creare diverse forme, ma pur sempre biscotti. Chiameremo pertanto Engine l’esemplare specifico di risolutore.

Tornando ai casi presentati nello scenario 1, avremo uno stesso risolutore (Engine Template) e due esemplari specializzati (Engine), uno per rispondere al caso di compilazione assistita di form per la preventivazione degli ordini e un secondo esemplare per il caso di compilazione ordini per l’approvvigionamento da fornitore. Dal punto di vista dell’architettura SOA, un particolare Engine viene pubblicato e visto all’interno del sistema come uno specifico Service (es. ProponiNuovoPreventivoCliente).

Ma cos’è che fa funzionare un Engine e cosa lo rende intelligente?
La risposta sta proprio nella stretta relazione che si instaura tra un Engine Template e l’insieme delle informazioni ed eventi raccolte dal sistema tramite l’Event Server. Un Engine sa proporre in tempo reale delle risposte (Predicted Result) dopo che è stato addestrato per un certo periodo e si è costruito così un modello di conoscenza sul quale si basano le risposte che esso sarà in grado di fornire in tempo reale. L’acquisizione di nuove informazioni attraverso ulteriori sessioni di apprendimento consente all’Engine di aggiornarsi, di evolvere in modo tale da saper rispondere in modo sempre più preciso alle query che gli vengono sottoposte.

A seconda del problema da risolvere, e quindi dell’Engine Template utilizzato, il tempo di costruzione del modello a partire dai nuovi feedback può essere più o meno elevato. Alcuni modelli, in particolare, possono essere aggiornati online. In ogni caso, una volta aggiornato il modello, esso è immediatamente operativo. L’implementazione interna di un Engine Template si basa tipicamente sull’utilizzo sinergico di più algoritmi di machine learning. Lo stesso algoritmo può essere riutilizzato all’interno di più Engine Template.

Dal punto di vista dell’architettura del sistema, l’adozione di un server come PredictionIO consente di concentrarsi sullo sviluppo degli Engine Template, lasciando alla piattaforma la raccolta degli eventi, dei feedback, il deployment di nuove versioni di modelli, problemi di distribuzione e parallelizzazione degli Engine ed altri servizi infrastrutturali comuni a tutti i risolutori.

Concludiamo ritornando alla domanda iniziale, ovvero se esiste oggi la possibilità di realizzare un software intelligente di questo tipo: la risposta è sì, a patto di possedere una conoscenza non improvvisata di queste tecniche.

A supporto dello sviluppo, inoltre, esistono una varietà di framework utilizzabili sia su piattaforma Microsoft.NET sia su piattaforma Java EE, ciascuno dei quali offre una suite di algoritmi di machine learning. Tra i tanti citiamo, solo a titolo di esempio, Accord.NET (http://accord-framework.net ) e Apache Spark (http://spark.apache.org). Proprio su quest’ultimo si basa il progetto PredictionIO e l’implementazione di alcuni Engine Template che esso offre nella propria Engine Template Gallery.

Come in altri contesti l’implementazione della soluzione migliore parte da un’analisi approfondita del problema e dalla scelta e combinazione degli algoritmi di machine learning più adatti. Per il momento questo è il valore e il contributo fondamentale alla soluzione che nessuna macchina può rimpiazzare.