# Processing with AI
## Partie 2: 👩‍⚖️ Ethics of AI

Nom - Prénom :
> Axel PARDIN
>
Sujet :
> 💕 Improve dating apps matching algorithms using NLP

>[TOC]

## Cahier des charges

### Biais

Si notre jeu de données n'est pas conçu avec suffisamment de rigueur, les biais suivant risquent d'apparaître :

>1. Biais socio-économique. En effet, si les données sont par exemple basées sur un français soutenu, les personnes issues de milieux défavorisés qui parlent un langage plus familier ou un moins bon français ne bénéficieront pas des mêmes chances sur l'application que ceux issus de classes supérieures qui parleront un français plus correct ou soutenu qui sera quant à lui reconnu de manière efficace par l'application. (mauvais orthographe, mots mal orthographiés, mots très familiers non reconnus mais mots soutenus reconnus, français famillier "j'suis", "j'veux"... )
>2. Biais d'âge. Les jeunes s'approprient tous les jours de nouveaux mots. La langue est en perpetuelle évolution et cela passe par les anglicissimes ou tous les autres mots qui apparaissent dans les cours d'école ou chez les jeunes. Si l'application ne prend pas en compte ce paramètre, le langage utilisé par les jeunes ne sera pas reconnu et ils pourront moins profiter de l'application que les personnes un peu plus âgées qui utilisent un langage plus classique, plus élémentaire et traditionnel, et qui est quant à lui reconnu par l'application. L'application se doit de prendre en compte les mots plus récents qui font parti du langage courant des jeunes ("date", "flirt", "binge-watcher", "seum", "chiller", "pioncer"...).

>3. Biais racial. En Amérique du Nord, les Afros-américains ont un langage bien à eux appelé African-American Vernacular English (ou AAVE, aussi appelé Ebonics, ou African-American English/AEE). Cet anglais qui se démarque de l'anglais classique utilise des variations gramaticales voire parfois un vocabulaire particulier ou encore un bon lot d'expressions propres aux afros-américains. (Ex: "Sis", "issa" pour "it's a", "gon" pour "gonna", "ain't", " "spill the tea", "Yas", "Chile"... très utilisés aux États-Unis et au Canada (et de plus en plus au Royaume-Uni) par la communauté noire anglophone.) Si l'application n'est pas en mesure de comprendre ou d'analyser ces termes, les personnes noires anglophones pourraient être lésées vis à vis de leurs compères blancs sur l'application. Il est important de pouvoir potentiellement couvrir tous les usages et les variations d'une même langue qui est parlée différemment par les différentes communautés d'un même pays.
>(J'ai choisi ici d'illustrer ce biais avec un cas anglophone même si j'utilisais des exemples en français pour mes exemples des deux autres biais car le cas de l'anglais AAVE en Amérique du Nord m'a le semblé plus éloquent pour illustrer le potentiel biais racial basé sur le langage auquel j'ai pensé)

>4. Biais géographique. Certains mots, expressions sont régionales. Cela peut créer une inégalité géographique si par exemple on se base sur le français parlé à Paris. Cepui-ci est en effet différent de celui parlé à Marseille. Il faut prendre en compte ces variations, ce vocabulaires distinct etc pour ne pas créer une disparité géographique en terme d'efficacité de l'application. (Ex: "Fraté", "Chocolatine", "Gavé" ou encore "Cher" à Lyon alors qu'à Paris on dit "Grave" etc)

Nous allons donc nous assurer que notre modèle n'est pas biaisé en :

>1. S'assurant que nos données prennent en compte les fautes d'orthographe, les vocabulaire erroné, les usages de la langues plus familliers et les constructions gramaticales propres aux catégories sociales les plus populaires.

>2. Sourçant nos données depuis des dictionnaires français reconnus mais aussi des bases de données ou dictionnaires en ligne d'argot. Utiliser la contribution de jeunes pour incorporer aussi leur nouveaux usages de la langue ou les perpetuels nouveaux mots qu'ils utilisent.
>
>3. (&4). Garantissant que les sources utilisées couvrent bien tous les usages de la langue utilisé par les différentes minorités ethniques ou même les différentes régions d'un même pays. Il faut veiller à avoir de la diversité dans les bases de données et supports utilisés pour pouvoir couvrir la langue dans toute son ampleur. Utiliser des bases de données et sources diverses même si on se concentre une seule et même langue (par exemple sur le AAVE en amérique du Nord, peut-être aussi le Spanglish etc etc) pour éviter de n'être basé que sur une seule manière de parler qui nous semble linéaire mais varie pourtant entre les communautés de minorités ethniques ou entre les régions (ex: ne pas se base sur seulement le Français parlé à Paris qui nous semble unique, mais aussi pensé au Français parlé à Lyon qui a quelques variations). En gros : ne pas oublier que même seule langue peut-être plurielle au sein d'un même pays.

### Overfitting

Nous allons nous assurer que notre modèle ne sera pas dans une situation de sur-apprentissage (overfit) en :
> Vérifiant la précision de notre modèle sur par exemple un réseau social (un réseau social basé sur le texte, comme Twitter, et pas basé sur les photos comme Instagram par exemple, puisque l'on veut analyser du texte/de l'écrit en français) qui n'est pas utilisé par un bassin homogène de la population française. Il faut s'assurer que les personnes utilisant ce réseau sont de tous âges, de toutes origines ethniques, de tous milieux sociaux et de Partout en France pour pouvoir le prendre pour tester notre modèle.

### Usages détournés

>Nous devons nous rappeler que notre application pourrait être utilisée de façon malveillante par les entreprises pour ciblier les individus en fonction de leurs centres d'intérêt et leurs goûts (ou tout simplement leur manière de parler), qu'ils partageraient sur leur profil ou en DM par exemple, et leur faire de la publicité ciblée.

### Fuite de données
***Choisissez** la proposition qui s'applique le mieux selon vous concernant votre **jeu de données**:*

> **🔐 Closed source:** Dans un scénario catastrophe, au cours duquel l'entièreté de notre jeu de données d'entrainement serait volé ou récupéré à partir de notre modèle, le risque serait que des données et informations qui sont échangées en DM soient partagées. En effet, l'application analyse, en plus des textes du profil, les échanges écrits en DM entre les individus. Ces échanges sont donc privés et non affichés publiquement et nous nous devons alors de les maintenir privés par soucis de protection et de respect des utilisateurs. Ces informations échangées en DM que l'on va avoir dans notre jeu de données peuvent constituer des donées personnelles ou des informations intimes.

### Piratage

> Si une personne trouvait un moyen de "tromper" notre modèle et modifier son comportement à volonté, le risque serait que la personne match sur l'application avec qui elle veut même si elles n'ont à priori rien en commun. Cela pourrait par exemple favoriser le harcèlement ou tout simplement diminuer la qualité du service proclamée par l'application.