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 その時にまた会おう