Como os LLMs enxergam texto: o que meu sistema de i18n me ensinou sobre economia de tokens

Quando construí o sistema de tradução i18n para meu site, descobri que traduzir um post de blog em inglês com 1.500 palavras para coreano consumia 2,8x mais tokens do que o texto original em inglês. O mesmo conteúdo semântico, o mesmo significado, mas 2,8x o custo de API. O japonês ficou em 2,4x. O chinês tradicional em 2,1x. O espanhol em 1,15x. A economia de tokens do conteúdo multilíngue me pegou desprevenido porque eu não entendia como os tokenizadores funcionam.¹

TL;DR

A tokenização converte texto legível por humanos em tokens numéricos que os modelos de linguagem processam. Depois de traduzir 27 posts de blog em 6 idiomas, tenho dados reais de custo: scripts não latinos consomem 2-3x mais tokens por unidade semântica do que o inglês. O visualizador interativo abaixo permite que você cole texto em qualquer idioma e veja a decomposição em tokens. Entender a tokenização me ajudou a orçar meu pipeline de tradução com precisão, otimizar meus prompts para reduzir o custo em 35% e depurar um problema de formatação em que as traduções em coreano perdiam a estrutura do markdown porque o tokenizador dividia marcadores de notas de rodapé entre fronteiras de tokens.

Meus dados de custo de tokens com i18n

Traduzi 27 posts de blog em 6 idiomas usando Claude. A qualidade da tradução exigia modelos de nível Opus (nunca modelos mais baratos — uma lição que aprendi quando o Haiku produziu traduções que pareciam saída de máquina). O consumo de tokens por idioma me surpreendeu:

Os idiomas de script latino (espanhol, alemão, francês) ficaram dentro de 20% do inglês. Os idiomas CJK e Hangul saltaram 2-3x. A diferença de custo se acumula ao longo de 27 posts × 6 idiomas = 162 traduções.²

Por que a diferença existe

A maioria dos tokenizadores (BPE, usado tanto pelo Claude quanto pelo GPT-4) é treinada predominantemente em texto em inglês. Palavras em inglês têm representações de tokens otimizadas porque os dados de treinamento contêm mais inglês do que qualquer outro idioma. Palavras comuns em inglês (“the”, “and”, “is”) mapeiam para tokens únicos. Blocos silábicos coreanos, kanji japoneses e caracteres chineses frequentemente se dividem em 2-3 tokens em nível de byte porque o tokenizador os encontrou com menos frequência durante o treinamento.³

O efeito é sistemático, não aleatório. Cada tradução para coreano custa aproximadamente 2,8x o equivalente em inglês. Consigo orçar com precisão porque o multiplicador é consistente.

O bug de tokenização

Durante meu primeiro lote de traduções para coreano, os posts traduzidos perderam toda a formatação markdown: referências de notas de rodapé ([^1]) desapareceram, blocos de código perderam suas tags de idioma, e marcadores de título (##) se fundiram ao texto do corpo.

O diagnóstico levou uma hora. A causa raiz: meu prompt de tradução dizia “Traduza este post de blog para coreano” sem especificar a preservação da formatação. O tokenizador dividiu a sintaxe markdown em fronteiras de tokens de forma diferente no contexto coreano do que no contexto inglês. O modelo tratou [^1] como conteúdo traduzível em vez de marcação estrutural.

A correção: adicionei restrições explícitas ao meu prompt de tradução:

Preserve all markdown formatting exactly:
- Keep [^N] footnote references unchanged
- Keep ``` code fences with language tags unchanged
- Keep ## heading markers unchanged
- Keep **bold** and *italic* markers unchanged

Cada restrição eliminou um modo de falha. A lista de restrições ficou maior que a instrução de tradução — um padrão que descrevo no meu framework OODA de engenharia de prompts.⁴

O que são tokens

De caracteres a tokens

Uma abordagem ingênua do processamento de texto trataria cada caractere como uma unidade de entrada. “Hello world” se torna 11 caracteres. O processamento em nível de caractere captura todos os detalhes, mas produz sequências extremamente longas: um documento de 1.000 palavras se torna aproximadamente 5.000 caracteres.⁵

O processamento em nível de palavra reduz o comprimento da sequência, mas falha com palavras desconhecidas. Um vocabulário de 50.000 entradas em nível de palavra não consegue processar “unfathomability” a menos que exatamente essa palavra tenha aparecido no treinamento.

A tokenização de subpalavras encontra um meio-termo. Palavras comuns (“the”, “and”) permanecem como tokens únicos. Palavras incomuns se dividem em pedaços de subpalavras. “Unfathomability” se divide em [“un”, “fath”, “om”, “ability”], onde cada pedaço aparece com frequência suficiente para ter uma representação treinada.

Byte-Pair Encoding (BPE)

BPE, usado pelo Claude e pelo GPT-4, começa com bytes individuais e mescla iterativamente os pares adjacentes mais frequentes:⁶

1. Comece com caracteres individuais: [l, o, w, e, r]
2. Par mais frequente: (l, o) → mescla para [lo, w, e, r]
3. Par mais frequente: (e, r) → mescla para [lo, w, er]
4. Par mais frequente: (lo, w) → mescla para [low, er]
5. Par mais frequente: (low, er) → mescla para [lower]

O vocabulário final contém todos os bytes originais mais cada token mesclado, tipicamente entre 50.000 e 100.000 entradas. Palavras em inglês dominam os tokens mesclados porque o inglês domina os dados de treinamento.

Como otimizei meus prompts

Após descobrir a diferença de custo por tokens, otimizei meu pipeline de tradução para reduzir o custo em 35%:

Otimização 1: Agrupar por família linguística

Idiomas de script latino (espanhol, francês, alemão) compartilham similaridades estruturais. Agrupe o prompt de tradução para produzir os três em uma única chamada de API quando o post fonte for curto o suficiente para caber na janela de contexto com todas as três saídas. O contexto compartilhado (o texto fonte em inglês) é pago uma vez em vez de três.⁷

Otimização 2: Deduplicação de restrições

Meu prompt de tradução original repetia restrições para cada idioma. A versão otimizada define as restrições uma vez e as aplica a todas as saídas:

# Constraints (apply to ALL translations below):
- Preserve markdown structure, footnotes, code blocks
- Keep proper nouns in English
- Adapt idioms, don't transliterate

# Translate the following post into: Spanish, French, German

A seção de restrições consome tokens uma vez. A alternativa (repetir restrições por idioma) consome 3x.

Otimização 3: Instruções concisas

Meu prompt original usava 340 tokens de instruções. Após a otimização: 180 tokens. A redução de 47% se acumula ao longo de 162 traduções.

Idiomas CJK se beneficiam menos da otimização de prompts porque os tokens de saída (a tradução em si) dominam o custo. A saída é inerentemente mais longa em termos de tokens, independentemente de quão concisas sejam as instruções.⁸

Aplicações práticas

Estimando custos

Uma heurística aproximada para texto em inglês: 1 token equivale a aproximadamente 0,75 palavras, ou aproximadamente 4 caracteres. Um documento de 1.000 palavras consome aproximadamente 1.333 tokens. Aplique o multiplicador de idioma da minha tabela acima para conteúdo não inglês.⁹

Tokenização de código

Código é tokenizado de forma diferente da prosa. Palavras-chave comuns (def, return, if) mapeiam para tokens únicos. Nomes de variáveis se dividem com base na frequência:

# "def calculate_total(items):" splits approximately as:
# ["def", " calculate", "_total", "(", "items", "):", ]

Convenções de nomenclatura consistentes reduzem a contagem de tokens. Minha infraestrutura de hooks usa a convenção verb-noun.sh (git-safety-guardian, recursion-guard, blog-quality-gate). O padrão consistente ajuda o tokenizador a prever e mesclar subpalavras comuns de forma eficiente.

Depurando comportamento inesperado

Quando um modelo produz uma saída inesperada, a tokenização pode explicar o porquê. Meu bug de formatação em coreano aconteceu porque o tokenizador dividiu [^1] de forma diferente no contexto coreano do que no inglês. Entender o padrão de divisão levou diretamente à correção (restrições explícitas de preservação).

Principais conclusões

Para engenheiros usando APIs de LLM: - Meça os custos de tokens por idioma antes de se comprometer com suporte multilíngue; idiomas CJK custam 2-3x mais por unidade semântica do que o inglês - Otimize as instruções dos prompts (redação concisa, restrições deduplicadas) para uma redução de 30-50% no custo em pipelines de tradução de alto volume - Teste a tokenização de termos específicos do domínio e sintaxe markdown antes do deploy em produção; divisões inesperadas causam bugs de formatação

Para gerentes de produto orçando funcionalidades de IA: - O suporte a idiomas não ingleses custa 1,5-3x mais por chamada de API do que o inglês; orce funcionalidades multilíngues de IA usando o multiplicador de idioma, não uma estimativa fixa por idioma - Os limites da janela de contexto afetam idiomas CJK desproporcionalmente; uma janela de 200K tokens comporta 40% menos conteúdo em coreano do que em inglês

Referências