WEBVTT 00:00.890 --> 00:07.700 もう一度、 この素晴らしい図をご覧いただきたい。 00:07.700 --> 00:10.970 さて、 私が言及したかった技術的なことだ。 00:10.970 --> 00:19.970 だから、 過去にモデルが次のトークンを予測すると言ったとき、 私は少しルーズだった。 00:20.000 --> 00:21.200 単純に考えればいい。 00:21.200 --> 00:25.730 私たちはよくそのような言い回しを使っているが、 実際に起こっていることはそうではない。 00:25.730 --> 00:30.800 トランスフォーマー・アーキテクチャーがあり、 一番下のレイヤーから出てくるのは、 予測された次のトークンである単一のトークンである、 00:30.800 --> 00:33.560 というようなものではない。 00:33.800 --> 00:35.390 そういうわけにはいかない。 00:35.390 --> 00:40.310 最後の層で実際に出てくるのは確率である。 00:40.310 --> 00:44.390 すべてのトークンを持っている。 00:44.390 --> 00:48.080 そのトークンが次のトークンである確率は? 00:48.080 --> 00:52.130 その一連の確率を出力する。 00:52.160 --> 00:54.920 これがニューラルネットワークの底から出てくるものだ。 00:55.100 --> 01:00.410 そして、 プリントするときに見た最後のレイヤーを覚えているかもしれない。 01:00.410 --> 01:02.640 このモデルはLMヘッドと呼ばれる。 01:02.700 --> 01:06.420 そして、 それが本当に最後のステップとなる。 01:06.420 --> 01:12.810 実際にロジットと呼ばれる確率を表す数値のベクトルが出てくる。 01:12.840 --> 01:14.970 そして、 それを関数に通す必要がある。 01:15.090 --> 01:19.260 ええと、 これはもう詳しすぎるだろうけど、 もう知っているかもしれないね。 01:19.260 --> 01:31.650 ソフトマックスと呼ばれる関数があり、 この関数はこれらの数値を確率に変換する。 01:31.680 --> 01:39.540 つまり、 モデルの結果を、 次のトークンの確率として解釈する方法を与えてくれるのだ。 01:39.540 --> 01:43.710 つまり、 これがフォワードパスで出てくるものなのだ。 01:44.130 --> 01:52.080 推論を行うとき、 推論モードでこれを実行すると、 得られるのはこれらの確率だ。 01:52.080 --> 01:52.980 それでどうするんだ。 01:53.010 --> 01:55.530 次のトークンをどう予測するか? 01:55.530 --> 01:58.080 まあ、 たいていの場合はとてもシンプルなアプローチなんだけどね。 01:58.080 --> 02:00.600 次のトークンを取るだけだ。 02:00.600 --> 02:02.820 最も確率の高いトークンを取る。 02:02.850 --> 02:04.450 さまざまな確率が示された。 02:04.480 --> 02:06.130 どれが最大なのか調べてみよう。 02:06.130 --> 02:07.750 それを次の手紙とする。 02:07.780 --> 02:10.840 もう少し洗練されたテクニックもある。 02:10.840 --> 02:16.720 これらの確率を、 サンプルの取り方の重みとして使って、 無作為にサンプリングすることができる。 02:16.780 --> 02:18.550 そうすれば、 もう少しバリエーションが増える。 02:18.700 --> 02:25.900 その他にも、 いくつかの文字を並べてみて、 それが自分の進みたい道かどうかを判断するテクニックもある。 02:25.900 --> 02:33.490 そのため、 推論の際には、 これらの確率に基づいて、 最善の仕事をするために使えるさまざまな戦略がある。 02:33.490 --> 02:39.220 このトークンはそれぞれコストを表し、 02:39.220 --> 02:45.940 数字を表している。 02:45.940 --> 02:50.440 それで少しスマートなことはできるが、 その必要はない。 02:50.440 --> 02:54.130 単純に確率の高いものを選ぶこともできる。 02:54.340 --> 02:57.550 これがモデル出力の説明だ。 02:57.580 --> 02:59.470 これではっきりしたと思う。 02:59.680 --> 03:02.050 それから損失関数。 03:02.050 --> 03:04.330 だから、 前回のビデオで少し触れた。 03:04.360 --> 03:05.840 損失を計算するようにね。 03:05.840 --> 03:07.550 どの程度悪かったのですか? 03:07.550 --> 03:09.950 では、 実際にはどうなのか? 03:09.980 --> 03:11.990 素晴らしくシンプルだ。 03:11.990 --> 03:15.890 つまり、 次に起こりうるすべてのトークンの確率がわかったわけだ。 03:16.010 --> 03:21.200 それで、 次のトークンが何であるべきかがわかった。 03:21.290 --> 03:23.690 仮に99歳だとしよう。 03:23.690 --> 03:30.740 そこで、 これらの確率をすべて調べて、 モデルが99に対してどのような確率を与えたか、 実際に正しい次のトークンであったか、 03:30.740 --> 03:33.350 と言うのだ。 03:33.350 --> 03:34.790 そして、 ここで重要なのはそれだけだ。 03:34.790 --> 03:38.780 重要なのは、 実際に正しかったことにどのような確率を与えたかということだ。 03:39.080 --> 03:45.320 うーん、 もし100%の確率でそうなるのなら、 完璧だったということになる。 03:45.320 --> 03:48.050 正しい結果に100%の自信を持っていた。 03:48.050 --> 03:51.320 確率は足し算で1になるのだから、 それ以外はすべてゼロでなければならない。 03:51.320 --> 03:53.900 だから、 それは絶対に完璧だ。 03:53.900 --> 03:58.190 もし100%以下なら、 うまくいかなかったということだ。 03:58.400 --> 04:01.850 確率が低ければ低いほど、 成績は悪くなる。 04:02.000 --> 04:11.910 そして、 その確率を求め、 その数値の対数をとり、 それを否定する式がうまく機能することがわかった。 04:11.910 --> 04:15.390 つまり、 その数字の対数のマイナス1倍を取るわけだ。 04:15.390 --> 04:21.360 それを計算すると、 その数字が1であれば、 100%の確率であれば、 0になるということだ。 04:21.360 --> 04:24.150 それはいいことだと思う。 04:24.180 --> 04:26.700 完璧であれば、 損失は何もないはずだ。 04:27.090 --> 04:32.340 そして、 確率が低ければ低いほど、 その損失額は大きくなる。 04:32.340 --> 04:42.840 つまり、 確率の負の対数を取ることは、 うまく振る舞う損失関数を持つ方法なのだ。 04:43.230 --> 04:44.670 それに洒落た名前がある。 04:44.670 --> 04:48.030 この損失関数はクロスエントロピー損失として知られている。 04:48.060 --> 04:49.200 そう呼ばれている。 04:49.200 --> 04:54.330 真の次のトークンの確率の負の対数だ。 04:54.660 --> 04:57.120 そして、 それが使われているんだ。 04:57.120 --> 05:04.860 トレーニングが進行している場合、 各予測のクロスエントロピー損失を計算します。 05:05.190 --> 05:07.890 そして、 もうひとつ余談がある。 05:07.920 --> 05:11.790 特にデータサイエンティストにとっては、 これは何かを異なるビンに分類しようとするときに、 05:11.790 --> 05:17.700 分類に使われる計算だという解釈がある。 05:17.700 --> 05:22.860 昔、 画像を4つか5つのカテゴリーに分類しようとしたとき、 クロスエントロピー損失があれば、 05:22.860 --> 05:33.210 確率を計算し、 分類がうまくいったかどうかを判断するためにクロスエントロピー損失を使います。 05:33.630 --> 05:41.580 次のトークンを予測するプロセス全体が分類問題なのだから。 05:41.580 --> 05:48.000 次のトークンには、 いろいろなカテゴリーが考えられると言いたいのだろう。 05:48.030 --> 05:50.880 実際、 次の可能性のあるトークンはすべてある。 05:50.880 --> 05:57.660 そして、 次のトークンを入れるのに最も可能性の高いバケツはどれかを予想する。 05:57.660 --> 06:03.690 つまり、 生成AIの全プロセスは、 実際には単なる分類問題なのだ。 06:03.690 --> 06:10.200 次のトークンを分類し、 次のトークンがそうである確率を計算する。 06:10.690 --> 06:20.320 そして興味深いことに、 モデル価格を予測する私たちの特別なプロジェクトでは、 少し前にも言ったように、 これは本当に回帰の問題なのです。 06:20.320 --> 06:25.390 数字を予測しようとしているのに、 06:25.390 --> 06:36.670 それを分類問題のように扱っている。 06:36.670 --> 06:42.790 私たちは、 すべての製品をこの999のバケツのひとつに分類しようとしているだけです。 06:42.790 --> 06:45.850 だからこそ、 分類問題としては非常にうまく機能するのだ。 06:45.850 --> 06:55.120 フロンティア・モデルが得意とする理由であり、 オープンソース・モデルが得意とすることを期待している理由でもある。 06:55.390 --> 07:01.030 そして、 これらすべてが、 私たちの背後にある有益な理論である。 07:01.030 --> 07:04.060 でも、 今は練習に戻る時だ。 07:04.060 --> 07:12.730 そういうわけで、 そろそろオープンソースの、 ええと、 ファインチューニングはどうなっているのかについて話をしようじゃないか。