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.
 
 

334 lines
13 KiB

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がパンクしそうなので、 一旦中断して、 データがすべて読み込まれた休憩の直後にまたお会いしましょう。