Ability — Résolution d'Entités
Ability transforme des enregistrements désordonnés et chevauchants en un ensemble d'entités propres et traçables. Elle fonctionne en cinq étapes et ne détruit jamais les données sources : chaque enregistrement fusionné conserve les liens vers les originaux dont il provient.
Le record linkage est la mathématique de la correspondance (l'enregistrement A correspond-il à l'enregistrement B ?). La résolution d'entités est l'ensemble du travail : appariement, regroupement des correspondances en entités, score de confiance, et conservation de la provenance. Faites l'ensemble du travail.
Avant de commencer : la vérification d'alignement
Les demandes imprécises sont normales. Lisez les fautes de frappe et les abréviations pour comprendre l'intention et ne commentez jamais l'orthographe. Avant un travail réel, énoncez trois courtes lignes afin que l'utilisateur puisse corriger le cap à moindre coût :
DIT : <ce que l'utilisateur a littéralement demandé>
INFÉRÉ : <le problème réel à résoudre>
SUPPOSÉ : <la principale hypothèse que vous faites — posez au plus une question si vraiment bloqué>
Ignorez cela pour les questions rapides ; utilisez-le lorsque vous êtes sur le point de traiter des données ou de concevoir un pipeline.
Le pipeline en 5 étapes
1. Profilage
Examinez chaque champ avant toute correspondance. Rapportez par champ : taux de nullité, nombre de valeurs distinctes, valeurs principales, motifs de format et problèmes d'encodage (UTF-8 vs Latin-1). Le profilage vous indique quels champs sont suffisamment fiables pour servir de base à la correspondance et quelles valeurs sont si courantes (par exemple « Dupont », « 123 rue Principale ») que leur accord ne signifie pas grand-chose.
2. Standardisation
Normalisez avant de comparer, sinon les scores seront erronés : minuscules, suppression de la ponctuation, expansion des abréviations (Ave → Avenue), segmentation des noms en parties, normalisation des numéros de téléphone en chiffres, normalisation des suffixes d'entreprise (SARL, EURL, SAS) et standardisation des adresses (vérification postale lorsque disponible).
Les données réelles désordonnées nécessitent presque toujours aussi :
- Table de surnoms (Bob/Robert, Béatrice/Béa, Alex/Alexandre, Tricia/Patricia) et les initiales (« J. ») traitées comme compatibles avec tout nom commençant par cette lettre.
- Champs de nom inversés — comparez également prénom↔nom de famille inversés.
- Dates ambiguës — « 04/05/1990 » peut être le 4 mai ou le 5 avril. Conservez les deux lectures et traitez l'échange jour/mois comme une correspondance partielle, pas un conflit.
3. Blocage
Comparer chaque enregistrement à tous les autres est en N² — 1 million d'enregistrements signifie ~500 milliards de paires. Le blocage ne compare que les enregistrements qui partagent une clé. Utilisez plusieurs passes avec des clés différentes afin qu'une faute de frappe dans un champ ne cache pas une vraie correspondance :
- Nom phonétique (Soundex / NYSIIS) + année de naissance
- Préfixe du code postal + numéro de rue
- 4 derniers chiffres d'un identifiant + code postal
- Téléphone ou e-mail
- Pour les données textuelles denses : MinHash LSH sur des ensembles de jetons, ou embeddings + recherche par plus proche voisin (FAISS/HNSW)
Mesurez-le :
- Taux de réduction = 1 − (paires comparées ÷ nombre total de paires possibles) — visez > 99 %
- Complétude des paires = vraies correspondances qui tombent dans un bloc ÷ toutes les vraies correspondances — visez ≥ 95 %
4. Score — la cascade en 3 étapes
Exécutez d'abord les vérifications peu coûteuses et certaines, et les coûteuses uniquement là où nécessaire.
- Déterministe : un identifiant unique fiable correspond (numéro national, numéro fiscal, numéro de compte, e-mail vérifié) → correspondance.
- Flou : pas de correspondance d'identifiant → comparez les champs avec l'algorithme approprié par champ (voir tableau) et combinez-les avec les poids de Fellegi-Sunter.
- Apprentissage automatique / revue humaine : toujours ambigu → un classifieur (par exemple régression logistique sur les caractéristiques de similarité des champs) si des données étiquetées existent, sinon orientez vers une file d'attente de revue humaine.
| Type de champ | Utilisation |
|---|---|
| Noms de personnes | Jaro-Winkler (récompense les préfixes correspondants), plus listes de surnoms |
| Noms d'entreprises | Ratio de tri des jetons (l'ordre des mots n'a pas d'importance) après nettoyage des suffixes |
| Adresses | Levenshtein après standardisation ; les numéros de rue et d'unité doivent correspondre exactement |
| ID, téléphone, e-mail | Exact après normalisation |
| Texte long | Jaccard / cosinus sur les jetons |
Fellegi-Sunter en bref — pour chaque champ k :
- m = P(le champ concorde | les enregistrements correspondent vraiment) — fiabilité du champ
- u = P(le champ concorde | les enregistrements ne correspondent pas) — fréquence d'accord par hasard
- poids d'accord = log2(m/u) ; poids de désaccord = log2((1−m)/(1−u))
- score total = somme des poids pour le résultat de chaque champ
Les valeurs rares apportent plus de preuves : être d'accord sur « Dupont » (u minuscule) est bien plus fort que d'être d'accord sur « Martin ». Utilisez u spécifique à la valeur lorsque c'est possible. En pratique : un nom complet rare plus une date de naissance exacte est une preuve solide même si l'adresse, le téléphone et l'e-mail ont tous changé (la personne a déménagé) ; un nom commun plus une date de naissance ne l'est pas.
Pour scorer les paires, exécutez scripts/fs_score.py au lieu de calculer à la main — il applique
les poids, convertit le score en probabilité de correspondance compte tenu des probabilités a priori, et attribue
la bande de décision. Exécutez python scripts/fs_score.py --help pour l'utilisation.
Les formules complètes, l'exemple détaillé et l'estimation de m/u (y compris EM) se trouvent dans
references/methods.md ; lisez-le lorsque l'utilisateur souhaite les mathématiques ou doit régler les poids.
Deux pièges que le seul score ne détectera pas :
- Ménages. Les jumeaux, conjoints et colocataires partagent le nom de famille, l'adresse et parfois la date de naissance, donc leur score peut ressembler à une correspondance quasi certaine. Si les prénoms diffèrent (et ne sont pas des surnoms l'un de l'autre) et que les contacts personnels (e-mail, téléphone) sont en conflit, gardez-les séparés ou envoyez-les en revue — quoi que dise le score.
- Valeurs factices. Les dates comme 2000-01-01 ou 1900-01-01, les téléphones comme 555-0000 et les e-mails comme [email protected] sont des remplissages, pas des preuves. Le profilage (étape 1) devrait signaler les valeurs qui se répètent de manière suspecte ; ne leur donnez aucun poids.
Bandes de décision (ajustez sur données étiquetées ; voici des points de départ) :
| Probabilité de correspondance | Action |
|---|---|
| ≥ 0.95 | Correspondance automatique |
| 0.80 – 0.94 | File d'attente de revue humaine |
| < 0.80 | Non-correspondance |
5. Fusion — règle de survie et enregistrement doré
Regroupez les paires correspondantes en entités (composantes connexes / clustering par graphe — faites attention
aux chaînes où AB et BC mais A≁C ; séparez-les pour révision). Pour chaque entité, construisez
un enregistrement doré en choisissant chaque champ selon une règle énoncée :
- Plus récent (horodatage le plus récent) — pour les adresses, téléphone
- Plus complet (non nul, le plus long) — pour les noms, descriptions
- Source de confiance (classement du système) — pour les identifiants, noms légaux
Ne jamais écraser ni supprimer les originaux. Stockez : ID de l'enregistrement doré → liste des IDs des enregistrements sources, la règle qui a choisi chaque champ, et le score de correspondance qui les a joints.
Validation des résultats
Demandez, ou aidez à construire, un petit ensemble étiqueté (quelques centaines de paires marquées correspondance/non-correspondance). Rapportez la précision, le rappel et le F1 sur celui-ci, plus le taux de réduction et la complétude des paires pour le blocage. Les seuils sans validation sont des suppositions — dites-le lorsqu'il n'y a pas d'ensemble étiqueté.
Étiquettes de preuve
Lorsque vous revendiquez un résultat, dites comment vous le savez :
- [DOC] — à partir d'une spécification ou documentation, non exécuté
- [RAN] — exécuté dans cette session
- [PASS] — vérifié contre des données étiquetées/de test
Revue de point de contrôle
Sur les longs travaux (environ toutes les cinq tours de travail, lorsque l'utilisateur signale une erreur, ou lorsqu'il tape « checkpoint » ou « rêve ») : mettez en pause le travail du projet et passez brièvement en revue vos propres tours récents. Listez chaque erreur ou dérive par rapport aux contraintes énoncées par l'utilisateur, sa cause et le correctif que vous appliquerez à l'avenir. Reprenez ensuite. Gardez la revue en dehors des livrables — elle est pour la conversation, pas pour les données ou documents de l'utilisateur.
Sortie pour un travail de correspondance
Terminez un travail terminé par :
ENTITÉS : <enregistrements d'entrée> → <entités résolues> (<doublons trouvés>)
BANDES : auto <n> | revue <n> | non-correspondance <n>
QUALITÉ : précision <x> | rappel <x> | F1 <x> (ou « non validé — pas d'ensemble étiqueté »)
FICHIERS : <où les enregistrements dorés, le crosswalk et la file de revue ont été sauvegardés>
Vie privée
La correspondance implique souvent des données personnelles. Traitez-les localement, ne collez pas d'identifiants
dans des URL ou des services externes, et lors de la liaison entre organisations, suggérez un
appariement préservant la vie privée (encodage Bloom-filter des noms, comparés avec la similarité Dice) —
détails dans references/methods.md.