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.
 
 

193 lines
6.7 KiB

WEBVTT
00:00.410 --> 00:01.670
Colabへようこそ。
00:01.670 --> 00:04.910
7週目2日目のコラボへようこそ。
00:04.910 --> 00:10.760
ベース・モデルを試す前に、 これらのトークナイザーが実際に動いているところを見てみよう。
00:10.820 --> 00:15.410
ええと、 いつものようにPipのインストールとインポートから始めよう。
00:15.560 --> 00:23.120
定数セクションで、 4つの異なるトークナイザーを設定します。
00:23.120 --> 00:27.830
その後、 ベースモデルのラマを見て、 データを使っていくつかの作業をする。
00:27.830 --> 00:35.930
そして、 過去に結果を視覚化したときに覚えているかもしれないが、 カラーで出力するための定数もここに用意した。
00:36.440 --> 00:37.850
よし、 実行しよう。
00:37.880 --> 00:43.070
ハグフェイスにログインするには、 もうお馴染みのスニペットを使う。
00:43.070 --> 00:49.100
そして今、 私はモデル名を受け取ってトークン化する調査という便利な関数を書いた。
00:49.460 --> 00:58.790
そして、 そのモデル名のトークナイザーをロードし、 0、 1、 10、 100、
00:58.790 --> 01:06.030
999、 1000の6つの数字を繰り返し処理する。
01:06.090 --> 01:14.160
それぞれの数字について、 それを文字列に変換し、 その文字列をトークンに変換するようトークナイザーに依頼する。
01:14.160 --> 01:20.130
では、 文字列100をテキストとして表現するトークンとは何か?
01:20.520 --> 01:24.660
ええと、 この特別なトークンを追加することをfalseパラメータとして使っているんだ。
01:24.660 --> 01:29.940
つまり、 文頭トークンや文末トークンなど、 邪魔になるようなものを追加しないでください、
01:29.940 --> 01:33.510
ということです。
01:33.600 --> 01:38.760
このテキストを、 そのテキストを表すトークンに変換するだけだ。
01:38.970 --> 01:40.260
うーん、 だからそうなるんだ。
01:40.260 --> 01:41.730
そしてそれをプリントアウトする。
01:41.730 --> 01:50.520
そこで、 トークン・サイザーを調査するために、 トークン・サイザーを呼び出してみよう。
01:51.450 --> 01:59.460
まずはラマ・スリー・ワン・アーのモデルから始めよう。
01:59.460 --> 02:00.950
何が出てくるか見てみよう。
02:02.390 --> 02:06.200
つまり、 得られるのは文字列ゼロである。
02:06.200 --> 02:09.710
テキストゼロはトークン番号15に変換されます。
02:09.740 --> 02:12.230
ひとつはトークン16へ。
02:12.260 --> 02:15.380
10はトークン番号605へ。
02:15.410 --> 02:16.190
たまたまだ。
02:16.190 --> 02:21.380
そして、 同じようなことが109でも見られるだろう。 99 それぞれが1つのトークンにマッピングされている。
02:21.890 --> 02:25.310
1000でトークン2枚になる。
02:25.340 --> 02:28.580
実際、 これは100という数字のトークンに対応する。
02:28.610 --> 02:33.230
その後に数字のゼロとそのトークンが続いている。
02:33.230 --> 02:41.030
つまり、 あなたが想像している通り、 100というテキストを表すトークンの後に0というテキストが続く。
02:41.090 --> 02:55.130
3桁のテキスト番号、 3桁の数字に焦点を絞った場合、 どのような価格であっても常に1つのトークンに対応するという便利な特性がある。
02:55.160 --> 03:02.330
つまり、 ある商品の価格を予測しようとするモデルのタスクは、 結局はただ1つのトークンを予測し、 そのトークンを正解にすれば、
03:02.330 --> 03:05.930
その商品の正しい価格がわかるということになる。
03:06.110 --> 03:08.690
だから、 本質的な性質ではないんだ。
03:08.720 --> 03:15.470
私たちは、 これらのモデルが一連のトークンを完璧に生成できることを要求しているわけではないが、 問題を単純化して、
03:15.470 --> 03:20.270
この1つのトークンを正しく生成することだけに絞るのは好都合だ。
03:20.720 --> 03:26.270
また、 K-125のような別のモデルでもこのように見える。
03:28.280 --> 03:30.350
そして今、 私たちは違うものを見ている。
03:30.380 --> 03:38.450
一桁の0と1は1つのトークンに対応するが、 10は2つのトークンに対応する。
03:38.450 --> 03:53.210
実際、 1の後に0が続く100のトークンは100999であり、 おそらく999であり、 1000は1000である。
03:53.210 --> 03:54.830
つまり、 異なる特性があるのだ。
03:54.830 --> 03:59.930
そして、 私がなぜラマ3・1が有利だと思うのか、 その理由が明確になればいいのだが......。
04:00.290 --> 04:00.590
ええと。
04:00.630 --> 04:01.230
ジェマ
04:01.230 --> 04:02.670
ジェマに2つ、 2つ。
04:02.700 --> 04:03.450
申し訳ない。
04:03.630 --> 04:04.290
あの、 ジェマ。
04:04.290 --> 04:08.280
クォンに似た物件が2つある。
04:08.460 --> 04:11.880
あー、 興味深いことに、 あー、 語彙が全然違うんだ。
04:11.880 --> 04:14.670
もっと大きな数字だが、 それも不思議ではない。
04:14.670 --> 04:17.610
同じ語彙でなければならない理由はない。
04:17.940 --> 04:19.860
ええと、 それで、 ええと。
04:19.890 --> 04:26.640
ええ、 明らかに、 3桁の数字1つに対して1つのトークンではありません。
04:26.910 --> 04:30.660
そしてファイ3も似たようなものだ。
04:30.990 --> 04:38.220
ええと、 実はファイ3には別のバリエーションがあって、 ラマ3世と同じような素晴らしい特性を持つ小さなバリエーションがあるんだ。
04:38.220 --> 04:42.420
だから、 これも試してみる価値があるだろう。
04:42.480 --> 04:44.040
ええと、 どれでも試すことができますか?
04:44.040 --> 04:48.270
決して複数のトークンを出すことが失格というわけではない。
04:48.450 --> 04:49.020
分かった。
04:49.020 --> 04:55.680
まあ、 いずれにせよ、 トークナイザーの背景と、 私たちがなぜこのモデルを選んだのか、 その理由はご理解いただけたと思う。
04:55.740 --> 05:01.410
次のビデオでは、 データをロードしてモデルをテストしてみよう。