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.
313 lines
12 KiB
313 lines
12 KiB
WEBVTT |
|
|
|
00:00.740 --> 00:08.330 |
|
そして今、 ラグの最も重要な側面であるベクトルについて話す時が来た。 |
|
|
|
00:08.360 --> 00:11.750 |
|
すでにベクトルやベクトル埋め込みに馴染みのある方は、 そのままお待ちください。 |
|
|
|
00:11.750 --> 00:13.610 |
|
かなり手短に説明しよう。 |
|
|
|
00:13.610 --> 00:17.570 |
|
こうして説明するうちに、 知らなかったことが出てくるかもしれない。 |
|
|
|
00:17.570 --> 00:21.290 |
|
まず最初に、 重要な予備知識として、 このコースでは様々なLMSについてお話してきましたが、 |
|
|
|
00:21.290 --> 00:30.380 |
|
これまでお話してきたLMSのほとんどは、 自己回帰LMと呼ばれるLMの一種です。 |
|
|
|
00:30.380 --> 00:35.300 |
|
そして、 オートエンコーディングと呼ばれる全く異なるカテゴリーのLMも存在する。 |
|
|
|
00:35.300 --> 00:36.500 |
|
では、 何が違うのか? |
|
|
|
00:36.530 --> 00:49.070 |
|
自己回帰型LMS(Autoregressive LMS)またはLMSは、 過去のトークンのセットが与えられ、 過去のトークンが与えられたときに、 シーケンス内の次のトークン(未来のトークン)を生成することが要求される。 |
|
|
|
00:49.070 --> 00:52.400 |
|
そして、 次のトークンを作ることを繰り返す。 |
|
|
|
00:52.400 --> 00:56.300 |
|
トークンの歴史を考えれば、 これは自己回帰的なLMだ。 |
|
|
|
00:56.300 --> 00:58.100 |
|
そしてもちろん、 大流行している。 |
|
|
|
00:58.100 --> 01:00.710 |
|
一緒に仕事をしているほとんどの人がそうだ。 |
|
|
|
01:00.710 --> 01:04.270 |
|
もちろん、 GPT4やクロード、 ジェミニなどもある。 |
|
|
|
01:04.690 --> 01:12.700 |
|
オートエンコーディングと呼ばれるタイプもあり、 過去と現在と未来の両方を表す完全な入力を受け取る。 |
|
|
|
01:12.700 --> 01:18.670 |
|
フルビットの入力で、 入力全体を反映した1つの出力を作り出すのだ。 |
|
|
|
01:19.090 --> 01:22.120 |
|
そして、 それを現実のものとするために、 いくつかの明白な例がある。 |
|
|
|
01:22.120 --> 01:26.620 |
|
センチメント分析では、 文章を取り込んで、 それが肯定的か否定的かを判断する。 |
|
|
|
01:26.770 --> 01:30.940 |
|
文章をバケツに入れる分類。 |
|
|
|
01:31.420 --> 01:36.790 |
|
どちらも、 数週間前にハギングフェイス・パイプラインについて少し検討したものだ。 |
|
|
|
01:36.850 --> 01:40.360 |
|
そして、 これらはどちらもオートエンコードllmsの例である。 |
|
|
|
01:41.260 --> 01:46.300 |
|
ベクトル埋め込みと呼ばれるものを作るためだ。 |
|
|
|
01:46.300 --> 01:48.700 |
|
それが、 今日お話しすることです。 |
|
|
|
01:48.730 --> 01:55.570 |
|
つまり、 ベクトル埋め込みとは、 テキストの一文、 あるいはさまざまなものを取り込む方法だが、 通常はテキストの一文である。 |
|
|
|
01:55.570 --> 02:04.360 |
|
そして、 そのテキストに隠された意味を何らかの形で反映させた一連の数字に変える。 |
|
|
|
02:04.360 --> 02:07.000 |
|
それが何を意味するのか、 すぐに説明しよう。 |
|
|
|
02:07.000 --> 02:17.960 |
|
今は少し抽象的に聞こえるが、 テキストを数字に変換し、 その数字が空間上の点を表していると考えることができるというものだ。 |
|
|
|
02:17.960 --> 02:22.670 |
|
つまり、 テキストを3つの数字に置き換えると、 X、 Y、 Zのようなもので、 |
|
|
|
02:22.670 --> 02:28.190 |
|
何かが空間のどこにあるかを正確に表していると考えることができる。 |
|
|
|
02:28.370 --> 02:33.800 |
|
そうすると、 通常は何百、 何千という数字に変換されてしまう。 |
|
|
|
02:33.800 --> 02:37.760 |
|
つまり、 1000次元の空間の一点を表しているのだ。 |
|
|
|
02:37.760 --> 02:41.690 |
|
私たちは3次元でしか考えることができないから、 それをイメージするのは難しいけど、 |
|
|
|
02:41.690 --> 02:42.620 |
|
同じ考えなんだ。 |
|
|
|
02:42.620 --> 02:55.250 |
|
その点は、 自動エンコーディングの例である、 生成に使われたテキストの背後にある意味を何らかの形で表すことを意味している。 |
|
|
|
02:55.280 --> 02:58.640 |
|
LlmsはGoogleのバート。 |
|
|
|
02:58.670 --> 03:02.540 |
|
バートについては、 最初の週に話したと思う。 |
|
|
|
03:02.570 --> 03:05.240 |
|
ええと、 だからバートはしばらく前からいるんだ。 |
|
|
|
03:05.390 --> 03:14.680 |
|
OpenAIが提供するオープンAIエンベッディングもありますし、 今週ラグ・プロジェクトで使用するオートエンコーダー・モデルもこれです。 |
|
|
|
03:15.160 --> 03:19.960 |
|
では、 私たちが意味するところについて、 もう少しお話しさせてください。 |
|
|
|
03:19.990 --> 03:28.690 |
|
まず第一に、 1文字、 1トークン、 1文字の束、 1単語、 1文、 1段落、 文書全体、 あるいは抽象的なものに対して、 |
|
|
|
03:28.930 --> 03:36.490 |
|
これらのベクトルを作成することができます。 |
|
|
|
03:36.490 --> 03:44.020 |
|
私の会社、 ネビュラでもそうですが、 私たちは人材や仕事などのベクトルを作っています。 |
|
|
|
03:44.680 --> 03:54.700 |
|
ベクトルを扱う場合、 数百から数千の次元を持つことがよくあり、 1つのテキストブロックを表す1000個の数字のようなものだ。 |
|
|
|
03:55.030 --> 04:01.420 |
|
そして今、 私は何度か、 これらの数字はインプットの背後にある意味を反映していると言ってきた。 |
|
|
|
04:01.420 --> 04:03.010 |
|
それは一体どういう意味なのか? |
|
|
|
04:03.040 --> 04:10.060 |
|
つまり、 簡単に言うと、 テキストの段落がたくさんあり、 それらがすべて、 空間内の互いに近い同じような点にマッピングされる、 |
|
|
|
04:10.060 --> 04:14.720 |
|
ということだ。 |
|
|
|
04:14.720 --> 04:18.800 |
|
つまり、 これらのテキストブロックは似たような意味を持つということだ。 |
|
|
|
04:18.800 --> 04:21.500 |
|
必ずしも同じ言葉が含まれている必要はない。 |
|
|
|
04:21.500 --> 04:25.790 |
|
まったく違う言葉かもしれないが、 意味は同じだ。 |
|
|
|
04:25.790 --> 04:35.540 |
|
ベクトル空間では互いに近接しているはずだから、 数字にしたときに近接するものは似たような意味になるはずだ。 |
|
|
|
04:35.540 --> 04:38.630 |
|
そして、 これが基本的な考え方だ。 |
|
|
|
04:38.630 --> 04:49.400 |
|
この背景には、 より洗練されたアイデアもあり、 これらの意味の裏側でベクトル数学と呼ばれるものができることもある。 |
|
|
|
04:49.400 --> 04:54.050 |
|
そして、 昔からよく言われるこの例がある。 |
|
|
|
04:54.050 --> 05:07.880 |
|
王様という単語があると仮定して、 王様という単語を表す空間上の点を見つけるためにベクトルエンコーディングを使ったとする。 |
|
|
|
05:07.910 --> 05:11.990 |
|
そして、 "man "という言葉を反映したベクトルも見つけることができる。 |
|
|
|
05:11.990 --> 05:14.510 |
|
そして、 女性という言葉を映し出すベクトル。 |
|
|
|
05:14.600 --> 05:21.790 |
|
王という言葉から男を引くと、 男の方向へ後退することになり、 |
|
|
|
05:21.790 --> 05:28.750 |
|
女を足すと、 女の方向へ前進することになる。 |
|
|
|
05:29.110 --> 05:41.470 |
|
あなたが効果的に行ったことは、 王の概念、 王の意味を取り上げて、 この王の意味において男を女に置き換えたいと言ったことだ。 |
|
|
|
05:41.470 --> 05:53.890 |
|
そして少々驚くべきことに、 これを実行すると、 実際にベクトル空間の位置に行き着く。 |
|
|
|
05:53.920 --> 06:00.220 |
|
つまり、 王という言葉の意味を男性から女性に置き換えると、 |
|
|
|
06:00.220 --> 06:06.850 |
|
女王という言葉の意味を反映したものになるようだ。 |
|
|
|
06:06.850 --> 06:13.780 |
|
その意味で、 ベクトルは、 似たような単語が近接しているという意味でも、 概念間の関係を理解するためのベクトル計算の能力という意味でも、 |
|
|
|
06:13.780 --> 06:26.420 |
|
そのベクトルが表す単語の背後にある意味を如実に反映しているように見えるのだ。 |
|
|
|
06:27.860 --> 06:30.860 |
|
ボロ雑巾との関係は? |
|
|
|
06:30.950 --> 06:32.930 |
|
ここにすべてが集約される。 |
|
|
|
06:32.930 --> 06:35.510 |
|
これが今のラグの大きな考え方だ。 |
|
|
|
06:35.540 --> 06:38.570 |
|
これは以前と同じ図だ。 |
|
|
|
06:38.570 --> 06:40.550 |
|
でも、 もう少し続くよ。 |
|
|
|
06:40.850 --> 06:43.970 |
|
一番上にエンコーディングLMという新しいボックスがある。 |
|
|
|
06:44.000 --> 06:48.650 |
|
これはテキストをベクターに変換できるものだ。 |
|
|
|
06:48.650 --> 06:52.070 |
|
そして一番下にはベクター・データ・ストアと呼ばれるものがある。 |
|
|
|
06:52.100 --> 06:55.250 |
|
ナレッジ・ベースの前にあったデータ・ストアのようなものだ。 |
|
|
|
06:55.250 --> 07:05.750 |
|
しかし今は、 テキストと一緒に、 そのテキストを表すベクトル、 そのテキストの意味を表すベクトルも保存できる。 |
|
|
|
07:06.260 --> 07:07.130 |
|
分かった。 |
|
|
|
07:07.130 --> 07:08.990 |
|
だから、 こうするんだ。 |
|
|
|
07:09.080 --> 07:12.260 |
|
ユーザーからの質問である。 |
|
|
|
07:12.290 --> 07:19.550 |
|
最初にすることは、 その質問をベクトル化することだ。 |
|
|
|
07:19.550 --> 07:22.360 |
|
では、 仮にエイミー・ミーとは誰かという質問があったとしよう。 |
|
|
|
07:22.360 --> 07:23.260 |
|
ランカスター |
|
|
|
07:23.260 --> 07:31.870 |
|
エイミー・ランカスターとは誰かという問いの意味を反映するベクトルに変える。 |
|
|
|
07:33.100 --> 07:34.990 |
|
私が次に何を言おうとしているか、 想像がつくだろう。 |
|
|
|
07:35.020 --> 07:49.180 |
|
このベクターデータベースの中で、 エイミー・ランカスターという人物のベクターに近いベクターは何か教えてください。 |
|
|
|
07:49.180 --> 07:51.760 |
|
だから、 そこにあるさまざまな文書を見てほしい。 |
|
|
|
07:51.760 --> 07:53.530 |
|
我々はそれらをすべてベクトルに変えた。 |
|
|
|
07:53.530 --> 07:58.000 |
|
エイミー・ランカスターとは誰か? |
|
|
|
07:58.030 --> 08:04.630 |
|
そのベクターを渡し、 そのベクターに変換された元の情報、 テキストを渡す。 |
|
|
|
08:04.630 --> 08:15.910 |
|
そしておそらく、 エイミー・ランカスターの実際の航空文書が、 エイミー・ランカスターとは誰かというベクトルに近い場所にある可能性が極めて高い。 |
|
|
|
08:16.810 --> 08:20.860 |
|
だから、 その情報を得たら、 単純にその文章を受け取る。 |
|
|
|
08:20.860 --> 08:29.870 |
|
さっきのおもちゃの例と同じように、 LLMにプロンプトを送ると、 おそらく余分な文脈を利用したレスポンスが返ってくる。 |
|
|
|
08:29.870 --> 08:32.210 |
|
そしてそれがユーザーに還元される。 |
|
|
|
08:32.300 --> 08:38.600 |
|
つまり、 おもちゃの例と同じように、 関連するデータを調べるために、 より強力なテクニックを使っているということだ。 |
|
|
|
08:38.600 --> 08:49.010 |
|
質問の意味と最も似た意味を持つ知識を理解する方法として、 ベクトルを使っている。 |
|
|
|
08:49.010 --> 08:51.410 |
|
まあ、 本当にそれだけだ。 |
|
|
|
08:51.410 --> 08:58.910 |
|
というのも、 次回はこれを実践して、 実際にデータベースでベクトルを見ることになるからだ。 |
|
|
|
08:58.940 --> 09:08.780 |
|
また次回は、 この種のアプリケーションを簡単に構築できるように設計された、 素晴らしい素晴らしいフレームワークであるラング・チェインというものを見ていくつもりだ。 |
|
|
|
09:08.780 --> 09:10.550 |
|
すべてマニュアル通りにやればいいんだ。 |
|
|
|
09:10.550 --> 09:15.860 |
|
実際にベクターを作成し、 さまざまなAPIを使ってベクターデータベースに保存することができる。 |
|
|
|
09:16.160 --> 09:19.610 |
|
しかし、 ラング・チェインでは、 ご覧のように超シンプルに仕上げている。 |
|
|
|
09:19.640 --> 09:26.450 |
|
ほんの数行のコードで非常にパワフルなことができるようになる。 |
|
|
|
09:26.450 --> 09:28.160 |
|
だから興奮しているんだ。 |
|
|
|
09:28.160 --> 09:29.090 |
|
君もそうだといいね。 |
|
|
|
09:29.090 --> 09:30.260 |
|
その時にまた会おう
|
|
|