WEBVTT 00:01.490 --> 00:06.830 それは、 おそらく他の部分ほど華やかではないが、 00:06.830 --> 00:12.770 おそらく最も重要なものである。 00:12.770 --> 00:16.850 そして、 データを狩るために人々がデータを探しに行ける場所はたくさんある。 00:16.850 --> 00:19.010 でも、 最初に、 最初に行く場所。 00:19.040 --> 00:25.640 もちろん、 何よりもまず、 あなたの会社が持っている独自のデータだ。 00:25.640 --> 00:34.460 それは願わくば、 あなたが解決しようとしている問題に直接関係するものであり、 あなたの微調整にとって極めて重要なものになるだろう。 00:34.460 --> 00:41.060 架空のラグ・プロジェクトの場合、 私たちはそうした。 00:41.090 --> 00:47.120 私たちは会社の共有ドライブを持っていることにして、 ナレッジベースを構築するのに使った。 00:47.150 --> 00:51.260 これは私たちが独自データを探しに行った例だ。 00:51.260 --> 01:00.800 私のビジネスであるネビュラの場合、 人材や仕事、 キャリアに関する情報があり、 それを使って独自のモデルを育成することができる。 01:00.950 --> 01:09.140 だから、 自分の問題に特化した独自のデータセットを自社で見つけることが、 最初のスタート地点になる。 01:09.170 --> 01:15.380 もちろん、 データサイエンティストにとって素晴らしいリソースであるKaggleもある。 01:15.740 --> 01:17.600 おそらく聞いたことも使ったこともあるだろう。 01:17.630 --> 01:19.160 そうでなければ、 行って見てください。 01:19.280 --> 01:22.400 たくさんのデータがあるんだ。 01:22.430 --> 01:29.180 データというのは、 Kaggleに投稿された長い期間に渡るものです。 01:29.330 --> 01:32.390 そしてもちろん、 ハグする顔もある。 01:32.420 --> 01:36.080 僕らにとっては素晴らしい情報源だよ。 01:36.110 --> 01:39.170 そして、 ハグする顔をすぐに使うことになる。 01:39.740 --> 01:42.290 合成データもある。 01:42.290 --> 01:46.640 ラグ・プロジェクトでは、 実際の会社の共有ドライブは使いませんでした。 01:46.640 --> 01:51.350 我々はLLMを使って合成データを作成したが、 それも選択肢の一つだ。 01:51.350 --> 01:52.880 もちろん、 長所も短所もある。 01:52.880 --> 01:59.780 フロンティアモデルを使って実際にデータから学習しようとするのであれば、 フロンティアモデルにデータを生成させ、 そこから学習させるのは意味がないかもしれない。 01:59.780 --> 02:04.690 しかし、 独自のモデルを構築しようとしている、 あるいはフロンティアモデルからシードを得て、 02:04.690 --> 02:09.130 より安価なモデルを構築しようとしているのであれば、 フロントエンドモデルを使ってデータを生成し、 02:09.160 --> 02:19.870 そのデータを使って、 より小さく、 より安価で、 より軽量なモデルを学習させることができる。 02:19.870 --> 02:24.310 つまり、 合成データが意味を持つさまざまな状況だ。 02:25.060 --> 02:32.890 そして、 あなたのためにデータセットをキュレートしてくれる専門会社があることもお伝えしておこう。 02:32.920 --> 02:37.390 実はこの会社、 以前、 あるリーダーボードを見ていたときに出会ったのだが、 02:37.390 --> 02:45.940 そのリーダーボードはsealと呼ばれるもので、 scaleという会社が作成したLLMS用のビジネス別リーダーボードだった。 02:45.940 --> 02:51.040 そして、 スケールはあなたの問題に対して、 精巧なデータセットを構築することに特化している。 02:51.040 --> 02:53.500 だから、 そこも行くべき場所だ。 02:53.680 --> 02:59.650 私たちの場合は、 データの宝庫であるHugging Faceを利用する。 Hugging Faceには、 この特定のデータセットを含め、 02:59.680 --> 03:04.090 コミュニティから提供された多くのデータが含まれている。 03:04.240 --> 03:07.600 長年にわたるアマゾンのレビューをかき集める。 03:07.600 --> 03:09.940 それは莫大なものだ。 03:09.940 --> 03:11.500 実に膨大なデータセットだ。 03:11.500 --> 03:22.870 また、 レビューだけでなく、 商品の説明や価格など、 商品に関連するメタデータも持っている。 03:22.870 --> 03:28.360 そしてもちろん、 それこそが私たちが求めているもの、 商品説明と価格なのだ。 03:28.360 --> 03:33.280 そして、 このデータセットにはそれが大量に含まれている。 03:33.280 --> 03:35.680 だから僕らにとっては完璧なんだ。 03:35.680 --> 03:37.600 ここが私たちが向かう場所だ。 03:39.370 --> 03:42.640 では、 どうやってデータを掘り下げていくのか。 03:42.640 --> 03:44.530 どのようなステップを踏むのですか? 03:44.590 --> 03:48.850 今日はこの作業の一部を行い、 明日はその一部を洗練させるつもりだ。 03:49.000 --> 03:55.900 でも、 データに深く入り込むには、 おそらく6つの異なる段階がある。 03:55.900 --> 04:02.380 まず第一に、 調査をしている時に、 データを理解するために、 どのようなフィールドを持つべきか? 04:02.380 --> 04:04.420 データはどの程度蓄積されているのか? 04:04.420 --> 04:07.090 データ品質にはどのような問題がありますか? 04:07.180 --> 04:15.490 それから、 少なくとも私が好きなアプローチ方法は、 データを解析して扱いやすい構造にすることだ。 04:15.670 --> 04:19.900 つまり、 生のデータセットを扱うことはもうないんだ。 04:19.900 --> 04:23.350 その時点では、 一般的にモノを使って仕事をしている。 04:23.620 --> 04:33.340 ビジュアル化することは素晴らしいことだ。 04:33.340 --> 04:38.650 あなたの価値観の中には、 例えば商品の価格について考えているとき、 価格の幅はどれくらいですか? 04:38.650 --> 04:42.940 分布が何らかの形で偏っているものが多いことが判明したのだろうか。 04:42.940 --> 04:46.360 だから、 それを視覚化することで、 本当に良い感覚を得ることができる。 04:46.930 --> 04:49.720 今度はデータの質をより深く評価する。 04:49.720 --> 04:53.710 データにどのような制限があるかを理解する。 04:53.830 --> 05:03.630 そしてキュレーションとは、 このデータセットをどのように作るかを決めることです。 05:03.630 --> 05:16.020 例えば、 データの4分の1が何らかの形でデータ品質が低いことが判明した場合、 そのデータを完全に除外することもできる。 05:16.020 --> 05:20.190 十分に大きなサンプルを持っているので、 4分の3に集中できると思うかもしれない。 05:20.190 --> 05:25.770 データセットのバランスが非常に悪いことがわかり、 トレーニングの一環として、 05:25.770 --> 05:35.160 モデルがデータの特定のバランスしか学習しないことを懸念しているのであれば、 この機会にそのバランスに対処する可能性がある。 05:35.160 --> 05:43.110 つまりキュレーションとは、 トレーニングに最適なデータセットを作成し、 それを保存することなのだ。 05:43.110 --> 05:46.200 我々の場合は、 Huggingfaceのハブにアップロードする。 05:46.500 --> 05:50.430 これがトレーニングに入る前の最終段階だ。 05:50.460 --> 05:55.590 というわけで、 新しいプロジェクトで初めてJupyterLabに向かい、 05:55.590 --> 05:58.860 データのキュレーションに取りかかろう。 05:58.890 --> 05:59.700 そこで会おう