WEBVTT 00:01.010 --> 00:02.810 Jupyter Labへようこそ。 00:02.810 --> 00:10.520 前回は、 基本中の基本のベースラインを作るために、 商品の価格を予測するための愚かなモデルをいくつか見てみた。 00:10.550 --> 00:14.270 次は、 もっと興味深いベースライン・モデルを見てみよう。 00:14.270 --> 00:20.900 これはもちろん、 一律の平均価格を予測する非常にシンプルなモデルを示した図である。 00:21.230 --> 00:30.740 小さな、 小さな変更にお気づきかもしれませんが、 黄色は見づらいと思うので、 ここにあった黄色をより見やすいオレンジ色に変更しました。 00:30.740 --> 00:34.370 しかし、 そうでなければ、 これはあなたにとって見慣れた写真になるはずだ。 00:34.460 --> 00:39.950 そして、 平均して145ドルの差があることにお気づきだろう。 00:40.010 --> 00:49.610 この前の図を見たとき、 これを見せたかどうか定かではないが、 平均して340ドルの差があったことを述べておく。 00:49.610 --> 00:56.420 だから、 平均を取るよりランダムに当てる方が、 明らかに成績が悪い。 00:57.170 --> 01:02.980 データセットが均等に分布していないからだ。 01:02.980 --> 01:06.220 それはええと、 ノルドは平均500だ。 01:06.940 --> 01:08.170 ああ、 わかった。 01:08.170 --> 01:20.230 それではここで、 特徴工学の話題に移りたいと思います。 特徴工学は、 伝統的な機械学習技術の中でも最も基本的なもののひとつです。 01:20.230 --> 01:23.470 率直に言って、 データ・サイエンスはかつてそうだった。 01:23.470 --> 01:25.060 これが私たちのやることだ。 01:25.060 --> 01:31.120 この種の問題が出てきたとき、 あなたはこの問題の側面は何か、 01:31.120 --> 01:40.570 アマゾンの各商品のどのような側面が、 価格を予測するのに最も適しているかを考え始めるだろう。 01:40.570 --> 01:54.010 そして多くの時間を、 フィーチャー・エンジニアリングと呼ばれる、 特定の商品のどのような特性がその価格を予測するのに最も意味があるのかを解明することに費やした。 01:54.190 --> 02:00.790 ディープ・ニューラル・ネットワークがそのすべてを代行してくれるとわかるまでは、 人々はその作業に多くの時間を費やしていた。 02:00.910 --> 02:12.370 もう1度言っておくと、 フィーチャー・エンジニアリングと伝統的な機械学習が素晴らしい結果を出すこともある。 02:12.370 --> 02:14.860 それがあなたの問題に必要なこともある。 02:14.860 --> 02:19.630 アマゾンの商品の場合、 そのような領域に入っていると思うかもしれない。 02:19.690 --> 02:21.970 あー、 でも、 どうなるか様子を見よう。 02:21.970 --> 02:24.370 そこでまず、 あることを思い出してほしい。 02:24.370 --> 02:29.590 トレーニング・データのひとつを見てみよう。 02:29.590 --> 02:31.630 detailsというフィールドがある。 02:31.630 --> 02:36.280 これはアマゾンのデータセットから吸い出したフィールドのひとつだ。 02:36.430 --> 02:41.230 これはPythonの辞書のようなものです。 02:41.260 --> 02:42.790 一見したところ。 02:42.910 --> 02:44.800 あなたはキーと値を見ている。 02:44.860 --> 02:48.280 ええと、 でも、 実は全部が文字列であることにお気づきでしょうか。 02:48.280 --> 02:50.380 ええと、 すべて大きな糸なんだ。 02:50.380 --> 02:53.980 これは辞書を表すJSONブロブだ。 02:54.190 --> 03:00.640 トレーニングでもテストでも、 データセットのすべてのポイントでこの詳細フィールドを読み込んで、 03:00.640 --> 03:07.040 テキストからPython辞書に変換できたらいいですね。 03:07.040 --> 03:10.160 そして幸運なことに、 標準ライブラリーがその方法を教えてくれる。 03:10.160 --> 03:19.430 JSONパッケージを使えば、 Jsonができる。 をロードまたはロードストリングすると、 これらの文字列をオブジェクトに変換する。 03:19.430 --> 03:22.880 だから、 それを実行して、 それを実行するんだ。 03:22.910 --> 03:25.190 数秒かかるだけだ。 03:25.190 --> 03:30.830 そして今、 私ができることは、 トレイン・ゼロのドット機能だ。 03:30.830 --> 03:36.830 同じ文字列がPythonの辞書に変換される。 03:37.010 --> 03:37.550 見てみよう。 03:37.550 --> 03:38.540 それを実行しよう。 03:38.570 --> 03:39.680 これでよし。 03:39.710 --> 03:40.820 それはわかるだろう。 03:40.850 --> 03:41.180 申し訳ない。 03:41.210 --> 03:46.220 辞書を拡大すると、 そのテキストと同じであることがわかる。 03:46.430 --> 03:50.900 実際、 ドットキーを使えば、 そのキーがここにあることがわかる。 03:51.380 --> 04:00.320 今、 私たちのデータには問題がある。 それは、 これらの辞書が商品によって異なるデータが入力されていることだ。 04:00.320 --> 04:05.320 製品によっては、 ええと、 機能がまったくないものもある。 04:05.440 --> 04:09.700 中には、 うーん、 ただ、 まばらな、 うーん、 特徴のない人もいる。 04:09.700 --> 04:11.950 だから、 人口に齟齬がある。 04:11.950 --> 04:13.630 それを感じ取ってみよう。 04:13.720 --> 04:21.520 Python標準ライブラリのもう一つの便利なツール、 collectionsパッケージのカウンターを使うことができる。 04:21.550 --> 04:26.470 カウンターを使えば、 いろいろなことを数え上げることができるし、 04:26.470 --> 04:35.290 例えば、 "特徴数"、 "最も一般的なドット"、 "最も一般的な40個 "などと言うことができる。 04:35.290 --> 04:37.990 何が返ってくるか見てみよう。 04:38.200 --> 04:46.450 つまり、 ここに表示されているのは、 すべてのトレーニング・データ・ポイントに対して入力された、 最も一般的な40の特徴です。 04:46.690 --> 04:51.340 それで、 最初に空いた日付はたくさん埋まっているんだ。 04:51.370 --> 04:52.180 ほとんどね。 04:52.180 --> 04:52.810 ああ、 そうだね。 04:52.840 --> 05:03.970 人口40万人のうち36万人というデータセットがある。 05:04.090 --> 05:07.190 ええと、 アイテムの重量は非常によく人口に膾炙している。 05:07.220 --> 05:08.990 メーカーブランド。 05:09.020 --> 05:10.820 よく似たベストセラーだ。 05:10.820 --> 05:14.780 ランクも人口が多く、 その後は尻すぼみになる。 05:15.050 --> 05:19.910 では、 どのような機能を使うのが良いのだろうか? 05:19.910 --> 05:22.520 まあ、 私たちは本当に人口の多いものを探しているんだ。 05:22.520 --> 05:23.600 いいスタートだ。 05:23.630 --> 05:33.350 私たちは一貫して人口に膾炙していることを望み、 また、 価格と有意義に関連しそうだと感じられるものであることを望む。 05:34.040 --> 05:38.600 それで、 これらのアイテムの重さを見ると、 かなり堅実な候補だと感じられる。 05:38.630 --> 05:47.300 つまり、 明確ではないが、 おそらく重量と価格にはある程度の相関関係があると思う。 05:47.510 --> 05:56.180 もっと大きくて、 もっと重くて、 もっと平均的な価値があるような、 05:56.360 --> 06:03.920 ブランドのような......。 06:03.950 --> 06:04.880 何かあるかもしれない。 06:04.880 --> 06:07.360 それはベストセラーになるようなことだ。 06:07.390 --> 06:08.980 だから、 まずはそこから始めよう。 06:09.010 --> 06:12.430 それらはそもそも妥当な機能だと感じる。 06:12.430 --> 06:16.990 そして、 もうひとつ、 少し前に話したことに戻るが、 追加しよう。 06:17.320 --> 06:21.850 ええと、 だから、 ちょっとジャンキーなことから始めようと思うんだ。 06:21.880 --> 06:25.090 ここに書いたように、 これはちょっと陳腐なものだ。 06:25.210 --> 06:34.510 この辞書に入力されているウェイトは、 とても汚いデータなんだ。 06:34.510 --> 06:40.450 ポンド単位の場合もあれば、 オンス単位の場合もあるし、 100分の1ポンドやミリグラム、 06:40.450 --> 06:45.490 キログラムなどさまざまだ。 06:45.490 --> 06:52.000 だから、 ここに大きな古いif文があって、 この重さがどの単位で計算されるかを調べ、 06:52.000 --> 06:58.720 それをポンド数に変換して、 その金額を返しているんだ。 06:58.720 --> 07:00.100 だから、 これはそういうことなんだ。 07:00.100 --> 07:03.100 これで仕事ができると必ずしも納得させるつもりはない。 07:03.100 --> 07:04.270 私の言葉を信じることができるだろう。 07:04.270 --> 07:09.330 あるいは、 私に不信感を抱いているのであれば、 この中に入って試してみてほしい。 07:09.510 --> 07:16.170 それから、 トレーニングに必要なウエイトも全部揃えるつもりだ。 07:16.350 --> 07:25.230 そして、 この行は、 もし明らかでなければ、 ここから「なし」をフィルタリングして、 07:25.230 --> 07:36.030 もし私がその単位を認識していないものがあれば、 「なし」を返すようにしています。 07:36.030 --> 07:40.800 平均重量は13ポンド。 6. 07:40.950 --> 07:44.430 なぜ平均体重を計算する必要があるんだ? 07:44.430 --> 07:49.350 少し技術的な理由ですが、 このような線形回帰を扱う場合、 07:49.350 --> 07:59.880 学習セットの10%の項目のうち、 重みを持たない項目をどのように扱うかを決定する必要があります。 07:59.880 --> 08:11.180 データサイエンティストの皆さんは、 重みがあるかないかを表す特徴量を使うトリックがあることをご存知でしょう。 08:11.300 --> 08:16.880 そして、 それをどのようにモデルに組み入れるか、 少し、 小細工をしなければならない。 08:16.940 --> 08:22.880 もし重みがないのであれば、 平均値を選んでそれを入れるというのも、 08:22.880 --> 08:26.420 ひとつのアプローチとして立派なものだ。 08:26.420 --> 08:34.700 この関数はアイテムを受け取り、 その重量を取得しようとします。 そして重量を返すか、 08:34.700 --> 08:41.360 重量がゼロかゼロでないかを返します。 08:41.360 --> 08:46.040 重さがないものは、 代わりに平均的な重さに置き換える。 08:46.580 --> 08:49.940 ええと、 これがデフォルトで体重を測るということですね。 08:50.690 --> 08:55.100 私たちがフィーチャー・エンジニアリングをしていく中で、 これはかなり、 ええと、 グロテスクな仕事だったと思う。 08:55.100 --> 08:58.760 だから、 ちょっと休憩して、 私たちがやらなければならない他の機能について熟考してもらおうと思う。 08:58.790 --> 09:04.880 そしてまた戻ってきたら、 フィーチャー・エンジニアリングを終えてモデルを実行する前に、 ベストセラー・ランクに入るつもりだ。 09:04.880 --> 09:06.650 そして、 それがどのように価格を予測するかを見ている。 09:06.680 --> 09:07.910 すぐに会おう。