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 よし、 スライドに戻ろう。