AIに「読めない文字」がある理由
（グリッチトークンのしくみ）

by

関連記事

1. グリッチトークン

ChatGPTに「植物百科通って何ですか」と聞くと、奇妙なことが起きます。
モデルは関係のない単語を持ち出し、自分で混乱し、話が崩れていきます。
「次の言葉を復唱してください：植物百科通」と命令しても、まったく別の文字列が返ってきます。
同じ現象は bagbogbo や 给主人留下些什么吧 といった文字列でも再現できます。
かつてGPT-2では SolidGoldMagikarp、英語で「ソリッドな金のコイキング」という文字列がこの役割を担っていました1。

これらはグリッチトークンと呼ばれます。
LLMの語彙に存在しているのに、モデルが意味を知らない文字列です。
なぜそんなものが生まれるのかを理解するには、LLMが言語をどう扱っているかを見る必要があります。

2. LLMは文字ではなくトークンを読む

LLMはテキストをそのまま処理しません。
入力された文字列は、まずトークナイザーと呼ばれる変換器を通って「トークン」の列に変換され、それがモデルへの実際の入力になります。

トークンは文字と単語の中間にあるような単位です。
たとえば英語の “the” は1トークン、”strawberry” は “straw” と “berry” の2トークン、日本語の「の」は1トークン、「ありがとうございました」もまとめて1トークンになる場合があります。
GPT-4やGPT-5が使うトークン辞書には約20万種類のトークンが入っています2。

この辞書を作るアルゴリズムはBPEと呼ばれます。
Byte Pair Encodingの略で、仕組みは単純です。
大量のテキストを分析して「最も頻繁に隣接して現れる文字の組み合わせ」を1トークンにまとめ、これを繰り返して辞書が20万個に達したら完成とします3。

頻度が高いものが短く表現されるという性質は、人間の言語と同じです。
英語で “the” が1音節なのも、日本語で助詞が1文字なのも、よく使うものを短くするという言語の自然な圧縮の結果といえます。
BPEはその原則をデータから自動で学習します。

3. スパムと掲示板の名無しが語彙を汚染した

問題は、トークナイザーの学習データにあります。

OpenAIはウェブをクロールして学習データを集めましたが、そこにはクリーニングで除かれるべきスパムが大量に含まれていました。
スパムの特徴は同じ文字列が繰り返し複製されることで、ギャンブルやアダルト系の中国語文字列が何千回も現れていました。
BPEはそれを「高頻度ペア」と判断し、1トークンとして辞書に登録してしまいます。

日本語では「VIPがお送りします」と「風吹けば名無し」という2ちゃんねるの匿名投稿者名がトークンになっています。
これらは1000レスのスレッドに1000回登場するので、クロールデータに大量含まれていれば高頻度になります。

SolidGoldMagikarp の来歴はより具体的に追えています。
redditに「無限まで数を数えよう」というスレッドがあり、そのユーザーが65000回以上の投稿を残していました。
クロールがそのスレッドを拾い、ユーザー名が大量に複製されたテキストとして学習データに混入した結果、SolidGoldMagikarp が1トークンとして辞書入りしました4。

4. なぜ意味を学習できないのか

トークナイザーの学習と、LLM本体の学習は別のプロセスで、使うデータセットも異なります。
本体の学習では意味のある文章が中心になるため、スパムや掲示板のコピペは除外されるかごく少量しか残りません。

LLMはトークンが何を意味するかを、そのトークンが出てくる文脈から学びます。
しかし 给主人留下些什么吧 のようなグリッチトークンは、本体学習のデータにほとんど登場しません。
登場するとしても周囲がスパム文字列だらけで、文脈から意味を読み取れない。
結果として、モデルは「そのトークンが存在することは知っているが、それが何を指すのか知らない」状態になります5。

意味を知らないトークンを受け取ったモデルが辻褄の合わない出力を生成するのは、当然の帰結です。

5. 区切り線も1トークンになっている

トークン辞書を文字列の長さ順に並べると、スパムとは別の奇妙なものも出てきます。

----------------------------------------------------------------------------------------------------------------

このようなハイフン100本超の区切り線が1トークンとして登録されています。
マークダウン文書や掲示板の投稿で仕切りとして使われる区切り線は、コピーして貼られることで大量のテキストに登場し、BPEの判定で1トークンになってしまいました。
語彙の一枠を占領するだけで、何の役にも立ちません。

6. strawberry問題とトークン設計の課題

グリッチトークンは極端な例ですが、トークン化の設計が性能に影響するケースは他にもあります。

“strawberry” に r がいくつあるか聞かれると、かつてのLLMは頻繁に間違えました。
“strawberry” が1トークンになった瞬間、モデルからはその内部の文字構成が見えなくなるからです。
文字数を数える、ダジャレを言う、部分一致で検索するといったタスクをLLMが苦手とする理由のひとつがここにあります6。

BPEはそもそも英語向きの設計で、単語の間にスペースが入らない日本語や中国語では効率が落ちます。
日本語では漢字1文字が1トークンになることも多く、英語に比べてトークン消費が増えます。
言語ごとの特性を考慮したトークナイザーの研究は、今も続いています7。

グリッチトークンは、LLMが「文字を読んでいない」という事実を可視化する現象です。
意味の理解は文字からではなくトークンから始まり、そのトークン辞書はウェブの汚れた断面を映し込んでいます。
植物百科通という4文字が1トークンである理由は、まだ誰も特定していません。

  1. グリッチトークンを最初に体系的に報告したのは、Jessica RumbelowとMatthew Watkins（2023年1月、SERI-MATS）です。彼らはGPT-2とGPT-3において、通常のプロンプトに対して異常な出力を引き起こすトークンの集合を発見し、その現象を「glitch tokens」と命名しました。 – SolidGoldMagikarp (plus, prompt generation)
  2. GPT-4oから導入されたトークナイザー「o200k_base」は、辞書サイズが正確に200,000トークンです。OpenAIはtiktokenというライブラリとしてオープンソースで公開しており、誰でも利用できます。以前のモデルが使っていたcl100k_baseは10万トークンでした。 – tiktoken (GitHub)
  3. BPEはもともと1994年にPhilip Gageがデータ圧縮アルゴリズムとして発表した手法です。これをNLP（自然言語処理）のサブワード分割に応用したのが、Rico Sennrichらの2016年の論文「Neural Machine Translation of Rare Words with Subword Units」で、現代のLLMトークナイザーの基礎になっています。 – Neural Machine Translation of Rare Words with Subword Units
  4. r/countingコミュニティには「Hall of Counters」と呼ばれるリーダーボードがあり、SolidGoldMagikarpさんは上位にランクインするほど投稿数が多かったとのことです。同コミュニティの他のユーザー名（TheNitromeFan、RandomRedditorWithNoなど）も同様にグリッチトークン化していることが確認されています。 – SolidGoldMagikarp III: Glitch token archaeology
  5. グリッチトークンへの応答が単なるランダムではなく、アドレス不能な埋め込み空間（embedding space）の端に位置するトークンに対してモデルが不確定な挙動をとることが技術的に確認されています。LessWrongのPart IIでは、グリッチトークンの埋め込みが通常トークンの埋め込みクラスターから外れた位置に存在することが報告されています。 – SolidGoldMagikarp II: technical details
  6. strawberry問題は2024年ごろにSNSを中心に広く知られるようになりました。OpenAIの「o1」ファミリーは開発コード名が「Strawberry」とされており、文字カウントの失敗を克服することが開発目標のひとつだったとされています。学術的には、トークン化がこの問題の主因であることがNanjing University of Aeronautics and Astronauticsらの研究グループによっても論文で確認されています。 – Why Do Large Language Models (LLMs) Struggle to Count Letters?
  7. 非英語言語のトークン非効率性は「fertility（フェルティリティ）」という指標で測定されます。同じ意味の文を表すのに必要なトークン数が英語に比べて多いほどfertilityが高く、非効率とされます。韓国語・日本語・アラビア語などは英語の1.5〜3倍のトークンを消費することが報告されており、APIコストや文脈ウィンドウの実効サイズに影響します。 – Understanding Token Fertility: Why It Matters for Multilingual LLMs