Dream11 utilise un modèle Llama 3 affiné pour rapprocher des noms lors des vérifications d'identité

Le problème

Dream11 est une plateforme de sports fantasy comptant plus de 250 millions d'utilisateurs. Avant de pouvoir jouer, l'utilisateur voit ses pièces d'identité contrôlées, ce qui revient à décider si des noms figurant sur des documents différents désignent la même personne. En Inde, une même personne peut apparaître sous le nom « Shubham Kumar Singh » sur un document et « ShubhamKumarSingh » sur une facture numérisée. Les noms sont écrits dans plusieurs alphabets, orthographiés de façons différentes et saisis avec des fautes de frappe. Auparavant, un rapprochement fondé sur des règles envoyait les cas ambigus à un prestataire tiers pour un examen manuel.

Les deux types d'erreur coûtent de l'argent. Une correspondance manquée empêche un utilisateur légitime de finaliser sa vérification. Une fausse correspondance peut permettre à un fraudeur de gérer plusieurs comptes.

Ce qu'ils ont construit

Les auteurs de Dream Sports ont entraîné une version du modèle Llama 3 8B à poids ouverts de Meta pour répondre à une seule question : ces deux noms désignent-ils la même personne ? Le modèle répond « Yes » ou « No ». L'entreprise appelle cette méthode Structure-Guided Entity Resolution.

Le modèle fonctionne au sein du circuit de vérification d'identité de Dream11. Selon les auteurs, il prend des décisions de correspondance et de non-correspondance entièrement automatisées, de sorte que la file d'examen manuel pour ces cas a disparu.

Comment ils s'y sont pris

L'entraînement s'est déroulé en deux étapes. Le modèle a d'abord appris à découper un nom en prénom, deuxième nom et nom de famille, à partir d'environ 10 000 noms indiens annotés à la main. Il a ensuite appris la décision de rapprochement à partir de paires de noms annotées. L'équipe est partie de 20 000 paires annotées issues d'opérations passées et les a portées à plus de 50 000 en inversant l'ordre des paires, en mélangeant les parties de noms et en supprimant les espaces.

Le jeu de test était distinct : 50 000 paires réelles issues de données de production historiques, annotées par l'équipe interne des opérations de risque. L'entraînement a tourné sur un seul GPU NVIDIA A100. En production, le modèle s'exécute sur trois GPU NVIDIA L4, avec le logiciel de serving vLLM sur Kubernetes.

Résultats

En production, les auteurs affirment que la suppression des contrôles manuels du prestataire fait économiser plus de 500 000 $ par an, et que le système traite jusqu'à 10 000 requêtes par minute avec une latence P99 de 120 millisecondes, ce qui compte lors des grands événements sportifs où les inscriptions explosent.

Hors ligne, sur un jeu de test distinct de paires historiques, le modèle a atteint une précision de 99,02 % et un F1 de 0,994. Les auteurs le comparent à d'autres approches sur les mêmes données : GPT-4o sollicité avec des exemples a obtenu une précision de 85,4 %, et le même modèle Llama entraîné en une seule étape avec des données supplémentaires, 95,7 %.

Ce qui a mal tourné

Les auteurs signalent deux points faibles persistants. Les noms qui sonnent de façon proche mais s'écrivent différemment, comme « Saurabh » et « Sorab », sont parfois jugés différents. Les noms cumulant plusieurs problèmes à la fois, comme des espaces manquants, un ordre inversé et des erreurs de numérisation, restent aussi difficiles. L'article indique que les rares correspondances manquées (moins de 1 % des utilisateurs) sont réglées par le service client.

Ce qu'il faut retenir

Commencez par une tâche dont la réponse est clairement oui ou non et qui dispose d'un historique de décisions annotées. Mesurez le modèle sur un jeu de test construit à partir de vos propres cas passés et comparez-le à un modèle généraliste sur le même jeu. Conservez une solution de repli humaine pour la petite part d'erreurs.