Milvus 2.4で高度な検索機能を解き放つ：高速化されたGPU検索、マルチベクトル検索、そしてその先へ
セッションについて
ZillizのVP of Engineeringが登壇する技術ウェビナーにぜひご参加ください。本セッションでは、Milvus 2.4の革新的な機能について解説するだけでなく、実際の動作もデモでご紹介します。このセッションは、検索機能を強化し、非構造化データの課題を習得したい開発者向けに設計されています。ライブデモを通じて、新機能を効果的に活用する方法を示し、概念と実践的な応用の両方を理解できるようにします。
主なハイライト:
- NvidiaのCAGRAによる高速GPU検索: GPUアクセラレーションで検索パフォーマンスを向上。
- マルチベクトル検索: 単一のコレクション内の複数のベクトルフィールドに対してクエリを実行。
- 多様な検索結果のためのGroupby: 大規模データセットで検索結果を多様化するためのグルーピング戦略を実装。
- スパースベクトル対応: SPLADEv2のようなスパースベクトルモデルを統合し、情報検索を改善。
このインタラクティブなセッションでは、膨大な非構造化データセットから効率的に情報を検索・取得し、検索精度を高め、Milvus 2.4の機能によってAIアプリケーションのパフォーマンスを向上させるための知識を身につけることができます。
このセッションで皆さんにご紹介できることをうれしく思います。ええと、Milvus 2. 4 による高度な検索機能の解放についてのセッションです。ゲストスピーカーは James で、Zilliz の VP of Engineering です。ええと、James は Oracle Head と Alibaba Cloud でデータベースエンジニアとして豊富な経験を持っています。ええと、James はまた、Alibaba Cloud のオープンソースデータベースである hatch base と、landform および自社開発の NoSQL データベースの開発において重要な役割を果たしました。彼はまた、Linux Foundation の技術諮問委員会、ええと、AI and Data Foundation の尊敬されるメンバーでもあり、そこで AI とデータ技術の未来を形作るために専門知識を提供しています。
James、ようこそ。このステージはあなたのものです。こんにちは、Stephen。はい、皆さんこんにちは。ええと、James です。ええと、サンフランシスコ・ベイエリアに拠点を置いており、ええと、過去3年間そこで働いています。
それで、ええと、現在は、ええと、mul プロジェクトのチーフアーキテクトであり、メンテナーでもあります。はい、皆さんとお話しできてうれしいです。mul について、mul 2. 4 について何か質問があれば、ええと、このセッションで議論できます。いいですね。Steven？はい。
James、今から画面を共有しますか？リリースの違いについて確認できます。もちろんです。はい。実は、ええと、短いデッキが1つあります。はい。
でも、ええと、はい、ええと、MES 2. 4 のハイライトのようなものがあります。Stephanie、紹介を私がするほうがいいですか、それとも？はい、もしよければ、ええと、ハイライトに直接入ってもらっても大丈夫です。はい。はい。
ええと、私たちは最近、MI was 2. 4 のリリース候補をリリースしたばかりです。まだ最終版ではありませんが、ええと、うまくいけば、ええと、GA 版は来週出る予定です。これは実際、UMM was 2. 3 と比べて長いバージョンです。
私たちは約6か月をかけて、ええと、このすべてに取り組んできました。大きな変更点は、私たちが、私たちが、私たちは、マルチ、ええと、マルチベクトルをサポートし、また meals 内部でリサーチ、ええと、を持つようになったことだと思います。なぜなら、ええと、meals 2. 4 以前は、ええと、各ロールまたは各エンティティは1つのベクトルしかサポートできず、マルチモダリティと re アプリケーションが非常に人気になると、すぐに、ええと、ユーザーは実際には自分のデータを説明するためのより良い方法を求めていることがわかりました。それは1つのベクトルだけではなく、おそらく、ええと、異なるインバウンドモデルに基づくもの、または単に属性、または単に、ええと、異なる特徴などです。
そこで、このマルチベクトルがあります。ええと、dense だけでなく sparsing manning をサポートしているので、より良い検索品質を得られます。ええと、rack アプリケーションにとって優れた機能であるグルーピング検索をサポートしました。すべての、ええと、scatter データの上に inward index をサポートしました。ですので、ええと、フィルタリングを行うときに、実際に高速化するのに役立ちます。
また、ええと、ファジー検索、ええと、ファジーフィルタリングもサポートしました。ですので、ええと、それらすべてに正規表現を使用できます。はい、そして 2. 4 で最もエキサイティングな機能は間違いなく、ええと、GPU Index です。私たちは Evid チームと協力しており、彼らは実際に、ええと、evid GPU 上のベクトル検索アルゴリズムを提供しています。実際、非常にうまく動作し、10倍高速です。
ええと、小さなバッチで実行している場合は、簡単に 50倍の、ええと、QPS、ええと、サポート増加を達成できます。オフライン作業を行おうとしている場合、大量のバッチがあるなら。では、ええと、すべてのステップを見ていきます。これらは、AI、ええと、JI アプリケーションをより良く行うのに役立ついくつかの機能です。はい。全体的な目標として 2.
4 は、ええと、より JI アプリケーションのユースケースに焦点を当てています。つまり、racks を行いたい、あらゆる種類のモデリングモダリティ検索を行いたいユーザーを支援しようとしています。ええと、より多くの検索コールとパフォーマンスで、より多くのセマンティクスを使用します。はい。そうですね。
では、ええと、各機能について、多少、ええと、詳細に入っていきます。ええと、最初に、ええと、言及すべきなのは実際、ええと、マルチベクトル検索とハイブリッド検索だと思います。なので、ええと、直前に言ったように、それぞれのベクトル、それぞれのインターネットにはベクトルが1つしかありませんが、いくつかのユースケースでは、そうですよね？あなたの写真の1つに対する説明があり、あなたの、写真があり、そして多分それは、異なる角度からのものですよね？ここで何が起こるか見てみましょう。Tesla があるとき、説明もあり、ええと、検索が起こるとき、それはテキストで検索するようなものかもしれませんし、テキストからテキストかもしれませんし、テキストから画像かもしれません。はい。
その前は、複数のコレクションを作成しなければならず、ええと、独自のランキングモデルを開発しなければなりませんでした。なので今できることは、1つのロールの中に、複数の埋め込みを保存できるということです。検索が起こると、それは、ええと、両方から、ええと、両方の、ええと、少数から取得します。そしてそれらは再ランキングアルゴリズムを行い、あなたが、トップ、トップ、トップの重要な候補のようなものを見つけるのを助けます。はい。
この機能によって、モダリティのユースケースをモデリングするのにはかなり良いです。例えば、red をやっている場合、1つの埋め込みに high を入れて、たぶん、ええと、他の demanding を追跡できます。検索品質の改善に役立ちます。そしてモデリング、ええと、ベクトルで作業する上で最もエキサイティングな部分は、異なる埋め込みモデルを持てることです。Open AI を、ええと、cohere と一緒に使うことができます。
なので、ええと、その両方がいくつかの異なる素材を見つけることができ、そしてあなたは、ええと、ええと、検索して、ええと、より興味深い候補を得ることができます。そして Disney venning と Sparse venning も使えます。はい。そして、それから、ええと、出てくるのは、うーん、sparse venning です。はい。
なので、ええと、その前は、私たちがサポートしている埋め込みのほとんどは、ええと、dense だけでした。battery venning もあり、これは最近とても人気があります。しかし、ええと、ユーザーのほとんどは、ええと、dense mans だけを使っています。dense について話すとき、それはつまり、うーん、各、ええと、各次元に何らかの値があるということです。うーん、それは、実際には浮動小数点数です。ええと、中にゼロはなく、dense mans はつまり、うーん、ええと、機械モデルから来ています。
ええと、それは、ええと、ええと、よりセマンティクス向けです。ええと、なぜなら、うーん、dancing balance を生成するとき、これらのコンテキストも持っているからです。なのでこれはこの単語だけについてではなく、文について、または、うーん、ええと、段落についてでもありますよね？しかし、うーん、多くのユースケースの下では、ええと、私たちはまだキーワード検索を望んでいたり、あるいはまだ詳細に集中したいと思っています。うーん、それが、あなたが、私たちが、ベクトル d、dbs と elastic search、さらに solar、さらにあらゆる種類の他の検索検索エンジンの間でハイブリッド検索を行う理由ですよね？しかし今は sparse meetings があります。なので sparse meaning がすることは、ええと、まず第一に、それは疎です。つまり、ほとんどの次元がゼロになるということです。はい。
しかしそれはなぜかというと、うーん、sparse meetings では、実際に辞書を持っているからです。つまり各トークンが実際には1つの次元です。なので、もし皆さんが、ええと、birds が持っているものに詳しければ、ええと、各、各、ええと、bird は通常およそ 30 K トークンです。つまり、私たちの sparsing mannings もおよそ 30 K 次元ということです。それは dancing Mannings と比べて、かなり大きな、はるかに大きな次元を持っています。
通常、密度医療は 7、6、8、あるいは、えー、15 K 36 になるわけですよね？でも Spartan embeds の場合は、えー、次元がより大きいのですが、幸いなことに次元のほとんどはゼロになります。つまり、このコーパス、あるいはこのクエリはそのトークンとは関係がない、ということですよね？ですから、各トークンに 1 つの重みを使うことで、えー、スパース化によって、より詳細に、あるいはキーワードに、トークン検索に、よりフォーカスできるわけです。つまり、彼らは、えー、たとえば、えー、クエリ、えー、クエリ埋め込みと、えー、埋め込みが送る、その、えー、コーパス埋め込みの間で非常によく似たトークンを見つけようとしているわけですよね？これは非常に役立ちます。えー、もし、たとえば、えー、昨日見た映画を検索したい、と言いたい場合ですね？Dancing Mannings のユースケースのいくつかは理解しています。昨日の映画だけでなく、一昨日の映画、あるいは去年の映画まで出てきます。なぜなら、えー、それはセマンティクス上ではまだ非常に近い、あるいは非常に似ているからですよね？えー、昨日見た映画と、一昨日見た映画ですね？でも Sparts Mans では、えー、yesterday がキーワードになります。なので、実際に検索したいものを絞り込めます。はい、これは非常に役立ちます。
多くの、えー、react のユースケースでは、制御された回答を得たいわけですよね？重要な情報を実際に伝えるキーワードにフォーカスしたいわけです。そして S Spark meetings のもう一つ良い点は、実際に dancing embeds と一緒に使えることです。つまり spar meetings はすべての詳細にフォーカスし、その一方で embeddings は、えー、コンテキストを得るのを助けることにフォーカスします。そして両方の embeddings から検索すると、異なる種類の情報を選び、ランキングを行って、最も、えー、関連性の高い情報を得るわけです。はい。オーケー。
それで、えー、3つ目は、実はグルーピング検索も、えー、興味深いユース、えー、ユースケースの一つです。えー、direct を行うとき、えー、おそらくすべてをチャンク化することになります。文書のチャンクを入れて、そのチャンクも埋め込みます。えー、ただ問題は、そこで top、top 10 クエリを行うと、1つの文書、あるいは1冊の本からすべてのチャンクが返ってくる可能性があるということです。つまり、多様性を失うわけですよね？この多様性があれば、間違いなくもっと多くのことができますし、再ランキングもできます。えー、ユーザーにそれを見せることもできます。そうすれば、彼らはどの文書、あるいはどの本が実際により関連性が高いのかを選べます。でも、起こり得ることとしては、最も関連性の高いものが1冊の本、または1つの文書だけから来ている、ということです。
はい。そこで今、Group by という新しい機能があります。データモデルにフィールドが1つあれば、それは document id でも book id でもよく、検索が発生したときに、この book id で group by できます。つまり、上位10件の最も関連性の高いチャンクを返すのではなく、最も関連性の高い文書、あるいは最も関連性の高い、えー、本を返すわけです。ですので、私たちが行っているのは、えー、えー、それはどちらかというと従来のデータベースに近いものです。
つまり、実際には最も関連性の高いすべてのチャンクを反復処理し、リレーショナルデータベースのようにすべてを groupby しようとします。はい。それで、えー、その出力には通常、えー、group、group id があります。それはあなたの場合の document ID であり、また、このグループ内の最も関連性の高いチャンクも含まれます。はい。James、ここで少し止めます。
チャットからすぐに質問があります。えー、それは、クエリ時に qua のスコープを何らかの形で制限できますか、たとえばワークスペースごとのクライアントやグループごとに、というものです。はい。えー、すみません。できますか、できますか、えー、質問を繰り返します。えー、何かをクエリするときにスコープを制限できますか？たとえば、ワークスペースごと、クライアントごと、またはグループごとに制限できますか？えー、私は、その質問を理解できているか分かりませんが、えー、あなたが実際に尋ねているのは、えー、マルチテナントについてだと思いました。たとえば、1つの collection に複数のテナントがある場合、えー、私のクエリをデータの一部だけに制限するには、えー、何が起こるのか、ということです。私、私、それで合っていますか？それが私の想定です。
はい。なので、ええと、はい、私が、ええと、もし、もし私が正しければ、ええと、もっと情報をください。でも、ええと、はい、つまり、私が言っているのは、ええと、新しい2.3で提供した別の機能を使う必要があるということです。それは、ええと、production keyです。この機能では、多くのRAGアプリケーションがマルチテナントのことをやっていると知っているので。複数のユーザーがいて、彼らは、絶対にお互いのデータを見たくありません。
はい。なので一番簡単な方法は、接続を作成するところです。1つのpartition keyフィールドがあります。なので、ええと、検索が発生するときに、どの、どの種類のpartition keyかを指定します。それはナレッジベースかもしれないし、user idかもしれないし、ええと、agent idかもしれないし、何でもよくて、ええと、それは、ええと、本当により多くのテナントを持つことになります。
それは、1000テナントになるかもしれないし、あるいは、ええと、10万テナントにさえなるかもしれません。なので各テナントは、ええと、それぞれ自分のprotection keyに留まります。そして検索が発生するとき、protection keyを指定すれば、すべての結果はただ関連するものになります。はい。いいですね。
ありがとうございます。それから、group grouping researchに関連する別のものがあります。ええと、grouping searchはmulti vectorYでサポートされていますか？はい、それは、ええと、それは、ええと、はい、実際、ええと、サポートされています。はい、実際サポートされています。なので、ええと、私たちは実際、ええと、density manningsのサポートから、ええと、始めました。spars meetingsもサポートしていますし、ええと、brand embedsもサポートしています。
なので、ええと、それがGAになるときには、ええと、すべての種類のembeddingsをサポートすることになると思いました。いいですね。ありがとうございます。では、ええと、先に進みましょう。はい。
もし、ええと、他に質問があれば、ただ、ええと、入力して、ええと、タップして、ええと、はい、私は、後で他の質問を確認します。はい。わかりました。ではそれが、ええと、何を、ええと、何を、どのようにこの、ええと、ええと、grouping searchを使うかということです。なので、はい、ええと、1つのフィールド内に、ええと、データを持つ1つのcorrectionがあります。
また、この、ええと、ええと、group byフィールドもあります。これは通常、出力が来るときのdocument idで、document IDsとpassenger idも要求します。これはchunk IDsのようなものですよね？なので結果は、ええと、以下のように見えます。つまり、ええと、euro a、ええと、1、ええと、distance pass one I、ええと、1つのdocument IDと、1つのpassenger idです。なので、どのdocumentが実際に最も関連性が高いか、そしてこのdocument内のどのchunkが実際に関連しているかがわかります。Okay。なので、ええと、もう1つの興味深いユースケースは、ええと、fuzzy matchingsと、ええと、inward indexのためのfuzzy searchです。
なので、ええと、AVコミュニティのおかげで、現在、非常に高性能な、ええと、inward indexがあります。これらと非常によく似ていますが、Rustで保持されています。はい。なのでついに、ええと、sも、ええと、Rustコミュニティの一部です。なので、ええと、この、the word indexは非常に、非常に優れたfeaturing performanceを提供します。ええと、右側のグラフが示すように。なので、ええと、もし大量の、ええと、ええと、文字列、大量の、ええと、整数wordingをフィルタリングしようとしているなら、それは間違いなく役立ちます。
唯一のエッジケースは、仮想条件が結果のたとえば50%以上に一致する場合で、その場合はWord indexを使うのはあまり意味がなく、すべてのデータに対して直接フィルタリングすべきです。なぜなら、Word indexでは低カーディナリティ向けにかなり偏って機能するからです、そうですよね？それで、もう一つ私が思いつくのは、AVIがファニー検索をサポートしているので、今ではprefixフィルタリングだけでなく、postfixや、Filterings内で非常に単純なrapid制約を使って、何らかのweb cardで始まり、別のwell cardのようなもので終わる、といったこともサポートしています。つまり、emerging indexはfile searchのパフォーマンス向上に役立ちます。また、多くのユースケースでかなり重要です。特に、vector dbs内にchunksがある場合です。そうすると元のコンテンツが何かはだいたい分かっていて、その時点で特定のキーワードを探しているだけです。たとえば、further searchとwording indexはパフォーマンス向上に役立ちます。prefixと比べると超高速になるわけではありません。選択肢があるなら、間違いなくprefixを使い、間違いなくexact matchを使ってください。
ただし、データがすでにそこにあり、検索したいなら、少なくとも選択肢が一つあります。はい。GPU indexです。多くのユーザーが、GPUを使うと有益なのかどうかについて質問しているのは知っています。2. 4以前では、答えは実際には、いいえ、です。GPUは実際にははるかに高速ですが、はい、多くの制限もあります。
コスト効率は実際には良くありません。GPUは高すぎます。また、非常に小さいbatchの場合、GP indexは通常、main memoryとGPU memoryの間でデータをコピーするのに多くの時間がかかります。つまり、完璧な解決策ではありません。少なくとも2.
4以前ではそうではありません。はい。ここ最近6か月、私たちはvidチームと非常に密接に取り組んできました。彼らは実際にcwaというこの派手なGPU indexを持っています。詳細については、こちらでも確認できます。そうですね、このC indexを統合して分かったのは、まず試そうとすると、実際に100倍高速だということです。
graph indexを使おうとすると、HWと比べて本当に10倍高速です。VF indexesを使っている場合は、30数倍高速です。そして私たちはAR a hundredと、最新のinference cardであるL 40の両方でテストしました。L 40、T 4 8 10、これらはGPU上のvector searchに非常に適したcardsであることが分かりました。はい。そしてそのようなシナリオで、大きなbatchがあり、非常に高いGPSがあり、search latencyを安定させたい場合、CPU indexが選択肢になるかもしれません。ぜひテストしてみてください。はい。では、いくつかの数値です。まず、上部にある最初のものは、実際にはCPU agentで、CPU index向けのsortのようなものです。
はい。eight 10がある場合、または、があり、flatを実行している場合、つまりGPU上で100%正確であるということですが、それでもCPU Graph indexと比較して非常に似たパフォーマンスを得られます。そして、GPUを使って何らかのa in searchを行う場合、そうですね、最後の行を見てください。これは私たちが得た数値で、a 100 plus categoryはCPU engineと比べて10倍、10倍高速です。W、はい。つまり、それがコツです。
高いrecallを求めているなら、fighting indexには間違いなくGPUを使ってください。非常に高いパフォーマンス、安定したlatencyを求めているなら、はい、間違いなくcover indexを選んでください。はい。ただし、大きな欠点も一つあります。DP indexを使う場合、すべてをTP memoryにpingしなければならないということです。
ご存じかもしれませんが、そのDPメモリは実際には非常に、あなたのユースケースに基づくものです。レコメンデーションシステムを構築しようとしている人をたくさん知っています。DPインデックスは彼らにとって完璧でしょうが、ただracksをやっているだけなら、あまり良くないかもしれません。というのも、ほとんどのrackアプリケーションでは、パフォーマンスと比べてコスト効率のほうが実際にはより重要になると思うからです。はい。そうですね。
それでコスト効率の話になります。はい。この、ええと、m mapソリューションがあります。その前は、ベクトルのすべてのデータを直接メモリにロードしていました。このインデックスを使っていたとしても、元のデータは、ええと、この上にありますが、メモリ内にもより小さなインデックスがあり、それは多くのストレージリソースを消費します。しかし、ユースケースによっては、パフォーマンスをあまり気にせず、ただコストを下げたいだけなら、もう一つの選択肢は、すべてをローカルディスクにマッピングすることです。それでも検索可能です。
ええと、これは実際には、オペレーティングシステムのページキャッシュとディスクの間でスワップイン、スワップアウトしています。他のインデックス上のHWと比べると実際には遅くなります。しかし重要なのは、ほとんどパフォーマンス低下なしに、ベクトルDBに保存できるベクトルが4倍、4倍になるということです。例えば10%、20%くらいです。はい。
ただ、ただ、ただ覚えておいてください。もしそのmapだけを使うなら、非常に高性能なディスクを使う必要があり、それはe SSDsになるでしょう。ええと、任意の、たとえば、EBSがそれにどれほど適しているかはわかりませんが、動かすことはできません。ですが、AWSや他のクラウドで実行している場合は、IO twoか、あるいはローカルSSDsを使うことを間違いなく推奨します。メモリと比べるとかなり安くなります。はい。ただ、ええと、そしてhyperを使うと、同様のパフォーマンスが得られます。レイテンシのようなものは少し、少し低くなりますが、実際にはずっと安価です。
はい。そうですね。もう一つのエキサイティングな機能は、ええと、変更データキャプチャに関するものです。つまり、ええと、データがmilsに書き込まれると、多くのユーザーが、どうやってデータを取り出せるのかと尋ねています。もしかすると、uscのものとEuropeのもの、2つのmilsクラスター間でデータの一貫性を保ちたいかもしれません。それはユースケースの一つにすぎません。他のユースケースでは、ユーザーが増分バックアップを行いたい場合があります。
そこでCDCがあります。CDCは、実際にはあなたのログからのサブスクライバーです。ええと、皆さんが、ええと、my logや、ええと、Postgresログに非常に詳しいなら、すべてのデータベースにはそれぞれ独自のRed hat loggingがあります。ですので、ええと、CDCはこれらの、ええと、red hack loggingをエクスポートし、それらのログを別のmillsクラスターに配信でき、そこですべてのログを消費できます。ええと、CDCはバックアップと連携できます。
ええと、つまりバックアップにはフル、フルデータがあり、ええと、そして、ええと、CDCはストリーミングデータまたは増分部分をカバーしますよね？ですから、すべてのデータをまとめると、それが、HRとストリーミングの両方について、すべてのデータセットになるわけです。そうですよね？ですので、ええと、これはそれらのクラウドで広く使われることになるでしょう。また、私たちはこれを顧客レプリケーションのために使っています。これを、ええと、増分バックアップのために使っています。ですので、これらの、ええと、gridツールを提供しています。ええと、クラウド上のあなた自身のユースケースでは、何らかの特別な、ええと、co、ええと、co、ええと、I実装が必要になるかもしれません。
私たちはそれらをすべて無料で用意しています。ですので、ええと、CD Cを使う簡単な方法は、それらのコードを使うことですが、それでも、実際にはAP Apacheライセンスの下でオープンソースです。ですから、もし皆さんの誰かが、自分のアプリケーションを調整したいのであれば、CDCは賛成です、はい、あらゆる種類の異なる操作をサポートしています。great job collectionsがあり、insertions、tions、ええと、あらゆる種類のメタ操作があります。ですから、それらすべての情報をサブスクライブするだけでよいです。
それは、ええと、そしておそらく、ええと、そして、他のシステムと統合できます。はい。わかりました。ええと、ここで止めます。つまり、これらは、私が思うに、ええと、2についてはほぼこんなところです。
4つの機能、I、3.0のロードマップについては別のページがありますが、ここで止めて、ほかに質問があるか見てみましょう。ありがとうございます、James。ええ、はい、チャットにあといくつか質問があります。ええ、そのうちの1つは、これもまたionキーに関連しています。つまり、1つのクエリで複数のパーティションキーを指定できるか、という質問です。
はい。各コレクションは1つのパーティションキーのみをサポートしています。それが現在の制限です。ただし、フィールド条件も使えます。ベストプラクティスとしては、ええ、マルチテナントの、ええ、ユースケースをやろうとしている場合は、1つの、ええ、パーティションキーを使うことだと思います。通常は、そのパーティションキーに基づいて、ほぼすべてをクエリすることになります。
ええ、ベストプラクティスは、ええ、テナントid、ええ、ナレッジベース、そのような情報です。そしてその下に、ほかの、ええ、式や条件がある場合は、単に、ええ、ええ、フィルタリングを使えます。複数の異なる、ええ、フィールドを持つことができます。一部のフィールドは、ええ、たとえば、もし、もしあなたが、ええ、本の、ええ、レコメンドシステムを構築しようとしているなら、ええ、authorフィールドがありますよね？また、ええ、ええ、pagesのようなものもあるかもしれませんよね？ええ、メタ情報として、ですね。なので、検索が発生したときには、単に、ええ、式としてpage equal to one、author is、ええ、JKのようなものを指定できます。はい。
いいですね。ありがとうございます。そして、ファジーマッチングと、そのインデックスのスライドに戻るのですが、ええ、brute、brute forceが何を意味するのか説明してもらえますか？ええ、埋め込みインデックスのパフォーマンスに関する、ええ、グラフがあり、ここにbrute forceと書かれています。説明していただけますか？はい。つまり、つまり、つまり、ええ、いくつかの、ええ、いくつかの条件でフィルタリングしたいということです。
そこで私たちが行うのは、ええ、まずbrute、ええ、brute force searchです。つまり、私たちがやるのは、単に、ええ、各integerを取得します。たとえばintegersフィールドだとして、あなたが持っている式の種類に基づいて、それぞれを1つずつ比較します。たぶん単に、ええ、a equals to oneかもしれません。つまり、私たちは、ええ、この、ええ、フィールド、ええ、field aの、ええ、row a、ええ、row oneを取得して、ええ、それが1に等しいかどうか比較します。もし、もしそれが等しければ、そのフィルターは通過しますよね？それ以外の場合は、2つ目の行に進みます。つまり、すべての行を処理し終える、というのが、ええ、brute forceで行っていることです。
ええ、理想的には、それは、それはそれほど簡単ではありません。なぜなら、送信命令に大きく、ええ、依存しているからです。なので、おそらく私たちが行うのは、8つの、ええ、異なるphone numbersを同時に比較することで、それによって実際にパフォーマンスが向上します。はい。ただ、その意味で実際にあるものは、ええ、かなり異なります。なぜなら、私たちは、ええ、すべてのデータの、ええ、順序を変更するからです。つまり、equal to oneであるすべてのデータをまとめて置きます。
なので、equals to oneを要求したときに、すべてを通して本当に計算する必要はありません。equal to oneのすべてのデータを取得して、それをbit setに入れるだけでよいのです。つまり、データ、データレイアウトを変更したため、実際にはずっと高速です。ああ、ありがとうございます。ええ、ありがとうございます。
ありがとうございます。まだ質問はありますか？ええ、ああ、はい。1つ、ええ、これらの機能のうち、現時点でZills Cloudで利用可能なものはどれですか？そして、もしまだであれば、いつ利用可能になりますか？それは良い質問です。ええ、では、ええ、私たちが今行っているのは、ええ、open sourceと比べてZills Cloudは2か月または3か月遅れるということです。その理由は、ええ、open sourceについては、I、たくさんの、ええ、新機能を使いたいユーザーがいることを知っています。なぜなら、彼らはまだPOC段階にあるからです。
彼らは、安定性が非常に重要になるとはいえ、それほど気にしません。しかし、ええ、多くのユーザーはそれを、ええ、自分たちのテスト環境に使っています。たとえそれが、ええ、十分に安定していなくてもです。それはまだrelease candidateです。はい。なので、私たちはすべてをできるだけ早くリリースしようとしています。
しかし zes cloud については、ええと、物事を、ええと、安定したエンタープライズ対応の状態に保ちたいと考えています。はい。私たちは、ええと、ベストプラクティスを提供したいのであって、ええと、現実的でないものや、あまり安心して使えないものにはしたくありません。そのため通常、すべてをこの状態に持っていくまでにさらに2、3か月かかります。はい。
私たちは、5月初旬にそれらの機能を ize しようとしました。はい、アップグレードするかどうかは選択できますが、ええと、すべてのクラスターを、ええと、2. 4 に入れるには、たぶん、ええと、さらに3マイルは seal します。はい。いいですね。
ありがとうございます。ええと、誰かが質問しています、ええと、partion サイズの制限はありますか？ああ、わかりました。では、ええと、または少し違うものですね。これは別の、ええと、マルチテナントのユースケースだと思いました。マルチテナントを行うには、実際には2つか3つの異なる方法があります。
1つは cloud multiple collections を使う方法、もう1つは predictions を使う方法です。これらは実際には非常に似たものになります。なので私の提案としては、もしテナント数が確実に1000未満、もしかすると10より少し多い、ええと、1000くらいであれば、collections を使って accelerations を行うことです。それは本当に、ええと、SaaS、SaaS企業向けのいくつかのユースケースに適しています。彼らが、ええと、ビジネス向けまたはエンタープライズユーザー向けに製品を構築したい場合、10万のエンタープライズユーザーを持つことはないですよね？そうなれば、あなたは、あなたは、あなたは、あなたは、間違いなく大成功することになりますが、ほとんどのユースケースでは、ええと、エンタープライズユーザーは1000程度です。
各ユーザーを、彼らの、ええと、ええと、buy collections によって分離できますよね？なので、その場合でも、まだ制限はあります、ええと、mill が 10 K を超えられるとは思いません。ええと、私は、ええと、collection 数は 5K より小さく保つべきだと言います。実際に 2. 4 ではそれに対して多くの強化を行ったので、2. 3 と比べると、ええと、ずっと良くなっているはずですが、それでもここには多くの制限がありますよね？しかし、もしあなたが、消費者向けアプリケーションのために何かを構築しようとしていて、その場合は非常に多数のユーザーがいて、1日あたり100万ユーザーになるのであれば、すべてのデータを分離するために collections や permissions を使うことは絶対にできません。
ええと、だからこそ私たちは、1つの大きな collection の中でより小さなテナントを isolate するのに役立つ permission key を用意しています。ありがとうございます。はい。待ってください、さらに質問が来ています。1つは、ええと、group such はその出力の preservation に関して offset と limit パラメータを扱えますか、というものです。はい。
なので、ええと、まだ offset と limits があります。ただし、ただしセマンティクスが少し違います。なので、ええと、offset を使う場合、ええと、実際には offset されるのは、ええと、documents であって、chunks ではありません。つまり、もし offset が、ええと、ええと、10、ええと、say equal to 10 の場合、それは私がすべての documents または、ええと、group、ええと、10 から 20 groups の内側にある group を見つけたいという意味であって、10 から 20 の、ええと、documents ではなく、ええと、10 から 20 chunks でもありません。これが主な違いです。
しかしはい、サポートしています。ありがとうございます。ええと、GPU リリースに関連するものが1つあります。それは、新しい segments の indexing は GPUs 上で行い、しかし、すでに index された segment の querying は CPUs 上で行うように、index を構成する方法はありますか？それは可能ですか？それは良い質問です。答えとしては、私たちは実際にそれに取り組んでいますが、今のところは、いいえ、です。
ええと、なぜなら、ええと、Carre index については、実際には特殊な graph なので、検索される必要があります。ええと、私たちは CPUs 上で検索しようとしましたが、パフォーマンスが本当に悪いです。なぜなら、ええと、GPUs は computation powers をあまり気にしないからです。なので私たちが行うこと、彼らが行うことは、より多くの computations を使おうとすることで、より高い品質を得ることができます。はい。しかし、ええと、もし CPUs を使う場合、computation powers がボトルネックになります。
そのため、あなたは、あなたは、あなたは、同じ graph architecture を本当に使うことはできません。はい。ですが、私たちがしていることは、CPU index を、ええと、GPU に適応させる、つまり GPU で構築するようなことです。ええと、それについてはいくらか進捗がありますが、まだリリースされていません。はい。
ええと、待ちましょう、たぶん 3.0。私たちは、それら全部、全部、全部を得ます。ありがとうございます。ええと、ハイブリッド検索でサポートされているスコアリングメトリクスに関連する別の質問ですが、私たちはそれらすべて、たとえば IP IGN L two のようなものをサポートしていますか、それとも制限されていますか？はい、ええと、いい質問です。
つまり、私たちは実際にはそれらすべてをサポートしています。ええと、リランキングを行う方法の一つはいずれにしても rf を使うことで、これは単にランキングに基づいています。距離、ええと、その距離がどれくらい大きいかとは何の関係もありません。ええと、私たちは weightedscore と呼ばれる別のモードもその下でサポートしています。その場合、ええと、私たちが行うのは、ええと、メトリクスの正規化です。
通常、cosign メトリクスは、ええと、IP メトリクスを使っている場合や、他の種類のメトリクス、ええと、high メトリクスのようなものを使っている場合、ゼロから 1 の間です。なので bannering や、ええと、L two メトリクスの場合、私たちは実際に正規化を行って、ええと、距離がゼロ、ええと、マイナス 1 と 1 の間になるようにし、それから異なるメトリクス間で、ええと、重み付けをそろえることができます。はい。つまり、それが実際に動作するものです。でも、ええと、はい、私は、もしそれらが同じメトリクスでいられるなら、そのほうがずっと良いと思います。
ありがとうございます。それと、誰かが尋ねています。つまり、ええと、VIS にはバックアップがあり、ええと、バックアップのオプションがあります。すみません。ええと、NetApp のようなストレージベンダーと統合して、たとえば彼らのデスクトップスナップショット技術を活用する計画はありますか、それとも、ええと、今のところはありません。はい。
つまり、ええと、どんな、ええと、ストレージベンダーであっても、ええと、私たちはとてもオープンです。もし、もし彼らが何らかの、ええと、助けを提供できるなら。はい。そうすれば、私たちは、私たちは、私たちはすべてのストレージを統合できますが、でも今のところ、mul はより、ええと、クラウドに集中しています。つまり、私たちが、私たちがしているのは、Euro はただ、オブジェクトストレージにより集中するということです。なぜならそれは、クラウド上の、ええと、ええと、共通プロトコルのように機能するからです。
私たちは実際に、私たちは実際に、ええと、ええと、ファイルシステムである EFS をサポートしていました。ええと、ええと、ええと、AWS も、ええと、それ自体は、もし何らかの種類のファイルシステム、ええと、nas、ええと、a FS はい、他のベンダーによって提供されるものを使いたい場合、非常に少ない作業で済むはずです。ええと、それがバックアップのためだけである限り、もし、もしそれを検索に使おうとしているなら、ほとんどのリモートファイルシステムは十分な性能ではありません。なので、はい。でもバックアップはとても簡単なはずです。
いいですね。ありがとうございます。それから誰かが尋ねました。ええと、スライドにあるグループ検索の例で、ええと、なぜ limit が 10 に設定されているのにグルーピング結果が 6 つしかないのですか？ええと、ああ、それは単に十分なスペースがなかったからです。はい。理想的には Yes なしで 10 ありますが、でも、ええと、私の側に十分なスペースがあっただけなので、切り落としました。
はい。ありがとうございます。ええと、そして少なくとも今のところ私が持っているのは、それが、それだけだと思います。ええと、VIS は 1 つまたは複数の多次元データキューブ上のスコアリングデータを同時にサポートしていますか？ええと、よくわかりません。それは何ですか、Data cube。
それが私が考えていたことです。つまり、ええと、次元領域値のようなものです。すみません。ええと、質問を正しく理解しているかどうかわかりません。つまり、ええと、地理空間検索のようなことをしようとしているなら、ええと、はい。
それは実際に私たちの計画にあります。それは、それは、それはまだ、ええと、非常に小さな次元のデータ、おそらく 2 次元、3 次元向けではありません。今、私たちは実際に、ええと、ええと、ある大企業の中のいくつかの、ええと、他のエンジニアリングチームと協力しています。つまり、ええと、私たちは、ええと、彼らは実際に多くの地理位置情報アプリケーションを持っています。なので、ええと、私たちが 3.0 に追加したいのは、昼間も持つ地理位置情報を持ちたいということです。
つまり、ええと、検索が起こるとき、場所に限定することもできるようになります。それは十分に良いもので、もしアプリケーションの位置情報の一部を構築しようとしているなら、非常に良いでしょう。たとえば、ええと、配送システム、たとえば、ええと、ええと、Uber のようなもの、ええと、ええと、はい、DoorDash、そのようなものです。はい。いいですね。ありがとうございます。今のところこれ以上質問はありません。
ちょっと 1 分だけ待ちます。ええと、はい、それで、ええと、たぶん、たぶん、たぶん私がちょっと、ええと、3.0 に何があるかを簡単にやってもいいかもしれません。どうぞ。はい。
そうですね。ありがとうございます。はい。オーケー。あ、一瞬お待ちください。
1つ目。はい。では、ええと、これは3.0に向けたロードマップ上の内容です。私たち、これはまだ最終決定ではありません。
ですので皆さん、もし何か、その他に、ええと、提案や機能リクエストがあれば、私たちが、まあ、ええと、皆さんと話したいことがあれば、メールを送るかGitHubに行ってください。ええと、私たちは、私たちは、ええと、間違いなく、ええと、まださらに多くの提案を待っていますよね？3.0は実際、ええと、今年最大のリリースになると思います。おそらく、ええと、7月、7月下旬ごろに行われる予定です。私たちがやりたいことがいくつかあり、ええと、reアプリケーションのユーザーだけでなく、ええと、より興味深いユースケース向けのものもあります。
1つは間違いなくパフォーマンスです。ええと、millsはスケールに非常に優れていることをご存じかもしれませんが、それでも私たちは、ええと、皆さんのコストを下げたいと考えています。私たちが見ている多くのユースケースでは、たとえばユーザーが、ええと、ええと、timber vectorsを持っていて、実際にはそれが、ええと、非常に大きなコスト、co costのようなものになっていて、ええと、つまり非常に高額になるわけです。しかし、ええと、一部のユースケースでは、検索は実際に発生します。ええと、だからこそ私たちにはこの、ええと、little loadがあり、それはautoscalerでもあります。
ですのでlittle loadが発生したとき、本当に、すべてをメインメモリやローカルディスクにロードする必要はありません。ええと、すべてのデータはオブジェクトストレージに保存され、検索が発生すると、私たちは、ええと、すべてをロードして、それを、ええと、ローカルディスクにキャッシュします。ですので、ええと、それはレイテンシを下げることができます、ええと、つまり、レイテンシは増加することになりますが、ええと、スループットは下がります、ええと、しかしその場合、あなたは、あなたは、以前のバージョンと比べて、1つのノードに間違いなくより多くのデータを保存できますし、autoscalesを使うことができます。ですので、もしリクエストがそれほど多くなければ、それが、ええと、ええと、スケールダウンのようなことを助けます。はい。
ええと、パフォーマンス。私たちは、ええと、GPOアクセラレーションにもまだ取り組んでいます。ええと、私たちは、ええと、現在の機能をもっと追加したいと本当に考えており、grouping searchも含まれます。つまり、これまでのところ、GPOはそうしたサポートを持っていません、ええと、非常に、ええと、高度な機能については。ですので、私たちは本当に、ええと、すべての機能がRTPO、ええと、indexをサポートするようにしたいと考えています。
そして、ええと、技術的には、ええと、より多くのtionsを行っています。私たちはbanking tionsをサポートする予定です。なぜなら、それは非常に人気があるからです。ええと、多くのinventingベンダーがすでにbanking tionsをサポートしています。はい、私たちは新しいストレージ、ええと、S3を用意します。S3上の新しいストレージは、実際にポイントクエリを高速化します。
それは、ええと、Apple fieldsを指定したいとき、データを、ええと、factory bから、スコアだけではなく取り出したいときに実際に大いに役立ちますよね？ですので、ええと、ええと、その、ええと、新しいストレージは実際、ええと、ポイントクエリ向けに最適化されており、オブジェクトストレージ向けにも最適化されています。ですので、ええと、パフォーマンスは大幅に、ええと、改善されるはずです。もし、ええと、もし、もしあなたが、ええと、rackアプリケーションを行っていて、chunks outしたい、主要な情報を取り出したい場合。はい。ええと、私たちは使いやすさについても多くのことに取り組みました。
私たちは、ええと、mules local modeを持っています。これは実際、データサイエンティスト向けの新しい、新しいモードで、ええと、mules向けです。デプロイは実際、多くのユーザーにとって複雑すぎると思います。特に、ええと、初めてのユーザーで、ただ試したいだけの場合です。ええと、今私たちができることは、piping saltを実行するだけで、mulesを、ええと、おそらく1分でインストールできるということです。ええと、それはまったく同じAPIを持っていますが、ええと、完全な機能はサポートしていません。しかし、初日のユーザーにとってはかなり良いものです。
はい。ええと、私たちはOC modeをlong chainおよびLAMA indexと一緒に統合しようともしています。ですので、いいえ、それは100万件程度のデータセットで多くの実験を行うには十分です。はい、新しいSDKがあります。Rustは、ええと、実際に私たちの最優先事項です。
ええと、多くのai GIユーザーがrustを使おうとしているのを見ました。そして、ええと、はい、私たちは、Rust SD caseをサポートする予定です。stay sharpはMicrosoftから来ています。ええと、li teamはすべての新機能に追随するために素晴らしい仕事をしました。はい。ええと、私たちはschema changeのようなより多くのデータベース操作をサポートします。
アプリケーションを構築しようとしているときに、ええと、その時点で、最終的にどんな種類の情報を持つことになるのか分からない場合があります。確かに、動的スキーマを使うことはできますが、将来的なパフォーマンスは実際には低くなります。ですので、1つのカラムでスキーマ変更を行ったり、1つのカラムを削除したりできます。はい。ええと、より多くのインデックスを持つものをさらにサポートすることを歓迎します。
ええと、私たちがやりたかった大きなことの1つは、うーん、JSONと、うーん、配列へのインデックスです。ええと、私たちはまた、ええと、日時、ええと、その型、そしてジオロケーションのデータ型のサポートも考えています。はい。地理空間検索をサポートするためです。また、ええと、エージェント向けの多くのユースケースもあります。
その、ユーザーは時間に基づいてフィルタリングしたいので、その場合、日時は実際に、ええと、彼らが求めているその型です。はい。私たちは、うーん、主キーの重複排除をサポートする予定です。というのも、現在はすべてのユーザーに対して、主キーを設計し、一意であることを確認してください、と伝え続けていますが、それでもいくつかのユースケースでは、例えばKafkaがクラッシュした場合、待機してリトライする必要があり、その間にリトライが発生すると、実際に同じ主キーを持つものが2つ発生することがありますよね？ですので、私たちはそれを保護するお手伝いをします。つまり、ええと、それは3. 0で実現される予定です。
私たちには、ええと、その、ええと、実際には、別のKiwiストレージがあり、すべての主キーを維持するのを支援します。ですので、この主キーがすでに存在する場合、私たちは直接、ええと、例外を投げるか、あるいは、ええと、ええと、もしindの、ええと、詳細設計に従うなら、それらの、ええと、ええと、重複した主キーを単に無視します。はい。ええと、そして私にとってもう1つ最もワクワクする部分は、3. 0では実際にさらに多くのモデルステップが追加されることです。
- 0以前は、このインフラの構築に非常に注力していました。ええ、私たちは実際その点で良い仕事をしましたが、ええと、多くのユーザーは、自分は埋め込みや再ランキングなどすべての専門家ではない、と言っています。自分には複雑すぎるので、すべての埋め込みを生成してベクトルDBに送るのではなく、データをそのまま入れてそのまま出すような方法はないのか、ということです。はい。ですので3.
0では、私たちは多くの推論、うーん、ベンダー、例えばBento mlのようなもの、ええと、OpenAIのような多くのモデルプロバイダーと連携する予定です。ですので私たちが行うのは、実際には関数を用意することです。つまり、うーん、チャンクを渡すだけで、ええと、私たちはその、ええと、関数を呼び出し、ええと、その関数は私たちが統合した他のすべての埋め込みプロバイダーやランキング、再ランキングプロバイダーと連携します。はい。そうすると、mulには元の生データがすべてあり、ええと、埋め込みは彼らの側で行われるので、私たちは単に、彼らの、うーん、ええと、リファレンス、ええと、推論エンジンのようなものを呼び出すのを手伝うだけです、そうですよね？ですので、より多くのセマンティック検索のユースケースもサポートします。
ええと、今はほとんどのユーザーが単に使っているだけだと思いますが、私たちは実際にはさらに異なるセマンティクスを追加したいと考えています。私たちは、ええと、フィルタリング、ええと、最近傍フィルタリングを追加したいです。つまり、フィルタリングは、ええと、スカラー・データだけでなく、ベクトル上でも行われます。例えば、犬の写真がたくさんあり、ええと、猫の写真もいくつかあるとします。検索では、似ている犬をすべて見つけたいけれど、猫は絶対に含めたくない、ということがあります。そこで、犬をポジティブな例として1つ与え、猫をネガティブな例として1つ与えることもできます。
そうすると私たちは、ええと、ほとんどの呼び出しで犬を読み出そうとしますが、ええと、猫はフィルタリングして除外しようとします。マルチターゲットは、ある意味で似たようなユースケースです。ですので、ええと、検索を開始するとき、おそらく何を、どのようなものを実際に検索するのか分からないことがあります。そこでポジティブな例を1つ与えると、私たちは例えば100件の類似結果を返し、その結果の中には、あなたが本当に欲しいものもあれば、そうでないものもあります。ですので、欲しいものをポジティブとしてマークし、うーん、欲しくないものをネガティブとしてマークできます。そして別の検索を行うことができます。
それはマルチターゲット検索と呼ばれます。なぜなら、ええと、クエリベクトルが1つだけではないからです。つまり、複数のポジティブな例と複数のネガティブな例があります。はい。Murals はすべての例に基づいて検索しようとし、ええと、その、ええと、ポジティブな、ええと、ial により近づき、ええと、ネガティブな ial から遠ざかろうとします。データを発見しようとする場合、それは非常に役立つ可能性があります。
つまり、このような、ええと、正確なターゲットがあるわけです。はい、それはほぼ 3. 0 向けです。そしてそれは今年の夏向けですよね？夏頃にリリースすることを期待しています。そうです。そして James、3. ポイントを夏にリリースすることを期待しています。
はい、それは今年の夏向けです。いいですね。はい。そこで、ええと、私たちは7月を目標にしています。ええと、実際には遅れることもあります。というのも、はい、私たちは1つのリリースにあまりにも多くのものを追加しようとしているだけだからです。でも期限どおりに提供しようとしています。
はい。わかりました。わかりました、いいですね。ありがとうございます。最後にもう1つ質問があります。それで、このウェビナーは終わりになると思います。
ええと、vis はフィールドの変更をサポートしていますか、ええと、ベクトルフィールドではなく？つまり、すでに挿入されている値がある場合、ええと、1つの可能性は upsets を行うことですが、その方はさらに、それによってベクトルフィールドの再インデックス作成がトリガーされるのか、と尋ねています。はい、それは、あれは実際に良い質問です。ええと、これについて考えています。ええと、これは、ええと、ストレージ形式にも大きく依存します。なぜなら、私にとっては、すべてはストレージ形式だからです。なぜなら、私たちの umm は、ええと、他の、ええと、競合とは少し異なります。私たちは、ええと、ええと、ストレージとコンピューティションを分離することに同意していません。ええと、したがって確実に得られるメリットは、システムが非常に、ええと、弾力的になり、また、ええと、スケールしやすくなることです。ええと、問題は、ええと、オブジェクトストレージ上では、ええと、いかなる変更も行えないことですよね？ですので、ストレージ形式を慎重に設計する必要があります。
ええと、ですので、ええと、その前に、observed、または、または、ええと、fuse の変更をサポートできるようになる前に。はい。でも、ええと、確かに、はい、私たちは、ええと、これについて考えています。おそらく 3. 0 ではなく、新しいストレージ形式ができたら 3. 1 かもしれません。それによって、私たちにとってそれを行うのが、より簡単になります。
はい。とてもいいですね。どうもありがとうございます。以上です。質問はすべて以上だと思います。あなた、それがすべての質問です。
それでは James、この1つの casing everything、すべてのリリースについて、どうもありがとうございました。ええと、参加してくださった皆さん、ありがとうございました。ええと、世界のどこにいらっしゃるかによって、おはようございます、こんにちは、またはこんばんは。質問がある場合は、Discord にもぜひ参加してください。それでは次回お会いしましょう。
ありがとうございます。バイバイ。
Join the Webinar
Loading...
Meet the Speaker
Join the session for live Q&A with the speaker
James Luan
VP of Engineering at Zilliz
James Luan is the VP of Engineering at Zilliz. With a master's degree in computer engineering from Cornell University, he has extensive experience as a Database Engineer at Oracle, Hedvig, and Alibaba Cloud. James played a crucial role in developing HBase, Alibaba Cloud's open-source database, and Lindorm, a self-developed NoSQL database. He is also a respected member of the Technical Advisory Committee of LF AI & Data Foundation, contributing his expertise to shaping the future of AI and data technologies.