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 次のビデオでは、 データをロードしてモデルをテストしてみよう。