Bene e benvenuti su Gitbar, altra settimana e nuovo episodio, anche oggi con un ospite.In questo periodo il Gitbar, nonostante la pandemia, continua a essere sempre più affollato e questo mi rende super entusiasta.Oggi infatti abbiamo un ospite super interessante, un amico di Luciano, quindi già questo garantisce sulla qualità dell'ospite, ma prima di svelarlo il mio ruolo è quello di ricordarvi i nostri contati info@gitbar.it via mail o @brainrepo su twitter questi sono i modi canonici naturalmente il gruppo telegram gruppo telegram trovabile cercando semplicemente gitbar e là siamo più di 300 e continuamente prendiamo diversi argomenti interessanti per esempio oggi parlavamo della nuova uscita di Node.js che grazie al WebAssembly gira anche sui browser e questo ci ha lasciato un po di stucco e ha aperto un mondo e delle discussioni abbastanza controverse ma se volete scoprire di più il gruppo Telegram sta lì quindi se non l'avete ancora fatto iscrivetevi comunque bando alle ciance io direi che possiamo iniziare benvenuti su github il podcast dedicato al mondo dei full stack developer i mezzo artigiani mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo Steve Hawking diceva che l'intelligenza artificiale potrà mettere fine all'umanità invece io credo che la vera intelligenza artificiale possa fare un enhancement di quelle che sono le capacità dell'uomo adesso questa visione un po' filosofica per un attimo la mettiamo da parte invece parliamo di giocattoli con chi questo argomento lo conosce molto bene parlo di Luca Marchesotti che è stato Researcher allo Xerox Xerox Research Center Europe ed è founder di Sparked.Ciao Luca! Ciao caro Mauro! Benvenuto su Gitbar, anche tu hai la birra fresca e siamo pronti.Io sono super curioso di riempirti di domande, credimi.No, contentissimo per questo invito, gentilissimo, sono veramente contento di essere qua con te e non ho la birra ma ho il Monster Energy perché fine settimana intensissima di lavoro con tante cose interessanti quindi siamo pronti per partire.La prima domanda che voglio farti Luca è come sei arrivato al mondo del machine learning? Qual è stato il tuo percorso? Ma diciamo che ho incominciato quando ancora AI e machine non erano cool, nel senso che nel 1998 mi trovavo nella hall dell'Università di Genova e c'era questo volantino che ho scritto "Si offrono tesi all'estero" e nel '98 io sono andato a fare una tesi di ricerca all'Università di Kingston a Londra e lì c'era appunto il mondo Linux nel 98-99 che si stava affacciando appunto sulla scala globale e mi avevano proposto di fare un'attesi appunto su questa cosa che si chiamava intelligenza artificiale.Io ne sapevo veramente ben poco e da lì è cominciato tutto il resto.Sono 25 anni quasi che ci lavoro, anzi no, 23-24 e diciamo ho visto tutte le fasi.Ho visto la fase 1 che era la fase che cosa è questa cosa, la fase 2, che era la fase dei risultati, un po' della disattenzione, del calo dell'interesse e poi ho visto la fase 3 che l'esplosione.Anche perché è un mondo che non risale agli ultimi dieci minuti, anche se così parrebbe visto da fuori.Di modernità ce n'è, ma ci sono anche delle basi storiche che fanno sì che questo mondo sia un po' più robusto di come lo immaginiamo.Ma in tutto questo percorso, secondo te, cosa è cambiato nel modo di vedere l'intelligenza artificiale in genere? Ma diciamo che l'intelligenza artificiale oggi non la vedi.E' questa la cosa che più mi sorprende.Le persone non del settore non vedono che l'intelligenza artificiale ha già un impatto incredibile sulle nostre vite, tutti i giorni.Quindi tutte le volte che noi apriamo un telefonino ci sono, io direi, centinaia di servizi basati su AI o di features che noi utilizziamo che appunto fanno capo un algoritmo di intelligenza artificiale.Credo che, come dici tu, la vera intelligenza artificiale, quella che lavora tutti i giorni, è ben lontana dai robot che conquisteranno il mondo, ma affianca il lavoro dell'uomo tutti i giorni.Tu hai vissuto il mondo e questo mondo, insomma, restringiamo il campo, parliamo di machine learning, perché quando si parla intelligenza artificiale nel calderone c'entra tutto e il contrario di tutto.Ma tu hai vissuto il mondo del machine learning sia dal lato della ricerca che oggi dal lato dell'impresa.Cosa è cambiato? Qual è la differenza? Diciamo che appunto in queste tre grandi fasi, ok? La fase 1 che io ho vissuto dall'inizio del nuovo millennio fino al 2010.In questa prima fase, diciamo che l'atteggiamento dell'azienda era l'indifferenza, nel senso che le aziende, anche le grandi, erano totalmente indifferenti al mondo del machine learning.Nel 2013 tutto cambia e cambia un pomeriggio di settembre in una conferenza che si chiama ECCV, European Conference of Computer Vision, e in quel pomeriggio cosa succede? Succede che Geoff Hinton, che è diciamo il padre del deep learning, annuncia che hanno vinto una competizione di machine learning con un delta, quindi con un margine double digit, una cosa mai vista.Quindi ci sono centinaia di persone, tra cui il sottoscritto, che guardano questi risultati a bocca aperta e in questa sala ovviamente c'era anche Google.e ovviamente loro come pionieri del machine learning si accorgono immediatamente del potenziale di questa tecnologia, comprano la startup di Geoff Hinton e il resto è storia.Quindi si apre la seconda fase.La seconda fase è una fase in cui le grandi di un certo tipo, quindi le deep tech, parliamo di gaffa quindi google facebook amazon e microsoft e apple vanno a mille all'ora dentro lo sviluppo del machine learning e nel come dire nell'adozione del machine learning a 360 gradi nell'azienda cioè non parliamo qui di apple o di amazon che vanno a sviluppare una feature in un prodotto specifico.Lo vanno a sviluppare in tutti i dipartimenti e quindi dall'accountancy alla logistica alle mobile apps eccetera.Terza fase, e concludo, in cui viviamo attualmente è una fase in cui non solo le grandi deep tech ma le società ad alta tecnologia di dimensioni varie, se non adottano almeno hanno l'ambizione, hanno nel business plan una riga sottolineata col pennarello in cui dicono vogliamo introdurre AI nei nostri business workflows.Chiaro chiaro e tra l'altro da quel momento in poi nell'ecosistema sono iniziata ad apparire tutta una serie di as a service per andare a risolvere una serie di casi d'uso particolare.Abbiamo visto anche le grandi, parliamo di Amazon, parliamo di Microsoft, parliamo di BM, parliamo di Google, che offrono questi as a service.Tu, ne parlavamo prima nel Furionda, così nella pre birra, tu mi hai raccontato che durante la pandemia un quasi colpo di follia vi ha portato a fondare una nuova società e la mia domanda è intanto quale spazio c'è per le piccole aziende? Naturalmente sono quasi tutte piccole se paragonate a quei colossi.Che spazio c'è? E poi naturalmente sono curioso di sapere qualcosa in più di questa esperienza che è iniziata proprio quando il momento di crisi, insomma, ti dice forse non è il caso di rischiare.Certo.Allora riguarda la prima domanda, qui noi parliamo di una nuova industria, ok? Quindi le opportunità sono molteplici.Le AI e il machine learning in particolare attualmente rappresenta un nuovo mercato, ok? Ben distinto da altri mercati come il mercato cloud, per esempio, ok? Che, diciamo, è un mercato affine e congruente, però è un mercato diverso, con dei prodotti diversi, delle soluzioni, dei bisogni clienti diversi.Quando parliamo di mercato dei machine learning, tipicamente parliamo di tre segmenti.Un primo segmento, è quello ovviamente del segmento API, il segmento del machine learning as a service, quindi un segmento dove società come la nostra, società come per esempio Clarify, che è un leader nel settore, portano sul mercato la loro tecnologia e la mettono a disposizione di developers o di industria as a service.Chiarissimo, immagino.Il secondo segmento è un segmento in cui invece abbiamo delle soluzioni o dei prodotti bespoke, cioè io ho un problema di computer vision che è il machine learning applicato alle immagini e i video vado a sviluppare un prodotto che risolve quel problema specifico.Poi c'è un terzo segmento che è chiamato ML Ops, quindi tutti quei tool, tutti quegli strumenti che servono a un data scientist, servono a un utente di machine learning o developer di machine learning avanzato per addestrare modelli ancora una volta bespoke.Chiaro, quindi in realtà il panorama è ben più vasto del servizio transcribe di Amazon o di riconoscimento delle immagini di Google da quello che ci stai dicendo e soprattutto credo che quello che si debba capire, correggimi se sbaglio perché io non sono un esperto di questo dominio quindi potrei dire delle castronerie, anzi sono qua proprio per dirle in modo che tu mi possa correggere e tutti possano vedere la mia inettitudine riguardo all'argomento, però credo che ci sia proprio un mondo tra i servizi che sono...io li chiamerei model as a service cioè c'è qualcuno che lavora il modello, fa le sue robe e poi ti dice ok tieni guarda c'è una bella API per la entity detection, ce l'hai bella pronto, non ti devi preoccupare di niente Oltre a quello c'è il momento N+1, quando tu ti devi andare a realizzare il modello.Pensi che abbia senso immaginare o utilizzare dei sistemi di generazione modelli as a service? Allora, domanda pertinente, domanda super attuale.Allora, hai mai sentito parlare di AutoML, quindi Auto Machine Learning, quindi tutti quei servizi che vanno a creare dei modelli automaticamente? No, mai sentito parlare.Ecco, questa è diciamo la risposta alla tua domanda fondamentale.Cosa succede quando i modelli black box o comunque quei servizi che promettono di risolvere un problema, quel problema non me lo risolvono.Per esempio, hai nominato "Named Entity Recognition", "Sentiment Analysis", quindi ho una review, voglio capire se questa review è positiva o negativa.Supponiamo che gli off the shelf tools, quindi l'API di recognition di Amazon l'API di Google non funzionano con i requisiti stringenti del tuo cliente.Io developer che faccio? Beh, ho tre opzioni.O aggetto la spugna, o chiedo aiuto a qualche Data Scientist esperto, oppure sperimento con questi nuovi tool di AutoML.Che cosa vuol dire? Cosa significa "Auto Machine Learning".Significa che il servizio ti mette a disposizione uno strumento per addestrare un tuo modello in maniera molto molto semplice.Ovviamente hai bisogno di tre ingredienti, diciamo, un po' come cucinare.A me piace tanto cucinare in italiana e il machine learning in in realtà è esattamente come fare da mangiare.Tu hai bisogno di tre ingredienti.Il primo, il dato.Ritorniamo all'esempio della review.Ovvio che io non posso adestrare un modello con una review singola, ma ne avrò bisogno di un centinaio.Quindi questo è il primo ingrediente, il dato grezzo.Il secondo ingrediente qual è? Beh, quello che in inglese si chiama la la label, quindi l'etichetta.Questi 100 esempi sono positivi, sono negativi.Ok? E poi il terzo ingrediente è la metrica.Che cosa voglio ottimizzare? Che cosa voglio migliorare? Per esempio l'accuracy nella stima del sentimento.Con questi tre ingredienti tu vai dentro questo tool di AutoML e ti addestri al tuo modello, come dire, bespoke, quindi il tuo modello che in teoria funzionerà meglio dei modelli generici, perché è un po' come quando vai in farmacia, quando prendi un farmaco generico versus il farmaco specifico per la tua malattia.Funziona molto meglio.Interessante, ti dico la verità, è la prima volta che sento, io vabbè non essendo un esperto del dominio, credo sia anche abbastanza normale, ma è la prima volta che sento, cioè la cosa più vicina a quello che stai dicendo, che ho visto, è la funzione per generare l'entity recognition su Amazon dove puoi definire le tue parole, il tuo dizionario, se non ricordo male però non l'ho mai provato, anche perché in realtà esiste una distinzione importante tra figure quando si parla di Machine Learning Engineer, non si parla di sviluppatore, cioè è un altro lavoro.Quali sono secondo te, a livello proprio di lavoro, le differenze tra queste due figure e se esistono dei punti di contatto? Certo.Allora, in realtà, come dire, sono delle figure ben distinte.Io nella mia società ho dei developers che fanno, che si occupano di deployment, di modelli machine learning e ho dei machine learning engineers.Queste due figure professionali si parlano, collaborano, però hanno formazioni completamente diverse, background diversi e soprattutto hanno delle mansioni diverse, delle guidelines, anche dal punto di vista del codice, delle pratiche, operano con due handbooks completamente diversi.Ti faccio un esempio.Un machine learning engineer, io lo dico sempre ai miei, quando voi dovete fare del codice per testare delle nuove features per adestrare i modelli, non spendete troppo tempo nello scrivere un codice modulare, un codice ben scritto.Perché anche tu da buon developer sai che comunque la qualità ha comunque un costo, cioè non arriva gratis.Cosa succede in machine learning? Molte volte nel machine learning il debugging è impossibile.Ed è impossibile perché è talmente complesso talmente hyperparametrizzato il codice che talvolta se c'è un problema si butta via tutto e si ricomincia da capo.E da qui l'esigenza di utilizzare dei notebook, l'esigenza di utilizzare dei Jupyter.Quindi è proprio un mindset diverso, cioè se un developer io lo metto a fare del machine learning, questo developer mi si incastra in un codice assolutamente non modulare, molto complesso, ingestibile e viceversa.Un machine learning engineer lo mette a fare del deployment, mi scrive del codice, come dire, se non è proprio una persona rigorosa, mi scrive del codice grezzo, mi scrive del codice di qualità bassa.Non so se mi spiego.Forse dovrei renderlo con un esempio un po' più calzante.Chiunque abbia visto un Jupyter notebook ha visto un po' come i data scientist scrivono il codice.Io ho avuto modo di vederne un po'.Ci ho capito poco, però in realtà mi sono reso conto proprio dell'approccio completamente diverso allo sviluppo del software.E una domanda mi viene immediatamente conseguente.Esiste il TDD per quel tipo di codice? Scusami l'ignoranza TDD è? La parte di testing.Dei test automatici, delle suite di test automatiche.La risposta è un grosso no.Allora, il test in realtà non lo si fa automaticamente perché lo fa il data scientist.Se tu sei un buon data scientist, un buon machine learning engineer, lo si vede subito se il codice non funziona o funziona.Perché noi facciamo delle assunzioni, ok? Queste assunzioni vengono verificate immediatamente nel momento in cui fai girare l'esperimento.Ti faccio un esempio per chiarire.Innanzitutto noi, machine learning engineers, siamo, broadly speaking, non vorrei fare di tutto un nervo in fascia, ma in generale machine learning è un cell programmer.Che cosa vuol dire cell programmer? Nel senso che noi viviamo in una cella.Nel Jupyter Notebook tutto è modulare, tutto è cell based e noi riusciamo a guardare come il codice si comporta e quali sono le reazioni del codice, cella per cella o riga per riga.Non so se la tua audience e tu stesso sei familiare con Pandas, per esempio? Sì, c'è un gatto, mia moglie ha chiamato il suo gatto Pandas per ovvi motivi Python related.Ottimo.Allora, dentro un Pandas DataFrame, in sostanza tu riesci a vedere cosa succede al dato ad ogni riga, giusto? Quindi io del testing non ne ho bisogno, io guardo ad ogni riga cosa succede e decido ad ogni riga se c'è un bug oppure no.Ok, quindi hai un controllo più capillare, quasi a livello di...potrei accomunarlo al debugging, con i breakpoint, nel codice più in generale, con la differenza però che in realtà lo scope nel quale si lavora è decisamente più contenuto.Prima parlando, hai tirato fuori due figure.Hai parlato di data scientist e di machine learning engineer.Sono curiosissimo di capire la differenza in termini di ruoli, di cose da fare, di competenze e anche di percorso di studi se esiste.Assolutamente.Questa è una domanda che mi viene posta molto frequentemente perché c'è grossa confusione.C'è grossa confusione perché un machine learning engineer può essere può occuparsi di data science e un data scientist in realtà può anche fare del machine learning.Ok.Però non è proprio la stessa cosa e non è la stessa cosa perché lo stakeholder è diverso.Un data scientist tipicamente ha una relazione molto più intima, molto più stretta con le business units, cioè un data scientist deve informare delle decisioni di business con degli insights e, se è un buon data scientist che è esperto del business con cui lavora, con delle raccomandazioni, cioè deve non solo dire che cosa succede su un dataset, ma deve anche capire il perché questo fenomeno ha luogo, quindi capire qual è l'insight e poi qual è la raccomandazione, cosa deve fare la business unit o lo stakeholder per andare verso quell'obiettivo di business che il data scientist deve sempre avere in testa come faro.Ok, illuminante.Ti faccio un esempio.supponiamo che io lavoro con un'azienda di fintech o con una banca e supponiamo che questa banca abbia l'obiettivo di business di incrementare o di ridurre il churn.Allora il data scientist deve trovare innanzitutto se nel database c'è un segnale di churn prepotente, in secondo luogo capire questo churn da dove viene e in terzo luogo suggerire un'azione per arginare il churn.Quindi questi tre step fondamentali.Il machine learning engineer tutti questi mal di testa non ce li ha perché il machine learning engineer cosa fa? Ti sviluppa un bel modello per la predizione del churn, te lo mette dentro un API and that's it.Non c'è nessuna ambizione diciamo di suggerire di business una raccomandazione al business ok quindi se vuoi un machine learning ingegnere non deve neanche parlare non deve neanche comunicare lui comunica tramite la bontà del modello che a destra come si dice in inglese in behalf of the stakeholder quindi il suo stakeholder business.Quindi fondamentalmente possiamo immaginare un po' come il data analyst un po' l'esperto del dominio e il machine learning engineer un po' più legato al codice, all'attività pratica e e ingegneristica a livello proprio d'approccio, no? Assolutamente, assolutamente.E aggiungo che i background sono completamente diversi, nel senso che un machine learning engineer deve avere delle basi solidissime di appunto intelligenza artificiale, statistica, matematica, ok? E poi ci devono essere tutti i tips and tricks collegati proprio alla praticità delle varie fasi di una pipeline di machine learning, quindi addestramento, sviluppo delle feature eccetera.Ci sono mille cose da conoscere e mille cose che attualmente tutti quelli che fanno ML Ops tentano di introdurre in questi tool per appunto semplificare la vita, perché se no non confesso che è un bagno di sangue.Ecco hai aperto il vaso di Pandora della mia curiosità.Hai parlato di ML Ops, no? In realtà me lo sono sempre chiesto.Qual è il percorso che porta un Jupyter Notebook a diventare un API? Certo, ottima domanda.Allora, innanzitutto ci deve essere un problema, ok? Dietro a quel Jupyter Notebook.E questo problema deve essere un problema che ha una soluzione dal punto di vista del machine learning, ok? Una volta che, diciamo, il problema è definito, la soluzione è più o meno trovata, alla fine della fiera hai un modello, diciamo, serializzato che lo puoi utilizzare in una fase di produzione o un ambiente di produzione.Quindi, una volta che il tuo modello è addestrato o meglio serializzato, deve essere introdotto dentro la fase di deployment o in un API o dentro un'applicazione standalone.Quindi, se tu pensi al Jupyter Notebook, il Jupyter notebook è semplicemente un'interfaccia che ti permette di arrivare a quel binary file fondamentale che è il modello addestrato.Poi, il Jupyter notebook, l'80% del Jupyter notebook lo buttiamo via, teniamo il 20% che serve nella cosiddetta fase di inferenza, cioè in produzione, quando ti arrivano i nuovi dati grezzi da classificare, quel 20% ti serve per caricare il modello, darlo, perdon, caricare il dato, darlo al modello e tirare fuori l'output del modello.Esempio, avevamo detto prima, avevamo fatto prima l'esempio della review da classificare in relazione alla sua polarità negativa o positiva.Supponiamo che abbiamo un Jupyter Notebook che è a destra a questo modello su dei dati proprietari.Tiriamo fuori il modello che potrebbe essere un pickle file, per gli amanti di Python.Questo pickle file è un binario, questo binario verrà caricato su un'API appropriata e questa API andrà a prendersi le review nuove, quelle che ci arrivano nuove dal cliente, e le tradurrà in un qualche formato che il modello capisce.Una volta che il modello ottiene questo dato convertito riesce a interpretarlo e tirare fuori una risposta positiva o negativa.La polarità.Adesso il racconto di questo percorso mi ha stimolato altre due domande.Sono super curioso.ti ammazzerò di domande oggi.No, però mi chiedo, intanto, da come l'ho raccontato, le API sono una sorta di shell dove vado a posizionare il mio modello in modo che ci possa interagire, che possa fare queste domande a questo oracolo che ha imparato e lui possa in qualche modo rispondermi.Ma esistono dei sistemi di scelta abeliche pronti, dei servizi, oppure tutto quel lavoro a corredo lo si costruisce in funzione del modello stesso? Quindi questo adattatore doveva incastrare il modello? Non so se sono riuscito a… Assolutamente, è chiarissimo.Allora, purtroppo, nella mia società Spark, tipo l'anno scorso, avevamo fatto il deployment di 15 API diverse e ahimè, nella maggior parte dei casi si rifà tutto da capo.Cioè ci sono comunque delle cose che si possono riutilizzare across clients, però nella maggior parte dei casi è del lavoro che, diciamo, è un overhead più o meno costante.Perché? Ti faccio un esempio.Supponiamo che io ho un cliente che vuole un modello per classificazione di video.Ok? Beh, l'API deve essere un API che si prende l'ingresso dei video.Mica semplice.Perché un video può essere magari un giga, può essere 300 mega può essere 10 giga.Ok.Andiamo su un altro cliente, un altro cliente che invece prende, vuole un API per le review.Allora parliamo di dati testuali, un input è un testo di 600 caratteri.Benissimo, mi posso implementare una lambda su Amazon web service.Supponiamo che adesso un altro cliente, un cliente che ha dei clip audio, allora l'input cambia ancora, quindi cosa facciamo? Abbiamo dei requirements super variabili.È molto difficile avere una soluzione che, diciamo, sia, come dire, configurabile sulla base del cliente in maniera orizzontale.Certo è che se tu modularizzi il tuo codice e hai toolkit che ti permette di creare questa API in maniera veloce e il lavoro ti si semplifica.Chiaro, è stato super chiarissimo.A questo punto ti faccio la seconda domanda figlia proprio del ragionamento che facevi prima.Hai detto io faccio il training del mio modello e poi lo deploio e quindi metto a disposizione del business o di altre unit di sviluppo quel servizio.La mia domanda è con questo approccio il modello è il modello al t0.Ok.Sì.Però nel frattempo i dati si accumulano.Le cose succedono.Io dovrò poi ritrainare il modello nel t1.Rideployarlo e così via.Esistono, non lo so, dei sistemi di, la butto là, continuous learning, no? O automatizzare il processo di generazione del modello affinché sembri quasi, non dico aggiornato in tempo reale, però comunque segua l'evolversi del tempo in modo completamente automatico? oppure c'è bisogno sempre di un data scientist che deve rianalizzare la situazione, vedere se i presupposti sono cambiati, creare il nuovo modello da trenare, trenarlo e così via? Allora, domanda molto pertinente, qui andiamo già comunque su delle architetture di tipo avanzato e la risposta è sì, assolutamente.Continual learning è un approccio che ha i suoi vantaggi ci sono anche gli svantaggi.Prima però do la buona notizia.La buona notizia è che se per esempio utilizzate soluzioni cloud come per esempio Amazon, noi siamo dei fan, non lo nascondo, però anche Google Cloud penso abbia l'equivalente, il continual learning, le pipeline di continual learning sono relativamente semplici da implementare.Che cosa vuol dire continual learning? vuol dire che noi ritorniamo all'esempio delle review, abbiamo adestrato il modello, abbiamo fatto il deployment del modello, il modello è in deployment e tutti i giorni riceve mille, diecimila, centomila review da classificare.Cosa succede? Che alcune di queste 100.000 review saranno riviste da qualche utente, saranno utilizzate nell'applicazione immagino.Quindi avremo la possibilità di capire se questi 100.000 scorro, queste 100.000 risposte che abbiamo ricevuto dal modello sono corrette o non sono corrette.Il concetto del continual learning è il seguente.Visto che noi abbiamo nuovi dati passati dentro il modello e potenzialmente validati da un umano, ok, perché non andare a utilizzare questi nuovi labels, oppure questi nuovi dati validati per riaddestrare il modello ogni giorno, ogni settimana, ogni mese? Allora, c'è un grosso vantaggio se facciamo questa Noi sappiamo che la teoria del machine learning ci dice più dati annotati o più dati utilizziamo nella fase di training e più le performance aumentano.Quindi questo continual learning sulla carta sarebbe fenomenale, Carlo Mauro, giusto? Perché noi più utilizziamo le nostre API e più queste API migliorano, più generano valore per i nostri clienti.Quindi, fenomenale, io faccio il continual learning e guadagno sempre di più.Ci sono due grossi ma.Il primo è, diciamo, the sad part of the story, che come in tutte le storie troppo belle, c'è un limite superiore.Quindi non potranno le performance crescere all'infinito.Crescono fino a un certo punto e poi asintoticamente vanno a stabilizzarsi.Numero 2, questo è molto più preoccupante, specialmente se lavorate ancora una volta con delle banche, con delle assicurazioni, c'è il cosiddetto model drift.Cosa succede? Succede che, supponiamo che prendiamo un esempio un po' più cattivo, ok? Supponiamo che invece di andare a fare del sentiment analysis sulle review andate a fare dello score, del credit scoring su delle persone che richiedono il mutuo della casa.E lì sono grossi problemi perché c'è comunque l'antitrust che impone o comunque i regulators che impongono alla banca delle regole molto stringenti.Gli dicono "guarda, tu non devi discriminare basandoti sul gender, basandoti sulla locazione fisica della persona, basandoti su alcuni attributi demografici.Cosa potrebbe succedere col continual learning? Allora, caro Mauro, tu hai stato il modello, hai dimostrato al tuo cliente della banca che funziona, che non discrimina, eccetera.Ok? Poi clicchi sul bottone continual learning di Amazon, te ne vai in vacanza e dopo tre settimane scopri che il modello incomincia a dire che tutti quelli che abitano a Novi Ligure hanno uno credit scoring che è 30% più basso della media.Il banchiere ti chiama e ti dice "Mauro, ma cosa sta succedendo? Qui abbiamo sette avvocati alla porta che bussano e che vogliono farci chiudere bottega.E tu che gli vai a spiegare che col continual learning bisogna stare molto attenti a questo fenomeno che appunto dipende da, come dire, fenomeni di distribuzione variabile dei dati d'ingresso.Quindi se la distribuzione dei tuoi dati cambia nel tempo, il tuo modello cambierà di behavior, cambierà il modo in cui si esprime su quella popolazione di distribuzione diversa.Allora qui sto andando un po' troppo forse nel tecnico dammi qualche punto di riferimento aiutami a capire se questo è chiaro.Io credo che da questo momento in poi mi perdono nel senso che capisco che il modello al cambiare dei dati di input o all'evolversi dei dati input possa comportarsi diversamente.La domanda che però mi chiedo è sì vabbè ma a quel punto se io continuo a utilizzare sempre il modello alti zero e quel modello non è più aderente alla realtà quindi comunque avrei un contro problema giusto allora sì sapendo che ci sono comunque delle proprietà di quel modello che ti garantiscono che l'uscita o comunque l'output del modello sia rispetto ai determinati parametri o determinati guidelines che tu hai validato dal punto di vista statistico.Ancora una volta qui entriamo un po' più nel tecnico, però l'idea del continual learning è fenomenale, però bisogna comunque gestirla nella maniera giusta, perché c'è questo fenomeno del drift da controllare, limitare e correggere soprattutto.E qui entriamo nell'ultima fase appunto del, diciamo, del life cycle di sviluppo machine learning che è quello della maintenance.Cosa vuol dire? Tutto quello che è post deployment rientra nella sfera di quality control, drift analysis, drift correction.Quindi qua se all'ascolto c'è qualcuno che vuole farsi una nuova startup, quest'ultima fase del processo, del life cycle, è ancora, come dire, relativamente poco battuto.questa è interessante naturalmente fuori dalla mia portata quindi ammetto i limiti riavviciniamoci un po al mondo dei full stack developer la cosa mi interessa e da te mi interessa capire ad oggi quali sono gli as a service che hai visto più interessanti che si possono avvicinare al mondo di chi lavora sul web, chi fa delle web application in genere? Allora, dipende da quale feature selezioniamo come criterio di giudizio.Se per esempio uno avesse come criterio di giudizio la semplicità d'uso, ok? Ormai, come dire, tutto quello che Amazon recognition, parlo di visione, parlo di test, eccetera, Google Vision API, tutte le API appunto di Google, Amazon, Data Robot, sono di facilissima integrazione.Quando parliamo di feature avanzate ci sono delle start up come per esempio Clarify o tutti quei tool di AutoML che ti danno la possibilità di sviluppare dei modelli bespoke.Se noi parliamo invece di persone, full stack developers che vogliono sporcarsi le mani e utilizzare o addestrare dei modelli per conto loro, ci sono anche su Amazon SageMaker, che non so se tu conosci, ci sono dei notebook già fatti o dei modelli preaddestrati che si possono utilizzare direttamente dentro notebook.Chiaro? Ah, chiaro.Io, sai, guardandomi attorno, la prima cosa che ti viene in mente è, insomma, che ne sono nelle login, andare a implementare degli specchi, dei semplici algoritmi di anomaly detection.Però così, prima di questa chiacchierata, mi guardavo attorno ho visto un articolo uscito da relativamente poco quest'anno dell'MIT che parlava, penso di averlo trovato tra i tuoi tweet, di algoritmi capaci di ripulire delle data tables o riordinare delle data tables.E' un po'...non ti nascondo che l'ho visto quasi come un inception, no? Cioè, il presupposto per far funzionare questo tipo di algoritmi è quello di avere dei dati il più affidabili possibile, no? E contestualmente li usi per rendere questi dati puliti e quindi affidabili.Come vedi questa funzionalità? Vedi anche tu il loop o sono solo io un po' scemo? No, assolutamente.Data cleaning, da un punto di vista proprio di data analysis, noi abbiamo fatto tanta data analysis negli early days della nostra attività emperioritariale, Il problema del data cleaning è un problema veramente spinoso ed è mischiato anche a un secondo problema che è legato al data interpretation, nel senso che quando uno pulisce il dato non solo fa quest'operazione appunto di strutturazione, di riformattazione e di pulitura, fa anche un secondo step di analisi del dato, di interpretazione del dato.Quindi delegare, sono d'accordo con te, delegare questo task a un algoritmo, a i pro e contro.Quindi l'argomento è spinoso.Ok, quindi ho beccato proprio il punto.L'altra domanda che ti volevo fare, sempre riguardo applicazioni pratiche è una domanda che probabilmente è stupida però secondo me neanche tanto questi giorni ci sono gli accessibility day del web un argomento che mi sta molto a cuore oggi abbiamo una serie di tool che ci permettono di verificare se il nostro sito è accessibile.Dall'altra parte il mondo dell'industria sta sviluppando attraverso il machine learning, e anche questo mi pare di averlo visto dal tuo profilo twitter, degli strumenti sempre più potenti di defect detection, quindi di riconoscimento del difetto.Secondo te ha senso immaginare un domani l'utilizzo di algoritmi di machine learning, e specie di computer vision, proprio in un'ottica di andare a vedere un po' oltre quello che gli attuali strumenti di verifica di accessibilità fanno? Allora assolutamente e questo è un dominio di ricerca, ancora un dominio di ricerca innanzitutto, quindi non ci siamo ancora dal punto di vista applicativo.Secondo me questo è un problema di ricerca interessantissimo.Noi abbiamo lavorato con una università, non mi ricordo più dove, negli Stati Uniti recentemente, che andava a classificare le interfacce su applicazioni mobile.Quindi andavamo col Computer Vision a analizzare come le interfacce venivano disegnate e lo avevamo fatto per un database di migliaia di applicazioni.Quindi assolutamente sì, è assolutamente un problema aperto nello stato dell'arte, però siamo ancora nel dominio della ricerca, più che nella ricerca e sviluppo.Quindi comunque non esistono dei prodotti.Perché mi sembra comunque super interessante e anche dal grande valore etico.Tra l'altro questo tipo di conoscenza.Assolutamente.Tieni conto, io non so se tu hai mai sentito parlare di GPT-3, di OpenAI e di tutto quel filone interessantissimo di generative machine learning e generative deep learning che può essere in realtà utilizzato per guidare il disegno di prodotti, di nuovi prodotti.Esempio, supponiamo che io sia uno UX designer o comunque qualcuno che si occupa di disegnare interfacce grafiche.Io posso avere un algoritmo che mi suggerisce, che mi dà dei suggerimenti interattivi quando vado a sviluppare la mia interfaccia per un'iOS app e mi dice "guarda, il bottone messo lì non va bene, mettilo 10 pixel più a destra perché è lì dove in generale l'attenzione dell'utilizzatore si concentra nei momenti in cui fa il task x y z.Chiaro e quando parliamo di UX il passo immediatamente successivo è quello del del developer.Quindi voglio portarti a una domanda, una cosa che mi chiedo da un po'.Con i ragazzi del gruppo abbiamo ormai appurato e condiviso un po' l'esperienza e ci siamo resi conto che buona parte della nostra attività è di lettura e scrittura dei dati, da qualche parte.Il 90% del nostro lavoro è quello, il restante 10% è scrivere delle funzionalità legate al al dominio ma adesso magari le percentuali non sono precisissime però credetemi io faccio una marea di crude e di logica di dominio la quantità è veramente un infinitesimo e visto che il crude è un'azione ripetitiva e dall'altra parte abbiamo una knowledge condivisa enorme, parlo di github, di gitlab, di tutto l'open source secondo te un domani proprio in un'ottica di machine learning generativo quindi di capacità di generare del contenuto quindi anche del codice possiamo auspicare a degli strumenti che prendono del pseudo codice e ce lo trasformano in software perché ad oggi quello che ho visto sono strumenti che ne so come c'è un plugin che io ho installato viso studio con tab 9 forse che fa un suggerimento basato sul sul machine learning del codice ecco ma riusciamo a immaginare dei tool che invece prendono pseudo codice lo trasformano un codice di un linguaggio piuttosto che un altro? E' a senso? È una domanda affascinante e io temo di non avere una risposta, forse perché, come dire, una risposta univoca non c'è o forse perché non sono qualificato abbastanza per rispondere.Se vuoi ti do la mia reazione di pancia.Da umano io ritengo che questo non succederà nel breve termine per due motivi.Il primo, riflettiamoci insieme forse, i linguaggi di programmazione sono stati sviluppati da umani per umani, giusto? Concordo al 110%.E invece un algoritmo di machine learning, come dire, non parla Python, non parla Visual Basic o Fortran, capisce… come dire, ha un altro tipo di struttura proprio, un altro tipo di mental model, se vuoi.Quindi è un po' come dire, è un po' il giro del loca.Io mi immagino un futuro in cui non passiamo più per i linguaggi di programmazione legacy, non so se mi spiego.Sono assolutamente convinto che il generative machine learning creerà delle tecnologie in maniera indipendente e in maniera generativa, ma non ritengo che questo percorso vada nella direzione dei linguaggi che gli umani utilizzano oggi.Credo che in realtà per arrivare a quel punto, dimmi se dico una capellata, l'uomo debba spogliarsi dell'innato inspection need, cioè la necessità di capire cosa sta succedendo sotto il cofano.Perché di per sé il machine learning non ha il controllo degli step interni, se mi correggimi se sbaglio, hai la visuale sull'ingresso e sull'uscita.E quando io ti dico la fase generativa sul codice è perché il mio bias, penso che sia un bias legato al fatto che sono un umano e vivo, è quello di capire cosa fa.Quindi la ricerca continua di cercare del controllo.Mi viene anche difficile da esprimere come concetto.Allora ti porto un altro esempio, un esempio che secondo me è più realistico.No code.Allora, io non so cosa i developer pensano di questo nuovo approccio, dell'approccio no code.Io posso portarti la mia esperienza.Il no code è fantastico fino a quando qualcosa si rompe o fino a quando non funziona come doveva.Supponiamo che ci sia nel futuro la possibilità di usare NoCode, e quindi parlo di tool come Zapier, come Automate.io, come Trey.Supponiamo di avere un futuro, un versioning di questi tool.Quindi supponiamo di avere la possibilità di integrarli, di debuggarli e di, come dire, li deploiati su tutti i servizi possibili e immaginabili.Ora, non ho idea di quanti utenti abbia Zapier, supponiamo che ne abbia 100.000-200.000, supponiamo che ognuno di questi utenti abbia creato in maniera indipendente almeno 10-15 flows, o le chiamano Zaps, ok? Ciò vuol dire che Zapier, come società, ha milioni di esempi, milioni di flow creati da umani.Quindi io mi aspetto che tra 4-5 anni Zapier utilizzerà questa incredibile database di intelligenza umana che è stata riversata dentro questo no code, di questi flow di no code per addestrare un machine learning che crea prodotti o crea delle features in maniera indipendente.Quello me lo immagino fatto tra due o tre anni, tre, quattro, cinque anni.Mi immagino molto di più un futuro di questo tipo che un futuro in cui, come dire, il machine generale codice python.Chiarissimo chiarissimo anche questa settimana abbiamo due amici che hanno voluto supportarci in questo esperimento di github.Infatti ci stanno donando le birre Matteo Manchi e Thorsen.Matteo ha scritto questo mese anziché comprare un libriotech la formazione passa tramite github ed è d'obbligo una birra per Mauro e per ogni ammuttinato quindi noi brindiamo alla salute di Matteo a seguire abbiamo anche Thorsen che ci invita a quattro birre e ci scrive grazie per alimentare la mia sindrome dell'impostore più seriamente grazie per la passione che ci mettete tanta stima grazie anche a te Thorsen Quindi con tantissime birre questa settimana noi brindiamo tutti insieme alla salute di Thorsen e alla salute di Matteo.Oggi ci sono dei prodotti web ma sempre di più comunque il mondo mobile è diventato centrale tanto che entità come Apple come Google hanno integrato nei loro device mobile con degli oggettivi limiti fisici cioè la capacità computazionale di un telefono per quanto potente ha dei limiti fisici la batteria temperatura e hanno introdotto questi kit per l'utilizzo del machine learning con praticamente qualcosa che si approssima allo zero effort da parte dello sviluppatore che ne so penso a core os di apple o a ml kit di google cioè è una chiamata API e ce l'è là pronta a disposizione e mi chiedo che differenza c'è tra l'utilizzo di questi servizi se esiste una differenza di questi di queste funzionalità l'utilizzo di servizi cloud nel machine learning? Allora diciamo che machine learning ha dei requisiti completamente diversi rispetto al machine learning core of the cloud.Ovviamente le limitazioni sono...le limitazioni e le opportunità sono imposti dal device ma sono imposte anche dall'interazione con l'utente.Ti faccio un esempio di un'applicazione che misura per esempio che vuole misurare le scarpe di un bambino.Allora, questa applicazione è una applicazione mobile che utilizza la telecamera e che per requisiti del caso d'uso deve muoversi in real time nell'intorno del piede che vuole misurare.Allora, se tu sviluppi un'applicazione di computer vision di questo tipo il tuo classificatore deve ricevere 30 frame, 24 frame al secondo.Non riuscirei mai a trasferire 24 frame al secondo sul cloud.Quindi magari ha più senso fare il deployment del tuo modello direttamente sul device.Ok? Però hai abbastanza capacità computazionale sul telefono, ci saranno dei problemi di compatibilità across devices, quindi è un problema completamente diverso e io ritengo molto più complicato rispetto al machine learning e computer vision a decor.Un altro mercato tra l'altro per chi vuole, come dire, farsi una nuova carriera nel machine learning.Anche qua c'è proprio un bivio, cloud versus edge.esatto domanda tanti tool per il machine learning sono open source ma quante soluzioni end to end esistono? mi viene in mente una, Prediction.io che sta sotto il cappello di Apacee dove esistono una serie di modelli già pronti da deployare tu gli dai impasto degli eventi, lancia un comando, lui ti genere il modello e poi risponde direttamente ai API.Che tu conosca, esistono delle cose come queste, insomma, cose che possono in qualche modo andare a sostituire i servizi minimi, anche di analisi del test, che però sono open source con dei modelli che puoi trainare, già legati quasi alla funzionalità? Sì, allora diciamo che il mercato è super fragmentato e un mercato fragmentato, come dire, aggrega comunque delle tecnologie che sono ancora molto grezze e molto staccate dagli use case che per esempio in data science sono già molto più consolidati.è difficilissimo trovare quel tipo di tecnologia, di quel tipo di pipeline end to end, almeno per il tipo di problemi che ho in testa io.Per esempio anomaly detection, cioè anomaly detection dipende moltissimo dal contesto.Siamo in un contesto manifatturiero, siamo in un contesto di sicurezza, questi use case cambiano radicalmente il modo in cui quel tipo di tecnologia machine learning viene deployata, quindi è proprio difficile andare a sviluppare, andare a puntarti verso delle pipeline, come dire, utilizzabili.Avrei altre 70.000 domande, ma abbiamo già fatto un'oretta, quindi lentamente ci avviamo in conclusione e ci avviamo in conclusione con una domanda in realtà che sono sicuro che buona parte dei membri della community si chiedono e soprattutto spoiler al prossimo episodio di Gitbar.Quando si parla di Machine Learning si parla tantissimo di Python.Vuoi perché un linguaggio abbastanza semplice, vuoi perché esistono le migliori librerie o tra le migliori librerie per poterlo fare.Però dall'altro canto se io vado a guardare un po' quello che si dice di Python e ripeto questo è uno spoiler per il prossimo episodio, Python è lento.Ok? Adesso avrò fatto inferocire tantissimi però in realtà è una cosa che si vede spesso no? Ma se il machine learning è diciamo un ambito che presuppone grande prestanza computazionale come si sposa col concetto che python sia lento? Una parola, convenience.E convenience vuol dire che il machine learning è già una bestia così complicata che è conveniente utilizzarla nel linguaggio di programmazione relativamente semplice, pagando un prezzo che è il prezzo, come dire, della lentezza intrinseca.Ci sono delle soluzioni e secondo me ce ne saranno ancora di più nel futuro.Per i non amanti di Python, utilizzate Julia.Ok, questo è stato didascalico proprio.No, però in realtà, per esempio io leggevo che comunque sotto Python ci sono delle librerie C per molti framework che fanno il lavoro sporco.Certo, tutto in Cython, tutto quello che è TensorFlow di bassissimo livello.Io non sono un esperto del basso livello, però PyTorch, tutte le operazioni di ultra basso livello, io immagino, sono implementate in Cyton ad alta efficienza.Poi, come dire, tutto quello che è in fase di training noi lo facciamo girare su delle GPU eccetera.Nessuno si è mai posto il problema di andare veramente a ottimizzare, a esprimere al massimo, perché, come dire, per il momento è brut force.Ok, è tutto brute force.Però anche lì c'è un altro, diciamo, un'altra ventina di startup che nasceranno nel prossimo quinquennio.Adesso lasciamo per un attimo, anche se parzialmente, il mondo del machine learning.Io voglio tornare però a Spark.Perché tu mi hai detto "in questo periodo di pandemia volevamo fare qualcosa di diverso, qualcosa di per noi importante e abbiamo fatto nascere Spark".Quindi la mia domanda è cosa fate, ma soprattutto qual è stato il propulsore che vi ha detto "sì, andiamo a creare questa nuova società e lo facciamo in questo modo? Beh, allora sicuramente facciamo un fast forward, anzi torniamo indietro di un anno, marzo 2020, piena pandemia, noi siamo qua a Dublino, leggiamo sconcertati quello che accade in Italia e sentiamo i nostri amici e ci poniamo una domanda.fare per il nostro paese.E tenete conto che il 13 di marzo dell'anno scorso, metà marzo dell'anno scorso, tutto il mondo pensava che quello che fosse successo in Italia non era replicabile negli Stati Uniti, in Irlanda, nel UK.Boris Johnson che va negli ospedali inglesi stringendo mani a destra manca.Quindi c'era questa grande paura per l'Italia e soprattutto c'era la voglia di fare qualcosa per il nostro paese.Quindi siamo andati in Italia e abbiamo detto "Ok, andiamo a trovare i talenti italiani, anche se siamo all'estero, proviamo innanzitutto andare a trovare i talenti in Italia che ci sono".Ed è stato il nostro modo per aiutare l'Italia in un momento difficile.E questo è stato, come dire, il punto di partenza.E da lì poi, come dire, Spark ha avuto una crescita abbastanza esponenziale, nel senso che abbiamo trovato una massa critica in Italia, abbiamo trovato un sacco di persone in gamba che alcune sono ancora con noi oggi e soprattutto l'idea di Spark è stata quella di prendere un need, un bisogno del mercato, che è quello di soluzioni bespoke, soluzioni su misura, soluzioni che funzionano su problemi difficili e portarle su delle realtà di dimensione media.Quindi parliamo di piccole e medie imprese sotto i 200 dipendenti che non hanno ovviamente non hanno neanche forse l'esigenza di portarsi o di crearsi un team di machine learning engineers in casa, ma hanno l'ambizione, ok? Hanno l'ambizione di rimbalzare fuori da questa pandemia con un nuovo prodotto, delle nuove features o delle nuove soluzioni e l'AI e il machine learning, come tu ben sai, è il propulsore di questa innovazione.Cioè quando c'è innovazione del software, dal mio punto di vista, ci deve essere per forza una componente di AI o una componente legata al dato.Noi aiutiamo in questa missione fondamentale.Che bello.È interessante il riguardare l'Italia.Che differenza hai trovato nell'approccio al lavoro a livello internazionale? che ne so, tu oggi sei in Irlanda, quindi là, che ne so, in Irlanda piuttosto che l'Italia.Ma diciamo che ti sorprenderò, però dal punto di vista dell'etica del lavoro, dal punto di vista della serietà, da tutti i punti di vista, io non vedo delle grosse differenze.Forse sono stato fortunato perché ho sempre avuto dei collaboratori che sono di altissimo livello, di altissimo valore, però non vedo sta gran differenza.Anzi, io vedo gli italiani di una serietà e di una competenza, soprattutto incredibile.E soprattutto i giovani.Io mi sono sorpreso perché adesso noi assumiamo praticamente solo Machine Learning Engineers in Italia.E li portiamo qua in in Irlanda tra l'altro.Ne ho già due che sono venuti qua in Irlanda, da Milano.Saranno in realtà.Ti faccio una domanda.Ad oggi quanti clienti italiani hai? E soprattutto è interessante il tuo approccio perché dici noi lavoriamo per le medie imprese, la piccola media industria.E l'Italia, almeno il nord Italia, è una delle aree dove la piccola media industria regna sovrana.Non dimentichiamo che l'Italia è comunque importante per la piccola e media industria.Poi pandemia a parte.Però dico come mercato, come lo vedi e soprattutto le imprese stanno innovando in quella direzione? Allora domanda per clienti, domanda interessantissima, potremmo starci a parlare per un'altra mezz'ora.Non dimentichiamoci che l'Italia ha un ecosistema di piccole e medie imprese che è incredibilmente ricco di realtà con mille sfaccettature diverse e noi parliamo di un bacino che va grandi linee dalla Pelura Padana fino forse in Toscana e che ha delle realtà incredibili di altissimo livello internazionale.Quindi il mercato è interessantissimo, è anche un mercato difficilissimo per tre motivi.Il primo, frammentato.Il secondo, sono realtà piccole e quindi c'è un task supplementare che dal mio punto di vista è un task di educazione, di introduzione alle AI e machine learning che non è per niente banale.Però l'ambizione nostra è quella di fare tre cose, non solo sviluppare soluzioni su misura, ma numero due, fornire del supporto end to end, quindi dal sensore al deployment, e numero tre c'è il training che è fondamentale, nel senso che noi andiamo in una piccola e media impresa e portiamo una nuova tecnologia, ma anche forniamo le persone che hanno all'interno di quella realtà, dal CEO che, come dire, ha la responsabilità di business, ha la responsabilità di monetizzare la tecnologia, al data scientist che magari ha la responsabilità di occuparsi, come dicevamo prima, del model drifting.Lo sviluppo della consapevolezza distribuita all'interno di tutta la struttura aziendale che è, diciamo, la cosa forse più onerosa in termini di sacrificio ad oggi perché lo sviluppo tecnico, se non sono tre, ti metti cinque ingegneri, per quanto la produttività non segue esattamente il numero degli ingegneri però in un modo o nell'altro la soluzione la trovi.Da lì a sviluppare la consapevolezza hai l'elemento uomo che fa la differenza e quando tu entri in un'azienda parli col CEO e gli dici come queste nuove tecnologie possono migliorare il loro processo e lui dice "sì ma aspetta, respiriamo, cioè tu stai venendo a insegnare a me come si fa il mio lavoro".Quindi spesso questo accade nelle piccole medie realtà, cosa che già l'industria per altre dinamiche è diversa.Mi permetti un ulteriore commento? Questo tipo di risposte, tipo di reazioni in realtà si ottengono soprattutto su dei progetti, su delle commesse di data science, perché c'è appunto questa ambizione di data science di raccomandare e di tirare fuori degli insight.Dal punto di vista machine learning è un po' più semplice, perché alla fine dei conti addirittura ci sono...cioè la monetizzazione di tecnologie AI è chiara ed evidente, è semplice, cioè tu hai...sei un'azienda manifatturiera, hai un rate, anzi, hai un processo di controllo qualità manuale, quindi c'hai tre persone che lavorano controllo di qualità che si guardano un pezzo alla volta 24 ore su 24, io su quelle tre persone riesco a, come dire, liberartene due e quindi queste due persone possono essere relocate su un altro task a più alto valore giunto e lì la monetizzazione è chiara, ok? Su dei task di data science è più difficile.Caspita.Io credo di aver esaudito buona parte delle mie domande, le altre troppo banali, quindi le terrò per me.Esiste un momento tipico e topico del nostro podcast che noi chiamiamo il Paese dei Balocchi.È un momento dove i nostri ospiti che bevono la birra con noi portano qualcosa che loro reputano importante e condividere, che sia un libro, un video di una conferenza, un giocattolo, può essere, che ne so, dalla tastiera al testo che ti ha cambiato la vita, qualcosa del genere insomma.Hai qualcosa da condividere con noi? - Riconduco nel paese dei balocchi.- Ah, il paese dei balocchi.Ho una frase che mi sono nel cervello tutte le mattine quando mi sveglio, che potrei portare.La frase dice, la dico in inglese, consentitemi poi la traduciamo, anche in italiano, "a life well spent is more than enough".Quindi una vita ben spesa è abbastanza.Io sono assolutamente consapevole che se vivi questa frase e dichieni questa frase ogni minuto della tua giornata, fa la differenza in lungo termine.[Musica] E quindi io vorrei riprendere la frase che ho detto all'inizio della puntata di Hawking che pubblicò su Le Monde nel 2014 dicendo "l'intelligenza artificiale potrà mettere fine all'umanità".Io credo che in realtà più che l'intelligenza artificiale che potrà mettere fine all'umanità è la deficienza umana che potrà mettere fine all'umanità, nel senso che se l'uomo è capace di essere consapevole degli strumenti che va a creare e a utilizzare, probabilmente l'umanità potrà sopravvivere a questa evoluzione.Se non è consapevole, beh, allora Hukin ha ragione.mi auguro che il driver di Hawking era il suo pessimismo cosmico, no? Io voglio essere un pochino più ottimista e con questo voglio comunque ringraziarti tantissimo Luca, grazie di cuore per aver condiviso un po' della tua esperienza e per in qualche modo averci fatto capire di più di questo mondo ricco di buzzword dove spesso diviene difficile quasi raschiare lo strato più esterno delle buzzword, dell'area più fancy e poi in realtà sotto quello esiste tutto un mondo che funziona, produce, genera e che è reale e spesso questo mondo si perde creando dei grossi danni anche all'evoluzione di questo stesso mondo e allo sviluppo della consapevolezza quindi grazie di cuore a nome mio e di tutti gli ascoltatori di Gitbar.Grazie Mauro.Gitbar il circolo dei full stack developer una volta settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.a presto.
