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.
 
 

292 lines
11 KiB

WEBVTT
00:00.950 --> 00:06.440
というわけで、 今週はこの企画をご紹介できることを大変嬉しく思う。
00:06.440 --> 00:08.810
そして、 その肉付きの良さ。
00:08.840 --> 00:11.930
これがコースのキャップストーン・プロジェクトだ。
00:11.930 --> 00:14.120
私はそれを『プライス・イズ・ライト』と呼んでいる。
00:14.120 --> 00:17.060
私たちがこれまでやってきたことをまとめるものだ。
00:17.090 --> 00:18.890
私たちは建設するということだ。
00:18.890 --> 00:31.970
私たちに課せられた課題は、 インターネット上で公開されている取引を探し、 RSSフィードを購読して、 公開された取引を見つけることができるプラットフォームを構築することです。
00:31.970 --> 00:38.780
潜在的な取引、 有望そうな取引を見つけると、
00:38.780 --> 01:18.170
それを読み、 解釈し、 先週私たちが構築した独自のものを含む多くのLMSを使用して、 それがどれくらいの価値があるかを独自に推定します。
01:18.380 --> 01:26.720
そして、 もし我々がそれを成し遂げることができれば、 そしてそのプラットフォームを構築することができれば、 我々は先進的なプラットフォームという特別なものを構築したことになる。
01:26.720 --> 01:31.190
多くの異なる機能の断片を統合したもので、
01:31.190 --> 01:36.350
願わくば私が誇れるものでありたい。
01:36.770 --> 01:38.780
エージェントは7人になる。
01:38.780 --> 01:40.340
すでに言ったが、 もう一度言う。
01:40.370 --> 01:42.650
7人のエージェントが協力する。
01:42.800 --> 01:45.500
ええと、 すべてがLMSで構築されているわけではありません。
01:45.500 --> 01:52.010
Pythonのプロセスのようなものもあるが、 パズルの7つのピースが協力し合っているようなものだ。
01:52.280 --> 02:01.430
GPT4またはGPT4ミニを使ってRSSフィードから情報を取得し、 それを解析して理解し、
02:01.430 --> 02:05.060
潜在的な取引に変える。
02:05.060 --> 02:11.630
GPT4よりも優れたフロンティア・バスト・モデルを使用する。
02:11.840 --> 02:15.500
そしてクロードはそれを使って、 物の価値を推し量る。
02:15.500 --> 02:16.520
しかし、 それだけではない。
02:16.520 --> 02:18.650
他のモデルも使うつもりだ。
02:18.650 --> 02:23.960
私たちはまた別のラグ・パイプライン、 別のラグ・ベースのモデルを作るつもりだ。
02:24.140 --> 02:26.300
うーん、 でも今回はラングチェーンは使わないよ。
02:26.300 --> 02:27.470
自分たちで巻くんだ。
02:27.470 --> 02:29.420
とても簡単なことだ。
02:29.510 --> 02:37.580
でも、 以前アマゾンのスクレイプから取り出した40万点すべての商品を使うんだ。
02:37.580 --> 02:48.080
そのすべてをメガCromaデータベースに入れ、 それを使ってフロンティアモデルへのラグ・パイプラインの一部としてコンテキストを追加する。
02:48.170 --> 02:51.020
もしかしたら、 すでに考えていたかもしれない。
02:51.020 --> 02:59.330
同じような商品の同じような価格を武器にしたフロンティアモデルが、 先週微調整したモデルを上回るのかどうか、
02:59.330 --> 03:05.670
すでに疑問に思っているかもしれない。
03:05.700 --> 03:06.510
今にわかるさ。
03:06.510 --> 03:07.320
今にわかるよ。
03:07.470 --> 03:11.670
しかし、 可能な限り最良の価格を実現するために、 両モデルに協力してもらうつもりだ。
03:11.670 --> 03:14.940
そして、 別のモデルもすべて明らかにされる。
03:15.390 --> 03:17.820
だから、 大きな1週間になるだろう。
03:17.850 --> 03:22.080
もちろん、 最も重要なポイントは、 このキャップストーン・プロジェクトが、 具体的でリアルに感じられる方法で、
03:22.080 --> 03:26.070
非常に満足のいく形ですべてをまとめるように設計されていることだった。
03:26.070 --> 03:32.160
しかし、 本当に重要なのは、 この機会に学んだことをすべて修正し、 専門知識を身につけ、
03:32.190 --> 03:40.290
経験を積み、 実際に手を動かしてプロレベルのモデルを作ることができるということだ。
03:40.380 --> 03:42.510
そして、 それがこの件の最大のポイントなんだ。
03:42.540 --> 03:47.910
私たちは楽しい文脈の中でそれを行っており、 便利な製品があったときに実際にプッシュ通知を送るようなものだが、
03:47.910 --> 03:57.930
この7週間の間に私たちが行った学びを固めるためのものだ。
03:59.550 --> 04:06.780
でも、 ちょっとだけお話しさせてください。 私たちのエージェント・プラットフォームのアーキテクチャは、 ユーザー・インターフェースを持つことになっています。
04:06.780 --> 04:09.060
もちろん、 グラディオで建設される。
04:09.390 --> 04:15.840
エージェントが過去に何を推薦したかを知ることができるようにメモリーを持ち、
04:15.930 --> 04:24.930
ロギングなどをサポートし、 フレームワークで何が起こっているかを理解できるようにする。
04:25.260 --> 04:27.900
プランニングを担当するエージェントがいる。
04:27.900 --> 04:31.770
他のエージェントの活動を調整することになる。
04:31.770 --> 04:33.960
そして、 このエージェントたちがいる。
04:33.960 --> 04:38.160
有望な案件を見極めるスキャナー・エージェントがいる。
04:38.160 --> 04:40.590
RSSフィードを見ることによって。
04:40.620 --> 04:47.910
アンサンブル・エージェントと呼んでいるもので、 専門用語でアンサンブルというものがあるんだ。
04:47.910 --> 04:57.240
複数のモデルを組み合わせる場合、 このエージェントは、 製品の価格を見積もるさまざまな見積もりモデルをまとめる役割を担うことになる。
04:57.720 --> 05:01.830
そして、 プッシュ通知を送ってくれるメッセージング・エージェントを用意する。
05:01.890 --> 05:05.250
エージェントはこれ以外にもあるからだ。
05:05.250 --> 05:10.740
もちろん、 そのアンサンブル・エージェントは、 他の3人のエージェントと協力することになるからだ。
05:10.740 --> 05:13.230
これが3人の推定代理人だ。
05:13.410 --> 05:16.230
しかし、 この図ではあまりにごちゃごちゃしてしまうので表示しない。
05:16.230 --> 05:19.440
でも、 将来、 そこに着いたら、 きっとそうするよ。
05:19.530 --> 05:23.610
これが、 これから私たちが作ろうとしているものを理解してもらうためのハイレベル・アーキテクチャだ。
05:23.760 --> 05:28.140
そして今日は、 そのうちのひとつに焦点を当てる。
05:28.170 --> 05:30.210
そして、 我々はこのアーキテクチャーをあまり見るつもりはない。
05:30.210 --> 05:38.130
今回は、 前回作ったモデルを、 モーダルという素晴らしいサービスを使ってインターネットにアップする話をするだけです。
05:38.850 --> 05:45.030
モーダルについて話す前に、 もうひとつ言っておきたいことがあります。 私たちは今、 より本格的なコードを書こうとしていますが、
05:45.030 --> 05:55.170
JupyterLabは反復的かつ実験的で、 さまざまな解決策を素早く生み出すための素晴らしいプラットフォームです。
05:55.170 --> 06:06.270
しかし、 研究開発から生産化に向けた道筋が進むにつれて、 コーディングにも変わっていく部分がある。
06:06.600 --> 06:10.560
手始めに、 コードの一部に型ヒントを入れることにする。
06:10.740 --> 06:13.470
もしかしたら、 すでによく知っていることかもしれない。
06:13.470 --> 06:15.660
そうでなければ、 私が説明すればそうなる。
06:15.870 --> 06:16.860
その理由がわかるだろう。
06:16.860 --> 06:22.800
そして、 このようなプロダクションレベルのコードを構築する際には、 ベストプラクティスとなるものだ。
06:23.280 --> 06:25.830
あと、 もう少しコメントを書くつもりだ。
06:25.860 --> 06:29.610
素敵なJupyterノートブックを持っていて、 テキストを入れたり説明したりする時間がたくさんあるときには、
06:29.640 --> 06:40.080
同じようなコメント・アプローチは必要ないかもしれませんが、 今は少なくともメソッドや関数レベルではコメントを入れることができます。
06:40.500 --> 06:44.190
伐採もいいことだし、 そうするつもりだ。
06:44.400 --> 06:49.800
もうひとつ、 非常に良いベストプラクティスがある。
06:49.830 --> 06:54.570
ええと、 もちろん、 本番に使うコードに良い単体テストを書くことはとても重要だ。
06:54.570 --> 06:58.170
カウボーイだからといって、 そんなことはしない。
06:58.290 --> 07:00.990
ああ、 そうだね、 確かにそうすべきだね。
07:01.020 --> 07:03.960
ただ、 私が言いたいのは、 素晴らしい練習だということだ。
07:03.960 --> 07:09.580
もしあなたが、 私たちがプロダクション化しているコードの背後にあるユニットテストを書きたいと望むなら、 どうぞ。
07:09.580 --> 07:10.600
それは素晴らしいことだ。
07:10.630 --> 07:11.920
とても感謝している。
07:11.920 --> 07:18.370
そして、 もしあなたがgit pushをしたいのであれば、 私はそれをdelightと一緒にマージし、
07:18.400 --> 07:24.910
もちろん、 あなたがユニットテストを書いたことに完全な帰属とクレジットを与えます。
07:25.210 --> 07:27.850
それはとても良いベストプラクティスだよ。
07:29.020 --> 07:30.160
オーケー。
07:30.250 --> 07:37.510
ええと、 モーダルの紹介になるんだけど、 これが今日使うプラットフォームなんだ。
07:37.540 --> 07:45.460
モーダルは、 サーバー上でリモートでコードを実行できるプラットフォームで、 使用した時間分だけ料金を支払う。
07:45.490 --> 07:47.410
非常に強力なプラットフォームだ。
07:47.410 --> 07:52.930
AIの世界では、 プロダクションモデルの展開に多用されている。
07:52.960 --> 07:58.900
しかし、 これから説明するように、 クラウド上にあらゆる機能を展開するためにCPUを使用したり、
07:58.900 --> 08:01.960
さまざまな目的で使用することもできる。
08:02.260 --> 08:06.730
それでは早速、 次のビデオではモーダルを試してみましょう。
08:06.760 --> 08:07.660
そこで会おう