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に行って試してみよう。