WEBVTT 00:01.130 --> 00:05.450 正直に言うと、 この時点で私には焦る理由がある。 00:05.480 --> 00:10.340 私たちはずっとラガについてしゃべってきたのに、 あなたはまだ実際にラガを使う機会がなかった。 00:10.340 --> 00:11.840 ベクターについて話したばかりだ。 00:11.840 --> 00:16.520 プロンプトとコンテクスト、 そしてラグの廉価版について話してきた。 00:16.910 --> 00:18.890 いよいよ本番だ。 00:18.920 --> 00:22.100 今日は、 ボロ・パイプラインを実行に移す時だ。 00:22.100 --> 00:23.330 そして、 バカバカしくなる。 00:23.330 --> 00:23.750 簡単だ。 00:23.750 --> 00:25.250 待っていてくれ。 00:25.280 --> 00:27.440 それで今日はどうなるんだ? 00:27.440 --> 00:32.480 私たちはロング・チェーンで会話の連鎖を作ろうと思っています。 ロング・チェーンは、 00:32.480 --> 00:38.720 ラグとのリトリーバルで会話をするために、 さまざまなピースを接着剤でくっつけたものです。 00:38.750 --> 00:48.410 私たちは、 専門家の理解を示す質問と回答を得ることで、 最終的にはチャットUIを備えたナレッジワーカーアシスタントを構築するつもりです。 00:48.410 --> 00:53.870 そして、 すでに学んだ素晴らしいことのおかげで、 もちろん、 信じられないほど簡単になることがわかるだろう。 00:54.050 --> 01:03.920 まず最初に、 簡単に説明すると、 ロングチェーンにはいくつかの抽象化された概念がある。 01:03.920 --> 01:07.490 今日使うのはこの3つだ。 01:07.520 --> 01:10.250 まず第一に、 LLMには抽象的なイメージがある。 01:10.250 --> 01:13.730 LLMは、 我々の場合はOpenAIを表しているに過ぎない。 01:13.760 --> 01:15.350 だが、 他の選手を代表する可能性もある。 01:15.350 --> 01:20.690 そして梁城は、 モデルを抽象化した1つのオブジェクトを提供する。 01:20.870 --> 01:23.750 そして、 レトリーバーと呼ばれる抽象的な存在がある。 01:23.750 --> 01:28.130 そしてそれは、 ベクターストアのようなものへのインターフェースのようなものだ。 01:28.130 --> 01:32.420 この場合、 ラグ検索に使われるのはクロマーである。 01:32.420 --> 01:38.090 つまり、 ベクトルを受け取ってプロンプトを充実させることができる、 レトリーバー・インターフェースのようなものだ。 01:38.150 --> 01:41.090 そして3つ目の抽象化がメモリーだ。 01:41.090 --> 01:48.470 そしてそれは、 チャットボットとのディスカッションの履歴のようなもの、 記憶を表している。 01:48.470 --> 01:55.040 だから実際には、 私たちがここで慣れ親しんでいるのは、 ディクツのリスト、 一番上のシステム・メッセージのようなものからなるリスト、 01:55.070 --> 01:59.090 そしてユーザー・アシスタント、 ユーザー・アシスタントだ。 01:59.360 --> 02:11.390 しかし、 それはロングチェーン・メモリーという概念に抽象化され、 その裏側では、 リストやその他のさまざまなモデルが必要とするフォーマットを処理する。 02:11.390 --> 02:19.090 これが、 ロング・チェインから得られる、 より多くの機能を包む3つの主要なラッパーだ。 02:19.090 --> 02:26.020 そのことを念頭に置いて、 ラグ・パイプラインをいかにシンプルにまとめるかを見てみよう。 02:26.080 --> 02:29.650 これは4行のコードでできる。 02:29.650 --> 02:33.070 そしてこれが、 今目の前にある4行のコードだ。 02:33.310 --> 02:37.720 そして、 これこそが1行目にある輝きなのだ。 02:37.900 --> 02:42.280 LMは、 ラングチェーンlnオブジェクトを作成しているチャットオープンAIです。 02:42.370 --> 02:46.120 オープンAI用のLMオブジェクト。 02:46.450 --> 02:50.890 そして、 他のものにも似たようなものを作ることができると想像できるだろう。 02:51.670 --> 02:53.860 これが最初のラインであり、 最初の抽象化だ。 02:53.890 --> 02:55.480 2行目のLM。 02:55.480 --> 02:56.470 2つ目の抽象化。 02:56.470 --> 02:57.130 メモリ。 02:57.160 --> 03:01.210 会話バッファメモリと呼ばれるラングチェーン・オブジェクトを作成します。 03:01.630 --> 03:03.580 これには2つほど必要なものがある。 03:03.580 --> 03:10.660 重要なのは、 どのように整理するか、 03:10.660 --> 03:26.020 何を整理するか、 何を使ってメモリやチャット履歴を検索するかということだ。 03:26.020 --> 03:30.910 だから、 この種のチャット・アプリケーションには、 これらを使用しなければならないことを知っておく必要がある。 03:31.810 --> 03:44.290 次の行は、 単純にベクターストアがあり、 そのクロマを作成したと言っている。 03:44.290 --> 03:48.100 そして、 それをリトリーバーと呼ばれるインターフェース・オブジェクトで包む。 03:48.100 --> 03:56.710 ラング・チェーンがラグ・ワークフローを実現するために期待しているのは、 このようなオブジェクトなのだ。 03:56.980 --> 04:01.570 つまり、 LM、 メモリー、 そしてレトリバーという3つの抽象的なものだ。 04:01.600 --> 04:02.680 それらはすべて作られたものだ。 04:02.680 --> 04:07.600 そして今、 最後の一行がそれを会話の連鎖と呼ばれるものにまとめた。 04:07.900 --> 04:14.470 LMからこのメソッドを呼び出して作成し、 04:14.500 --> 04:25.030 LM、 リトリーバー、 メモリの3つを渡すだけです。 04:25.030 --> 04:26.920 それはとてもシンプルなことだ。 04:26.920 --> 04:32.620 この4行目のコードで、 ラグ・パイプラインができた。 04:33.490 --> 04:34.450 信じないのか? 04:34.450 --> 04:37.150 JupyterLabに行って試してみよう。