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