Vedant Jumle 关于他的跨脚本名字检索系统的写作，正是那种又小又聚焦、能在实际中真正打开局面的研究项目。问题平凡但重要：当"Владимир Путин"在一个西里尔字母的源里、而监控列表是按拉丁字母索引的时候，Levenshtein、Double Metaphone 和 BM25 这些经典模糊匹配器都会严重失败。这些 baseline 在拉丁-到-拉丁和拉丁-到-非拉丁检索之间的性能差距是 0.88 到 0.94——意味着同一脚本里能标记出匹配的系统，跨脚本时几乎完全错过等价名字。制裁筛查、移民数据库、医院记录匹配、金融合规管道每天都和这个失败模式共存。
模型很小，架构也常规：一个 400 万参数的 transformer 编码器，6 层、256 隐藏维度，用 InfoNCE 对比损失加 ANCE 难负例挖掘训练。关键是输入。它不用子词 tokenization——子词 tokenization 在统计结构差异巨大的不同书写系统之间是脆的——而是直接读原始 UTF-8 字节，一个 256 符号的字母表，原生处理每种脚本。没有脚本特定的预处理，加希伯来语或印地语时也没有要重训的独立 tokenizer。Embedding 单位归一化，所以检索就是余弦相似度，部署就是预计算向量上的 ANN 索引。整个系统能装进经典语音匹配器也能装进的内存预算里。
让结果可信的是训练数据的构造。Jumle 从 Wikidata 采样了 119,040 个人名实体，让它们走过一个四阶段的合成对管道（Llama-3.1-8B 生成语音化拉丁变体，Qwen3-30B 跨脚本转写到八种脚本），再和 Wikidata 真实名字对融合，得到 467 万正例对。标题数字是整体 0.775 MRR、0.897 R@10，而关键的是拉丁-到-非拉丁差距塌缩到 0.096——比经典 baseline 好一个数量级。阿拉伯语、俄语、希伯来语都过了 0.95 R@10。中文（0.666）和韩文（0.728）落后，作者正确归因于真实的罗马化歧义而不是模型失败：任何一个汉字或韩文名字都有多种站得住脚的罗马化方式，ground truth 也更稀疏。
Jumle 标记的诚实局限是 99.5% 的训练数据由 LLM 生成、通过从拉丁出发转写来合成，而不是从野外收集原生脚本里的拼写变体。这在生产里很重要：真实的制裁筛查得能匹配常见拼写错误、方言变体、历史罗马化惯例，而合成管道从未见过这些。Benchmark 数字是真的，但评估分布在同一个合成生成器的下游，意味着 benchmark 和生产之间的差距可能比标题暗示的更大。对开发者来说，结论是双重的：字节级编码器加对比学习能破解经典语音匹配破解不了的问题，架构小到能在任何地方跑，没有多语种配对数据时合成数据捷径就是正确的 bootstrap 方式——但生产部署仍然要一个从你真实数据分布里抽出来的真评估集，不是训练这个模型的那个生成器。仓库在 github.com/vedant-jumle/cross-language-phonetic-text-alignment，谁想在自己的配对数据上微调都可以拿。