Join the Webinar
Loading...
セッションについて
Milvusでベクトル検索の旅を始めることは、ほんの始まりにすぎません。インスタンスのパフォーマンスを最適化し、向上させるための数多くの戦略があることをご存じですか？エンジニアリング担当VPであるJames Luanが、Milvusの可能性を最大限に引き出すための貴重な洞察と専門的なヒントを共有します。高度なテクニック、ベストプラクティス、パフォーマンス向上のための施策を発見し、あなたの体験を次のレベルへ引き上げましょう。経験豊富なユーザーであっても、始めたばかりであっても、このセッションはMilvusに関する理解と習熟度を深めるものとなります。当社のエンジニアリング専門家の指導のもと、Milvusインスタンスの効率と機能を最大化する機会をぜひご活用ください。
学べる内容：
- Milvusのベストプラクティス
- インスタンスのパフォーマンスを最適化し、向上させるための戦略
- エンジニアリング担当VPによる専門的なヒント
本日は、今日のセッション「Your Vis Instance の最適化」とゲストスピーカーをご紹介できることを嬉しく思います。James won は当社のエンジニアリング担当 VP です。James won は Zillow のエンジニアリング担当 VP で、Cornell University でコンピューター工学の修士号を取得しています。彼は Oracle、he Vig、Alibaba Cloud でデータベースエンジニアとして豊富な経験を持っています。James は HBase、Alibaba Cloud のオープンソースデータベース、そして自社開発の NoSQL データベースである Lindor の開発において重要な役割を果たしました。
また、彼は Linux Foundation、AI and Data Foundation の技術諮問委員会の尊敬されるメンバーでもあり、AI とデータ技術の未来を形作るために専門知識を提供しています。ようこそ James。では本日の参加者の皆さん、こちらのブログを取り上げていきます、はい。みんなどこにいますか？ こちらです。このブログの内容を取り上げていきます。
ですので、本日最初に行うことは、バージョン、検索、ええと、メモリ、vis にどのように挿入されるか、設定、ログ、クラスター、ドキュメント、ええと、vis のデプロイ方法、そして、ええと、データを削除したときに何が起こるかについて話すことです。では James、ええと、自己紹介をお願いしたいです。その後、トピックに入っていければと思います。もちろん、もちろん。ええと、ありがとう Eugene。ええ、そして、ええと、ここで皆さんにお会いできて嬉しいです。
ええと、今日は、私、できれば私たちが、MO インスタンスを最適化する方法について何らかの知識を得られればと思っています。ええと、私たちは実際に、パフォーマンスを向上させる方法やコストを削減する方法について非常に長いリストを持っています。ですので、ええと、いくつかの質問から始めて、詳細に入っていけるかもしれません。もちろん。はい。
私たちのコミュニティで最も頻繁に言及されるトピックの 1 つがバージョンです。そして、ええと、最近 2. 4 をリリースし、その前には 2. 3 がありました。ですので、かなり多くの、ええと、異なるバージョンがありましたので、あの、違いは何なのか、そして、ええと、追加されている新機能は何なのか、何が、そして、あの、破壊的変更などがあるのか、といったことをある程度知ることができると素晴らしいと思います。
はい。実際、コミュニティにとっては、A IGC コミュニティが実際に行っていることと同じように、非常に非常に速く進んでいます。ですので、ええと、私たちは Mills 2. 2 からパフォーマンスの最適化を始めました。これは、ええと、2021 年頃にさかのぼります。その時点で、私たちは、ええと、ええと、多くの、最適化、特に検索に関するものを行い、そして、ええと、ええと、degree cluster におけるある種のボトルネックを取り除きました。
ですので、ええと、現在、ええと、ware を使おうとしている場合は、少なくとも、ええと、two two の最新バージョンである two to17 から始めることをお勧めします。そして、ええと、それはおそらく Milless の最も安定したバージョンです。そうですね。ただ今は、ええと、つまり、あなたのコストのほとんどは、もし milless の新規ユーザーであれば、直接使うことをお勧めします。Two。
Three は私たちの最新の、ええと、安定ブランチです。ええと、two three では、私たちは実際に、ええと、featuring、ええと、in に関する多くのパフォーマンス改善を導入し、また、ええと、メモリレプリカも改善しました。ですので、複数のレプリカを持つことができ、ええと、パフォーマンスを向上できます。一度、ええと、もし、もし十分な crib per second がないとわかったら、レプリカをさらに追加するだけです。はい。さらに、ええと、私たちはいくつかの新しい種類のインデックスも導入しました。
重要なインデックスの 1 つは、ええと、Google Scan です。ええと、従来の fast index と比較して、実際には 5 倍、10 倍速く、agent double と比較しても、いくつかのユースケースでははるかに高速です。たとえば、大きな top case がある場合、ええと、featuring がある場合、ええと、UA scan はすべての graph index と比較して、ええと、より高速になります。はい。私たちはまた、ええと、graph index、たとえば Asian sub に対しても多くの最適化を行いました。私たちは、ええと、将来のパフォーマンスを改善するために多くの機能を追加しました。ええと、graph の構造を変更することを含み、ええと、ex execution path には多くの最適化があります。
たとえば、もしあなたのフィーチャリング率が非常に高くなるなら、私たちはこれを持っていて、ええと、ええと、私たちは、ええと、グラフインデックスを使うのではなく、直接、ええと、ブルートフォースに行きます。もし、ええと、中程度のフィーチャー率のようなものがあるなら、私たちは、ええと、いくつかの、ええと、ええと、命令を持っていて、ええと、あなたが、ええと、グラフの接続性を改善するのを助けます、ええと、そうした種類の特徴を使って。ええと、私たちのフィルタリング性能は、実際には、ええと、2、2、2ワードと比べて10倍高速です。なので、ほとんどの場合、もし性能を改善する方法に興味があるなら、twoを使って、ええと、two、threeを使ってください。そしてもう1つ興味深い部分は、ええと、私たちは、私たちは、ええと、GPUインデックスを導入しました。これは実際にNvidiaチームと共同で取り組んだものです。
ええと、私たちが現在取り組んでいるGPUインデックスは実際には、ええと、rapidでオープンソースになっているもので、これは、ええと、Nvidiaチームからのものです。そうですよね？ なので現在私たちが使っているインデックスはGPU flで、ええと、これは、ええと、CPU版と比べてはるかに高速です。特に、ええと、より大きなクエリのバッチを持っている場合です。はい。ええと、でも非常に小さなクエリを持っている場合、または性能を重視する場合、現在のGPUインデックスのワードは最適ではないかもしれません。しかしtwo four n、来月には、新しいGPUインデックスを持つ予定で、それは、ええと、Cargo Indexと呼ばれています。
これは実際にはGPUグラフインデックスです。そして、ええと、実際にずっと、ずっと高速で、ええと、私たちの、ええと、タスクでは5倍、10倍高速です。なので、ええと、GPUを使いたい場合、非常に高いスループットがある場合、ええと、2.4を見逃さないでください。なのでそれは、ええと、ええと、来月中旬にリリースされる予定です。なので、ええと、バッチクエリをどのように行えるかについても多くの異なる、ええと、最適化があります、ええと、GPUインデックスで。
そしてまた、ええと、それはSPARSING meetingsもサポートします。なので、より良い検索品質を求めているなら、それなら、ええと、two fourを待ってください。検索品質の改善を助ける新しい機能がたくさんあります。ああ、なるほど。とても楽しみですね。つまりtwo threeでは、scanや、Nvidiaと共同で作成したGPUインデックスを含む多くの新しいインデックスが入りました。
ええと、そしてスケーリングをより簡単にするためにレプリカを追加する機能があり、最適化によって性能も向上しています。そしてtwo fourでは、新しいGPU Intaxが入り、これは高スループットのユースケースに本当に適したものになり、ええと、sparse embeddingsも入って、ええと、検索の一部を調整するのに役立ちます。なので本当に楽しみです。そしてそれは実際に、次のトピックに入るのにとても良い流れです。それは検索についてです。では、visで、ええと、私たちができる検索の種類について少し話してもらえますか、ええと、searchがあり、queryがあります。
ええと、そしてmetadata filteringや新しい、ええと、新しいgroup by機能のようなものについても話してもらえるかもしれません。はい。ちょっと、ええと、1つ見逃している部分がありますよね？ つまり多くのユーザーが私に、どの種類の、どの最新バージョンを実際に推奨するのか尋ねます。なので私の答えは常に、最新のmulバージョンを使う、常に最新を使う、になります。はい。
なぜなら、ええと、私たちは、リリースする前に実際に多くのテストを行ったからです。なので非常に初期のバージョンでない限り、もし、それがリリース候補なら、その場合はいくつかのity問題があるかもしれませんが、それ以外は、安定ブランチについては、単にいくつかのバグ修正を行っているだけです。なので新しいバージョンはより安定しているだけでなく、より高速にもなります。はい。わかりました。
では検索に戻ると、そうですよね？ つまりVector database全体の非常に基本的な検索機能は、ええと、提供するものとしては、ただ、ええと、in searchですよね？ これは実際にはすべてのVector dbで提供されるものです。うん。ええと、それは、ええと、ええと、少し違うものを提供します。なぜならまず第一に、それはスケーラブルになるからです。なので、ええと、私たちは実際に分散Vector dbです。なので私たちは、異なるノード上で、ええと、同時検索がどのように起こるかについて多くの最適化を行いました。ロードバランスについて多くの最適化を行い、各ノードがデータの一部を保持することを確実にしているので、データをどのようにスケールするかを心配する必要はありません。
そうですね。ええと、それ以外にも、ええと、私たちはさまざまな新機能をたくさん導入しました。たとえば、2 では、2. 2 では、実際に新しい検索の同僚、ええと、Range Search と呼ばれる検索機能があります。つまりユーザーに、距離の制限を与えて、距離がゼロ点、ええと、liter 0 より大きいすべてのベクトルを見つけるためのものです。
7 mm-Hmm。彼らの co metric 上で。すると、ええと、非常に大量の、ええと、ええと、ベクトルが得られます。これは、異常データを見つけたいとき、私たちが見つけたいときに非常に役立ちます。つまり異常データは、特定のユースケースでは非常に大きくなることがあります。そうですよね。
それで、ええと、research は通常、結果の ation と一緒に動作します。ええと、top case search とは違って、そうですよね。ええと、research では、非常に大きなリストを返すことができます。なので、RBC からバッジを取得するのではなく、結果を反復処理しなければなりません。さもないと、さもないとメモリが auto memory になってしまいます。そうですよね。
そうです。なので、ええと、2. 4 で実際に導入しようとしているもう 1 つの興味深い機能は、group by search です。では、それが実際に何をするかというと、ええと、特に rag のユースケースで使われます。そこでは多くのドキュメンテーションがあり、各ドキュメンテーションにはたくさんのチャンクがあります。Mm-Hmm。
ある種のユースケースで検索しようとするとき、単に top K chunks を持つのではなく、top key document を持ちたい場合があります。なぜなら、ええと、ある種のユースケースでは、そうですよね？top top 10 で検索したときに、関連する上位 10 個のチャンクがすべて 1 つの記事 Mm-Hmm から、または 1 つのドキュメントから来ている場合があります。Mm-Hmm。つまり、検索を行ったときに、得られるのは 1 つのドキュメントだけで、多様性がまったくないということです。そうですよね。
そして、異なる、ええと、可能性を見つけるためにさらにランキングを行う方法がありません。なので、ええと、ええと、group I を使うと起こり得ることは、より 1 つのトピックの cate categories、または単に楽しいチャンクだけではなく topic key document を見つけるようなものです。したがって、これは、ええと、検索とレコメンデーションの両方にとって非常に役立つでしょう。間違いなくもっと多様性が欲しいですから。なので、ええと、検索に関するもう 1 つの興味深い機能は、間違いなく research で、ええと、元のものと比較して、つまり、実際には 2 種類の、ええと、hybrid research があります。
1 つは単に fuel drinks を行うもので、もう 1 つは、ええと、私たちは spars meetings と一緒に hybridsearch できます。Mm-Hmm。なので、ええと、2. 0 から fuelings のサポートを開始しました。ええと、私たちは、ええと、文字列を含む、数値を含む、ほぼすべての種類の scatter datas をサポートしています。
現在、私たちは、配列や json のような、より高レベルのデータ構造もサポートしています。JSON のサポートにより、あらゆる種類の、ええと、dynamic schema を持つことができます。そうですよね？事前に schema を定義する必要はありません。はい。そして 2.
4 では、私たちの主要な、ええと、ブレークスルーは、ええと、実際に、ええと、すべての、すべての、すべての、ええと、ええと、SC data の上に inverted index をサポートすることです。ええと、私たちは実際に、ええと、10 index を使用しています。これは実際に、ええと、優れた Rust Library です。ええと、lu に非常に似ています。ええと、lun に非常に似ています。私たちは、新しい inward index により、あらゆる種類の、ええと、in word index をサポートします。
また、新しい inward index により、いくつかの非常に興味深い操作もサポートします。たとえば、ええと、たとえば、ええと、ええと、regular expression search、たとえば、ええと、queries に対するものです。そうした種類の操作により、mules はより従来型のデータベースのようになります。すべての scatter functions を一緒に使って、filtering search と連携させることができます。はい。すごい。
そして、ええと、そして一方では、そうですよね、新しい have research があります。つまり、Sparkmini search 以降の dancing embedding の両方を行うことができ、そのすべての上でランキングモデルを実行できます。なので、ええと、2. 4 では、新しい、ええと、より、ええと、data type、つまり sparsing embeddings を導入します。したがって、dancing battings とは異なり、sparsing embeddings は、ええと、ええと、実際にはより大きな次元を持っていますが、ほとんどの次元はゼロです。ええと、sparsing battings を生成するには、displayed や BM 25 のような、ええと、model を使用できます。
つまり、Sparsing battingsは、ダンシングやバッティングと比べて、sparsing battingは、本当に、ええと、はるかに、はるかに特定の詳細を見つけるのに優れています。たとえば、ええと、いくつかの、ええと、何らかの数値に基づくものとか、ええと、それは、それは、それはまた、ええと、オートドメイン検索にも非常に優れています。ですので、spars meetingsを使う典型的な方法の1つとして、私たちは、ええと、density embeddingsと一緒に使うことができます。うん。両方のembeddingsから検索して、ええと、おそらくトップ、トップキーの結果を取得し、crossing kohler model、たとえば、birdや、あるいは、ええと、coherent ranking modelsのようなものを使って再ランキングします。そうすると、より正確な結果が得られます。私たちのテスト結果では、denseとsparse meaningsの両方をre rankerと一緒に使うことで、検索精度が、おそらく3%から5%向上します。
はい。わかりました。すごい。わかりました。それで、再ランキングによって3〜5%向上するんですね。
ええと、それはかなり興味深いです。ええと、視聴者から最初の質問があります。ええと、これはバージョニングについてで、Alexandraからの質問です。新しいvissバージョンでは、pie vissインターフェースに破壊的変更が導入されますか？私は現在、古いバージョンのvissを使っていて、アップグレードするとpie milsの変更に関するバグを修正しなければならないのではないかと心配しています。はい。私たちは実際、破壊的変更を導入することには非常に保守的です。
私が、ええと、前回いくつかの破壊的変更を導入したのは、2. 1から2. 2だったと思います。皆さんがどれくらい古いバージョンを使っているのかはよくわかりませんが、2. 2のバージョンを追加する場合、ええと、2.
3へ、そして、さらに言うと、ええと、私たちは実際に、ええと、ええと、2. 2からloading upgrade機能を持っています。つまり、ええと、私が言いたいのは、2. 2のかなり後のバージョンで、2. 2220ではなく、おそらく2, 2 16のような、何らかのバージョンです。
ですので、loading upgrade機能があれば、ええと、アップグレードはかなり自由にできます。データを変更する必要はありません。API変更もありません。そして、私たちは多くのAPI改良を行いましたが、全体としては、古いAPIをおそらく2つのメジャーバージョン分は維持しています。はい。ですので、ほとんどの場合、変更する必要はあります。
はい。わかりました、いいですね。つまりAPIのバージョンはおよそ2つのメジャーバージョン分維持され、最後の破壊的変更は2. 1から2. 2だったということですね。
なのでAlexandra、もし2. 1より新しいバージョンを使っているなら、まったく問題ないはずです。ええと、そうでない場合は、少しリファクタリングをする必要があります。ええと、視聴者から別の質問があります。ええと、vis dash cliの責任者は誰ですか？ああ、実際には、ええと、たしか、Milに取り組んでいるコミッターが2人いると思います。
CLIについて何か質問がありますか？ですので、もし、もし何か機能要件があるとか、バグを見つけた場合は、遠慮なくGitHubに行って、ええと、issueを投げてください。はい。私も、muralの、ええと、メインリポジトリやpenリポジトリ、それから、ええと、mul. CIも見ています。はい。
それで、ええと、面白い事実としては、ええと、mul Cell,Iは実際には、ええと、ええと、私たちのツールと同じ作者です。ええと、皆さんが、ええと、DUI two formulasにどれくらい馴染みがあるかわかりません。それはtwoという名前です。もし知らないなら、皆さんにはぜひ使うことをお勧めします。使うのは少しぎこちないです。
それで、そして、何か理由があれば。はい、私たちも、何か役立つフィードバックがあれば欲しいと思っています。そうすれば改善できます。はい、こうしたウェビナーを開催して、ユーザーの皆さんに参加してもらうことの素晴らしい点は、まさにこうしたユーザーフィードバックを見られ、何が起きているのかを把握できることですね。ええと、ここに別の質問が見えます。ええと、PDFをベクターデータベースにロードしてchunkingを適用することについて、ええと、それはENT全体の、まあ、それ自体で1つの完全な講演になると思います。
それで、ええと、tasing については、ひとまずそのリンクといくつかのリソースをお送りします。ええと、ではこの3つ目の部分に進みましょう。3つ目の質問、これまで出てきた中で3番目に多かったトピックはメモリです。パフォーマンスと精度とメモリの間のトレードオフは何ですか？はい、ええと、皆さんがどの程度ご存じか分かりませんが、ええと、新しい CEP サーバーは、今では従来のデータベースとまったく同じようなもので、そこで探しているのは、ええと、一貫性、可用性、そして、ええと、ネットワーク予測の間のトレードオフですよね？ただし、通常のデータベースの場合にも、新しいトレードオフがあります。それはコスト、精度、そして、ええと、パフォーマンスです。ですので、ええと、私たちは、あなたが、あなたが使おうとしているユースケースの種類に基づいて、VUS にさまざまな種類のインデックスを提供しています。
たとえば、もしあなたが高スループットの Harry call、ええと、インデックスを探しているなら、私は、GPU Index Index、特に新しい cargo index が探しているものになると思います。ですので、私たちは今年の GTC で、この、ええと、GPU index を A VI チームと一緒にリリースする予定です。ですので、それは3月にちょうど行われるはずです。その点については少しお待ちください。一方で、そうですね、ええと、もし CPU を使っているなら、最も高性能なインデックスは、ええと、HHW になります。
そして、ええと、recall についてあまり心配しないのであれば、HW と quantitations を組み合わせることができます。HWSQ を使うことで、メモリを節約すると同時に、ええと、検索パフォーマンスも向上させることができます。はい。ええと、それから、ええと、ほとんどの rack ユーザーにとっては、ええと、より良いスループットや recall を得るよりも、低い、つまり、ええと、少ないコールのようなメモリを好むでしょう。その場合、実際には2つの異なる、ええと、推奨事項があります。もし recall を重視していて、かつ高性能なディスクを持っているなら、disconnect があなたが、あなたが、ええと、探すべきものです。これは実際に、インメモリインデックスと比べてメモリを10分の1に削減するのに役立ちます。
そして mills は実際に、このインデックスをサポートする唯一の Vector DB です。私の知る限りでは、これまでのところ、私は、ええと、分かりません、というのも、私は、更新のようなことはしていないので、でも今のところ Mills が唯一だと思います。ですので、ええと、これが何をするかというと、実際には MAM メモリ内にいくつかのインデックスを維持しますが、そのインデックスは、ええと、ええと、ole 圧縮または contentized されており、元のデータはすべて直接ディスク上に置かれます。つまり何が起こるかというと、ええと、検索が行われるとき、メモリ内のインデックスを使って候補をいくつか見つけ、そのうえで、この上のすべての候補を使ってリファインメントを行い、recall が高くなるようにします。はい。
ええと、ただし key の問題は、ええと、インデックス構築が実際には少し遅いことです。ですので、ええと、非常に頻繁な exertions がある場合は、ええと、間違いなくより多くの、ええと、index node が必要になります。それが1つの問題です。そして2つ目の問題は、それが、それらすべての候補に対して refining を行うことになるため、非常に高性能なディスクが必要だということです。ええと、それは少なくとも VME ディスクでなければならず、50 K として 50 KLPS を提供する必要があります。
それ以外の場合、あなたの検索パフォーマンスは非常に低くなります。はい。そしてもう一方で、もしメモリを節約したいだけで、recall をあまり気にしない場合、ええと、たとえば、もし特定のデータセットがある場合、ええと、たとえば open eye dataset ですね？condition を行ったとしても、非常に高い recall が得られるはずです。ですので、そのようなユースケースでは、ええと、VF index を、ええと、sq または product position と一緒に使ってみてください。それはメモリを削減し、また、ええと、検索パフォーマンスを向上させるのに役立ちます。
はい。そして最後に、もし新しい open AI embedding models を使おうとしているなら、ええと、私たちは実際に vector dimensions を削減する新しい機能を持っています。ですので、それは実際には、ええと、recall にあまり影響しませんが、ええと、ええと、それを使うことで、ええと、vector dimension を、ええと、たとえば 2K から、たぶん 2 56 または、ええと、five 12 にまで減らすことができます。メモリを4分の1に削減できます。そして、ええと、ほとんどの場合はそれを採用すべきです。
わあ。なるほど。かなりいいですね。ええと、あの、そのディスクの件について聞きたいです。ちょっと待ってください。
つまり、disk NN を行うには、ええと、MVME ディスクで 50 K が必要だと言っていましたが、その必要な 50 K とは何でしたか？50 K-I-O-P-S。ああ、ああ、なるほど。50 K、秒あたりみたいな。ああ、なるほど。わあ。
なるほど、いいですね。ええと、つまり、メモリ関連については、いろいろな選択肢があるようですね？Me Vis は disk NN を使う唯一のもので、ええと、その、メモリ内データが 10 分の 1 になるというのは、非常に興味深いです。そして、それは作業に使えるメモリがあまり多くない人たちにとって、本当に良い選択肢をたくさん提供すると思います。そして、非常に高速になるでしょう。IVF PQ SQ のものも役立つでしょう。
そして、ええと、別の質問があります。ええと、Alexandra が質問しています。VUS データベースのセットアップをチューニングする際、ポッド数、ええと、ノードの水平スケーリングと垂直スケーリング、そして永続 di ディスクサイズの観点で、どのようなアドバイスがありますか？はい、私たちは、ええと、mill style に実際に計算ツールを用意しています。ですので、最初のステップは、Euro は常に codo を使っていくつか見積もりを行うことだと思います。大まかな自動化としては、80 ギガバイトのメモリごとに、およそ、ええと、150 万から 200 万の、ええと、768 次元ベクトルを保持できるというものです。
ですので、ええと、この見積もりに基づいて、次に、どれくらいの ose メモリが必要なのかを知る必要があります。で、それに基づいて、ええと、32 ギガワットメモリを超える場合は、ええと、スタンドアロンではなく、この bu の分散版を使うことをお勧めします。ですので、ええと、すべてを 3、2 ギガバイトのポッドに分割できます。そして、ええと、ほとんどの場合、プロキシ 1 つ、mixed coordinators 1 つ、そして data node 1 つがあれば十分なはずです。そして、非常に頻繁にその挿入分割を行うのでない限り、またはネットワークの問題があるのでない限り、スケールアップするだけで大丈夫です。例えば、たくさんの異なる views を取得したい場合、proxy network がボトルネックになる可能性があります。
その場合は、ええと、po、ええと、proxy をさらにスケールアップするか、単にスケールアウトするかを考える必要があります。で、そして index node については、ええと、唯一のコツは、もし、ええと、index のような、ええと、他の flight のようなものを使っている場合、それらは index の構築が非常に速いはずで、h and w の場合でもそうです。ですので、追いつくのは非常に簡単なはずです。しかし、これについては少し違ってきます。ですので、ええと、おそらく非常に大きな index po が必要です。ええと、これについては妥当なパフォーマンスが出るように、実際かなり多くのチューニングが必要です。
1 つのセグメントサイズを選び、index pump size をチューニングし、ええと、disk についてもチューニングする必要があります。ですので、disk index を使う最も簡単な方法は、この cloud を使い、私たちの capacity optimizing を使うことです。実際には、ええと、dis と比べて、ええと、その、より高速な速度を提供します。そしてそれらの call については、ええと、index build poll もあります。ですので、ユーザーは index の大きさを心配する必要はありません。私たちは index build における insertion data について課金しません。
心配すべき唯一のことは、どれだけ、どれだけの criminals が必要かということです。しかしオープンソースユーザーの場合は、はい、おそらく少しベンチマークを行う必要があります。ですので、お勧めとしては、monitoring me metrics を持つ必要があります。実際には monitoring metrics があり、ええと、例えば、実行されていない、またはキューで待っている index tasks がいくつあるか、もし、キューが実際に非常に大きい場合、それは less no means index をスケールする必要があるということです。はい。
つまり、ええと、オープンソースのユーザーは、disk, a NN を使う場合、かなりのチューニングを行う必要があるということですね。ええと、しかし Disk N は基本的に、Zillows cloud における capacity optimized version として実装しているものですね。ええと、その cloud については。実際には in-house index で、純粋に、ええと、decent や他の種類のオープンソースというわけではありませんが、ええと、capacity については、実際には diskin に非常に似ています。はい。
わかりました。ああ、それはとても興味深いですね。なるほど。それで、ええと、これは実際、挿入の部分を飛ばして、あなたがちょうど話していたこと、つまりこの、ええと、このクラスターやスケーリングの話、そして、ええと、クラスタリングとデプロイメントに触れるのにうまくつながると思います。今まさに触れていたことだと思います。少しその話に移るのは自然だと思いますし、Novus standalone と Novus cluster の違いについて話していただけるかもしれません。
ええと、たぶんいつ切り替えるべきか、そして、ええと、それがどういうものなのか、この2つのバージョンのどちらかをデプロイする際にどんな違いがあるのか、ということですね。はい。まず、多くの初心者にとっては、ええと、standalone が、ええと、最初に試すべきバージョンだと思います。というのも、実際デプロイが非常に簡単ですし、ええと、同様に、ええと、単一の docker だけなので、ラップトップ上で立ち上げるのはとても簡単なはずです。ですので、ええと、standalone cluster でどんなテストでも気軽に行ってください。ええと、実際には、standalone バージョンから cluster バージョンへ切り替えるタイミングには、2つの異なるシグナルがあります。
ええと、1つ目の理由は、大量のデータがある場合です。つまり、たぶん、1,000万を超える、1,000万データ、おそらく2,000万データを超える場合、ええと、それは standalone から、ええと、cost version へ切り替えるべきデータ量として、かなり妥当な数だと思います。はい。そして、ええと、2つ目のシグナルは、非常に高い可用性が欲しい場合です。なぜなら、ええと、standalone clusters では、stand、ええと、primary standby のようなものをサポートしてはいますが、クラスターが復旧するまでにより長い時間がかかることになるからです。しかし、Kubernetes の助けを借りた cluster versions であれば、高可用性を実現するのはずっと簡単になります。そして、ええと、いつでもスケールしたい場合も、ずっと簡単になります。
はい。ただ、ええと、stand、ええと、そして standalone から cluster へ切り替える方法もあります。ですので、standalone から始めて、ええと、cost aversion へ移行したい場合でも、それを行う方法はまだあります。ですから、あまり心配しすぎないでください。はい。
わかりました。ええと、ここで質問があるのですが、Mil Vista standalone から cluster への切り替えはどのように機能するのでしょうか？ええと、表面下では何が起きるのでしょうか？はい、mil standalone には、実際には2つの mills があります。1つは local mode、もう1つは remote mode です。違いは、ええと、もし皆さんが mills について少し詳しいことをご存じなら、私たちは mills 自体のために多くの依存関係を持っています。実際には status です。また、データは3つの par、ええと、3つの依存関係に保存されます。
まず第一に、メタストレージです。私たちは、ええと、ETCD を使っています。ええと、2つ目は、ええと、message queue で、これは WL として MessageQ を使っています。standalone では、ええと、Uly user、ユーザーが使っているのは、ええと、log db で、ええと、distributed version の場合は、そうですね？分散型の、ええと、ログストレージが必要で、それは Kafka や psa のようなものです。そして3つ目は、ええと、object storage で、すべてのデータが保存されます。
ですので、最も簡単なモード、standalone の local mode では、彼らがすることはすべて、ローカルディスクにすべてのデータを保存することです。そのため、ええと、別のバージョンへアップグレードするのは非常に難しくなります。ええと、できることの1つは、バックアップを行い、そして、ええと、データを新しいクラスターへ re、ええと、復元して、データが移行できることを確認することです。はい。そして、ええと、それらすべての依存関係とともにデプロイされた standalone cluster の場合、つまり、もしデプロイするなら、もし、ええと、S3 storage と EDCD も一緒にデプロイしようとしているなら、その場合ははるかに簡単になります。なぜなら、すべての、すべて、すべてのデータ、ええと、つまり、standalone と、ええと、costs のすべての機能は、まったく同じだからです。
なので、あなたがやる必要がある唯一のことは、ええと、デプロイメントを変更することです。ええと、1つ、1つのノードから、ええと、複数のレプリカへ。はい。それは、それほど難しくないはずです。ああ、わかりました。つまり、もし私たちがローカルのスタンドアロン版から切り替えたい場合、やる必要があるのは基本的にデータをバックアップすることです。そのデータは通常ローカルに保存されていて、それを新しいクラスター版に移行します。
ただ、もし私たちがすでにリモートのスタンドアロンを、これらすべての依存関係をデプロイした状態で使っているなら、いくつかのパラメータを変更するだけで、ええと、クラスター版を使えます。うーん、はい。つまり、依存関係はすべてそのまま整っているので、少し楽になります。わかりました。すごいですね。
それは素晴らしいです。というのも、つまり、もし私たちがvisをスケールさせたい場合、最初は実験のためにMelvicを使い始めることさえできるということです。うーん、そしてローカル版を使えます。それは本当に簡単です。使うのも本当にシンプルです。そしてスケールする準備ができたら、スケールするのはとても簡単です。なぜなら、ある意味で、ええと、自然な移行ができるからです。
Novusとのインターフェースの仕方には、実際にはほとんど変更がありません。うーん、これは実際、ええと、ログについてのポイントにも自然につながると思います。あなたはログキューについて言及しましたし、うーん、vissには他のログもあります。では、vissにあるログのいくつかについて話しましょう。ログレベルや、ええと、データがどのようにログに記録されるのか、またはどのデータがログに記録されるのかについてです。はい、つまり、実際には2つ、2種類の、ええと、ログがありますが、それらは実際には非常に混乱しやすいです。
もしログのログについて話しているなら、つまり、ええと、すべての、すべての、すべての、すべてのデータのことですが、私たちはそれを、ええと、WAL write-ahead logと呼んでいます。はい。つまり、ええと、すべてのデータは、ええと、Kafkaに入り、または、ええと、スタンドアロンの場合は、ええと、log dbに保存されます。つまり実際には、あなたの、ええと、データを、すべてのデータが永続化されることを確実にするためのものです。なのでwriteが発生すると、ええと、proxyが直接データをログに書き込みます。そして、ええと、それらのログは実際にはすべて、ええと、data nodesによって消費され、特定のリクエストを処理します。
それで、Cコミュニティで起きている1つの大きな変更は、実際にはログストレージを改善していることです。ええと、2.0から、私たちはKafkaプロセスをサードパーティの、サードパーティの依存関係として使っています。しかし多くの、ええと、ユーザーが、ええと、millsクラスターと、ええと、ログストレージの両方を維持するのは重すぎる、と不満を言っています。なので私たちは実際に新しい、ええと、分散ログ実装に取り組んでいて、それは実際に、ええと、より高速です。
そして、ええと、ええと、それは実際にはその一部です。なので、ええと、将来的にはこの依存関係を削除する予定ですが、それは、それは実際には、ええと、ええと、まだ、ええと、ロードマップ上では長期計画です。なので今年のQ3またはQ4に起こる可能性があります。それで、ええと、もし、もしあなたが、ええと、ロギングについて話しているなら、ええと、デフォルトでは実際には、ええと、info、ええと、infoレベルを使っています。なので、ええと、それが、私たちが使いたい最も推奨される、ええと、ロギングレベルです。そして、ええと、もしmealsを本番環境に入れたい場合、ええと、1つの推奨事項は常にロギングシステムを持つことです。それが、ええと、Lokiであっても、ええと、何らかのパブリッククラウドが提供するものであっても、ええと、ELKであっても関係ありません。何であれ持っているものを使ってください。というのも、これは認知的なシステムなので、私たちはそれらすべてのログを標準ストリームに出力します。
なので、あなたは、あなたは、あなたは、いくつかの設定を変更してファイルに出力する必要があるか、または私が今言及したようなシステムを何でも使うことができます。すべてのログを確実に持っているようにしてください。なぜなら、いったん何らかの問題にぶつかると、コミュニティのすべての、ええと、メンテナーやコミッターは、彼らは、彼らは助けたいと思っていますが、すべての問題を調査するには間違いなくより多くのログが必要になるからです。もし、それらのログを準備しておくことを忘れていて、すでに問題に遭遇してしまった場合、その方法の1つとして、私たちは、ええと、export logsスクリプトを提供しています。そのスクリプトでは、ええと、実際に選択できます。ええと、たとえば直近10分間のログを、ええと、発生している問題の種類に基づいて選択できます。
非常に頻繁に、ええと、ログがある場合、十分な情報がないかもしれませんが、いくつかのケースでは役立つはずです。私たちは、私たちは、私たちは、私たちは US gate への支援に投資して、あなたのクラスターの修正を手助けできます。はい、いいですね。つまり、Novis について話すとき、novis には実際には 2 種類のログがあります。つまり、2 種類のログについて話していて、従来のデバッグ情報のような、ログレベルのようなものがあります。
そして、私たちが write ahead log と呼んでいるものもあります。これは、ええと、vis にデータを移動する方法でもあります。これらは 2 つの異なるものです。そして、ええと、私たちはまた、独自の write ahead log を更新し、作成する予定です。ええと、それは、より高速で軽量なものになります。ええと、それからログ、通常のログに関しては、ええと、これらのレベル、つまり、info や debug などのレベルですが、ええと、本番環境で最初に適切なログが設定されていない場合でも、実際にはそこで、mils が提供するスクリプトの 1 つを使って過去 10 分間のログを収集し、それをエクスポートして、たとえば GitHub discussions に投稿し、人々から回答を得ることができます。ええと、それから言及しておくと、S 2.
3 では、実際に、ええと、ログレベルを動的に変更する新機能をサポートしています。ですので、それは、それも役立つでしょう。なぜなら、ええと、debug ログは実際に、ええと、非常に、非常に詳細だからです。ですので、問題がない場合でも、ただ、ええと、ええと、何らかの理由で info ログに十分な情報がない場合は、そのままログレベルを debug に変更できます。はい。筋が通っています。
ええと、それから次の 2 つも非常に似た形で扱えると思います。つまり insert と delete です。人々は、ええと、どのようにデータを挿入するのかを知りたがっています。どのような形式のデータが必要なのか、そして、どのような形式のデータを挿入できるのか。データを挿入するために何が必要なのか。ええと、それから削除について、ええと、novis がデータを削除すると何が起こるのか。そして、これは upsert について話すのにも良いタイミングだと思います。はい。では、ええと、Mill 2.0 のとき、または Mill が作られたときですね。私たちにとって重要な目標の 1 つは、ええと、vector、ええと、streaming data をサポートすることでした。
ええと、なぜなら、すべての、ええと、従来の vector index Act では、ええと、ええと、ええと、それはつまり、新しいデータがありますよね？いくつかの、ええと、vector、ええと、いくつかの vector を変更したい、またはいくつかの vector を遅延させたい場合、インデックスを再構築しなければなりません。ですので、重要なことの 1 つで、ええと、meal がサポートしているのは、ええと、ええと、streaming dirt です。ですので、私たちは、複数の異なる、ええと、index tab を持っていますよね？一部の index tab、たとえば GPU index については、ええと、すべての index は単に immutable になるので、そこに insert や delete する方法はありません。そこで私たちが作成したものは、ええと、growing segment と呼ばれます。ですので、私たちは、実際にそれを 2 つの部分の 2 番目の部分に読み込みます。ええと、最初の部分は growing segment で、実際には mutable です。ええと、ですので、そこに er できますが、ええと、search では、その上にも index を構築します。それを私たちは、ええと、bing log index と呼んでいます。
しかし、search では、その index は効率的ではありません。他の、ええと、HW や wealth index のような index types ほど効率的ではないのです。そうですよね？ですので、ええと、私たちはまた、ええと、growing segment が大きくなると、それを sell して、すぐに index node に渡して、ええと、ええと、second index を構築します。それから私たちはそれを historical segments と呼びます。ですので search が発生すると、単に merge を行います。つまり growing segment から search すると同時に、すべての historical segment からも search して merge します。それはかなり、かなり、ええと、ええと、log structure merry に似ています。つまり、異なる segment からのすべての、すべてのデータを merge して、ええと、完全な結果を得ます。
ですので delete が発生すると、ええと、実際には、mules は、is a、is so whole disagree storage and the competition だからです。ですので、私たちができる方法はありません。ああ、ここで何か技術的な問題が起きているようですね。ええと、わかりました。ええと、何が起きているのかよくわかりません。James に技術的な問題が発生したようです。
ええと、まあ、その、もし私が、いくつか質問に答えてみます。皆さんは、チャットやQ&Aでいくつか質問してもらえますし、JamesがZoomに再接続できるかどうか見てみましょう。ええと、もし、あ、あ、あ、彼はいなくなりました。わかりました。ええと、ではJayが次の数分でZoomに再接続できるかどうか見てみましょう。
ええと、もしできなければ、まあ、Q&Aだけにもう少し時間を使って、それから、ええと、そこで終わりにします。つまり打ち切ります。では、ええと、確認ですが、Dockerにはスタンドアロン、SED、min ioが必要で、Kafkaと統合する場合のみのメッセージは何ですか？ええと、そうですね、Vissは、ええと、vissをデプロイすると、スタンドアロンのviss、ええと、SC、D、そしてMIN ioがあります。この3つ、ええと、この3つのコンテナは、情報を保存するために起動している必要があります。つまり、SCDは状態を保存するために使うもので、min ioは永続ストレージに使うものです。
ええと、そして、あ、Jamesが戻ってきました。はい、よかったです。ええと、James、ええと、削除が起きたときに何が起こるかについて話していたところで切断されたと思います。ええと、そこから再開してもらえると助かります。はい。
ええと、ネットワークが不安定で申し訳ありませんが、ええと、はい、削除が起きると、ええと、実際にはオブジェクトストレージに依存しているので、どのファイルも変更することはできません。そこで、ええと、data logと呼ばれる新しいデータ形式を、ええと、追加します。data logでは、どのエンティティがすでに削除されたかだけを管理します。読み取りが発生すると、ええと、それはマスクとして機能します。つまり、すべてのデータは、それが起きたとき、実際には削除されるわけではなく、まだ、この、ええと、オブジェクトストレージに保持されます。
ただし、ええと、それを検索で見つける方法はありません。また、compactionと呼ばれるバックグラウンドタスクもあります。compactionが行うことは、すべてのログと、ええと、個別のログをマージすることです。そうすることでデータ自体がクリーンであることを確保します。つまり、それが起きることです。
つまり、ええと、このログをログに追加するときは、あなたは、あなたは、すべてのcriminalsにも通知しなければなりませんよね？新しい遅延がありますので、必ず、ええと、その、ええと、そのデータがユーザーに読み出されないようにしてください。それが削除が起きたときです。それで、ええと、次にobservedとは何か？つまり何が起きるかというと、ええと、mulには主キーがあります。ですから、私たちは、主キーを一意に保ちたいのですが、いくつかの技術的な理由で、ええと、重複する主キーを入力したときに、ええと、どのキーが、ええと、実際に検索されるものになるのかを保証する方法がありません。はい、これは従来のデータベースとは違います。従来のデータベースでは、マージが発生します。ええと、ええと、検索自体は、ええと、ええと、実際に正確です。
なので、同じ主キーを持つエンティティが2つある場合、常に上書きできます。しかし、検索を行うときに起こり得るのは、ええと、古いエンティティが、ええと、トップキーリストに入っているが、新しいinternetはトップKリストに入っていない、ということです。つまり起こり得るのは、ええと、ええと、上書きしたい場合でも、古いinternetがまだ表示され、別のクエリでは新しい、ええと、エンティティが見えるということです。ですから、ええと、これを避けるために、できることの一つはobserveを行うことです。基本的に、私たちが行うのは、ええと、古いinto thisを1つ遅延させることです。
つまり、新しい成長中のセグメントに新しいものが入るので、それが問題を避ける助けになります。でも、でも、でも、これを使うこと、ええと、この absurd と delete も使うことについては、ええと、慎重になるべきです。もし大量のデータを削除しようとしているなら、compaction と in building の両方に多くの、ええと、負荷がかかります。なので、もし非常に頻繁な delete があるなら、ええと、より新しいバージョンを使うことをお勧めします。ええと、たぶん 2、2、3、ええと、2.3 の最新バージョンです。なぜなら concurrent delete と insert に関する多くの問題を修正しているからです。ええと、私の知る限りでは、2.2 バージョンでは、ええと、それが起きたときに、いくつかのデータを失う可能性があるバグ、delete をいくつか失う可能性があるバグがあります。なので非常に頻繁にありますが、それは常に、ええと、非常に大きな delete がある場合、または、ええと、非常に大量の delete や insert がある場合に起きます。
なので、ええと、delete がある場合は慎重にしてください。はい。わかりました、いいですね。では、ええと、今の内容を全部まとめます。通常、インデックスは、インデックスを構築すると、そのインデックスは immutable です。
しかし、私たちにはこれらの growing indexes と、ええと、いわゆる sealed indexes という概念があるので、できることとしては、実際に、ええと、より簡単にスケールでき、より簡単に検索できるインデックスを、ええと、構築できます。そしてこれは実際、データを delete するときにも役立ちます。なぜなら、データの delete は通常、ある程度、ええと、たとえば bit flip のように振る舞うからです。そして私たちはそれをマスクします。ええと、もしこれらの growing indexes がなければ、正しい primary key を取得するという、この、この課題が生じます。しかし、これらの、ええと、segments、これらの growing segments があるので、できることとしては、古い segments をすべてたどって、古い primary key を取り除き、それから新しいものを growing segment に追加します。つまり、それは別のインデックスの中にあります。なので、それは本当に、ええと、効果的で興味深い方法です。
そしてチャットに Frank から別の質問があります。ええと、Frank ではなく、私たちの A-I-M-L の責任者ではない別の Frank です。ええと、connection あたり DB が 1 つだけであることの技術的制約は何ですか？ ええと、ええと、connection あたり DB が 1 つであることの制約が何なのかについては、私は、ええと、特に考えがありません。はい、Frank、ええと、それをもう少し明確にしてもらえますか？ はい。たぶんその間に、先に進められます。はい。その間に先へ進んで、ええと、この最後の部分をやります。
では最後の、あ、いや、実際にはもう 2 点あります。私たちが、ええと、まあ、両方の点をカバーできるか見てみましょう。configuration がたぶんより重要な点で、documentation はずっと簡単に扱えると思います。では、VIS で利用可能な configurations と、ええと、Viss をその場で configure する方法について話す時間を少し取ってみましょう。では、ええと、まず、ええと、Frank からの質問に答えますね。つまり、別の db に切り替えられないということです。ええと、ええと、別の、ええと、db を使うことでそれはできると思います。
なので可能なはずですが、でも、でもはい、その通りです。各 connection については、1 つの db だけを使えます。なので複数の、ええと、databases がある場合、ええと、私たちが推奨する方法は複数の process を持つことです。Python の users であれば、ええと、model process を持ち、ええと、ええと、もし他の language、たとえば Golan や Java のようなものを使っているなら、ええと、異なる dbs を使って 2 つの mill kind を作成できます。はい、では、ええと、configurations に戻ると、私は、ええと、最も重要なのは、ほとんどの場合、つまり default の configurations で、ほとんどの users にとっては十分に強力だと思います。非常に大規模な deployment がある場合や、ええと、ええと、use cases にとって performance が非常に critical になる場合を除いてです。
なので、ええと、変更したいかもしれない configurations がいくつかあります。まず第一に、segment size です。なので、ええと、default では 512 megabytes だけです。ええと、それは非常に小さな deployment 向けの設計です。4 gigabytes から 8 gigabytes のような、非常に限られた memory を持っています。
それなら、5 12 は妥当な初期値になるでしょう。ただし、大規模なクラスターがあり、パフォーマンスを向上させたいほど大量のデータがある場合は。思うに、重要な設定の一つとして変更が必要なのはセグメントサイズです。ええと、パフォーマンスを向上させたいのであれば、たぶん 2 ギガ、2 ギガバイトを使うことをおすすめします。はい。それから、ええと、パフォーマンスの変更を検討しているなら、検索パラメーターやインデックスフィールドのパラメーターもたくさんあります。
特に検索パラメーターについては、調整したいところです。ええと、それは検索精度とパフォーマンスの間で非常に柔軟なトレードオフを提供してくれます。なので、はい、実際にはいくつかのベストプラクティスがありますが、インデックスが違えば異なります。ええと、実際にそれらのブログや milvus ブログの両方で、それについて話している記事がたくさんありますので、ぜひそれらの記事を見てください。はい。
わかりました。設定については、セグメントサイズ、そして、うーん、セグメントサイズがおそらくパフォーマンスを得るために変更すべき最も重要なものです。そして、さまざまなベストプラクティスは、異なるインデックスごとに異なってくるということですね。そして、うーん、それだけでおそらく一つの講演になる内容です。うーん、では、わかりました。
そして、VUS のウェブサイトで見られた最も一般的な用語トップ 10 の最後、そして最も一般的な質問はドキュメントです。ドキュメントを最新の状態に保つためには何をすべきでしょうか？最も最新のドキュメントはどこで見つけられますか？はい、ええと、はい、私たちは、ええと、すべてのユーザーが、ええと、ただ、ええと、ええと、より良いドキュメントを望んでいることを知っています。私たちは皆、より良いドキュメントを望んでいます。なので、はい。ただ、ええと、それには間違いなく、ええと、多くの、ええと、人的リソースと、多くの忍耐が必要です。
ですので、まず第一に、どんな、どんな貢献でも、meals の、ええと、ウェブサイトにとって歓迎されます。ええと、たぶん、単に、ええと、コンテンツを書くのを手伝ってもらうだけではありません。どんな、ええと、コンテンツを、あなたが、あなたが探しているのかについて、アドバイスや課題を教えていただくだけでも、とても、とても役に立ちます。はい。そして、ええと、第二に、私たちがやろうとしていることの一つは、私たちは、私たちは、私たちは確認しようとしています。なぜなら、私たちは、2. 4 向けのような新機能をたくさん持っていて、実際には、おそらく 2 つ以上の主要機能を、うーん、リリースしたいと思っています。
そして私たちは、それら主要機能のそれぞれに、1 つの、うーん、ええと、ユーザードキュメントと、実装を紹介するための詳細ドキュメントを 1 つずつ用意したいと思っています。ですので、こうした新機能すべてに非常に関心があるなら、うーん、それで十分でしょう。使い方を理解する助けにもなりますし、ええと、設計の詳細についても少し理解できます。はい。そして三つ目の部分ですが、Rack は、ええと、非常に、非常に人気になるでしょう。
それで、私たちは実際に、ええと、rec システムの構築方法には非常に詳しいです。ですので、私たちが、私たちが近い将来に、ええと、行うかもしれないことの一つは、mul とそれらのドキュメントのための、ええと、bot を構築したいということです。つまり、それはすべての情報を持っていて、すべてのドキュメントを、mul ウェブサイトからこの、ええと、この bot に投入するだけです。私たちは追加の検索を行います。また、より大きなモデルを使って、生成部分も行います。
ですので、それは、ええと、より正確な、ええと、ドキュメント結果を見つけるのに役立つ可能性があります。ええと、今のところ、私たちのウェブサイトは、ええと、goal を使っているだけです。それは実際には良い agreed ツールですが、キーワード検索により重点を置いています。ただ、ええと、私たちはセマンティクスが欲しいのです。はい。わかりました。
素晴らしいです。うーん、ありがとう、James。では、その、皆さん、要約すると、ドキュメントのことです。ぜひご意見をお寄せください。何を知る必要があるのか、何を知りたいのかを教えてください。私たちは喜んで、そこでお手伝いします。
うーん、そしてはい、ここでほぼセッションを締めくくれると思います。あと 1 分待って、追加の質問が入ってくるか見てみましょう。もしあれば、たぶん 1 つか 2 つの質問を受ける時間はあると思います。うーん、もしなければ、ここで、ええと、セッションを締めくくってまったく問題ないと思います。うーん、わかりました。
それでは、寄せられている質問が1つあります。Philipは、私たちのvis、ええと、ドキュメントボットのRAG実装について、ええと、より詳しい情報を得られるか知りたいそうです。はい、ええと、彼らは、実際にはnon matricのようなものです。で、1つ目として、ええと、私たちが実際に使っているフレームワークは実はLA Indexです。はい、非常に柔軟性があります。
単にragをやりたいだけなら、独自のエンベディングを選べますし、独自のランキングも使えます。で、私たちが、ええと、試したいことの1つは実際にはリサーチです。そこで、ええと、両方の、ええと、プロセスミーティングのためにすべてのドキュメントを入れました。で、で、これまでのところ、ええと、open-end embedsは実際とても良いです。なので、ええと、私たちはまた、ええと、さまざまな種類のオープンソースのembedsも試しました。
ええと、BG in embedsは実際、ええと、私たちの選択肢の1つであり、おそらく、おそらく、ええと、で、で、ええと、私たちは現在、ええと、現在いくつかの、ええと、他の新しいエンベディングをテストしています。Mistral embeddingsのようなもので、これは実際に大規模モデル上に構築されているため、より良い品質を持つはずですが、それはまだいくつかのベンチマーク中です。で、Sparsing mining側では、ええと、私たちが実際に使っているのはspreadで、これは実際、うーん、全体としてはsparsing miningモデルだと思います、思います。つまり、BD rankersを使って両側で検索し、ランキングを行うのは、ええと、v doによって完全にオープンソース化されています。ええと、何らかの有料サービスのようなものを使うなら、cohering、そのcoherent rankingはまさにGoogle向けのソリューションの1つです。彼らも独自のランキングを持っています。なので、ええと、それが生成のための3つ目の部分で、間違いなくopening Iですが、もし品質があるなら、あるいは他の、他の種類の、ええと、学習モデルがあれば、それで十分良いはずです。
はい。いいですね。素晴らしいです。la Indexをフォローしてください、私たちのブログをフォローしてください。Reactに関する多くの情報をお届けします。
はい。私もracについて多くの作業をしてきました。なので、うーん、皆さん、いいですね。では、参加してくださってありがとうございます。これでセッションを締めくくれると思います。はい、James、ありがとうございました。そして参加してくださった皆さん、ありがとうございました。また次回お会いしましょう。
またお会いしましょう。
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.