トークン化 ** と埋め込み** は、GPT などの大規模言語モデル（LLM）の基本的な構成要素であり、テキストの理解と生成に不可欠です。トークン化は生のテキストをトークンと呼ばれる管理可能な単位に分解し、埋め込みはこれらのトークンにリッチなベクトル表現を提供します。トークン化と埋め込みの違いを理解することは、LLM が言語データをどのように処理するかの複雑さを把握するために不可欠です。
はじめに
トークン化と埋め込みは、GPT などの大規模言語モデル（LLM）の基本的な構成要素であり、テキストの理解と生成に重要です。トークン化は生のテキストをトークンと呼ばれる管理可能な単位に分解し、埋め込みはこれらのトークンにリッチなベクトル表現を提供します。トークン化と埋め込みの違いを理解することは、LLM が言語データを処理する方法の複雑さを把握するために不可欠です。
トークン化とは
トークンは、AI 研究で頻繁に議論されます。例えば Llama 2 の論文では、著者らが 2 兆トークンのデータで学習したと述べています。トークンは、大規模言語モデル（LLM）の基本単位（「原子」に類似）として機能します。トークン化は、文字列（つまりテキスト）をトークンのシーケンスに変換する処理、およびその逆の処理を含みます。
機械学習の分野では、トークンは通常、単一の単語と同等ではありません。代わりに、文字や単語の一部などのより小さな単位、あるいはフレーズ全体などのより大きな単位を表すこともあります。トークンのサイズは、使用されるトークン化アプローチによって異なります。
トークン化は通常、「トークナイザー」と呼ばれるコンポーネントによって処理されます。このモジュールは大規模言語モデルとは独立して動作し、独自のテキストトレーニングデータセットを持ちます。これは LLM のトレーニングデータとは完全に異なる場合があります。
なぜトークン化が重要なのか？
トークン化は、大規模言語モデル（LLM）で観察される多くの特異性の根底にあります。一部の問題は当初ニューラルネットワークアーキテクチャや LLM 自体に起因するように見えるかもしれませんが、実際にはトークン化に起因する可能性があります。以下は、トークン化に遡ることができる問題の非網羅的なリストです。
- スペルの不正確さ
- 文字列の反転などの単純な文字列処理の困難さ
- 日本語などの非英語言語でのパフォーマンス低下
- 基本的な算術演算の低パフォーマンス
- GPT-2 が直面した Python などのコーディングタスクの課題
- 末尾の空白に関する問題
- 初期バージョンの GPT が「SolidGoldMagikarp」というプロンプトで異常な動作を示した例
- 構造化データを扱う際の JSON よりも YAML の優先
この投稿では、トークン化がこれらの問題にどのように寄与するかを詳しく掘り下げます。
トークン化の詳細
以下はトークン化に関わる手順の概要です。これらの手順の一部はすぐには明確でないかもしれませんが、この投稿を進めるにつれてより詳しく掘り下げます。
事前学習：語彙の確立
- トレーニングデータを収集する：モデルが学習するための大規模なテキストデータコーパスを集める。
- 初期トークン化：初期トークン化手法を用いて、テキストを単語、サブワード、文字などの基本単位に分割する。
- 語彙の作成：Byte Pair Encoding（BPE）、WordPiece、SentencePiece などのトークン化アルゴリズムを選択し、管理可能で効率的なトークンセットを生成する。
- アルゴリズムの適用：選択したアルゴリズムを初期トークンに適用し、トレーニングデータに存在する言語的ニュアンスを捉えたサブワードトークンまたは文字のセットを生成する。
- ID 割り当て：結果の語彙の各トークンに一意の整数 ID を割り当てる。
リアルタイムのトークン化プロセス
- 確立された語彙に基づいて入力テキストをトークンに変換し、すべてのテキストを完全にカバーする。
- 各トークンを、事前に確立された語彙で定義されたそれぞれの整数 ID に関連付ける。
- モデル処理の要件を満たすために、必要な特殊トークンをシーケンスに組み込む。
トークン化の課題を理解する
自由に文章を入力し、トークンがどのように生成されるか（およびトークン数とプロンプトあたりの価格の増加に注目）を観察してください。
右側のテキストにカーソルを合わせ、「Show whitespace」チェックボックスを有効にすると、強調表示されたトークンが表示されます。これらのトークンは通常、先頭にスペース文字を含む「チャンク」で構成されています。
別の例：
トークンチャンクとその数値表現が、次の要素に基づいてどのように変化するかを観察してください。
- 単語の前のスペースの有無
- 句読点の存在
- 大文字小文字
大規模言語モデル（LLM）は、トークンにこれらの違いがあるにもかかわらず、単語が同じ概念を表すか、少なくとも非常に類似していることを生データから学習しなければなりません。この変動性はパフォーマンスを低下させる可能性があります。
他の人間言語
英語のチャンクサイズを他の言語と比較すると、英語以外の言語では使用されるトークン数が大幅に多いことに気づくでしょう。この違いは、他の言語のチャンクがより断片化される傾向があり、ドキュメント内のシーケンス長が膨張することに起因します。
機械学習トランスフォーマーのアテンションメカニズムでは、非英語言語に対してコンテキストが不足する可能性が高くなります。同じメッセージを伝える場合でも、チャンクが小さいため、より多くのトークンが消費されます。この不一致は、トークナイザーのトレーニングセットとトークナイザー自体の両方に影響されます。
最終的に、非英語言語に対するコンテキストウィンドウの非効率的な利用は、大規模言語モデル（LLM）が非英語のクエリを処理する際のパフォーマンス低下につながります。
トークン化とコード — Python
Python の場合、OpenAI の GPT-2 エンコーダーは、Python コードセグメントのインデントに使用される個々の空白文字に多くのトークンを費やすことがよくありました。この動作は、非英語言語で直面する課題と同様に、LLM のコンテキストウィンドウを大幅に膨張させ、パフォーマンスの低下につながります。
設定：YAML vs. JSON
YAML は JSON よりも密度が高く、同じタスクを達成するために必要なトークン数が少ないことが判明しています。
簡単な例を示します：
JSON: 46 トークン
JSON の肥大化により、次のことが発生します：
- LLM が理解するのが難しくなる（密度が低く、コンテキストウィンドウを超えやすい）。
- ユーザーのコスト増加（OpenAI への API 呼び出しでは基本的にトークン単位で支払うため）。
トークン化の問題
トークン化は、大規模言語モデル（LLM）で観察される多くの異常の核心にあります。当初はニューラルネットワークアーキテクチャや LLM 自体に関連しているように思えるいくつかの問題も、実際にはトークン化に遡ることができます。例えば：
- LLM は単語のスペルや、文字列の反転などの基本的な文字列処理タスクに苦労する。
- 非英語言語ではパフォーマンスが低下する傾向がある。
- LLM は単純な算術処理で低パフォーマンスを示す。
- GPT-2 は Python でのコーディングタスクで大きな課題に直面した。
- 末尾の空白に関する奇妙な警告が発生することがある。
- 「Solid Gold Magikarp」というフレーズは、LLM を無関係な話題に逸らすことが多い。
- LLM を扱う際、YAML が JSON よりも好まれる。
大規模言語モデルにおけるトークン化
大規模言語モデル（LLM）のトレーニングでは、文字列を取得し、事前定義された語彙から整数に変換するプロセスが含まれます。これらの整数は、埋め込みテーブルからベクトルを取得するために使用され、その後 Transformer モデルに入力されます。このプロセスは、基本的な英語アルファベットだけでなく、さまざまな言語や絵文字などの特殊文字もサポートする必要があるため、複雑になります。
Python の文字列と Unicode コードポイント
Python では、文字列は Unicode コードポイントで構成される不変のシーケンスです。これらのコードポイントは、Unicode コンソーシアムによって Unicode 標準内で定義されており、現在約 150,000 文字、161 のスクリプトを網羅しています。Unicode 標準は積極的にメンテナンスされており、最新バージョン 15.1 は 2023 年 9 月にリリースされました。
Python で単一文字の Unicode コードポイントを取得するには、ord() 関数を使用できます。例：
しかし、これらの生のコードポイント整数をトークン化に使用することは現実的ではありません。語彙が非常に大きくなり（150,000 以上）、Unicode 標準が継続的に進化しているため不安定になるからです。
Unicode バイトエンコーディング
より効果的なトークン化ソリューションを追求するため、ASCII、UTF-8、UTF-16、UTF-32 などの Unicode バイトエンコーディングに注目します。これらのエンコーディングは、抽象的な Unicode コードポイントを、ストレージと送信に適した具体的なバイトに変換する方法を定義します。
Unicode バイトエンコーディング、ASCII、UTF-8、UTF-16、UTF-32
Unicode コンソーシアムは 3 種類のエンコーディングを定義しています：UTF-8、UTF-16、UTF-32。これらのエンコーディングは、Unicode テキストをバイナリデータまたはバイトストリームに変換する手段として機能します。
これらのエンコーディングの中で、UTF-8 が最も一般的です。各 Unicode コードポイントを、コードポイントに応じて 1 ～ 4 バイトのバイトストリームに変換します。最初の 128 コードポイント（ASCII）は 1 バイトのみ必要です。次の 1,920 コードポイントはエンコードに 2 バイト必要で、ラテン文字アルファベットの大部分を含みます。基本多言語面（BMP）内の残りの 61,440 コードポイントには 3 バイトが必要です。4 バイトは、あまり一般的でない CJK 文字、さまざまな歴史的スクリプト、数学記号を含む他の Unicode 面をカバーします。
生の UTF-8 バイトを直接使用することは、言語モデルにとって非常に非効率的です。語彙サイズがわずか 256 の可能なバイト値に制限され、シーケンスが過度に長くなります。このような制約は、モデルが十分に長いコンテキストに注意を向ける能力を妨げます。
解決策は、バイトペアエンコーディング（BPE）アルゴリズムを使用して、これらのバイトシーケンスを可変的に圧縮することです。このアプローチにより、より大きく調整可能な語彙サイズでテキストを効率的に表現できます。
トークン化と埋め込みの違いは？
トークン化と埋め込みは、大規模言語モデル（LLM）（GPT など）内の別個でありながら相互に関連するプロセスであり、これらのモデルがテキストを理解し生成する方法に貢献します。以下にそれぞれの概要と違いを示します。
LLM トークン化
目的：トークン化は、生のテキストをトークンのシーケンス（トークン化アプローチに応じて、単語、サブワード、文字を含む）に変換することを目的とします。
手順：テキストをモデルが解釈できる管理可能なセグメントに分割することを含みます。これには、最初にテキストをスペースや句読点で分割し、その後、モデルの事前定義語彙に存在しない場合にサブワードや文字にさらに分割することが含まれる場合があります。
結果：結果は、モデル処理に適した形式で元のテキストを表すトークンシーケンスです。各トークンには、モデルの語彙に対応する一意の整数 ID が割り当てられます。
埋め込み
目的：埋め込みは、トークンのコンパクトで低次元の連続ベクトル表現です。セマンティックおよびシンタクティックな意味をエンコードし、モデルが言語のニュアンスを理解するのを容易にします。
手順：トークン化の後、各トークン（整数 ID で表される）は埋め込みベクトルに関連付けられます。これらのベクトルはモデルのトレーニングフェーズを通じて取得され、埋め込み行列またはテーブルに保存されます。
結果：埋め込みは LLM のニューラルネットワーク層への入力として機能し、モデルがトークンに対して計算を実行し、データセット内の関係とパターンを識別できるようにします。
LLM 埋め込みの詳細については、ブログ記事「LLM 埋め込みとは：知っておくべきすべて」をご覧ください。
区別する特徴
処理段階：トークン化は初期の前処理ステップであり、テキストをモデルが理解できる形式（トークン）に変換します。一方、埋め込みはトークン化の後に発生し、トークンを詳細なベクトル表現に変換します。
機能：トークン化は主にテキストの構造的な分解と表現に関与しますが、埋め込みはトークンに埋め込まれたセマンティックおよびシンタクティックな意味を捕捉して活用することに焦点を当てています。
表現：トークン化はテキストコンポーネントの離散的で整数ベースの表現を生成しますが、埋め込みはこれらの整数を、言語情報をエンコードする連続ベクトルに変換します。
結論
結論として、トークン化と埋め込みは大規模言語モデルの機能において極めて重要な役割を果たします。トークン化がテキストをトークンに構造化する一方で、埋め込みはベクトル表現を通じてこれらのトークンにセマンティックおよびシンタクティックな意味を提供します。これらのプロセスを理解することで、LLM がテキストを解釈し生成する方法を洞察し、自然言語処理の進歩に貢献します。
novita.ai は、無限の創造性のためのワンストッププラットフォームであり、100 以上の API にアクセスできます。画像生成、言語処理、音声強化、動画操作まで、従量課金制でお手頃価格。GPU メンテナンスの手間から解放され、独自の製品を構築できます。無料でお試しください。
おすすめの記事
