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 それではまた、 次のビデオでお会いしましょう。