From the uDemy course on LLM engineering.
https://www.udemy.com/course/llm-engineering-master-ai-and-large-language-models
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
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度戻って、 コーディング・ソリューションを見て、 次のレベルに進むために何ができるかをお話しします。
|
|
|