トークナイザーの互換性とは何か、なぜモデルの切り替えで問題が起きるのか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

トークナイザーの互換性とは、サービングスタックが、選択したモデルに期待される語彙IDと特殊トークン構造へテキストを正確に変換することを意味します。

2つのローカルモデルが同じアーキテクチャとコンテキスト長を共有していても、同じテキスト片に異なる整数を割り当てたり、異なる会話マーカーを要求したりする場合があります。キャッシュ済みのトークンID、チャットテンプレート、または停止トークンを保持したまま重みファイルだけを切り替えると、意味不明な出力、早すぎる終了、または安全でないプロンプト境界が生じる可能性があります。したがって、互換性は単に語彙サイズを一致させることではなく、アイデンティティ契約です。

語彙はトークンIDを学習済み埋め込みに結び付ける

トークナイザーはテキストを分割し、それぞれの要素を整数にマッピングします。その整数に対応するモデルの入力埋め込み行と出力確率列は、対応するトークン用に学習されています。そのため、マッピングを変更すると、影響を受けるすべてのIDの意味が変わります。

SentencePieceはサブワード語彙マッピングを、生テキストから直接学習して記述し、言語固有の前処理なしでサブワード分割をサポートします。異なる語彙で学習された2つのモデルは、同じ文を異なる長さと識別子でエンコードできます。この違いは、後の家庭環境でのテストでも確認できます。

語彙の次元数が同じでも、マッピングが同じとは限りません。サーバーは同じサイズの代替品を受け入れるのではなく、モデルのリビジョンに対応するトークナイザーアーティファクトを読み込む必要があります。自動化を進める前に、中間結果を検査可能な状態に保つ必要があります。

特殊トークンとチャットテンプレートが会話構造を定義する

開始、終了、役割、ツール、パディング、制御の各トークンは、表示されるテキストを超えた意味を持ちます。チャットテンプレートは、システム、ユーザー、アシスタント、ツールの各メッセージを、学習または指示チューニングで使用された正確なシーケンスにシリアライズします。この境界は、現実的な運用条件で個別に測定する必要があります。

Hugging Faceのドキュメントによると、モデルは基盤アーキテクチャを共有していても、異なる制御トークンを使用できます。制御トークンを重複して追加したり、生成プロンプトを省略したりすると、解析エラーが発生しなくても動作が低下する可能性があります。実際の影響は、複数のソースが限られたコンテキストを奪い合うときに現れます。

停止ロジックも、正しい終了トークンとテンプレートに依存します。古いトークナイザーを使用すると、出力が早期に終了したり、ツール境界が無視されたり、ユーザーテキストが制御トークンの位置を占有したりする可能性があります。この依存関係は、最終インターフェースで明示的に保つ必要があります。

キャッシュ済み状態と適応済み状態が互換性契約を拡張する

プレフィックスキャッシュ、トークン化済みプロンプト、投機的デコード用ドラフトモデル、文法マスク、アダプターは、特定のトークナイザーを前提としている場合があります。切り替え後にそれらを再利用すると、構文上は有効でも意味が変わった整数を保持してしまう可能性があります。そのため、結果は元の証拠と照合する必要があります。

トークナイザー転移に関する研究では、語彙の割り当てが多言語モデルの動作と下流タスクに影響を与えることが示されており、語彙設計が中立的なフロントエンドではなく、モデルの能力の一部である理由が分かります。この違いは、後の家庭環境でのテストでも確認できます。

失敗境界は、トークナイザーのリビジョン、特殊トークンID、正規化、テンプレートの整合性を証明できない切り替えです。デコードと再エンコードによるスポットチェックでは、まれな制御トークンを見落とす可能性があるため、互換性のないキャッシュとセッションは見た目ではなくアイデンティティによって無効化する必要があります。

-15% OFF