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.
 
 

427 lines
17 KiB

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
そして、 次のセッションに続く。