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，誰想在自己的配對資料上微調都可以拿。