Byte Latent Transformer: Tokenよりもスケーラビリティに優れたPatch

 (ai.meta.com)
1 ポイント 投稿者 GN⁺ 2024-12-15 | 1件のコメント | WhatsAppで共有
  • Byte Latent Transformer (BLT) は、バイトレベル大規模言語モデル(LLM)の新しいアーキテクチャであり、トークナイゼーションベースのモデルと同等の性能を達成しつつ、推論効率と堅牢性が大幅に改善されている
  • バイトを動的サイズのパッチとしてエンコードし、パッチが主要な演算単位として機能
    • 動的パッチ分割: 次のバイトのエントロピーに基づき、複雑度の高いデータにより多くの計算資源を割り当て
  • バイトベースモデルにおける初のFLOP制御スケーリング研究:
    • 8B(80億)パラメータ、4兆(4T)学習バイトまでスケーリング
    • 固定された語彙(vocabulary)を必要としない生バイトによるモデル学習の可能性を確認

主な結果

  1. 効率的な学習と推論:
    • データが予測可能なときは長いパッチを選択して計算量を削減
    • モデルが複雑さに応じて動的にパッチを調整し、資源を最適化
  2. スケーリングの改善:
    • 固定された推論コストにおいて、トークナイゼーションベースのモデルより優れた性能
    • パッチサイズとモデルサイズを同時に増加させることで、スケーリング効率を確保
  3. 定性的な性能改善:
    • 推論および汎化能力の向上: 理由推論やスパースデータ(long-tail)処理において質的改善
    • 固定語彙ベースのアプローチの限界を克服

意義

  • BLTはトークナイゼーションなしで生バイトを処理しながらも、大規模データとモデル学習の効率性を実証
  • 推論コストに対してより優れた性能を提供し、次世代バイトレベルLLMの可能性を示唆
  • 特に、複雑なデータを扱う際に動的パッチ方式が適応型モデリングの新たな標準として定着する可能性を示している

関連記事

1件のコメント

 
GN⁺ 2024-12-15
Hacker Newsの意見

  • BERTが公開された夏、文字ベースのCNNモデルを使って分類作業をしていたスタートアップで働いていた。チームメンバーは単語ベクトルに関心を持っていたが、語彙外単語が多く、失敗につながる可能性があると考えていた

    • 「基盤モデル」でも語彙外単語が問題になっていた
    • 文字ベースのモデルでそこそこの成果を出していたが、ニューラルネットワークに「辞書」を保存するのは非効率だという意見があった
    • Word2Vecのような方式は失敗すると確信し、以前のプロジェクトを離れた
    • バイト対符号化が導入されたとき、初めて支持できるトークナイゼーション方式だと言った
    • 文字ラベルで作業できることを望んでいる。トークナイザーには反感がある

  • 階層構造は興味深いが、2段階しかないのが惜しい。さらに多くの階層を積み重ねることが研究の方向になり得る

    • FLOP予算を階層ごとに配分することには注意が必要
    • パッチをより大きな単位にグループ化する方法を見つける必要がある

  • パッチを生成するために小さなモデルを使って、入力文字列の次の文字の可能性を予測する

    • 例: 次の文字が 'a' である可能性が100%、または 'a' と 'b' である可能性がそれぞれ10%という場合がある
    • 文字の推定値をまとめてパッチ（またはトークン）を作る

  • サンプリングはLLMの難しい点だが、有効なJSONを常に出力するよう強制したり、温度を調整してさまざまな分布を得たりするなど、興味深い使い方を可能にする

    • BLTでは、デコーダに許可/禁止されたバイトを追加入力として与え、有効な出力が得られるまでデコードを繰り返す方法が考えられる

  • AIがバイナリファイルで事前学習できるのかという質問がある

  • トークナイゼーションを暗黙的なものにして、バイト（または文字）だけをモデルに与えられないのかという質問がある

  • Karpathyの関連する引用: トークナイゼーションはLLMの多くの奇妙さの中心にある

    • LLMが単語を綴れない理由はトークナイゼーションのせいである
    • LLMが単純な文字列処理タスクを実行できない理由はトークナイゼーションのせいである
    • LLMが非英語言語に弱い理由はトークナイゼーションのせいである
    • LLMが単純な算術に弱い理由はトークナイゼーションのせいである
    • GPT-2がPythonコーディングで不必要な困難を抱えた理由はトークナイゼーションのせいである
    • LLMが "<|endoftext|>" という文字列を見ると突然止まる理由はトークナイゼーションのせいである
    • "trailing whitespace" 警告が出る理由はトークナイゼーションのせいである
    • "SolidGoldMagikarp" について質問するとLLMが壊れる理由はトークナイゼーションのせいである
    • LLMでYAMLをJSONより好むべき理由はトークナイゼーションのせいである
    • LLMが実際にはエンドツーエンドの言語モデリングをしていない理由はトークナイゼーションのせいである
    • 苦痛の真の根源はトークナイゼーションである

  • 3つの構成要素からなるモデルである

    • エンコーダ: バイトのグループを受け取り、パッチという隠れ状態/エンコーディングを出力する
    • トランスフォーマー: パッチのエンコーディングを自己回帰的に処理する
    • デコーダ: トランスフォーマーが処理したエンコーディングをバイトとして出力する
    • 損失はバイト間のクロスエントロピー（次バイト予測）に基づく

  • バイトをグループ化する方法

    • エントロピー閾値を使う: バイト列のエントロピーが閾値より低ければグループ化する
    • データから学習されたモデルである

  • 現在のLLMのバイト対トークナイゼーションより利点がある

    • エンコーダ/デコーダが「学習可能な」トークナイゼーション方式として機能する
    • 効率性のトレードオフがより良い（予測可能なバイト列の場合、エンコーダが主要なトランスフォーマーの計算負荷を「オフロード」できる）
    • 歴史が示すように、エンドツーエンドで学習されたシステムは人間が設計したメカニズムを上回る

  • 私たちは停滞期に入るべきだと思っていた