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 そして、 ベクター化してベクターデータベースに入れる準備が整う。