WEBVTT

00:00.200 --> 00:02.360
Google Colabへようこそ。 

00:02.360 --> 00:06.290
トーケナイザーの素晴らしい世界を探検してみよう。 

00:06.290 --> 00:11.360
それで、 ええと、 まず最初にすることは、 輸入をすることだ。 

00:11.600 --> 00:15.290
そして、 それが終わった後、 ここでこの発言に触れたい。 

00:15.290 --> 00:23.300
前回のビデオでこのことを言い忘れたが、 あのコラボに追加したので、 とにかく見つけて私の説明を読んでほしい。

00:23.450 --> 00:28.220
ええと、 Huggingfaceにログインしたことがないなら、 Colabにログインする必要があるかもしれない。 

00:28.220 --> 00:31.370
そのためのコードがこれだ。 

00:31.370 --> 00:36.890
まず最初に、 まだ抱き顔のアカウントを作成していない場合は、 抱き顔のアカウントが必要です。

00:36.890 --> 00:37.700
無料だ。 

00:37.730 --> 00:40.910
それは素晴らしいことで、 決して後悔することはない。 

00:40.910 --> 00:46.970
そこで、 huggingfaceにサインアップし、 設定に移動して新しいAPIトークンを作成する。 

00:46.970 --> 00:48.470
自分に書く許可を与える。 

00:48.470 --> 00:53.060
今は必要ないだろうが、 将来は必要になるだろう。

00:53.090 --> 00:59.570
そして戻ってきたら、 このColabのキーセクションに行き、 新しいシークレットを追加する。 

00:59.570 --> 01:05.220
secretにはHFアンダースコア・トークンを、 valueにはあなたのトークンを指定する。 

01:05.220 --> 01:15.000
そして、 シークレットからHFトークンを取得するこのコードを実行し、 ここでインポートしたログイン・メソッドを呼び出すだけです。

01:15.000 --> 01:18.180
そして、 そのログイン方法はハグ顔にログインする。 

01:18.180 --> 01:19.470
すぐに実行しよう。 

01:19.470 --> 01:20.760
そして完成した。 

01:20.790 --> 01:23.400
そして、 そこに権利があると書いてあるのがわかるだろう。 

01:24.060 --> 01:35.400
さて、 トーケナイザーの話をしよう......まずはファンタスティックなラマ3から。  1、 メタの象徴的なモデルで、 オープンソースモデルへの道を開いた。

01:35.880 --> 01:42.240
さて、 llama 3を使っているとき。  1、 metaはまず利用規約にサインする必要がある。 

01:42.240 --> 01:47.520
その方法は、 ここにリンクされているハギング・フェイスのモデル・ページにアクセスすることだ。 

01:47.520 --> 01:52.680
そのページの一番上には、 サインするために必要なことがとてもシンプルに書かれている。 

01:52.830 --> 01:59.610
メールアドレスは、 あなたのハグする顔のアカウントと一致しているのがベストです。

01:59.610 --> 02:01.370
つまり、 素早く物事を成し遂げるということだ。 

02:01.370 --> 02:04.370
実際、 数分で承認されるはずだ。 

02:04.370 --> 02:07.610
土曜の深夜に一度だけ行ったこともある。 

02:07.610 --> 02:09.680
とても早く承認されたよ。 

02:09.740 --> 02:13.460
ただ、 彼らが本当にボールを持っているからなのか、 それともすべて自動化されているのかはわからないが、

02:13.550 --> 02:15.350
実に素早い。

02:15.770 --> 02:26.420
万が一、 この署名規約が何か邪悪なものだと思われるかもしれないが、 細かい字を読めば、 それはあなたがレンマ3を使うつもりがないことを確認するためのものなのだ。

02:26.420 --> 02:26.420
1悪意はなく、

02:26.420 --> 02:30.770
善意がある。

02:30.770 --> 02:34.400
だから、 サインすることに何の問題もないはずだ。 

02:34.400 --> 02:39.590
そうすれば、 ラマ3のすべてのバリエーションにアクセスできるようになる。  1.

02:39.590 --> 02:43.070
一つのサインで、 家族全員に適用されるんだ。 

02:43.370 --> 02:53.060
もし、 llama 3や2のような古いllama 3モデルを使いたいのであれば、 そのモデルのファミリーの契約書にサインする必要がある。

02:53.450 --> 02:57.650
もし、 何らかの理由で承認されたくなかったり、 すぐに承認されなかったりした場合は、

02:57.650 --> 03:00.200
後日、 私たちが開始するときにスキップすればいい。

03:00.230 --> 03:06.840
それか、 私が3人分プレーするのを見ることもできる。  1、 そして、 他のトークナイザーを使い始めたら、 また戻ってくることができる。

03:06.840 --> 03:12.510
しかし、 トークナイザーの作成はこの1行だけだ。 

03:12.690 --> 03:23.070
Hugging faceにはオート・トークナイザーというクラスがあり、 この特定のモデルに必要なトークナイザーのサブクラスを作成する。

03:23.100 --> 03:24.330
あまり心配する必要はない。 

03:24.330 --> 03:31.410
オート・トークナイザーは、 pre-trainedからクラス・メソッドを呼び出します。 つまり、 事前に訓練されたモデルがあるので、

03:31.410 --> 03:35.790
そのためのトークナイザーを作成してほしいということです。

03:35.820 --> 03:36.960
それが名前だ。 

03:36.960 --> 03:38.760
これが私たちが使っているモデルだ。 

03:38.760 --> 03:41.610
それは、 ハグする顔のハブから直接取ることができるものだ。 

03:41.610 --> 03:45.690
メタ・ラマのメタ・ラマ3だ。  180億ドル

03:45.720 --> 03:55.140
このトークナイザーを持ち込むと、 モデルの一部であるコードが存在する可能性がある。

03:55.140 --> 03:57.750
そして、 メタの正体を知っていると言っているんだ。 

03:57.780 --> 04:01.570
私たちはこれが問題ないことを知っていますから、 信頼してください。 

04:01.840 --> 04:04.030
それを含まなくても、 問題なく機能する。 

04:04.030 --> 04:06.040
ただ警告を与えるだけだ。 

04:06.040 --> 04:10.930
だから、 もし醜い警告を出したくないのであれば、 そう書いておいてくれ。 

04:11.950 --> 04:12.550
オーケー。 

04:12.550 --> 04:15.970
それで次にすることは、 テキストを使うことだ。 

04:16.000 --> 04:27.160
LLMのエンジニアにトーケナイザーの動きを見せるのが楽しみです。 テキストを文字列として受け取り、 トーケナイザーを呼び出してそのテキストをドット・エンコードします。

04:27.160 --> 04:30.070
そして、 その結果のトークンを印刷する。 

04:30.760 --> 04:31.720
それがこれだ。 

04:31.750 --> 04:33.400
とてもシンプルなことなんだ。 

04:33.400 --> 04:34.720
単なる数字の羅列だ。 

04:34.720 --> 04:35.860
それ以上のことはない。 

04:35.860 --> 04:37.390
トークンには何の不思議もない。 

04:37.390 --> 04:38.440
ただの数字だ。 

04:38.440 --> 04:40.960
そして、 この数字はそのテキストを表している。 

04:40.990 --> 04:43.600
何人いるか見てみよう。 

04:43.630 --> 04:50.320
では、 まず、 私たちが渡したテキストに何文字あったかを言ってみよう。 

04:50.350 --> 04:53.560
そのテキストには61の文字がある。 

04:53.560 --> 04:56.260
これでトークンの数を数えることができる。 

04:56.260 --> 05:02.510
大まかに言って、 トークンに何文字が対応するかという経験則を覚えていますか?

05:02.540 --> 05:06.110
平均すると4人だ。 

05:06.110 --> 05:06.440
大体ね。 

05:06.440 --> 05:12.890
経験則では、 通常の英語、 または英語をたくさん使う場合は、 4文字程度を1トークンとする。 

05:12.890 --> 05:16.880
だから61通を期待している。 

05:16.970 --> 05:19.790
トークンは15枚程度を想定している。 

05:19.820 --> 05:20.780
何が出てくるか見てみよう。 

05:20.780 --> 05:21.980
15トークン

05:21.980 --> 05:22.520
これでよし。 

05:22.550 --> 05:25.280
このテキストにちょうど15トークン。 

05:25.610 --> 05:31.940
トークンをテキストに戻すために、 このデコードを行うことができる。 

05:31.940 --> 05:35.150
だから、 原文を再現することを期待している。 

05:35.150 --> 05:39.020
そして私たちが手にするのは、 似ているようで少し違うものだ。 

05:39.020 --> 05:44.180
おわかりのように、 返ってくるのは期待通りのテキストである。 

05:44.180 --> 05:50.990
しかし、 その前面には新しいものがある。 このおかしなもの、 角度のついた括弧で囲まれたテキストは、 less

05:50.990 --> 05:55.010
thanとgreater thanの記号で始まる。

05:55.040 --> 05:55.910
これは何だ?

05:55.910 --> 06:01.900
これはスペシャル・トークンと呼ばれるもので、 ハイライトしたものはすべて1つのトークンにマッピングされます。

06:01.930 --> 06:14.740
実際、 このトークン、 128,000トークンは特別なトークンで、 プロンプトのテキストの始まりであることをモデルに示している。

06:14.950 --> 06:20.710
だから、 LMに特別な指示を出すために使うんだ。 

06:20.740 --> 06:24.550
さて、 皆さんはこう思うかもしれない。 

06:24.580 --> 06:30.820
ということは、 何らかの方法でトランスフォーマーのアーキテクチャを設定し、 そのようなトークンを期待するようにしなければならないということですか?

06:30.910 --> 06:35.920
ええと、 そして、 おそらくあなたは今、 とても快適だと思いますが、 答えはノーです。 

06:35.920 --> 06:37.270
そういう意味ではない。 

06:37.300 --> 06:44.080
ええと、 これはどういう意味かというと、 トレーニング中に見たすべてのトレーニング例の中で、 このように設定されていたということだ。

06:44.080 --> 06:48.250
トレーニングの例は、 この特別なトークンから始まる。 

06:48.250 --> 06:52.780
だから、 それを期待したトレーニングで慣れてきたんだ。 

06:52.780 --> 06:58.330
そして、 最高品質のアウトプットを確実にするためには、 同じアプローチを再現する必要がある。 

06:58.390 --> 07:02.210
ええと、 推論時に新しいプロンプトを入力するとき。 

07:02.990 --> 07:04.670
というわけで、 お分かりいただけただろうか。 

07:04.700 --> 07:08.360
バッチデコードの方法もある。 

07:08.360 --> 07:13.940
トークンを使ってこれを実行すると、 1つの文字列の代わりに、 それぞれの文字列が1つのトークンを表す、

07:13.940 --> 07:19.550
小さな文字列のセットが返ってくる。

07:19.550 --> 07:24.080
だから、 この最初のトークンがここになったんだ。 

07:24.080 --> 07:27.920
そして、 それがどのように機能しているかを確認するために、 フォロースルーすることができる。 

07:28.130 --> 07:30.920
ええと、 ここから注目すべきことがいくつかある。 

07:30.920 --> 07:37.730
そのひとつは、 ほとんどの場合、 単語がトークンにマッピングされることだ。

07:37.730 --> 07:43.370
1つのトークンにマッピングされる文字数は4文字よりはるかに多いのですが、 一般的な単語なので、

07:43.370 --> 07:45.380
ボキャブラリーに入っています。

07:45.620 --> 07:58.700
GPTトークナイザーと同じように、 単語の前にあるスペースもトークンの一部です。

07:58.700 --> 08:13.560
So and so amは言葉の始まりで、 Amという文字はただのamとは違うトークンであり、 もっと複雑なものの中にある可能性のある文字の断片である。

08:14.250 --> 08:23.130
また、 Tokenizersのようなものが、 単語トークンとISAの2つのトークンに分割されたことにもお気づきだろう。

08:23.460 --> 08:28.740
ISAの語尾は面白いね。 

08:28.740 --> 08:34.350
それはトークン化の一部なんだ。

08:34.380 --> 08:37.890
もうひとつ注意しなければならないのは、 大文字と小文字が区別されるということだ。 

08:37.890 --> 08:43.860
だから、 大文字のTがついたトークンがそこにあるのがわかるだろう。 

08:45.120 --> 08:53.040
最後に、 トークナイザー・ドット・ボキャブについて触れておこう。 

08:53.070 --> 08:58.500
tokenizer dot vocabを実行すると、 ええと、 これが表示されます。 

08:58.500 --> 09:03.980
言葉の断片と数字の完全な対応付けの辞書である。 

09:04.310 --> 09:06.590
そして、 ここにはかなり曖昧なものがあるのがわかるだろう。 

09:06.590 --> 09:12.620
非常に多くのトークンが用意されており、 中には異なる言語や異なる目的で使用される、

09:12.740 --> 09:15.920
かなり奇妙なトークンも含まれている。

09:16.190 --> 09:22.580
だから、 3文字や4文字の枠を超え、 さまざまなものを目にすることになる。 

09:22.610 --> 09:26.630
A ええと、 かなりたくさん印刷されています。 

09:26.870 --> 09:32.840
ええと、 この辞書をスクロールしていくと、 他のものが出てきます。 

09:33.050 --> 09:34.040
ここに戻ってこい。 

09:34.250 --> 09:41.990
印刷もできるし、 コメントもできる。 

09:42.440 --> 09:48.470
ええと、 追加されたボキャブラリーと呼ばれるもので、 さっき言った特別なトークンです。 

09:48.650 --> 09:53.840
申し訳ないが、 一番上にあるのは、 LMに合図を送るために使われる、

09:53.840 --> 10:01.860
語彙に予約されている特別なトークンだ。

10:01.890 --> 10:02.580
本文の冒頭。 

10:02.610 --> 10:03.570
本文終わり。 

10:04.020 --> 10:06.150
ちょっと遠慮がちに...。 

10:06.180 --> 10:11.100
そしてスタートヘッダ、 ID、 ヘッダ。 

10:11.100 --> 10:12.690
そして他にもいくつかある。 

10:12.690 --> 10:14.190
そしてパイソンのタグ。 

10:14.220 --> 10:17.070
明らかに特別な何かがある。 

10:17.070 --> 10:25.470
どんな理由であれ、 これらの特別なトークンを語彙に含め、 トレーニング中に提供することは、

10:25.470 --> 10:42.180
推論を行う際や、 テキストを生成するためにモデルを実行する際に、 これらのトークンを使ってモデルに物事を示すことができるため、 有用であると認識されています。

10:42.960 --> 10:43.530
分かった。 

10:43.560 --> 10:47.580
まあ、 これはラマ3モデルでちょっと遊んだだけだ。 

10:47.640 --> 10:49.290
ええと、 ラマ3。  1トークナイザー。 

10:49.320 --> 10:56.670
また戻ってきたら、 特にチャットに適用される方法を見てみよう。 

10:56.670 --> 10:59.640
それから、 他のトークナイザーも使ってみよう。 

10:59.640 --> 11:00.390
それではまた。