18岁独立开发者从零搭建突尼斯达里贾语翻译模型：BLEU 3.89 的诚实起点

上周末，一个18岁的突尼斯学生在 r/MachineLearning 甩出了一个略显冷门但很有意思的项目：一套从零训练的突尼斯达里贾语（Tunisian Darija）机器翻译流水线，加上一份手工标注的平行语料库，全部开源。首版 BLEU 只有 3.89——他自己也很坦诚地写在了 README 里。

这不是什么惊天动地的 SOTA，但值得聊一聊。因为在 2026 年这个大模型满天飞、Llama 4 和 GPT-5 都能跑多语言的当下，还有一整批语言是这些巨兽根本没吃进去过的——突尼斯达里贾就是其中之一。

一门被主流 NLP 忽略的语言

先说清楚这门语言到底是什么。突尼斯达里贾是突尼斯当地的口语阿拉伯语方言，跟你在课本上学的现代标准阿拉伯语（MSA）差别之大，堪比粤语之于普通话，甚至更狠。更麻烦的是它的书写方式——年轻人日常用拉丁字母加数字来写，业内叫 Arabizi，比如：

• 3 代表阿拉伯语的 ع（ayn）
• 7 代表 ح（ha）
• 9 代表 ق（qaf）
• 5 代表 خ（kha）

所以一句 "3aychek"（意思是"谢谢"）在任何标准阿拉伯语 tokenizer 眼里都是乱码。这就导致现有的阿拉伯语 NLP 工具链——不管是 AraBERT 还是 Google Translate 的阿拉伯语模块——碰到 Arabizi 基本上都会先强行归一化到 MSA，再翻译，中间损耗巨大。

作者的原话是："Existing Arabic tools route it through MSA and mishandle the orthography." 一句话把痛点点破了。

他做了什么

这套流水线的技术栈其实相当克制，没有堆参数、没有蒸馏 GPT-4，全是老老实实的 Transformer encoder-decoder：

• Arabizi-aware SentencePiece BPE tokenizer：16k 共享词表，关键是把 3/7/9/5 这些数字作为受保护符号（protected symbols）单独处理，避免 BPE 把它们和普通数字混在一起切碎。这是整个项目最有巧思的一处工程决策。
• ~15.6M 参数的 Transformer：从零训练，不基于任何预训练 LM。
• 迁移学习路径：先在清洗过的摩洛哥达里贾语数据上预训练（因为北非阿拉伯语方言之间有一定互通性），再在手工构造的突尼斯配对数据上微调。
• 完整的清洗 / 训练 / 评估流水线：整套代码可复现。

数据量呢？约 553 条手工标注的平行句对。是的，你没看错，五百多条。

为什么这个项目值得关注

先说结论：从工程和结果看，这个 v1 基本是玩具级别。BLEU 3.89 意味着输出基本没法直接用，几乎所有 n-gram 都对不上。但如果你在低资源 NLP 领域待过，就知道这条路径本身是对的。

对比一下 2020 年北理工那篇司法领域藏汉平行语料库的工作——那是一个团队搞了 16 万级别的语料库，还有专业术语表做先验知识。而这里是一个高中生独自搞了 553 条，还要从 tokenizer 开始重造轮子。差距是数量级的，但方法论上他做对了几件事：

1. 从 tokenizer 开始正视 Arabizi 的正字法特殊性，而不是简单粗暴地音译回阿拉伯字母。
2. 用摩洛哥达里贾做迁移源，这是低资源 NMT 里典型的"近亲语言迁移"策略，2021 年那篇《稀缺资源语言神经网络机器翻译研究综述》里专门讨论过这条路。
3. 把语料建设开放为社区共建，而不是自己闷头堆数据。553 条只是种子，关键是流水线打通了，其他突尼斯开发者和语言学者可以持续往里加。

换句话说，他没打算靠这个 v1 解决问题，而是搭了一个所有人都能往上贡献的脚手架。

低资源翻译的老问题

低资源机器翻译不是新话题。学界从统计机器翻译时代就在啃这块骨头，NMT 时代也有大量工作在讨论回译（back-translation）、多语言迁移、pivot translation 等等。阿里天池甚至专门办过低资源多语言翻译评测榜单。

但方言这一层，长期以来是被绕开的。原因很朴素：

• 方言书写不标准，同一个词可能有 5 种拼法（比如"你好" slem / slam / sale7 都能见到）
• 缺乏权威语料源，法律文书、新闻报道基本都是 MSA
• 商业价值不明确，Google、Meta 这种大厂没动力单独训一个突尼斯方言模型

所以这类工作只能靠社区自己。作者提到，据他所知，在他之前根本不存在突尼斯达里贾的开源平行语料库。这句话本身就说明问题——一个有 1200 万人口的国家的日常语言，在 2026 年的开源 NLP 世界里是空白的。

一些值得吐槽和期待的地方

吐槽的部分：

• 15.6M 参数的模型在 553 条数据上，过拟合几乎是必然的。作者也承认 test set 很小，locked test set 上的 BLEU 数字统计意义有限。
• BLEU 作为方言翻译评估指标本身就有问题。Arabizi 的拼写自由度太高，同一个正确翻译可能有多种合法表达，BLEU 会严重低估。COMET 或人工评估会更合适。
• 没有 back-translation 增强。这是低资源 NMT 最标准的操作之一，作者可能后续会加。

期待的部分：

• 语料库以社区共建方式扩展，如果能做到 1 万条量级，配合当前流水线，效果应该会有显著跃升。
• Arabizi-aware tokenizer 这套设计思路可以直接迁移到其他 Maghrebi 方言（阿尔及利亚达里贾、利比亚阿拉伯语），甚至埃及阿拉伯语的口语场景。
• 如果社区愿意接手，未来可能会看到基于 Qwen 或 Gemma 这种小尺寸开源基模型的 fine-tune 版本，效果会比 15M 从零训练的 Transformer 好得多。

对开发者意味着什么

如果你在做多语言应用，尤其是覆盖北非、中东市场的产品，这个项目至少给你两个直接可用的东西：

1. 一份 Arabizi-aware 的 SentencePiece tokenizer，可以直接嫁接到你自己的模型上，处理用户输入中的 Arabizi 文本。
2. 一套可复现的低资源 NMT 训练模板，如果你手里有其他方言的小规模数据，几乎可以照抄。

对于日常调用主流大模型的开发者来说，这类项目的意义在于提醒你：主流模型的"多语言支持"是有边界的。GPT-5 和 Claude 4 处理 MSA 没问题，处理 Arabizi 时你就得自己做预处理。真正的产品化场景里，这些细节比模型排行榜上的几个点分数重要得多。

顺带一提，如果你想快速做多模型对比测试——比如同一段 Arabizi 文本分别喂给 GPT、Claude、Gemini、DeepSeek 看谁的方言处理最靠谱——OpenAI Hub 一个 Key 调所有模型这套东西是省事的，国内直连、兼容 OpenAI 格式，写个脚本跑一圈评估就行。

一点感想

2026 年了，AI 圈的注意力全在 agent、多模态、推理模型上。但在这些聚光灯之外，还有一堆语言、一堆场景、一堆用户的实际需求没被满足。一个 18 岁的学生用 553 条句子和 15M 参数的模型，把这个空白撕开了一道口子。BLEU 3.89 不好看，但这条路径是对的。

低资源 NLP 需要的从来不是更大的模型，而是更多这样愿意从 tokenizer 开始一行行写代码、一句句标数据的人。

参考来源

• I built an open, from-scratch MT pipeline + parallel corpus for Tunisian Darija - Reddit — 项目作者的原始发布贴，含技术细节和 GitHub 链接