WEBVTT 00:00.920 --> 00:05.060 私たちがデータセットを作っていた何年も前のことを覚えているだろうか。 00:05.060 --> 00:08.960 その最後に、 Huggingfaceにデータをアップロードした。 00:08.990 --> 00:15.200 その時点から、 ピックルファイルも作っていたので、 それ以降はピックルファイルからデータを読み込んでいる。 00:15.200 --> 00:27.050 しかし、 Google Colabにいる今、 Huggingfaceのハブからデータを収集するのが一番簡単だ。 00:27.080 --> 00:28.400 それでは、 どうぞ。 00:28.430 --> 00:34.550 データセットをロードするには、 データセット名を渡して、 00:34.550 --> 00:40.190 データセットをtrainとtestに分割する。 00:40.220 --> 00:44.930 そうしたら、 最初のトレーニングデータを見てみよう。 00:45.080 --> 00:48.710 テキストと値段が書いてある。 00:48.740 --> 00:51.830 私たちが自分たちでこれを設定したことを覚えているかもしれない。 00:51.830 --> 00:54.800 テキストは私たちのプロンプトだ。 00:54.830 --> 01:00.590 この商品はいくらですか(1ドル単位)」、 「この商品はいくらですか(1ドル単位)」、 「この商品はいくらですか(1ドル単位)」、 01:00.590 --> 01:07.070 「この商品はいくらですか(1ドル単位)」、 「この商品はいくらですか(1ドル単位)」、 「この商品はいくらですか(1ドル単位)」。 01:07.070 --> 01:08.330 そしてトップには 01:08.330 --> 01:09.920 これはいくらするんだ? 01:09.950 --> 01:11.330 1ドル単位で。 01:11.720 --> 01:20.870 そうしている理由は、 ラマ3世の作業を少しでも楽にしたいからだ。 80億のパラメータを持つ1モデル。 01:21.230 --> 01:26.870 フロンティア・モデルに送る場合、 セントに関する独自の判断を下すのに十分なパワーを備えているため、 01:26.870 --> 01:29.030 それを指定する必要はなかった。 01:29.030 --> 01:33.710 しかし、 この場合、 私たちはモデルにできる限りのシンプルさを与えたい。 01:33.920 --> 01:40.400 ええと、 そうなると、 ラマ3では常に1つのトークンに対応することになりますから。 1、 私たちは、 トークンを1つ予測するだけでいいように、 01:40.400 --> 01:46.490 とても簡単にしています。 01:46.490 --> 01:50.180 それが、 うまくやる方法を学ぼうとすることになる。 01:50.540 --> 01:54.320 そしてこのデータセットには、 実際の価格も含まれている。 01:54.680 --> 02:00.560 ええと、 テストデータを見て、 最初のポイントを取ると、 テストデータは非常によく似た構造になりそうだが、 02:00.560 --> 02:02.600 1つだけ小さな違いがある。 02:02.600 --> 02:03.950 その違いが何なのか分かる? 02:04.130 --> 02:05.030 そうだろうね。 02:05.070 --> 02:11.220 もちろん、 この時点のテストデータには価格が提示されていない。 02:11.250 --> 02:13.260 テキストはテキストになる。 02:13.290 --> 02:14.970 1ドル単位でいくらですか? 02:14.970 --> 02:17.340 そして、 この文章を通過する。 02:17.340 --> 02:21.870 そして私たちのモデルに課せられたのは、 次のトークンを予測することだ。 02:21.900 --> 02:25.260 この後、 次のトークンが来る確率は? 02:25.260 --> 02:35.490 そして、 3という数字に一致するトークンが高い確率で出ることを期待している。 74、 ええと、 実際の価格と同じです。 02:35.550 --> 02:37.350 それが任務だ。 02:37.350 --> 02:47.760 そして、 これは1つのトークンに対応するので、 次のトークン、 つまりそのコストを表す1つの次のトークンを予測することに長けていることが本当の課題なのだ。 02:48.030 --> 02:52.620 ええと、 もうひとつ言っておくと、 覚えているかもしれないが、 このテキストが常に179トークン以内に収まるようにするために、 02:52.620 --> 02:58.140 いろいろと工夫した。 02:58.260 --> 03:08.460 そのおかげで、 最大配列長182という定数がここにある。 03:08.880 --> 03:10.320 トークンも少し入れた。 03:10.320 --> 03:13.140 実際に179番がある。 03:13.140 --> 03:20.790 というのも、 トークナイザーはシーケンスの最初に文頭トークンを追加し、 03:20.790 --> 03:28.890 最後に文末トークンやパッドトークンを追加する可能性があるからです。 03:28.890 --> 03:37.020 そして、 最も重要なトークンの価格を誤って切り下げてしまうようなリスクは絶対に避けたい。 03:37.020 --> 03:42.450 だから、 少し余裕を持たせれば、 実際、 トレーニングに入るまでは重要なことではないんだ。 03:42.450 --> 03:45.540 でも、 データを見ている今だからこそ、 指摘しておきたかったんだ。 03:46.470 --> 03:48.510 そうだ。 03:48.720 --> 03:50.790 申し訳ないが、 やり過ぎた。 03:50.790 --> 03:53.010 今、 このデータを見たところだ。 03:53.040 --> 03:57.630 次にすることは、 正しい量子化設定を選ぶことだ。 03:57.630 --> 04:01.530 定数を4ビットより上に設定したんだ。 04:01.560 --> 04:03.420 今回はtrueに設定した。 04:03.450 --> 04:06.030 行って確認してみよう。 04:06.060 --> 04:06.810 これでよし。 04:06.810 --> 04:08.970 量子4ビットが真にセットされる。 04:08.980 --> 04:14.320 それで、 もう一度下に戻ってきたら、 4ビットの量子化を選ぶんだ。 04:14.320 --> 04:17.110 そして、 8ビットを選ぶとどうなるかをお見せしよう。 04:17.110 --> 04:20.680 しかし、 我々は本当に極小の4ビットバージョンを選ぶつもりだ。 04:21.100 --> 04:24.370 そして、 トークナイザーとモデルをロードする。 04:24.370 --> 04:26.680 このセルを走らせるつもりはない。 04:26.680 --> 04:28.870 メモリーの中にあるのがわかるだろう。 04:28.870 --> 04:30.730 2回目を実行するとメモリが足りなくなる。 04:31.810 --> 04:36.100 ここで行うのは、 トークナイザーを読み込むことだ。 04:36.130 --> 04:39.640 ここには、 よく目にするような定型文のようなものが少しある。 04:39.760 --> 04:45.670 つまり、 トークナイザーがシーケンスの最後を埋める必要がある場合は、 文末トークンを使い、 04:45.670 --> 04:48.970 それを繰り返すように指示するのです。 04:48.970 --> 04:51.400 そうすれば、 右側に表示されるはずだ。 04:51.400 --> 04:54.430 これは、 トレーニングのときに起こる標準的なことだ。 04:54.430 --> 04:56.200 今は実際に使うことはない。 04:56.320 --> 04:57.910 だから、 心配する必要はないよ。 04:57.910 --> 04:59.740 でも、 でも、 このようなことはあちこちで目にすることだろう。 04:59.740 --> 05:04.300 このラインもそうだが、 非常に標準的なセットアップだ。 05:04.300 --> 05:10.540 私たちがやっているのは、 トークナイザーを作り、 llama 3を読み込むことです。 ベースモデル1台。 05:10.540 --> 05:15.370 そして、 5を使い切っている。 あなたが期待している6GBのメモリ。 05:15.370 --> 05:22.090 そうだ、 55だ。 9、 それは私が下で推論を行ったからだと思う。 05:22.240 --> 05:29.710 ええと、 でも、 そうだね、 4ビットにスリム化したモデルなんだ。 05:30.250 --> 05:34.810 この関数は、 最近フロンティア・モデルの価格抽出で使ったので、 05:34.840 --> 05:43.780 おなじみのものだろう。 05:43.780 --> 05:55.570 例えば、 priceをドル999で抽出するような場合、 文字列として持っている必要がある。 05:55.570 --> 05:57.040 だから、 それではうまくいかない。 05:57.040 --> 06:01.120 価格は9999ドルだ。 06:01.540 --> 06:04.600 価格は999ドル。 06:04.840 --> 06:05.770 とても安い。 06:07.060 --> 06:07.960 何でもいい。 06:08.260 --> 06:10.210 ああ、 そうなるといいんだけど......。 06:10.240 --> 06:10.540 そうだ。 06:10.570 --> 06:12.610 99999を抜き取るということだ。 06:12.610 --> 06:16.760 しかし、 このモデルは、 プロンプトの中で提供されることは分かっている。 06:21.860 --> 06:25.820 そして、 このモデルが予測する。 06:25.820 --> 06:30.080 これがテスト・ハーネスで使用する関数だ。 06:30.080 --> 06:33.020 これは、 そのことを伝える機能である。 06:33.050 --> 06:34.790 これからプロンプトを出す。 06:34.790 --> 06:37.550 そして、 その費用がいくらかかるのかを知りたい。 06:37.550 --> 06:44.540 数週間前にやったのと同じように、 推論モードでモデルを呼び出す方法だ。 06:44.810 --> 06:52.490 ええと、 プロンプトをトークナイザーのドット・エンコードを使ってエンコードします。 06:52.490 --> 06:55.820 これをGPUに押し出す。 06:56.510 --> 07:01.400 あー、 これはただ、 あー、 超どうでもいいことなんだ。 07:01.400 --> 07:03.020 警告が表示されなくなる。 07:03.020 --> 07:06.680 だから、 実際には何の影響もない。 07:07.190 --> 07:22.880 正確には、 入力トークンの領域で起こっていることを予測しようとするのを防いでいるんだ。 07:22.880 --> 07:24.170 いずれにせよ、 そうなるだろう。 07:24.170 --> 07:27.230 しかし、 もし私たちがそれを明確に伝えなければ、 警告を出すだろう。 07:27.410 --> 07:33.380 そこで、 ベースモデルをレンマ3と呼ぶことにする。 1. 07:33.380 --> 07:36.950 そしてgenerateメソッドを呼び出す。 07:36.980 --> 07:38.720 インプットを渡す。 07:38.720 --> 07:41.930 私たちは新規トークンの最大数を言うつもりだ。 07:41.930 --> 07:43.340 もっと少ない数字にできるはずだ。 07:43.340 --> 07:44.900 本当に必要なのはトークン1つだけだ。 07:44.900 --> 07:51.680 万が一、 別のドル記号などが表示された場合に備えて、 最大4つのトークンを生成できるようにしている。 07:52.100 --> 07:58.130 ええと、 警告を出さないように設定したアテンションマスクの中を通過するんだ。 07:58.130 --> 08:00.590 そしてこれは、 ただひとつの答えを返してほしいと言っているにすぎない。 08:00.590 --> 08:03.290 複数の答えが返ってくることは避けたい。 08:03.680 --> 08:08.000 そして、 その1つの答えを返すと、 また送られてくる。 08:08.000 --> 08:13.130 そして、 トークナイザー・ドット・デコードを呼び出して文字列に戻す。 08:13.130 --> 08:15.830 そして、 その文字列を取り出す。 08:16.340 --> 08:17.000 分かった。 08:17.000 --> 08:18.240 だからエキサイティングだ。 08:18.240 --> 08:20.280 思い出してみよう。 08:20.280 --> 08:27.270 では、 0番目、 つまり最初のテスト項目を例にとると、 こうなる。 08:27.270 --> 08:30.000 純正のACコンプレッサーだ。 08:30.030 --> 08:33.780 実際の価格は374ドル。 08:33.810 --> 08:34.920 誰が知っていた? 08:34.920 --> 08:37.440 では、 最初のショットをご覧いただこう。 08:37.440 --> 08:40.080 だから、 モデルということになる。 を予測する。 08:42.870 --> 08:44.010 テストゼロ。 08:44.010 --> 08:48.390 そして、 そのプロンプトを出すために、 私はテキストを呼び出すだけだ。 08:49.050 --> 08:50.190 準備はできているか? 08:50.220 --> 08:50.970 さあ、 始めよう。 08:51.000 --> 09:02.850 ラマ 3. 1ベースモデルは、 何か修理キット大丈夫とOEM ACコンプレッサーの価格を予測しようとする。 09:02.850 --> 09:07.470 そして、 1800ドルという予想はかなり外れている。 09:07.470 --> 09:12.960 ということは、 リャマが3位になるには悪い予兆かもしれない。 ベースモデルは1台。 09:12.960 --> 09:20.460 ただ、 最初の例は運が悪かっただけかもしれないが、 それは次のビデオで明らかになるだろう。