From the uDemy course on LLM engineering.
https://www.udemy.com/course/llm-engineering-master-ai-and-large-language-models
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
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 |
|
そして、 ベクター化してベクターデータベースに入れる準備が整う。
|
|
|