この記事は機械翻訳によるものであり、英語が原文です。 原文を読む
言語モデルが単語に含まれる文字を数えるのに苦戦する理由
「strawberry」という単語は、str、aw、berry という3つの断片としてGPT-4に届く。モデルが何かを読む前に、文字はすでに消え去っている。
言語モデルに「strawberry」の中に文字「r」が何回現れるかを尋ねると、2回と答えることがよくある。これは何か深刻な欠陥の証拠として扱われがちだが、実際には、耳で聞いたことしかない単語について筆の画数を数えるよう誰かに求めることに近い。
モデルが実際に受け取っているもの
モデルがテキストを目にする前に、テキストはトークンへと切り分けられる。文字でも単語でもなく、大規模なコーパスを観察し、最も頻繁に出現した隣接ペアを何度も繰り返し統合して数万個の語彙になるまで構築したアルゴリズムによって選ばれた塊である。
よく使われる単語は単一のトークンになる。より珍しい単語は分割され、その分割がどこに入るかは、意味や綴りではなくコーパスの統計によって決まる。「strawberry」は2つか3つの断片として届くかもしれず、モデルから見たそれらは分割不可能な記号であり、それぞれが語彙に対する任意のインデックスにすぎず、番地（家の番号）以上の内部構造をモデルが知ることはできない。
したがって、文字は真に入力の中に存在しない。モデルは綴りに関する事実――特定のトークンが文字に関する特定の主張と共起しやすいこと――を学習できるが、それは入力そのものから推論しているのではなく、自身の入力に関する伝聞から推論しているにすぎない。この分割が起きる様子はTokenizerで観察できる。その語彙はウェブのクロールではなく本サイト自身の文章から作られているため、GPTが3つに分割するところを、「strawberry」を4つの断片に切り分ける。
これが説明するその他の現象
桁数の多い数値の計算。 数値もトークン化されるが、必ずしも1桁ずつ分割されるわけではない。位取りをまたぐ塊に分割されることもあるため、筆算を行うモデルは、桁の位と揃っていない断片を扱うことになる。桁数が増えると性能が急激に低下するのは、問題が表現形式にあることを示す手がかりである。
押韻、アナグラム、アクロスティック。 意味ではなく文字に基づいて定義されるあらゆるタスクが、同じ壁に突き当たる。
英語以外の言語におけるコストとコンテキストの制限。 トークナイザーは圧倒的に英語が多いコーパスで訓練されるため、英語には効率的なトークンが割り当てられ、他の言語は単語ごとにより多くの断片へと細片化される。使用割合の低い言語では、同じ文でも数倍のトークンを消費することがあり、これは処理コストの上昇と、固定されたコンテキストウィンドウのより大きな消費を意味する。これは前処理の段階に潜む公平性の問題である。
意外な挙動の原因はトークンだけではない
意味は幾何学的である。 単語はベクトルになり、その空間における近さは共起（何が何と近くに出現するか）から学習される。モデルが連想を非常にうまく捉えるのも、学習元のテキストが持つバイアスを受け継いでしまうのもこれが理由だ。コーパス内で特定の単語が他の特定の単語の近くに出現する場合、その空間内でも近くに配置されることになり、その仕組みの中には事実とステレオタイプを区別するものは何もない。Token Embeddingsツールはその空間の縮小版を構築しており、幾何学的空間がどのように構成されているかを確認できる。
出力は選択されるのではなく、サンプリングされる。 モデルは次のトークンに関する確率分布を出力し、何らかの処理によってその中から1つが選ばれなければならない。温度を下げる（temperatureを低くする）と、モデルは毎回最も確率の高い選択肢を取り、反復的で予測通りのものになる。温度を上げると、確率の低い選択肢を選ぶ頻度が増え、独創的になる一方で信頼性は低下する。モデルが「創造的」であると形容されることの多くは、サンプリングパラメータによるものだ。ハルシネーションはそうではない。温度ゼロのモデルであっても依然として物事を捏造（作話）するのであり、サンプラーはその頻度を変えるにすぎない。Temperature Samplingでは、分布と選択された結果を並べて確認することができる。
挙動がどの層に由来するか
これにより、不可解な謎が仕様へと変換される。「モデルが信頼できない」という言説では対策の立てようがないが、「モデルは文字を見ることができないため、綴りや文字数のカウントに関するタスクはコードに任せる」であれば実行可能である。「この言語は3倍のトークンを消費するため、それに応じて予算を組む」や、「この出力は再現性のある結果が得られない温度でサンプリングされた」という判断も同様だ。
これらのシステムをうまく活用するための実践的な判断のほぼすべては、ある挙動がどの層――トークナイザー、埋め込みの幾何構造、あるいはサンプラー――に由来するかを知ることから生まれる。これら3つのどれ一つとして知能ではなく、3つともすべて検証可能なものである。
語彙はどのように構築されるか
通常用いられる手法はバイト対符号化（Byte Pair Encoding）であり、その評判に反して仕組みは単純である。まず、すべての文字をそれぞれ独立したトークンとすることから始める。コーパス全体で隣接するすべてのペアを数え上げ、最も頻出するペアを見つけて1つの新しいトークンへと統合する。これを数万回繰り返す。
こうして出来上がるものは、言語学的な分析ではなく、頻度の順位付けにすぎない。一般的な英単語が丸ごと残るのは、コーパス内で頻出したからにすぎず、形態論が捉えられるのも、それがたまたま頻度と一致した場合だけである。トークナイザーには「running」の中に「run」が含まれているという概念はない。その分割がたまたま頻度の集計で勝ち残った場合にのみ、そのように表現される。
語彙とは、ある特定の時点における特定のコーパスの化石である。訓練用のテキストを変えれば、分割の位置も変わる。異なるトークナイザーを持つ2つのモデルは、単に出力について一致しないだけでなく、入力が何であるかについての認識そのものが異なっているのだ。
なぜ簡単に修正できないのか
当然の対応策として考えられるのは、代わりにモデルに文字を直接入力することだ。実際にそうしているモデルもあるが、そのトレードオフには代償が伴う。
トークンが存在するのは、系列長を短縮するためである。英語1ページ分はおよそ250トークン、あるいは1,200文字であり、アテンション機構の計算コストは系列長の2乗に比例して増大するため、文字単位で処理を行うと同じ文章に対しておよそ20倍の計算量が必要になる。トークン化は圧縮の処理であり、圧縮に関する記事で論じられているのとまったく同じトレードオフが当てはまる。すなわち、トークン未満の構造へのアクセスを捨てることによって、より短い系列を手に入れているのである。
したがってこれは、モデルが何かを目にする前に行われる、系列長と引き換えにした文字レベルの可視性の意図的な交換であり、その代償は、まさに文字レベルの詳細こそが肝要であった部分に降りかかることになる。
1994年の圧縮の工夫
この分割手法には奇妙な歴史がある。バイト対符号化は、1994年にフィリップ・ゲイジがプログラミング雑誌において、ファイルを圧縮するためのデータ圧縮アルゴリズムとして発表したものだ。その規則は、最も頻出する隣接バイトのペアを見つけ、使われていないバイトで置き換えることを繰り返すというものであった。
2016年、センリッチ、ハドウ、バーチがこれを機械翻訳に応用した。何かを圧縮するためではなく、珍しい単語を諦めてしまう代わりに断片として表現できる語彙を構築するためであった。
こうして、ディスク容量が懸念されていた時代に設計された30年前の圧縮の工夫が、現代の最大規模のモデルが知覚できるものを決定づけているのである。