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.
 
 

181 lines
7.3 KiB

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に移動しよう。