LLMs ganham acesso a cada letra, e escrever palavras de trás para frente fica mais fácil para elas

A frase «LMU München» tem 11 caracteres, contando o espaço. O modelo de linguagem por trás do ChatGPT a recebe em três pedaços: «LM», «U» e «München». As letras individuais de «München» o modelo não vê diretamente. Essa característica explica toda uma classe de erros estranhos: contar letras em uma palavra, fazer edições caractere por caractere, escrever ao contrário. De acordo com o TechXplore, pesquisadores mostraram que, se o modelo for ajustado para enxergar cada letra, inverter uma palavra fica mais fácil para ele.

Por que o modelo não vê as letras

Antes de processar o texto, a LLM o divide em tokens: palavras inteiras ou fragmentos delas. Essa etapa se chama tokenização em subpalavras. Ela existe por eficiência: a sequência fica mais curta e, portanto, mais barata em computação. Palavras frequentes viram um único token, e as raras são montadas a partir de vários.

Essa economia tem um preço. Para o modelo, o token «München» continua sendo um identificador indivisível. Para inverter a palavra, ele precisa saber de quais letras ela é feita, e não consegue descobrir isso diretamente. O conhecimento de ortografia precisa ser reconstruído de forma indireta, a partir de textos de treinamento em que as palavras às vezes são soletradas. O resultado é pouco confiável. Com isso, os modelos têm um entendimento limitado no nível dos caracteres, algo que a fonte original afirma de forma explícita.

O que significa «ver cada letra»

No trecho disponível da publicação, a estrutura do aprimoramento não é descrita. Tamanhos de modelo, precisão e benchmarks também não aparecem, então não há números concretos de melhoria aqui. O princípio geral fica claro pelo título: o modelo passa a ter acesso a caracteres individuais, e não só a pedaços já prontos.

Na indústria, o caminho costuma ser usar modelos de caracteres ou de bytes, ou acrescentar um nível de caracteres sobre os tokens. Mas essa abordagem também tem custo: as sequências ficam mais longas. E o custo da atenção nos transformers cresce mais rápido que o tamanho da entrada. Por isso, a questão não é se o acesso a caracteres ajuda. Ele ajuda. A questão é quanto custo computacional será preciso pagar por isso.

Em resumo, o que se sabe a partir do material:

• Exemplo de divisão: «LMU München» vira 3 tokens («LM», «U», «München») para 11 caracteres.
• Mecanismo do problema: a tokenização em subpalavras esconde do modelo as letras individuais.
• Tarefa de teste: escrita invertida de palavras.
• Resultado: modelos que veem cada letra lidam com ela com mais facilidade.
• Não divulgado no texto disponível: arquitetura, tamanhos dos modelos, métricas numéricas.

O que fazer como desenvolvedor

Enquanto esses modelos não se tornam padrão, é melhor não confiar cegamente na LLM para operações com caracteres em produtos. Validação de códigos e números, anagramas, transliteração, comparação caractere por caractere, correção de erros de digitação em nomes: tudo isso é mais seguro de fazer com código convencional. Nesses cenários, vale acionar o modelo como orquestrador, que repassa a tarefa a uma ferramenta, e não como executor.

É preciso ter cuidado especial com idiomas em que as palavras têm morfologia rica. Os tokenizadores de alemão e de russo costumam fragmentar mais do que os de inglês, e os erros de caracteres aparecem com mais frequência. Se você está escolhendo um modelo para esse tipo de trabalho, teste-o com seus próprios dados: rode uma dezena de strings reais suas e veja o resultado.

Quanto ao estudo em si, vale esperar o texto completo, com os números. A direção parece razoável, mas a pergunta principal continua em aberto: o ganho em precisão no nível dos caracteres será suficiente para justificar o aumento do custo computacional?