你的模型只在英文下「抗揍」——一篇 27 语言的论文实锤了 tokenizer 的隐藏偏见

费劲调好了一个模型，英文 benchmark 跑得漂漂亮亮。推到日文或者阿拉伯语的场景里，用户发来的文本多了一个空格、少了一个标点、或者用了不太标准的写法——模型突然就降智了。第一反应是查 prompt、查 fine-tuning 数据，但大概率不会怀疑到 tokenizer 头上。

最近 arXiv 上这篇论文标题很长，结论很直接：「Language Models are not Equally Robust to Non-Canonical Tokenization across Languages」——语言模型对不同语言的非标准切词方式，抗揍程度不一样。

所谓「非标准 tokenization」，指的是同一个字符串理论上可以切出指数级多种切法，但模型实际走的只有一条——分词器默认给出的那一条。之前针对英文的研究普遍发现，模型对 alternative tokenization 几乎无感，怎么切结果都差不多。但这篇论文问了一个关键问题：这个「不敏感」在其他语言里也成立吗？

答案是不成立，而且差距非常大。

研究者在 27 种语言、6 个下游任务上测了三个模型：Llama-3.1-8B、Qwen3-8B、Gemma-3-12B。在非标准 tokenization 下，Llama-3.1-8B 性能平均掉了 23.7%，Qwen3-8B 掉了 11.4%，Gemma-3-12B 掉了 9.9%。这不是某一个模型的问题，是所有被测试模型的通病。

掉性能不是随机的，有系统性规律。那些 token 碎片化程度更高的语言——也就是同一个词被切得零零碎碎的语言——对 tokenization 的变动更敏感。 如果模型的 tokenizer 在某语言上本来切得就不好，随便改一点输入格式，模型都可能崩。

这一点对正在做多语言部署的团队来说很要命。花大量精力调指令、做对齐、凑数据，但底层的 tokenizer 可能根本没把那种语言当回事。Tokenization 是模型理解文本的第一关，这一关就不稳，后面所有层都跟着晃。

论文也给了缓解路径。用 LoRA 在多 tokenization 数据上做 fine-tuning，可以明显降低这种敏感性。只用英文数据做 fine-tuning，也能跨语言地提高 tokenization 鲁棒性——但最好的效果还是来自系统性地采样多种非标准 tokenization 一起训练。

这个发现挺反直觉的。英文研究者不太觉得 tokenization 是个问题，因为英文在主流 tokenizer 里总是被伺候得很好。但换一种脚本、换一种拼写习惯，模型的脆弱面就露出来了。Tokenization 不是一个已经被解决的基础设施问题——它可能是多语言 LLM 部署里最被低估的瓶颈。

这类研究接下来只会越来越多，因为现实世界的输入永远不会像 benchmark 那么干净。不可能要求所有用户都按 tokenizer 最喜欢的格式打字。如果在做非英语的 LLM 产品，现在就该去测一测模型在「不那么标准」的输入下表现怎么样——别等用户发现才补救。

相关链接：
- 论文：https://arxiv.org/abs/2607.26831