WEBVTT 00:00.680 --> 00:01.790 皆さん、 こんにちは。 00:01.790 --> 00:10.790 私が第7週をとても楽しみにしているのは、 この時期から実際に独自のモデルを構築し始めるからだ。 00:10.790 --> 00:16.910 私たちが独自のAIを作り始めるのは、 フロンティア・モデルと競争できるようなものを作ろうとするときであり、 00:16.910 --> 00:25.550 そう、 少なくともいくつかのフロンティア・モデルを凌駕できるかどうかを試してみるときでもある。 00:25.580 --> 00:32.300 このようなことが可能なのは、 データがたくさんある特定の問題を解決しようとしているからで、 00:32.300 --> 00:38.960 フロンティア・モデルよりもかなり小さいモデルを採用できる可能性があるからだ。 00:38.960 --> 00:41.990 80億のパラメーターのようなモデルを使うことができる。 00:41.990 --> 00:50.810 そして、 1つの集中したタスクを非常に得意にすることで、 GPTフォーゼロのような巨大なジャイアンツ、 00:50.810 --> 00:53.840 巨人軍に対抗することができる。 00:54.290 --> 01:00.560 なぜなら、 GPT4は何兆ものパラメーターを持っているにもかかわらず、 大統領候補について気の利いた詩を書くなど、 01:00.560 --> 01:04.790 実にさまざまなことができるように設計されているからだ。 01:05.060 --> 01:12.620 しかし、 商品の価格を予測することに関しては、 本当に、 本当にうまくやろうと思っている。 01:12.620 --> 01:13.970 それが僕らの仕事だ。 01:13.970 --> 01:15.350 それが我々のビジネス上の問題だ。 01:15.350 --> 01:17.210 それを解決するのが私たちの目的だ。 01:17.240 --> 01:24.170 この最初のステップは、 微調整のためのベースモデルとしてどのモデルを使うかを決めることで、 01:24.170 --> 01:31.280 これは時間をかける価値のあることだ。 01:31.670 --> 01:34.880 それ自体、 巨大なハイパーパラメーターのようなものだと考えればいい。 01:34.880 --> 01:38.120 別のベースモデルを試してみて、 その結果を見ることもできる。 01:38.120 --> 01:47.360 その一環として、 私たちはそのモデルのオリジナルの事前訓練されたバージョン、 まさにベースモデルを使うかどうかを決めなければならない。 01:47.360 --> 01:53.390 チャット用に微調整されたもので、 01:53.390 --> 02:08.360 インストラクトバリアントと呼ばれることもあります。 02:08.370 --> 02:16.530 あなたが覚えているその入力スタイルは、 プロンプトのさまざまなセクションを区切る一連のトークンに変わる。 02:16.530 --> 02:18.540 だから、 それについて決断しなければならない。 02:18.540 --> 02:20.520 もちろん、 長所も短所もある。 02:20.700 --> 02:26.550 そうしたら、 ベースモデルをそのまま使って、 02:26.550 --> 02:34.950 我々の挑戦に対してどうなのかを見てみるべきだ。 02:34.950 --> 02:42.030 そして、 フロンティアモデルと競争していないとしても、 これが無料になること、 少なくとも私たちの負担になることを忘れないでほしい。 02:42.030 --> 02:48.840 計算を実行することで、 自分たちのオープンソース版のモデルを実行するときにAPIコストを支払う必要がなくなる。 02:48.840 --> 02:54.210 だから、 私たちが正しい領域にいるとしても、 オープンソースを使うべき理由はまだたくさんある。 02:54.210 --> 02:59.910 この特定のビジネス問題に特化した独自のモデルにするという話をする前から、 02:59.910 --> 03:00.600 だ。 03:00.600 --> 03:05.910 とにかく、 それを念頭に置いて、 どのモデルを使うべきかを話す時が来た。 03:06.060 --> 03:09.420 ええと、 まず最初に、 いくつのパラメーターを使うかを決める必要がある。 03:09.420 --> 03:13.830 それに、 多ければ多いほどいいというものでもないだろう。 03:13.860 --> 03:19.140 パラメーターを増やせば、 問題を解決する可能性が高まる。 03:19.140 --> 03:26.670 特に今のような世界では、 多くのトレーニングデータがあり、 40万もの例がある。 03:26.670 --> 03:28.980 だから大量のトレーニングデータがある。 03:28.980 --> 03:31.020 その点で私たちが制限されているわけではない。 03:31.020 --> 03:33.180 そして、 やろうと思えばいつでももっと生み出せる。 03:33.210 --> 03:39.270 というわけで、 私たちの制約となるのは、 メモリの容量ということになる。 03:39.300 --> 03:42.270 もっと小さな箱に収めたい。 03:42.300 --> 03:49.740 この時点で、 私たちは80億のパラメーターを持つモデルを作ることができることをすでに知っている。 03:49.770 --> 03:51.150 パラメータは70億から80億。 03:51.150 --> 03:53.430 それ以上は無理だろう。 03:53.460 --> 04:02.400 パラメータが小さいモデルがある一方で、 ジェンマのようにパラメータが20億か30億のモデルもある。 04:02.400 --> 04:04.080 ええと、 すぐに見てみましょう。 04:04.230 --> 04:16.510 ええと、 おそらく、 余裕がある箱に収まる、 可能な限り大きなモデルとして8つを選びたいんだ。 04:16.660 --> 04:22.930 だから、 ベースやインストラクターのバリエーションに関しては、 そういうアプローチになるだろう。 04:22.930 --> 04:26.710 長所も短所もあるし、 試してみる価値はある。 04:26.740 --> 04:35.500 一般的に言えば、 特定のプロンプトを使用し、 特定の方法での応答を期待するような、 04:35.500 --> 04:41.230 ある問題に特化した微調整を行うのであれば、 インストラクターのバリアントではなく、 04:41.230 --> 04:53.200 ベースモデルから始めた方がよいでしょう。 04:53.230 --> 05:00.490 だから、 ベースとなる1つを微調整して、 その1つのタスクだけが本当に得意になるようにしたほうがいい。 05:00.490 --> 05:02.680 それがデフォルトの答えだ。 05:02.710 --> 05:06.850 さて、 インストラクターのバリエーションから始めることにはいくつかの利点がある。 05:06.850 --> 05:08.890 そのひとつは、 とてもおいしいということだ。 05:08.950 --> 05:15.220 システムプロンプトやユーザーアシスタントのインタラクションなどを認識するようにすでに訓練されている。 05:15.220 --> 05:20.710 システム・プロンプトを使うことで、 ペルソナを学習させるのではなく、 05:20.710 --> 05:31.210 ペルソナを学習させ、 トレーニング・データを通してペルソナを学習させることができる。 05:31.210 --> 05:37.300 だから、 インストラクターのバリエーションがより良い出発点になる状況もある。 05:37.450 --> 05:51.610 僕らの場合、 直感的にはベースの方がスタート地点としてはいいんじゃないかと思うんだ。 05:51.880 --> 05:58.120 実際に両方試してみたが、 ベースはインストラクターのバリエーションより若干良かったが、 非常に僅差だった。 05:58.180 --> 06:02.770 ええと、 両方試してみて、 私と同じ結果が出るかどうか見てみるのもいい。 06:02.770 --> 06:09.070 でも、 僕らのような状況では、 ある特定のタスクがあり、 システムプロンプトなどを適用する必要がない場合、 06:09.070 --> 06:16.090 ベースのバリアントから始めるのが普通だと思う。 06:16.600 --> 06:24.670 しかし、 その紹介をした上で、 ハグする顔、 あー、 オープンリーダーボードに向かい、 いくつかのモデルを見てみよう。