✨ 要点🔬 技术摘要
想象一下,你正在为一次旅行打包行李箱,这次旅行既包括英语国家城市,也包括印度九个拥有各自独特文字(如天城文、泰米尔文或奥里亚文)的地区。
问题:“一刀切”的行李箱 目前,大多数人工智能模型使用的是一种标准的“行李箱”(分词器),其设计主要针对英语和少数几种欧洲语言。当你试图将印度语言塞进这个行李箱时,它并不合身。
类比 :想象一下,试图将一件精致复杂的印度纱丽塞进一个专为 T 恤设计的行李箱。由于行李箱没有合适的隔层,它迫使你不得不将纱丽折叠成细小且凌乱的碎片。
结果 :像奥里亚语这样的印度语言中的一个单词,可能仅仅为了塞进行李箱而被切分成三个独立的碎片 。相比之下,一个英语单词可能只需一个碎片即可容纳。这使得“行李箱”(即 AI 处理的数据)变得沉重得多,携带成本也更高,尽管实际的信息量是相同的。
解决方案:BrahmicTokenizer-131K 本文的作者创建了一种更智能的新行李箱,名为BrahmicTokenizer-131K 。他们并非从零开始制造行李箱,而是选取了一个非常高质量且流行的行李箱(OpenAI 的 o200k_base),对其进行了“手术”改造,使其完美适配印度语言,同时不破坏其承载英语或代码的能力。
以下是他们通过简单步骤实现这一目标的过程:
1. “断舍离”(第一阶段)
原始行李箱拥有 200,000 个隔层。其中许多隔层装满了本次特定旅行不需要的语言物品(如韩语、日语、阿拉伯语或俄语)。
行动 :他们扔掉了 38,000 个未使用的隔层。
结果 :现在他们拥有一个更干净、更小的行李箱,恰好包含 131,072 个隔层,准备进行新的布局。
2. “手术式改造”(第二阶段)
现在行李箱里有了空余空间。他们没有让这些空间闲置,而是小心翼翼地用高频印度单词和字符将它们填满。
策略 :他们使用数学公式(线性规划)来决定哪些印度单词值得获得一个位置。他们优先考虑了那些此前被忽视的语言,例如奥里亚语。
神奇之处 :他们专门增加了725 个隔层 用于奥里亚文字符。在此之前,行李箱里零个 位置留给奥里亚语,迫使每个奥里亚字母都被拆解成细小且低效的碎片。现在,它们可以容纳完整的奥里亚语单词或其大部分片段。
3. “即插即用”功能
最棒的是,这个新行李箱在外观上与旧行李箱完全一致。
类比 :这就像将标准汽车发动机更换为高性能发动机,而新发动机恰好能装入完全相同的发动机舱内。你无需重建汽车、更换轮胎或重写手册。
声明 :任何使用旧行李箱的 AI 训练流程都可以简单地将其替换为新行李箱,并立即生效。
结果:发生了什么变化?
该论文在包含 2700 万份印度文档的庞大集合上测试了这个新行李箱。以下是他们的发现:
巨大的节省 :对于印度语言,这个新行李箱产生的碎片(token)数量比当前最佳竞争对手(Tekken/Sarvam-m)减少了26.7% 。
示例 :对于奥里亚语,改进幅度巨大。旧行李箱需要4.3 倍多 的碎片来承载相同的文本。而新行李箱则能高效地承载它。
没有权衡取舍 :通常,当你让行李箱在某一方面变得更好时,它在另一方面就会变差。但这个新行李箱是一个“通用型”赢家。
它在打包英语单词方面与原版一样出色。
实际上,它在打包计算机代码和数学问题方面比竞争对手更好 。
“专家”与“通才”的权衡 :
还有其他专为印度语言设计的行李箱(专家型)。它们在打包印度单词方面略胜一筹(大约好 12–18%)。
然而,这些专家型行李箱在打包英语或代码方面表现糟糕。
BrahmicTokenizer-131K 是唯一一个能在同一尺寸限制下,同时出色地处理所有 内容(印度语言、英语、代码和数学)的行李箱。
总结
该论文提出了一种工具,解决了 AI 处理印度语言时的结构性低效问题。通过手术式地移除未使用的语言槽位,并用精心挑选的印度语言槽位取而代之,他们创建了一种分词器,在为印度语言节省大量计算能力的同时,保持了现代 AI 模型所依赖的英语和代码的高性能。这是一个“即插即用”的升级方案,使得在印度数据上训练 AI 变得更便宜、更快速,而不会牺牲其说英语或编写代码的能力。
技术摘要:BrahmicTokenizer-131K
问题陈述
当前的大语言模型(LLM)分词器在“梵文系压缩差距”方面存在显著缺陷。在真实的印地语系网络文本上,标准分词器往往无法高效编码被约 14 亿人使用的 11 种主要印度语言中的九种梵文系文字。这种不足是结构性的,而非翻译伪影;例如,Tekken/Sarvam-m 分词器(131K 词表)的词汇表中完全缺失奥里亚语(Oriya)Unicode 区块的任何词元,迫使每个奥里亚语字符回退到字节级编码(每个字符 3 个词元)。这导致了巨大的低效:一个 37 个字符的奥里亚语句子,使用 Tekken/Sarvam-m 分词器会被切分为 99 个词元,而使用更优化的分词器仅需 21 个词元。此类差异增加了训练计算成本,降低了有效上下文长度,并在多语言大语言模型中造成了能力不平等。虽然针对印地语系语言存在专用分词器,但它们往往以牺牲英语、欧洲语言、代码和数学方面的表现为代价。反之,像 o200k_base 这样的通用分词器在英语和代码方面表现优异,但对低资源梵文系文字的覆盖不足。
方法论
作者提出了 BrahmicTokenizer-131K ,这是一个拥有 131,072 个词元的字节级 BPE 分词器,旨在作为 OpenAI 的 o200k_base 的“即插即用”替代品。其构建遵循两阶段的“手术式改造”流程:
第一阶段:脚本剪枝裁剪 :将 o200k_base 的基础词表(200,019 个词元)缩减至 131,072 个,通过移除覆盖九种非目标脚本(CJK、韩文、日文、阿拉伯文、西里尔文、泰文、希腊文、希伯来文和僧伽罗文)的 38,345 个词元来实现。此步骤顺便移除了违反结构约束的词元,例如那些超过 32 个 UTF-8 字节或跨越不相连书写系统的词元。
第二阶段:手术式改造 :将裁剪后词表中 2,372 个“语料库死区”槽位(在审计语料库中触发率为零的词元)重新用于高频梵文系内容。
分配策略 :采用线性规划(LP)方法确定这些槽位在九种梵文系脚本中的分布。其目标是在审计语料库上最大化总词元节省量,优先处理相对于其语料库占比而言代表性不足最严重的脚本。
内容类别 :2,372 个槽位被分配至:
字符基础设施(5 个槽位) :字节对中间项,用于修复高频脚本中 GPT-2 字节级预分词器回退的问题。
单词级槽位(1,443 个槽位) :高频梵文系单词和子词片段(大多为 3 个 aksharas 或更少),以实现“整词机制”。
每脚本内容(922 个槽位 + 产物) :通过 LP 策略分配,包括 149 个印度数字合并项和 3 个共享标点符号词元。
合并规则 :通过在梵文系受限的审计语料库上训练 BPE 生成新的合并规则,并经过过滤以确保没有任何合并项组合来自不相连书写系统的字节(即“无跨脚本合并”规则)。
预分词器、解码器以及继承的英语/欧盟/代码合并规则与 o200k_base 保持位级一致,确保该分词器可作为直接接口替代品发挥作用。
主要贡献
成果 :在 Apache 2.0 许可下发布 BrahmicTokenizer-131K,包括 tokenizer.json、验证脚本和审计套件。
方法论 :记录了一种用于扩展字节级 BPE 分词器词表的“手术式改造”方法论。该方法被证明比在印地语系密集的语料库上从头训练更具计算效率,同时保留了源分词器在非目标语言方面的特性。
结构保证 :该构建强制最大词元字节长度为 32 个 UTF-8 字节,并确保没有任何词元跨越两个不相连的书写系统,这些特性对于字节池化嵌入架构至关重要。
结果
该分词器在五个维度上与另外 13 种分词器进行了评估:印地语系词元量、每词丰度、每词元字节压缩率、结构诊断以及代码/数学压缩。
印地语系压缩 :在包含 2700 万份文档的印地语系预训练语料库(28.4 亿词)上,BrahmicTokenizer-131K 在相同的 131K 词表预算下,比 Tekken/Sarvam-m 产生的词元数量少 26.7% 。
按语言划分的节省幅度从**15.79%(泰米尔语)到 76.79%(奥里亚语)**不等。
奥里亚语的优势在机制上归因于增加了 725 个奥里亚语区块词元,将该语言从字节回退(每字符 3 个词元)提升至子词分词,实现了4.31 倍的压缩率 。
英语和欧盟语言表现 :该分词器保留了 o200k_base 的英语压缩能力(1.235 词元/词,而 o200k_base 为 1.232),在 0.034% 的精度内与其匹配。在法语、德语和西班牙语方面,它仍与 Tekken/Sarvam-m 保持竞争力(与最佳水平相差在 2.5% 以内)。
代码和数学压缩 :在 131K 词表的分词器中,BrahmicTokenizer-131K 在代码和数学方面实现了同类最佳压缩。它比 Tekken/Sarvam-m 在 HumanEval(4.0%) 、MBPP(5.4%) 和 GSM8K(14.2%) 上表现更优。这归功于保留了 o200k_base 针对数字的 3 位分组策略。
通用竞争力 :在公开可用的 131K 词表分词器中,BrahmicTokenizer-131K 是唯一同时在印地语系、英语、欧盟语言、代码和数学维度上具有竞争力的分词器。专用分词器(如 68K 的 Sarvam-1 或 262K 的 Sarvam-30B)虽然在印地语系压缩方面表现更好,但在英语(Sarvam-1 差 15.9%)和代码/数学表现(Sarvam-1 差 26–33%)方面遭受显著退化。
意义与主张
本文主张,BrahmicTokenizer-131K 在 131K 词表预算下成功消除了梵文系压缩差距,同时未牺牲 o200k_base 系列在英语、代码和数学方面的高性能特性。
作者强调,这是一个通用 解决方案。虽然专用分词器可以通过将更大比例的词表分配给这些脚本来实现更高的印地语系文本压缩,但这是以牺牲非印地语系能力为代价的。BrahmicTokenizer-131K 提供了一种平衡的权衡,在提供显著的印地语系效率提升(词元量减少 26.7%)的同时,在其他领域保持"o200k 级”的性能。
本文将“手术式改造”方法论定位为从头训练分词器的可行替代方案,特别是针对那些已存在高质量源分词器(针对目标语言子集)且需要额外覆盖的场景。作者指出,与 68K 专用分词器 Sarvam-1 相比,印地语系压缩损失 12.7%,与 262K 的 Sarvam-30B 相比损失 18.7%,这是在 131K 预算下维持通用广度的有意成本。
每周获取最佳 machine learning 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题,再试一次?
无垃圾邮件,随时退订。