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.
 
 

337 lines
13 KiB

WEBVTT
00:00.770 --> 00:03.530
今、 あなたは疲れきっているはずだ。
00:03.560 --> 00:05.330
もしそうなら、 それでもいい。
00:05.360 --> 00:07.430
あなたは驚異的な仕事をした。
00:07.430 --> 00:15.290
今週は、 リーダーボードやアリーナの導入から、 コードトランスレータの実装、 フロンティアモデルやオープンソースモデルの導入に至るまで、
00:15.290 --> 00:25.070
大量の新情報に直面し、 大変な1週間だった。
00:25.070 --> 00:29.450
私たちは多くのことを経験してきたし、 かなりの道のりだった。
00:29.480 --> 00:37.490
あなたはたくさんの新しいスキルを身につけた。 だから、 私はあなたを祝福するためにここにいる。 そして、
00:37.490 --> 00:44.240
来週に備えるために、 今日の最後のセッションはかなり早く終わることを伝える。
00:44.270 --> 00:49.190
だから、 まず最初に言っておきたいのは、 もちろん、 フロンティアにとっては1点だったということだ。
00:49.190 --> 00:53.600
今回はクロードにショーを勝たせなければならない。
00:53.690 --> 01:01.130
コードを書いたり、 PythonとCの間でコードを変換したりするソフトウェアを書くのは、 とても楽しかった。
01:01.130 --> 01:01.640
それに
01:01.640 --> 01:05.490
そして、 クロードがねぐらを支配するのを見た。
01:05.490 --> 01:10.260
これらのアルゴリズムを再実装した素晴らしい仕事だ。
01:10.500 --> 01:17.700
ええと、 今日の最後には、 オープンソースとクローズドソースのモデルのパフォーマンスについてもう少し議論したいと思います。
01:17.790 --> 01:21.510
それから、 コード生成の商業的な使用例について話すつもりだ。
01:21.510 --> 01:23.940
そしてもちろん、 あなたへの課題もある。
01:23.940 --> 01:25.560
君にとっては大きな任務だ。
01:25.560 --> 01:34.350
だから、 このセッションは比較的短いが、 あなたにとっての仕事は比較的大きい。
01:34.770 --> 01:49.170
しかし、 その前に、 重大な問題についてお話ししたいと思います。 それは、 AIソリューションが実際に良い仕事をしているかどうかをどのように判断するかという問題です。
01:49.260 --> 01:53.400
ええと、 評価のテクニックとは何ですか?
01:53.460 --> 02:01.530
ここで言うように、 おそらく最も重要な質問なんだ。
02:01.560 --> 02:06.070
それは前もって考えなければならないことであり、 それを確立して取り組む必要がある。
02:06.610 --> 02:13.720
しかし、 実際には2つの異なる種類のパフォーマンス指標があり、 その違いを理解し、
02:13.720 --> 02:17.770
正しい文脈で両者を使い分けることが重要だ。
02:17.800 --> 02:23.560
最初の種類は、 モデル中心または技術的なメトリクスとして知られているものです。
02:23.560 --> 02:29.620
データ・サイエンティストにとって、 このような指標は生きているようなものだ。 なぜなら、
02:29.620 --> 02:37.690
このような指標はモデルを最適化することができ、 モデルのパフォーマンスを非常に即座に測定することができるからだ。
02:37.720 --> 02:43.300
これから、 これらのメトリクスのいくつかについて話すつもりだが、 すべてではない。 なぜなら、 これらの中には従来の機械学習に関連したものもあるからだ。
02:43.300 --> 02:46.030
それに、 すでに経験があるかもしれないし、 なくても問題ない。
02:46.030 --> 02:53.170
しかし、 最初の「損失」は、 LLMがそのタスクでどれだけうまくいかなかったかを表す一般的な用語で、
02:53.170 --> 02:56.530
通常、 最適化の際に使われる。
02:56.530 --> 03:01.480
つまり、 それが最適化の仕事なのだ。
03:01.480 --> 03:03.100
モデルをトレーニングするとき。
03:03.340 --> 03:10.910
この分野で最も頻繁に使用される損失はクロスエントロピー損失と呼ばれるもので、 このように機能する。
03:10.940 --> 03:17.480
トークンの入力セット、 つまり入力テキストであるトークンのシーケンスがあるとしよう。
03:17.480 --> 03:19.730
そして、 次のトークンを予測しようとしている。
03:19.730 --> 03:23.570
そして、 次のトークンが実際に何であるかをトレーニング・データで知ることができる。
03:23.780 --> 03:28.820
しかし、 トレーニングの一環として、 このシーケンスをある程度モデルに送り込み、 例えば次のトークンを予測し、
03:28.850 --> 03:32.750
そして実際の次のトークンを持ってくる。
03:32.750 --> 03:37.220
そして、 この2つの結果に関する何かを使って損失を計算したい。
03:37.250 --> 03:38.780
その方法のひとつを紹介しよう。
03:38.810 --> 03:44.810
このモデルが実際に行っているのは、 私がこれまで言ってきたような方法で次のトークンを予測するだけではない。
03:44.810 --> 03:52.370
これは、 リストの中で次に来る可能性のあるすべてのトークンの確率分布を与えるものである。
03:52.370 --> 03:55.880
そして例えば、 最も確率の高いものを選ぶかもしれない。
03:55.910 --> 04:03.770
クロスエントロピーの損失を計算する方法は、 次のトークンが本当は何だったのかがわかったとする。
04:03.800 --> 04:08.850
そのトークンにモデルがどのような確率を割り当てたかを調べてみよう。
04:08.850 --> 04:15.570
実際に次に来るのが、 ハローから始まって、 次に来るのがその単語のトークンだったとする。
04:15.600 --> 04:20.130
そこで、 モデルがその単語にどのような確率を与えたかを調べてみよう。
04:20.130 --> 04:25.560
そして、 この確率こそが、 我々がクロスエントロピーの損失の根拠とするものである。
04:25.560 --> 04:27.360
そして実際、 それを損失に変えてしまった。
04:27.360 --> 04:31.260
なぜなら、 数字が大きい方が良いという確率だけを取れば良いからだ。
04:31.260 --> 04:35.190
そして、 損失は悪いことであり、 私たちはより高い数字を望んでいる。
04:35.190 --> 04:39.810
そこで私たちが行うのは、 実際に負の対数を取ることだ。
04:39.840 --> 04:42.600
確率の対数をマイナスする。
04:42.630 --> 04:44.100
少し混乱するかもしれない。
04:44.130 --> 04:44.790
なぜそんなことをするのか?
04:44.790 --> 04:57.390
というのも、 もし確率が1だとしたら、 それは完璧な答えであり、 次のトークンがまさに次のトークンである可能性が100%あると言ったことになるからだ。
04:57.390 --> 05:00.450
つまり、 確率が1であれば完璧な答えとなる。
05:00.450 --> 05:04.320
まあ、 1のマイナス対数はゼロゼロロスだ。
05:04.320 --> 05:05.340
完璧な答えだ。
05:05.340 --> 05:06.360
それでいいんだ。
05:06.390 --> 05:12.540
そして、 確率が非常に小さな数であれば、 それが小さくなるにつれて、 ゼロに近づいていくにつれて、
05:12.540 --> 05:18.000
その数の負の対数はどんどん大きな正の数になっていく。
05:18.000 --> 05:19.410
それでまたうまくいく。
05:19.410 --> 05:21.420
それは損失となる。
05:21.450 --> 05:24.120
これ以上の損失は悪いニュースだ。
05:24.210 --> 05:31.590
そのため、 確率の負の対数、 つまり予測された確率が実際に次のトークンであることが判明した確率を取る。
05:31.590 --> 05:39.720
これはクロスエントロピー損失と呼ばれ、 使用される基本的な指標の一つである。
05:39.750 --> 05:44.700
そして、 トレーニング用LMSの場合、 ある時点で自分たちも使うことになるのが一般的だ。
05:45.330 --> 05:50.790
もう一つ、 よく耳にする指標で、 非常に関連性の高いものですが、
05:50.820 --> 05:54.180
これは「難解度」と呼ばれるものです。
05:54.210 --> 06:05.280
それが判明したときの意味は、 当惑が1であれば、 そのモデルは完全に自信に満ちた正しい結果であるということである。
06:05.280 --> 06:08.490
100%確実で100%正確だ。
06:08.490 --> 06:10.470
そうなると、 戸惑いが1つ生まれる。
06:10.500 --> 06:13.560
2人の当惑は50を超える50のようなものだろう。
06:13.590 --> 06:15.540
半分は正しい。
06:15.690 --> 06:21.120
4点の当惑は25%の確率だ。
06:21.120 --> 06:22.800
だから、 それが感覚になる。
06:22.800 --> 06:31.350
困惑度が高ければ高いほど、 次のトークンを予測するためには、 すべての条件が同じなら、
06:31.350 --> 06:35.820
いくつのトークンが必要なのかがわかる。
06:36.030 --> 06:39.330
だから、 喪失感と当惑が生まれる。
06:39.330 --> 06:45.870
その他については割愛するが、 これらはモデルの精度や不正確さを測定する即席の方法であり、
06:45.870 --> 06:52.170
最適化の際やモデルの分析に使えるということがお分かりいただけるだろう。
06:52.350 --> 06:55.110
これがモデル中心の評価基準だ。
06:55.110 --> 06:56.880
では、 もうひとつの指標とは?
06:56.910 --> 07:00.750
もう1つの指標は、 ビジネス中心の指標や成果指標である。
07:00.750 --> 07:05.220
そして、 これらはあなたのビジネスの聴衆に最も響くものである。
07:05.220 --> 07:08.610
そして最終的には、 この問題を解決することが求められているのだ。
07:08.690 --> 07:14.990
つまり、 ビジネス・パーソンが求めた実際の成果に結びついたKPIなのだ。
07:15.020 --> 07:17.390
投資対効果かもしれない。
07:17.480 --> 07:23.030
もし、 これが何かを最適化するためのものであるならば、 それは時間における改善なのかもしれない。
07:23.390 --> 07:28.850
今やったことを考えれば、 究極の指標はコードだろう。
07:28.850 --> 07:30.740
先ほど構築したコード・ソリューションの場合。
07:30.740 --> 07:34.610
C++のコードはPythonのコードよりどれくらい速いですか?
07:34.730 --> 07:38.030
同じ答えなら何倍速い?
07:38.210 --> 07:48.620
つまり、 これはビジネス中心、 あるいは成果指標の一例であり、 製品をフル稼働させ、 最後に何が出てくるかを確認する必要があるからだ。
07:49.280 --> 07:53.780
ええと、 別の例としては、 ベンチマークとの比較があるかもしれない。
07:53.780 --> 08:02.630
もし何かをするのであれば、 ある種のソリューションを構築し、 それがあるビジネス・タスクを遂行する上で他のベンチマークを凌駕することになる。
08:02.660 --> 08:10.700
つまり、 この種の測定基準の大きな利点は、 目に見え、 具体的であり、 ビジネス目標につながるということだ。
08:10.700 --> 08:15.740
これらの指標で針を動かすことができれば、 インパクトを提供したことになり、 それを証明することができる。
08:15.770 --> 08:21.830
もちろん、 これらの問題点は、 モデルのパフォーマンスとそれほど明確に結びついていないことだ。
08:21.830 --> 08:25.730
それは、 あなたが持っているデータの種類、 環境、 その使われ方、 ビジネス上の問題を解決するためにオリジナルのアイデアが本当に機能するかどうかなど、
08:25.730 --> 08:30.260
他のあらゆることに関連している。
08:30.260 --> 08:36.260
つまり、 モデルのパフォーマンスとビジネス指標の間には、 未知の部分がたくさんあるのだ。
08:36.260 --> 08:41.870
しかし、 ビジネス・メトリクスには、 現実の世界で実際に意味を持つという大きな利点がある。
08:41.870 --> 08:46.130
つまり答えは、 この2種類の指標を使う必要があるということだ。
08:46.130 --> 08:47.780
協調して使う必要がある。
08:47.780 --> 08:54.620
1つは、 モデルを最適化し、 その高速性能を実証するためにモデルを微調整することができます。
08:54.620 --> 09:01.520
そしてもうひとつは、 最終的にソリューションの背景にあるビジネスインパクトを証明するために使うものだ。
09:01.520 --> 09:04.490
これをもって、 次のセッションは一時中断する。
09:04.490 --> 09:11.600
もう1度戻って、 コーディング・ソリューションを見て、 次のレベルに進むために何ができるかをお話しします。