【mT5多语言翻译】之三——数据工程：从Tatoeba原始语料到模型就绪数据的构建实战

1. 从Tatoeba原始数据到模型就绪数据的完整流程

当你第一次打开Tatoeba数据集时，可能会被它庞大的规模和复杂的文件结构吓到。作为一个涵盖487种语言、4024种语言对的庞然大物，Tatoeba确实需要一些技巧才能驯服。我在处理这个数据集时，最大的感受就是：原始数据就像刚从矿场挖出来的原石，需要经过多道工序才能变成可以镶嵌的宝石。

Tatoeba的数据结构很有特点，每个数据集（训练集、验证集、测试集）都包含三个独立文件：.id文件记录语言编码，.src文件存放源文本，.trg文件保存目标文本。这种设计虽然灵活，但直接用于模型训练却不太方便。比如中日翻译任务中，你可能会看到.src文件里是日语句子"一つ、二つ、三つ..."，而对应的.trg文件里是中文"一、二、三..."。更复杂的是.id文件中标注的各种中文方言变体，从简体中文(zho_Hans)到繁体中文(zho_Hant)，再到各种方言版本。

2. 数据筛选与清洗策略

2.1 语言变体的标准化处理

中文可能是Tatoeba数据集中最复杂的语言之一。除了常见的简体(zho_Hans)和繁体(zho_Hant)外，还有文言文(lzh)、粤语(yue)、吴语(wuu)等方言变体。在实际项目中，我强烈建议先统一语言标准。比如只保留简体中文(zho_Hans)数据，这样可以避免模型因为方言差异而产生混淆。

处理这个问题的代码其实很简单，就是在读取.id文件时做个过滤：

if "zho_Hans" not in id: continue

这个小技巧帮我节省了大量后续处理的时间。你可能想问：这样会不会损失太多数据？根据我的经验，简体中文的数据量已经足够大，而且质量相对统一，对模型训练更有利。

2.2 空值和异常数据的处理

原始数据中经常会出现空行或格式异常的情况。我曾在处理韩语数据时踩过坑，有些行看似正常，但实际上包含不可见的特殊字符。最稳妥的做法是同时检查源文本和目标文本是否为空：

if trg == "" or src == "": continue

此外，建议在处理完数据后做一次简单的统计，比如每种语言对的数量分布。这能帮你发现潜在的数据倾斜问题。我曾经发现某个小语种的数据90%都来自同一主题（比如宗教文本），这种情况下就需要考虑是否要平衡数据集。

3. 任务前缀设计与优化

3.1 从自然语言到精简前缀的演变

最初的mT5论文中使用的是"translate X to Y"这样的自然语言前缀。但在实际应用中，我发现这种长前缀会占用太多token位置。比如设置序列长度为10时，光前缀就可能占去5-6个token，留给实际文本的空间就很少了。

经过多次实验，我找到了一种平衡方案：使用语言代码作为精简前缀。比如：

• "jan:" 表示日语到中文的翻译任务
• "kor:" 表示韩语到中文的翻译任务

这种设计不仅节省了token位置，还能保持任务的可区分性。修改后的前缀处理代码如下：

data.append(["{}:".format(src_name), trg, src])

3.2 多语言任务的高效管理

当处理多种语言对时，前缀系统需要更有条理。我建议建立一个统一的前缀映射表，例如：

这样在扩展新语言时，代码维护会更容易。在我的项目中，这个简单的前缀系统成功支持了12种语言对的联合训练。

4. 数据格式转换实战

4.1 从分散文件到TSV的转换

将原始的三文件格式(.id/.src/.trg)转换为TSV是数据处理的关键一步。TSV（制表符分隔值）格式的优势在于：

1. 所有相关信息都在一行内，处理更方便
2. 容易被pandas等工具读取
3. 占用空间比JSON等格式更小

转换过程的核心代码如下：

train_df = pd.DataFrame(data, columns=["prefix", "input_text", "target_text"]) train_df.to_csv(tsv_name, sep="\t", index=False)

这里有个细节要注意：一定要设置index=False，否则pandas会多写入一列行号，导致后续读取时出错。这个坑我踩过不止一次。

4.2 内存友好的大数据处理

当处理千万级数据时，内存管理就变得很重要。我推荐两种策略：

1. 分块处理：用pandas的chunksize参数分批读取和处理
2. 使用迭代器：特别是对于超大数据集

改进后的代码示例：

chunk_size = 100000 for chunk in pd.read_csv(large_file, sep="\t", chunksize=chunk_size): process(chunk)

5. 预分词与序列化存储

5.1 为什么需要预分词

mT5使用的SentencePiece分词器虽然强大，但在训练时实时分词会有两个问题：

1. 重复计算：每次epoch都要重新分词同样的文本
2. IO瓶颈：从磁盘读取原始文本再分词的速度很慢

预分词方案能显著提升训练效率。在我的测试中，使用预分词数据训练速度提升了3-5倍。

5.2 高效的批量编码实现

HuggingFace的tokenizer提供了batch_encode_plus方法，能高效处理批量文本。关键参数包括：

• padding：统一序列长度
• truncation：超长文本截断
• max_length：控制序列长度

我的编码函数通常这样实现：

def encode_str(text, seq_len=20): return tokenizer.batch_encode_plus( text, return_tensors='pt', padding='max_length', truncation=True, max_length=seq_len )['input_ids']

5.3 序列化存储的最佳实践

最终的.pt文件应该包含所有必要信息。我推荐的结构是：

• 维度0：样本索引
• 维度1：源文本/目标文本对
• 维度2：token序列

保存和加载的代码很简单：

# 保存 torch.save(data, "dataset.pt") # 加载 data = torch.load("dataset.pt")

但要注意文件大小。一个包含1200万样本的中日翻译数据集，序列长度设为20时，.pt文件大约2-3GB。建议根据显存情况合理设置序列长度。

6. 质量检查与验证

6.1 数据一致性的验证

在完成所有处理后，必须检查数据的一致性。我通常会：

1. 随机抽样检查原始文本和编码后的对应关系
2. 验证特殊字符（如emoji）是否被正确处理
3. 检查序列长度分布是否符合预期

一个实用的检查脚本：

# 随机检查5个样本 for i in random.sample(range(len(data)), 5): print(f"原始文本: {src_texts[i]}") print(f"编码结果: {data[i][0]}") print(f"解码结果: {tokenizer.decode(data[i][0])}")

6.2 训练前的最终确认

在投入正式训练前，建议：

1. 计算数据集的基本统计信息（样本数、序列长度分布等）
2. 验证GPU加载是否正常
3. 检查数据shuffle是否有效

这些步骤看似繁琐，但能避免很多潜在问题。我曾经因为没做充分检查，浪费了三天训练时间才发现数据有问题。

7. 实际项目中的经验分享

在最近的一个多语言翻译项目中，我们处理了包含中日、中韩、中英等12种语言对的Tatoeba数据集。整个过程让我深刻体会到几个关键点：

首先，数据质量比数量更重要。我们最初尝试使用所有中文变体，结果模型在简体中文上的表现反而下降。后来改为只使用zho_Hans数据，不仅训练速度更快，最终BLEU分数还提高了2-3个点。

其次，前缀设计需要平衡可读性和效率。我们尝试过用表情符号作为前缀标识（如"🇯🇵→🇨🇳"），虽然直观但导致分词复杂度增加。最终简化为2-3个字母的代码是最优解。

最后，预分词确实能大幅提升训练效率，但要注意磁盘空间。我们的解决方案是使用压缩的numpy格式(.npz)作为中间格式，比.pt文件小30-40%，加载速度几乎不变。