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 それではまた。