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.
 
 

283 lines
9.6 KiB

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
そういうわけで、 そろそろオープンソースの、 ええと、 ファインチューニングはどうなっているのかについて話をしようじゃないか。