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