WEBVTT 00:00.560 --> 00:04.160 トーケナイザーの活躍をご覧いただき、 ありがとうございます。 00:04.160 --> 00:09.830 これから見ていくのは、 モデルのインストラクター分散と呼ばれるものだ。 00:09.830 --> 00:28.430 そのため、 ユーザーとチャットで会話をするために特別に設計された、 00:28.520 --> 00:43.310 チャット用に微調整されたモデルがたくさんあります。 00:43.610 --> 00:50.870 つまり、 システムメッセージ、 ユーザーメッセージ、 アシスタンスレスポンスを識別する特別なトークンのセットを持つ特定の構造のプロンプトを期待するように訓練されているので、 00:50.900 --> 01:00.920 一種のチャットを形成している。 01:00.920 --> 01:06.270 そして、 それは単に十分な例で訓練された方法の一部に過ぎない。 01:06.270 --> 01:13.260 というのも、 フロンティア・モデルで遊んでいたときに慣れ親しんだ、 01:13.260 --> 01:19.830 メッセージやディクテット(辞書)のリストという構造の理由について、 01:19.830 --> 01:28.290 私が少し前に種をまいたことがあったからだ。 01:28.290 --> 01:37.470 というわけで、 今回はメタ・レンマ3を使ってトークナイザーを作ってみようと思う。 180億のインストラクター・バリアント。 01:37.470 --> 01:39.720 だから、 これは見覚えがあるだろう。 01:39.720 --> 01:48.420 これは、 OpenAIやClaudeなどでよく使うディクテーションのリストのひとつで、 01:48.420 --> 01:56.790 ロールとコンテンツを指定する。 01:56.880 --> 02:06.570 Huggingfaceが提供するトークナイザーは 特別な関数を持っています チャットテンプレートを適用し OpenAI APIフォーマットで 02:06.570 --> 02:16.170 このフォーマットのメッセージを受け取ります そしてこの特定のモデルで使用される 適切な構造に変換します このモデルが期待しているプロンプトのタイプは 02:16.170 --> 02:34.290 それが訓練された方法であることを考慮します ここでtokenized equals trueを指定した場合 返ってくるのは単なる数字の羅列で 何が起こっているのかわかりません 02:34.290 --> 02:35.910 だから、 トークン化イコールfalseにしたんだ。 02:35.910 --> 02:39.750 だから、 私たちに戻ってくるのは、 そのテキスト版になる。 02:39.750 --> 02:46.770 そして、 この会話を推論するときに、 これが何に変換されてモデルに送り込まれるのかがわかるように、 02:46.770 --> 02:53.820 これを印刷します。 02:53.820 --> 03:00.360 特別なトークンのテキストで始まり、 ヘッダーがある。 03:00.360 --> 03:04.380 そして、 システムという言葉をシステムにして、 ヘッダーを終了する。 03:04.560 --> 03:10.780 そして、 そこにはカット知識の日付と今日の日付についての情報が押し込まれている。 03:10.780 --> 03:12.160 それは特別なことだ。 03:12.160 --> 03:14.260 それにラマ3だと思う。 1のことだ。 03:14.260 --> 03:17.830 以前のリャマの家族にはそのような記憶はないが、 間違っているかもしれない。 03:18.280 --> 03:25.840 それから、 これはもちろん、 私たちがここで提供したシステムメッセージです。 03:26.860 --> 03:31.870 それから、 ユーザーとヘッダーの開始ヘッダーがもう一つある。 03:31.870 --> 03:35.170 そして、 これがユーザーメッセージだ。 03:35.620 --> 03:41.800 それから、 別の開始ヘッダーがあり、 アシスタントという言葉があり、 03:41.800 --> 03:44.590 そして終了ヘッダーがある。 03:44.590 --> 03:50.800 つまりこれは、 この後に続くのは、 このシステム指示に続くプロンプトに応答してアシスタンスが言ったことであるべきだ、 03:50.800 --> 03:58.720 というモデルのお膳立てのようなものだ。 03:59.590 --> 04:07.000 だから、 これがあなたにとってハッとするような瞬間であってほしい。 どうすればこのような構造を持つことができるのか、 おわかりいただけただろうか? 04:07.000 --> 04:10.120 そして、 モデルとの会話について、 あなたはこう考えるかもしれない。 04:10.120 --> 04:16.980 しかし、 結局のところ、 モデルに投入されるのは、 特別なトークンが混じったこのようなプロンプトだ。 04:16.980 --> 04:23.490 そして、 そのような構造、 特別なトークンで訓練されているため、 次に何が必要か分かっている。 04:23.520 --> 04:25.410 とアシスタンスは答える。 04:27.210 --> 04:30.990 というわけで、 チャットのインターフェースについて説明しよう。 04:30.990 --> 04:34.140 もう少しモデルを使って経験を積もう。 04:34.140 --> 04:36.360 私は特に3つのモデルを選ぶつもりだ。 04:36.480 --> 04:40.290 ファイ3はマイクロソフトのモデル。 04:40.680 --> 04:45.150 クイン2は、 アリババ・クラウドが提供するこの強力なモデルだ。 04:45.150 --> 04:49.800 スターコーダー2は、 コードを生成するために設計されたモデルだ。 04:49.890 --> 04:57.210 ServiceNowとNvidiaの3社が協力し、 顔をくっつけ、 顔をくっつけ、 04:57.240 --> 05:05.340 顔をくっつけ、 顔をくっつけ、 顔をくっつけ、 顔をくっつけ......この3社が提携して、 05:05.340 --> 05:11.450 このスター・コーダーを作り、 この特別なモデルを作った。 05:11.450 --> 05:12.560 オーケー。 05:12.560 --> 05:18.060 では、 ファイ3に挑戦してみよう。 05:18.060 --> 05:24.300 そこで、 まったく同じアプローチで、 事前に訓練された自動トークナイザーを使い、 モデルを提供する。 05:24.300 --> 05:27.750 そして今、 私は同じ文章を書いている。 05:27.750 --> 05:31.470 LLMのエンジニアたちに、 トーケナイザーの動きを見せるのが楽しみだ。 05:31.470 --> 05:40.020 前回のザ・ラマ3を再掲する。 1 トークンがどのように見えるかを思い出させるTokenizersの結果。 05:40.050 --> 05:44.070 それから空白の行を入れ、 ファイ3をプリントする。 05:44.070 --> 05:50.490 そして問題は、 一日の終わりに、 基本的に同じトークンを生産するのか、 それとも違うのかということだ。 05:50.520 --> 05:52.200 見てみよう。 05:53.700 --> 05:57.150 まあ、 両者がまったく違うことはすぐにわかるだろう。 05:57.270 --> 05:58.200 彼らは違うんだ。 05:58.230 --> 06:07.620 生成されたテキストが違うだけでなく、 メッセージの特別なトークンの始まりであるこの最初のテキストもまったく違う。 06:07.830 --> 06:11.070 ええと、 バッチデコードをして、 それを見てみましょう。 06:16.980 --> 06:17.760 トーケナイザー。 06:17.790 --> 06:21.930 ドットバッチデコード。 06:24.450 --> 06:27.030 トークンと言わざるを得ない。 06:27.030 --> 06:28.110 イコールである。 06:31.770 --> 06:32.970 トークン 06:33.780 --> 06:35.280 何が出てくるか見てみよう。 06:36.360 --> 06:40.800 そして、 まったく違うものを手に入れた。 06:40.860 --> 06:44.520 そして実は、 興味深いことに、 1秒前に言ったことは間違っていた。 06:44.550 --> 06:52.350 53の場合は文頭の特殊トークンがないので、 そのまま文頭に入る。 06:53.250 --> 06:56.850 だから、 それは非常に異なるアプローチなんだ。 06:58.830 --> 06:59.670 分かった。 06:59.700 --> 07:07.350 適用されたチャットテンプレートを使って、 53がどのようにチャットテンプレートを使うか見てみよう。 07:07.380 --> 07:09.900 まずはラマにもう一度やってみよう。 07:09.900 --> 07:11.250 だから、 リャマに会うことになる。 07:11.250 --> 07:18.990 そして、 同じ会話、 同じプロンプト53のチャットテンプレートを並べて印刷します。 07:19.020 --> 07:20.160 どう見えるか見てみよう。 07:20.160 --> 07:26.260 つまり、 これはラマに相当するもので、 ファイ3に相当するものはこちらだ。 07:26.290 --> 07:28.450 明らかにもっと短い。 07:28.450 --> 07:31.270 日付が変わっても通過しない。 07:31.510 --> 07:38.230 そして興味深いことに、 Lamaの構造がヘッダー、 システム、 エンドヘッダー、 ユーザー、 エンドヘッダーという構成だったのに対して、 07:38.260 --> 07:42.730 Lamaはヘッダー、 システム、 エンドヘッダーという構成になっている。 07:42.730 --> 07:52.720 ファイ3の場合は、 システム用の特別なタグとユーザー用の特別なタグ、 アシスタント用の特別なタグがあるだけだ。 07:52.720 --> 07:55.870 だから、 まったく違うアプローチなんだ。 07:56.110 --> 08:02.020 この2つのトークナイザー、 この2つのモデルは、 プロンプトがどのように送信されるかについて異なるアプローチを持っているというのは、 08:02.020 --> 08:04.240 実に興味深いことです。 08:04.240 --> 08:07.870 だから、 もし間違ったモデルに間違ったトークナイザーを使ったら、 ゴミになってしまうという印象を持ってもらえればいいんだけど、 08:07.870 --> 08:15.430 トークンが違ったり構造が違ったりすると、 llama 3にとっては無意味になってしまうのは明らかだからね。 08:16.120 --> 08:18.850 そして今度は、 クイン2についても同じことをやってみよう。 08:18.880 --> 08:23.020 オリジナルのラマ・バージョンを見るつもりだ。 08:23.020 --> 08:26.870 そして、 ファイ3バージョンとファイ2バージョンをお見せします。 08:27.050 --> 08:28.460 来たぞ。 08:29.120 --> 08:35.690 この3つのトークナイザーで、 まったく異なる結果が得られることは明らかだ。 08:35.750 --> 08:38.720 それと、 もう1回ハイライトを。 08:38.720 --> 08:41.810 適切なモデルに適切なトークナイザーを選ばなければならない。 08:43.370 --> 08:51.170 チャットテンプレートを適用して、 ジョークを言うという同じメッセージのチャットテンプレートをもう一度見てみましょう。 08:51.170 --> 08:52.400 それはリャマのために見ることにしよう。 08:52.400 --> 08:56.330 そして5-3、 クイン-2......。 08:56.330 --> 08:57.350 どんなものか見てみよう。 08:57.380 --> 08:59.000 リャマのものはすでに見た。 08:59.000 --> 09:01.010 53年のものはすでに見た。 09:01.010 --> 09:03.560 そして、 これがクイン2のものだ。 09:03.560 --> 09:06.650 その中間のようなものだ。 09:06.680 --> 09:08.840 ラマに少し似ている。 09:08.840 --> 09:14.030 イム・スタート、 イム・エンド、 そしてシステムがここにある。 09:14.210 --> 09:16.850 次にユーザー、 そしてアシスタント。 09:16.850 --> 09:19.250 つまり、 この2つの中間ということになる。 09:19.250 --> 09:23.870 ええと、 単語の間に何かが入っているわけではないんだ。 09:23.870 --> 09:26.000 ヘッダーの特別なタグはない。 09:26.000 --> 09:28.440 ただ、 その、 このアプローチなんだ。 09:28.440 --> 09:36.810 だから、 第3のアプローチ、 別のバリエーション、 別の特別なトークンというのはまた面白い。 09:37.740 --> 09:38.370 分かった。 09:38.370 --> 09:41.580 そして最後に、 スターコーダー2をお見せしよう。 09:41.610 --> 09:44.520 これはコード生成モジュールである。 09:44.520 --> 09:46.440 トークン化する。 09:46.440 --> 09:49.470 そこにこのコードを入れる。 09:49.500 --> 09:54.570 Hello world a def hello world uh person 変数を取る。 09:54.570 --> 09:55.980 そして、 ハローと印刷される。 09:55.980 --> 09:57.090 そしてその人。 09:57.090 --> 10:02.220 そして、 同じエンコードを使ってトークンに変換する。 10:02.220 --> 10:11.730 そして、 各トークンの後に、 そのトークンは何にマッピングされ、 そのテキストは何を表しているのか? 10:11.730 --> 10:18.840 ここでわかることは、 最初に何かがあり、 次にdefが1つのトークンに入り、 次にhello 10:18.840 --> 10:25.110 underscore world、 そしてpersonということだ。 10:25.110 --> 10:33.210 これは明らかにタブを反映し、 ハローカンマの人を閉じ括弧で囲んで印刷する。 10:33.210 --> 10:46.140 つまり、 スターコーダー・ツー・トークナイザーは、 英語ではなくコードをトークン化するために設計されたトークナイザーなのだ。 10:46.500 --> 10:48.120 そして、 いくつかできる実験もある。 10:48.150 --> 10:54.060 まずは、 さまざまなトークナイザーを試して、 テキストからトークンへのマッピングを探ってみよう。 10:54.180 --> 10:55.590 どの単語が使われているか調べる 10:55.590 --> 11:02.040 リャマに含まれるトークンが1つである、 可能な限りレアな単語を探してみてください。 11:02.040 --> 11:06.360 トークナイザーとか、 一番長い単語とか、 そんな感じかな。 11:06.360 --> 11:09.720 いくつか実験をして、 それから満足するんだ。 11:10.170 --> 11:15.210 かなり複雑なコードであっても、 star coder tos tokenizerの方が、 11:15.240 --> 11:22.260 英語専用のトークナイザーよりも効率的にトークン化できることがお分かりいただけるはずです。 11:22.650 --> 11:33.180 そしてその時点で、 あなたはオープン・ソース・トークナイザーの世界におけるエキスパートとなり、 次のピースであるモデルに挑戦する準備が整うだろう。 11:33.180 --> 11:35.160 まず、 スライドに戻ろう。