L'article de Vedant Jumle sur son système de récupération de noms entre scripts, c'est le genre de petit projet de recherche focalisé qui fait une vraie différence pratique. Le problème est mondain pis important : quand « Владимир Путин » est dans une source cyrillique pis que la liste de surveillance est indexée en latin, les matcheurs flous classiques comme Levenshtein, Double Metaphone pis BM25 échouent gravement. L'écart de performance entre la récupération Latin-vers-Latin pis Latin-vers-non-Latin sur ces baselines va de 0,88 à 0,94 — ce qui veut dire que le système qui signale un match dans le même script manque presque complètement le nom équivalent à travers les scripts. Le filtrage des sanctions, les bases de données d'immigration, le matching de dossiers d'hôpital pis les pipelines de conformité financière vivent avec ce mode d'échec tous les jours.

Le modèle est petit pis l'architecture est conventionnelle : un encodeur transformer de 4 millions de paramètres avec six couches pis 256 dimensions cachées, entraîné avec une perte contrastive InfoNCE pis du mining de négatifs durs ANCE. Le truc, c'est l'entrée. Au lieu de tokenisation par sous-mots, qui est fragile à travers les systèmes d'écriture avec des structures statistiques très différentes, l'encodeur lit des octets UTF-8 bruts — un alphabet de 256 symboles qui gère chaque script nativement. Y a pas de pré-traitement spécifique au script pis pas de tokeniseur séparé qui doit être réentraîné quand t'ajoutes l'hébreu ou le hindi. Les embeddings sont normalisés unitaires donc la récupération est de la similarité cosinus, ce qui veut dire que le déploiement est juste un index ANN sur des vecteurs pré-calculés. Le système entier tient dans des budgets de mémoire que les matcheurs phonétiques classiques tiennent aussi.

La construction des données d'entraînement, c'est ce qui rend le résultat crédible. Jumle a commencé avec 119 040 entités de personnes échantillonnées de Wikidata, les a fait passer dans un pipeline de paires synthétiques en quatre étapes (variantes latines phonétiques de Llama-3.1-8B, transliterations entre scripts dans huit scripts de Qwen3-30B), pis a fusionné avec les paires de noms vérité-terrain de Wikidata pour obtenir 4,67 millions de paires positives. Le chiffre vedette, c'est 0,775 MRR pis 0,897 R@10 au total, pis surtout l'écart Latin-vers-non-Latin s'effondre à 0,096 — un ordre de grandeur mieux que les baselines classiques. L'arabe, le russe pis l'hébreu passent tous 0,95 R@10. Le chinois (0,666) pis le coréen (0,728) traînent, ce que l'article attribue correctement à une vraie ambiguïté de romanisation plutôt qu'à un échec du modèle : y a plusieurs romanisations défendables de n'importe quel nom Hanzi ou Hangul donné, pis la vérité-terrain est plus rare.

La limite honnête que Jumle signale, c'est que 99,5 % des données d'entraînement sont générées par LLM pis synthétisées en translittérant à partir du latin, pas en récoltant des variantes orthographiques en script natif dans la nature. Ça compte en production : un vrai filtrage de sanctions doit matcher des fautes d'orthographe communes, des variantes dialectales pis des conventions de romanisation historiques que le pipeline synthétique a jamais vues. Les chiffres de benchmark sont réels mais la distribution d'évaluation est en aval du même générateur synthétique, ce qui veut dire que l'écart entre benchmark pis production est potentiellement plus grand que ce que le chiffre vedette suggère. Pour les développeurs, la leçon est double : les encodeurs au niveau octet plus l'apprentissage contrastif peuvent craquer des problèmes que le matching phonétique classique peut pas, l'architecture est assez petite pour rouler n'importe où, pis le raccourci de données synthétiques, c'est la bonne façon de bootstrapper quand t'as pas de données multilingues appariées — mais le déploiement en production veut quand même un vrai set d'évaluation tiré de ta vraie distribution de données, pas du générateur qui a entraîné le modèle. Le repo est à github.com/vedant-jumle/cross-language-phonetic-text-alignment pour quiconque veut fine-tuner sur ses propres données appariées.