LLMs Taught to See Every Letter Find Reversing Words Easier

The phrase "LMU München" is 11 characters long, counting the space. The language model behind ChatGPT receives it as three chunks: "LM", "U" and "München". The model does not directly see the individual letters of "München". This quirk lies behind a whole class of odd errors: counting letters in a word, character-by-character edits, spelling backwards. According to TechXplore, researchers have shown that if a model is modified so that it sees every letter, reversing a word becomes easier for it.

Why the model can't see letters

Before processing text, an LLM breaks it into tokens: whole words or fragments of them. This step is called subword tokenization. It exists for efficiency: the sequence gets shorter, and therefore cheaper to compute. Frequent words become a single token, while rare ones are assembled from several.

This saving comes at a cost. To the model, the token "München" remains an indivisible identifier. To reverse the word, it needs to know which letters it consists of, and it cannot learn that directly. It has to reconstruct spelling knowledge indirectly, from training texts in which words are sometimes spelled out letter by letter. The result is unreliable. As a consequence, models have a limited understanding at the character level, and the source material states this explicitly.

What "seeing every letter" means

The available excerpt of the publication does not describe the design of the upgrade. It also gives no model sizes, accuracy figures or benchmarks, so there will be no specific improvement numbers here. The general principle is clear from the headline: the model gets access to individual characters, not just to ready-made chunks.

The industry usually does this with character-level or byte-level models, or by adding a character level on top of tokens. But this approach has a cost too: sequences get longer. And the cost of attention in transformers grows faster than the input length. So the question is not whether character access helps. It does. The question is how much extra compute you have to pay for it.

A quick summary of what the material establishes:

• Example of splitting: "LMU München" becomes 3 tokens ("LM", "U", "München") for 11 characters.
• Mechanism of the problem: subword tokenization hides individual letters from the model.
• Test task: spelling words backwards.
• Result: models that see every letter handle it more easily.
• Not disclosed in the available text: architecture, model sizes, numerical metrics.

What developers should do

Until such models become standard, don't take an LLM's word for it on character-level operations in your products. Validating codes and numbers, anagrams, transliteration, character-by-character comparison, fixing typos in names: all of these are more reliable with ordinary code. In such scenarios, call the model as an orchestrator that hands the task to a tool, not as the executor.

Be especially careful with languages whose words are rich in morphology. German and Russian tokenizers usually split text more aggressively than English ones, and character-level errors show up more often there. If you are choosing a model for this kind of work, test it on your own data: take a dozen of your real strings, run them through, and see what comes out.

It is worth waiting for the full text of the study, with its numbers, before judging it. The direction looks sensible, but the main question remains open: will the gain in character-level accuracy be enough to justify the rise in compute cost?