AfI/IAf #2: “Machines are objective” / “La machine est objective” (1/2)

In this second article in the Artifakal Intelligence / Intelligence Artifaussielle series, I’ll dive more into the famous phrase: “machines are logical, hence they are objective“. To which extent is it true that machines are unbiased? Can we really trust an AI to be completely “fair and neutral” when solving a problem?

This article is also available on Medium.

To learn more about this project, read the introductory article.

A few weeks ago, the french journal Courrier international published a set of articles about predictive algorithms and how they are used in our everyday lives. In particular, they tried to paint a picture of the advantages people can get from AI but also of the lack of objectivity these programs may have that are born directly from our own clichés.

Over the past few years, a rumour has spread around that, because they are but lines of code, algorithms are absolutely neutral and objective. Even big IT magazines like CXOtoday have articles such as “AI To Empower Workforce And Drive Objectivity” (by M. Sengupta) that list the benefits of AI in a work environment, in particular in getting rid of biases or doing a better examination of your data.

But while it is absolutely legitimate to regard machines as a good analysis tool, we should still be cautious and not give them too much credit. I’m not saying that there could be a “ghost in the machine” that writes lines in-between the lines the programmer has written to make robots sentient and completely autonomous; however I feel it is important to remember that in AI, algorithms are only a part of the process. Let’s take a step back and think of what they actually can and can’t do.

Note: this article will be split into two parts – one this week and the second one next week. Today, I’ll talk about the concept of objectivity and the issues that can appear in the data an AI analyzes. Next time, we’ll see how what consequences they can have in real-life applications of AI and I’ll discuss some ideas that may reduce biases in algorithms.

What is objectivity, truly?

To be honest, a lot of the blurriness in this sentence comes from the main word itself: “objectivity”. What does this really mean? Looking at the online version of the Collins dictionary, here is the definition we get for the “objective” adjective we’re interested in:

objective: If someone is objective, they base their opinions on facts rather than on their personal feelings.

The suggested synonyms are “unbiased”, “neutral”, “detached”, “just”. My take on this is that we can extract 3 pieces of information from these observations (that are relevant to our discussion here):

  • objectivity is linked to factual events, observations and reality: if you want to be objective, you need to examine the world around you and report on measurable things
  • objectivity is a way of making decisions
  • objectivity is linked to the concepts of fairness and justice: judging with feelings is bound to tip the scale while judging only with facts and reality makes for a “just” outcome

The second point sounds right to me, because “objectivity” and “subjectivity” are indeed two (valid) processes to analyze a problem. The difference is that, of course, each uses different analysis tools. Since subjectivity depends on feelings and we haven’t (yet?) managed to implement that in an AI, it seems logical we should use objectivity rather than subjectivity to make decisions in our algorithms.

In my opinion, the third point is not that easy to state as a general rule. Being quite rational myself, I am inclined to think that using objective facts is a better way of getting to equality. Still, it is easy to come up with examples where being “fair” does not mean “make the most people happy”. If asked to only look at the numbers, an economist might suggest new laws that don’t necessarily help the unprivileged…

Note: in a sense, you could argue that this depends whether you consider utilitarianism an okay philosophy or not. These ethical theories “promote actions that maximize happiness and well-being for the affected individuals” (see Wikipedia). Therefore a utilitarian might turn against objectivity as a gold standard if it favors statistics over happiness.

The first point seems hardly negotiable: isn’t it the essence of objectivity to be a paradigm where “everyone gets the same answer for the same question”? If I say I’m objective and you say you’re objective too, then given the exact same situation we should end up with the exact same, right? Well…

I believe the whole trick is in the “same situation” phrase. Very often, when two objective persons disagree, it’s because whether we want to or not, we always have our own perception of the reality around us. If placed in the exact same context, you and I might perceive it differently, hence analyze a different set of data and get different conclusions.

Be it with humans or machines, analysis relies on inputs. So if you’ve decided that your analysis program is perfect and always give you the right answer (either because you believe you know all that is needed about a situation or because your algorithm is amazingly efficient), you better make sure you give it the right inputs!

The importance of data

Once again, it is particularly true in AI, where data is everything. You can design as complex a model as you wish, if you can’t feed it with the right kind of information to begin with, it won’t be able to “learn” and “predict” anything. In the previous article of this series, I talked about how the “entire world” of the machine is decided upon by its programmer. These inputs are the window that the AI has to view the world, it is the data the algorithm is going to base its “objective analysis” on. And it can, of course, come with its own set of issues.

We saw previously that this data should be organized, preprocessed and often labelled very neatly. We also pinpointed the fact that this cannot yet be done by machines, which is why humans are currently “enslaved” into mindless jobs to take care of this step, be it by FigureEight, Amazon Mechanical Turk, Clickworker or Accenture.

However, this is not the only problem with these inputs: another crucial question is whether what you feed your machine truly represents the “just” world you want or if it itself contains some inherent biases. This is a continuation of what I mentioned before about everyone having their own perception of reality.

Note: our societies currently are filled with biases… that’s why giving an AI real-world data can still result in biased results. For more on this, check out another article I published last month about bias in ML.

To illustrate this, let’s take a little example. Suppose we have two basic AIs that do binary classification on colors. In other words, we want to tell if an object is of the given reference color or not. The fun thing is that each is blind to all but one color: the first AI can only see blue (the rest of the world is grey) and the second one can only see red. So the reference of the first is blue and the reference of the other is red. If we don’t talk about this important distinction and point the finger at this, what might happen is that:

  • the first AI observes the reality and builds its own model of the world where there is blue and grey; it becomes good at it and whenever you ask it to tell whether an object is blue or not, it can predict with an absolute confidence and an incredible accuracy the right answer
  • the second AI has a parallel and independent model that distinguishes “red from not red” and is just as accurate
  • if either algorithm is asked to predict something about the other’s reference color, it won’t have any idea what to say; but it has to give an answer, so it still gives a prediction at random

This little toy example shows that the AIs have very different perceptions of their environment, that they have learnt to spot completely different patterns and that, even if they both process the inputs “logically and fairly”, they get different results. It is crude, though. In reality, finding and fixing biases in the inputs is a very complex task.

These biases can be introduced because your data does not encompass the full scope of the situation you want to model (like in our “blind to all but one color” example), because you lack some learning examples, because you have an overrepresentation of others… all in all, there are many ways to have biased data which is why it is often very hard to spot this.

When you’re a data scientist and you’re given a brand new dataset to play with, you usually start with a statistical analysis phase that is supposed to give you this sort of information; you may encounter various problems that can each be treated in various ways and can each result in various biases.

Note: I’ll just talk about a few issues here but there are more!

“Skewed” datasets

One of the main thing you want to find out is whether some of your measurements show characteristics that are “skewed” in some way. This regularly comes from an imbalance in your dataset: in other words, you have an uneven number of items in each of your categories. This can be intuitively represented like this:

By saylordog (https://saylordotorg.github.io/text_essentials-of-geographic-information-systems/section_10/e8b3fa38d26678631d8c8c2c7822011b.jpg)

In a “normal case” (where your data follows a “normal distribution”), you have a symmetric curve. In the skewed cases, your curve “leans” either on the right or on the left. This has an impact on the mean and the median of the data and on the statistical analysis in general – some tools might not apply to a skewed dataset.

Let’s take an example to better understand this. Suppose you want to do some house prices prediction, which is quite a common task in data science beginner tutorials. Something that might happen depending on the dataset you take is that you might have less examples in the big price range. Since most of your data is in the low price range and the prices vary a lot, your algorithm will probably consider that the mean of your data not where you would expect. And it might even conclude that these expensive examples are “outliers” (i.e. points that are very far away from the data and could be considered “too weird to keep”, see below) and decide to virtually ignore them in its analysis.

Note: last year, when I worked on ScamPredictor, an email scam prediction tool, with SignalArnaques, we faced this issue too. Because we had a lot of references of scam emails but not so much of “correct” emails, the initial algorithm had difficulties learning the distinction properly and instead focused on super tiny variations between the scam examples.

There are several ways of dealing with this issue (as discussed for example by R. Vasudev in this short article) that mostly rely on “rescaling” your data to try and erase these big jumps and regroup your data a bit more cleverly.

The problem with skewed datasets is that the overrepresentation of some categories usually impacts an AI greatly by essentially narrowing down its vision of the world to only these categories. Rather than trying to distinguish between the various categories, the machine will focus on these overrepresented categories, ignore the rest, and search for small-level differences inside these categories alone.

Outliers: should I kick it out?

Another big thing in data processing is the problem of outliers. Namely: what should I do with the points that seem very different from the rest of the data? If I have a bunch of measurements that all lie in the same part of my result space but one point suddenly stands out and jumps to a complete different zone, do I consider it is just a measurement error or do I interpret this as an inherent characteristic of my data with a true significance?

Suppose you are a skiing coach for kids. After a week of teaching them the ropes, you ask them to go down the High Jade Slope and you time them. Because you know the slope is 500m long, you can then easily compute the speed of each kid. Here are the results:

NameTime (s)Speed (km/h)
John104.717.2
Amy103.417.4
Tom111.816.1
Patrick100.617.9
Elise10018
Ronald2258

Your goal is to have an average speed of at least 16 km/h, since this is a common basic speed for skiers. For now, the mean of all speeds is 15.4 km/h, so you haven’t achieved it yet! But let’s be honest, Ronald doesn’t like skiing very much and he even stopped for a while to drink some soda. He clearly took a lot longer than the rest of the group to get down the slope: he is an outlier in the dataset. If you were to remove this item from your data, then the average would jump up to 17.3 km/h, a really good result!

But should you consider Ronald is the exception to the rule? Could it be that, with a larger group of children, more would have had this behavior and there would actually be two subgroups – the “quick” and the “easy peasy”? The issue with outliers is that they are a “relative” notion, in the sense that an item is “different” from others… if there are others to compare it with!

Say you do decide to remove those items from your dataset. The question is then: how many times do you allow yourself to “kick outliers out?”. Once you have removed an item, it is quite probable that the overall pattern will change a little, so you will know have a new set of outliers. If you remove them a second time, you will again modify your data, and perhaps find new outliers… When should you stop doing that? At which point have you removed so many items that you have completely transformed – and thus made irrelevant – your dataset?

Treating outliers can be quite tricky if the difference is not obvious or if there are multiple ways of grouping your data that make for multiple sets of outliers. In general, you should be wary of not just getting rid of “weird” points and instead wonder why exactly they are in your dataset: is it a measurement error? or a true special thing in the situation your are modeling?

Missing data

When you get a set of values, there might be some missing data. Be it because you couldn’t make the measurement, because you’re just too unsure of it to reasonably use it or because it just doesn’t make sense for an item, sometimes it happens that there are “holes” in your table of values.

For example, let’s say we are a group of five friends and each of us has a hamster. We want to measure the size and weight of each pet. There are five rodents: Marcus, Billy, Becky, Rose and Cathie. Marcus is really fast, so it’s hard to have it stay put long enough to get its weight. Billy likes to jump a lot rather than stay still, so we’re having trouble getting its size. Becky and Rose are quite obedient but Cathie likes to appear tall and always stretches when you measure its size; so you’re not certain of how big it really is. In the end, we have a dataset that looks like that:

NameSize (cm)Weight (g)
Marcus18 
Billy 44
Becky1532.4
Rose17.237
Cathie 35.1

There are many ways of dealing with missing data that are more or less complex: some people just replace all missing values by a null equivalent, others do some basic linear interpolations based on the closest values, there are even a few “auxiliary generative AIs” that you can train to predict what the missing value should be (depending on the patterns in your dataset). One way of filling our dataset would be to assume a linear correspondence between the two columns and to infer the empty cells from the ones next to them; if we take the data for Becky and Rose (that gently let us measure both characteristics), we see that there is a factor f ~= 2.15 between the two, such that weight = f * size.

NameSize (cm)Weight (g)
Marcus1838.7
Billy20.544
Becky1532.4
Rose17.237
Cathie16.335.1

But doing that is a bit “optimistic”: we were lucky that both our items gave us a similar value for the f factor but we have no guarantee that this linear relationship truly exists. Perhaps those were exceptions: having just two items is far from enough to insure a global pattern. Moreover, you always have to be careful with units and transforms that have been applied to your data: should we do a log() of our “weight” column, the linearity we assumed would completely disappear!

Whenever we “fill in” missing values, we need to be very careful that we don’t unintentionally add, modify or remove patterns in our data.

Simpson’s paradox aka “I smelled the wrong rat”

Simpson’s paradox is a statistical phenomenon in which some patterns show in a subgroups of the dataset but disappear when those groups are combined. A second less-mentioned paradox is about the reverse situation: when a trend shows in the full dataset but not in subsets. In any case, the Simpson’s paradox says that there are some datasets that may be analyzed to conclude one thing or its complete opposite.

It is usually caused by the fact that, in addition to what you have identified as cause(s) for your resulting variable, there are more factors that impact your result. In particular, there are variables that are called “confounding factors” (or “lurking variables”) and that impact both your cause(s) and your result. They add relationships and patterns you might not be aware of in your data and that make for sometimes (apparently) illogical outcomes.

The example of kidney stone treatment is quite interesting for that matter. In 1986, four researchers published an article in the British Medical Journal that studied how two types of treatments A and B worked for small and large stones. The result was quite surprising:

  • when you look at the results for both stone sizes (small and large) at the same time, then Treatment B is better (with an 83% success rate versus only 78% for Treatment A)
  • however, if you look at small stones first and then at large stones separately, Treatment A is consistently better than Treatment B (for small stones: A has a 93% success rate, B only 87%; for large stones: A has a 73% success rate, B only 69%)

How is that possible? The most likely explanation is that there is a confounding factor with the severity of the case to treat. In these experiments, when we have a large stone, we use Treatment A a lot more than Treatment B. So even if Treatment A is inherently more efficient than Treatment B, it has to deal with the most difficult cases and thus fails more often on average. In truth, this lurking variable has an even larger effect on the success rate than the choice of treatment.

Note: if you speak French, the really cool David Louapre from Science Etonnante made a nice YouTube video on this topic focused on a very similar example.

The problem here is that those factors you did not account for also have an impact on the cause(s) you did list.

So when you have a dataset, you should always be careful how it was collected. It might be hard to identify the confounding factors but it is necessary to have an accurate picture of the situation to model. In particular, it is important to know if you are reading a prospective or a retrospective study, i.e. if this data was gathered specifically for the study or if it already existed before and the researchers are “just” taking a new look at it from another angle. With the former, it is more probable that researchers were cautious and thought of lurking variables; with the latter, you should be very wary because there might lots of hidden confounding factors!

There just isn’t enough!

One very classic problem with data science is not having enough of it. When you’re asked to work on an AI model but lack actual inputs to process, then you’re probably gonna have a hard time. In particular, when working on clearly insufficient amounts of data, you might be faced with various issues:

  • if you have a really small number of items, your model may very well overfit; this means that it will effectively “learn the answer by heart” on your train set and will thus only be able to predict an output for those inputs that it knows about… which is quite useless! For the rest of your items (usually called the “test set”), it will just give a random prediction because it has not learnt any general behavior in the data but instead just remembered what the exact answer was for the few items it encountered.
  • as mentioned before, if your dataset is skewed, your AI will probably learn biased patterns and therefore do biased predictions. This can be especially harmful when applied to concrete everyday-life cases (I will give examples next week, or you can read this article by C. Baraniuk about the Harm Assessment Risk Tool, an AI algorithm used by the police in Durham, North East England)…

Next time

Next week’s article will discuss how biased machines have an impact on our lives, how our usage of AIs in the real world has to be monitored closely to avoid repeating systemic issues such as racism or other forms of discriminations.

I’ll also point to some ideas that could help us improve the algorithms by mitigating the biases or at least making people aware of them.

Until then, stay curious and don’t hesitate to follow me if you’re interested!

Dans ce second article de la série Artifakal Intelligence / Intelligence Artifaussielle, je vais m’intéresser à la fameuse phrase : “les machines sont logiques, donc elles sont objectives“. A quel point peut-on dire que les machines ne sont pas biaisées ? Peut-on réellement penser en toute confiance qu’une IA est complètement “juste et neutre” quand elle résout un problème ?

Il y a quelques semaines, le journal français Courrier international a publié un ensemble d’articles à propos des algorithmes prédictifs et de la façon dont ils sont utilisés dans la vie de tous les jours. En particulier, ils ont essayé de dépeindre à la fois les avantages que nous pouvons tirer de l’IA mais aussi le manque d’objectivité que ces programmes pourraient avoir – un problème qui vient directement de nos propres clichés.

Ces dernières années, la rumeur s’est propagée que les algorithmes n’étant que des lignes de code, ils sont absolument neutres et objectifs. Même de grands magazines d’informatique comme CXOtoday écrivent des articles tels que “AI To Empower Workforce And Drive Objectivity” (“L’IA pour dynamiser les employés et stimuler l’objectivité”, de M. Sengupta) qui listent les bienfaits de l’IA au travail, en particulier pour éliminer des biais et mieux examiner les données.

Pourtant, même s’il est tout à fait légitime de considérer les machines comme de bons outils d’analyse, il faut rester prudent et ne pas leur accorder trop de crédit. Je ne dis pas qu’il pourrait y avoir un “fantôme dans la machine” qui écrit entre les lignes rédigées par le programmeur pour donner une conscience aux robots et les rendre autonomes ; mais il faut se souvenir qu’en IA, les algorithmes ne sont qu’une partie du processus. Prenons un peu de recul et réfléchissions à ce qu’ils peuvent effectivement faire, ou ne pas faire.

Note : cet article sera divisé en deux parties – un cette semaine et le second la semaine prochaine. Aujourd’hui, je vais parler du concept d’objectivité et des problèmes qu’il peut y avoir dans les données qu’une IA analyse. La prochaine fois, nous verrons les conséquences qu’elles peuvent avoir pour des applications de l’IA dans la vie réelle et je présenterai quelques idées qui pourraient aider à réduire les biais dans les algorithmes.

Qu’est-ce que l’objectivité, en fait ?

Honnêtement, beaucoup du flou dans la phrase ci-dessus vient du mot central lui-même : “objectivité”. Que veut-il dire réellement ? Si on regarde la version en ligne du Larousse, voici la définition que l’on trouve pour l’adjectif “objectif, ve” qui nous intéresse :

objectif, ve : Qui ne fait pas intervenir d’éléments affectifs, de facteurs personnels dans ses jugements.

Parmi les synonymes suggérés, il y a “impartial”, “exact”, “détaché”, “fidèle”, “précis”. A mon avis, on peut tirer 3 informations importantes (pour notre discussion) de ces observations :

  • l’objectivité est lié à des faits, des observations, à la réalité : si on veut être objectif, on doit examiner le monde autour de nous et étudier des choses mesurables
  • l’objectivité permet de prendre des décisions
  • l’objectivité est lié aux concepts d’égalité et de justice : juger avec ses émotions fausse la balance alors que juger avec des faits permet un résultat “juste”

Le deuxième point me paraît valable parce que “objectivité” et “subjectivité” sont en effet deux moyens (valides) d’analyser un problème. Ils diffèrent, bien sûr, dans les outils d’analyse utilisés. Comme la subjectivité dépend des émotions et que nous n’avons pas (encore ?) réussi à les implémenter dans une IA, il est logique que nos algorithmes se reposent plutôt sur l’objectivité que la subjectivité pour prendre des décisions.

Je pense que le 3e point n’est pas aussi simple à affirmer en toute généralité. Je suis pour ma part assez rationnelle, donc je suis encline à penser que l’objectivité est souvent un meilleur moyen d’être égalitaire. En même temps, on peut facilement trouver des exemples où être “juste” ne coïncide pas avec “maximiser le bonheur”. Si on lui demande de ne regarder que les chiffres, un économiste pourrait proposer des lois qui n’aident pas vraiment les personnes défavorisées…

Note : d’une certaine façon, on pourrait dire que cela dépend de si vous appréciez l’utilitarisme. Ces théories éthiques “prescri[ven]t d’agir (ou de ne pas agir) de manière à maximiser le bien-être collectif, entendu comme la somme ou la moyenne de bien-être (bien-être agrégé) de l’ensemble des êtres sensibles et affectés” (voir Wikipédia). Donc un utilitariste pourrait refuser d’accepter l’objectivité comme la solution miracle si elle favorise les belles statistiques plutôt que le bonheur.

Le premier point semble difficilement réfutable : n’est-ce pas l’essence même de l’objectivité d’être le paradigme où “tout le monde a la même réponse à la même question” ? Si je dis que je suis objective, et que vous dites la même chose, alors dans la même situation, nous devrions arriver à la même conclusion, pas vrai ? Mmh…

Je crois que toute la ruse est dans l’expression “même situation”. Souvent, quand deux personnes objectives ne sont pas d’accord, c’est parce que, qu’elles le veuillent ou non, elles ont toujours une perception personnelle de la réalité qui les entoure. Même en étant mis exactement dans le même “contexte”, nous pourrions le percevoir différemment, donc analyser des données différentes et arriver à des conclusions différentes.

Que ce soit pour un humain ou une machine, l’analyse repose sur les données d’entrées. Cela signifie que si on décide que le programme d’analyse est parfait et donne toujours la bonne réponse (soit parce qu’on croit savoir tout ce qui est nécessaire sur la situation ou parce que l’algorithme est incroyablement efficace), on doit encore s’assurer de lui donner les bonnes entrées !

L’importance des données

Encore une fois, c’est particulièrement vrai en IA où les données sont primordiales. On peut concevoir un modèle aussi complexe que l’on veut, si on ne peut pas le nourrir avec les informations nécessaires, il ne pourra pas “apprendre” et “prédire” quoi que ce soit. La dernière fois, j’ai parlé du fait que l’entièreté du monde de la machine dépend du programmeur. Ces entrées sont la fenêtre que l’IA a d’ouverte sur le monde, ce sont les données que l’algorithme va prendre comme base pour son “analyse objective”. Et, évidemment, ces entrées peuvent apporter leur lot de problèmes.

On a vu précédemment que la donnée doit être organisée, préparée et souvent étiquetée très soigneusement. Nous avons aussi mis en avant le fait qu’on ne peut pas encore demander à des machines de le faire et que, pour cette raison, des humains s’occupent aujourd’hui de cette étape en étant “esclaves” d’emplois abêtissants (proposés par FigureEight, Amazon Mechanical Turk, Clickworker ou Accenture).

Pourtant, ce n’est pas le seul problème avec ces données. Une autre question cruciale est : est-ce que ce qui nourrit notre algorithme représente vraiment le monde ou est-ce que ces entrées contiennent des biais intrinsèques ? Ceci poursuit ce que je mentionnais plus tôt sur le fait que chacun a sa propre perception de la réalité.

Pour illustrer cela, prenons un petit exemple. Supposons que nous avons deux IAs qui doivent faire de la classification binaire avec des couleurs. En d’autres termes, elles doivent dire si un objet est de la couleur de référence ou non. Le piège, ce que chaque IA ne perçoit qu’une couleur : la première ne peut voir que le bleu (le reste du monde est gris) et la seconde ne peut voir que le rouge. Donc, la référence de la première est le bleu et la référence de la seconde est le rouge. Si on ne mentionne pas cette distinction importante et qu’on ne la met pas en lumière, il pourrait arriver que:

  • la première observe le monde et construise son propre modèle où tout est bleu et gris ; elle devient très performante et lorsqu’on lui demande si un object est bleu ou non, elle peut prédire avec une confiance absolue et une précision incroyable la bonne réponse
  • de son côté, la seconde a indépendamment construit un modèle qui distingue “rouge” de “non rouge” et est aussi précis
  • si on demande à l’une d’elles de faire une prédiction à propos de la couleur de référence de l’autre IA, elle n’aura aucune idée de la réponse ; mais elle sera obligée de donner une réponse alors elle fournira une prédiction au hasard

Cet exemple montre que ces IAs ont des perceptions très différentes de leur environnement, qu’elles ont appris à repérer des schémas complètement différents et que, même si elles étudient toutes les deux les entrées de manière “logique et juste”, elles trouvent des résultats différents. C’est un peu simpliste, cependant. Dans la réalité, trouver et réparer les biais dans les données est une tâche très complexe.

Ces biais peuvent être liés au fait que les données n’englobent pas l’entièreté de la situation que l’on veut modéliser (comme dans notre exemple où les IAs sont “aveugles à toutes les couleurs sauf une”), qu’on manque d’exemples d’apprentissage, que certaines catégories sont surreprésentés… il y a finalement beaucoup de raisons pour lesquelles on peut avoir des biais dans nos données, c’est pourquoi ils sont souvent difficiles à repérer.

Quand on est un data scientist et qu’on nous demande de travailler sur un nouveau jeu de données, on commence en général par une phase d’analyse statistique qui est supposée révéler ce genre d’informations ; on peut rencontrer une multitude de problèmes qui peuvent chacun être résolus de diverses manières et peuvent tous causer des biais.

Note : Je ne vais pas parler ici que de quelques problèmes mais il y en a d’autres !

Jeu de données “skewed

Une des choses importantes à vérifier est le fait que les mesures présentent ou non des caractéristiques statistiquement biaisées (ou skewed, en anglais). Cela vient souvent d’un déséquilibrage dans le jeu de données : on a un nombre inégal d’items dans chacune de nos catégories. Intuitivement, on peut le représenter ainsi :

Par saylordog (https://saylordotorg.github.io/text_essentials-of-geographic-information-systems/section_10/e8b3fa38d26678631d8c8c2c7822011b.jpg)

Dans un “cas normal” (où les données suivent une “distribution normale”, à gauche), on a une courbe symétrique. Dans les cas statistiquement biaisés, la courbe “penche” à gauche ou à droite. Cela a un impact sur la moyenne et la médiane des données et sur l’analyse statistique en général – certains outils peuvent ne pas s’appliquer à un jeu de données biaisé.

Etudions un exemple pour mieux comprendre. Disons que l’on souhaite prédire le prix de maisons, une tâche assez commune dans les tutoriels de débutants en IA. Il peut arriver, selon le jeu de données choisi, qu’on ait moins d’exemples pour les maisons très chères. Comme la majorité des items sont dans la gamme basse de prix et que ces prix varient beaucoup, l’algorithme considèrera probablement que la moyenne des données n’est pas là où on l’attend. Et il pourrait même conclure que ces exemples très chers sont des “outliers” (ou “aberrations statistiques”, c’est-à-dire des points très éloignés du reste des données que l’on peut considérer comme trop étranges pour être conservés, voir ci-dessous) et décider de globalement les ignorer pour l’analyse.

Note : l’an dernier, quand j’ai travaillé sur le projet ScamPredictor, un outil de détection des mails frauduleux, avec SignalArnaques, nous avons aussi eu affaire à ce problème. Etant donné que beaucoup de nos références étaient des spams mais que nous avions peu d’emails “corrects”, notre premier algorithme avait du mal à apprendre à distinguer proprement ces deux classes et se concentrait plutôt sur des petites variations entre les exemples de spam.

Il y a plusieurs moyens de traiter ce problème (comme détaillé par exemple par R. Vasudev dans ce court article) qui repose principalement sur un “redimensionnement” des données pour essayer d’effacer les grandes disparités et de regrouper les données de manière plus intelligente.

La difficulté avec les jeux de données statistiquement biaisés est que la surreprésentation de certaines catégories impact beaucoup une IA. En pratique, cela réduit la vision que l’IA a du monde a ces catégories-là. Plutôt que d’essayer de distinguer les catégories elles-mêmes, l’algorithme va se concentrer sur les catégories surreprésentées, ignorer le reste et chercher des différences à une petite échelle au sein des ces catégories.

Outliers : faut-il s’en débarrasser?

Une autre difficulté dans le traitement des données est la question des aberrations statistiques, les outliers. En d’autres termes : que doit-on faire des points qui ont l’air très à part, très différents du reste des données ? Si j’ai un ensemble de mesures qui sont toutes similaires et que soudain, la nouvelle mesure n’a rien à voir, dois-je considérer que c’est simplement une erreur de mesure ou dois-je l’interpréter comme une caractéristique intrinsèque de mes données avec une vraie signification ?

Imaginons que vous êtes moniteur de ski pour un groupe d’enfants. Après leur avoir appris les bases pendant une semaine, vous leur demandez d’aller descendre la Grande Pente de Jade et vous les chronométrez. Comme vous savez que la pente fait 500m de long, vous pouvez facilement calculer la vitesse de chaque enfant. Voici les résultats :

NomTemps (s)Vitesse (km/h)
John104.717.2
Amy103.417.4
Tom111.816.1
Patrick100.617.9
Elise10018
Ronald2258

Votre but est d’atteindre une vitesse moyenne d’au moins 16 km/h, une vitesse habituelle pour des skieurs non professionnels. Pour l’instant, votre moyenne est de 15.4 km/h, donc vous n’y êtes pas encore ! Mais, en vérité, Ronald n’aime pas beaucoup le ski et il s’est même arrêté en chemin pour boire du soda. Il a clairement mis beaucoup plus longtemps que le reste du groupe à descendre la pente. Si vous enleviez cet item des données, la vitesse moyenne remonterait à 17.3 km/h, un très bon résultat !

Faut-il considérer que Ronald est une exception ? Ou est-ce qu’avec un groupe d’enfants plus nombreux, d’autres auraient le même comportement et il y aurait en fait deux sous-groupes – les “rapides” et les “tranquilles” ? Le problème avec le concept d’outlier est que c’est une notion relative puisque le fait qu’un item soit “différent d’un autre” dépend de ce à quoi on le compare.

Disons que vous décidez effectivement d’enlever les aberrations statistiques de votre jeu de données. Alors la question devient : combien de fois pouvez-vous “jeter les outliers” ? Quand on enlève un item, il est très probable que le schéma général soit un peu modifié et qu’on ait alors un nouvel ensemble d’aberrations. Si on enlève ces nouveaux outliers, on modifie encore les données, et on trouve peut-être encore de nouvelles aberrations… Quand doit-on s’arrêter ? A quel moment a-t-on retiré tellement d’items que l’on a complètement transformé – et donc rendu “hors sujet” – notre jeu de données ?

Traiter le cas des outliers peut être délicat si la différence n’est pas nette ou s’il y a plusieurs façons de regrouper les données qui donnent divers ensembles d’aberrations. De manière générale, il faut se méfier de simplement retirer les points étranges et plutôt se demander pourquoi ils sont présents dans le jeu de données : sont-ils dûs à une erreur de mesure ? ou à quelque chose de réellement particulier dans la situation que l’on modélise ?

Données manquantes

Quand on récupère un jeu de données, il est parfois incomplet. Que ce soit parce qu’on n’a pas pu effectuer la mesure, parce que l’on est trop incertain du résultat pour le garder en toute confiance ou parce que ce type de mesure ne s’applique pas à l’item considéré, il arrive qu’il y ait des “trous” dans notre table de valeurs.

Par exemple, supposons que nous sommes un groupe de cinq amis et que chacun d’entre nous a un hamster. Nous voulons mesurer la taille et le poids de chacun des animaux de compagnie. Il y a cinq rongeurs : Marcus, Billy, Becky, Rose and Cathie. Marcus est très rapide, donc il est difficile de le faire rester en place assez longtemps pour le peser. Billy aime bien sauter, donc il est difficile d’obtenir sa taille. Becky et Rose sont plutôt obéissantes, mais Cathie adore avoir l’air très grande et s’étire quand on veut la mesurer ; donc on ne peut pas être sûr de sa taille. Finalement, on a un jeu de données qui ressemble à ça :

NomTaille (cm)Poids (g)
Marcus18 
Billy 44
Becky1532.4
Rose17.237
Cathie 35.1

Il y a de nombreuses façons de gérer les valeurs manquantes qui sont plus ou moins complexes : certains remplacent simplement les valeurs manquantes par la valeur nulle équivalente, d’autres font des interpolations linéaires basiques d’après les valeurs proches, d’autres encore utilisent des “IAs génératives auxiliaires” qui sont entraînées à prédire les valeurs manquantes à partir des schémas que l’on peut extraire du jeu de données. Une solution ici serait de faire l’hypothèse qu’il y a une relation linéaire entre les deux colonnes et d’inférer la valeur des cellules vides à partir des données voisines. Si on regarde les données recueillies pour Becky et Rose (qui nous ont gentiment laissé mesurer les deux caractéristiques qui nous intéressent), on voit qu’il y a un facteur f ~= 2.15 entre les deux, tel que poids = f * taille.

NomTaille (cm)Poids (g)
Marcus1838.7
Billy20.544
Becky1532.4
Rose17.237
Cathie16.335.1

Mais faire cela est un peu “utopique” : nous avons eu de la chance parce que les deux items complets nous ont donné une valeur similaire pour notre facteur f, mais nous n’avons aucune garantie que cette relation linéaire existe bel et bien. Peut-être que c’étaient des exceptions : avec seulement 2 exemples, on ne peut absolument pas s’assurer d’un schéma global. De plus, il faut faire attention aux unités et aux transformations qui ont été appliquées aux données : si on avait un log() de notre colonne “poids”, cette linéarité supposée disparaîtrait complètement !

Quand on “remplit” des valeurs manquantes, il faut rester vigilant à ne pas involontairement ajouter, modifier ou enlever des patterns dans nos données.

Le paradoxe de Simpson’s ou “il y a mauvaise anguille sous roche”

Le paradoxe de Simpson est un phénomène statistique dans lequel certains schémas apparaissent dans des sous-groupes du jeu de données mais disparaissent quand on rassemble ces groupes. Un deuxième paradoxe moins souvent mentionné parle de la situation inverse : quand une tendance se montre dans le jeu de données complet mais pas ses sous-groupes. De toute façon, le paradoxe de Simpson montre qu’il y a des données dont l’analyse peut mener à une conclusion ou son contraire.

En général, il vient du fait qu’en plus de la/des cause(s) que l’on a identifiée(s) pour notre variable résultat, il existe aussi d’autres facteurs qui ont un effet sur ce résultat. En particulier, il y a des variables appelées “facteurs de confusion” (ou “variable confondante”) qui ont un impact à la fois sur la/les cause(s) et le résultat. Elles ajoutent au jeu de données des relations et des patterns dont nous n’avons pas forcément conscience et qui aboutissent parfois à des conclusions (apparemment) illogiques.

L’exemple du traitement des calculs rénaux est un cas d’école en la matière. En 1986, quatre chercheurs ont publié un article dans le British Medical Journal qui étudiait l’efficacité de deux types de traitements A et B sur les petits et les gros calculs rénaux. Les résultats sont assez surprenants :

  • quand on regarde les résultats pour les deux tailles de calculs (petit et gros) en même temps, le Traitement B est meilleur (avec un taux de réussite de 83% contre seulement 78% pour le Traitement A)
  • pourtant, quand on regarde d’abord les petits calculs et ensuite les gros séparément, le Traitement A est toujours meilleur que le Traitement B (pour les petits : A a un taux de réussite de 93%, B seulement 87% ; pour les gros : A a un taux de réussite de 73%, B seulement 69%)

Comment est-ce possible ? L’explication la plus probable est qu’il y a un facteur de confusion avec la gravité du cas traité. Dans ces expériences, pour les gros calculs, on a beaucoup plus utilisé le Traitement A que le Traitement B. Donc même si le Traitement A est intrinsèquement plus efficace que le Traitement B, il a eu à gérer les cas les plus difficiles et a donc plus échoué en moyenne. En vérité, cette variable confondante a un impact encore plus important sur le taux de réussite que le choix du traitement.

Note : le génial David Louapre de Science Etonnante a fait une très bonne vidéo YouTube (en français) sur le sujet centrée sur un exemple similaire.

Le problème ici est que ces facteurs que l’on ne prend pas en compte ont aussi un effet sur le/les cause(s) que l’on a en effet listée(s).

En d’autres termes, quand on a un jeu de données, il faut toujours se demander comment il a été collecté. Il peut être difficile d’identifier les facteurs de confusion, mais c’est nécessaire pour dresser un portrait exact de la situation à modéliser. En particulier, il faut savoir si on lit une étude prospective ou rétrospective ; autrement dit si les données ont été récupérées spécifiquement pour l’étude ou si elles existaient déjà auparavant et que les chercheurs les ont “juste” analysées sous un nouvel angle. Dans le premier cas, il est plus probable que les chercheurs ont fait attention et réfléchi aux variables confondantes. Dans le second, il faut être très méfiant car il pourrait y avoir beaucoup de facteurs de confusion cachés !

Il n’y en a juste pas assez !

Un problème très courant en science de la donnée, c’est de ne pas en avoir assez. Si on vous demande de travailler sur un modèle d’IA mais que vous n’avez pas d’entrées à traiter, vous allez probablement avoir des difficultés. Notamment, quand on travaille sur trop peu de données, on peut avoir affaire à différents problèmes :

  • si on a vraiment un nombre d’items très restreint, le modèle peut overfitter (“surapprendre”) ; cela signifie qu’en réalité, il va “apprendre par coeur” les réponses pour le jeu d’entraînement et ne sera donc capable de faire des prédictions que pour ces entrées qu’il connait déjà… ce qui n’est pas très utile ! Pour le reste des exemples (on l’appelle généralement le “jeu de test”), le modèle donnera simplement une prédiction au hasard parce qu’il n’a pas appris de comportement global dans les données mais a plutôt mémorisé les réponses exactes pour quelques items qu’il a rencontrés.
  • comme mentionné plus tôt, si le jeu de données est biaisé statistiquement, l’IA apprendra probablement des schémas biaisés et fera donc des prédictions biaisées. Cela peut causer du tort, en particulier quand l’algorithme est appliqué à un cas concret (je donnerai plus d’exemples la semaine prochaine, ou vous pouvez lire cet article de C. Baraniuk à propos du Harm Assessment Risk Tool, un algorithme d’IA utilisé par la police de Durham, au Nord-Est de l’Angleterre…)

Dans le prochain épisode

La semaine prochaine, nous verrons pourquoi les machines biaisées influent sur nos vies et pourquoi nous devons utiliser les IAs de manière responsable pour éviter de répéter des problèmes systémiques comme le racisme ou d’autres formes de discriminations.

Je parlerai aussi de quelques idées qui pourraient nous aider à améliorer les algorithmes en réduisant les biais ou au moins en faisant prendre conscience aux gens du fait qu’ils existent.

D’ici là, restez curieux et n’hésitez pas à me suivre si vous êtes intéressé !

REFERENCES / SOURCES
  1. Courrier International’s website: https://www.courrierinternational.com/
  2. Collins dictionary (online): https://www.collinsdictionary.com/dictionary/english
  3. Larousse dictionary (online): https://www.larousse.fr/portail/
  4. ScamDoc’s website: https://www.scamdoc.com/
  5. M. Sengupta, “AI To Empower Workforce And Drive Objectivity” (https://www.cxotoday.com/business-intelligence/ai-to-empower-workforce-and-drive-objectivity/), June 2019. [Online; last access 6-January-2020].
  6. Statistics How To, “Skewed Distribution” (https://www.statisticshowto.datasciencecentral.com/probability-and-statistics/skewed-distribution/). [Online; last access 6-January-2020].
  7. R.Vasudev, “How to deal with Skewed Dataset in Machine Learning?” (https://becominghuman.ai/how-to-deal-with-skewed-dataset-in-machine-learning-afd2928011cc), Aug. 2017. [Online; last access 6-January-2020].
  8. C. R. Charig, D. R. Webb, S. R. Payne and J. E. Wickham, “Comparison of treatment of renal calculi by open surgery, percutaneous nephrolithotomy, and extracorporeal shockwave lithotripsy” (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1339981/), Mar. 1986. [Online; last access 6-January-2020].
  9. D. Louapre, “Le paradoxe de Simpson – Science Etonnante #7” (https://www.youtube.com/watch?v=vs_Zzf_vL2I), Apr. 2015. [Online; last access 6-January-2020].
  10. C. Baraniuk, “Durham Police AI to help with custody decisions” (https://www.bbc.com/news/technology-39857645), May 2017. [Online; last access 6-January-2020].
  11. I. Wikimedia Foundation, “Ghost in the machine” (Popular culture section) (https://en.wikipedia.org/wiki/Ghost_in_the_machine#Popular_culture), Dec. 2019. [Online; last access 6-January-2020].
  12. I. Wikimedia Foundation, “Utilitarianism” (https://en.wikipedia.org/wiki/Utilitarianism), Dec. 2019. [Online; last access 6-January-2020].
  13. I. Wikimedia Foundation, “Simpson’s paradox” (https://en.wikipedia.org/wiki/Simpson%27s_paradox), Dec. 2019. [Online; last access 6-January-2020].
  14. I. Wikimedia Foundation, “Confounding” (https://en.wikipedia.org/wiki/Confounding), Dec. 2019. [Online; last access 6-January-2020].

Leave a Reply

Your email address will not be published. Required fields are marked *