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