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.
 
 

358 lines
12 KiB

WEBVTT
00:00.800 --> 00:02.300
だから、 あなたが何を考えているかは分かる。
00:02.300 --> 00:03.800
何が起こっているんだ?
00:03.830 --> 00:05.000
もう5日目だ。
00:05.030 --> 00:06.740
週目の5日目だ。
00:06.770 --> 00:08.840
なぜ彼はJupyterノートブックを開いているのか?
00:08.840 --> 00:10.730
それが4日目だ。 5.
00:10.730 --> 00:21.110
ベクター・データ・ストアを別のものに変更するのがいかに簡単かを純粋に知ってもらうために、 4日目にはちょっとした逸脱があるからだ。
00:21.110 --> 00:34.310
また、 このような抽象化されたデータ・ストアで作業することがいかに簡単であるかをお見せすることもできます。
00:34.340 --> 00:39.140
さて、 説明しておかなければならないのは、 これは本当のベクトル・データ・ストアではないということだ。
00:39.140 --> 00:47.810
Facebook AI Similarity Searchの略で、 Facebookが公開しているオープンソースのライブラリで、
00:47.840 --> 00:58.370
他のベクトルに近いベクトルを素早く検索することができる。
00:58.370 --> 01:09.230
Langshanは適切な抽象化機能を備えているので、
01:09.230 --> 01:19.220
chromaの代わりに使うことができます。
01:19.220 --> 01:22.310
そのため、 以前はクロマを使っていた。
01:22.310 --> 01:26.090
つまり、 より深刻なハードコアデータストアの悪癖なのだ。
01:26.510 --> 01:29.360
クロマの代わりにそれを使えばいい。
01:29.360 --> 01:37.610
抽象化と他のいくつかのことを除けば、 コードはほとんど同じになるからだ。
01:38.240 --> 01:42.110
そこで、 このインポートでは前回と同様にインポートを実行する。
01:42.110 --> 01:45.980
クロマのインポートをコメントアウトしているのがわかるだろう。
01:45.980 --> 01:52.160
Chromaはここには含まれず、 代わりにフェイスブックのAI類似性検索を取り込んでいる。
01:52.190 --> 01:59.930
注目すべきは、 フェイスにはCPUとGPUの2つのバリエーションがあることだ。
01:59.930 --> 02:04.490
そして、 この環境では、 もちろん、 PipはCPU版をインストールしていますが、 GPU上で動作する高性能プロジェクトでは、
02:04.490 --> 02:13.880
GPU版を実行することで、 猛烈なスピードで動作させることができるので、 バイスをインポートしましたが、 エラーはありませんでした。
02:14.150 --> 02:15.650
いくつかのことを準備する。
02:15.650 --> 02:17.300
これはすべて同じコードだ。
02:17.300 --> 02:19.220
以前と同じようにすべてを積み込む。
02:19.220 --> 02:25.970
うまくいけば、 123をレンチャンクに変更できるかもしれない。
02:25.970 --> 02:28.310
では、 123はあるのか?
02:28.340 --> 02:29.570
そうだ。
02:29.600 --> 02:31.700
正しいメタデータがあることを確認しよう。
02:31.700 --> 02:33.590
私たちには4つのタイプがある。
02:33.590 --> 02:35.840
今のところ何も変わっていない。
02:35.840 --> 02:36.980
これはすべて同じだ。
02:36.980 --> 02:38.000
しかし、 これを見てほしい。
02:38.000 --> 02:40.550
ここで一行、 狡猾に変更されている。
02:40.580 --> 02:44.060
ああ、 そこまで注意を引く必要はなかったよ。
02:44.060 --> 02:45.860
もうお気づきのことと思う。
02:45.860 --> 02:49.850
だから私たちは、 ベクターストアはドキュメントからのクロマ・ドットだと言っていた。
02:49.880 --> 02:53.720
そして、 チャンクの埋め込みとパーシスト・ディレクトリを渡した。
02:53.720 --> 02:58.580
そして今、 私たちは同じ構成からバイスドットと言っているだけだ。
02:58.610 --> 03:00.380
チャンクも渡す。
03:00.380 --> 03:01.970
また、 埋め込みも渡す。
03:01.970 --> 03:06.320
バイスはディスク上に残らないからだ。
03:06.620 --> 03:09.980
ええと、 この2本のラインも違う。
03:09.980 --> 03:14.750
そのため、 データストアに質問する下位レベルの方法は異なる。
03:14.750 --> 03:23.600
Feistを使うのであれば、 これを手元に置いておくと、 ベクトル数や次元数などのクエリーの仕方がわかって便利です。
03:23.630 --> 03:27.530
クロマでこれをやったとき、 いくつの次元があったか覚えているかどうかわからない。
03:27.650 --> 03:32.630
うーん、 でも、 ここで考えているのは同じ次元の数だよ。
03:32.630 --> 03:36.590
ベクトル化には同じOpenAIのエンベッディングを使っている。
03:36.590 --> 03:40.550
だから、 ベクターを作るために同じLLMを使っていることに変わりはない。
03:40.550 --> 03:45.620
変更されたのは、 これらのベクターをクロマではなくファイズに保存する方法だ。
03:46.130 --> 03:50.540
各チャンクに1つずつ、 計123のベクターがある。
03:50.540 --> 03:54.470
そして、 彼らはOpenAIから戻ってくる次元を持っている。
03:55.190 --> 04:01.370
もうひとつ変わったのは、 プレワークのセクションが4日目から変わったことだ。
04:01.400 --> 04:04.010
4日目のプレワークで思い出してほしい。
04:04.010 --> 04:05.660
それを見てみよう。
04:06.080 --> 04:07.850
ええと、 バ、 バ、 バ、 バ。
04:08.450 --> 04:15.890
クロマからベクター、 ドキュメント、 ドキュメントタイプを抜き出すだけです。
04:15.890 --> 04:19.970
そして、 このデータを得るためにクロマに問い合わせる方法を見ることができる。
04:20.170 --> 04:22.810
それで、 悪徳業者にはこうしたんだ。
04:22.840 --> 04:25.840
もっときっちりしたやり方があるかもしれないが、 これなら簡単そうだ。
04:25.840 --> 04:31.810
同じベクトル、 ドキュメント、 ドキュメントタイプ、 色を集めて、 それをPlotlyが期待する色にマッピングして、
04:31.990 --> 04:40.480
以前2Dでやったのと同じようにベクトルを視覚化できるように、 同じ図を描くだけです。
04:40.600 --> 04:44.290
このコードは1つの小さな例外を除いて同一である。
04:44.320 --> 04:45.670
見分けられるかな?
04:45.670 --> 04:47.290
それが唯一の変化だ。
04:47.290 --> 04:52.570
タイトルをクロマからバイスに変更しましたが、 それ以外のコードは同じです。
04:52.750 --> 04:55.390
では、 データストアを可視化します。
04:55.390 --> 05:00.250
そして、 これがバイスで表現されたベクトルである。
05:00.250 --> 05:04.660
そしてもちろん、 ご想像の通り、 同じベクトル化のアプローチだ。
05:04.660 --> 05:06.430
だから、 かなり似ている。
05:06.430 --> 05:11.020
ベクター・データストアとして別の基礎技術を使っているだけだ。
05:11.260 --> 05:13.960
もちろん、 それを3Dで表現することもできる。
05:13.990 --> 05:24.370
そして今、 バイスで3D表現を見ているところだが、 今回はとてもきれいに分離されている。
05:24.400 --> 05:25.060
これでよし。
05:25.090 --> 05:26.560
とにかく、 一日中見ていても飽きないよ。
05:27.160 --> 05:28.510
だから、 そういう感覚があるんだ。
05:28.510 --> 05:31.930
そして、 それをまとめるコードも同じだ。
05:31.930 --> 05:33.310
これはまったく変えていない。
05:33.340 --> 05:38.020
レトリバーとして保存されたベクターは、 クロマで呼び出すこともできるし、 フェースで呼び出すこともできる。
05:38.020 --> 05:39.190
それは同じだ。
05:39.190 --> 05:39.940
そうだ。
05:39.970 --> 05:40.750
我々はそれを実行する。
05:40.780 --> 05:41.740
エラーはない。
05:41.740 --> 05:42.370
大丈夫だよ。
05:42.370 --> 05:45.550
さっそくグラディオの話をしよう。
05:45.820 --> 05:49.180
ええと、 それで......。
05:49.210 --> 05:51.820
これがグラディオのインターフェイスだ。
05:52.150 --> 05:58.690
ええと、 前回お見せしようと思っていたことの1つで、
05:58.690 --> 06:07.060
今この機会にお見せしようと思っています。
06:07.060 --> 06:11.710
ランカスターとは言っていないし、
06:11.710 --> 06:17.500
スペルも小文字のaを使った。
06:17.500 --> 06:21.370
エイブリーの名前のスペルも間違えるしね。
06:21.400 --> 06:24.400
エイブリーは以前何をしていたのですか?
06:25.870 --> 06:27.670
ええと、 ええと。
06:27.670 --> 06:32.920
そして、 このコードをそのまま実行して、 何が戻ってきたかを見ることができる。
06:33.130 --> 06:45.580
私が話しているのはエイブリー・ランカスターのことだと正しく認識され、 彼女の人事文書を調べ、 彼女がイノベート・インシュアランス・ソリューションズで働いていたこともまた正しく認識された。
06:45.670 --> 06:48.760
ええと、 中に入って手早く確認したほうがいいかもしれない。
06:48.760 --> 06:51.700
設定されているので、 従業員の書類に移動する。
06:51.700 --> 06:53.500
エイブリー・ランカスターを見つけた。
06:53.500 --> 06:54.580
これだ。
06:54.580 --> 06:56.560
これが彼女の人事記録だ。
06:56.560 --> 06:57.700
彼女が何をしたか見てみよう。
06:57.700 --> 07:03.310
保険会社エルムを設立する前は、 イノベイト・インシュアランス・ソリューションズに在籍していた。
07:03.550 --> 07:06.010
ああ、 それを発明しなかったのはいいことだ。
07:06.340 --> 07:17.530
ええと、 要するに、 テキストマッチングだけではなかったということが実感できる。
07:17.530 --> 07:23.230
小文字と大文字を間違えても騒がなかった。
07:23.230 --> 07:31.870
エイブリーの綴りが間違っていても、 エイブリー・ランカスターのYの綴りと同じ意味であることがわかったのだ。
07:31.870 --> 07:39.220
それが、 私たちが目指していたものである可能性が非常に高いことを認識するのに十分な常識を備えている。
07:39.220 --> 07:44.890
そしてまた、 これをベクトルにしてベクトルに入れ、 ベクトル・データ・ストアでそれに近いベクトルを探したところ、
07:44.890 --> 07:56.050
エブリー・ランカスターのHR記録がデータ・ストアでそれに近いものとして見つかったからだ。
07:56.050 --> 08:00.430
だから、 スペルを間違えてもうまくいくというのは魅力的なことだと思う。
08:00.430 --> 08:12.130
最初のセッションで使ったブルートフォース・テクニックよりも、 ベクター・ルックアップ・アプローチを使ったほうがはるかに優れていることがよくわかる。
08:12.190 --> 08:17.890
だから、 クロマを使っても同じテストがうまくいくことを自分で証明してもらおう。 もちろん、
08:17.890 --> 08:19.720
両方試してみればわかる。
08:19.720 --> 08:23.350
クロマもバイスも、 実にうまく機能していることを願っている。
08:23.440 --> 08:26.020
しかし、 最も重要なのは、 それを見たことだ。
08:26.050 --> 08:37.510
先に説明したとおり、 ラングでは、 裏で異なるベクター・データ・ストアを切り替えて、 同じ配管をラグのワークフローに使うことができる。
08:38.080 --> 08:39.760
よし、 スライドに戻ろう。