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.
 
 

460 lines
15 KiB

WEBVTT
00:01.310 --> 00:03.650
そして5日目へようこそ。
00:03.680 --> 00:04.490
本当だよ。
00:04.490 --> 00:06.680
我々は実際に適切なJupyterノートブックにいる。
00:06.710 --> 00:11.060
今回は5日目、 5週目に突入した。
00:11.060 --> 00:13.610
そして、 それは以前と同じだ。
00:13.940 --> 00:16.580
4日半ではなく、 4日目と重複している。
00:16.580 --> 00:24.560
ここではChromaデータストアを使用しています。 すでにご存知のことばかりなので、 本当に手短に説明します。
00:24.560 --> 00:31.160
そしてGradioのインターフェイスに戻る。
00:31.160 --> 00:31.970
ただそれだけだ。
00:31.970 --> 00:33.110
追いつかれた。
00:33.230 --> 00:33.890
描かれている。
00:33.890 --> 00:36.080
舞台裏の2Dと3Dのダイアグラムだ。
00:36.080 --> 00:37.130
しかし、 そんな時間はない。
00:37.130 --> 00:37.490
今すぐだ。
00:37.490 --> 00:38.840
我々は前進する必要がある。
00:39.200 --> 00:46.550
ええと、 まず最初に、 前にやった鳥小屋のテストがクロマでもバイスと同じように機能することをお見せしましょう。
00:46.550 --> 00:49.190
では、 早速試してみよう。
00:49.400 --> 00:56.750
あのー、 aviaryのスペルミスって、 確保する前は何をしていたんですか?
00:57.320 --> 01:00.350
そして、 私は想像している。
01:00.350 --> 01:01.130
今にわかるよ。
01:01.160 --> 01:01.820
そうだ。
01:01.820 --> 01:06.280
そのクロマも何の問題もない。
01:06.310 --> 01:07.810
驚きはない。
01:07.840 --> 01:11.980
よし、 しかし、 今度はそううまくはいかないものをお見せしよう。
01:11.980 --> 01:16.360
まず、 従業員の人事文書を覗いてみたい。
01:16.390 --> 01:25.360
ナレッジ・ベースに入り、 従業員のところに行くと、 あるマキシン・トンプソンの従業員記録を見ることになる。
01:25.390 --> 01:27.610
マークダウンで開いてみよう。
01:27.610 --> 01:30.010
というわけで、 値下げされた栄光の姿をご覧いただこう。
01:30.040 --> 01:35.830
テキサス州オースティンのデータ・エンジニア、 マキシン・トンプソンの人事記録だ。
01:35.830 --> 01:47.860
そして、 ちょっと注目していただきたいのは、 この下を見ていただくと、 マキシンが2023年のエンシュア・エルム・イノベーター・オブ・ザ・イヤーに認定されていることです。
01:47.890 --> 01:56.410
2023年には名誉あるI o T Award in Elm Innovator of the yearを受賞。
01:56.440 --> 01:59.110
さて、 正直に告白すると、 私はこの一文を自分で付け加えた。
01:59.110 --> 02:06.760
これは、 GPT4やクロードが合成データの一部として発明したようなものではなかった。
02:07.090 --> 02:08.620
これはすべて私がやったことだ。
02:08.830 --> 02:09.640
そして、 ひどいものだ。
02:09.640 --> 02:11.500
だから私を責めなさい。
02:11.830 --> 02:21.580
では、 5日目に戻って、 誰が勝ったのか?
02:24.400 --> 02:36.820
2023年に名誉あるシュリーラム・イノベーター・オブ・ザ・イヤーを受賞したのは誰だったかな?
02:36.850 --> 02:38.740
その内容を見てみよう。
02:40.570 --> 02:42.160
わからないと書いてある。
02:42.190 --> 02:43.510
しかも、 かなりぶっきらぼうに。
02:43.540 --> 02:44.710
かなり素っ気ない。
02:44.770 --> 02:46.420
それは興味深いね。
02:46.450 --> 02:47.530
失敗したんだ。
02:47.530 --> 02:49.330
それが提供された情報だった。
02:49.330 --> 02:51.370
文書にもあった。
02:51.370 --> 02:52.900
それは少し残念だ。
02:52.900 --> 02:56.290
だから今すべきことは、 この問題を診断することだ。
02:56.290 --> 03:00.520
そうすることで、 ラング・チェインがボンネットの中でどのように機能するのかを少し学ぶことになる。
03:00.700 --> 03:02.950
そして、 それはあまり驚くべきことではないだろう。
03:03.370 --> 03:06.310
それで、 ここで何が起こっているのか見てみよう。
03:06.370 --> 03:11.850
標準出力コールバックハンドラーと呼ばれるものを作れば、
03:11.850 --> 03:19.590
舞台裏で起こっていることを標準出力に出力することができる。
03:19.620 --> 03:22.710
つまり、 これは皆さんが慣れ親しんでいるコードと同じなのだ。
03:22.740 --> 03:24.000
私たちは警報を発する。
03:24.090 --> 03:25.530
私たちは思い出を作る。
03:25.560 --> 03:35.850
私たちはレトリーバーを作り、 LM、 レトリーバー、 思い出の中ですれ違うこの美しいワンライナーで会話の連鎖を作る。
03:35.850 --> 03:40.410
コールバックのリストだ。
03:40.410 --> 03:46.560
ここではコールバックをひとつだけ作っている。
03:46.560 --> 03:55.710
そして、 この会話の連鎖が続くにつれ、 おそらく、 あー、 予想できるように、 標準的なものが何度も印刷されることになるだろう。
03:55.800 --> 03:58.650
では、 誰が勝ったのか?
03:58.680 --> 03:59.460
私は別の言い方をした。
03:59.730 --> 04:00.540
同じようにやろう。
04:00.570 --> 04:07.020
2023年に栄えあるIet賞を受賞したのは?
04:07.050 --> 04:07.770
これでよし。
04:07.800 --> 04:09.030
その質問をしよう。
04:09.030 --> 04:10.110
答えは後ほど。
04:10.110 --> 04:11.930
何が書いてあるか見てみよう
04:12.770 --> 04:19.010
つまり、 ラング・チェインがどのように機能しているのか、 その一端を知ることができるのだ。
04:19.010 --> 04:21.170
これにはさまざまなオブジェクトがある。
04:21.170 --> 04:30.440
これらは、 会話やラグ・クエリーを構築する段階を経るにつれて、 ある種のチェーンと呼ばれるものだ。
04:30.440 --> 04:36.590
また、 各ステージで何が起こっているのか、 より詳細に表示するために、 さまざまなコールバックを使用することもできる。
04:36.590 --> 04:41.600
しかし、 私たちが本当に気にしているのは、 GPT4に行くことになるプロンプトだ。
04:41.600 --> 04:43.040
そしてここにある。
04:43.040 --> 04:44.090
システム。
04:44.090 --> 04:47.330
ユーザーの質問に答えるには、 次のような文脈を利用する。
04:47.330 --> 04:50.300
答えがわからなければ、 わからないと言えばいい。
04:50.300 --> 04:52.220
答えを作ろうとするな。
04:52.250 --> 04:57.200
このプロンプトは、 ラング・チェーンのスペシャリストたちが、 専門家のように、
04:57.230 --> 05:02.090
さまざまなLLMに送る理想的なプロンプトとして作り上げたものだからだ。
05:02.090 --> 05:06.020
だから、 これは盗んで自分のプロジェクトに使うのに最適なものなんだ。
05:06.020 --> 05:07.730
とても丁寧に書かれている。
05:07.730 --> 05:13.250
GPT4の幻覚を止めたのだから、 非常に効果的なのは明らかだ。
05:13.370 --> 05:16.670
うーん、 それにしても、 よくできた促し文句だね。
05:17.390 --> 05:18.710
しかし、 問題はここからだ。
05:18.710 --> 05:25.520
これが、 これから登場するLMに提供された文脈である。
05:25.520 --> 05:30.740
そして、 実際には、 私たちが持っているさまざまなチャンクから取り出したいくつかのチャンクであることがわかるだろう。
05:30.770 --> 05:36.200
2つか3つの塊で、 HRの記録から取られたようだ。
05:36.410 --> 05:38.180
でも、 彼らは正しくない。
05:38.180 --> 05:42.140
なぜなら、 彼らはI o t賞について触れていないからだ。
05:42.140 --> 05:47.060
つまり、 このケースでは残念ながら間違ったチャンクが特定されてしまったのだ。
05:47.300 --> 05:51.230
うーん、 そして最後にこれが問題なんだ。
05:51.230 --> 05:55.400
栄えあるI o t賞を受賞したのは人間である。
05:55.730 --> 05:56.780
私は人間だ。
05:56.780 --> 06:03.320
その質問に答えるには、 明らかに文脈が足りなかった。
06:03.320 --> 06:07.160
だから、 その反応は "わからない "というものだった。
06:07.850 --> 06:10.370
では、 どうすればいいのか?
06:10.370 --> 06:15.590
正しい文脈を提供できていないというのは、 ラグではよくある問題なんだ。
06:15.590 --> 06:17.440
できることはいくつかある。
06:17.680 --> 06:22.420
そのひとつは、 チャンキング戦略を見直すことだ。
06:22.540 --> 06:25.270
どのように文書をチャンクに分けていますか?
06:25.270 --> 06:26.050
そうしているのか?
06:26.050 --> 06:26.500
そうだね。
06:26.500 --> 06:28.780
そして、 すぐにでも試せることがいくつかある。
06:28.810 --> 06:34.300
そのひとつは、 チャンキングの代わりに、 ドキュメント全体をコンテキストとして送ることだ。
06:34.300 --> 06:40.480
だから、 クロマーにフルドキュメントを入れて、 一番近いドキュメントを探すんだ。
06:40.510 --> 06:46.930
もっと細かく、 もっと小さな塊にすることもできる。
06:47.140 --> 06:52.960
チャンク間のオーバーラップを調査して、 オーバーラップを増やすか減らすかを確認することもできる。
06:52.960 --> 06:57.490
この場合、 有用なチャンクを提供できる可能性が高くなる。
06:57.490 --> 07:06.160
つまり、 チャンキング戦略をうまく機能させ、 適切なコンテキストを提供するためには、 これらのことを調査する必要があるのだ。
07:06.190 --> 07:07.420
もうひとつある。
07:07.420 --> 07:08.230
そして、 それはとてもシンプルだ。
07:08.230 --> 07:09.910
そしてそれが、 今回のケースで我々がやろうとしていることだ。
07:10.090 --> 07:15.850
そしてそれは、 チャンクの数、 つまり実際に送信されるコンテキストの量をコントロールすることだ。
07:16.090 --> 07:21.390
この場合、 実際には3つのチャンクを送信しているのですが、
07:21.390 --> 07:28.650
送信されるチャンクの数をコントロールすることができます。
07:28.650 --> 07:38.040
retrieverとしてretrieverベクターストアを作成する際、 実際にいくつのチャンクを返して欲しいか、 渡して欲しいかを指定することができる。
07:38.040 --> 07:44.340
そして今回のケースでは、 25個のチャンクを作成し、 渡すことを指定した。
07:44.370 --> 07:49.470
一般的な経験則として、 LLMに多くの文脈を送るのは良い考えだ。
07:49.500 --> 07:56.730
LLMSは、 つまり、 関連する文脈だけに焦点を当て、 無関係な文脈を無視することに長けている。
07:56.730 --> 07:59.670
だから、 チャンクをたくさん送るのは良い習慣だ。
07:59.670 --> 08:03.810
そうしない方がいい状況もたまにある。
08:03.840 --> 08:10.260
例えば、 オープンAIが提供している最新のモデルのひとつに、 プロンプトをより詳細に見て、
08:10.260 --> 08:17.970
それを本当に理解するために舞台裏でさらに分析を行うモデルがある。
08:17.970 --> 08:20.070
思考の連鎖のようなものだ。
08:20.250 --> 08:28.230
ええと、 そこで推奨されているのは、 無関係なコンテクストをたくさん提供しないことです。
08:28.230 --> 08:35.040
しかし、 そのような時折の例を横に置いて、 一般的な経験則から言えば、 より多くの文脈を持つことは一般的に良いことである。
08:35.490 --> 08:43.260
この場合、 2つか3つの最も近いチャンクを提供するよりも、 25の最も近いチャンクを提供することにそれほど大きな問題はない。
08:43.260 --> 08:45.900
全部で123のチャンクがある。
08:45.900 --> 08:48.810
つまり、 これはまだ全データの5分の1程度なのだ。
08:48.810 --> 08:51.210
だから、 全データを出荷するわけではない。
08:51.240 --> 08:58.680
私たちは、 LLMに送るために、 最も関連性の高い25のチャンク、 つまり私たちのコンテンツの最も関連性の高い5分の1を選んでいる。
08:58.680 --> 09:00.360
では、 これがうまくいくかどうか見てみよう。
09:00.360 --> 09:02.010
だから、 これを実行する。
09:02.010 --> 09:07.530
そして前回同様、 いつものGradioのインターフェイスを表示させる。
09:07.530 --> 09:15.540
そしてすぐに、 誰が優勝したのか......申し訳ないのですが、 誰が優勝したのか......。
09:15.570 --> 09:16.860
だから一貫性を保っている。
09:16.890 --> 09:26.960
2023年に名誉あるI t y 賞を受賞した。
09:26.990 --> 09:27.950
見てみよう。
09:27.980 --> 09:29.240
ドラムロールをお願いします。
09:29.270 --> 09:30.230
マキシン
09:30.260 --> 09:35.300
マキシンは名誉あるI o t 2023賞を受賞した。
09:35.300 --> 09:40.730
つまり、 LMにチャンクを増やすことで問題は解決したのだ。
09:40.940 --> 09:46.370
ということで、 あなたへの練習は、 もう一度戻って、 このことを実験してみることだ。
09:46.370 --> 09:47.960
難しい質問に挑戦してみよう。
09:47.960 --> 09:51.140
自分で文書にいくつか挿入して、 何が起こるか見てみるのもいい。
09:51.350 --> 09:54.440
そして、 いろいろなチャンキング戦略を試してみる。
09:54.440 --> 10:01.370
文書全体を試したり、 100文字程度の小さなチャンクで、 重なりを多くしたり少なくしたりして、
10:01.370 --> 10:09.140
それが結果の質にどのように影響するか、 またどのように文脈を与えすぎるかについて、 良い感触を得る。
10:09.170 --> 10:11.780
文脈を提供しすぎることの影響もわかるかもしれない。
10:11.810 --> 10:14.540
そのせいで、 回答の精度が落ちるのかもしれない。
10:14.540 --> 10:24.830
だから実験して、 良いことも悪いこともよく理解し、 最も効果的なやり方についてコツをつかむのだ。
10:24.830 --> 10:28.010
それではまた、 次のビデオでお会いしましょう。