WEBVTT 00:00.530 --> 00:01.130 まあね。 00:01.130 --> 00:01.730 こんにちは。 00:01.730 --> 00:07.520 8週目の2日目まで来たわけだが、 よく頑張ってくれた、 そしてあと4日というところまで来てくれた、 00:07.520 --> 00:11.090 と超感謝している。 00:11.090 --> 00:18.050 そしてこの日、 おそらく全コースの中で最もタフな日だと思う。 00:18.050 --> 00:22.250 だから、 もしあなたがこの1日を乗り切り、 それを理解し、 コードを実行し、 それがすべて意味をなすものであれば、 00:22.250 --> 00:27.860 あなたはすでに基本的にLMエンジニアリングをマスターしていることになる。 00:27.860 --> 00:29.060 こういうことなんだ。 00:29.090 --> 00:30.530 今日はタフになりそうだ。 00:30.710 --> 00:31.940 覚悟しておけ。 00:32.060 --> 00:35.780 でも、 そうなれば本当に面白くなる。 00:35.780 --> 00:38.600 そして、 私たちは素晴らしい功績を成し遂げようとしている。 00:38.600 --> 00:45.020 LMマスターへの8週間の旅も残すところあと4日。 00:45.050 --> 00:46.610 ホームストレッチに入った。 00:46.610 --> 00:52.070 もちろん、 フロンティアモデルを使ってテキストやコードを生成することはできる。 00:52.100 --> 00:58.610 オープンソースを使えば、 顔と顔をくっつけながら、 データセットのキュレーションで問題を解決する戦略に従って、 00:58.610 --> 01:07.770 ベースラインモデルを作り、 フロンティアモデルを微調整することができる。 01:07.860 --> 01:14.640 そして最後に、 私たちが前回行ったのは、 微調整したLMSを本番環境にデプロイすることです。 01:14.670 --> 01:15.750 私たちはモーダルを使う。 01:15.750 --> 01:23.220 他にもたくさんありますが、 モーダルは素晴らしいですし、 ローカルで実行できるシンプルなPythonコードを書くだけで済むような方法で使っています。 01:23.220 --> 01:30.270 どうやらローカルで動いているように見えるが、 実際はクラウド上で動いているモデルをモーダルで呼び出しているようだ。 01:30.300 --> 01:32.910 使った分だけ支払う。 01:33.360 --> 01:43.770 そこで今日は、 最終的なプライシング・モデルを構築するために、 より多くのプライシング・モデルを見るためのサイドステップを踏む。 01:43.770 --> 01:48.330 それはアンサンブルと呼ばれる、 複数のモデルの組み合わせになる。 01:48.330 --> 01:58.110 Ragに戻り、 Ragを使って巨大なChromeデータストアに対して動作するフロンティアモデル・ソリューションを構築する。 01:58.140 --> 02:00.870 前回と違うのは、 ラングチェーンを使わないことだ。 02:00.870 --> 02:07.380 ベクターストアで直接調べて、 それを使ってプロンプトを作る。 02:07.380 --> 02:11.320 カバーの中でどのように機能するかを正確に理解するのは良いことだ。 02:11.650 --> 02:17.380 そして、 高い専門性をもってこのアンサンブル・モデルを構築し、 多くのモデルを呼び出しながら、 02:17.380 --> 02:21.370 プロダクション・レディなコードを提供できるようにする。 02:21.370 --> 02:26.680 そして、 おそらくここで最も重要なことは、 私たちがやることの多くは、 02:26.680 --> 02:35.290 これまでやってきたことの繰り返しでありながら、 もう少し工業的な強さを持っているということだ。 02:35.290 --> 02:41.020 これは、 LMエンジニアリングのさまざまな側面にかなり自信がある状態から、 02:41.020 --> 02:47.290 上級者になることを目指すものだ。 だから、 時間をかけてコードに目を通し、 これを練習、 02:47.290 --> 02:54.100 練習、 練習の機会としてとらえ、 真の専門知識を身につけたと感じられるようになるのだ。 02:54.850 --> 02:55.390 分かった。 02:55.390 --> 02:59.530 手っ取り早く、 私たちがここで取り組んでいるプロジェクトが何なのかを思い出してほしい。 02:59.560 --> 03:14.080 ザ・プライス・イズ・ライトと呼ばれるプロジェクトでは、 この自律型エージェントフレームワークのエージェントワークフローを構築し、 03:14.080 --> 03:20.410 お得な情報がオンラインで公開されるのを監視し、 その価格を推定し、 03:20.410 --> 03:30.670 お買い得だと思われる場合はプッシュ通知を送信します。 03:30.700 --> 03:37.390 前回、 エージェントのワークフローを示した図をお見せしましたが、 覚えていらっしゃるでしょうか。 03:37.390 --> 03:43.960 左側がユーザー・インターフェースで、 右側がフレームワークです。 03:43.960 --> 03:54.640 そして、 有望な取引を探すスキャン・エージェント、 価格を見積もるアンサンブル、 プッシュ通知を送ってくれるメッセージング・エージェントの3つだ。 03:54.760 --> 04:03.520 というのも、 アンサンブル・エージェント自体が3つの異なるモデルに呼びかけるからだ。 04:03.520 --> 04:15.430 フロンティア・エージェントを呼び出すことになるが、 これは、 たくさんの既存商品の在庫をもとに商品の価格を決めるラグ・ワークフローになる。 04:15.440 --> 04:18.170 ラグにとっては完璧な使用例だ。 04:18.200 --> 04:24.050 もちろん、 私が言うようにすでに考えていたかもしれない。 04:24.080 --> 04:24.800 まあ、 そうするつもりだ。 04:24.830 --> 04:31.430 今日、 アンサンブル・エージェントは、 すでにあるスペシャリスト・エージェントを使用し、 04:31.460 --> 04:42.800 スペシャリスト・エージェント・クラスのようなものを構築し、 ランダムフォレスト・エージェントを使用します。 04:42.830 --> 04:44.690 ただし、 ひねりがある。 04:44.720 --> 04:49.910 トランスフォーマーアーキテクチャを使用するベクトル埋め込みを使用する予定だ。 04:49.910 --> 04:54.110 つまり、 伝統的なMLを現代風にアレンジしたようなものだ。 04:54.290 --> 05:00.320 というわけで、 今日は基本的に、 赤で示したアイコンのすべてに取り組むことになる。 05:00.320 --> 05:02.060 これからアンサンブル・エージェントに取り組むつもりだ。 05:02.060 --> 05:03.740 我々はすでに専門エージェントを構築している。 05:03.740 --> 05:09.050 だから、 残りの2つは今日の征服の一部となる。 05:09.050 --> 05:16.910 そして今日は、 他の複数の推計者を利用して価格を計算することができるアンサンブル・エージェントを紹介する。 05:16.940 --> 05:18.230 それが課題だ。 05:18.230 --> 05:20.150 JupyterLabに移動しよう。