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.
 
 

286 lines
11 KiB

WEBVTT
00:00.620 --> 00:07.460
そして、 私がデータをクレンジングし、 モデルに含めるべきものを捨てていないとき、
00:07.460 --> 00:15.380
私は良いことをしたと自分自身を納得させる。
00:15.470 --> 00:21.200
もしそのようなものを見つけたら、 すぐに教えてほしい。 私はモデルからもう少し汁を絞り出したり、
00:21.200 --> 00:26.360
結果を少し良くしたり、 データを変えたりするのが大好きだからだ。
00:26.390 --> 00:33.830
モデルに投入するデータの質を向上させることが、 モデルのパフォーマンスに最も大きな影響を与えた。
00:33.950 --> 00:39.980
ハイパーパラメーターのチューニングと呼ばれるものに膨大な時間を費やすことができる。 私たちは皆、
00:39.980 --> 00:44.690
しばらくの間、 自分のモデルからほんのわずかな力を絞り出し、 フロンティアモデルに対して真っ向勝負を挑む中で、
00:44.690 --> 00:50.450
結果を予測する能力を少しでも高めようとする。
00:50.540 --> 00:58.850
しかし、 結局のところ、 そのデータの質を向上させることが、 針を動かす最も簡単で効果的な方法なのだ。
00:58.850 --> 01:01.640
だからこそ、 時間を費やす価値があるんだ。
01:01.640 --> 01:08.600
そして最後のJupyterノートブックでは、 このリストの1番、 2番、 3番、 そして4番と5番の一部に取り組んだ。
01:08.630 --> 01:16.460
まだ4と5が残っているが、 最も重要なのは、 イソムのクラスに目を通し、 それがどのように機能しているかを自分で確認することだ。
01:17.690 --> 01:33.710
さて、 最後にもう一度、 このモデルの目標が達成できたかどうかをどのように判断するかという業績評価について触れておきたい。
01:33.950 --> 01:41.150
ええと、 少し前にお話ししたように、 パフォーマンスを評価するために使える2種類の指標があります。
01:41.150 --> 01:48.020
モデル中心のメトリクスもあり、 これはモデルが数学的にどの程度うまく機能しているかを理解する、
01:48.020 --> 01:52.310
データサイエンティストの領域に近い。
01:52.430 --> 01:59.030
そして、 ユーザーやスポンサー、 CEOの心に響くような、
01:59.030 --> 02:03.650
成果ビジネス中心の指標がある。
02:03.680 --> 02:07.430
それがプロジェクトの最終目標だ。
02:07.460 --> 02:15.620
モデル中心的なものは、 モデルによってより直接的に測定可能であり、 通常はトレーニング中や最適化中に測定することができる。
02:15.650 --> 02:23.540
ビジネス中心のものは、 最も重要なものだが、 必ずしもすぐにモデルと結びつくものではない。
02:24.080 --> 02:34.760
私たちの場合、 ビジネス・セントリック・メトリックスという素晴らしい贅沢がある。
02:34.760 --> 02:41.720
トレーニング・ロスとバリデーション・ロスという言葉をよく耳にするが、 トレーニング・ロスとはトレーニング・セットでのロスのことだ。
02:41.750 --> 02:46.430
バリデーション・ロスは、 バリデーション・セット、 つまり、 あなたが保留したデータの一部である。
02:46.880 --> 02:54.620
これはモデルが計算する指標で、 後で詳しく説明する。
02:54.620 --> 03:05.120
トレーニングの過程で、 トレーニングの損失が徐々に減っていくのがわかるだろう。
03:05.510 --> 03:15.240
そして、 より洗練されたデータサイエンスの指標もあり、 それらも様々な場面で見ていくつもりだ。
03:15.240 --> 03:19.230
平均二乗対数誤差と呼ばれるものがある。
03:19.260 --> 03:20.190
RMSE l.
03:20.490 --> 03:27.690
この特別なエラーの利点は、 モデルが絶対的に間違っている場合と、 パーセンテージベースで間違っている場合の両方で、
03:27.690 --> 03:33.390
モデルにペナルティを与えることができることだ。
03:33.390 --> 03:38.910
また、 低価格の商品で数ドルの差があっても、 そのモデルに不当なペナルティを課すことはない。
03:38.910 --> 03:47.460
つまり、 絶対的な差と相対的なパーセンテージの差を天秤にかけた、 バランスの取れた指標なのだ。
03:47.640 --> 03:48.990
うーん、 適当だ。
03:48.990 --> 03:51.450
だから、 その点にも注目している。
03:51.480 --> 04:00.900
もうひとつは、 もっと単純な平均二乗誤差で、 これは予想と実際の価格の差の二乗である。
04:00.990 --> 04:06.270
平均二乗誤差の課題は、 価格が大きくなると爆発してしまうことだ。
04:06.270 --> 04:14.100
つまり、 800ドルのものを900ドルと予想した場合、 そこには100ドルの差がある。
04:14.100 --> 04:21.330
二乗すれば1万となり、 これは大きな数字で、 他のすべての誤差を凌駕する。
04:21.420 --> 04:26.460
そのため、 平均二乗誤差は私たちのような問題にとってはより厄介なものとなる。
04:26.850 --> 04:29.340
これがモデル中心の評価基準だ。
04:29.340 --> 04:32.040
しかし、 次はビジネス指標について話そう。
04:32.040 --> 04:37.890
だから、 この問題の素晴らしいところは、 どちらの陣営にも属するこの指標があるということだ。
04:37.890 --> 04:42.480
あくまで平均的な絶対価格差だ。
04:42.480 --> 04:45.210
基本的に、 このモデルがいかに間違っていたか。
04:45.210 --> 04:49.560
冷蔵庫は100ドルと書いてあったが、 実際は120ドルだった。
04:49.560 --> 04:51.060
だから20点差だった。
04:51.090 --> 04:56.220
その平均的な価格差はとてもシンプルで、 人間的で、 理解できる。
04:56.460 --> 05:00.240
そして、 それは素晴らしいビジネス成果の指標である。
05:00.240 --> 05:01.710
欠点もある。
05:01.710 --> 05:10.050
800ドルもするような高価なものが、 もし850ドルもするようなものだとわかったら、
05:10.050 --> 05:14.670
悪くないと思う。
05:14.670 --> 05:18.990
しかし、 これは50ドルのエラーにカウントされる。
05:19.230 --> 05:24.720
一方、 10ドル、 10ドルのものであれば、 50ドル差よりはずっといいものを作りたいと思うだろう。
05:24.720 --> 05:26.100
だから理想的ではない。
05:26.100 --> 05:29.460
いくつか問題はあるが、 かなりいい。
05:29.460 --> 05:34.710
そして、 我々のモデルが良い結果を出しているかどうかを判断する、 人間にとって理解しやすい方法を与えてくれる。
05:34.890 --> 05:41.970
それに関連して、 価格差のパーセンテージを見ることもできる。
05:41.970 --> 05:48.990
その方が理にかなっているし、 高額商品には合理的だが、 安い商品には少し不公平に思える。
05:49.200 --> 05:51.540
10ドルのものが12ドルになる。
05:51.570 --> 05:56.370
それなら、 20%アウトというのはちょっと厳しすぎるような気がする。
05:57.120 --> 06:03.690
そしてもう一つの方法は、 見積もりが良質であると判断するための基準を持つことです。 その基準は、
06:03.690 --> 06:09.000
絶対的な差とパーセンテージの差を組み合わせることができます。
06:09.000 --> 06:18.780
40ドル以内か、 20%以内ならヒットだと思う。
06:18.780 --> 06:20.370
私は、 これは良い見積もりだと思っている。
06:20.400 --> 06:22.530
十分な見積もりだ。
06:22.680 --> 06:30.870
そうすれば、 モデルの予測の何パーセントがその基準を満たし、 良好とみなされるかを測定することができる。
06:30.900 --> 06:36.030
だから、 これもビジネス指標として使えるし、 使うつもりだ。
06:36.180 --> 06:40.860
それで、 これがパフォーマンスを評価する方法なんだ。
06:40.860 --> 06:46.110
そして、 私たちのプロジェクトで嬉しいのは、 彼らがとても人間的になることだ。
06:46.110 --> 06:47.070
理解できる。
06:47.070 --> 06:53.340
そのため、 異なるモデルや異なるハイパーパラメーターを試すようなことができるようになる。
06:53.370 --> 06:54.510
いろいろなモデルを試してみるつもりだ。
06:54.510 --> 06:56.790
フロンティアとオープンソースを試してみるつもりだ。
06:56.790 --> 07:03.360
そして、 単純にどれが商品価格の予測に優れているかを見ることができるだろう。
07:04.920 --> 07:14.820
そして、 私たちは袖をまくり、 コーディングに取り掛かり、 これがどのように機能するか、 どのように価格を予測できるかを評価する準備がほとんどできている。
07:14.820 --> 07:16.740
そして、 とても楽しくなりそうだ。
07:16.830 --> 07:20.970
ええと、 でも、 その前にやらなきゃいけないことがいくつかあるんだ。
07:21.000 --> 07:30.340
このような問題を解決するためのビジネス戦略について少しお話したいと思います。
07:30.370 --> 07:36.010
そして、 もしあなたが私のようなものであれば、 早くこの世界に入りたい、
07:36.040 --> 07:40.810
この世界に入りたいとうずうずしていることだろう。
07:40.900 --> 07:48.010
でも、 この基礎固めをしておきたいんだ。 そうすれば、 ビジネス上の問題を解決するときに、
07:48.100 --> 07:52.060
その背景がより強固なものになるからね。
07:52.690 --> 08:00.130
パフォーマンスを向上させるためのさまざまなテクニックを対比させ、 それぞれの違いは何なのか?
08:00.130 --> 08:04.990
どんな状況でラグを使うのか?
08:04.990 --> 08:07.570
どのような状況で微調整を行うのですか?
08:07.570 --> 08:09.340
よく聞かれる質問だ。
08:09.370 --> 08:12.250
そのことをはっきりさせておいた方がいいと思うんだ。
08:12.250 --> 08:18.040
だから、 その文脈を理解した上で、 データセットについてまだ宿題があるんだ。
08:18.070 --> 08:21.640
まだ最終的なデータセットをキュレーションしてアップロードしなければならない。
08:21.640 --> 08:22.570
大きくなるだろうね。
08:22.570 --> 08:25.690
大きなデータセットになるだろうし、 たくさんのトレーニングをしたいからね。
08:25.810 --> 08:27.430
だから、 そこでもう少しやることがある。
08:27.460 --> 08:30.580
そのすべてが、 明日やってくる。
08:30.610 --> 08:31.420
ではまた