Por que computadores não sabem ler

01 · Conceito

Conceito

Digite a palavra café numa caixa de chat e envie ao Qwen3.8-27B. Uma coisa perfeitamente banal de se fazer, e que esconde um problema que já quebrou sistemas em produção. Existem duas formas padrão de representar essa palavra em Unicode. Uma usa quatro code points, terminando num único caractere pré-composto para o e acentuado. A outra usa cinco, terminando num e simples seguido de um acento agudo combinante separado. Na tela, são indistinguíveis. Serializada em UTF-8, a primeira ocupa cinco bytes e a segunda, seis, porque o caractere acentuado custa dois bytes na primeira forma e o e sozinho mais o sinal combinante custam três na segunda.

O modelo nunca vê a sua tela. Seu tokenizer público recebe uma string Unicode e, nesta versão fixada, a normaliza para NFC antes do processamento byte-level. As duas grafias de café portanto convergem para a mesma string normalizada e os mesmos ids de token. Outras distinções — como um espaço comum versus um espaço não separável — podem sobreviver à normalização e produzir sequências diferentes. A lição não é que todo par visualmente idêntico difere, mas que a política de normalização declarada pelo tokenizer decide quais distinções chegam ao modelo.

Então acompanhe o caminho inteiro, nomeando o que cada etapa promete e o que não promete. A primeira fronteira é a codificação. O Unicode atribui code points a um repertório imenso de elementos de texto, e o UTF-8 define como cada code point vira de um a quatro bytes. Um valor de byte sozinho não significa nada sem saber qual codificação o produziu. Até a noção de caractere visível é escorregadia: um emoji com modificador de tom de pele e um zero-width joiner pode ocupar vários code points e ser desenhado como um único glifo, e o exemplo do café mostra que mesmo uma palavra latina com um acento tem mais de uma grafia legal em bytes.

A normalização pode forçar formas canonicamente equivalentes a coincidir, e o tokenizer fixado do Qwen3.8-27B aplica NFC explicitamente. Identificadores, senhas e código-fonte muitas vezes precisam preservar distinções que texto em linguagem natural aceita perder de bom grado. O espaço em branco carrega o mesmo risco: um espaço comum, um espaço não separável e um espaço estreito não separável parecem quase idênticos e são bytes completamente diferentes. Todas essas escolhas são feitas antes de qualquer modelo entrar em cena.

A segunda fronteira é a tokenization. Um tokenizer mapeia texto Unicode normalizado, por UTF-8 e BPE byte-level, para entradas do vocabulário e ids inteiros. Os artefatos do Qwen3.8-27B expõem 248.077 ids mapeados, enquanto esses ids indexam tensores com 248.320 linhas; as 243 linhas restantes não têm mapeamento no tokenizer publicado. Os ids em si são rótulos, não quantidades. O token 900 não é maior, nem posterior, nem mais importante que o token 12. O tokenizer deste modelo é byte-level, o que tem uma consequência enormemente útil: como seu alfabeto byte-level representa cada byte UTF-8 produzido a partir de uma string Unicode normalizada válida, o tokenizer não precisa de token desconhecido para esse texto. Isso não transforma a API pública de texto numa interface para binário arbitrário. A lição 1.2 examina o que esse vocabulário contém e a lição 1.3 mostra como ele foi construído.

Rode a ida e volta mentalmente. Após a normalização NFC, qualquer das duas grafias de café vira a mesma sequência de bytes UTF-8 e depois a mesma lista curta de ids. Cada id seleciona uma linha da tabela de embeddings, produzindo um vetor de 5120 dimensões como a lição 0.4 descreveu. Esses vetores atravessam 64 camadas, cada uma reescrevendo o estado. A camada final emite 248.320 scores para a próxima posição, um token é escolhido, e o decoder mapeia os ids escolhidos de volta para bytes e então para texto legível. Para ids produzidos ao codificar essa entrada normalizada, a decodificação reconstrói o texto normalizado, incluindo distinções que a normalização preservou, mas não pode recuperar uma grafia de code points canonicamente equivalente que o NFC substituiu. Ids arbitrários amostrados pelo modelo não correspondem a uma entrada codificada e, portanto, não têm garantia NFC; fragmentos de bytes malformados também podem exigir tratamento de substituição no decode.

Uma tabela de embeddings mapeia ids para vetores e, na inicialização, esses vetores não contêm definição alguma. O treino os remodela, junto com tudo que vem depois, para que as representações se tornem úteis à predição. Note que a mesma linha serve a toda ocorrência de um token. A palavra manga na fruteira e manga na camisa começam numa linha idêntica; são os tokens ao redor, misturados pelas camadas acima, que separam os dois estados. Significado, na medida em que a palavra se aplica, é propriedade de um estado contextual, não de uma entrada de vocabulário.

Sintaxe e semântica, portanto, não são entregues nem pelo Unicode nem pelo tokenizer. Elas emergem, imperfeitamente, de padrões nos dados de treino, do viés arquitetural e do objetivo de treino. Um modelo pode aprender que uma aspas de abertura prevê uma de fechamento mais adiante, que um sujeito restringe um verbo, ou que certos nomes coocorrem com certas profissões. Essas regularidades sustentam comportamento genuinamente útil sem equivaler a uma gramática explícita nem a uma base de conhecimento verificada.

A visão em camadas explica um catálogo de falhas reais. Bytes corrompidos quebram a decodificação antes de o modelo ser alcançado. Caracteres visualmente confundíveis podem esconder um identificador trocado no que parece texto comum. Um tokenizer azarado pode estilhaçar um idioma em muito mais posições que outro, o que a lição 1.4 converte em dinheiro. Grafias raras recebem representações fracamente treinadas. E um modelo fluente ainda pode ligar o referente errado do mundo real, porque seu objetivo premiava continuação provável e não verificação ancorada.

Computadores processam texto com sofisticação extraordinária, e cada etapa desse processamento tem um contrato estreito o bastante para caber em uma linha. O UTF-8 mapeia símbolos normalizados para bytes. Tokenizers mapeiam essa representação para ids. Embeddings mapeiam ids para vetores. Camadas transformam vetores. A decodificação mapeia scores de volta para tokens. Manter essas seis fronteiras distintas é o que impede o verbo vago ler de esconder onde a informação entrou, mudou ou se perdeu em silêncio.