WEBVTT 00:00.620 --> 00:03.290 そして、 6週目のフォルダーへようこそ。 00:03.290 --> 00:08.450 私たちは今、 データ・キュレーションの最終段階である2日目を迎えている。 00:08.720 --> 00:11.840 これからデータセットをもっと大きくしていくつもりだ。 00:11.840 --> 00:16.880 そして、 私たちはそれを特別な、 あー、 ちょうどいいものに作り上げるんだ。 00:16.880 --> 00:27.110 トレーニングの目的としては、 まずインポートして環境を整え、 ハグフェイスにログインして準備をする。 00:27.260 --> 00:37.550 前回、 私が書いたitemsというPythonモジュールの話をした。 00:37.550 --> 00:44.750 あなたはそれをよく覚えているし、 願わくば、 あなた自身がこれを調べ、 それが機能する方法を確認するのに時間を費やしたことがあるだろう。 00:44.750 --> 00:51.470 私が作ったPythonモジュールには、 00:51.470 --> 01:02.060 loadersと呼ばれるもっと短くてシンプルなものがある。 01:02.540 --> 01:10.850 Pythonのコンカレント・フューチャーズ・パッケージを使い、 01:10.850 --> 01:16.700 複数のワーカーでこれを行う。 01:16.850 --> 01:20.780 あまり詳しく説明する必要はないだろう。 01:20.780 --> 01:26.870 いくつかお伝えしたいことがあるのですが、 それについてはまた、 書いてあるとおりになっているとご自身を納得させてください。 01:26.990 --> 01:31.130 メインで呼ばれるメソッドはloadだ。 01:31.130 --> 01:35.990 そして労働者の数を渡すと、 デフォルトでは8人の労働者を想定している。 01:35.990 --> 01:41.420 私は8コアのMacBook Proで作業しているので、 対応できる。 01:41.450 --> 01:43.430 私のマシンに大きな衝撃を与えている。 01:43.430 --> 01:44.300 そうしているうちに 01:44.300 --> 01:50.090 同時に他のことをしないのであれば、 マシンのCPUをどれだけ捨てても構わないかにもよるが、 01:50.090 --> 01:54.020 より少ない数のワーカーを渡した方がいいかもしれない。 01:54.350 --> 02:02.480 ええと、 では、 このロード・イン・パラレル方式は、 このプロセスを使うものですね。 02:02.480 --> 02:03.470 プール執行人。 02:03.500 --> 02:09.560 ご存知の方、 使ったことがある方はわかると思うが、 これは基本的にいくつもの他の選手を生み出す。 02:09.680 --> 02:16.520 今、 ミスを見つけたんだけど、 "workers "と書くべきところを、 "8 workers "と書いてしまったんだ。 02:16.520 --> 02:18.320 そうでなければ、 常に6本を使うことになる。 02:18.590 --> 02:32.300 そして、 指定された数のワーカーを起動し、 各データポイントを読み込みます。 02:32.300 --> 02:42.500 そして、 私がやったことは、 ジェネレーターに慣れ親しんだジェネレーターを作っただけだということがお分かりいただけると思います。 02:42.650 --> 02:48.440 でも、 私たちはジェネレーターを使って、 データセットを切り刻んでいるんだ。 02:48.470 --> 02:51.350 たまたまだが、 ここではチャンクサイズを1000に設定した。 02:51.350 --> 02:53.360 つまり、 一度に1000のデータポイントだ。 02:53.360 --> 02:56.960 そのため、 一度に1000点のデータセットに分割される。 02:56.960 --> 03:08.970 そして、 それぞれのチャンクが渡され、 最終的には、 前回作業したのと同じアイテム・クラスを使って新しいデータ・ポイントを作成する。 03:08.970 --> 03:10.650 だから、 ここに本当のマジックはない。 03:10.650 --> 03:16.290 これは、 効率的な方法で商品を積み込むための、 ちょっと凝った包装に過ぎない。 03:16.320 --> 03:20.820 一度に1000人、 8人の作業員に分散している。 03:20.820 --> 03:28.350 しかし、 このコードを見直す価値はあると言っておく。 なぜなら、 この種のプロジェクトではよくやりがちなことだからだ。 03:28.350 --> 03:40.110 箱は重くなるし、 複数の作業員に分担するのに適した作業内容であることが多いからだ。 03:40.110 --> 03:42.210 そして、 このコードはかなり再利用できるはずだ。 03:42.240 --> 03:50.520 読みやすく、 再利用しやすいように書いたつもりなので、 ぜひそうしてほしい。 03:51.150 --> 03:56.490 それと、 もうひとつ、 ちょっとしたトリックがあるんだ。 03:56.490 --> 03:56.700 申し訳ない。 03:56.730 --> 04:02.010 もうひとつ、 えーと、 えーと、 結果に影響する決定がなされた。 04:02.160 --> 04:15.180 ええと、 0ドルの間の商品だけを選ぶことにしました。 50ドルと999ドルと0ドル。 04:15.180 --> 04:15.180 49. 04:15.180 --> 04:19.380 だから、 その範囲の価格のものに限定するつもりだ。 04:19.380 --> 04:21.270 そうした理由はいろいろある。 04:21.390 --> 04:29.460 ええと、 ひとつは、 その数字よりはるかに大きいものを取ると、 結果が歪んでしまうということです。 04:29.490 --> 04:37.290 ごくわずかなことだが、 大きな代償を伴うことがあり、 それが我々のテストパフォーマンスのようなものを完全に台無しにしてしまうことがある。 04:37.290 --> 04:43.830 たまたま莫大な値段のものを選んでしまった場合、 少しずれただけで誤差が大きくなってしまう。 04:43.830 --> 04:50.310 また、 絶対誤差を使用したいので、 推奨価格と実際の価格との差だけである。 04:50.340 --> 05:00.870 価格が妥当な範囲に保たれていれば、 そのモデルがどのようなパフォーマンスをしているのかをきちんと把握することができる。 05:00.870 --> 05:08.790 だから基本的に、 このプロジェクトの範囲、 我々がやろうとしていることについては、 1,000ドル以下のものについて話すつもりだと言っているんだ。 05:08.790 --> 05:13.800 それが私たちのスコープとなり、 データセットに集中することができる。 05:13.890 --> 05:21.150 また、 境界線を変えてやってみたり、 より大きな範囲を試してみたりして、 様子を見ることもできる。 05:21.150 --> 05:26.040 しかし、 私はこれが最も扱いやすく、 全体的に良い結果をもたらすと感じた。 05:26.040 --> 05:28.920 それがここで起こっていることだ。 05:29.370 --> 05:34.980 じゃあ、 これを保存して、 今日の話に戻ろうか。 05:34.980 --> 05:45.840 ちょっとバグを修正したので、 カーネルを再起動してもう一度実行します。 05:45.840 --> 05:50.310 インポートを実行し、 再びHuggingfaceにログインする。 05:50.400 --> 05:59.760 そして今度は、 前と同じように家電製品のデータセットをロードする。 06:00.300 --> 06:07.500 前回、 家電製品のデータセットをすべて読み込むのに約1分かかったが、 06:07.500 --> 06:14.070 今回は0分だ。 2分。 06:14.070 --> 06:17.190 だから、 むしろ分解した方が早いんだ。 06:17.220 --> 06:20.280 8人の作業員が私のコンピューターを叩いている。 06:20.400 --> 06:22.440 だから、 あなたにもそうすることを勧める。 06:22.440 --> 06:29.850 しかし、 工程数が少なければ、 明らかにここでパスする労働者は4人以下になる。 06:30.330 --> 06:34.830 これが家電製品のデータセットだ。 06:34.830 --> 06:42.600 28,625のデータポイントがあり、 その範囲内で価格が設定されている。 06:42.870 --> 06:47.610 ええと、 それらはすべてロードされています。 06:47.640 --> 06:49.470 最初は何だったか覚えている? 06:51.780 --> 06:52.620 またやってしまった。 06:52.650 --> 06:53.610 前回もそうだった。 06:53.610 --> 06:53.970 これでよし。 06:54.000 --> 06:54.810 これを試してみてほしい。 06:55.020 --> 06:56.400 そして、 これだ。 06:56.400 --> 06:59.490 ラック、 ローラー、 スタッドのアッセンブリーキットです。 06:59.520 --> 07:02.220 そのプロンプトを印刷してみよう。 07:04.530 --> 07:12.690 そして、 願わくば、 そのような不格好な部品番号がフィルターにかけられたものであることをもう一度納得させたい。 07:12.720 --> 07:13.740 そうだ。 07:13.770 --> 07:19.350 そしてこれが、 やはり食器洗い機のトップラックリールとスタッド組み立てキットだ。 07:22.680 --> 07:26.460 そしてこれがドアピボットブロック。 07:26.850 --> 07:28.500 いつもそれを必要としていた。 07:28.650 --> 07:30.510 ああ、 そうだ。 07:30.660 --> 07:35.100 ええと、 ここにデータがあります。 07:35.460 --> 07:43.560 うーん、 これからは規模を拡大し、 もっと大きな問題に着手する時期になるだろう。 07:43.560 --> 07:49.980 我々はアマゾンからこれらのデータセットをすべて持ち込むつもりだ。 07:49.980 --> 07:55.120 商品価格データセットのリポジトリです。 07:55.150 --> 08:01.810 これらは、 大きなホームセンターで売っているような、 かなり似たような種類のものを選んだ。 08:01.810 --> 08:10.690 つまり、 服や美容品、 本、 ソフトウェアといったものを除けば、 アマゾンにあるものならほとんど何でも手に入るということだ。 08:10.690 --> 08:14.650 だから、 似たようなものだと感じたのは全部そうなんだ。 08:14.740 --> 08:18.040 うーん、 それは本当に良い包括的なデータセットになるだろうね。 08:18.040 --> 08:19.570 これがそのデータセットだ。 08:19.570 --> 08:25.000 そしてもちろん、 もしあなたがこれをフォローしながらやっているのであれば、 もしあなたがこれをやっているときにこれをやっているのであれば、 08:25.000 --> 08:30.550 これをやっているときにこれをやっているのであれば、 これで遊ぶことができますし、 別のデータセットを選ぶこともできます。 08:30.550 --> 08:31.030 お望みなら 08:31.030 --> 08:34.090 洋服のためにこれをやって、 そのパフォーマンスを見ることができるだろう。 08:34.180 --> 08:40.480 ええと、 もしあなたがデータサイズを気にしていて、 より速く物事を進めたいのであれば、 データを制限すればいい。 08:40.480 --> 08:43.450 家電製品のデータセットは、 その中でも最も小さいもののひとつだ。 08:43.480 --> 08:46.210 ええと、 エレクトロニクスはナイスで、 真ん中に1つ。 08:46.210 --> 08:48.340 だから、 エレクトロニクスに集中すればいい。 08:48.520 --> 08:57.730 それでも、 とても楽しいし、 データセット全体を使った場合とほとんど同じようなパフォーマンス結果を得ることができる。 08:57.880 --> 09:00.160 これがすべてのデータセット名だ。 09:00.160 --> 09:06.550 そして今、 私はアイテム・ローダーを使ってそれらを追いかけるために、 それらをすべて読むつもりだ。 09:06.550 --> 09:09.370 そして、 一人ずつ読み込んでいく。 09:09.370 --> 09:12.790 最大のものは、 リストの最初にある自動車だ。 09:12.790 --> 09:16.180 私は大体、 最初に一番大きなものを注文してきたと思う。 09:16.330 --> 09:29.110 というのも、 最初にこれを実行するとき、 Huggingfaceからあなたのコンピューターにデータをダウンロードする必要があるからです。 09:29.230 --> 09:33.130 うーん、 でも、 そのせいでちょっと、 うーん、 時間がかかるかもしれない。 09:33.130 --> 09:35.170 そして出発する。 09:35.380 --> 09:40.180 今、 私のコンピューターにかかる時間は合計で20分ほどだ。 09:40.240 --> 09:50.080 ええと、 CPUがパンクしそうなので、 一旦中断して、 データがすべて読み込まれた休憩の直後にまたお会いしましょう。