O texto em nepalês "pesava" três vezes mais que o inglês — o conserto do tokenizador não resolveu o problema por completo

De onde vem o desperdício de tokens

Uma equipe de pesquisadores descobriu por que modelos de linguagem como Llama-3 e Qwen3 lidam com texto em nepalês de forma tão desperdiçadora — e tentou corrigir isso. Descobriu-se que o problema não está no vocabulário do modelo, mas na primeira etapa, a mais discreta, do processamento de texto: a divisão preliminar em pedaços que acontece antes mesmo de o tokenizador começar a montar os tokens.

De onde vem o excesso de tokens

Tokenizadores do tipo GPT-2, sobre os quais Llama-3 e Qwen3 são construídos, cortam o texto com uma expressão regular antes da tokenização principal. Essa expressão só considera "palavra" uma sequência de letras Unicode. O problema é que o nepalês usa a escrita devanágari, na qual as vogais não são representadas por letras independentes, mas por sinais especiais colocados acima ou abaixo da letra base — os chamados sinais combinantes. No Unicode, esses sinais formalmente não contam como "letras", então a expressão regular corta a palavra em nepalês literalmente em cada sinal vocálico.

O resultado: onde um falante de inglês gasta um token, o mesmo texto em nepalês exige, nos mesmos modelos, de 2 a 3 vezes mais tokens para transmitir a mesma quantidade de significado. Os pesquisadores mediram isso no corpus paralelo FLORES-200 (as mesmas frases em idiomas diferentes) — o tokenizador do Qwen3 gasta visivelmente mais tokens numa frase em nepalês do que em sua tradução para o inglês, e o tokenizador usado por Phi-4, OLMo-2 e Granite-4.1 é ainda pior.

Para os usuários, isso não é uma métrica abstrata. Mais tokens para o mesmo significado significa uma consulta mais cara, uma resposta mais lenta e menos conteúdo útil cabendo na janela de contexto do modelo.

Por que o "ajuste fino" comum do vocabulário não ajuda

O método padrão para ensinar um modelo já treinado a lidar melhor com um novo idioma é a chamada extensão de vocabulário baseada em fusões (merge-based vocabulary extension): novos tokens fundidos são adicionados ao vocabulário e ajustados com texto do novo idioma. O problema é que a divisão por expressão regular acontece antes de qualquer fusão — e se uma palavra já foi cortada em pedaços pelos seus sinais vocálicos, nenhuma quantidade de novas fusões vai conseguir recolar pedaços separados por esse corte. Os pesquisadores demonstram que essa abordagem tem um "teto" matemático de economia, que depende apenas da expressão regular, não do tamanho do vocabulário.

Eles verificaram isso em lançamentos reais: encontraram dez extensões de vocabulário publicadas anteriormente para seis escritas diferentes (no Llama-3, Llama-3.1, Qwen2.5 e Qwen3) — e todas as dez bateram em seu respectivo teto, extraindo pelo menos 98% da economia possível. Ou seja, os desenvolvedores desses modelos já tinham feito tudo o que era possível fazer com o método padrão — insistir mais no vocabulário sozinho não faz sentido.

Os pesquisadores também testaram uma brecha: registrar strings em nepalês como "tokens adicionados" que não passam pela expressão regular. Isso realmente rompe o teto, mas quebra a segmentação por limites de palavra — um quinto desses tokens passa a dar match bem no meio de uma palavra, o que prejudica o sentido da divisão.

O que o "conserto" da expressão regular trouxe

Os pesquisadores reescreveram a própria expressão regular para que os sinais vocálicos devanágari contassem como parte da palavra, e não como caracteres separados. Uma propriedade importante do conserto: eles provaram matematicamente que, para qualquer texto sem sinais combinantes e sem caracteres devanágari (ou seja, para inglês e código), a tokenização permanece absolutamente idêntica à anterior — nenhum token muda.

Com a nova expressão regular e 32.000 novos pares de fusão, o texto em nepalês passou a exigir quase a mesma quantidade de tokens que o inglês — 54% menos tokens do que a extensão de vocabulário padrão.

Mas, ao fazer de fato o fine-tuning dos modelos Llama-3.2-1B e Qwen3-0.6B com uma mistura de textos em nepalês e inglês, o resultado foi inesperado: o tokenizador original, o "não corrigido", apresentou, com orçamento igual, melhor qualidade de previsão para o nepalês (medida em bits por byte) do que tanto a versão corrigida quanto a versão com extensão padrão. Essa era a principal hipótese dos pesquisadores — e ela não se confirmou.

Com um número igual de etapas de treinamento (em vez de bytes), o tokenizador corrigido se mostrou melhor no Qwen, mas pior no Llama — ou seja, o ganho foi inconsistente entre os modelos. Aumentar a taxa de aprendizado no Qwen melhorou os resultados das três variantes, mas não mudou sua ordem relativa.

O que isso significa na prática

Para engenheiros que fazem fine-tuning de modelos abertos para idiomas com sinais combinantes (não só o nepalês, mas também, por exemplo, tailandês, árabe ou bengali), a conclusão tem dois lados. Por um lado, a economia de tokens é real e confirmada matematicamente — o tokenizador corrigido efetivamente gasta 54% menos tokens no mesmo texto em nepalês, sem afetar inglês ou código. Por outro lado, menos tokens não significa automaticamente um modelo melhor: os próprios pesquisadores mostram que, em seus testes, o tokenizador antigo, o "não corrigido", ainda vence em qualidade com orçamento de computação igual.

Resta uma pergunta em aberto, que os pesquisadores honestamente não testaram: se a economia de tokens se traduz, na prática, em ganho de velocidade e custo na geração de texto, mesmo com uma qualidade um pouco pior. O código, os tokenizadores treinados e o plano de análise estão disponíveis em acesso aberto no GitHub e no Hugging Face.