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

Nom - Prénom :
> VALLIMAMOD Rayhan
>
Sujet :
> Improve dating apps matching algorithms using NLP

>[TOC]

## Cahier des charges

### Biais

Le but de notre algorithme est de trouver le profil parfait que recherche un utilisateur. Le plus important n'est pas de créer un modèle unique et binaire pour tous, mais un modèle qui prenne en considération les attentes de chacun, afin d'éviter d'avoir une tendance générale qui se dégage et qui risque de marginaliser des groupes d'individus pas toujours autant désiré par la tendance générale.

En effet, si notre application est utilisée partout dans le monde, mais que les qualifications prises en compte sont celles d'une région en particulier, alors les valeurs de telle région risquent d'entrer en conflit avec les attentes dans une autre région.

Par conséquent, si notre jeu de données n'est pas conçu avec suffisamment de rigueur, en particulier sur les points de différenciations que sont l'aspect physique, les biais suivant risquent d'apparaître :

>1. discrimination raciale
>2. discrimination de l'âge
>3. discrimination culturelle

De plus, l'algorithme risque de fournir un résultat tronqué et totalement hors-sujet par rapport aux attentes d'un utilisateur particulier.

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

>1. Sourçant nos données depuis un questionnaire que l'utilisateur ou l'utilisatrice va remplir, et qui ne portera sur aucune valeur attribuable à ce genre de qualification potentiellement discriminante. Les questions porteront sur des aspects de la personnalité, des besoins, des convictions et l'individu va classer ces points par ordre de préférence.
>2. S'assurant que nos données prennent en compte certaines combinaisons de mots clés pour immédiatement les rejeter comme "cherche une femme afro-américaine" *(Discrimination raciale envers les autres éthnies)*
>3. Concernant l'âge, il peut être compréhensible que pour chercher une personne avec qui partager une vie, un utilisateur ou une utilisatrice souhaite trouver un partenaire de la même génération. Par conséquent, nous demanderons à l'utilisateur d'entrer son âge et de cocher s'il ou elle souhaite trouver des profils de personnes de la même génération. Si non, alors nous excluons de l'algorithme, toute variable qui concernerait l'âge.
>4. Afin de favoriser la probabilité d'un match, il est nécessaire de proposer à l'individu quel genre d'orientation sexuelle ou confession religieuse il préfère, en entrant le mot-clé en question, pas de catégorie à choisir, nous ne mettons pas cela en place pour rester neutre, et ne pas tronquer les résultats proposés en classifiant nous même les ethnies ou autre. Nous laissons libre arbitre à l'utilisateur ou utilisatrice d'afficher ses envies sans que nous interférions. En fonction du mot clé entré par l'utilisateur ou l'utilisatrice, il sera recherché sur divers profils sans pour autant en faire un élément éliminatoire, mais il sera précisé que le mot-clé en question n'a pas été trouvé dans le questionnaire ou la bio des profils proposés.

### Overfitting

Nous allons nous assurer que notre modèle ne sera pas dans une situation de sur-apprentissage (overfit) en :
> Ajoutant une fonctionnalité de personnalisation et de "Gamification".
> Le but ici est de faire du reverse engineering. On va utiliser l'algorithme à notre avantage en choissisant nos questions plutôt que de le laisser faire des suggestions via un pattern unique.

1. Personnalisation
> En effet, nous allons créer un formulaire avec un set identique de questions pour tous, disons par exemple 100 questions rapides.
> Sur ces 100 questions, l'utilisateur va choisir de répondre à 50 d'entre elles au maximum, aucune n'est obligatoire, il faut juste répondre à au moins 30 d'entre elles jusqu'à 50. 30 pour que l'échantillon d'information soit assez développé, et 50 pour s'assurer d'un nombre suffisant de combinaison pour ne pas que l'algorithme s'habitue.
> Ainsi, un individu va s'exprimer en développant ce qu'il attend ou ne veut absolument pas, que ce soit l'idée d'avoir des enfants, d'avoir un animal de compagnie, que ce soit de dire si la personne préfère vivre en ville ou en-dehors des villes etc.

2. Gamification
> Ensuite, nous demanderons aux utilisateurs/trices de classer ces questions par ordre de préférence, en sous-catégories, de la catégorie 1 "Top-tier" ou chaque élément présent dans un profil sera valorisé 100 points, en passant à la catégorie 2, les "Second-tier" où les éléments seront valorisés seulement 20 points.
Ainsi, un profil sera jugé convenable en tant que résultat s'il combine un score supérieur à 800 points, ou en fonction du barème que l'utilisateur chosira, s'il est très exigeant, il prendre un curseur à 1500 points, si l'utilisateur veut un maximum de profils possible, il réduira à 500 points.

Ainsi, l'algorithme ne pourra pas en sur-apprentissage car il se retrouvera face à un nombre trop élevé de combinaisons possibles pour n'en utiliser que quelques unes.

### Usages détournés

>Nous devons nous rappeler que notre application pourrait être utilisée de façon malveillante par des scammeurs pour sous-tirer de l'argent ou mettre en danger la vie d'autrui.

Par conséquent, nous allons bannir les profils qui spam les utilisateurs/trices avec un copier-coller d'un texte, ou biens si on perçoit la volonté de se faire envoyer de l'argent pour voir la personne.

### Fuite de données

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 les informations sur les utilisateurs/trices soient dévoilées en public, et que les malfaiteurs fassent du rançonnage et du blackmail.

De ce fait, nous allons masquer de notre propre base de données les noms des utilisateurs, et n'utiliser que des clés publiques et clés privées via la cryptographie pour anonymiser et donc, ne pas permettre l'identification de nos utilisateurs/trices par des tiers aux intentions douteuses. Ainsi, nous ne connaissons pas l'identité exacte de nos individus, il n'y aucun KYC (Know Your Customer) imposé par la loi, nous ne souhaitons pas interférer avec l'intimité de nos utilisateurs, et donc nous éviter de les juger. Cependant nous continuerons de traquer les faux profils, en cherchant à voir s'ils restent inactifs trop longtemps (des mois), s'ils spamment des utilisateurs etc.

De ce fait, notre modèle se veut closed source.
En effet, en raison d'un soucis de viabilité économique et de lutte contre la concurrence, nous n'avons pas à dévoiler notre algorithme.

De plus, l'idée ici n'est pas de dégager une tendance générale qui pourrait aider une cause comme la lutte contre le cancer, mais de définir les préférences d'un individu et le faire matcher avec des profils qu'il souhaite rencontrer, en fonction de ses critères de sélection.

### Piratage

> Si une personne trouvait un moyen de "tromper" notre modèle et modifier son comportement à volonté, le risque serait que l'algorithme devienne biaisé.

Pour éviter ce genre de désagrément, nous allons nous reposer sur une technologie de Blockchain, c'est à dire que pour qu'un individu malintentionné prenne contrôle de l'algorithme et cherche à le tromper, il devra prendre le contrôle de tous les téléphones des utilisateurs et fasse accepter les modifications qu'il apporte en un temps record, avant que le bloc ne soit construit (en moins de 1h par exemple).

Par conséquent, l'inconvénient de cette mesure infailliblle en terme de protection (hormis si le malfaiteur fais une attaque 51% sur tous les appareils des utilisateurs, mais cela pourrait être trop coûteux à réaliser, et pas réalisable par une seule personne), c'est que chaque modification de l'algorithme est beaucoup plus longue, elle devra être approuvée par la majorité des utilisateurs pour réaliser une "soft fork", c'est à dire une modification mineure, qui sera expliquée dans l'idée, mais pas dévoilée dans le code pour le garder secret.