WEBVTT 00:00.740 --> 00:08.690 さて、 何が起こったかを事後報告する前に、 ここにある順位表の立ち位置を簡単に見ておこう。 00:08.690 --> 00:18.110 だから、 平均値に基づいて一定の走りをしたとき、 平均予測差146という誤差が出たことを覚えているだろう。 00:18.620 --> 00:22.280 従来の機械学習では139点だった。 00:22.280 --> 00:24.800 ランダムフォレストは97だった。 00:24.830 --> 00:33.860 その人間、 特にある人間、 名前は伏せるが、 GPT4かミニを初めて走らせたときは127、 00:33.860 --> 00:37.400 残念ながら80ドルだった。 00:37.430 --> 00:43.310 GPT4は76で、 今戻ってきたのは91だった。 00:43.310 --> 00:50.300 というのも、 実際に前評判より改善された点もあったのだが、 理由はともあれ、 まあ、 00:50.300 --> 00:52.580 そういうことなのだ。 00:52.580 --> 00:54.350 結果はごまかせない。 00:54.350 --> 01:01.130 残念なことに、 我々が最も注目しているビジネス指標は、 01:01.160 --> 01:05.670 微調整がやや甘かった。 01:05.670 --> 01:07.350 それについて話そう。 01:08.280 --> 01:13.830 それは私たちにとって明らかに気が引き締まる瞬間であり、 旅の重要な学びだった。 01:14.130 --> 01:17.610 ちょっと時間がかかるんだ。 01:17.640 --> 01:24.600 フロンティアモデルによる微調整の目的は何なのか? 01:24.660 --> 01:39.390 ファインチューニングはよく使われるもので、 パラメータが少ないオープンソースのモデルを、 データセットで訓練してフロンティアモデルに匹敵するようにするために使います。 01:39.420 --> 01:44.760 しかし、 すでに何兆ものパラメータを持ち、 膨大なデータセットで訓練されたフロンティアモデルがある場合、 01:44.760 --> 01:48.450 その目的は何でしょうか? 01:48.510 --> 01:53.460 フロンティアモデルを微調整する主な目的は5つある。 01:53.460 --> 01:57.390 これらは基本的にOpenAIのウェブサイトから引用した。 01:57.420 --> 02:05.460 これらは、 GPTのようなものを微調整する訓練を多くの人が受けたいと思う理由についてのOpenAIの理由である。 02:05.730 --> 02:16.860 返答のスタイルやトーンに工夫を凝らしたいのであれば、 返答に皮肉を加える例を挙げています。 02:16.860 --> 02:23.790 もしあなたが、 特定のタイプのフォーマット(構成)を確実に上達させたいのであれば、 そのフォーマットは特定のスタイルや方法、 02:23.790 --> 02:27.120 構造である必要がある。 02:27.540 --> 02:34.950 うーん、 3つ目は、 モデルが難しい、 あるいは挑戦的なプロンプトに従えない場合の修正です。 02:34.950 --> 02:40.410 非常に複雑なことを要求されているのに、 ジョークが通じず、 見逃している。 02:40.800 --> 02:47.130 エッジケースの処理というのは、 モデルの中に時折露呈する欠陥のようなものがあって、 それを修正する必要がある場合に、 02:47.130 --> 02:52.020 何か新しいことを実行することだ。 02:52.020 --> 02:57.930 そして、 これこそが私たちがやろうとしていたことであり、 新しい課題なのだが、 プロンプトで明確に表現するのは難しい。 02:57.930 --> 03:05.110 OpenAIがサイトで強調しているのは、 優れたプロンプトで解決できないことを解決しようということです。 03:05.110 --> 03:12.340 GPT 4やminiのようなものでは、 多くの場合、 プロンプトだけで非常に高いレベルのパフォーマンスを得ることができるので、 03:12.340 --> 03:23.560 できる限りプロンプトに取り組むことから始めるよう、 本当に促しています。 03:23.920 --> 03:28.960 フロンティア・モデルにとって、 それが重要なんだ。 03:29.170 --> 03:37.120 ええと、 私たちはプロンプトの中で、 手元の質問と出力のスタイルを非常に明確に指定することができます。 03:37.120 --> 03:45.280 そして実際、 事前の結果を思い起こせば、 GPT4ミニは適切な構成という点で的確な反応を示していた。 03:45.280 --> 03:49.990 どのケースでも、 数字を引き出せないことはなかった。 03:49.990 --> 03:54.850 そして、 その数字は常に、 誤差の範囲内だった。 03:54.850 --> 04:01.330 推測だから、 課題や出力形式を理解することに問題はなかったんだ。 04:01.330 --> 04:21.270 GPT4とGPT4ミニは、 世界的な知識を持つトレーニングデータのサイズが非常に大きいことを忘れてはならない。 04:21.960 --> 04:29.460 そして、 少し前に話した、 壊滅的な忘却、 忘却と呼ばれる、 より細かい調整を加えることで、 04:29.460 --> 04:35.940 事前のトレーニングで得たより深い知識が損なわれてしまうことがある、 04:35.940 --> 04:41.730 ということがある。 04:41.730 --> 04:45.060 だから、 微調整をすることが必ずしもいいこととは限らない。 04:45.300 --> 04:50.910 このわずかな落ち込みの原因が、 壊滅的な忘れ物なのか、 それとも単に運が悪かっただけなのか、 04:50.910 --> 04:58.500 システム内にノイズがあり、 たまたまテストセットでうまくいかなかっただけなのかはわからない。 04:58.800 --> 05:01.860 うーん、 でも、 状況が改善したようには見えなかった。 05:01.860 --> 05:02.970 これが結論だ。 05:02.970 --> 05:15.030 そして、 私の見解では、 そして私の理解や実験が示すところでは、 私たちはすでに必要なことを明確に促すという素晴らしい仕事をしていたからだ。 05:15.030 --> 05:22.590 GPT4は、 多くの場合、 すでにそのことをよく理解していたし、 結果の質もすでに非常に良かった。 05:23.580 --> 05:29.610 とはいえ、 あなたにとっての挑戦は、 これに取り組み続けることだ。 05:29.610 --> 05:35.940 ハイパーパラメーターを最適化したり、 試行錯誤したりして、 少しは改善できるようになった。 05:36.120 --> 05:37.350 うーん、 でもそれほどでもない。 05:37.350 --> 05:43.320 そして、 この微調整が、 少なくとも以前より少しはマシになる、 少しはマシになるというところまで到達できないのであれば、 05:43.320 --> 05:46.650 私はショックを受けるだろう。 05:46.650 --> 05:48.270 それがあなたへの挑戦です。 05:48.300 --> 05:54.540 つまり、 OpenAIは大規模なデータセットの投入を推奨しているわけではないのですが、 05:54.540 --> 06:02.130 特に無料で投入できる間は、 より大規模なデータセットを試してみたいと思っています。 06:02.130 --> 06:04.650 1000または2000のトレーニングデータセットを試す。 06:04.680 --> 06:06.930 もう少しエポック数を増やしてみようか。 06:06.930 --> 06:10.710 でも、 何か違うことを試してみてほしい。 06:10.710 --> 06:13.560 他にもハイパーパラメーターを調べることができる。 06:13.590 --> 06:15.300 OpenAIのウェブサイトで調べることができる。 06:15.300 --> 06:18.660 あなたが望むなら、 変えてみることができるカップルがある。 06:18.660 --> 06:21.900 それを同じハイパーパラメーターの辞書に渡すだけだ。 06:22.260 --> 06:29.490 それから、 別のトレーニングデータを入れてみたり、 プロンプトで遊んでみたりすることもできる。 06:29.520 --> 06:38.190 つまり、 OpenAIのウェブサイトで最も強調されているのは、 プロンプトを改善することで最大の効果が得られるということだ。 06:38.310 --> 06:43.890 これは明らかに、 私たちがデータのキュレーションとプロンプトの完成に少し時間を費やしたものですが、 06:43.890 --> 06:46.440 もっともっとできることがあるはずです。 06:46.440 --> 06:48.780 だから、 それも試してみてほしい。 06:48.780 --> 06:56.820 あなたの課題は、 ハイパーパラメーターを最適化し、 プロンプトを弄って、 少なくとももっとうまくやることだ。 06:56.820 --> 06:58.200 自分たちがいた場所を振り返ってみよう。 06:58.230 --> 07:01.470 あなたの挑戦は76より良い結果を出すことだ。 07:01.590 --> 07:09.310 ええと、 76よりいいタイムを出したこともあるんだ。 07:09.460 --> 07:16.360 だから、 あまり多くの変更を加えなくても、 76年よりもいい結果を出すことは可能だとわかっている。 07:16.390 --> 07:18.520 大幅に良くなったわけではないが、 良くなった。 07:18.730 --> 07:21.010 そして、 それがあなたにとっての挑戦でもある。 07:21.040 --> 07:24.790 ぜひそうしてください。 07:24.790 --> 07:30.610 そして、 もし最適化されたプロンプトやハイパーパラメータが得られたら、 07:30.610 --> 07:36.040 コードをプッシュしてPRしてください。 07:36.370 --> 07:43.480 そして、 76歳以上の成績を収めたとき、 それがあなたの挑戦の達成となる。 07:45.040 --> 07:46.240 分かった。 07:46.240 --> 07:49.870 これで第6週の結論が出た。 07:49.870 --> 07:58.690 AIとLMエンジニアリングをマスターした熟練LMエンジニアになるまでの道のりの4分の3、 07:58.690 --> 08:01.900 75%に達している。 08:02.110 --> 08:04.570 僕と同じように、 君たちも楽しみにしていてほしい。 08:04.600 --> 08:10.130 あなたが学んだことすべてを誇りに思うべき、 素晴らしい進歩だ。 08:10.190 --> 08:15.920 明らかに、 フロンティアモデルのアシストでテキストとコードを生成し、 抱擁顔トランスフォーマー、 08:15.920 --> 08:20.570 ライブラリ、 あー、 ラングチェーンラグでオープンソースモデルを使用している。 08:20.720 --> 08:26.960 そして最近では、 データをキュレーションする問題解決のための5つのステップ戦略だ。 08:26.960 --> 08:28.250 私たちはデータのキュレーションをたくさん行った。 08:28.250 --> 08:32.420 でもね、 LMエンジニアの生活には多くのデータキュレーションが含まれるんだ。 08:32.420 --> 08:37.490 それはコツであり、 最も重要な部分のひとつだ。 08:37.490 --> 08:44.810 確かに、 私が行ったすべての実験において、 データ構造を変えることが何よりも針を動かした。 08:44.900 --> 08:48.950 すでに多くの実験が行われている。 08:49.040 --> 08:51.560 うーん、 でも君なら......もっとうまくやれると思うよ。 08:52.070 --> 08:55.100 ええと、 あなたは従来の機械学習で遊んだことがありますね。 08:55.160 --> 08:59.660 ええと、 ただ、 僕らが楽に勝ってきたという基準値を知るためにね。 08:59.810 --> 09:04.460 あなたはフロンティアモデルの解を作り、 今はフロンティアモデルを微調整している。 09:04.460 --> 09:06.660 だから結果は少し残念だった。 09:06.690 --> 09:07.710 本当だよ。 09:07.890 --> 09:11.520 しかし、 それにもかかわらず、 これはあなた自身のプロジェクトで使えるものだ。 09:11.520 --> 09:17.760 また、 スタイルを変えたいとか、 難しいエッジケースが問題を引き起こしているといった状況であれば、 09:17.760 --> 09:20.730 微調整が答えとなる。 09:20.730 --> 09:22.560 そして今、 少なくともあなたは良いレシピを持っている。 09:22.590 --> 09:25.980 やり方は知っているし、 走りを見たこともあるだろう。 09:25.980 --> 09:28.980 あなたはそのステータスをチェックし、 ウェイトやバイアスを観察してきた。 09:28.980 --> 09:31.290 関係することはすべて知っているはずだ。 09:32.490 --> 09:44.160 さて、 来週からまた新たな一歩を踏み出し、 オープンソースモデルに目を向ける。 09:44.160 --> 09:52.290 オープンソースのモデルを微調整することは、 フロンティアモデルを微調整すること、 オープンソースのモデルを微調整することとはまったく異なる提案である。 09:52.290 --> 09:59.970 私たちがやろうとしているのは、 私たちが扱っている大型モデルよりもはるかに小さいものから始めることだ。 09:59.970 --> 10:02.040 つまり、 まだ何十億ものパラメーターがある。 10:02.040 --> 10:13.290 しかし、 GPT4やGPT4ミニの何兆ものパラメータとは比較にならない。 10:13.320 --> 10:20.460 オープンソースのモデルを微調整し、 Loraと呼ばれるものを使用する予定です。 Loraについては何度か触れたので聞いたことがあるかもしれませんが、 10:20.460 --> 10:32.820 おそらくLoraの例をいくつか見たことがあるかもしれませんし、 Loraの同類でLoraの量子化バージョンであるLoraについても聞いたことがあるかもしれません。 10:32.850 --> 10:37.770 私たちはこの2つに取り組み、 最後にはこの2つについて一から十まで知ることになる。 10:37.980 --> 10:44.640 ええと、 次のセッションではベースモデルを選びますが、 それが何かはもうお分かりですね。 10:44.640 --> 10:47.310 でも、 でも、 本当に選ぶんだ。 10:47.490 --> 10:53.070 それがGPT4と競争するモデルになるだろう。 10:53.340 --> 10:56.280 リーダーボードの現在の勝者。 10:56.280 --> 10:59.220 それが来週の課題だ。 10:59.250 --> 11:03.480 大きな挑戦になるだろうけど、 挑戦するのが待ちきれないよ。 11:03.480 --> 11:05.940 そして、 あなたも待ちきれないことを願っている。 11:05.940 --> 11:07.140 それではまた。