A palavra "Google", por exemplo, pode ser codificada como um único token ["Google"] ou como dois tokens ["Go", "ogle"]["G", "o", "o", "g", "l", "e"]
Isso gera dois problemas que se acumulam:
Primeiro, a camada de embedding não captura totalmente a informação característica. Pesquisas indicam que essas camadas armazenam um bom nível de informação apenas sobre o primeiro caractere de cada token. Para o restante, o detalhamento a nível de letra se degrada rapidamente . Quando um modelo precisa contar letras, ele tenta reconstruir a sequência de caracteres a partir de uma representação numérica que nunca foi projetada para preservar essa informação. Camadas posteriores do Transformer podem compensar parcialmente — pesquisadores observaram um "ponto de virada" em que o modelo finalmente consegue soletrar um token corretamente —, mas o processo é frágil e nada confiável
.
Segundo, os tokenizadores de subpalavras são, em grande parte, "ignorantes quanto à estrutura interna dos tokens". Um estudo de 2024 cunhou o termo 'a maldição da tokenização' para descrever essa vulnerabilidade: os tokenizadores são inerentemente sensíveis a erros de digitação, variações de tamanho e cegos para a composição interna das palavras . Um termo como "journalism" pode virar um token único — o modelo jamais aprendeu a decompô-lo em
j-o-u-r-n-a-l-i-s-m. Por isso, na hora de soletrar, ele simplesmente chuta.
O resultado é exatamente o que os usuários viram: uma IA que debate filosofia e escreve códigos de programação com maestria, mas insiste que "Google" tem dois 'p's ou que "poop" contém exatamente um 'r' .
Se a raiz do problema está na tokenização, a solução intuitiva seria usar modelos que trabalhem diretamente com caracteres ou bytes, permitindo que a IA enxergue cada letra. Essa abordagem existe — modelos como o ByT5 processam os bytes brutos do texto —, mas ela nunca foi amplamente adotada porque torna os modelos dramaticamente mais caros de executar .
Migrar para um processamento puro por caractere aumenta o comprimento das sequências de texto em cerca de 3 a 5 vezes, elevando o custo computacional na mesma proporção. Isso também dificulta que o modelo aprenda relações semânticas de longo alcance . Os tokenizadores de subpalavras são o grande acordo de eficiência que viabilizou os LLMs modernos. Eles comprimem o texto em vocabulários de tamanho gerenciável, preservando significado suficiente para gerar uma linguagem fluente.
Pesquisadores concordam, em linhas gerais, que provavelmente não existe um tokenizador 'perfeito' . Esses sistemas "rotineiramente produzem codificações não únicas" e criam um "descompasso de representação" que é profundamente arquitetural — não se trata de um simples bug que pode ser corrigido com um patch
. A troca entre precisão em nível de caractere e fluência semântica parece ser uma limitação inerente à arquitetura dos Transformers.
As falhas de soletração expõem várias limitações estruturais que vão muito além do Google AI Overviews.
LLMs são casadores de padrões, não manipuladores de símbolos. Contar letras é uma tarefa algorítmica trivial para qualquer computador rodando um código tradicional. Mas os LLMs não executam algoritmos — eles preveem o próximo token mais provável com base em padrões estatísticos nos dados de treinamento . Quando perguntamos quantas letras existem, o modelo gera a resposta que "soa" mais plausível a partir de associações aprendidas, não uma operação real de contagem.
A confiança da resposta não tem relação com sua veracidade. A IA respondeu "duas" com uma fluência gramatical impecável, mas estava objetivamente errada. Esse é um sintoma clássico das alucinações de IA: afirmações convincentes e bem-escritas, sem nenhum mecanismo interno de verificação. Em 2024, o próprio Google admitiu que, embora o AI Overviews seja "projetado para mostrar apenas informações respaldadas pelos principais resultados da web", ele ainda pode "interpretar mal consultas ou nuances da linguagem" .
O ponto cego é arquitetural, não incidental. Todo grande modelo de linguagem que usa tokenização de subpalavras — incluindo produtos da OpenAI, Anthropic e Meta — apresenta fraquezas semelhantes em tarefas de manipulação de caracteres, como soletrar palavras de trás para frente, contar letras ou lidar com anagramas . Aumentar a escala dos modelos ajuda marginalmente, mas o viés estrutural permanece
.
Essas falhas podem parecer vexatórias — uma IA de última geração que não sabe soletrar o nome da própria empresa —, mas a indústria não as trata como uma crise porque o enorme valor dos LLMs está em outro lugar.
Geração de texto fluente, sumarização, raciocínio, tradução, geração de código... Todas essas capacidades vêm da habilidade do modelo de trabalhar no nível semântico, onde a abstração via tokens é uma vantagem, não um defeito . A precisão em nível de caractere simplesmente não é o objetivo que essas arquiteturas foram desenhadas para otimizar.
A solução prática tem sido redirecionar consultas de soletração e contagem para softwares tradicionais baseados em regras, em vez de pedir que o LLM lide com elas. Várias implementações do AI Overviews já tentam detectar e desviar essas perguntas — embora os erros amplamente divulgados em maio de 2026 provem que essa detecção ainda é imperfeita . Um estudo separado revelou que o Google AI Overviews responde a perguntas sobre inversão de ortografia de forma errada em 52% das vezes. Para palavras com três sílabas ou mais, apenas 10% foram invertidas corretamente
.
O Google continua trabalhando em correções para os problemas de contagem que se tornaram públicos . Mas, para quem entende as complexidades do dilema da tokenização, a verdadeira lição não é que o Google lançou um produto com bugs. É que a arquitetura que está impulsionando a revolução da inteligência artificial tem um calcanhar de Aquiles fundamental — e ninguém, até agora, descobriu como resolvê-lo sem sacrificar justamente aquilo que torna os LLMs tão valiosos.
Comments
0 comments