Popper, Datascience & Lego: “Tutta la vita è risolvere problemi”

Ho sempre amato Popper, uno dei più importante filosofi della scienza, sia per il celebre principio di falsificabilità che è alla base della distinzione tra scienze e pseudoscienze, sia per la critica all’induzionismo estremo. Sintetizzando questo concetto egli sostiene che non basta osservare ma bisogna sapere cosa osservare. In questo senso la deduzione, che si nutre anche dell’osservazione non passiva della realtà, svolge un ruolo fondamentale nella creazione di teorie scientifiche e nella risoluzione di problemi. Questo processo è stato reso particolarmente evidente in due recenti e mediatiche scoperte scientifiche quali quelle del bosone di Higgs e delle onde gravitazionali, in cui la deduzione (fisica teorica) è stata confermata dalla induzione (fisica sperimentale) a distanza di molto tempo. E in questi processi di verifica induttiva la datascience ha avuto un’importanza fondamentale visto che tecnologia, algoritmi e specialisti di analisi dati la fanno ormai da padroni in questi grandi esperimenti. Anche nei processi deduttivi l’osservazione dei dati, soprattutto se guidata da una conoscenza del contesto e del problema che si vuole risolvere, porta un supporto importante nella realizzazione di quegli schemi mentali creativi necessari alla definizione di ogni teoria scientifica falsificabile.
Ma la citazione di Popper nel titolo del post fa riferimento anche ad un aspetto specifico e critico nell’utilizzo della datascience e in particolare alla domanda, che mi capita sempre meno spesso di sentire, su quale sia il punto di partenza di qualsiasi progetto relativo ai dati e in particolare quelli per i quali “sprechiamo” l’attributo Big Data.
Non ho alcun dubbio nell’indicare che sia fondamentale partire da un problema implicito o esplicito (chiarirò più avanti il concetto) degli stakeholder del progetto: il Cliente nei progetti di business o i Decision maker e la Comunità stessa in progetti non commerciali.

Sicuramente estremamente errato è partire dalla infrastruttura tecnologica. Cito a questo proposito un bellissimo post “Put data Science before Data Infrastructure” di  David Johnston, datascientist di Thoughworks che evidenzia come una qualità fondamentale per ogni analisi dei dati è sapere cosa osservare e perchè osservarlo.

DataScience1

Certamente molte tecnologie “Big Data”, cito l’ecosistema Hadoop per esempio, sono abilitanti ma non bisogna dimenticare che sono solo un mezzo, una condizione in alcuni casi necessaria ma mai sufficiente al buon risultato finale.

Talvolta è certamente possibile partire dai dati, soprattutto quando una vera domanda da parte degli stakeholder non esiste o meglio è implicita perchè questi ultimi non sono in grado di identificarne l’esistenza. Sicuramente la crescita esponenziale della disponibilità di dati può aumentare queste situazioni ma come punto di partenza diventa molto rischioso soprattutto in ottica business per gli investimenti correlati a questi progetti che possono non trovare un mercato. Questa è la via intrapresa da Linkedin nei suoi primi anni di vita quando, trovatosi grandissime moli di dati relativi a professionisti di tutto il mondo, ha lasciato che i datascientist interni realizzassero prodotti basati sui dati (soprattutto in ambito soluzioni per Human Resources) che il marketing tradizionale e i potenziali Clienti non riuscivano neppure ad immaginare. Certamente quando si riescono a creare prodotti (risolvere problemi) vincenti in questo modo l’oceano blu che si apre nel mercato è veramente importante. Ma sono poche le aziende che, per cultura e per organizzazione, riescono a sfruttare queste situazioni.

In altri casi è possibile partire dagli algoritmi per capire se è possibile far emergere dai dati (anche i “soliti dati”) delle situazioni (pattern) che possano rispondere a problemi impliciti o espliciti di Clienti o di Decision maker. In questo celebre post il datascientist Brandon Roher prova ad incrociare domande/problemi generici ad algoritmi più o meno innovativi nel campo del machine learning. Partendo proprio dagli algoritmi il deep learning ha fornito convincenti risposte a problemi ancora irrisolti, per esempio nel riconoscimento di cose e persone nelle immagini . Ma anche in questo caso la strada verso risultati concreti è molto ardua e riservata ad un numero ancora limitato di datascientist-driven companies.

In questo senso la visione popperiana di mettere al centro il problema, applicato alla datascience, è sicuramente vincente. Come scrive Popper ” .. il metodo consiste nel proporre tentativi di soluzione del nostro problema, e nell’eliminare le soluzioni false come erronee. Questo metodo presuppone che noi lavoriamo con un gran numero di tentativi di soluzioni. Una soluzione dopo l’altra viene messa a prova ed eliminata.” E oggi questo metodo, figlio del galieiano metodo sceintifico, applicato alla Datascience trova nella tecnologia NoSQL, negli algoritmi “big data” e nei datascientist  un forte abilitatore nonchè un grande acceleratore.

In questa evoluzione conoscere il contesto in cui si muove il progetto/problema e definirlo al meglio rimane la parte più difficile. Oggi più di ieri perchè  su questo aspetto che tocca problematiche organizzative, culturali e sociali non abbiamo (soprattutto in Italia) fatto gli stessi passi avanti che siamo riusciti a realizzare negli altri aspetti, ahimè solo abilitanti (tecnologia, algoritmi, dati ecc.).

Sulla base delle considerazioni sopra descritte mi piace descrivere il flusso che coinvolge qualunque progetto di datascience in maniera modulare quasi fosse una costruzione “lego”. Sotto riporto una immagine che esemplifica questi concetti
LegoDataScience

Cercherò di fare alcune considerazioni in futuri post di ciascuno di questi livelli, di come si possano spesso compenetrare (soprattutto quelli centrali), di come lo spessore (l’importanza) di ciascuno di questi sia variabile funzione del progetto .
Vedremo anche come, a sua volta, questo pattern (ovvero singolo progetto), possa combinarsi con altri perchè spesso i due strati superiori (i problemi risolti e i relativi dati) costituiscono la base per altri progetti/programmi  più complessi o più complicati.
Credo che sia importante aver “fissato” (anche visualmente) la centralità della definzione del problema all’interno di qualunque progetto di datascience e quindi nell’ideale diagramma di Conway da cui siamo partito nel precedente post mi sento di sottolineare più che mai l’importanza del cerchio inferiore, cioè della conoscenza del contesto a 360°: dai dati agli stakeholder per essere in grado veramente  di “risolvere problemi tutta la vita”.

Popper, Datascience & Lego: “Tutta la vita è risolvere problemi”

Si fa presto a dire big data … (parte 1)

Oltre che ad essere il motto di questo blog, la frase “si fa presto a dire big data …” è stata ed è la miglior sintesi della maggior parte di convegni, webinar e  riunioni di lavoro a temache relative ai dati degli ultimi miei anni lavorativi. Purtroppo il termine “Big Data”, essendo una buzzword, è pronunciato spesso a sproposito sia per attirare l’attenzione che per giustificare qualunque tipo di progetto. Per questo oltre a far riferimento ad una delle migliori definizione e descrizioni del termine big data cioè la voce inglese di wikipedia proviamo ad entrare un po’ più in dettaglio in questo post per darne un’interpretazione più specifica e rigorosa.

LogoABDrev1

Il termine big data incomincia ad essere associato a progetti e a relativi prodotti a partire dalla seconda metà degli anni 2000 per differenziarli da quei progetti dati realizzabili con tecnologie mature già presenti sul mercato. Questo fenomeno si è espanso su più direttrici:
1) quella tecnologica. Cioè nella capacità di gestire grandi volumi dati e/o veloci volumi di dati. Le nuove tecnologie di memorizzazione dati di tipo NoSql rappresentano al meglio questa direttice.
2) quella algoritmica. Cioè la nascita o il grande miglioramento di metodologie che riescono ad estrarre valore da grandi moli di dati e che sono tipicamente definiti machine-learning.
3) quella relativa ai dati. Cioè l’aumentata disponibilità in termini sia di volumi che di frequenza di aggiornamento dei dati su cui possono fare leva progetti e analisi. Fenomeni come Open Data, il web stesso e Internet of Things hanno e stanno accelerando questa direttrice.
4) quella umano-organizzativa. Cioè l’evoluzione delle tradizionali figure di data-analyst verso le più poliedriche figure dei datascientist secondo la migliore definizione data nel 2010 da Drew Conway in un celebre post del suo blog. Queste figure riuscendo ad unire la capacità di usare nuovi algoritmi alle nuove tecnologie di elaborazione e memorizzazione dei dati, conoscendone la semantica e il contesto riescono a chiudere il cerchio del valore del progetto.

Esporeremo in dettaglio nel nostro viaggio tutte e quattro le direttrici ma quando almeno due sono presenti in misura importante all’interno di un progetto allora, secondo me, sì possiamo spendere l’aggettivo Big Data.
E’ chiaro che il numero di due è una scelta un poco arbitraria e che deriva dall’esperienza ma la presenza di una semantica “fumosa” non aiuta a sfruttare al meglio il fenomeno.  E poi non capita così spesso soprattutto in Italia che siano presenti anche due sole direttrici …

 

 

Si fa presto a dire big data … (parte 1)