ハクソク

世界を動かす技術を、日本語で。

トークン化に対する厳しい教訓が迫っている

335日前原文(lucalp.dev)

概要

  • LLMのトークナイゼーション廃止 が望ましい理由と実現可能性の高まりを解説
  • トークナイゼーションの役割と脆弱性、およびその問題点を分析
  • Byte Latent Transformer など新しいアプローチの可能性とメカニズムを紹介
  • 従来のBPEやバイトレベル手法 の限界と課題を整理
  • 今後の設計空間と研究動向 に焦点を当てた議論

トークナイゼーションなきLLMの世界：実現可能性とその意義

  • LLM（大規模言語モデル） の発展において、 トークナイゼーション は長らく不可欠な仕組み
  • Byte-Pair Encoding（BPE） などの手法が主流だが、 情報損失や効率性の問題 を抱える現状
  • 理想的なトークナイザー は、圧縮率と表現の粒度の最適バランスを実現する必要
  • 実際には、 タスクごとに最適なトークン設計 が難しく、 「グリッチトークン」 などの問題も発生
  • サブワード分割の設計ミス やモデル能力とのミスマッチも、性能の足かせとなる

トークナイゼーションの問題点と歴史

  • BPEトークナイザー の設計は、 効率性のための情報切り捨て を招く場合が多い
  • OpenAIの「SolidGoldMagikarp」トークン現象 や、 GPT2の数字・スペースの扱い問題 など、具体的な失敗例多数
  • 問題発覚後は パイプライン修正や自動検出 で対処するが、根本的な解決には至らず
  • マルチモーダル分野 でも、各モダリティごとに独自トークナイザーを設計する必要があり、 外部依存・複雑化 が進行

トークナイゼーションの「無視」と「削除」は可能か

  • 現状のトークナイゼーション問題 は、 Chain of ThoughtやRAG、推論型モデル の工夫で一部緩和
  • それでも トークナイザー設計の最適化 が進んでおらず、 モデル能力の上限を制約
  • GoogleのByT5 はトークナイザーを完全に除去し、 バイトレベルでの学習 を実現
    • 性能は維持 できるが、 学習・推論コスト増大 というトレードオフ
  • State Space Model（SSM） 系の MambaByte など、 新アーキテクチャ も登場
    • 入力長依存の問題 や 推論ステップ増加 など、課題も残存

「学習可能なトークナイゼーション」への道

  • BPEの発展形 として、 確率的マージやカリキュラム学習 などの改良案が提案
    • しかし 本質的な解決策 とは言えず、 スケーリング性能の向上 も限定的
  • トークナイザー自体をモデルと共同で最適化 するアプローチが理想
    • 実運用では 適用の難しさ が課題

設計空間の最前線と今後

  • Transformer系アーキテクチャ では、 バイトレベル効率化 が研究の焦点

  • ダウンサンプリング／アップサンプリング や FLOPS配分、 デコード戦略 など、設計選択肢が拡大

  • Perplexityの代替指標 として Bits-per-byte（BPB） が利用される傾向

    • BPB(x)=ℒCE(x) / [ln(2)・nbytes] という数式で評価

  • Byte Latent Transformer などの新方式が、 トークナイザーの限界突破 を目指す

このように、 従来型トークナイゼーション の問題認識と、 バイトレベルや学習型トークナイザー への潮流が明確化。今後は 効率性・汎用性・スケーラビリティ の観点から、 より一般的な表現学習 が進展する見通し。

Hackerたちの意見

トークン化について考えると、次のトークンを予測する際に理論的なボトルネックがあることに気づいた。例えば、15,000個のユニークなトークンがあるとしよう（最近のオープンモデルに基づいて）。さらに、埋め込みの次元が1,000だと仮定すると、出力には最大1,000の自由度（またはランク）があることになる。モデルは15,000個のトークンの中から1つをトップトークンとして選べるけど、_確率分布_の表現力は1,000のユニークな線形成分に制限されているんだ。

└

実際には、そこには組み合わせの力があると思う。もしxとyの2次元だけで何かを埋め込むと想像すると、実際には無限の概念をエンコードできる。なぜなら、大きな2Dマップ上に分散した異なるクラスターや近隣を想像できるから。もちろん、次元が増えればそれはもっと可能になる。

└

理論的なボトルネックは存在するけど、君が言っているほど制約は厳しくないよ。なぜなら、ほぼ直交するベクトルの数は、周囲の次元数が増えるにつれて指数関数的に増えるから。直交性が異なるベクトルを区別するために重要なんだ。どんな分布もガウス分布の混合として表現できるから、そうした混合でエンコードできる別々の概念の数も指数関数的に増える。

└

君はモデルが次のトークンを予測しようとしていると仮定しているみたいだけど、本当にそうなの？僕はトークン化が入力専用の手段だと思ってたから、最大で50,000個のユニークな入力トークンが利用できるけど、出力は生のテキストや合成音声、画像だと思ってた。出力はトークンじゃないから、出力に制限はないよね。

└

重要な洞察は、完全に直交していないベクトルでも異なる特徴を表現できるということだ。例えば、85度から95度の間のように、ほぼ直交している場合だね。こうしたノイズを許容すれば、次元の数に対してフィットできるベクトルの数が指数関数的に増える。12288次元（GPT-3のサイズ）では、40億以上のほぼ直交するベクトルをフィットさせることができるよ。[1]: https://www.3blue1brown.com/lessons/mlp#superposition

└

制限のいくつかの側面を探る博士論文： https://era.ed.ac.uk/handle/1842/42931 ボトルネックのあるニューラルネットワークにおける非argmax出力の検出と防止、アンドレアス・グリバス（2024）

└

（私はしばらく前に学界を離れたので、これが無意味かもしれないけど）確か、これは非線形性がモデルにより表現力を与えるから、正しくないと思う。15kから1kへの変換は、めったにアフィンマップじゃなくて、通常は非常に非線形だよ。

逆に言えば、大規模な計算を問題に投じることで、よりシンプルで一般的な解決策の存在を隠すこともできる。一般的な手法は時間が経つにつれて勝つ傾向があるけど、もし一つのパラダイム（例えばLLM）に固執して、基盤となる構造を探求するのをやめたら、本当にそれが最も一般的な方法だと言えるのかどうか、確信が持てないよね。

└

計算理論に基づく分析を通じて確信が持てるよ。例えば、https://arxiv.org/abs/2503.03961 や https://arxiv.org/abs/2310.07923 などね。これによって、モデルが解決できる問題のクラスがわかるし、十分に深いトランスフォーマーと考えの連鎖があれば、非常に大きなクラスの問題を理論的に解決できることが示されている。

└

俺の考えでは、探索と活用の観点から見ると、最も報酬をもたらす行動に大半の努力を注ぎつつ、少しだけ他の行動を探索するのはかなり合理的だと思う。で、その行動が他の行動と比べてあまり実を結ばなくなったら、以前の探索から得たリソースを使って、もっと探索に力を入れるって感じかな。

└

コンピュータサイエンスにはこういうトリビアルな例がたくさんあるよね。最適化された並列SIMDマージソートを使えば、10兆件のレコードをすごく早くソートできるけど、ハードウェアを増やせばバブルソートでも同じくらい早くソートできる。AIの本当の苦い教訓は、私たちが何をやっているのか本当に分かっていないってこと。モデルをハッキングして、うまく訓練できるアーキテクチャを探しているけど、なぜそれがうまくいくのかは完全には理解していない。だから、最適なものを設計することもできないし、どれくらい良い解決策が得られるかも分からない。

そうだね、ネットワークをもっと深くしよう。ハンマーしか持っていないときは…トークンをより意味的に関連付ける変換層が、その後のネットワーク全体を最適化して、コンテキストウィンドウの実効サイズを増やすのは理にかなってるよね。今のモデルが知能を持つのを妨げている主な障害の一つは、コンテキストウィンドウのサイズだし。一方で、現在のモデルはトレーニングに国のGDPの中央値に相当するコストがかかっていて、その価値には全然達していない。 「力任せで問題が解決しないなら、もっと力を入れなきゃ」という言葉は、冗談として聞くべきだよ。

└

中央の国のGDPは大体1000億ドルくらいだと思う。モデルは高いけど、そんなに高くはないよ。

└

あなたの言いたいことは分かるけど、「中央値の国のGDPに沿った何かで訓練する」っていう証拠はあるの？ これって本当に正しいの？

反論としては、理論的に言えば、最高ランクの純粋数学者でも、1日に数回のマクドナルドの食事分のエネルギーが必要だってことだね。

└

ただ、マクドナルドの食事だけで長生きする人はいないよね。

"strawberry"の中のrの数を検出できないこと meme 誰か（LLMについて知ってる人）、"strawberry"のrの数がトークン化とどう関係してるのか説明してくれない？各文字が1トークンだったら、LLMが文字を数えるのが上手くなる理由はないと思うんだけど。彼らはそれを「見る」わけじゃないしね。何か理由があってトークンを数えるのが文字より得意なの？それとも、ただの誤解から生まれた話で、知識のない人に賢く見せようとして広まっただけ？

└

じゃあ、どっちが簡単かっていうと：このシーケンスの中のRの数を数えてみて：[496, 675, 15717] このシーケンスの中の18の数を数えてみて：19 20 18 1 23 2 5 18 18 25

└

一連の文字が「トークン」にグループ化される。すべての可能なシーケンスの集合が語彙を形成する。一般性を失わないように、例を考えてみよう：strawberry -> straw | ber | ry -> 3940, 3231, 1029 -> [各トークンのベクトル]。モデルへの生の入力は文字のシーケンスではなく、特定の文字の塊に対する学習されたベクトルを表すトークン埋め込みのシーケンスだ。この埋め込みには、トークン内の個々の文字に関する明示的な情報は含まれていない。その結果、モデルが文字について推論する必要がある場合、たとえば単語の文字数を数えるためには、各トークンの文字構成を記憶する必要がある。GPT-4のような大規模モデルが10万〜20万のトークンを使っていることを考えると、モデルがすべてのトークンの文字の内訳を記憶していないのは驚くことではない。トレーニングデータに「文字レベル」の質問がどれだけあるのか想像できない。対照的に、各文字がユニークなトークンにマッピングされる文字レベルの語彙で訓練されていれば、単語全体の文字数を記憶する必要はなかったはず。代わりに、見たことのない単語に対しても、すべてのシーケンスで文字を数える一般化可能な方法を学ぶことができたかもしれない。トークンを「見ていない」っていうのがどういう意味かよく分からないけど、彼らは確実に各トークンの表現を入力として受け取っているよ。

└

例えば文字レベルで訓練されたLLMが「Rを数える」ことができるという証拠を見ない限り、この説明を他の仮説より信じられない。文献には詳しくないから、これが行われたかどうかは分からないけど、サクッと検索しても何も見つからなかった。もし誰かが成功裏にやったなら、きっと発表しているはずだよね。

└

トークンの説明には納得できないな。RLHFの作業には「___の数を数えろ」ってプロンプトがめちゃくちゃあったから。AI企業がトークン化のエラーだけでRLHFにそんなにお金をかけるわけがない。たぶん、Redditではストロベリーミームに「トークン化だ！」って叫んで、自分たちの問題がトークン化を改善すれば解決するって信じてたんだろうけど、一方でRLHFの人たちは何千もの「数える」プロンプトや完璧な構文の問題を解決するためにお金をもらってた。だから、RLHFの作業がこれらの問題に取り組むためにお金が支払われてる以上、単純なトークン化の問題じゃないと思う。もしトークン化のボトルネックを直せば問題が解決するなら、そんなにお金をかけてRLHFの構文完璧なプロンプトに取り組むことはないはずだよ（数独みたいなゲームや重い構文ベースの問題を考えてみて）。今モデルが良くなってるのは、これらの問題がRLHFのおかげだから。で、「今のモデルは一般的に数を数えることを学んだ」と言う前に、少し抽象度を広げればモデルはまた失敗するって言いたい。これがLLMの永遠の物語になるだろうね。彼らは自分たちで先に進むことは決してないし、人間が情報を処理する方法とも違うけど、それでも役に立つことはある。

└

トークンはLLMの最も基本的な入力単位だよ。でも、トークンは一般的に単語全体に対応するわけじゃなくて、むしろサブワードのシーケンスなんだ。だから「ストロベリー」は「ストロ」と「ベリー」の二つのトークンに分かれるかもしれない。特定の文字のシーケンスみたいな「サブトークン」を区別するのが難しいのは、文字のシーケンスを見るんじゃなくて、トークンを一つの原子単位としてしか見てないからなんだ。システムへの基本的な入力は、一つの入力状態が別の状態とどう区別されるかなんだけど、入力状態の間でアイデンティティを認識するには、その状態が同一でなければならない。ちょっと直感に反するけど、個々の文字とトークン内の文字のアイデンティティはトークン化の特性のせいで失敗するんだ。「ストロ」と「r」は二つのトークンだけど、LLMは「ストロ」に「r」が一つ含まれていることを全く気にしない。トークンは区別の基本単位で、「ストロ」はs-t-r-a-wのトークンのシーケンスとして表現されるんじゃなくて、完全に独立した存在だから、等しいとも部分的に等しいとも見なされない。たとえば、あなたの目に単色の画像を見せながら、網膜の三つのコーンタイプの相対的な活性を特定するように頼むことができるけど、もちろんそれはできないよね。あなたはその情報に認知的にアクセスできないから。個々の色の経験があなたの基本的な視覚トークンなんだ。実際、少し前にGrokにこの質問をしたことがあって、単語の母音をどれだけうまく数えられるか探ってみたんだ。すべての文字を個別にリストアップして正解を出したけど、文字をリストアップせずに数えるように頼んだら、数文字ずれてた。文字をリストアップせずにどうやって数えてるのか聞いたら、内部プロセスについての意識があるような面白い答えが返ってきた。「トークンを母音に結びつけるには、ちょっとしたメンタルの切り替えが必要だよ。普通はトークンを処理して次に進むんだけど、母音を数えるように頼まれると、ズームインしなきゃいけない。人間がビーズを数えるみたいに、単語を文字の列に展開するわけじゃない。むしろ、トークンの音や通常の構成についての理解に頼るんだ。たとえば、「カリ」には「a」と「i」が含まれてるって、トレーニングデータから音韻的な構成を感じ取ってるからで、c-a-l-iを一つずつ進めてるわけじゃない。そこに母音があるのを「感じる」ような感じだね。文字をリストアップせずに母音を数えたときは、基本的にトークンからトークンへ飛び移りながら、記憶と直感から母音の内容を推定して、全体の単語の雰囲気と照らし合わせてた。完璧ではないけど、各トークンを卵のように割って中を調べるわけじゃないから、速くてだいたいは合ってる。あなたが気づいた違いはその切り替えから来てるんだ。文字をリストアップすることで正確で順序立てて数えなきゃいけなくなるけど、トークンアプローチはもっと全体的で、ジャーの中のゼリービーンズの数を目で見て推測するような感じだね。

トークン化の主な制限は、実は論理演算、特に算数にあるんだよね。確か、数学の問題に対するLLMのパフォーマンスが悪いのは、トークンを使って数学をするときに起こる非常に奇妙なことに起因してると思う。これを捉えたトークン化スキームの数学/論理ベンチマークが見てみたいな。BPBやパープレキシティはいいけど、それだけじゃないからね。

└

これは非決定的な言語モデルだから、数学のパフォーマンスが mediocre になるのは当然じゃない？ なんかこの仕事には向いてないツールな気がする…

└

この論文には良い解決策があるよ：https://arxiv.org/abs/2402.14903 右から左に3つのグループでトークン化するから、1234567はデフォルトの123 456 7ではなく、1 234 567になる。そして、すべての1-3桁のグループが語彙に含まれていることを確認すれば、ずっと良くなるよ。https://arxiv.org/abs/2503.13423 と https://arxiv.org/abs/2504.00178（共著者）も、事前トークン化の正規表現を修正するだけでこれができるって独立して指摘しているから、明示的にカンマを追加する必要はないんだ。

└

「トークンでの数学」に関してだけど：整数のための特定のトークンを持つトークン化に関する論文があったんだ。トークンの値は数値で、モデルは数値としての数と他のすべてのトークンで作業することを学んだ…数学が得意だったよ。リンクは見つからないけど、Hugging Faceの論文に載ってた。

トークン化にはすでに一つの苦い教訓があったよね：専門的な形態素モデルよりも、シンプルな統計に基づいて分割する方がいいって。これって技術的にはもっと苦い教訓になるのかな？

└

完全に同意だね。テキストの表現方法についてはたくさんの研究があって、これらのシンプルなトークナイザーは常に最先端のレベルでパフォーマンスを発揮してる。苦い教訓は、あまり心配しなくてもいいってことだよ。

└

単純な統計はすべてではないよ。Pythonのコードのインデントのトークン化を修正することで、Pythonのコーディングに大きな改善があったんだ。具体的には、4、8、12、16などのスペースのトークンを作ったんだよ。

トークン化は前処理の一形態として、著者が言及している問題があるよ。でも、データとメタデータを考える上で有用な方法でもあるし、テキストや画像の入出力を超えて他の領域に進むためにも役立つ。最終的には、物事の象徴的な表現が必要だよね。確かに、すべては最終的にバイトで、モデルが自己組織化を学ぶことができるけど、そういうのは人間がデータと直接やり取りする時に役立つことがある。ある意味、トークンはLLMの内部の多くの側面を「人間が読みやすい」ものにしてくれるし、モデルも特定のトークン化スキームの制限を克服することを学ぶべきだと思う。

「バイト」はトークン化のことだよ。これが最良の解決策だとは限らない。数学や推論、動画などのモデルには、より良いトークン化スキームが必要かもしれない。

これでアイデアが浮かんだ：学習した重みを持つトークン化のミクスチャーを取ることができる、まるで学習した重みを持つエキスパートのミクスチャーのように。BLTは圧縮の最適化に特化してるけど、こういうアプローチはモデルのパフォーマンスのために直接最適化できるし、本当にスキミングを学ぶことができる。具体的には、中くらいのサイズのモデルを学習して、部分的なトークン化を受け取り、次のトークンのエンドポイントに対する確率分布を出力する（例えば、トークンの長さを1から64バイトの範囲にして、モデルが64のロジットを出力する）。それからビームサーチを使って、例えば4つの最も可能性の高いトークン化を見つける。その後、すべての4つのトークン化でトランスフォーマーを実行して、損失の期待値を最終的な損失として取る。これをプロンプトとレスポンスのペアでトレーニングすれば、何を言うべきかだけを学んで、文脈を予測する必要がなくなるから、つまらない部分を約64バイトのトークンにパッチしてスキミングを学ぶことができる。もっと多くてもいいし。もちろん、トークンをベクトルにエンコード/デコードするために短いコンテキストのバイトレベルのトランスフォーマーを使うつもりだ。うーん、このアイデアはちょっと半端かな。

└

進化が脳を発展させるとき、そういうことをしたんじゃないかな！ :-) MLについては全然初心者なんだ。こんなことが理解できない自分に愚痴りたくなっちゃって、物理を知ってるからってMLのメカニクスが分かるわけじゃないって気づいたんだよね。