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度戻って、 コーディング・ソリューションを見て、 次のレベルに進むために何ができるかをお話しします。