Ieri 26 marzo i dati CoVid-19 relativi ai contagi son tornati a salire ma in conferenza stampa si sono udite parole come si potrebbe essere trattato di un accumularsi di tamponi e comunque la curva resta discendente. Chi lo dice, lo dice sulla base di cosa?

La mia sensazione è che i dati che la Protezione Civile fornisce ogni pomeriggio siano pensati ad uso e consumo della stampa, soprattutto la pseudo-stampa televisiva, che in nome della par condicio ha abolito da anni qualsiasi forma di pensiero critico e azzerato ogni capacità di analisi. Sono un po’ come le pecore di Orwell: ricevono un messaggio e lo amplificano.

Poi si parla di intelligenza artificiale come della bacchetta magica. Anzi si parla delle intelligenze artificiali che fanno cose che voi umani…

La legge fondamentale dell’apprendimento via software (ovvero il machine learning, ovvero lo strumento principale delle cosiddette intelligenze artificiali) è che se nella macchina entra spazzatura non può che uscirne spazzatura. Come direbbero i francesi, shit-in-shit-out.

Il valore del dato digitale si misura secondo due parametri chiave: qualità e integrità.

La qualità del dato indica la rilevanza e il significato che esso ha nel contesto di un problema. In altre parole, il dato mi è utile e sufficiente per capire il problema e analizzarne a fondo la dinamica?

La integrità, invece, fa riferimento alle caratteristiche fisiche del dato raccolto e indica l’affidabilità delle informazioni che da esso vengono estratte. L’integrità si misura attraverso parametri come la completezza, l’unicità, la densità temporale, l’accuratezza e la consistenza.

Perché i dati della Protezione Civile sono spazzatura? Perché i dati forniti, e parlo dei CSV e dei JSON rilasciati ogni pomeriggio, sono spesso:

• Incompleti
• Distribuiti malamente nel tempo
• Non sufficientemente accurati
• Inconsistenti

Il punto più doloroso è la completezza dei dati.

Completezza

Un dato è completo se la sua rappresentazione digitale contiene tutti gli attributi strettamente necessari alla comprensione di un problema da parte dell’uomo e della macchina. Il dato 100 email ricevute è scarno ma sufficiente se è il problema è raccontare una storia alla stampa. Al tempo stesso, però, una strategia di raccolta dati è seria se consente di raccogliere dati minuziosamente e poi aggregarli per scenari. Tornando alle email, raccogliere il totale è insufficiente e per nulla lungimirante. Peggio, non ha nulla a che vedere con paroloni come Open Data con cui le amministrazioni riempiono la bocca e i siti ufficiali. Ben diverso è fornire una tabella di email con colonne per orario, mittente, destinatari in copia, soggetto, testo. Da essa, se necessario, si potrà poi estrarre il semplice totale di quelle ricevute. Chi volesse, però, potrebbe fare ogni sorta di analisi.

I dati della protezione civile non comprendono:

• Il dettaglio dei ricoverati per provincia e per comune e/o per ASL. È auspicabile che questi dati esistano e che vengano utilizzati in qualche modo efficace da qualcuno che sappia cosa fare. Ma perché non renderli pubblici in modo capillare?
• Non si conosce il numero di coloro che escono dalla terapia intensiva e la ragione (miglioramento delle condizioni, peggioramento delle condizioni di altri, selezione naturale, sopraggiunta morte)
• Non si conosce la media dei giorni di terapia intensiva e di ricovero. Questo dato poi dovrebbe essere a livello di struttura ma anche aggregato a livello di provincia sarebbe utile per analisi
• L’entità tampone non è ben descritta. Bisognerebbe sapere che tipo di tampone è stato fatto (kit rapido, tampone molecolare, luminescenza) e se è stato ripetuto sullo stesso soggetto per controprova, in quale data e in quale struttura

In questa situazione è oggettivamente difficile pensare di fare machine learning e costruire modelli previsionali che specializzino con parametri specifici i modelli epidemiologici noti. Ma più modestamente è anche difficile comprendere cosa stia succedendo e se una scelta operativa dia risultati buoni o meno.

Densità temporale

La densità temporale fa riferimento alla distribuzione dei dati nel tempo. La frequenza del campionamento, ovvero ogni quanto ha senso raccogliere un dato, dipende dal problema in esame e dagli obiettivi che ci si pone. Buchi nella raccolta e successivi accumuli in avanti rovinano l’integrità del dato.

I ritardi nei risultati dei tamponi, per esempio, han fatto sì che i dati del 26 marzo abbiano segnato un picco inatteso ma in realtà se potessimo riportare i dati ai giorni effettivi vedremmo probabilmente una curva uniformemente discendente, magari meno inclinata ma senza picchi.

Ciò è solo quanto suggerisce l’esperienza ma non esiste (e non esisterà in mancanza di dati sufficientemente densi) la prova oggettiva.

Accuratezza

Un dato è accurato se descrive in modo meticoloso un’entità reale. Ciò significa che ogni attributo ritenuto necessario deve essere fornito. Ad esempio, se parliamo di email allora tutti i campi (Soggetto, CC, Mittente) devono essere compilati. Non vi devono essere buchi nella riga della tabella che rappresenta la descrizione di un’entità.

I dati resi noti dalla Protezione Civile non presentano buchi orizzontali importanti ma al tempo stesso il dato riportato non è necessariamente accurato perché risente di accumuli di informazioni su più giorni (densità temporale) e superficiale descrizione della struttura (completezza).

Inconsistenza

Un dato è consistente se i suoi valori sono coerenti con quelli di altri dati e non in palese contraddizione. Un classico esempio di inconsistenza è trovare un valore negativo laddove ci si aspetta, ad esempio, un totale.

Nel caso del CoVid-19 il report della Protezione Civile contiene solo a livello regionale una colonna che indica il totale dei nuovi casi positivi riscontrati ogni giorno. Tuttavia il 25 marzo tale colonna riportava un -2 sulla riga del Molise.

Il punto è: che significa esattamente il nome nuovi_attualmente_positivi? Significa che la colonna è semplicemente una colonna calcolata riportando la differenza tra il valore corrente della colonna totale_attualmente_positivi e quello del giorno prima. Sarà pure solo un problema di definizione, ma il dato di quanta gente in più è stata scoperta positiva nel giorno non esiste visto che il totale degli attualmente positivi sottrae guariti e deceduti dal totale dei casi.

Dunque?

La cosa peggiore è che questi dati esistono ma molto spesso sono confinati al reparto della struttura ospedaliera e da lì non fuoriescono. Dovrebbero, invece, finire in automatico in un archivio nazionale a cui la Protezione Civile attingerebbe per i suoi report. Non sto parlando di rendere pubblici i dati personali, ma semplicemente di avere dati anonimi molto più precisi e minuziosi.

Poi la politica.

Ieri, 26 marzo, Fontana spara un In Lombardia 2500 nuovi casi. Cos’è quel 2500? In realtà è l’incremento sul giorno prima del totale dei casi CoVid-19, che comprende la storia di tutti coloro che nel tempo sono stati censiti, inclusi guariti e deceduti. In realtà ieri in Lombardia il carico per gli ospedali — che è dato operativo essenziale da monitorare — è aumentato di sole (si fa per dire) 1598 unità, escludendo quindi guariti e deceduti.

Il dato è neutro, non ha interpretazione ed è fatto di freddi atomi numerici. L’informazione fornita, invece, è pre-lavorata e costituita di molecole emozionali di dubbia origine.

Perché non esiste una strategia del dato efficace?

Perché anche la Protezione Civile fatica ad accedere ai dati e lo stesso ISS fatica ad accedere alle cartelle cliniche? Perché la sanità è regionale e ogni regione ha il suo sistema e protegge i suoi dati. Peggio ancora, spesso nelle strutture anche i singoli reparti proteggono i propri dati. Manca completamente il senso ultimo della digital transformation.

Che non è avere file PDF al posto di moduli cartacei.

It’s informally called the method of the carrot and the stick.

Building a Behavior

As humans, we learn through the input we receive from senses and senses give us instinctively the feeling that something is good or bad. Sensory inputs are then logged into the brain and further elaborated into a number of information (e.g., we like it, we don’t like it) that, once stored, altogether contribute to the brain database of memories. The content of this database of memories will then be used further on to elaborate the next sensory input in a less instinctive, more thoughtful way.

Trending AI Articles:

1. Ten trends of Artificial Intelligence (AI) in 2019

2. Bursting the Jargon bubbles — Deep Learning

3. How Can We Improve the Quality of Our Data?

4. Machine Learning using Logistic Regression in Python with Code

Now imagine doing this over and over and again, synapses after synapses, second after second. A humongous archive of information builds up. The brain, in a way, indexes the database so that it can quickly find the set of neural commands to forward to neurons and muscles to react. Any sign of life of ours is a matter of reacting to some stimulus.

Hence, the more you receive a given input, the more you know about the behavior you consciously want to have about it. The more you receive the same given input, the more often you react in the same given way. Therefore, the more you morph an instinctive behavior into some more thoughtful behavior.

Changing the instinctive behavior to something smarter in terms of final results is the ultimate purpose of training. For animals, humans as well as for algorithms.

Reward and Punishment

The purpose of training is changing the frequency of certain behaviors so that an undesirable behavior is observed less often and a desirable behavior, instead, is observed more frequently. To build any form of training, you must use consequences and fine-tune your actions to trigger just the expected reactions as often as possible.

One of the core principles of training is offering the trainee a positive experience–a reward–in response to a desirable action. Another core principle of training is specular to this and consists in offering the trainee an aversive experience–a punishment–in return of an unwanted action. All trainers, therefore, use consequences as all trainees instinctively tend to orientate their behavior towards rewards (the carrot) and to avoid punishment (the stick). The carrot-and-stick approach is the pattern that animals and humans use to learn.

What about algorithms?

If the carrot exists to please the trainee and the stick serves to punish the trainee, how do you please, or punish, an algorithm? Of course, you don’t. Or, at least, you don’t do it in the common sense.

For a trained algorithm, the reward or the punishment results from the position of the computed result, over or under an acceptable threshold.

And Once the Behavior is Learned?

Once a behavior is learned should you remove any rewards from the equation and expect that the human, the animal or the algorithm behaves the desirable way only for the joy of performing?

Professional dog trainers, for example, agree that you can reduce the food reward but never phase it out entirely. The reason is that dogs (but the same holds true for other animals and, even more, humans) are living beings and use their behavior as a tool to trigger events and produce consequences.

The carrot (or stick) stimulus should remain even when the behavior is learned, but the strength of the stimulus should be modulated over time to maintain the likelihood of desirable behavior high enough.

What about algorithms? It’s just the same.

A trained algorithm, more than animals and humans, can effectively be thought as a fountain from which a desirable behavior flows. The issue is that the landscape and the context around the fountain may continuously change. Hence the algorithm, like animals and humans do, must adapt. Adapting the algorithm to a changed context required a new session training and probably also fine-tuning the threshold that sets what’s good and what’s bad.

PS: Training an algorithm is hard.

NOTE: Overall, the carrot-and-stick approach is a technique aimed first at teaching how to perform a desired behavior and then at internalizing it so that it becomes natural regardless of the actual conditions it was initially taught in. Thinking of carrots and sticks with an eye on machine learning, the words pronounced by Sir Winston Churchill right before the beginning of the second world war resound evocatively: Thus, by every device from the stick to the carrot, the emaciated Austrian donkey is made to pull the Nazi barrow up an ever-steepening hill.

“Introducing Machine Learning in .NET”, Microsoft Press, 2019

Youbiquitous

Don’t forget to give us your 👏 !

Carrots, Sticks and (AI) Learning was originally published in Becoming Human: Artificial Intelligence Magazine on Medium, where people are continuing the conversation by highlighting and responding to this story.

So at SDD 2018 I decided to attend a talk on React. We all know that titles and abstracts only rarely match the actual content being delivered as titles tend to be catchy and abstracts are written either six months before when you are far away from putting together slides and demos. Yet, the promise was enticing and I am quite curious about React. I got lost after 25 minutes but not because React was overly complex or me overly dumb.

At some point after 25 minutes my brains got locked in a loop.

Right after the render method of an App component, the speaker demoed routes and my brains threw an exception “OK, I can get the same with stupidly simpler hyperlinks. What’s wrong? Me? The demo? The order of topics? The entire React thing?” I could have raised hand and ask a question — sure — but that beyond that I feel it was the structure of the story told to be problematic. In first place I was expecting a clear statement about the issues that React is trying to solve and why would it be preferable over plain HTML+JS.

“We used it to replace another older SPA app and it worked well”. No doubt it really went like this but it’s kind of Me-vs-You statement. No arguments. Speaking and coding are different jobs. Speaking is about storytelling; coding is about problem solving and many other things.

In another talk I attended I had a similar lock-down experience with my brains but in a radically different context. The speaker was amazing — too amazing — and well prepared. The story was scripted in every single particular, including exceptions and many of the possible reactions from the audience. Too perfect. It was also technically relevant and engaging so my brains got caught and it was working on its own as the speaker was talking.

The talk followed a clear pattern: show the issue, indicate a poor solution, then a slightly better one, then the ideal one. My brains got the pattern and after the first round switched to other gigs waiting for the stage at which the real applicable solution would have been presented.

Talks about code can’t be perfect and can’t be poor. Stories must be about life of coders and we all know coding is fun but not exactly a well paved road.

Who said that? It was a software architect working for one of the major software companies in the world. He said that when he came to meet me at the JetBrains booth at the Great Indian Developers Summit conference in Bangalore.

As a software professional, I’m sure you pretty much know the story. Loading Visual Studio 2017 takes ages or, anyway, tons of another unit of time that claws through the skin as it ticks away. If you also have ReSharper installed then the whole thing takes well two ages to be up and running. And, nicely enough, when under memory pressure Visual Studio 2017 also kindly suggests to shut down ReSharper to let it run less slowly.

So we’re back to the question the anonymous software architect working for a software giant asked this morning. Have you ever considered removing some features from your products? Regardless of what ReSharper and Visual Studio have specifically done over the years, I think that we all consider software applications as append-only containers in the sacred name of backward compatibility and customer care. Except that, in the end, by doing so we just kill our customer care ourselves.

A company I worked for grew quickly in only a few years because of a good idea they have been able to implement under a quite rare and favorable astral conjunction. Customers were coming like rain just willing to pay for services and begging for some customization. Customization was done for every customer in the sacred name of customer care. Except that, in the end, by doing so customers now call the product outdated because heavy and cumbersome and providing (and charging for) way too many features they actually don’t need anymore.

Have you ever considered removing some features from your products?

I’m tempted to say that the few who did it, if any, concluded that it was OK to keep everything on board. “It works and it would cost more to remove it” I can hear a swarm of project managers say. Except that, in the end, by doing so we make the same product expensive, gigantic and accompany customers towards leaner and meaner competitors.

Just the kind of company that happen to have a good idea and can implement it under a rare, but recurring, favorable astral conjunction.

Remove that feature. Oh great, but how?