Tokenizer Traces

A language model doesn’t read text the way you do. Before it computes anything, the text is broken down into small building blocks called tokens. A token might be a whole word, sometimes just a syllable, sometimes a single character. Which building blocks exist at all is decided once at the start and never changed afterward. This fixed list differs slightly from provider to provider, almost like a fingerprint. Tokenizer traces are the marks that this very list leaves behind in the finished model and in its responses.

What the traces reveal about a model’s origin

A model’s list of building blocks arises from the texts used to create it. Whoever used a lot of German text ends up with building blocks like “schaft” or “ungen”. Whoever mainly used programming code ends up with building blocks for brackets and commands. So the list roughly reveals what a model was built from.

That is more than a curiosity. In the industry, there are recurring disputes over whether a provider secretly trained its model on the outputs of a competitor. Such accusations are hard to prove. Matching or strikingly similar building-block lists are considered evidence, because two independently created lists practically never look the same.

But evidence is not proof. Many providers use the same freely available tools and the same public text collections. So similarity can also arise harmlessly. Experts therefore combine the traces with other clues before making any claim about origin.

How the building-block list arises and leaves traces

The list is built through a statistical process. One starts with individual characters and looks at which pairs stand next to each other especially often. These pairs are merged into a new building block. This is repeated tens of thousands of times until the desired number of building blocks is reached.

In the process, random byproducts inevitably emerge. If a spam text or a username appears very frequently in the source data, it becomes its own building block. Such odd entries stand out later and are especially easy to recognize. They are the actual core of what is called a trace.

The traces can also be made visible from the outside without opening the model. To do this, you type in unusual character sequences and observe where the model stumbles. It often behaves nonsensically for exactly those odd building blocks, because they barely occurred during training. A well-known example was a building block from an internet forum, for which a large model gave completely incoherent answers.

Where you encounter this topic in the news and in everyday life

Most often you read about this when a new model is released and experts dissect it within hours. On platforms for open models, the building-block list is often published alongside the model. Observers then compare it with known lists and post their findings. Such analyses now regularly end up in the business press, because a lot of money is riding on such accusations.

In everyday life, you notice the splitting in a different place: the cost. Anyone using an AI through a programming interface pays per token, not per word. For many models, German texts require noticeably more building blocks than English ones. So the same content can be noticeably more expensive in German.

A common misconception is that tokenizer traces are a watermark. A watermark is deliberately built in to later attribute texts. Traces, by contrast, arise unintentionally as a byproduct. That is exactly what makes them interesting, since they can hardly be concealed.