というわけで､ 今週はこの企画をご紹介できることを大変嬉しく思う｡
そして､ その肉付きの良さ｡
これがコースのキャップストーン・プロジェクトだ｡
私はそれを『プライス・イズ・ライト』と呼んでいる｡
私たちがこれまでやってきたことをまとめるものだ｡
私たちは建設するということだ｡
私たちに課せられた課題は､ インターネット上で公開されている取引を探し､ RSSフィードを購読して､ 公開された取引を見つけることができるプラットフォームを構築することです｡
潜在的な取引､ 有望そうな取引を見つけると､
それを読み､ 解釈し､ 先週私たちが構築した独自のものを含む多くのLMSを使用して､ それがどれくらいの価値があるかを独自に推定します｡
そして､ もし我々がそれを成し遂げることができれば､ そしてそのプラットフォームを構築することができれば､ 我々は先進的なプラットフォームという特別なものを構築したことになる｡
多くの異なる機能の断片を統合したもので､
願わくば私が誇れるものでありたい｡
エージェントは7人になる｡
すでに言ったが､ もう一度言う｡
7人のエージェントが協力する｡
ええと､ すべてがLMSで構築されているわけではありません｡
Pythonのプロセスのようなものもあるが､ パズルの7つのピースが協力し合っているようなものだ｡
GPT4またはGPT4ミニを使ってRSSフィードから情報を取得し､ それを解析して理解し､
潜在的な取引に変える｡
GPT4よりも優れたフロンティア・バスト・モデルを使用する｡
そしてクロードはそれを使って､ 物の価値を推し量る｡
しかし､ それだけではない｡
他のモデルも使うつもりだ｡
私たちはまた別のラグ・パイプライン､ 別のラグ・ベースのモデルを作るつもりだ｡
うーん､ でも今回はラングチェーンは使わないよ｡
自分たちで巻くんだ｡
とても簡単なことだ｡
でも､ 以前アマゾンのスクレイプから取り出した40万点すべての商品を使うんだ｡
そのすべてをメガCromaデータベースに入れ､ それを使ってフロンティアモデルへのラグ・パイプラインの一部としてコンテキストを追加する｡
もしかしたら､ すでに考えていたかもしれない｡
同じような商品の同じような価格を武器にしたフロンティアモデルが､ 先週微調整したモデルを上回るのかどうか､
すでに疑問に思っているかもしれない｡
今にわかるさ｡
今にわかるよ｡
しかし､ 可能な限り最良の価格を実現するために､ 両モデルに協力してもらうつもりだ｡
そして､ 別のモデルもすべて明らかにされる｡
だから､ 大きな1週間になるだろう｡
もちろん､ 最も重要なポイントは､ このキャップストーン・プロジェクトが､ 具体的でリアルに感じられる方法で､
非常に満足のいく形ですべてをまとめるように設計されていることだった｡
しかし､ 本当に重要なのは､ この機会に学んだことをすべて修正し､ 専門知識を身につけ､
経験を積み､ 実際に手を動かしてプロレベルのモデルを作ることができるということだ｡
そして､ それがこの件の最大のポイントなんだ｡
私たちは楽しい文脈の中でそれを行っており､ 便利な製品があったときに実際にプッシュ通知を送るようなものだが､
この7週間の間に私たちが行った学びを固めるためのものだ｡
でも､ ちょっとだけお話しさせてください｡ 私たちのエージェント・プラットフォームのアーキテクチャは､ ユーザー・インターフェースを持つことになっています｡
もちろん､ グラディオで建設される｡
エージェントが過去に何を推薦したかを知ることができるようにメモリーを持ち､
ロギングなどをサポートし､ フレームワークで何が起こっているかを理解できるようにする｡
プランニングを担当するエージェントがいる｡
他のエージェントの活動を調整することになる｡
そして､ このエージェントたちがいる｡
有望な案件を見極めるスキャナー・エージェントがいる｡
RSSフィードを見ることによって｡
アンサンブル・エージェントと呼んでいるもので､ 専門用語でアンサンブルというものがあるんだ｡
複数のモデルを組み合わせる場合､ このエージェントは､ 製品の価格を見積もるさまざまな見積もりモデルをまとめる役割を担うことになる｡
そして､ プッシュ通知を送ってくれるメッセージング・エージェントを用意する｡
エージェントはこれ以外にもあるからだ｡
もちろん､ そのアンサンブル・エージェントは､ 他の3人のエージェントと協力することになるからだ｡
これが3人の推定代理人だ｡
しかし､ この図ではあまりにごちゃごちゃしてしまうので表示しない｡
でも､ 将来､ そこに着いたら､ きっとそうするよ｡
これが､ これから私たちが作ろうとしているものを理解してもらうためのハイレベル・アーキテクチャだ｡
そして今日は､ そのうちのひとつに焦点を当てる｡
そして､ 我々はこのアーキテクチャーをあまり見るつもりはない｡
今回は､ 前回作ったモデルを､ モーダルという素晴らしいサービスを使ってインターネットにアップする話をするだけです｡
モーダルについて話す前に､ もうひとつ言っておきたいことがあります｡ 私たちは今､ より本格的なコードを書こうとしていますが､
JupyterLabは反復的かつ実験的で､ さまざまな解決策を素早く生み出すための素晴らしいプラットフォームです｡
しかし､ 研究開発から生産化に向けた道筋が進むにつれて､ コーディングにも変わっていく部分がある｡
手始めに､ コードの一部に型ヒントを入れることにする｡
もしかしたら､ すでによく知っていることかもしれない｡
そうでなければ､ 私が説明すればそうなる｡
その理由がわかるだろう｡
そして､ このようなプロダクションレベルのコードを構築する際には､ ベストプラクティスとなるものだ｡
あと､ もう少しコメントを書くつもりだ｡
素敵なJupyterノートブックを持っていて､ テキストを入れたり説明したりする時間がたくさんあるときには､
同じようなコメント・アプローチは必要ないかもしれませんが､ 今は少なくともメソッドや関数レベルではコメントを入れることができます｡
伐採もいいことだし､ そうするつもりだ｡
もうひとつ､ 非常に良いベストプラクティスがある｡
ええと､ もちろん､ 本番に使うコードに良い単体テストを書くことはとても重要だ｡
カウボーイだからといって､ そんなことはしない｡
ああ､ そうだね､ 確かにそうすべきだね｡
ただ､ 私が言いたいのは､ 素晴らしい練習だということだ｡
もしあなたが､ 私たちがプロダクション化しているコードの背後にあるユニットテストを書きたいと望むなら､ どうぞ｡
それは素晴らしいことだ｡
とても感謝している｡
そして､ もしあなたがgit pushをしたいのであれば､ 私はそれをdelightと一緒にマージし､
もちろん､ あなたがユニットテストを書いたことに完全な帰属とクレジットを与えます｡
それはとても良いベストプラクティスだよ｡
オーケー｡
ええと､ モーダルの紹介になるんだけど､ これが今日使うプラットフォームなんだ｡
モーダルは､ サーバー上でリモートでコードを実行できるプラットフォームで､ 使用した時間分だけ料金を支払う｡
非常に強力なプラットフォームだ｡
AIの世界では､ プロダクションモデルの展開に多用されている｡
しかし､ これから説明するように､ クラウド上にあらゆる機能を展開するためにCPUを使用したり､
さまざまな目的で使用することもできる｡
それでは早速､ 次のビデオではモーダルを試してみましょう｡
そこで会おう