Hello,
Cela faisait un petit temps que j’avais envie de parler de l’entity resolution. Je ne savais pas trop comment présenter et donc je me suis limiter à une vue très hélicoptère du problème.
Bonne journée !
Salut,
Je commence à lire ton article, ayant une activité professionnelle touchant à la BI, c’est un sujet qui m’intéresse. Notons que j’ai fait une proposition pour des tags pour ton article, dis-moi s’ils te vont.
Sinon, globalement en arrivant sur ton article, j’ai l’impression qu’il est arride. C’est pas une mauvaise chose en soi, mais ça fait peur. Je pense, que c’est principalement dû à deux choses:
Je pense que l’introduction gagnerait à être totalement revue :
J’entends par "problème d’entrée" une mise en situation où on comprend qui peut être intéressé et quel poil à grater il va subir en premier lieu.
Par exemple, sur un sujet de gouvernance des données, j’avais vu un post linked-in y’a pas longtemps sur les problématiques des notations de pays. Ce qui faisait qu’on a par exemple trois ensemble de données à joindre, et dans l’un d’eux on a « united states », dans l’autre on a « USA », dans le troisième on a « U.S. », dans un autre « United States » (avec les majuscules)…
Juste avec cette situation là, la personne montrait comment à partir d’une liste d’alias il arrivait à faire un modèle qui envoie le pâté. Et on entrait ensuite dans des questions plus velues style performance etc.
Je pense qu’on peut s’inspirer de ce genre de forme d’article pour accueillir le lecteur, le prendre au jeu avec nous puis l’emmener dans un sujet qui grimpe petit à petit.
Bonjour Atragis,
Tout d’abord, merci pour ta réponse, c’est extrêmement pertinent.
J’ai revu tout l’article pour:
Gawa
Bonjour les agrumes !
La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :
Merci d’avance pour vos commentaires.
Les améliorations sont notables.
En relisant encore ton article (qui est intéressant, c’est indéniable), je me dis qu’il y a un point à revoir c’est celui-ci:
L’entity resolution se compose généralement de plusieurs grandes étapes classiques mais qui peuvent être optionnelles ou répétées aux besoins, avec des paramètres ou critères qui diffèrent. On retrouve:
Prétraitement des données: étape plus que primordiale, elle consiste au nettoyage et à la standardisation des données en entrée afin d’assurer une certaine consistance et compatibilité entre des données qui peuvent provenir de sources souvent très hétérogènes en qualité. Le but étant évidemment de fournir des données ayant un maximum d’information exploitable afin d’aider les différentes étapes qui suivront; cela se traduit par la suppression de données invalides, la correction des erreurs, la gestion des valeurs manquantes ou mal classifiées. On fait généralement la distinction entre:
- Le cleansing: le nettoyage des données consiste à la détection et à la rectification des erreurs à proprement parler (comme des doublons ou des erreurs typographiques), ou la gestion des données qui n’ont pas de valeurs sémantiques: n.a. pour 'not available' ou encore la gestion des problèmes de consistances (comme un mauvais code postal associé à une ville).
- La normalization: généralement liée à des aspects plus techniques comme l’encodage en UTF-8, la suppression des 'espaces’ en trop, … Cela s’accompagne le plus souvent par la décomposition en unités atomiques d’information telle que la scission d’une adresse en rue, ville, code postal, …
- La standardization: le but est d’obtenir une représentation commune d’une donnée, peu importe sa forme originelle, par exemple: numéro de téléphone en +XXX, code postal luxembourgeois de type L-XXXX ou n’avoir que des 'avenue' et non 'av.’, … Ou encore, traiter des problèmes de translittération, traduction ou de champs multi-langues. L’important est de résoudre toutes les variations que l’on peut retrouver dans la représentation de la donnée afin de ne proposer qu’une vue 'unique’.
Sélection: pour démarrer le processus d’entity resolution, il faut bien commencer par prendre un record et sélectionner tous ceux qui lui sont affiliés. Toute l’astuce réside dans la définition du concept de similarité/dissimilarité afin de retrouver tous les records qui pourraient être des candidats à cette résolution, à ce cluster. Il y a tout un spectre de puissance d’identification, des éléments qui sont fortement discriminants: un code de sécurité social, un numéro de série ou un numéro de passeport, d’autres qui ne prennent leur force que par leur combinaison: même date de naissance, prénom et nom de famille et enfin ceux qui n’ont que très peu de valeur: numéro de téléphone de la société pour laquelle la personne travaille. Une grande partie de la subtilité réside également dans le contexte dans lequel ces informations apparaissent: un nom de famille peut être très commun (M. Leclercq) en France, mais très peu présent au Japon.
Blocking: c’est une étape complémentaire au processus de sélection, elle consiste à diviser le jeu de données (éventuellement sélectionnés) en plus petits ensembles sur base de critères ou attributs. Cette étape fait surtout sens lorsque l’on a des indications additionnelles sur ce que l’on cherche (code d’activité d’une entreprise ou société pour laquelle une personne travaille). Et vise principalement à réduire la complexité en réduisant l’espace de recherche et déjà trouver des premiers ensembles. Si un nombre insuffisant de résultats ressort de cette opération, on peut revenir à l’étape de sélection en élargissant le spectre et ainsi faire un ping-pong.
Similarité ou matching: une fois que des records potentiels sont identifiés, on peut chercher à identifier à quel point des éléments sont similaires ou dissimilaires entre eux. De nouveau, toute une couche d’arbitraire s’opère à cette étape, tant sur la comparaison des champs en eux-même:
- deux dates de naissance sont similaires si on ne possède que l’année ? Quid des formats américains YYYY/MM/DD vs civilisés DD/MM/YYY ? des chaînes de caractères, quelles métriques employer ? Levenshtein, les indels, Jaro–Winkler ?
- deux adresses peuvent être fort différents mais référencer la 'même' chose (p.o. box vs adresse 'physique’). que la combinaison de ces différentes métriques en un score 'unique’. Si, dans un cas, quatre champs sont identiques, mais qu’ils ne diffèrent que par un seul alors que dans un autre, on ne possède que l’information sur un champ 'fort’.
Évaluation et validation: une fois que les records qui forment un cluster ont été identifiés, est-ce que certains éléments ne peuvent pas être regroupés pour une raison extérieure ? Approche prudente des identificateurs forts (numéro de passeport) afin d’éviter de se retrouver avec deux numéros de passeport pour un même individu ou dissimilarité trop forte au niveau des âges ou adresses. Si le cluster est dégénéré et contient un nombre anormalement élevé de records, est-il pertinent ? Ou alors selon des critères externes, si on suppose que l’entité est ainsi résolue, est-ce que l’information est cohérente ? Ex: Jeff Bezos est un nom assez rare mais si je vois qu’un record est lié à un professeur du secondaire et l’autre au patron d’Amazon, peu de chances qu’il s’agit du même individu en pratique. C’est une étape qui peut être plus ou moins manuelle et nécessite une expertise très forte de la part d’un individu afin d’affirmer ou non la pertinence de la résolution.
Génération des résultats: finalement, on veut récupérer l’ensemble des entités qui ont été résolues, afin de pouvoir être exploités à d’autres fins et ainsi proposer une vue holistique des entités au travers des différentes sources de données. Il peut également être important d’enregistrer les raisons qui ont mené à la création de cluster en particulier à des fins d’audit.
Ce listing est super important et donne réellement le fonctionnement du concept que tu présentes. Cependant l’aspect "aplat de texte" le rend relativement peu exploitable en soi.
Je comprends qu’il est dur de trouver le bon curseur, mais je pense qu’il y a deux choses que tu peux faire :
Prenons un exemple avec la première étape "Prétraitement", on pourrait la reformuler sur un modèle de ce type:
- Prétraitement des données : C’est l’étape qui a pour but de faire en sorte qu’on ne traite que les données adéquates et qu’elles sont toutes dans le même format
- Le cleansing (Nettoyage) permet de retirer des erreurs dans les ensembles de données ainsi que les doublons. On reviendra plus bas sur les défis de cette étape.
- La normalisation se concentre sur l’aspect technique telle que les encodage, les espaces en fin de mot, la capitalisation… Pour normaliser on va souvent découper chaque élément en petit élément simple à traiter, par exemple une adresse sera coupée en numéro/rue/code postal/ville etc.
- La standardisation va s’assurer que la manière de représenter une entitée est uniforme dans tous nos ensembles de données. Pour l’adresse, par exemple on s’assurera d’avoir toujours "avenue" plutôt que "av."
Bonjour les agrumes !
La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :
Merci d’avance pour vos commentaires.
Bonjour,
La bêta du contenu « Résolution d’entité - Entity resolution » a été désactivée.
