不用翻译语料，如何构建日常转写训练数据

翻译数据可能把“明天见”和另一种语言的一句话配成一对。Convert 模型收到的却是另一种对象，例如 kal Zoom pe milte hain：只有部分文字要换成目标文字，Zoom 必须原样保留。

这个差别决定了什么样的数据才应该进入训练集。

翻译对教的是另一个任务

翻译会改变语言。转写只改变书写系统，同时保留原本的语言和输入中受保护的部分。

如果数据奖励语义翻译，模型可能会替换用户故意输入的英文词，抹掉口语表达，或者重写整句话。这些选择在翻译里可能合理，在 Convert 里却是错误。

日常输入不只是干净的完整句子

真实草稿里有很多碎片和边界：

• hao de、theek hai 这样的短回复；
• 人名、品牌、地名和借词；
• @账号、#标签、链接和邮箱；
• 代码、命令、版本号和文件名；
• emoji、重复标点和拉长拼写；
• 同一行里的两种或更多语言；
• 因人而异的拉丁字母拼写。

训练数据必须围绕这些对象来构建。只包含标准句子的数据集可能分数很好，却仍会破坏用户真正交给 Convert 的文字。

社交写法有价值，但不需要复制别人的帖子

社交文字里有用的是输入形态：缩写、语言混写、emoji 位置、回复符号、方言拼写和不完整语法。我们可以原创覆盖这些形态的例子，不必把某个人的帖子复制进训练集。

每个例子还应该带有可以检查的约束。网址必须逐字节不变；多行输入必须保留行数；纯英文对照必须继续是英文；已经使用目标文字的输入不应被无故重写。

边缘案例就是数据集的一部分

对 Convert 来说，所谓边缘案例通常只是多了一个限制的普通消息。@sara、v2.1 或 Arabizi 数字都可能改变正确输出。因此，这些情况从设计数据时就要出现，也要留一部分只用于测试。

目标不是堆出最多的句子，而是覆盖模型真正要做的三种判断：转换、保留，或者完全不改。

下一篇会解释拼音、Romaji、Hinglish 和 Arabizi 为什么是四种不同的转换问题。受保护内容的产品规则见隐私与受保护内容。