Hoe een taalmodel tekst leest

Deel 02De stukjes worden niet bedacht, maar geleerd

Het algoritme heet byte-pair encoding, afgekort BPE, en het is verrassend eenvoudig. Het komt uit de compressiewereld van de jaren negentig en werd later hergebruikt voor taalmodellen.

Het recept, om de lijst te leren:

1. Neem een enorme berg tekst en knip alles in losse tekens.
2. Tel welk paar naburige tekens het vaakst voorkomt.
3. Voeg dat paar overal samen tot één nieuw stuk, en noteer die regel.
4. Herhaal, tot je er genoeg hebt.

Meer is het niet. Er komt geen taalkunde aan te pas, geen woordenboek, geen grammatica. Puur tellen.

Wat eruit komt is een lijst van regels, in de volgorde waarin ze geleerd zijn. Regel 12 is e + n, want dat is een van de allervaakst voorkomende paren. Regel 47 036 is lij + k, veel zeldzamer. Die volgorde heet de rang.

Deel 03De lijst toepassen

Nu de andere kant: je hebt de lijst, en er komt tekst binnen. Begin met losse bytes en voeg telkens het paar samen met de laagste rang, tot er niets meer kan.

Hieronder gebeurt dat met het woord " gewichten", stap voor stap, met de echte rangen uit het modelbestand.

Kijk naar de rangen: 12, 36, 86, 109, 170, 4609, 22283, 28442. Ze lopen op. Kijk dan naar wáár in het woord de samenvoegingen gebeuren: eerst achteraan (en), dan in het midden (ic), dan vooraan (Ġg), dan weer in het midden. Het springt heen en weer.

Dat is het gedrag dat de meeste mensen verrast. Een tokenizer werkt niet als een lezer die van links naar rechts gaat. Hij werkt als iemand die eerst alle veelvoorkomende lettergrepen aan elkaar plakt, en pas daarna de zeldzamere combinaties.

Bij " tokenizer" zie je hetzelfde, maar dan tot het einde doorgezet:

rang 3       Ġ + t        -> Ġt
rang 5       e + r        -> er
rang 12      e + n        -> en
rang 55      Ġt + o       -> Ġto
rang 193     i + z        -> iz
rang 2456    k + en       -> ken
rang 2879    iz + er      -> izer
rang 3694    Ġto + ken    -> Ġtoken
rang 45702   Ġtoken + izer -> Ġtokenizer          één enkel token

Negen samenvoegingen om van tien losse bytes naar één token te komen. Het woord "tokenizer" kwam blijkbaar vaak genoeg voor in de trainingstekst om een eigen plek in de lijst te verdienen.

Deel 04De byte-truc, en dat rare teken Ġ

Tot hier deed ik alsof tekst uit letters bestaat. Dat is ze niet. In een computer is tekst een reeks bytes, en dat verschil is precies wat BPE zo robuust maakt.

Het probleem met werken op letters: er zijn er te veel. Unicode heeft meer dan 150 000 tekens. Zou je die allemaal als startpunt nemen, dan is je woordenschat op voorhand al vol.

De oplossing is om onder het niveau van letters te duiken. Er zijn maar 256 mogelijke bytes. Neem die als startpunt, en elke denkbare tekst — in elke taal, met elk emoji, zelfs een stuk van een fotobestand — kan gecodeerd worden. Er bestaat geen "onbekend woord" meer.

Waarom een spatie een eigen teken nodig heeft

Er zijn 94 bytes die overeenkomen met gewone zichtbare tekens: de letters, cijfers en leestekens. Die blijven zichzelf. Alle andere — spatie, tab, regeleinde, en alles boven de 127 — zouden onzichtbaar zijn of samenvallen met witruimte. Daar zou je bij het opsplitsen last van krijgen.

Daarom krijgt elke van die bytes een eigen zichtbaar plaatsvervanger, ergens in een ongebruikt hoekje van Unicode. De spatie wordt Ġ, het regeleinde wordt Ċ, de tab wordt ĉ.

Deel 05Eerst knippen, dan pas samenvoegen

Er ontbreekt nog een stap. Als je BPE zomaar op een hele zin loslaat, gaat het mis.

Stel dat "hond." vaak voorkomt aan het einde van zinnen. Dan zou BPE daar één token van maken, en zou "hond" mét punt iets anders zijn dan "hond" zonder. Dat wil je niet. Een punt hoort geen deel te zijn van een woord.

Daarom wordt de tekst eerst in brokken geknipt, met een reguliere uitdrukking, en gebeurt het samenvoegen alleen binnen een brok. Over de grens heen wordt nooit samengevoegd.

De uitdrukking die dat doet ziet er afschrikwekkend uit, maar bestaat uit zes losse regels achter elkaar:

// 1. Engelse samentrekkingen apart houden
(?:'[sS]|'[tT]|'[rR][eE]|'[vV][eE]|'[mM]|'[lL][lL]|'[dD])
// 2. een reeks letters, eventueel met één teken ervoor (meestal een spatie)
|[^\r\n\p{L}\p{N}]?\p{L}+
// 3. één cijfer
|\p{N}
// 4. leestekens, eventueel met een spatie ervoor
| ?[^\s\p{L}\p{N}]+[\r\n]*
// 5, 6. regeleindes en overige witruimte
|\s*[\r\n]+|\s+(?!\S)|\s+

Regel 3 is de interessante. Er staat \p{N} — één cijfer. Niet \p{N}+. Daardoor valt elk getal uiteen in losse cijfers.

Dat lijkt verspilling, maar het is een bewuste keuze. Als "2024" één token zou zijn en "2025" een ander, dan moet het model voor elk getal apart leren hoe groot het is. Met losse cijfers ziet het model de opbouw, en kan het leren rekenen op een manier die overdraagbaar is. Modellen die getallen in brokken van drie knippen — zoals Llama 3 — maken hier een andere afweging.

Deel 08Wat dit in de praktijk betekent

Vier gevolgen die je merkt zonder ooit een regel code te zien.

1. Nederlands is duurder dan Engels

Dezelfde zin, vertaald, en dan geteld:

Nederlands kost 43 % meer tokens dan Engels voor exact dezelfde inhoud. Dat betekent: 43 % meer rekentijd, 43 % meer van je contextvenster, en bij betaalde modellen 43 % meer geld. De reden is simpel — er stond nu eenmaal veel meer Engels dan Nederlands in de trainingstekst, dus zijn er meer Engelse brokken in de lijst terechtgekomen.

Je ziet het terug in losse woorden:

2. Modellen kunnen de letters van een woord niet zien

Vraag een taalmodel hoeveel keer de letter r in "strawberry" voorkomt, en het antwoordt vaak fout. Dat is geen gebrek aan intelligentie maar een gevolg van de tokenizer.

Voor het model is " strawberry" één ondeelbaar nummer: 72600. Het ziet geen s, geen t, geen r. Het heeft ooit geleerd dat dat nummer met aardbeien te maken heeft, maar de spelling zit er niet in — net zomin als jij aan het cijfer 7 kan zien hoeveel streepjes er in het woord "zeven" zitten.

Aan het begin van een zin, zonder spatie ervoor, valt het woord toevallig wél uiteen in strawberry — en dan gaat het soms opeens wel goed. Dat verklaart waarom hetzelfde model dezelfde vraag de ene keer juist en de andere keer fout beantwoordt.

3. Getallen zijn duur

Een jaartal kost vijf tokens, een rekeningnummer dertig. Wie tabellen met cijfers aan een model voert, betaalt daar stevig voor. Een tabel van duizend getallen kan makkelijk vijfduizend tokens kosten — meer dan tien bladzijden gewone tekst.

4. Structuur kost meer dan proza

JSON is voor een tokenizer heel duur: alle accolades, aanhalingstekens en dubbele punten zijn losse tokens. Dezelfde gegevens in gewone zinnen zetten scheelt vaak de helft. Bij dit model kostte een klein JSON-fragment 31 tokens waar de Engelse zin er 14 nodig had, terwijl beide ongeveer even lang waren.