WEBVTT 00:00.920 --> 00:02.510 みんな知っているよ。 00:02.510 --> 00:08.210 つい先日のことのように思えるが、 私たちは今、 4週目に入り、 00:08.210 --> 00:13.490 急速に中間地点に近づいている。 00:13.490 --> 00:17.090 さて、 今回は何が待ち受けているのだろうか? 00:17.210 --> 00:24.770 ええと、 今週は核となる知識を構築するのに不可欠な時期に入る。 00:24.770 --> 00:31.070 今回は、 私たちすべてに襲いかかるこの非常に挑戦的な問題、 つまり、 私たちは選択の余地を奪われているということについて話すつもりだ。 00:31.070 --> 00:33.140 世の中にはたくさんのLLMがある。 00:33.140 --> 00:36.590 クローズドソースかオープンソースか、 決断しなければならないことはたくさんある。 00:36.590 --> 00:39.590 そして、 それぞれのカテゴリーで、 非常に多くの選手がいる。 00:39.620 --> 00:43.910 目の前の問題に適したLLMを選ぶにはどうすればいいのか。 00:43.910 --> 00:46.610 それが今週のメインテーマだ。 00:46.700 --> 00:53.900 さらに、 私たちはオープンソースの土地で私たちのためにコードを書いてくれるllmsを構築するコードを生成することになるだろう。 00:53.930 --> 00:55.400 それは楽しみだね。 00:55.910 --> 01:01.970 ええと、 今日私たちがやろうとしているのは、 タスクに適したモデルを選ぶにはどうすればいいかというテーマについて、 01:01.980 --> 01:03.450 さっそく考えてみることだ。 01:03.450 --> 01:08.370 オープンソースのモデルを比較するのに役立つ、 Hugging 01:08.370 --> 01:16.950 Faceの素晴らしいリソースであるOpenml leaderboardというものを使うつもりだ。 01:17.550 --> 01:21.690 その前に、 もちろん、 8週間を振り返ってみよう。 01:21.690 --> 01:23.340 左からやり直した。 01:23.340 --> 01:25.320 私たちは右で終えるつもりだ。 01:25.320 --> 01:26.490 週目だ。 01:26.490 --> 01:32.070 私たちはフロンティア・モデルについて語り、 6つのフロンティアLMSを比較しました。 01:32.070 --> 01:40.410 第2週はGradioのエージェント化でUIを紹介し、 第3週はもちろんマルチモダリティで遊んだ。 01:40.440 --> 01:43.980 先週、 私たちはオープンソースにどっぷりはまった。 01:43.980 --> 01:49.110 私たちはハブを調べ、 ハイレベルAPIとパイプラインを調べ、 そしてトークナイザーとモデルを調べました。 01:49.110 --> 01:54.540 そして、 これらのチャット・インターフェースがどのように機能するのか、 01:54.540 --> 02:08.200 そしてこれらの辞書のリストがどのようにトークンになるのかを理解するという点で、 多くのことがまとまったと思います。 02:09.190 --> 02:16.510 第4週は、 LMSの選択と、 非常に興味深いコード生成の問題についてだ。 02:16.540 --> 02:18.700 第5週がラグであることを願う。 02:18.700 --> 02:20.620 第6週は微調整。 02:20.650 --> 02:22.090 トレーニングを始めるときだ。 02:22.120 --> 02:27.970 フロンティアでのトレーニング、 そしてオープンソースでのトレーニング、 そしてそのすべてを統合する。 02:28.090 --> 02:30.520 これが8週間のプランだ。 02:30.910 --> 02:36.820 それで今日は、 モデルの比較、 LMSの比較についてお話しします。 02:36.820 --> 02:48.340 そして、 このセッションから1つ収穫があるとすれば、 最も重要なポイントは、 このLLMが他のLLMより優れているというような単純な答えがあるわけではないということだ。 02:48.370 --> 02:52.360 ベストからワーストへというランキングではない。 02:52.390 --> 02:55.690 何を達成しようとしているのかがすべてだ。 02:55.690 --> 02:59.830 そして、 目の前の課題に適したLLMを選ぶことだ。 02:59.830 --> 03:05.420 ですから、 さまざまなLMSを比較検討し、 03:05.420 --> 03:10.160 要件と比較することが重要です。 03:10.160 --> 03:14.810 その第一は、 モデルに関する基本的な事実だけを見ることだ。 03:14.900 --> 03:18.320 ええと、 モデルの値段のような明らかなものです。 03:18.410 --> 03:23.630 そうすれば、 決断の幅が狭まり、 選択肢が少なくなる。 03:23.630 --> 03:29.270 そして、 基本的な属性や異なるモデルの基本的な側面を調査したら、 03:29.270 --> 03:32.750 次に詳細な結果を調べ始める。 03:32.750 --> 03:37.100 そのためには、 ベンチマーク、 リーダーボード、 アリーナといったものを見る必要がある。 03:37.100 --> 03:50.660 そして、 これらすべてを踏まえて、 最終的にあなたのタスクに最適なLLMを選択するためのプロトタイピングに使用する候補のLLMを手に入れる必要があります。 03:51.500 --> 03:54.770 それで、 基本的なことを少し話そう。 03:55.610 --> 04:03.740 だから、 基本的なことを比較すると言ったのは、 異なるモデルについて評価しなければならない最も明白なことを意味しているんだ。 04:03.740 --> 04:10.070 そして、 オープンソースモデルかクローズドソースモデルかを理解することから始める。 04:10.070 --> 04:15.020 そしてもちろん、 長所と短所があり、 他の基本的な属性の多くに影響する。 04:15.020 --> 04:20.030 そこで、 候補リストを作成する際、 最初にメモしておくべきことは、 オープンソースかクローズドソースかということだ。 04:20.150 --> 04:21.860 発売はいつですか? 04:21.890 --> 04:26.450 発売日はいつですか? 04:26.450 --> 04:30.170 しかし、 注意すべき重要な点は、 知識のカットオフとは何かということだ。 04:30.170 --> 04:31.370 日付は? 04:31.430 --> 04:38.180 学習データの最終更新日。 それ以降は通常、 現在の出来事に関する知識を持たない。 04:38.180 --> 04:41.780 そして、 あなたのユースケースによって、 それはあなたにとって重要かもしれないし、 そうでないかもしれない。 04:42.200 --> 04:44.570 次にパラメータの数。 04:44.600 --> 04:49.190 これでモデルの強さがわかる。 04:49.190 --> 04:55.820 また、 かかるコストの強さもわかるだろうし、 どれだけのトレーニングデータが必要かもわかるだろう。 04:55.820 --> 04:59.630 そのモデルを微調整したいのであれば、 それについても少しお話ししましょう。 04:59.630 --> 05:09.000 パラメーターの数、 モデルのサイズも基本的な事実のひとつで、 トレーニング中に使用されたトークンの数をメモしておく。 05:09.000 --> 05:15.120 トレーニングデータセットのサイズは重要なポイントで、 モデルのパワー、 そのレベル、 05:15.150 --> 05:24.180 専門知識の深さ、 そしてもちろんコンテキストの長さ、 コンテクストウィンドウの大きさを改めて感じさせてくれる。 05:24.210 --> 05:27.750 過去に何度も話したことだ。 05:27.810 --> 05:33.840 次のトークンを予測する間、 効率的にメモリに保持できるトークンの総量は、 オリジナルのシステム、 05:33.870 --> 05:38.280 プロンプト入力プロンプトを含む必要がある。 05:38.280 --> 05:44.820 また、 チャットのユースケースで指示する場合、 ユーザーとアシスタントのやりとりはすべて、 05:44.820 --> 05:47.940 コンテキストの長さに収まる必要がある。 05:47.940 --> 05:53.970 マルチショット・プロンプティングを扱う場合、 推論時に複数の例を提供してモデルに学習させるのであれば、 05:53.970 --> 06:03.090 それらの例をすべて取り込むのに十分なコンテキストの長さを確保する必要がある。 06:03.480 --> 06:06.450 今日の文脈の長さが最も長いモデルを覚えていますか? 06:06.760 --> 06:17.410 ええと、 ジェミニ1号。 5フラッシュに100万サイズのコンタクトウインドウがある。 06:17.680 --> 06:19.780 これが基本中の基本だ。 06:19.780 --> 06:23.440 もっと基本的なことに目を向けてみよう。 06:23.440 --> 06:27.850 だから、 気をつけなければならないコストがたくさんある。 06:27.880 --> 06:32.350 推論コスト、 トレーニングコスト、 ビルドコストに分けてみた。 06:32.350 --> 06:40.420 つまり、 推論コストとは、 入力が与えられたときに出力を生成するために、 本番でこのモデルを実行するたびにどれだけのコストがかかるかということである。 06:40.420 --> 06:43.750 簡単に言えば、 推論とはそういうことだ。 06:43.930 --> 06:51.430 オープンソースかクローズドソースか、 あるいはどのようなやり取りをするかによって、 さまざまな種類のコストが発生する可能性がある。 06:51.460 --> 07:01.840 もちろん、 フロンティアモデルでは、 APIコストについて考えていることは知っている。 07:02.170 --> 07:11.630 Proのユーザーインターフェイス、 チャットUIを使うということであれば、 サブスクリプション、 つまり月額のサブスクリプション費用を考えていることでしょう。 07:11.630 --> 07:16.820 また、 オープンソースのモデルを自分で実行するのであれば、 実行時の計算コストがかかるでしょう。 07:16.820 --> 07:26.960 これは、 共同研究コストのようなものかもしれませんし、 このコースの最終週には、 本番環境へのデプロイ方法についてお話しすることになるでしょう。 07:26.990 --> 07:33.170 モーダルのようなプラットフォームを考えてみると、 07:33.170 --> 07:40.430 GPUボックス上でモデルを本番稼動させることができる。 07:40.430 --> 07:44.180 オープンソースのランタイム・コンピュートもその要因のひとつだ。 07:44.180 --> 07:49.820 通常、 自分でトレーニングしたオープンソースのモデルを使用している場合、 07:49.820 --> 07:52.400 推論コストは低くなる。 07:52.400 --> 07:55.400 毎回API使用料を支払う必要はない。 07:55.400 --> 07:58.100 でも、 明確な計算はできない。 07:58.130 --> 07:59.300 ユースケースによる。 07:59.300 --> 08:03.350 モデルの選択、 パラメーターの数などによる。 08:04.220 --> 08:06.710 そしてトレーニング費用。 08:06.710 --> 08:13.470 だから、 箱から出してフロンティア・モデルを使うのであれば、 トレーニング・コストはかからない。 08:13.470 --> 08:16.770 さらに微調整をするのでなければ、 第7週にすることになる。 08:17.010 --> 08:22.380 しかし、 もしオープンソース・モデルを構築し、 それを自分の専門分野に特化させ、 トレーニング費用やトレーニング付きで提供するのであれば、 08:22.380 --> 08:27.810 それにはコストがかかる。 08:27.810 --> 08:29.820 それを方程式に組み入れる必要がある。 08:30.000 --> 08:31.680 建設費。 08:31.740 --> 08:37.650 では、 この解決策を作るのにどれだけの労力がかかるのか。 08:37.770 --> 08:42.900 そして、 それは次の「市場投入までの時間」に大きく関係している。 08:43.170 --> 08:47.610 フロンティア・モデルを使うことのセールスポイントのひとつだ。 08:47.610 --> 08:50.280 それが市場投入のタイミングなのか? 08:50.280 --> 08:52.590 また、 建設コストも非常に低く抑えることができる。 08:52.590 --> 08:59.640 フロンティア・モデルを使った強力なソリューションの立ち上げには、 ほとんど時間がかからない。 08:59.640 --> 09:04.140 通常、 独自のオープンソースモデルを微調整しようとすれば、 より時間がかかり、 09:04.140 --> 09:05.340 より難しくなる。 09:05.490 --> 09:18.790 つまり、 フロンティア・モデルを使ったレート制限を検討する上で、 電話できる頻度の制限にぶつかる可能性があるということだ。 09:18.790 --> 09:21.820 これは通常、 サブスクリプション・プランの場合である。 09:22.030 --> 09:25.660 それと、 もしかしたら、 料金制限もあるかもしれない。 09:25.660 --> 09:30.610 私は、 APIを通じてフロンティア・モデルを使用する際にも信頼性を指摘している。 09:30.610 --> 09:43.930 GPT4とクロード3の両方で経験したことがある。 09:43.930 --> 09:43.930 5ソネットのAPIは、 09:43.930 --> 09:45.970 その時間帯は生産が忙しすぎるため、 負荷がかかりすぎているというエラーで応答する。 09:45.970 --> 09:54.460 これはレート制限に関連するものだが、 ある種の安定ポイントであり、 スループットの一種であるスピード、 つまり、 どれくらいの速さでレスポンス全体を生成できるか、 09:54.460 --> 10:02.740 どれくらいの速さで新しいトークンを生成できるかということだ。 10:02.740 --> 10:04.780 そしてとてもよく似ている。 10:05.050 --> 10:11.980 スピードとレイテンシー(リクエストの応答時間)には微妙な違いがある。 10:12.040 --> 10:17.620 と尋ねると、 トークンごとにどれくらいのスピードで返答が始まるのですか? 10:17.920 --> 10:25.990 私たちが航空会社のためにAIアシスタントを開発したときのことを覚えていらっしゃるかもしれない。 10:25.990 --> 10:28.090 そこではレイテンシーが少し問題になった。 10:28.120 --> 10:33.040 その時は言わなかったと思うけど、 テキストがある時はもちろん、 それがモデルに送られるから、 10:33.040 --> 10:35.260 気まずい間があったんだ。 10:35.260 --> 10:39.940 フロンティアモデルに呼びかけ、 オーディオを生成し、 戻って来てオーディオを再生する。 10:39.940 --> 10:45.910 そして、 画像を生成しているときはさらに衝撃的で、 画像が戻ってくるまでに時間がかかり、 10:45.910 --> 10:49.510 私たちはそこに座って画像を待っていた。 10:49.540 --> 10:56.200 もちろん、 私たちのプロトタイプでやったよりももっと潔くそれを処理する方法はある。 10:56.350 --> 11:02.590 もしあなたが独自のオープンソースモデルを扱っているのであれば、 それはあなたがよりコントロールしやすいものであることを覚えておいてほしい。 11:02.890 --> 11:08.800 そして、 基本中の基本だが、 間違いなく重要なのがライセンスだ。 11:09.010 --> 11:12.620 オープンソースであろうとクローズドソースであろうと。 11:12.740 --> 11:20.660 使用できる場所、 使用できない場所など、 ライセンスの制限を十分に認識しておく必要がある。 11:20.810 --> 11:25.130 ええと、 オープンソースのモデルの多くは、 非常にオープンなライセンスを持っています。 11:25.160 --> 11:27.380 うーん、 中には細かい字が書いてあるものもある。 11:27.380 --> 11:33.200 安定した拡散というのは、 ある程度までは商業的に使うことが許されている。 11:33.200 --> 11:43.730 収益があるレベルを超えると、 その時点で何らかの、 安定した普及のためのビジネスアレンジメントが必要になる。 11:43.760 --> 11:51.260 そして、 私たちは、 ラマ3との利用規約にサインした。 メタで1。 11:51.290 --> 11:58.490 でも、 ライセンスの一部であることは認識しておく必要がある。 11:58.520 --> 12:01.310 基本的なことは以上だ。 12:01.310 --> 12:11.240 これらはすべて、 目の前のタスクに対するモデルのパフォーマンスや精度をより詳細に分析する前にメモしておくべきことだ。 12:11.240 --> 12:13.880 そして、 次のセッションに続く。