だから､ あなたが何を考えているかは分かる｡
何が起こっているんだ？
もう5日目だ｡
週目の5日目だ｡
なぜ彼はJupyterノートブックを開いているのか？
それが4日目だ｡ 5.
ベクター・データ・ストアを別のものに変更するのがいかに簡単かを純粋に知ってもらうために､ 4日目にはちょっとした逸脱があるからだ｡
また､ このような抽象化されたデータ・ストアで作業することがいかに簡単であるかをお見せすることもできます｡
さて､ 説明しておかなければならないのは､ これは本当のベクトル・データ・ストアではないということだ｡
Facebook AI Similarity Searchの略で､ Facebookが公開しているオープンソースのライブラリで､
他のベクトルに近いベクトルを素早く検索することができる｡
Langshanは適切な抽象化機能を備えているので､
chromaの代わりに使うことができます｡
そのため､ 以前はクロマを使っていた｡
つまり､ より深刻なハードコアデータストアの悪癖なのだ｡
クロマの代わりにそれを使えばいい｡
抽象化と他のいくつかのことを除けば､ コードはほとんど同じになるからだ｡
そこで､ このインポートでは前回と同様にインポートを実行する｡
クロマのインポートをコメントアウトしているのがわかるだろう｡
Chromaはここには含まれず､ 代わりにフェイスブックのAI類似性検索を取り込んでいる｡
注目すべきは､ フェイスにはCPUとGPUの2つのバリエーションがあることだ｡
そして､ この環境では､ もちろん､ PipはCPU版をインストールしていますが､ GPU上で動作する高性能プロジェクトでは､
GPU版を実行することで､ 猛烈なスピードで動作させることができるので､ バイスをインポートしましたが､ エラーはありませんでした｡
いくつかのことを準備する｡
これはすべて同じコードだ｡
以前と同じようにすべてを積み込む｡
うまくいけば､ 123をレンチャンクに変更できるかもしれない｡
では､ 123はあるのか？
そうだ｡
正しいメタデータがあることを確認しよう｡
私たちには4つのタイプがある｡
今のところ何も変わっていない｡
これはすべて同じだ｡
しかし､ これを見てほしい｡
ここで一行､ 狡猾に変更されている｡
ああ､ そこまで注意を引く必要はなかったよ｡
もうお気づきのことと思う｡
だから私たちは､ ベクターストアはドキュメントからのクロマ・ドットだと言っていた｡
そして､ チャンクの埋め込みとパーシスト・ディレクトリを渡した｡
そして今､ 私たちは同じ構成からバイスドットと言っているだけだ｡
チャンクも渡す｡
また､ 埋め込みも渡す｡
バイスはディスク上に残らないからだ｡
ええと､ この2本のラインも違う｡
そのため､ データストアに質問する下位レベルの方法は異なる｡
Feistを使うのであれば､ これを手元に置いておくと､ ベクトル数や次元数などのクエリーの仕方がわかって便利です｡
クロマでこれをやったとき､ いくつの次元があったか覚えているかどうかわからない｡
うーん､ でも､ ここで考えているのは同じ次元の数だよ｡
ベクトル化には同じOpenAIのエンベッディングを使っている｡
だから､ ベクターを作るために同じLLMを使っていることに変わりはない｡
変更されたのは､ これらのベクターをクロマではなくファイズに保存する方法だ｡
各チャンクに1つずつ､ 計123のベクターがある｡
そして､ 彼らはOpenAIから戻ってくる次元を持っている｡
もうひとつ変わったのは､ プレワークのセクションが4日目から変わったことだ｡
4日目のプレワークで思い出してほしい｡
それを見てみよう｡
ええと､ バ､ バ､ バ､ バ｡
クロマからベクター､ ドキュメント､ ドキュメントタイプを抜き出すだけです｡
そして､ このデータを得るためにクロマに問い合わせる方法を見ることができる｡
それで､ 悪徳業者にはこうしたんだ｡
もっときっちりしたやり方があるかもしれないが､ これなら簡単そうだ｡
同じベクトル､ ドキュメント､ ドキュメントタイプ､ 色を集めて､ それをPlotlyが期待する色にマッピングして､
以前2Dでやったのと同じようにベクトルを視覚化できるように､ 同じ図を描くだけです｡
このコードは1つの小さな例外を除いて同一である｡
見分けられるかな？
それが唯一の変化だ｡
タイトルをクロマからバイスに変更しましたが､ それ以外のコードは同じです｡
では､ データストアを可視化します｡
そして､ これがバイスで表現されたベクトルである｡
そしてもちろん､ ご想像の通り､ 同じベクトル化のアプローチだ｡
だから､ かなり似ている｡
ベクター・データストアとして別の基礎技術を使っているだけだ｡
もちろん､ それを3Dで表現することもできる｡
そして今､ バイスで3D表現を見ているところだが､ 今回はとてもきれいに分離されている｡
これでよし｡
とにかく､ 一日中見ていても飽きないよ｡
だから､ そういう感覚があるんだ｡
そして､ それをまとめるコードも同じだ｡
これはまったく変えていない｡
レトリバーとして保存されたベクターは､ クロマで呼び出すこともできるし､ フェースで呼び出すこともできる｡
それは同じだ｡
そうだ｡
我々はそれを実行する｡
エラーはない｡
大丈夫だよ｡
さっそくグラディオの話をしよう｡
ええと､ それで......｡
これがグラディオのインターフェイスだ｡
ええと､ 前回お見せしようと思っていたことの1つで､
今この機会にお見せしようと思っています｡
ランカスターとは言っていないし､
スペルも小文字のaを使った｡
エイブリーの名前のスペルも間違えるしね｡
エイブリーは以前何をしていたのですか？
ええと､ ええと｡
そして､ このコードをそのまま実行して､ 何が戻ってきたかを見ることができる｡
私が話しているのはエイブリー・ランカスターのことだと正しく認識され､ 彼女の人事文書を調べ､ 彼女がイノベート・インシュアランス・ソリューションズで働いていたこともまた正しく認識された｡
ええと､ 中に入って手早く確認したほうがいいかもしれない｡
設定されているので､ 従業員の書類に移動する｡
エイブリー・ランカスターを見つけた｡
これだ｡
これが彼女の人事記録だ｡
彼女が何をしたか見てみよう｡
保険会社エルムを設立する前は､ イノベイト・インシュアランス・ソリューションズに在籍していた｡
ああ､ それを発明しなかったのはいいことだ｡
ええと､ 要するに､ テキストマッチングだけではなかったということが実感できる｡
小文字と大文字を間違えても騒がなかった｡
エイブリーの綴りが間違っていても､ エイブリー・ランカスターのYの綴りと同じ意味であることがわかったのだ｡
それが､ 私たちが目指していたものである可能性が非常に高いことを認識するのに十分な常識を備えている｡
そしてまた､ これをベクトルにしてベクトルに入れ､ ベクトル・データ・ストアでそれに近いベクトルを探したところ､
エブリー・ランカスターのHR記録がデータ・ストアでそれに近いものとして見つかったからだ｡
だから､ スペルを間違えてもうまくいくというのは魅力的なことだと思う｡
最初のセッションで使ったブルートフォース・テクニックよりも､ ベクター・ルックアップ・アプローチを使ったほうがはるかに優れていることがよくわかる｡
だから､ クロマを使っても同じテストがうまくいくことを自分で証明してもらおう｡ もちろん､
両方試してみればわかる｡
クロマもバイスも､ 実にうまく機能していることを願っている｡
しかし､ 最も重要なのは､ それを見たことだ｡
先に説明したとおり､ ラングでは､ 裏で異なるベクター・データ・ストアを切り替えて､ 同じ配管をラグのワークフローに使うことができる｡
よし､ スライドに戻ろう｡