Join the Webinar
Loading...
何を学べるのか？
ベクトルデータベースは2023年に大きな注目を集めました。最も人気のあるLLMアプリケーションであるチャットボットにおいて、ベクトルデータベースは重要な役割を果たしています。しかし、それはベクトルデータベースの用途のごく一部にすぎないことをご存じですか？ほかにも、製品レコメンデーション、化学分析、逆画像検索などに使用できます。
なぜでしょうか？それは、ベクトルデータベースの主なユースケースが、非構造化データを扱えるようにすることだからです。
扱うトピック:
- 非構造化データが扱いにくい理由
- ベクトルデータベースが有効な一般的なユースケースの概要
- 非構造化データをベクトルデータベースに取り込む方法
- 独自のベクトルデータベースを評価・構築する際に考慮すべきこと
- ベクトルデータベースを使い始める際によくあるミスを避ける方法
本日は、本日のセッション「Vector Database 1 0 1」短期集中講座と、ゲストスピーカーのYujian Tangをご紹介できてうれしく思います。ええと、YujianはここZillizのデベロッパーアドボケイトです。ええと、彼はAmazonでauto MLに取り組むソフトウェアエンジニアリングのバックグラウンドを持っています。Yujianは、コンピューターサイエンス、統計学、神経科学を学び、ええと、IEE fake dataを含むカンファレンスで研究論文を発表しています。
彼はタピオカティーを飲むのが好きです。これは私が確認できます。ええと、家族と過ごすこと、そして水辺にいることも好きです。ようこそ、Yujian。ああ、ありがとうEmily。ええと、皆さんこんにちは。
それでは今日は、Vector Database 1 0 1について取り上げます。ええと、本日取り上げる内容の基本としては、まず、Vectorデータベースが解決する問題とは何か、そしてそれによって非構造化データをどのように扱えるようになるのかについて、ある種の概要から始めます。ええと、それからいくつかのユースケース、それらがどのように機能するのかに踏み込み、最後にデモを行います。では、ええと、まず私について少し。Emilyが言及したように、ええと、私はここZillowのデベロッパーアドボケイトで、タピオカティーが大好きです。そして、ええと、そこにあるQRコード、または画面の、右側の画面上にあるQRコードから、もし後でつながって質問したい場合は、ええと、私のLinkedInにアクセスできます。
ええと、始める前にZillizについて少し。Zillizは、2017年に設立されました。カリフォルニア州Redwood Shoresを拠点としており、そして私たちは多数のオープンソースプロジェクトのメンテナーです。そして本日お話しする内容に、ええと、最も関連があるのはvisで、これは私たちのオープンソースのベクトルデータベースです。そしてGPT cacheは、私たちの、ええと、オープンソースのセマンティックキャッシュです。では、本日はこれらのトピックをこの順番で扱います。
まず、ええと、Vector Databases 1 0 1として、データのレビューと、ええと、概要のようなもの、ええと、扱えるデータの種類といくつかの、ええと、ユースケースを取り上げ、その後、ええと、ベクトルデータベースがどのように機能するのか、そしてデモを行います。では、Vector Databases 1 0 1、なぜベクトルデータベースなのか？何がポイントなのか？ええと、ここでまず話すべき、ええと、ことは、ベクトルデータベースは非構造化データを扱うためのものだということだと思います。そして非構造化データは世界のデータの80%を占めています。ええと、Vectorデータベースはこれを行う唯一の種類のデータベースです。そして、これらが、例えばSQLデータベースやno SQLデータベースのような他のデータベースと異なる点は、本質的には検索パターンです。
検索の種類ですね。つまりSQLデータベースやno SQLデータベースでは、多くの場合、キー同士のマッチングを行っています。例えば、「ねえ、ええと、X, Y, Zを選択したい、where X, Y, Z from、何かそんな感じ」のようなものを見つけようとしているわけです。そうですよね？つまり多くのキー同士のマッチングを行っているのです。ええと、そしてベクトルデータベースで実際に行うことは、多くのベクトル比較であり、ベクトルとは、これらの、ええと、非構造化データの表現で、実際には長い、ええと、数値の列です。したがって、ベクトルデータベースはこの種の非構造化データを扱うために特別に構築されており、テキスト、画像、動画、音声を含め、それらを数値に変換し、そのうえで、ええと、定量的に扱えるようにします。では、ええと、テキストや、ええと、さまざまな種類の非構造化データがなぜ扱いにくいのか、いくつか例を見ていきましょう。まずテキストに関するものを見て、その後、ええと、ええと、画像に関するものを見ます。
そしてここはプレゼンテーションのインタラクティブな部分になります。ですので、ええと、チャットに入力する準備をしておいてください。ではここで、テキストを見ているとき、ええと、何らかのキーワード検索を行っているとします。通常のキーワード検索では見逃すかもしれないが、ええと、ベクトル検索なら拾えるかもしれないものの一つは、意味的な意味や文脈、そしてユーザーの、ええと、意図のようなものです。そうですよね？例えばここにappleがありますが、果物としてのappleを意味することもあれば、企業としてのAppleを意味することもあります。ええと、それから、rising dome proofing breadに関する何かもあります。
ええと、それから車のタイヤがありますよね？つまり、車のタイヤを交換したい場合、あなたが探しているのは実際に車のタイヤを交換する方法の手順ですか？それとも、車のタイヤをいつ交換すべきかを知りたいのでしょうか、ということですよね？つまりテキストには、ええと、意味や文脈、そしてテキストそのもの以外のものがたくさんあります。なので、このキーワード検索を行うだけでは、必ずしも十分ではありません。A、正しい結果が返ってこないかもしれませんし、b、正しい意図すら返ってこないかもしれない、ということですよね？それではこの部分がプレゼンテーションのインタラクティブな部分です。ええと、ここにとても、とても有名なセレブ、ええと、私のお気に入りのセレブであるTaylor Swiftの写真がいくつかあります。そして皆さんに知りたいのは、これらの写真のうちどれがTaylor Swiftではないと思うかです。では、ええと、ここで少し間を取りますので、皆さんにはチャットに番号を入れていただきたいです。
このすぐこちらの、すごく赤いものなら1、こちらの2枚目なら2、彼女が、ほら、黒いトップスを着ているようなものなら3。そして、ええと、この最後の、彼女が小さなキラキラしたドレスを着ているものなら4です。見てみましょう、2、4、2、3。この絵文字、それはあまり数字ではないですね。ええと、わかりました、ここにはたくさんの、ええと、たくさんのゲストがいて、かなり意見が分かれているようですね。
皆さんがある程度、いくつかの回答が入ってくるのを待ってからお伝えしようと思います。ですので、この演習によって、ベクトルデータベースが実行するかもしれない操作を行うとはどういうことか、イメージを持っていただけるといいなと思います。この場合、ここでの操作は画像の類似検索です。そして、ええと、ちなみに2と言った皆さん、正解です。2が実際にはTaylor Swiftではないものです。他のものはすべてTaylor Swiftです。
3もたくさんありますし、4も出ていますが、でも皆さん、この写真がTaylor Swiftだということはご存じなんですね。これはきっと非常に象徴的な写真なのでしょう。さて？では、数字であるこれらのベクトルは、どのように機能するのでしょうか？どこから得るのでしょうか？まずはナレッジベースから始めましょう。前の例では、それは何らかのテキストだったでしょうし、Taylor Swiftの写真だったでしょう。ええと、企業環境では、おそらく皆さんの仕事においては、実際の社内文書である可能性が高いです。ではこのデータに何が起こるかというと、ディープラーニングモデルに渡されます。
そしてここで本当に重要なのは、持っているディープラーニングモデルが適切な種類のモデルであることです。適切な種類のデータで訓練されていなければなりません。画像を扱っているなら、画像データで訓練されたモデルが必要です。テキストを扱っているなら、テキストデータで訓練されていなければなりません。画像を扱っていて、特に猫の種類を識別しようとしているなら、それがデータに含まれていなければならない、ということですよね？それで何が起こるかというと、画像データを取り、それをディープラーニングモデルに通し、それから最後の層を切り落とします。
ディープラーニングモデルの最後の層は通常、予測を行いますよね？つまり、ええと、例えば画像モデルがあるとすると、通常は、はい、この写真には猫がいます、または、いいえ、この写真には猫はいません、というような予測を行います。しかし私たちが求めているのは、実際にはそのモデルがそのデータについて何を学習したのかを知ることであって、予測を出してほしいわけではありません。ただ何を学習したのかを知りたいのです。そこで数値表現を持つことで、後でそのデータを扱いたいときに、そのデータを定量的に扱う方法を持てるようにします。その方法として、最後の層を切り落とし、最後から2番目の層からの出力を取得します。
では、なぜ最後から2番目の層であって、中間にある他の層ではないのかというと、モデルにデータを通すにつれて、各層はモデルについて新しいことを学習していくからです。そして最後から2番目の層には、予測を行う前のすべての意味情報が含まれています。そしてそれが基本的にベクトルというものです。そしてそのベクトルを取り出して、Zills や Milds のようなベクトルデータベースに入れると、後でクエリを実行して、他の情報をそのベクトルと比較できます。ええと、ですから、比較する情報はすべて同じ長さ、同じ次元のベクトルでなければならないということも理解しておくことが重要で、これについては後で扱います。
後のスライドで、ええと、もう一度それを見ていきます。では、ベクトルデータベースはどう使うのでしょうか？実際にどうやって使うのでしょうか？ここにベクトルデータベースの9つのユースケースがあります。ええと、この数か月、基本的にはこの1年で私たちが見てきた中で最も人気のあるものは、rag retrieval、augmented generation、つまり検索拡張生成ですね。ここです、上の隅にあります。ええと、rag について聞いたことがある方は、チャットに書いてください、チャットに何か投稿して、ええと、それについて何を聞いたことがあるか、あるいは rag について何か質問があるか教えてください。ええと、チャットに書いてください。ええと、rag 以外にも、他にもたくさんあります。
それで、ええと、レコメンダーシステムがあります。ええと、たとえば、商品レコメンデーションは実際、最も一般的なユースケースの1つであり、vis における本番環境で最も一般的な、ええと、ユースケースの1つです。ええと、商品というのは、テキストや画像、ええと、レビューなど、さまざまなものが付随する複雑なものです。ですからレコメンダーシステムが行うのは、これらの商品やユーザーを比較し、それを定量化して比較するためにベクトルデータベースを使えるようにすることです。ええと、他の例ですね。テキスト検索、これは今話しました。画像検索についてはこれから話します、あ、今話しましたね。ええと、動画類似検索。
動画から動画への検索ができれば素晴らしいですよね。ええと、音声類似検索、ええと、異常検知も非常によく使われるものです。ええと、2つの、ええと、ユーザーアクションはどれくらい異なるのか、本当に同じユーザーなのか、ということです。そしてこれは、不正検知のようなものに関して非常に重要です。ええと、それからここに挙げている最後のものはマルチモーダル検索です。そしてこれは、ええと、2024年に私たちがさらに取り組んでいくものです。ええと、マルチモーダル検索のやり方について、いくつかチュートリアルを作成する予定です。
ええと、いくつか例を見てみましょう。ここにある、ええと、この例では、ええと、このスライドには右側にQRコードがあり、ここにたくさんの写真がありますよね。これらの写真はすべて絵画で、ここにあるものはすべて、すべて印象派の絵画だと思います。そしてこれらはすべて検索対象の写真です。このノートブックで説明しているのは基本的に、ええと、これらの写真をどのように取り込み、他の写真と比較するか、ということです。ええと、写真は少し時間がかかります。ですので、このノートブックを実行するには、およそ12分から15分かかります。
ええと、でも後で確認してみてください。ええと、そしてここにあるもう1つの例はテキスト検索ですね。今、画像検索を見たので、次にテキスト検索を見ていきます。そして後ほど一緒に進めるデモでは、テキストを使ったことも行います。ええと、このテキスト検索では、私たちがやったのは単に Wikipedia をスクレイピングしただけです。基本的に、私は Wikipedia のページ、The Nightmarebefore Christmas をスクレイピングして、「あらすじは何ですか？」と尋ねました。すると、「The Nightmarebefore Christmas のあらすじは、Halloween town の pumpkin king である Jack Skellington が、同じ Halloween の決まりきった流れに飽きて、Christmas Town を発見することを中心に展開します」と答えています。
そしてそれは続いて、『ナイトメアー・ビフォア・クリスマス』のプロットの残りについて説明します。いいですか？では、ベクトルデータベースは実際にはどのように機能するのでしょうか？表面下では何が起きているのでしょうか？まず、例のエントリを見てみましょう。これは、ベクトルデータベースの1つのエントリに保存するかもしれないものです。この、ええと、このエントリで最も重要な2つの要素はIDと埋め込みです。IDは、その、ベクトルデータベースがあなたのエントリに一意のIDを持たせるための方法です。
そして埋め込みは実際のベクトル埋め込みです。これは、検索してベクトルを比較するときに比較されるものですよね？だから先ほど、ベクトルデータベースは特定のユースケースに最適化された特定の種類のデータベースだと言っていたのです。そしてそのユースケースとは、埋め込みを比較し、この種の、ええと、高計算負荷のタスクを行うことです。そしてそれらの2つのフィールドに加えて、この例ではたくさんのメタデータフィールドもあります。これらは基本的にフィルタリングに使えるフィールドです。
ええと、この例について言うと、これは実際には、私がchat towards data science向けに作ったデモアプリからの例です。そして実際、これはZillow's cloudを使っています。いいですか？では、ベクトルデータベースの背後にある、おそらく中核的な機能の1つを見てみましょう。これは、まさに非常に基本的な機能です。これは意味的類似性です。
これこそがベクトルデータベースがあなたのために行うことです。この例では、4つの単語がすべて2次元ベクトルとして設定されています。そして例に入る前に、これはおもちゃの例であり、企業が単語に2次元ベクトルを使っているのを見ることは決してない、ということをはっきりさせておきたいです。ええと、それはかなり変です。それから、ええと、ここで queen と woman、そして king と man は第1軸、つまり第1次元で同じ値を持っていることも指摘しておきたいです。
そしてここでそれが意味するのは、これらの単語がその次元上で同じ値を持っているということだけです。その次元が何を意味するのかについては何も教えてくれません。ただ、これらの単語がその次元に沿って同じように関連していると言っているだけです。ですから例えば、0. 3 は、ええと、5文字の単語と相関し、0.
5 は、3文字または4文字の単語に対応する、ということもあり得ますよね？だから、この次元が必ずしも私たちの世界における、ええと、離散的な概念に反応する、あるいは対応するわけではない、ということを指摘したいだけです。では、この背後にある数学を見てみましょう。つまり、このスライドの背後にある考え方は queen minus woman plus man equals king です。queen は 0. 3, common 0. 9、そして woman は 0.
3, common 0. 4 です。ですから、それらを引き算したときの差は、ちなみにマンハッタン、これはマンハッタン距離と呼ばれます。ただ引き算をする場合、これも通常は実装されません。そしてこの例では 0.
5 です。そして man を足します。これは 0. 5, common 0. 2 で、それらを足し合わせると 0. 5,common 0. 7 になり、これは king に直接対応することがわかります。
ですからこの例の背後にある、ええと、考え方は、もともと数値ではないものに対してベクトルを使って数学ができる、ということです。そしてこの例では単語を使いました。いいですか、では実際の類似度指標のいくつかを見てみましょう。先ほど言いましたが、このスライドで数学を行っている方法を、私はマンハッタン距離と呼びましたよね？では、ベクトル、ええと、類似検索で実際に使う距離指標を見てみましょう。マンハッタン距離は単に、その、ええと、基本的には Qqi minus pi です。これはユークリッド距離で、これはおそらく皆さんの多くに非常になじみがあるでしょう。ええと、代数2や幾何などを超えるものを何か学んだことがあれば、たぶん、ええと、この、ええと、線、つまり直角三角形における斜辺と呼ばれるこの概念についての理解があると思います。
そして本質的に、それがL two、つまりユークリッド距離が測定しているものです。これはxの二乗マイナスy、あるいは、XX one マイナス y one の二乗プラス x one マイナス x two の二乗プラス Y one マイナス Y two の二乗、ということです。そして、ええと、実際にはvisでは、平方根は取りません。なぜなら、それは余計な計算にすぎないからです。そして、すべての距離は実際には同じ、ええと、同じランク順になります。すみません。
ええと、はい、では次はipです。先ほど、ええと、EU clinicianを見ましたが、これは空間内の距離を測るものですよね？これは基本的に、直角三角形がある場合に空間内の直線距離を測るものです。IPはそれより少し複雑です。これが測るのは、ええと、これはある線を別の線に投影した距離を測るものです。ですから、ここで想像してみると、ええと、「ああ、この2点について斜辺を求めよう」と言う代わりに、ええと、実際にやることは、原点からこれら2つの点を投影している、と考えるようなものです。そして、この、ええと、IPはこの点を別の点へ投影したものです。つまり、それを直角にどう投影するか、ということです。ええと、そしてこれは本質的に、2つの、ええと、ベクトル間の角度の違いだけでなく、2つのベクトル間の空間的距離も測ります。
つまり、これは向きと大きさの違いを測り、L twoは大きさだけです。さて次は、ええと、cosignで、これは向きだけを測りますよね？つまり、大きさ、向き、向きと大きさ、があります。cosignについて考える方法は、ええと、ご存じのように、基本的には2つのベクトル間の角度の差だけです。ベクトルは点としても、そして、ええと、点を指す線としても考えることができます。ですから基本的にco-sign ipでは、それらを線、点と点として考えています。
そしてco-signでは、単に自分の2つの、ええと、ベクトルの間の角度がどれくらい大きいかを考えているだけです。ここで少し興味深いこととして気づくのは、cosignとIPが非常によく似て見えるということです。IPはai biの和で、cosignはそれを上の、ええと、分子に持っています。ですからcosignは実際には正規化された、ええと、ipにすぎません。なので、ええと、もしベクトルがすべて正規化されている、つまりベクトルの大きさがすべて1であるなら、ipを使えばよく、co-signとまったく同じ値が得られます。
では、これらのメトリクスのどれを使うかを選ぶ際には、ええと、基本的には、これらの概念がどれくらい離れているかを測る必要があるのか、ええと、あるいはこれらの概念のいくつかの背後にある意味がどれくらい離れているかを測る必要があるのか、ええと、そして自分のベクトルは正規化されているのか、などを考える必要があります。また重要なのは、これらはすべて同じランク順を持つという点です。ですから、どれを使っても、返すベクトルのランクはそれらすべてでほぼ同じになるはずです、ええと、または、それらすべてで、そ、その、その同じになるはずです。ええと、では、はい、次にインデックスにアクセスする方法のいくつかを見てみましょう。インデックスとは、あなたの、ええと、データを保存する方法、あるいはデータに到達する方法を保存するものです。つまり、データを見つける方法、データを検索する方法はインデックスによって決まります。
先ほど話したのは距離メトリックで、これはどれだけ離れているかを測るもの、つまり、私たちのデータが互いにどれくらい離れているかをどのように測るかを教えてくれるものです。そしてこれは、データ内の点をどのように探すかを教えてくれます。inverted file index、つまりIVFは、おそらく最も直感的なベクトル検索手法です。これをどう考えるかというと、基本的には、たくさんのk-meansを行い、ある数のOIDがあるとします。そしてクラスタリングを行い、それらのOIDに最も近いすべてのベクトルを見つけ、これらのクラスタを作成します。そして検索時に何が起こるかというと、まず最も近いOIDを探すためにOIDを検索し、その後、それぞれのOIDの内部で、ええと、実際の点を検索します。
そして実際には、すべてのポイントを検索するか、量子化されたバージョンを通じてそれを行うことができます。これについては後のスライドで話します。次に重要なインデックスはHNSW、つまりhierarchical navigable small worldsです。そしてこれはグラフインデックスです。本質的にこれが行うのは、ベクトル空間内のすべてのポイントを取得し、それをグラフに挿入することです。そしてグラフに挿入する際に、一様ランダム変数を与え、割り当てます。
そしてその変数の値に応じて、レイヤーが割り当てられます。つまり、すべてのポイントはレイヤー0に入り、その後、変数が特定の範囲内にある場合、一様ランダム変数が特定の範囲内にある場合、レイヤー1に進みます。そして再び、ええと、変数が特定の範囲内にある場合、再びレイヤー2に進みます。ここで重要なのは、レイヤー1のすべてのポイントはレイヤー0にもあり、レイヤー2のすべてのポイントはレイヤー1にもあるということです。そして検索時に何が起こるかというと、最上位のレイヤーから開始し、進んで最も近いものを見つけ、下に降り、最も近いものを見つけ、また下に降りる、ということを何度も繰り返します。
つまり、HNSWはグラフ内のすべての距離を保存するため、非常に正確です。ええと、そしてすべての距離が保存されているため非常に高速です。ここでのトレードオフは、ご想像のとおり、HNSWは多くの容量を消費するということです。同じものを複数回保存しなければなりません。いいですか？インデックス作成に関して次に知っておきたい部分は量子化です。
これは、ええと、スカラー量子化と呼ばれるもので、1次元に沿った量子化です。そして量子化というのは、ほとんど、私はこれをバケッティングだと考えていますよね？つまり実数のリストがある場合、今度は整数のリストがあります。たとえば、ええと、実数としてマイナス3から3までがあるとします。そして今、マイナス3からマイナス、ええと、2. 5までのすべての値をマイナス3とする、と言います。
そしてマイナス2. 5からマイナス1. 5までのすべての値をマイナス2とします。つまり、単なるバケッティングです。そしてこれが行うことは、ディスク上に保存・格納する情報をずっと少なくできるようにすることですが、検索の粒度はずっと低くなります。
そして次はプロダクト量子化です。これは本質的に、インデックス全体にわたるスカラー量子化です。つまり、単一のベクトルだけではなく、ええと、横方向と縦方向の両方です。プロダクト量子化はスカラー量子化よりもはるかに多くの容量を節約します。そして検索に関しては、かなり、ええと、精度が低くなります。ですから実際にやりたい場合、つまり、Novusではスカラー量子化、プロダクト量子化をIVFやHNSWと組み合わせることができます。たとえばHNSWをスカラー量子化と組み合わせると、ディスク上に大量のメモリを用意しなくてもよく、同時にHNSWが提供する優れた、ええと、精度も得られる、というような感じになりますよね？このようなさまざまな手法を取り、それらを組み合わせ、いろいろなことをして、より良い結果を得ることができます。
ええと、ではデモに移ります。デモに移る前に、ここで質問のために少し止まるべきだと思います。見てみましょう。ええと、ああ、はい。
これらの質問はどれも、ええと、今すぐ答える必要はありません。はい、いいですね。ではデモを見てみましょう。すぐにコードを書いていきます。コードデモを見ていきます。そしてこのコードデモで基本的に行うことは、いくつかの埋め込みモデルをダウンロードすることです。
そしてこれは、ええと、非常によく質問されてきた部分の1つです。これは間違いなくこの1年のFAQで、つまり、どうやって自分のデータをvissや、ええと、Zillowに入れるのか、ということです。なので、ここでは3つの異なる埋め込みモデルを使ってその例を見ていきます。ただし、ええと、さらに簡単な方法は、ええと、Zillowのpipelinesを使うことです。これは、データを、ええと、有効なデータベースに入れたいという声を非常に多く聞き続けたため、かなり最近作成したものです。3つのモデルをダウンロードしたら、データセットを作ります。ええと、ええと、リンク、私は、私が使っているデータセットをそのまま取得できるようにリンクを用意します。
ええと、それからそのデータを2つの異なるモデルで埋め込み、そしてその両方のデータセットをvissに取り込みます。これは単に、いわゆる一括挿入ですね、基本的には。そして次に、その3つ目の埋め込みセットを使って、えー、visにクエリを投げます。ええと、ここで、これらの埋め込みに何が起こると思うか、ぜひ皆さんの考えを聞きたいです。えー、チャットにコメントを投げて教えてください。
さて、皆さんの返答を待っている間に、ええと、質問が1つ入ってきました。内容は、3つすべてのメトリクスのランク順は同じですか、というものです。本当ですか？私にはそうではないように思えます。3つすべてのメトリクスのランク順は同じですか。
ええと、これについて今すぐ頭の中から数学的な証明を出せるわけではありません。うん。えー、でも少なくとも簡単に分かるのは、ええと、コサインと内積のものは同じだということです。なぜならそれらは単純な、えー、変換であり、そこで、ええと、すべてのコサインは基本的にそれぞれの大きさで割られているからです。ええと、L2については、私は今すぐ頭の中からこの変換を持っているわけではありませんが、XI、つまりYIを引いたものの二乗、という方程式を変形する方法はあります。そして、えー、それを、ええと、その、その、その、そのコサイン、えー、ab、えー、評価と比較できます。
ですので、ええと、それらのランク順はすべて同じになるはずです。正規化された、えー、データであれば間違いなくすべて同じです。それらの異なる方法とは何ですか？それは、その、メトリクスについてでしたか？はい、そうだと思います。ああ、わかりました。それなら納得です。ええと、はい。
えー、皆さんはデモをざっと確認する機会があり、これから作業するnotebookを見ることができていますか？あと1分ほど待ちます。ええと、もし異なる埋め込みや異なる埋め込みモデルを比較すると何が起こるかについて考えがあれば、チャットに入れてください。うん。では。これを始めるには十分な時間だと思うので、notebookを表示します。そして、このデモがリンクしている、えー、notebookへのリンクもzoomに落とせますね。ではそれをzoomに貼ります、はい。
それから、えー、よし、いいですね。これからコピー＆ペーストをいくつか行い、ライブコーディング、実際のライブコーディングを少し、ええと、そしてコピー＆ペーストも行います。最初にやることは、これをコピー＆ペーストすることです。viss、viss、そしてsentence transformersをインストールします。これらが、えー、この、えー、プロジェクトに必要な3つのライブラリです。
さっきこれをやったばかりなので、本当に何も壊れないことを願っています。そしてこれが視聴者には小さすぎる場合は、ええと、チャットで知らせてください。そうすれば、えー、Jenに画面を少しズームインしてもらえます。見やすいかどうか教えてください。あ、少しズームインしますね。はい。
いいですね。今インストールしているのはこれです。そしてこれは驚くほど時間がかかっています。実際には驚いていません。あ、pipもインストールする必要がありますが、それは後でできます。PIPは後日インストールできます。はい、それからここで、えー、いくつかimportも取得します。
ここでは、sentence Transformersライブラリからsentence transformerをimportします。これが埋め込みモデルを取得する方法です。次に、visからdefault serverをimportします。これはvis lightです。これにより、notebookから直接立ち上げられるserverを持つことができます。そして、ええと、Pine Vissを取得します。
そしてPine Vissから、connectionsをimportします。これにより接続できます。utilityは、S schemasを扱えるようにします。えー、それからfield schema selections、collection、schema、data type、そしてcollectionです。つまりVissはcollectionsを作成し、collectionsの内部にはschemasがあります。そしてschemasの内部には、えー、fieldsがあります。基本的にfieldsはschemaを定義するために使われるもので、fieldsはdata typesによって定義されます。はい。
それからここには、timeもあります。これは主に、えー、時間を測定するためのものです。この、えー、特定の、ええと、何というか、use caseで実際に使うかどうかは分かりません。では、これがどうなるか見てみましょう。これはimportに本当に長い時間がかかっていますか？Python notebookのセルが実行に10秒以上かかると、いつも不安になります。
どうなってるの？って感じです。ライブデモの魔法ですね。ライブデモの魔法なんですが、動いているように見えます。少なくとも、ここでいくつかのコマンドは確実に実行されています。ええと、わあ、30秒。実行にかなり時間がかかっています。
これはかなり珍しいですね。あ、出ました。オーケー、いいですね。ナイス。では次にやることは、デフォルトサーバーを起動して、それからデフォルトサーバーに接続することです。
ええと、ではやってみましょう。default server dot starts は基本的にサーバーを起動し、それから connections dot connect です。ここでは、ええと、これが local host で、ここがサーバーがデフォルトで起動する場所だとわかります。そして、サービスが起動したポートをリッスンするメソッドもあります。ええと、デフォルトでは、これは、うーん、19 530 だと思います。
はい、いきます。あ、いいですね。オーケー。ええと、不安になる直前でした、10秒。オーケー。
では次の部分では、ええと、いろいろダウンロードします。なので、実際に皆さんがこれをこんなに素早く入力できるとは思っていませんが、ノートブックからならこのくらい素早くコピー＆ペーストできると思います。ええと、3つの異なる sentence transformers を取得します。すると multilingual mini LM L 12 を取得しているのがわかります。そして、ええと、これらはすべて同じベースで、これらはすべて同じベースモデルです。つまり、これは sentence transformers のベースモデルです。
そして他の2つはファインチューニングされています。これらは異なる組織によって、異なるデータセットでファインチューニングされています。オーケー？ ではここでやることは、これらの名前を変更することです。これは実際には mini LM B two quantized ではなく、ええと、おそらく別のものです。ええと、でもこのままにしておきます。この名前のままにしておきます。
基本的にここで私がやっているのは、2つの collection 名を与えていて、さらに dimension と呼ばれるものも定義しています。dimension はベクトル埋め込みのサイズです。次元数、つまり本質的には、機械学習、埋め込みモデルがあなたのベクトル埋め込みとして生成する数値の個数です。これらの paraphrase, multilingual mini lmm, L 12 V two モデルはすべて dimension が 3 84 です。これは、コードの中でいじってみて、出力を取得し、そのベクトルの長さを確認することでわかります。
または、モデルカードを読むこともできます。そしてこれらを定義した後、utility を使って進み、まっさらな状態であることを確認し、もし現在、ええと、その、何て言うんでしたっけ collection、ええと、collection ではなく、ええと、database に存在していれば削除します。ではこれから、データを定義していきます。私はこのデータをたくさんコピー＆ペーストしました。これは、ええと、speak に触発されたものです。
さて、ええと、Taylor's version を使いました。ええと、とはいえ本当のところ、彼女が speak の自分のバージョンを出したときに最初にこれを作ったと思います。ええと、実際いや、それは違う気がします。いや、完全には確信がありません。とにかく、これら4曲からいくつか歌詞を持ってきました。そして見てわかるように、基本的には全部文で、ええと、50個くらいあります。これで埋め込みの比較をいくつか行い、これがどれくらい長いか見てみます。
51個あると思います。51個あります。ええと、51文なので、うーん、これは本当に、かなりおもちゃの例です。返ってくる結果はあまり多くありません。50個しかありません。なので、ええと、その点は覚えておいてください。
さて、それではスキーマの重要な部分をいくつか定義していきましょう。ここで行うのは、ええと、私たちの、うーん、コレクションのスキーマを定義することです。そうですよね？つまり、これら2つのコレクションがあり、それぞれに2つのコレクション名があって、それらに同じスキーマを与えます。そしてスキーマでは、フィールドを定義します。プレゼンテーションの前半で話したのを覚えていれば、本当に定義する必要があるフィールドは2つだけで、それはIDとembeddingです。そして残りのフィールドはメタデータフィールドです。
ここでIDとembeddingを定義します。そして例とは違って、私はIDとして自動インクリメントする、ええと、整数を使います。そしてここで、ベクトルの次元が384であることを、ええと、データベースに伝える必要があります。それから単に、enable dynamic field equals true と指定します。これにより、基本的に任意のメタデータを、ええと、フィールドスキーマや、うーん、コレクションスキーマで事前定義することなく挿入できるようになります。
そして、うーん、実はこれについてブログを書いたばかりなので、ええと、そのリンクを、ええと、チャットに貼るべきですね。ですが、dynamic schema がどのように機能するのか、そしてそれが何なのかについてもう少し詳しく説明しているブログがあります。次の部分では、実際のembeddingsを取得します。うーん、その方法としては、次へ進んで、ほら、これらのmodelsがありますよね？覚えていますか、ここ上の方でmodelsを取得しました。modelsはどこでしたっけ、ここ上のmodelsです。それから、このencodeという関数を呼び出します。
そして、うーん、本質的には、これからencodeを行い、ここで辞書を作成して、すべてのsentencesをそれぞれのvector embeddingsにマッピングします。ですから、これは、ええと、少し時間がかかるはずですが、おお、わあ、すごく速かったですね。ああ、いいですね、はい。うーん、これによって、最初の2セットのembeddingsが得られます。そうですよね？つまり、これら2つのmodelsがあり、この2つのmodelsからすべてのembeddingsを取得して、それらをマッピングしています。では次にやりたいのは、この2つの、ええと、vectorsのセットに対して、どのようにindexを作成するかを決めることです。そうですよね？ベクトル、indexes、そしてdistancesについて話したのを覚えていますか。
ですからここでindexを作成するときには、それを念頭に置く必要があります。IVF、ですよね？これは最初に話したindexでした。最も直感的なもので、基本的には多数のclustersを作成するだけのものです。そしてflat、flatは量子化されていないという意味です。そうですよね？私が挙げた他の例はssqとpq、scaler quantization、そしてproduct quantizationでした。これらはメモリ消費を削減するのに適しています。うーん、しかし今回は非常に少数のvectorsしかなく、問題にならないので、ここではmetric typeとしてLtwoを使っています。
そしてparametersでは、nlist は、ええと、IVFにおいて、いくつのclustersが欲しいかを表します。そしてデータポイントは50個しかないので、ええと、4clustersはおそらく問題ない数です。わかりましたか？それでは次にやりたいのは、これらのfieldsに対してこれらのindexesを作成し、それからcollectionsをメモリにloadして、メモリ上にloadされた状態にして扱えるようにすることです。いいですね？さて、ここまでできたので、次にやりたいのは大量のdataをinsertすることです。ここ上の方で、このdictionary、sentencesの2つのdictionariesを作成したのを覚えていますか。そしてここ上の方でsentencesを作成しました。これは、ええと、sentencesのlistです。
うーん、ではこれから、ええと、insertion functionを作成します。これはdictionariesのlistです。うーん、主にbatch insertとして使うことを想定しているためで、ここではsingle insertとして使っています。うーん、ですが、ええと、これを使って一度に何百ものdata pointsを挿入できます。基本的にここでやっていることは、私は、おそらくこれら50個すべてをまとめてbatch insertできると思います。つまり基本的に、ここでやっているのは、「これがsentenceで、これがembeddingsです」と言っているようなものです。
そして、insert の中で ID を指定していない、ええと、あるいは ID を定義していないことに注目してください。これは Id が自動インクリメントされるからです。ただし、ここで sentence という新しいフィールドも定義していることに注目してください。これを事前に定義せずにできるのは、たぶん dynamic scheme のおかげです。いいですか？つまり基本的に私たちがやっているのは、挿入するためのものをたくさん作成し、それらを挿入してから、collection に対して flush を呼び出すことです。そして Flush が何をするかというと、Mils では、mils はこれらのノード内に、ええと、大量のメモリを保持する分散システムです。
つまり flush が行うことは、最初はメモリとノードにあるものを、ええと、flush がそのメモリを永続ストレージにフラッシュし、そのデータ上に、ええと、実際の index を作成するということです。いいですか？では次に、これらの embeddings を検索する方法を見つけていきます。search embeds では、私はもう一度 dictionary を作成します。ええと、そして、ええと、私がやることは、sentences からいくつかの文を取ることです。ここでは 5 番目と 6 番目の文を取ります。
ええと、そして以前使わなかった model を使ってそれらを encode します。それからそれらを map して、list に入れるようにします。そうすれば vis を検索するときに、ええと、この list を渡すだけで済みます。はい、いきましょう。これは少し複雑なセクションなので、ここで一旦止めて説明します。先ほど言っていたように、time は基本的に、ここで実験結果を見るためだけのものでした。
ええと、ただ私たちがやることは、data を渡すことです、そうですよね？つまり data は検索に使う data で、vector embeddings のこの list を渡します。そして approximate nearest neighbor search field、A NNS、approximate nearest neighbor search field は embeddings だと指定します。それが embeddings field です、そうですよね？それが比較対象となる field です。そして検索するためには、同じ metric type lmm、ええと、いや lmm ではなく L two を使う必要があります。そして、ええと、parameters では、いくつの clusters を見るかを指定する必要があります。clusters は 4 つしかありません。
そのうち 2 つだけを見てみましょう。そして上位 3 件の results だけが欲しいとし、output field、ええと、それは、ええと、output、つまり field、metadata field で、本質的には database から取り出したいものは sentence です。なのでこの collection に対してここでそうします。そしてもう一方の collection に対してもまったく同じことをします、そうですよね？これが一対一になっているのがわかりますか、repeat search data embeddings L two、probe two、one、probe two、ええと、ええと、clusters limit of three、field を output、ええと、sentence を output します。では見てみましょう。
ここで time を見ると、Novus の search time がとんでもなく速いことがわかります。ええと、それから実際の values が何かを見られます。これは最初のもので、query sentence が何か、そして nearest neighbor が何かを見ます。ええと、本当は、ええと、これをこの 3 つと、次の 3 つに分けるべきでした。でも query sentence が、ええと、うーん、これが何の曲かわかりません。
あ、これは speak now だとわかりました。ええと、これが query sentence で、これが result sentence です。そしてこれらが同じではないことがわかります。つまり、これら 2 つの embeddings models は非常に異なる embedding spaces を持っているということです。なぜなら、ここにある 3 つの文のどれも、ええと、query sentence と同じ文ではないからです。これは、同じ、ええと、embeddings model を使っているなら見られると期待するものです。そして、ええと、もう一度見ると、これら 3 つもまた、nearest neighbors のどれも qua ants ではありません。
つまりそれは、ええと、これら 2 つの embeddings models は、同じ base model であるにもかかわらず、かなり異なる、ええと、embedding spaces を持っているということを示しています。さて、ではもう一方を見てみましょう。これが今日見ていく最後のものになります。私の、ああ、ありました。はい、もう一方は、ええと、ほとんど似たように見えます。ほとんどまったく同じです、そうですよね？なので、こちらは実際には同じ result であることがわかります。
これは違います。ええと、それから、ああ、はい、いきましょう。実際に3つ目では同じ文が返ってきています。これは興味深いですね。これは、これらのモデルがこの2つの文を似た空間にマッピングできたけれど、完全に同じではなかった、ということを示しています。
そしてこれはまた、ここでは実際に最初の2つの間にいくつか、ええと、クロスオーバーがある、ということも示していますよね？ここにあります、この2つは同じものです。ええと、そしてこちらのものを見ると、ここでもまた、同じ文の繰り返しがないことがわかります。うーん、つまりこれは、ベクトル、ええと、埋め込みモデルがどれほど重要か、そして、うーん、ベクトルデータベースを扱って得られる結果にどれほど重要であるかを本当によく示しています。はい、いいですね。ということで、この、このデモについてはだいたい以上です。
うーん、では質問を受け付けられると思います。うーん、埋め込みモデルが異なるものとして指定されたのはどこですか？はい、ではもう一度説明します。ここで sentence transformers を取得していますよね、うーん、ここで sentence transformers、そして後でまた sentence transformers を取得しています。つまりこれが読み込むもの、これが行うことは、この特定の、ええと、sentence transformer を読み込むことで、ここで3つの sentence transformers を読み込んでいるのがわかると思います。そしてこれら3つの sentence transformers を使っているとき、データに対して私が行っていることは、これらの transformers それぞれでデータを encode して、ええと、embed する、ええと、embed ではなく、うーん、ええと、ちなみにこれは基本的には embed です、ええと、そして、vis に格納する、ということです。
そして検索を行うときには、最後のものを使って最後の embedding を行っていることがわかると思います。そこが、異なる、ええと、embeddings models を指定している場所です。image text ではなく時系列データ向けの pine mils embeddings utilities はありますか？それとも同じ関数が適用されますか？うーん、そうですね、うーん、ここで最初に答えるべきことは、pine mils には embeddings utilities はないということだと思います。ええと、ここでの embeddings は完全に hugging face で行いました。ええと、Zillows cloud には、ええと、データを自動的にドラッグ＆ドロップするだけで済むようにする方法があります。
embeddings について心配する必要はありません。今のところ text data でしか機能しないと思います。うーん、ただ、images、audio time series、その他どんな種類の data でも、ええと、そこに、ええと、pipeline の中に入れる計画はきっとあると思いますが、うーん、pipeline の中に、ですね。そしてそのツールも pipelines と呼ばれています。そして、ええと、それは Zillow's cloud の free tier、うーん、または serverless cluster を使っている人なら誰でも無料で利用できます。
つまりそれが、embeddings を取り込む、ええと、1つの方法です。一方で、うーん、time series と text、image data の違いに関して重要なのは、モデルそのものと、それが何で訓練されたかです。ですから、もし time series data に特化して訓練されたモデルを持っている、あるいはそのようなモデルを知っているなら、ええと、それが必要になるモデルの種類、ええと、time series data を扱うために必要な embedding model の種類になります。他に質問があれば、画面下部の qand a tool に自由に投稿してください。うーん、e Eugene、あなたは多くの人と話してきましたし、多くの人が Novus を始めるのを助けてきました。多くの人がどこで苦労していると感じますか、うーん、そして彼らにどんな tips がありますか？うーん、うーん、そうですね、私たちは、ええと、ここで共有を止めます。
ええと、これについては少し触れたと思います。うーん、ほとんどの人は自分たちのデータをMOIsに取り込むのに苦労しています。ええ、これは私がよく受ける質問で、うーん、そして私が考えてきたことでもあります。つまり、この種の、うーん、この種の、ええ、課題にどう対処するのが最善なのか、ということです。そして、これに対処すること、あるいは人々が始めやすくすることを難しくしているものの一つは、単に、ええ、誤情報が多いということだと思います。そして、うーん、物事の捉え方が、まるで画像ベクトルやテキストベクトルが存在するかのように見せてしまっているんです。うーん、でもそれは正しくありませんよね。つまり、ベクトル自体は実際には数値なんです。そうですよね？そしてこれは、ええ、私がプレゼンテーションの中で何度か伝えようとしたことです。つまり、ほら、数値を取り出す、最後から2番目の層からの出力を取り出す、そして画像の、その埋め込み、つまり数値だったものです。そして入力を行ったとき、ええと、私は、デモをしたときには埋め込みを見せませんでしたが、うーん、画像とテキストは単に2種類の非構造化データにすぎません。
そして、それらをベクトルに入れると、すべて単なる数値の列になります。そして、この点について混乱がある理由は、画像ベクトルとテキストベクトルは通常長さが異なるからだと思います。そして私は今、これらのものは存在しないと話していたにもかかわらず、画像ベクトルやテキストベクトルという言葉を使ってしまいました。でも、画像データから作られたベクトル、画像データで訓練されたモデルは通常、テキストデータで訓練されたモデルとは、最後から2番目の層の長さが異なります。ええ、だからそれが私が見ている最大の課題の一つだと思います。うーん、もう一つの課題として、ええ、私がよく受ける、ええ、もう一つの質問は、LMSと埋め込みモデルについて、あるいは違いがあるのかどうかについて話す人たちです。あるいは、RAGに関しても、人々は「LLMは何をするのですか？これはベクトルデータベースだけでできますか？」と聞きます。ええ、そして、ほら、もう一つの選択肢、つまりその逆の選択肢として、「ああ、私はLLMを持っているのに、なぜベクトルデータベースが必要なのですか？」という質問も受けます。ええ、なのでその両方に答えます。
では、うーん、ベクトルデータベースについてですが、RAGを行うためにその上にLLMを置く理由は、例えば、ええ、私が質問するとします。ええと、うーん、すぐに良い質問が思い浮かびませんでしたが、ええ、「リンゴに最も似ている果物は何ですか？」とします。そして私の、そして、私のベクトルデータベースには、たくさんのテキストが保存されています。それが行うのは、意味的に最も似ている質問、または意味的に似ているテキストを取り出してくることで、おそらくそれは「オレンジに最も似ている果物は何ですか？」とか「トマトに最も似ている野菜は何ですか？」とか、ええ、そういったもの、あるいはトマトは果物である、といったものになるでしょう。うーん、でも、ええ、ほら、それは「ああ、実際に欲しいのは、appleという単語に最も似ているものを見つけたいということだ」とは言えないわけです。LLMが行うのは、そのクエリを分解して、「実際に検索すべきなのはこれです」と言うことです。それが意味的に似ているものです。そして逆に、なぜRAGのためにLLMの下にベクトルデータベースを置くのかというと、うーん、lmmはあなたのデータにアクセスできないからです。
それは、ええ、あなたが何に取り組んでいるのかを知りませんし、あなたが取り組んでいることのコンテキストも持っていません。ですから、ベクトルデータベースでは、あなたが行うのは、自分のデータを取り、それをベクトル化し、ベクトルデータベースに挿入することです。そしてRAGの最中に、検索によってあなたのデータを取り出します。検索拡張生成というのは文字通り、ベクトルデータベースから検索されたデータによって拡張された生成ということです。そしてそれをコンテキストとしてLLMのプロンプトに入れると、何らかの、より人間が読める応答が得られます。ありがとうございます。
ええと、Rishiにいくつか質問があります。ええと、彼らはGoogle collabで問題にぶつかっています。ええと、チャットにいくつか詳細があるので、あなたにざっと見てもらえます。ええ、これは単なる依存関係の問題です。ええと、おそらくそこでPIをpip installしたいでしょうし、もしかすると、ええと、そこにどんなライブラリがインストールされているか確認するとよいかもしれません。
Rishi、ええと、それから質問があります。VUSsはLLMに依存しないのですか、それとも、ええと、特定のタイプのLLMでより良いパフォーマンスを発揮するように使われるものですか？ええ、Vissは完全にLLMに依存しません。LLMは、つまり、LMSとベンチャーデータベースは完全に分離されています。ええ、なので、そこには、特定のLLMより良いパフォーマンスを発揮するということはなく、何でも持ち込めます。素晴らしい質問です。
ええ、埋め込みモデルについても同じです。これも完全に埋め込みモデルに依存しません。使いたい埋め込みモデルを何でも使うことができ、同じ結果が得られます、いや同じ結果ではなく、でも、ほら、同じ品質の結果が得られます。では、Eugene、あなたはたくさんのプロジェクトをやってきました。ええと、そのいくつかは画像ベースで、いくつかはテキストベースで、その多くはTaylor Swiftベースで、ええと、Taylor Swiftです。
新しいプロジェクトを始めるとき、どうやって、埋め込みモデルの選び方をどのように考えていますか？つまり、ある種、継続的に同じようなものを使う感じですか？あなたのリサーチのアプローチはどんなものですか？というのも、特にオープンソースモデルの世界では、今は本当にたくさんの選択肢があると知っているので。では、選ぶことをどのように考え、何を見ているのですか？ええ、ええと、それは素晴らしい質問です。なので、私はもうBenningsモデルではあまり多くの実験はしていません。主な理由は、昨年、基本的に数か月間、Bettyのモデルで遊び回っていたからです。ええと、それが実は、今一緒に見てきたデモが生まれたきっかけでした。というのも、私は「ああ、ほら、面白そうだ、いくつかのBettyのモデルを比較して、それらがどれくらい違うのか、どれくらい似ているのか、その他いろいろ見てみるべきだ」と思ったからです。
ええと、そして、ええと、テストをするとき、私が実際に見ていたこと、私が、私がもっと実験をしていた頃に見ていたことの多くは、ええと、ほら、これは、これは筋が通っているか？というようなことでした。たとえば、ええと、画像を扱っていたとき、あの絵画のものですが、「これは筋が通っているか？」について考えたことは、似たような絵画を与えるなら、返ってくると期待している絵画がトップ3の中に返ってくるほうがいい、ということです。つまり、見た目が、ほら、似ているということです。なので、テストに使ったものはガリラヤ湖のSkiだったと思います、ええと、そして私は「ああ、船があるはずだし、水もあるはずだ」と思いました。ええと、そしてテキストの場合はもっと、ええと、ほら、ええと、これは筋が通っているか、みたいな感じです。つまり、これは筋が通っているか？テキストが返ってくる、つまり、それは、それの多くはただ人間的なものです。これは筋が通っているか？現在、実際には、人々が考案している評価手法があり、LMSを使ってLLMからの結果と埋め込みモデルからの結果を評価します。
しかし、その課題は、その評価手法がragアプリ全体、ええと、アプリ、スタック全体を評価してしまい、埋め込みモデルだけを評価するわけではないということです。そして実際、私は、埋め込みモデルについては、自分の埋め込みモデルが良いのか、適切な埋め込みモデルなのかを判断するのは実際とても難しいと思います。ええと、そして埋め込みモデルで何をすべきかに対する本当の答えは、特に、ええと、エンタープライズ本番環境では、自分自身の埋め込みモデルを作成するか、オープンソースのものをファインチューニングし、互いに関連付けたいDIデータタイプ、互いに関連するものを確実に入れることで、あなたの潜在空間で動作するものを得ることです。素晴らしいです。ええと、もう1つ質問があります。
Vector DBを可視化してナレッジマップを作成する方法はありますか？ええ、あります。ええと、つまり、作成できます。ええと、ええと、単に見るだけなら、文字どおりHNSWインデックスを見るだけなら、それは基本的にナレッジマップです。ええと、ただ別の方法としては、できることとして、実際にすべてのベクトルを取得してダウンロードし、それらを3次元空間にマッピングして、ええと、それを、ええと、ああ、それを可能にするものは何でしたっけ？map pot libなら3次元空間を扱えると思います。map pot libでできると思います。ええと、なのでそれらをダウンロードして、マッピングし、それから3次元空間にプロットして、クラスタがどのように見えるかを確認できます。
ええと、そしてこれは実際、多くの、ええと、評価手法の基礎でもあります。ええと、それは、ええと、ええと、ええと、ええと、多くのオープンソースの評価、ええと、ライブラリが行っていることに似ています。Galileoにも可視化ツールがいくつかありますよね？はい。なのでGalileoとArise Phoenix、ええと、それからTru True LensとY Labs、Y logsはすべて非常によく似たことをしていて、ええと、基本的にその可視化を可能にしてくれます。素晴らしい質問があります。
ええと、Vissは何の上に構築されているのですか？MongoDBですか？ああ、はい。実は、Atlasがベクトル検索にVissを使うという話を聞きました、ええと、MongoDBがベクトル検索にTOXs Vissを使っていたと。ええと、でもVissは構築されています、これは実際には、ええと、ゼロから、つまり、特にベクトルのために目的に合わせて構築されていますよね？つまりMongoDBはNoSQLデータベースとして構築されており、キーからキーへの検索のために作られていて、その上にベクトル検索を実装しなければなりません。それは、ええと、たとえば、ああ、すべてのベクトル、またはすべてのエントリを検索する、みたいなことをせずに実行できるようにする必要があります。ええと、なので私たちはベクトルで動作するようにネイティブに構築されており、KafkaやMin io、ええと、KafkaまたはPulsarのようなものの上に構築されています。ええと、VUSはpub subsystemとしてモデル化されているので、つまり、データをpublishして、それはストリーミングデータのようなもので、そのまま流れていきます。
そして本質的には、もしMediumアカウントを持っていると考えるなら、Mediumアカウントで物事をpublishしていて、それからsub、ええと、subscriberがいて、それはたとえば、あなたのMediumアカウントを追加している人たち、あるいはあなたのMediumのpublicationをリストか何かに追加している人たちのようなものです。ええと、なので、はい、それが、ええと、それが、VISが構築されている方法を考える一つの捉え方です。ええと、おそらく今後のセクションで、より、ええと、Vissについてもう少し時間をかけてディープダイブすることになるでしょう。ええと、ただNovusは既存のデータベースの上に構築されているわけではありません。ゼロから構築されています。
それに少し付け加えると、ええと、私たちが、ええと、創業者や初期の開発者たちがそのアプローチを取った理由は、本当にスケールに対応できるようにするためでした。なので、新しく出てきているベクトル検索ツールはたくさんあると思いますが、ええと、それらはおそらく非常に小さなデータセットでは問題なく動作するでしょう。ええと、それはVissの意図では決してありませんでした。本当のVissは、実際には10億、100億規模を想定しています。なので、たとえば10万ベクトルがあるなら、多くの、多くの選択肢が使えます。ええと、しかし10億、50億、100億、ええと、規模について話しているなら、そして、ベクトルデータ専用に目的特化して構築されていることは本当に重要です。
なので、そこが私たちの専門領域です。ええと、いくつか見てみましょう、ええと、Vector database expertとは何を意味しますか？SQL Server expertと同じですか、それとも完全に異なりますか？完全に異なります。ええと、ええと、これらはほとんど互いに関係がありません。ええと、SQLは、SQLデータベースは、batchデータベースが構築される意図と同じ意図でさえ構築されていませんよね？つまりSQLデータベースは、既知の属性を持つエンティティを保存し、それらと関係を作成できるようにすることを意図して構築されています。クエリ時に、ベクトルデータベースは、エンティティのセマンティックな意味を数値のリストとして保存し、クエリ時にこれらのベクトルを比較できるようにするためのものです。したがって、これら2つのデータベースの背後にある意図はまったく異なります。
ええと、データベースの保守もおそらく少し違うところがあります。ただし、バックエンドでDevOpsを行うという点では、コンテナ化や、スケーリング、オートスケーリング、そしてこうしたすべてのことは非常に似ていると言えるかもしれません。ええと、他のベクトルDBとの性能比較に関するベンチマークはありますか？Vector DB benchについて話しますか？はい。はい、話します。Vector DB benchがあります。実はそれは、私が言及しなかったスライドに載っていた、Zillowsが維持しているオープンソースプロジェクトのリストに入っていました。ええと、ああ、それ、ええ、ありがとう、Emily。
はい。ですので、ええと、私たちには利用できるオープンソースの、ええと、ベンチマークツールがあります。それを使って、すべてのベクトル、ええと、データベースを比較できますし、自分のデータを持ち込むこともできます。ええと、オープンソースなので、ええ、ぜひ見てみてください。さて、そろそろ時間のようです。どうやら、ええと、本日の質問はすべて終えられたようです。
ええと、本日はご参加いただき、皆さんありがとうございました。今後の、ええと、ウェビナーでまたお会いできることを願っています。今後開催予定のすべてのセッションは zillows. com/event でご確認いただけます。今月の少し後に、ええと、テキスト埋め込みに関するものもあります。
ええと、Eugene、改めて素晴らしいセッションをしていただきありがとうございました。そして皆さん、次回またお会いできることを願っています。ありがとうございました。皆さん、ご参加ありがとうございました。
Meet the Speaker
Join the session for live Q&A with the speaker
Yujian Tang
Developer Advocate at Zilliz
Yujian Tang is a Developer Advocate at Zilliz. He has a background as a software engineer working on AutoML at Amazon. Yujian studied Computer Science, Statistics, and Neuroscience with research papers published to conferences including IEEE Big Data. He enjoys drinking bubble tea, spending time with family, and being near water.