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.
 
 

385 lines
15 KiB

WEBVTT
00:00.440 --> 00:05.900
JupyterLabへようこそ、 そしてLong Chainの世界での最初の実験へようこそ。
00:05.900 --> 00:11.840
私のようにJupyterノートブックを使いこなすことがいかに重要か、 もう一度思い出してほしい。
00:11.840 --> 00:16.490
理想的なのは、 私が話しているのと同時に、 あなたもJupyter Labを立ち上げ、
00:16.490 --> 00:23.870
5週目、 そして2日目のこの日に向けて、 私がステップを踏んでいるように、 あなたもステップを踏むことができることです。
00:23.900 --> 00:29.360
もしそれが無理なら、 できるだけ早くその直後に、 それからこれを試してみてほしい。
00:29.390 --> 00:33.860
特に、 テキスト・チャンクや後のベクターといった概念について話し始めると、
00:33.860 --> 00:36.830
これを自分で体験することはとても重要だ。
00:36.860 --> 00:41.480
私の言っていることを検証し、 実験し、 自分の目で確かめ、 コードを試したり、
00:41.480 --> 00:46.790
いろいろなものをプリントアウトしたりして、 舞台裏で動いていることに慣れることが、
00:46.790 --> 00:49.010
これからとても重要になる。
00:49.010 --> 00:58.280
もちろん、 私たちは5週目に入り、 フォルダーの中では2日目に入っている。
00:58.760 --> 01:01.950
輸入もいくつかやっているし、 今は新しい輸入もある。
01:01.950 --> 01:07.020
ラングチェーンからコードをインポートするのは初めてなので、 ドキュメント・ローダーと呼ばれる、
01:07.020 --> 01:11.820
ファイルを読み込むためのユーティリティ・クラスをインポートします。
01:11.850 --> 01:19.320
フォルダ全体を読み込むディレクトリローダーと、 個々のテキストファイルを読み込むテキストローダーと呼ばれるものがある。
01:19.440 --> 01:24.720
文字テキスト分割ツールというものもインポートしています。
01:24.720 --> 01:31.890
これは、 ご覧のように、 ドキュメントを文字の塊に分割するものです。
01:31.920 --> 01:34.170
インポートを実行しよう。
01:34.530 --> 01:39.060
ええと、 今日は実際に使わないけど、 次回使う定数をいくつか設定した。
01:39.390 --> 01:42.870
ええと、 仕事に取り掛かろう。
01:42.870 --> 01:51.360
前回、 文書を読んで辞書に載せるという馬鹿げたことをやったのを覚えているかい?
01:51.360 --> 01:52.770
鍵は文書の名前だった。
01:52.770 --> 01:54.870
その値はドキュメントの内容だった。
01:54.870 --> 01:57.360
さて、 今回はもう少しスマートなことをするつもりだ。
01:57.360 --> 01:59.370
ラングチェーンを使うのもいい。
01:59.370 --> 02:03.670
そこでまず、 ナレッジ・ベース内のさまざまなフォルダーのリストを取得する。
02:03.700 --> 02:08.680
これらのフォルダは、 これらの会社の契約社員や製品であることを覚えているだろう。
02:08.680 --> 02:10.990
だから、 それをフォルダ分けしたんだ。
02:11.500 --> 02:21.100
そして今、 それぞれのフォルダーについて、 まず文書会社の契約社員や製品の種類を取得する。
02:21.370 --> 02:35.050
そして、 ディレクトリ・ローダーを使ってこのディレクトリをロードし、 ハンドルとディレクトリ・パスを渡す。
02:35.050 --> 02:40.210
さらに、 テキスト・ローダー・ローダー・クラスというものを渡して、 テキスト・ファイルなので、
02:40.210 --> 02:45.220
それを使ってそれぞれのファイルを取り込むように指示する。
02:45.220 --> 02:49.420
そして、 loader dot loadを呼び出すだけで、 それらのドキュメントをすべて取り込んでくれる。
02:49.510 --> 02:52.600
それぞれのドキュメントを繰り返し見ていく。
02:52.630 --> 02:56.920
各ドキュメントにメタデータを設定することができるかと言います。
02:57.460 --> 03:04.740
docタイプと呼ばれるものを追加し、 会社の契約書、 従業員、 製品などのDoctypeに設定したい。
03:04.740 --> 03:08.550
そして、 それをドキュメントと呼ばれるリストに追加する。
03:09.030 --> 03:10.680
ご理解いただけただろうか。
03:10.920 --> 03:16.590
実行した結果、 ドキュメント・タイプのオブジェクトが31個になったので、
03:16.590 --> 03:21.240
そのうちのひとつをお見せしよう。
03:22.740 --> 03:23.940
これだ。
03:23.970 --> 03:27.150
ナレッジベースのディレクトリにある。
03:27.300 --> 03:30.210
メタデータにはソースと呼ばれるものがあり、 それがどこにあるかを教えてくれる。
03:30.240 --> 03:33.360
そして、 これがdoctypeで、 製品に追加したものだ。
03:33.930 --> 03:34.860
だから商品なんだ。
03:34.860 --> 03:39.990
レルムMDと呼ばれるもので、 これがファイルの全内容だ。
03:40.020 --> 03:46.020
製品に入れば、 確かに領域と呼ばれるものがあることを納得しに行こう。 md。
03:46.710 --> 03:52.260
それをダブルクリックすると、 おそらく読み込まれたものと同じものであることがわかるだろう。
03:52.290 --> 03:56.010
最初の文書はこちらでも見ることができる。
03:56.130 --> 03:58.410
そして、 それは製品にも入っている。
03:58.410 --> 04:00.370
マーク・カームと呼ばれている。
04:00.730 --> 04:03.580
それがどこから来るのか、 おわかりいただけるだろう。
04:03.580 --> 04:06.730
そして、 ランダムに24番を選んでみよう。
04:07.360 --> 04:13.870
24番目の文書は、 マキシン・トンプソンの従業員人事記録である。
04:13.870 --> 04:15.580
そしてマキシンがいる。
04:15.580 --> 04:19.000
彼女はドクタータイプの社員で、 そこに彼女のコンテンツがある。
04:19.000 --> 04:22.570
だから複雑なことは何もない。
04:22.720 --> 04:29.890
ドキュメントを読み込み、 ドキュメント・タイプを指定し、 31のドキュメントがドキュメントに収まっている。
04:30.250 --> 04:41.080
次にすることは、 このテキスト・スプリッターというものを使って、 ドキュメントを取り込み、 それぞれのドキュメントを文字の塊に分割することだ。
04:41.080 --> 04:44.320
その際、 ラングチェーンには2つのことを指定する。
04:44.350 --> 04:50.860
ひとつはチャンクサイズで、 各チャンクにだいたい何文字入れたいか。
04:51.220 --> 04:56.410
というのも、 ラングチェーンにある程度の裁量を与えて、 スペースと空白行、
04:56.410 --> 05:06.620
あるいはドキュメントの異なる部分の間にセクションがあるような、 賢明な境界でこれらのチャンクを分割するようにするつもりだからだ。
05:06.620 --> 05:10.460
だから、 段落の途中や単語の途中などでカットすることはない。
05:10.460 --> 05:11.780
それでは意味がない。
05:11.930 --> 05:17.870
その結果、 LMに提供するコンタクトが悪くなる可能性がある。
05:18.740 --> 05:28.160
チャンクオーバーラップとは、 それぞれのキャラクターが完全に分離していることを望まないということだ。
05:28.160 --> 05:30.710
両者の間にある程度の重なりを持たせたい。
05:30.710 --> 05:35.240
つまり、 2つのチャンクに共通するドキュメントの内容があるわけだ。
05:35.390 --> 05:44.090
つまり、 クエリを入れると、 そのクエリに関連するチャンクの束が抽出される可能性が高くなる。
05:44.120 --> 05:49.550
私たちは、 何かの連想や批判的な言葉のためにリスクを冒したくない。
05:49.550 --> 05:55.340
そして、 あるチャンクにだけ含まれ、 そのチャンクに本当に近い別のチャンクは含まれない。
05:55.340 --> 05:56.630
それも同様に重要だ。
05:56.630 --> 06:04.380
チャンクのオーバーラップによって、 同じキーワードを含む複数のチャンクを持つことができる。
06:05.220 --> 06:07.980
これがテキスト・スプリッターだ。
06:07.980 --> 06:11.100
そして、 ドキュメントを分割し、 ドキュメントを渡す。
06:11.100 --> 06:14.730
そして、 私がそれを実行すれば、 それは実行されることになる。
06:14.730 --> 06:24.150
そして、 作成されたチャンクのひとつが、 サイズが1088であることを警告してきた。
06:24.150 --> 06:28.710
そしてまた、 それは境界線をどのように尊重するかをスマートにしようとしているからだ。
06:28.740 --> 06:32.730
それで、 このような決断を下したんだ。
06:32.730 --> 06:42.270
それで、 最終的にいくつのチャンクができたかというと、 31のドキュメントから123のチャンクができた。
06:42.270 --> 06:48.240
そして今できることは、 チャンクを選ぶこと、 つまり5番のチャンクを選んで、 そのチャンクを見てみることだ。
06:48.450 --> 06:53.070
ドキュメントにメタデータがあるように、 チャンク自体にもメタデータがあるんだ。
06:53.340 --> 06:55.890
ええと、 そのソースがどこから来たかを知っている。
06:56.100 --> 06:59.520
そして、 docタイプ、 我々が設定したdocタイプを持っている。
06:59.650 --> 06:59.830
アップ。
06:59.830 --> 07:04.240
だから私たちは、 この特定の塊が製品から抜き取られたものだと知っている。
07:04.480 --> 07:09.490
ええと、 実際、 マルカムについての商品概要なんだ。
07:09.490 --> 07:15.400
新しいセクションで始まり、 そのセクションの終わりで終わっているのがわかるだろう。
07:15.580 --> 07:18.100
だから、 境界線を尊重するように注意してきた。
07:18.100 --> 07:21.460
1000文字程度の手頃な塊がある。
07:21.610 --> 07:25.630
そして、 その直前のチャンクと重なる部分もあるだろう。
07:25.960 --> 07:28.090
ええと、 そうすることを選んだかどうか見てみよう。
07:29.470 --> 07:32.530
この場合、 その前のチャンクは非常に小さなチャンクだからだ。
07:32.710 --> 07:39.820
とにかく、 チャンク間で重複がある場合、 それが可能なオプションの例を見つけられるかどうか、
07:39.820 --> 07:46.510
試してみてください。
07:46.660 --> 07:51.910
それで、 このチャンクのいくつかを使って実験してみるんだ。
07:51.910 --> 07:57.100
つのチャンクに同じ情報が含まれている例を探してみてください。
07:58.330 --> 08:09.260
だから、 これからすることは、 これらのチャンク全体のDoctypeメタデータを検査し、 すべての正しいdocタイプがあることを確信することだ。
08:09.260 --> 08:13.490
では、 すべてのチャンクで何があるか見てみよう。
08:13.490 --> 08:18.230
私たちには、 従業員、 契約、 会社、 製品の4つのドキュメント・タイプがあります。
08:18.230 --> 08:24.830
というのも、 これはもちろん、 我々が読み込んだ4つのディレクトリと完全に一致するからだ。
08:24.830 --> 08:26.900
それですべて良さそうだ。
08:27.440 --> 08:35.150
では、 それぞれのチャンクを見てみよう。
08:35.150 --> 08:38.540
ランカスターという単語が含まれているチャンクは?
08:38.570 --> 08:39.590
ランカスター
08:39.620 --> 08:46.070
これが架空の会社の架空のCEOの架空の名前なのだから。
08:46.070 --> 08:49.250
ランカスターは彼女の名字なんだね。
08:49.250 --> 08:52.580
そして、 どの塊に彼女の名字が入っているか見てみよう。
08:52.580 --> 08:53.600
それでは、 どうぞ。
08:53.840 --> 09:03.100
保険についての書類には、 もちろん彼女の名前があった。
09:03.490 --> 09:10.210
それから、 彼女の人事記録にはランカスターが載っていて、 私たちの人事記録の一番下にも載っている。
09:10.210 --> 09:16.660
また、 他の人事のメモにも、 彼女のことが、 ええと、 苗字で書かれている。
09:17.110 --> 09:28.930
それで、 おそらく皆さんもお気づきだと思いますが、 前回やった安くて陽気なバージョンのラグからすると、 大きな問題のひとつはランカスターという単語を探すだけだということです。
09:28.930 --> 09:39.100
だから、 最悪のランカスターに反映されていないCEOに関する情報があれば、 それは前回のおもちゃのバージョンでは見逃されることになる。
09:39.100 --> 09:49.360
彼女のファーストネームであるエイブリーを検索すると、 より多くのチャンクがヒットすることがわかるだろう。
09:49.630 --> 09:51.760
うーん、 それで、 そうだね。
09:51.790 --> 09:58.120
そしておそらく、 CEOとした場合、 ランカスターという単語が含まれるものだけを見ていたのでは見逃される可能性のある、
09:58.240 --> 10:07.460
CEOが含まれるチャンクもたくさんあることがわかる。
10:07.520 --> 10:13.850
つまり、 ドキュメントをテキストベースで検索するのは、
10:13.850 --> 10:18.410
あまりいい方法ではないということだ。
10:18.440 --> 10:25.250
私たちがベクター検索に求めているのは、 テキストだけでなく、 探しているものの背後にある意味を理解した上で、
10:25.250 --> 10:32.690
関連性のあるチャンクを見つける方法をよりスマートにできるものです。
10:32.720 --> 10:35.870
そしてもちろん、 それがラグの背後にある大きなアイデアなのだ。
10:35.900 --> 10:45.710
この時点で、 テキスト・ローダーやディレクトリ・ローダーを使って文書を読み込み、 チャンクに分割することに慣れていることを願う。
10:45.710 --> 10:50.780
そして、 この練習をすることで、 さまざまなチャンクと戯れるようになり、 理にかなった場所で分割されていること、
10:50.780 --> 10:54.440
重なり合う部分があることを自分自身に納得させることができる。
10:54.440 --> 10:59.240
そして、 ベクター化してベクターデータベースに入れる準備が整う。