WEBVTT 00:01.220 --> 00:07.940 でも、 今週の企画はとても良かったと思うし、 00:07.940 --> 00:12.920 とても楽しめた。 00:12.920 --> 00:15.110 今は走っているし、 とても気に入っている。 00:15.110 --> 00:19.250 絶対に気に入っているし、 早く乗り込んで皆さんにお見せしたい。 00:19.520 --> 00:22.790 そして、 いつものようにイントロダクションから始めよう。 00:22.790 --> 00:26.870 しかし、 すぐにコードに取りかかるつもりだ。 00:26.870 --> 00:31.250 だから、 私たちは巨大な "I "の中に深く入っていくことになる。 00:31.280 --> 00:32.750 とてもホットな話題だ。 00:32.750 --> 00:35.630 今、 誰もが満足できないものなんだ。 00:35.720 --> 00:42.410 この7週間半の間にすでに取り組んできたLMSのさまざまな構成要素について、 00:42.410 --> 00:50.120 より深く学ぶ機会として利用するのです。 00:50.120 --> 00:59.720 そこで今日は、 エージェント的なワークフロー、 エージェントフレームワークについて話し、 そしてエージェントフレームワークを構築する。 00:59.720 --> 01:10.520 RSSフィードを見て見つけたお得な情報を、 プッシュ通知で送ることができる。 01:10.520 --> 01:14.840 つまり、 すべてのピースを組み合わせて解決策を導き出すのだ。 01:15.140 --> 01:25.370 ではその前に、 エージェント型AIとは何か、 エージェントのワークフローとは何か、 これらすべてについて簡単にお話ししましょう。 01:25.370 --> 01:35.870 正直なところ、 この曖昧な用語はさまざまなグループによっていまだに使われ続けている。 01:35.870 --> 01:38.240 だから、 いろいろな意味で使われている。 01:38.240 --> 01:43.640 しかし、 一歩引いて考えてみると、 前の週にも少し触れましたが、 一歩引いて考えてみると、 01:43.640 --> 01:52.580 エージェント型AIの特徴や重要な側面は、 これら5つの要素から成り立っていると考えることができます。 01:52.580 --> 01:57.140 そして、 これ以上だと言う人もいれば、 これ以下だと言う人もいるのは間違いない。 01:57.140 --> 02:00.130 しかし、 私はこの5つがビッグ5だと思う。 02:00.160 --> 02:06.160 つまり、 まず第一に、 エージェント・ソリューションとは、 より大きな問題、 より複雑な問題を、 02:06.160 --> 02:15.280 LMSや通常のソフトウェアで実行できる可能性のある小さな断片に分割することができるものである。 02:15.460 --> 02:22.960 しかし、 より困難なタスクを分解する能力は、 エージェント・ソリューションの特徴であることは間違いない。 02:23.110 --> 02:28.990 これまで様々な場面で取り上げてきたツールの使用、 関数呼び出し、 構造化されたアウトプット。 02:28.990 --> 02:33.250 これもまた、 エージェント・ソリューションの権限に含まれることが多い。 02:33.250 --> 02:41.350 LMSに単なる会話以上のものを与えるという考え方は、 プロンプトが表示され、 チャットの返答を返すというものなのでしょうか。 02:41.350 --> 02:45.190 しかし、 それはよりタイトな構成にフィットするものだ。 02:45.190 --> 02:47.830 この特定のJSONフォーマットでの出力が必要なのです。 02:47.830 --> 02:51.250 異なるアクティビティを実行するために、 これらの異なる関数を呼び出すことができる。 02:51.250 --> 02:56.860 つまり、 それがエージェントAIと環境にどのようにフィットするかということだ。 02:56.890 --> 02:58.660 フレームワーク環境。 02:58.690 --> 02:59.860 それに対するさまざまな言葉。 02:59.860 --> 03:11.260 しかし、 サンドボックスのようなものがあれば、 すべての異なるエージェントが利用できる機能を提供することができる。 03:11.290 --> 03:14.140 その典型的な例が、 メモリのようなものだろう。 03:14.140 --> 03:19.600 すべてのエージェントが、 過去に起こったことを反映した情報を共有できるようなものがあれば、 03:19.600 --> 03:27.820 それはエージェント環境であり、 異なるエージェントが何らかの方法でお互いを呼び出せるようにするものだ。 03:28.810 --> 03:33.760 それから、 これは必需品ではないものの例だ。 03:33.760 --> 03:36.490 これがなければエージェント・ソリューションがないというわけではない。 03:36.490 --> 03:44.920 しかし、 エージェント・ソリューションでは、 計画エージェント、 つまり、 どのタスクをどの順番で行うかを決定するエージェントを持つことが多い。 03:44.920 --> 03:49.660 繰り返しになるが、 普通、 この話をするとき、 プランニング・エージェントというのは、 LLM(法学修士号)のような、 03:49.660 --> 03:54.970 ある仕事を引き受け、 これとこれとこれをやりたい、 と考えることができる人のことを想像すると思う。 03:54.970 --> 03:57.020 しかし、 LLMである必要はない。 03:57.050 --> 04:01.820 5つのステップを踏むだけの簡単な問題なら、 そのステップを呼び出すPythonのコードを書けばいいし、 04:01.820 --> 04:07.190 JSONの設定ファイルでもいい。 04:07.460 --> 04:13.550 しかし、 このボックスにチェックを入れるには、 あなたの、 あなたの、 04:13.580 --> 04:22.430 あなたのプランナーとみなされる何かが必要で、 必ずしもそれが必要というわけではありません。 04:22.460 --> 04:31.460 主体的なものとそうでないものを区別する唯一の基準は、 おそらく自律性だろう。 04:31.460 --> 04:43.610 つまり、 エージェント型AIソリューションには、 人間とのチャットを超越した何らかの存在があるという考えだ。 04:43.610 --> 04:51.680 というのも、 私たちのラグ・ソリューションのようにQ&Aチャットをしたことがあり、 04:51.680 --> 04:59.700 保険会社について話したのですが、 明らかにそのチャットにメモリがありました。 04:59.730 --> 05:05.790 私たちの航空会社のチャットにもメモリがありましたが、 それは自律型AIとはみなされません。 05:05.820 --> 05:11.190 メモリが存在するのは、 そのアプリを実行し、 人間がそのアプリとやりとりしている間だけだ。 05:11.490 --> 05:15.810 それ以上の存在感はなかった。 05:15.810 --> 05:18.360 だから、 自主性という考え方もある。 05:18.390 --> 05:24.180 そして、 このものには、 より永続的な存在があるのだという、 ある種の感覚がある。 05:24.210 --> 05:26.100 と言って、 舞台裏で動いている。 05:26.130 --> 05:29.280 ちょっと不思議に聞こえるかもしれないが、 そんなことはない。 05:29.310 --> 05:34.590 おわかりのように、 基本的に、 実行中のプロセスがある場合、 そのプロセスは何らかのアクティビティを実行している。 05:34.620 --> 05:39.420 必ずしも人間的な交流が必要なわけではない。 05:39.450 --> 05:41.550 それがエージェント・ソリューションのようだね。 05:42.090 --> 05:45.720 だから、 一言で言えば、 超クリアなものがあるわけではないんだ。 05:45.750 --> 05:46.740 定義 05:46.740 --> 05:52.920 そして、 複数のモデルが関与する難しい問題を解決するAIソリューションを扱う場合、 05:52.920 --> 06:00.750 多くの場合、 そのモデル間の連携が必要となり、 単なるプロンプトとレスポンスだけではありません。 06:00.750 --> 06:08.430 私たちが慣れ親しんでいるチャット・インターフェースは、 そのようなものはすべてエージェント型AIソリューションと考えられている。 06:08.970 --> 06:13.020 現在、 エージェント機能を提供するフレームワークはたくさんある。 06:13.020 --> 06:16.860 ランシャンにはたくさんのエージェント能力がある。 06:16.860 --> 06:19.440 ハグすることで手に入る道具がある。 06:19.680 --> 06:22.560 グラディオは何かを持っているし、 他にもたくさんある。 06:22.560 --> 06:25.410 中にはノーコードと呼ばれるものもある。 06:25.410 --> 06:28.230 つまり、 異なるモデルをつなぎ合わせているだけなんだ。 06:28.230 --> 06:34.140 中には、 ラング・チェーンのオファーのように、 より多くのコードが絡むものもある。 06:34.140 --> 06:39.450 しかし、 私があなたに言いたかったことのひとつは、 これらのプラットフォームの多くがLlmsの周りに抽象化を施しているということです。 06:39.450 --> 06:45.540 私たちが以前Lang Chainに出会ったとき、 Ragがそうであったように。 06:45.540 --> 06:50.910 そして、 この種のエージェント型AIソリューションを構築するには、 そのような抽象的な概念は必要ない。 06:50.910 --> 06:54.980 私たちはLlmsに直接電話する方法を知っているし、 自分たちだけでできる。 06:54.980 --> 06:59.300 LMSを稼働させ、 適切な情報を適切な人に送ることができる。 06:59.360 --> 07:06.500 LMは現在、 LMエンジニアリングのマスターであり、 あと5%でマスターになれる。 07:06.500 --> 07:08.360 それはあなたの能力の範囲内だ。 07:08.360 --> 07:14.180 このセッションでは、 エージェントAIのフレームワークを構築するために、 エージェントクラスを作成し、 07:14.180 --> 07:20.510 Pythonのコードを使ってエージェントが動作するようにします。 07:20.510 --> 07:29.030 私たちはそれらをコラボレーションさせ、 私たち自身のコードでつなぎ合わせる。 07:29.030 --> 07:33.740 そして、 エージェント間でどのような情報がやり取りされているかを実際に見ることができる。 07:33.860 --> 07:41.540 でも、 もちろん、 既製品の抽象化レイヤー製品を使うこともできる。 07:41.540 --> 07:42.440 お望みなら 07:42.470 --> 07:47.510 Langshanや他の会社から入手可能なものを調べることができる。 07:47.600 --> 07:51.650 今やっていることの一部をやり直すのも面白いかもしれない。 07:51.680 --> 07:56.750 おそらく、 既製品のどれかを使えば簡単にできるだろう。 07:56.750 --> 07:59.270 でも、 私たちとしては、 もっと細かいことを知りたい。 07:59.300 --> 08:05.270 私たちは実際に小さなエージェントフレームワークを構築し、 私たちが解決しようとしている問題、 08:05.270 --> 08:12.620 つまりインターネット上のお得な情報をかき集めて、 それを見つけたら私たちにメッセージを送るという問題を解決するために、 08:12.620 --> 08:15.950 複数のllmsに参加してもらうつもりです。 08:15.980 --> 08:19.100 そのフレームワークがどのようなものか、 手っ取り早く思い出してみよう。 08:19.100 --> 08:20.480 我々の建築とは何か? 08:20.510 --> 08:25.070 これが私たちが組み立てているワークフローだ。 08:25.310 --> 08:32.240 3つのモデルが動いていて、 それらを呼び出すアンサンブル・エージェントがいる。 08:32.420 --> 08:39.530 他のモデルを呼び出すアンサンブルモデルは、 何年も前からあるものだからだ。 08:39.530 --> 08:46.040 しかし、 このフレームワークに参加し、 ログを取るという同じ構造、 08:46.040 --> 08:51.500 同じ機能を持つ別のクラスとして動作しているので、 08:51.530 --> 09:00.410 これらを別のエージェントとして考えるのは理にかなっています。 09:00.440 --> 09:05.780 ただ、 シンプルにするために、 直接呼ばれるようにしているだけだが、 確かにそうすることもできる。 09:06.140 --> 09:11.420 私は、 これらの3つの異なるモデルを実行するエージェントは別々であり、 それぞれのエージェントを呼び出し、 09:11.420 --> 09:23.600 それらのエージェントと協力し、 線形回帰の重みを適用して、 商品の価格のアンサンブルを与えるアンサンブル・エージェントがいることを提案することにしました。 09:23.690 --> 09:27.260 スキャナー・エージェントは前回見たものだ。 09:27.260 --> 09:28.490 これはエージェントだ。 09:28.520 --> 09:31.340 私たちはスキャナーのエージェントに電話をかけて終わりにした。 09:31.340 --> 09:45.140 フィードを収集し、 Gpt4ゼロを呼び出すことで、 各取引の簡潔な説明とそれに関連する価格帯を見つけることができる。 09:45.140 --> 09:46.340 そして、 それをまとめている。 09:46.340 --> 09:52.270 入力メモリがあったことを覚えているだろうか。 09:52.600 --> 09:58.540 記憶とは、 過去にすでに表面化した取引を表面化させないように指示することだ。 09:59.800 --> 10:04.990 メッセージング・エージェントは、 あなたの携帯電話にプッシュ通知を送る、 10:04.990 --> 10:11.650 とてもシンプルなものです。 10:11.680 --> 10:15.520 活動を調整することができるプランニング・エージェント。 10:15.520 --> 10:21.190 LMではなく、 単純なPythonスクリプトになるだろうが、 簡単にLMにすることができる。 10:21.850 --> 10:26.170 それからエージェント・フレームワーク。 10:26.170 --> 10:28.090 ええと、 全然派手じゃないよ。 10:28.090 --> 10:32.800 それは単に、 これらすべてのエージェントを持っていて、 メッセージングを続けることができるものだ。 10:32.800 --> 10:36.520 そして、 それが今日のエージェント・フレームワークの作成となる。 10:36.520 --> 10:43.390 そして明日は、 そのすべてを包み込み、 素晴らしく見せるユーザー・インターフェースを構築する。 10:43.690 --> 10:48.520 でも、 もう十分やる気を出してもらえたと思う。 10:48.550 --> 10:50.440 JupyterLabで会おう。