You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 

406 lines
15 KiB

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
まず、 スライドに戻ろう。