トークンとトークン化：なぜモデルはテキストを奇妙に見るのか

言語モデルに文をタイプするとき、あなたは単語を見ています。モデルは見ていません。いかなる「思考」が起きる前にも、あなたのテキストはトークンと呼ばれる断片に刻まれ、モデルが実際に処理するのは——文字でも単語でもなく——そのトークンです。この単一の翻訳ステップが、さもなければ不可解な振る舞いを驚くほど多く説明します。なぜモデルが単語の文字数を数え間違えるのか、なぜ一部の言語は処理により高くつくのか、なぜ入力が思ったより早く長さ制限に達するのか、そしてなぜ奇妙な文字列を貼り付けるとときに奇妙な出力が出るのか。いったんトークン化を理解すれば、多くのモデルの癖が謎でなくなります。

トークンとは実際に何か

トークンはテキストの塊——たいていはよくある単語、単語の一部、空白＋単語、あるいは一文字です。モデルが読み書きする単位です。「the」のような短くよくある単語は、しばしば一トークンです。より長いまたはまれな単語はいくつかに分割され得ます。「tokenization」のようなものは「token」＋「ization」になるかもしれず、珍しい名前は多くの小さな断片に砕けるかもしれません。

肝心な洞察は、トークンが単語とも文字とも同じではないということです。その中間に座っています。モデルの言語観全体が、これらの塊から構築されます。応答を生成するとき、モデルは一度に一トークンずつ、その前に来たトークンに基づいて各々を選びながら、生み出しています。文字や文まるごとを一次的な単位として扱う段階はどこにもありません。

そもそもなぜテキストを分けるのか

モデルに単語まるごと、あるいは一文字ずつを与えるほうが単純に思えます。どちらの極端も問題を引き起こし、トークン化はその妥協です。

単語まるごとを使えば、語彙は膨大になり、それでも見たことのない単語に絶えず出くわします——誤字、新しいスラング、専門用語、名前。モデルはそれらを扱う術がありません。

一文字を使えば、語彙は小さく、何一つ未知でなくなりますが、どんなテキストも非常に長い列になり、モデルは生の文字から意味をゼロから学ばねばなりません。それは無駄で遅い。

トークン化はその差を分け合います。よくある単語は効率のために独自のトークンを得ます。まれな単語はより小さな再利用可能な断片に分けられるので、モデルはなじみある断片を組み立てることで何でも扱えます——見たことのない単語でさえ、その断片は見たことがあるからです。これがモデルが新奇な単語を優雅にこなす理由です。サブワードの部分から意味を再構成するよう作られているのです。

なぜモデルは「テキストを奇妙に見る」のか

ここに肝心な帰結があります。モデルがトークンに対して動作するため、人間には自明なある種のタスクが、モデルには妙に難しくなります。

単語の文字を数えること、それを逆さにすること、二つの単語が韻を踏んでいると気づくことを考えてみましょう。あなたにとってこれらは個々の文字についてのものです。しかしモデルはその単語まるごとを単一のトークン——内部の文字が見えない不透明な塊——として受け取ったかもしれません。単語の中のrの数を数えるよう頼むのは、まるごとの形としてしか認識していない記号の文字数を数えるよう誰かに頼むようなものです。情報は技術的には回復可能ですが、モデルがテキストを表現する仕方に逆らいます。これが多くの「AIは綴れない」逸話の本当の理由です。愚かさではなく、文字レベルの構造が、モデルが読むまさにその単位によって部分的に隠されているのです。

同じ効果が、モデルが正確な文字操作、一桁ずつ書かれた特定の算術、そして意味ではなく文字列の正確な内部構成に依存するタスクで不安定になり得る理由を説明します。

なぜ同じテキストが異なる量になるのか

トークンは計量と課金の単位でもあります。モデルの利用と価格は、たいてい単語や文字ではなくトークンで数えられます。これは身につける価値のある実用的な帰結を持ちます。

異なる言語は非常に異なる効率でトークン化されます。トークナイザーの訓練でよく表された言語のテキストは、考えあたり少ないトークンに収まる傾向がある一方、他の言語——あるいはトークナイザーが効率悪く扱う文字体系——は同じ内容を表すのにずっと多くのトークンを要し得ます。結果として、同一の意味が、ある言語では別の言語より目に見えて高く処理されることになります。コード、構造化データ、珍しい記号だらけのテキストといった内容も同様です。見た目の長さが同じ平文の散文より多くのトークンに断片化し得ます。

典型的な英語の散文についてよく引かれる大まかな目安は、トークンが平均して一単語より少し少ないものに対応する、というものです——しかしそうした比率はどれも、定数ではなく緩い指針として扱いましょう。トークン数を確実に知る唯一の方法は、その特定のモデルのトークナイザーで測ることです。各モデルファミリーが異なるトークン化をし得るからです。

トークンとコンテキストウィンドウ

すべてのモデルはコンテキストウィンドウを持ちます。一回のやり取りで取り込み生み出せる、入力と出力を合わせたトークンの最大数です。その制限はトークンで測られ、それゆえ同じウィンドウが、何を入れるかによって大きくも小さくも感じられます。

これが長文書タスクに注意を要する理由でもあります。画面で中くらいに見える文書が、推測よりはるかに多くのウィンドウを消費するかもしれません——とりわけトークン化が冗長な言語や、書式と記号だらけの場合は。大きな入力を扱う何かを設計するときは、ページや文字ではなくトークンで考えることが、切り詰められた入力や制限を静かに超えるリクエストに驚かされるのを防ぎます。

実用的な含意

トークンがメンタルモデルの一部になると、いくつかの習慣が自然に従います。

• モデルに文字レベルの外科手術を気軽に頼まない。 文字を数える、文字列を逆さにする、といった類似のタスクはトークン表現と戦います。確実に行わせる必要があるなら、モデルの直観ではなくツールに頼りましょう。
• コンテキスト制限の近くにいたりコストを見張ったりするときは、長さを単語ではなくトークンで見積もる——そして重要なものは推測ではなく測りましょう。
• コストと長さが言語や内容の種類で変わると見込み、言語間で同等だと仮定せず、それに応じて予算を組みましょう。
• 見た目の長さを過信しない。 短く見えるコードや記号の塊はトークンが重いことがあり、長く続く平文の散文は見かけより軽いことがあります。

まとめ

トークンは、あなたのテキストとモデルの間の隠れた層です。モデルが読み書きするすべては、これらの塊——たいていは単語と単語の断片——でできており、扱いにくい単語まるごとの語彙と非効率な一文字ずつの処理の間の妥協として選ばれます。その妥協こそが、モデルがどんなテキストも優雅にこなせるようにするものですが、同時に文字レベルのディテールを隠し、それゆえ正確な綴りや文字タスクでつまずかせます。それはトークンを、長さ・コスト・コンテキスト制限を測る自然な単位にし、同じ考えがある言語で別の言語より高くつき得る理由を説明します。トークンを直接調べる必要はめったにありませんが、念頭に置いておけば、一群の奇妙なモデルの振る舞いが予測可能なものになります。