突厥语系翻译迁移，一篇论文摸清了谁跟谁真的「近」

做多语言产品的团队时常面对一种纠结：模型在土耳其语上跑得不错，但用户里还有说哈萨克语、乌兹别克语的，资源又不够每种语言单独训一个，于是押注迁移学习——拿土耳其语的数据微调，指望它自己「悟」出其他突厥语系的语言。到底能不能悟？悟多少？方向重不重要？这些问题一直靠猜。

7 月底 arXiv 上出现了一篇论文，专门把这事测了一遍。作者来自土耳其中东技术大学，拿 mT5 做了五组突厥语——土耳其语、阿塞拜疆语、乌兹别克语、哈萨克语、吉尔吉斯语——之间的两两迁移矩阵。设计很直接：用一种语言做微调数据（transfer source），在另一种语言上评估（transfer target），翻译目标语保持一致，这样就能隔离出「语言亲缘关系到底贡献了多少」这个变量。

结论基本印证直觉，但也给出了一些让人意外的细节。

迁移效果最强的确实是最亲近的语言对：土耳其语↔阿塞拜疆语，哈萨克语↔吉尔吉斯语。这符合语系内部的亲缘树——土耳其语和阿塞拜疆语同属乌古斯语支，哈萨克语和吉尔吉斯语同属钦察语支。手头只有土耳其语资源但想覆盖阿塞拜疆语的话，这条路走得通。

但迁移方向存在不对称性——不是 A→B 和 B→A 效果一样好。论文明确定语：transfer direction matters。选「锚点语言」时，不光要看资源多少，还得考虑谁做 source 对下游更友好。

拉丁化（Latinization）能提升 BLEU 和 chrF，但不是万能药。几种语言原本用西里尔字母，转写成拉丁字母后分数确实涨了，但涨幅不均匀——有的场景改善明显，有的几乎没变化。对工程技术团队来说，预处理阶段加一道 transliteration 大概率不亏，但不能指望它解决所有差距。

同一个 source-target 对，换一个翻译目标语，结果可能完全不一样。语言间的「迁移友好度」不是固定的静态属性，还会被任务方向影响。

论文用 mT5 做实验，这是一个已经有跨语言能力的多语言模型，因此不能简单等同于随机初始化训练。但这恰好也是行业里最真实的用法——没人从零训翻译模型了，大家都在用多语言基座做微调，然后再评估迁移能力。这个实验设置实际上更贴近工程决策场景。

最后他们还做了一个稳定性检验：换了数据集和模型配置之后，作为 transfer source 的语言排序基本不变。意思是如果测出来某语言是最佳 source，这个结论大概率不是刷出来的，换数据也站得住。

假如你做一个中亚市场用的多语言产品，手头只有土耳其语标注数据，这篇论文给了可行的扩散路径——土耳其语先覆盖阿塞拜疆语，哈萨克语和吉尔吉斯语之间可互相兜底，乌兹别克语居中需要考虑。拉丁化处理值得加，但不要期望它能拉平语支差距。

一个局限是 paper 没涉及推理成本、没有开源权重或实际部署测试，它停留在评测层面。要真上线，还得走一遍量化、蒸馏、在具体硬件上跑一遍延迟。但方向选对了，后面就是工程问题了。

这种「把语系内部关系定量测出来」的工作，在低资源 MT 里其实不多。大多数迁移学习论文要么只看一两个语言对，要么把几十种语言混在一起看平均分。这篇专门盯着一个语系做细粒度矩阵，对做中亚、西亚语言产品的团队来说，是一份可以直接抄进技术选型报告里的参考。

相关链接：
- 论文页面：https://arxiv.org/abs/2607.29355
- PDF 全文：https://arxiv.org/pdf/2607.29355