- Events
密ベクトル埋め込み != 完全な検索 - Milvus 2.5 の先行紹介
ウェビナー
密ベクトル埋め込み != 完全な検索 - Milvus 2.5 の先行紹介
Join the Webinar
Loading...
何を学べますか？
密な埋め込みは完全一致を見逃します。キーワード検索は意味的な意味を見逃します。2つの別々のシステムを運用するのは、メンテナンス上の悪夢です。Milvus 2.5のハイブリッド検索が統合ソリューションでこの問題にどのように取り組むかを示し、スパースベースのBM25実装をプレビューし、現在のElasticsearchベースのアーキテクチャとの性能比較の数値を共有します。
取り上げるトピック：
- 密な埋め込みが不十分な点と、統合システムアーキテクチャが検索ニーズにどのように対応するか
- Milvus 2.5のプレビュー - BM25実装とスパースベクトル最適化の簡単な紹介
- ハイブリッド検索のレイテンシとスループットをElasticSsearchと比較したベンチマーク結果
- 次の展開 - 技術ロードマップにおける今後の機能の簡単な概要
みなさん、こんにちは。本日のWOWウェビナーへようこそ。えー、本日は、えー、vis 2. 5について見ていきます。ちなみに、私の名前はChris Elloで、ここZillowで働いており、えー、マーケティングEndeavorを担当しています。
そして、みなさんにご参加いただけて本当に嬉しく思っていますし、えー、open source buに関して私たちが取り組んできたクールなことをみなさんに見ていただけるのがとても楽しみです。それから、えー、実は本日パネルに、えー、何人か参加しています。えー、みなさんからのご質問にお答えできる予定です。私自身、えー、プロダクトマーケティングリードのSteffi、それからEmily、えー、そしてもちろんJamesもいます。えー、そして、Q&Aのどの質問にも対応できるように、何人かエンジニアも呼ぶかもしれません。ですがその前に、えー、みなさんにお知らせしたいのですが、私たちにはみんなが集まっているとてもクールなDiscordchannelがあります。
ぜひDiscord Channelに参加してください。最近始めたもう一つのこととして、実際に申し込めるオフィスアワーのセットがあります。これまでは金曜日のUS時間帯に実施していて、えー、当初は、みなさんのvisに関する質問に答えるために、さまざまなエンジニアとの15分の、えー、ミーティングを予約できるようにしていました。すると、えー、15分では短すぎることが分かりました。そこで実際に、たしか20分か25分に延長しました。
そして、えー、嬉しいことに、えー、特に、えー、インデックスの選び方に関して、ドキュメントへの変更についてのフィードバックをすでにいくつか、えー、いただいています。もしそのフィードバックをくださった方のお一人であれば、本当にありがとうございます。そして、えー、私たちは、みなさんの、えー、VIS実装でぜひ成功していただきたいと思っています。ですのでぜひ参加してください。えー、もう一つ、私たちには、えー、えー、おそらくすでにご存じかと思いますが、毎月これらのmeetupを行っていて、えー、unstructured dataと呼んでいます。
ぜひご参加ください。もし参加できない場合でも、これらのセッションはすべてYouTubeチャンネルに録画されています。そして1月には、初めての女性向けハッカソンを開催する予定です。ですので、女性の方、または、えー、ご存じのとおり、参加したい方は実際にはどなたでも含めていますが、1月末にStanford Universityにホストしていただく予定です。そして、えー、一緒にかなりクールなハッキングができればと思っていますし、これが私たちが米国で行う多くのハッカソンの一つになればと思っています。
10月にGoogleで非常に成功したものを実施し、えー、はい、とても楽しかったです。ですので、えー、終日イベントです。えー、そして、えー、私たちの、えー、ハックをみなさんと共有します。えー、たとえば、えー、ブログやYouTubeチャンネル、そして、えー、ソーシャルメディアの、えー、チャンネルなどのさまざまなチャネルを通じて、ですね。はい、いいですね。では、みんな揃っているか確認させてください。
はい。では、これからやることは、えー、ここに体調があまりよくない人が何人かいます。えー、なので実は、えー、このプレゼンテーションを、えー、ほんの数日前に行いました。ですので、実際には、えー、Jamesの録画を、えー、みなさんにお見せします。えー、ただし彼は、えー、みなさんの質問に答えるためにここにはいますが、体調があまりよくないだけです。
えー、そしてもちろん私も、えー、みなさんをお手伝いするために、えー、ライブでここにいます。では始めましょう。Jamesはもちろん、私たちのVP of engineeringです。そしてこの人は、私は彼が寝ているとは思えないので、体調があまりよくないのも驚きではありません。それに小さな赤ちゃんもいます。
ですので、赤ちゃんはいつも冬場にたくさんの楽しい風邪をもたらしてくれます。では。おっと、これが正しく共有されているか確認させてください。実際、もう一度、少し待ってください。音声を正しく共有していなかったかもしれないことに気づきました。
あれだけ準備したのに、はい、共有、共有。音声、いいですね。できました。はい。では、えー、音声が正しく聞こえたら親指を立ててください。
自分について簡単に紹介します。私はJayです、音は大丈夫ですか？いいですね。すばらしい。拡大します。そして先ほど言ったように、えー、私たちは実際にみなさんのどの質問にも答えるためにここにいるので、もう少しうまくマルチタスクできます。
では始めましょう。James、ええと、エンジニアリング担当VPです。それに加えて、私はまた、ええと、3、4年前にwareをゼロから構築しました。ですので、私たちは市場で最もスケーラブルな、ええと、高性能なベクターDBソリューションの一つでもあります。私たちはオープンソースです。なので、ええと、私は、私は、私は、参加する前は実際にはいくつかの異なる、ええと、データベースで働いていました、ええと、Oracleで。
それから私はAlibaba Cloudに、データベースデザイナーのような形で参加しました。わかりました、James、なぜなのかを話してもらえますか？はい、ではもっと近づいて。はい。そうですね。今日は私たちは、ええと、3つの異なる部分をカバーして話していきます。
1つ目は、rackアプリケーションを構築するときに、なぜ多くのサービスがあなたの必要なすべてではないのか、特に、という点です。ええと、2つ目は、私たちがそれをどのように行うのか、あるいはなぜそれが既存の多くのソリューションより優れているのかです。ええと、最後に、hub researchを使って、ragのようなものを実装するために、どのように非常に簡単なコードを書くだけでよいのかについて、簡単なデモをお見せしたいと思います。はい、では、おっと、動かしたいです。おっと、よくあることです。
はい、では、ええと、ragについて簡単に、簡単に振り返ります。ここにいる皆さんはきっと、ええと、ragについて聞いたことがあると思いますよね？なので、ええと、実際にはシンプルです。ええと、できる限りシンプルにするなら、すべてをチャンキングしてベクターDBに入れるだけです。ああ、そのほうが良いかもしれません。はい？なので、ええと、すべてを、ええと、ベクターDBに入れて、それから、クエリをしたいときには、実際に、ええと、すべてのクエリを埋め込みしてw dbに検索し、それから、いくつかのような重要な事実を取得して、それをあなたの、より大きなモデルに投入します。
そうすれば信頼できる回答を得ることができますよね？いくつかのハルシネーションを取り除けますよね？本当にシンプルに見えますし、ある日、私が自分でrapidアプリケーションを構築しようとするまでは、実際かなりうまく機能していました。私は、ええと、友人たちと一緒に取り組みました。ええと、私たちがやろうとしているのは、ええと、実際には法律系の、アプリケーションです。ええと、文書の中には実際にある種の非常に特殊な法律用語がありますよね？なので、ええと、私がこのificationを使い、同時に、ええと、ベクターDBのようなものとして使っていたとき、最初は本当に、本当に良さそうに見えました。しかし、ええと、深く考慮してみると、いくつかの用語は実際には、ええと、それほど効果的に検索されていないことがわかります。ええと、検索が過度に広くなっているのを実際に見ました。つまり、1つの用語を検索すると、あなたは、似たような用語をいくつか得るかもしれませんが、それを制御できるものは何も、何もありませんよね？なので、ええと、私はその問題をどのように解決できるかを考え始めました。実際に2つの解決策を使いました。
1つは、私の埋め込みモデル、ええと、そして学習モデルをファインチューニングするだけです。最初のうちは問題なく機能しましたが、すぐに、私の、ええと、悪いケースをファインチューニングして訓練し始めると、コーナーケースがどんどん増えていくにつれて、大きなモデルが非常に多くの、たくさんの基本情報を忘れ始めるのがわかりました。私たちがモデルや埋め込みモデルを使う主な理由は、それらがすでに、たくさんの、ええと、既存の情報で訓練済み、事前訓練済みだからですよね？なので、多くのファインチューニングを行うと忘れ始めて、ええと、re、そのスコア、実際には評価スコアが実際に下がっていきますよね？なので、ええと、私が実際に試したもう1つの方法はクエリライティングを行うことです。なので、ええと、特定の種類の用語について、同義語のようなものをすべて見つけようとしました。話し方を変えたり、大きなモデルを使って変更したり、その上で多くのテクニックを行おうとしました。
でも、ときには反例が多すぎるような場合があり、自分のユースケースに合わせてこれを修正することはできないですよね？だから、私たちにできることは何もないように見えますよね？ええと、セマンティック検索にとって実際に何が問題なのかを見てみると、そうですよね？それが必要なもののすべてでは絶対にありません。実際、かなり良い技術です。私たちは record db を作っています。だから record DB が良くない、とは言いませんが、ええと、大きく3つ欠けているものがあるんです。1つ目は、ええと、結果を制御する方法がないということです。つまり、ええと、大規模モデルと同じで、基本的にはブラックボックスです。なぜこの結果が得られたのか、ええと、なぜそれらが似ていることになったのかは、すべてブラックボックスで、もし物事がうまくいかなくても私たちにできることは何もありませんよね？ええと、2つ目は、珍しいクエリの一部を扱うのに失敗することです。つまり、これらの埋め込みモデルは大規模なデータセットで訓練されていますが、それでも、実際には、そのデータセットはウェブから来ているか、非常に一般的なものなんですよね？でも、ええと、あなたのユースケースでは、特定の専門用語や、より特殊なクエリについては、あまりうまく機能しないことに気づくかもしれません。
ときには、そのトークンを訓練セット内で見たことすらない場合があります。だから、ええと、それは機能しないんです。3つ目は常にチャンキングに関するものです。チャンキングが簡単ではないことはみんな知っています。できる最も簡単な方法は、4K、8K でチャンキングすることですが、長いチャンクでは多くのトレードオフがありますよね。長いチャンクでは、すべてのコンテキストを失う、またはすべての詳細を失います。5、12 のような短いチャンクを使うと、今度はいくらかのコンテキストを失いますよね？だから、データをどのようにチャンクするかは、常に難しい、難しい部分なんです。わかりましたか？では、私たちはそれを修正する方法をどのように考えるのか。
それで、ええと、私は考え始めました。何が検索を非常に強力にしているのか、あるいは、検索を行う方法とは何なのか。私は、それはすべて確率に関するものだと思います。つまり、大規模モデルであれ、埋め込みモデルであれ、関係ありません。彼らがやりたい唯一のことは、私たちのコーパス内の文書の中にある、ええと、何らかのパターンを見つけようとすることなんです。できるだけ簡単に言えば、もし英字の頻度を計算すれば、間違いなく一部の文字が高くなるのがわかります。例えば、E は実際に、ええと、はるかに頻繁に現れます。だから、文書内の次の単語を予測するための小さな大規模モデルを作りたいとして、ええと、もし十分な RIN がなければ私も PPPE するでしょう。なぜなら、それが最も理にかなっているからです。ええと、2-gram でも同じです。つまり、2つの文字を組み合わせると、ええと、zx g、gq のように、実際には存在しないパターンがあることが間違いなくわかりますが、その一方で th のように非常に一般的なものもありますよね？わかりました。
ええと、同じことがここでも起こります。私たちが文字だけでなく、トークンに置き換えたときです。それが大規模モデルの仕組みです。つまり、次のトークンを予測するだけなんです。十分な訓練データセットがあれば、次に来る単語である可能性が最も高いものが何かがわかります。そして、どの種類の、ええと、文字、あるいはトークンが実際に最も似ているのかもわかりますよね？では問題は、その確率をどう改善するか、ですよね？その1つの方法は、常に事前学習済みモデルを使うことです。ええと、Open AI は間違いなくかなり良いです。私たちはまた、多くの lagging value models も知っています。
Warrior cohere、あなたは膨大な量のデータから訓練します。もし法務データセットを構築しようとしているなら、彼らには法律モデルがあります。金融データセットを見るなら、彼らには、ええと、そうした特定のデータセット向けに訓練されたモデルがあります。そしてときにはファインチューニングを行うこともできますが、私は、そうしたテクニックは一部のユースケースではあまりうまく機能しないと思います。もう1つの方法は、自分自身のデータ分布を把握することです。それは非常に、非常に難しそうに聞こえますが、そんなに難しくはありません。わかりました。ええと、私たちがそれを行う方法は実際には非常に伝統的ですが、実際には始めるうえで本当に役立ちます。ええと、振り返る必要があります。
その部分は少し技術的になりますが、えー、でもできれば、えー、ここで何が起きているのかについて、一般的な背景をお伝えできればと思います。なので、えー、えー、これらの stats を得る非常に伝統的な方法として、tf IDF と呼ばれるものがあります。TF は term frequency を意味します。つまり、各 token があなたの capus の中でどれだけの回数現れるかを示しますよね？なので、えー、もう一つは DF で、これは各 token の頻度を、あなたの documents の量に対して示します。なので、えー、例えば、もし私が、えー、同じ doc の中、同じ documents の中、または私の corpus の中に、たくさんの words を持っている場合、それはこの token があまり重要ではないということを意味します。
それは a third かもしれないし、えー、あるいは非常に一般的な tokens のようなものかもしれず、十分な semantics を含んでいないのです、よね？しかし、もし以前に見たことのないような非常に特別な words があり、それがあなたの corpus の中で一度だけ現れるなら、それはその IDF が一つだけになり、eight weeks は非常に高くなるということを意味しますよね？なので、あなたの dataset 全体を取得し、すべての stats を実行し、すべての term frequency、すべての、えー、inverse document frequency を計算すると、実際には、あなたの query と、あなたの、えー、corpus のようなものとの relevance を計算する方法があります。えー、それが T-F-A-D-F と呼ばれるものです。なので elastic search や、lucin ベースの、えー、えー、search のようなものは、実際には同じ技術を使っています。えー、ただし、それらは stats をどのように計算するかについて definitely different versions があり、その中で最も popular なものの一つが BM 25 と呼ばれています。なので、えー、一般的には同じ idea を使っていますが、search がより意味をなすように、いくつかの hyper parameters のようなものを変更していますよね？Okay。
では、えー、T-F-A-D-F を使っているときに何が起こり得るのでしょうか？それは、一般的には、えー、3つの異なる steps です。ここでの raw con、raw text は、scale のために構築された vector を持つ mill です。最初の part では、それを異なる tokens に分割する必要があります。ちょうど、えー、異なる token eithers を持つように、えー、時には最も簡単な方法は、ただ、えー、4文字、5文字のように分割することですが、同時に、たくさんの異なる stop word のようなものを使ったり、comma を使ってすべてを分けたりすることもできます。えー、もちろん、そのための integrated なものもあります。なので、どのように tokenize するかについては、実際には心配する必要はありません。
tokenize した後、いくつか transform を行い、lowercase にしたり、stammer を行ったり、非常に一般的な words の一部を削除したりすることを確実にします。すると、clean な、えー、tokens が得られますよね？それらの tokens を使って、2番目の step は、うーん、その上に in word index を実際に構築する必要があります。なので、えー、in word index とは何かを示しますが、これはいくらかの performance を与えてくれます。えー、それらの right third parties を検索しようとするときには、stats が必要です。
それが、私たちの、えー、data distribution を把握する方法です。なので重要な部分は、例えば、mul が私の document に何回現れるか、mill が何回現れるか、weer が私の doc document に何回現れるかを計算する必要があるということです、よね？理想的には vector、vector は、mules と比べてより多く現れるはずです、なぜなら vector はより一般的な words のようなものだからです、よね？つまり、もし mill が現れるなら、それは実際には vectors よりも重要になるということです。なぜなら、それはすべての documents に現れるからです。Okay？ Okay。なので、えー、何が起こるかについて簡単な例を挙げられます。私は3つの document を持っています。
1つ目は、information、えー、retrieval information material is a field of study。2つ目は、information、retrie、focus on follow relevant、えー、informations、whatever started that。Data mining and information retrieval overlap in research。Okay？これらが私が持っている3つの documents です。もし information retrieval research を検索した場合、どれがより重要であるべきでしょうか？はい、えー、理想的には間違いなく number three だと思います。
まず第一に、私が持っている3つのトークンはすべて、情報検索の研究が実際にはドキュメント3に示しているからですよね？そして、ええと、ドキュメント1、2についてはどうでしょう、どちらがより関連性が高くなるのでしょうか？はい、答えは、ええと、ドキュメント1のほうがより関連性が高くなります。ええと、なぜなら、ええと、ドキュメント2は、どちらもキーワードとして information show を持っているからです。だから全部そこにあります。ええと、information は実際にはずっと、ずっと、ええと、より多く、より多くの回数出てきます。なので、ええと、ええと、重みはより小さくなり、retrieval は示しています。ええと、より少ない回数で、あなたのドキュメントの10%だけが retrieval を持っています。だからそれはより重要になります。
そして、ええと、すべての計算をした後、ええと、そして、ええと、時にはある種の正規化を行うために、ドキュメントの長さで割る必要もあります。そして、スコアを常に計算することもできますよね？つまり、それが、BM 25 を使って、ええと、クエリとドキュメントがどれだけ関連しているかを評価する通常の方法です。いいですか？だから本当に良さそうに聞こえますよね？それで、ええと、私たちは、それを制御する方法があることを知っています。トークンについて知るだけでよいのです。誰でもトークンを読むことができ、それを変更できます。
ええと、それに対して将来のこともできます。それは良いのでしょうか？ええと、答えは違います。それだけでは十分ではありませんよね？だからこそ、私たちはまだベクトルDBが必要なのです。ええと、理由は、まず第一に、ええと、時々、セマンティック検索をするだけで、ええと、レキシカル検索をするだけで、コンテキストを失うことがあるからです。単に最も似ている単語を見つけようとしているだけです。しかし時には、たとえば Apple という単語には、複数の異なる意味があります。
私が意味しているのは果物のリンゴですか、それともその果物の会社を意味しているのですか？はい。だから、ええと、それは1つの課題になります。ベクトル、ええと、ベクトルDBやベクトル埋め込みは、その背後にあるものを理解するのに間違いなく役立ちますよね？それで2つ目は、sys についてはどうでしょう？時には、似たような文字、似たような単語を持っていても、ええと、異なる意味を持つことがありますが、一方で、まったく異なる単語であっても、似た意味を持つことがあります。だからこそ、ベクトルDBやベクトル埋め込みは、あなたのユースケースにとって、ええと、非常に重要であり続けるのです。3つ目は、あなたの、ええと、意図についてです。ええと、change cut air という単語を見るだけでは、もし私が異なるコンテキストを持っていて、もし私がeコマースのウェブ、ええと、ウェブサイトを見ているのか、あるいは自動車メーカーのウェブサイトを見ているのかによって、実際には異なるものを検索していることになりますよね？だから、そうではなく、キーワードだけを使ったり、Lexi ベースの検索だけを使ったりしても、これらのユースケースの多くにはあまり役立ちません。
それで、ええと、それが私たちが mul 2. 2 0. 5 で提案しているものです。ええと、これはレキシカル検索とセマンティック検索の両方を組み合わせた新しいハブ検索 MO モデルです。だから、ええと、まず第一に、ここにある数値を見ると、かなりうまく機能します。つまり、ただ dense や sparse を行うだけでは、おそらく最大でも、ええと、リコールの50%、60%を得られる程度です。しかし、ええと、それらすべてを組み合わせて再ランキングを行うと、検索品質の向上において間違いなく多くの、ええと、改善が示されますよね？それで、ええと、私たちは実際に BGM three というモデルを使っていて、それは複数の異なる埋め込みを生成できます。
そして BM 25 は、同じようなものです。BM 25 と、ええと、事前学習済みモデルの両方を組み合わせて、より良い結果を得ることができます。いいですか？それで、ええと、ここでの課題は何でしょう？もし、もし、もし、すでにそれほど良いのであれば、なぜ、なぜ本番環境に入れられていないのでしょうか？つまり、いくつかのことが、ええと、実際にはヘッドリサーチを本番環境に入れる際の障害になっています。ええと、1つは、それが実際にあなたの、ええと、アーキテクチャをより複雑にすることです。これは非常に一般的なアーキテクチャです。
私は、ええと、Alexa検索については、多くの人がElasticsearchを使い、OpenSearchを使い、ええと、Solrを使っていますが、ええと、それらは、ええと、ダンシング、embedding検索のようなもの、ええと、性能やコストの面ではあまり優れていません。だからこそ、あなたにも、特殊な、ええと、vector、ええと、vector dbが必要で、ええと、それがあなたのemailsです。他にもいくつかあるのは知っていますが、ええと、一般的にシステムを構築するときにやることは、検索サービスを持ち、それがランキングを行うのを助け、すべての生データを保存するのを助けますが、あなたは、あなたは、あなたはまた、ええと、Lexi検索用のシステムとsematic検索用のシステムも必要です。そしてあなたも、あなたは、embedding modelsを持っていますよね？そのため、あなたのシステムは非常に、非常に複雑になり、保守する方法がなくなりますよね？ええと、2つ目は、ええと、より複数の異なるembeddingがあることです。だからコストの問題もあるわけです、よね？それで、ええと、あなたは、ええと、時にはコストを2倍にしなければならないことがあり、複数の異なるembeddingsを維持するために、場合によってはコストが3倍にさえなることがありますよね？そして、ええと、また、性能上の複数の異なるボトルネックもありますよね。
そのため、診断が非常に難しく、可観測性にとっても非常に難しいです、いいですか？ええと、だからこそ私たちは、1つに統合すること、ええと、1つの大きなclusterや、あるいは、rec、ええと、vector searchと、ええと、s spark searchの両方をホストできる1つのdatabaseのようなものについて考え始めましたよね？それで、ええと、この部分は、少し、ええと、技術的になります。なので、従来の、ええと、Alexa検索エンジンとは何か、あるいはyesが何をするのかについて、少し背景を説明します。一般的に言うと、ええと、彼らがやっていることは、inverted indexを使うことです。つまり各tokenについて、実際に、ええと、このtokenを含むdocumentsがいくつあるかをリストするわけです、よね？例えば、もし私が、ええと、ええと、Harry Potterの本を持っていて、それを異なるchunksに分割し、ええと、Harryが、私のtokenになるとします。そして異なるchunksについて、token oneにはHariがあり、token twoにはhurryが2回あるかもしれません。
これが、私たちが、私がこの、ええと、in word index listを作った方法です、よね？検索が発生したとき、私たちが行う最も簡単な方法はDAATと呼ばれ、ええと、document at a timeの略です。つまり、ええと、関連するものすべてを素早く見ていきます。例えば、私が、ええと、自分のuse caseでB, c, Aを検索するとき、B, C, Aは単に、ええと、異なるtokensです。そこで私はBから始めて、見て、 okay、D oneは実際に関連しています。次にcに行くと、d oneも関連しています。
そこで、ここですべてのscoreを足し合わせます。そしてAもD oneに関連していますよね？なのでD oneは2. 5のscoreを得ます。それが関連性です。つまり、その、the oneは実際には私たちが話しているBM score、ええと、relevanceです、よね？それから次のdocumentであるD twoに進み、次にD threeへと、1つずつ進んでいきます。そして、もしあなたのimporting listが長い場合、それが長くなることがわかります。
すべてのlistsを通過するのに多くの時間がかかりますよね？だから性能があまり良くないのです、okay？それで、ええと、それを改善する賢い方法は確かにいくつかあります。なので、ええと、その詳細については話しません。しかし、ええと、weekendまたはWNと呼ばれるものが実際にあることを覚えておいてください。つまり、ええと、このalgorithmの全体的な目標は、単に、ええと、一部のtokensをskipする、あるいは一部のdocumentsをskipすることです。例えば、もし私が、もしすでに非常に関連性の高いdocumentを1つ見つけているなら、私たちができることは、十分なものを持っていないすべてのdocumentsをskipすることです。それで、ええと、私は、あなたは、これを本当に理解する必要はありませんが、その場合、D twoは実際には、scoreがD oneよりも実際にはずっと、ずっと小さいことがわかります。
だからそれをskipして、直接D fiveに進みます。もし、もし皆さんが興味があるなら、これについて非常に良いpaperが実際にあります。これは、すべての、ええと、ええと、ええと、searchにとって非常に基本的なpaperです。なので、ええと、このpaperでこれについてもっと読むことをお勧めします。Okay？ええと、しかしdouble endには何かdrawbacksはあるのでしょうか？ええと、確かにあります。そうでなければ、私たちはそれを、in、in、inに構築しなかったでしょう。私は、それが多くのuse casesで多くのperformance issueにぶつかっていると思います。
ええと、top K が大きく、チャンクサイズも大きく、ええと、長いクエリがたくさんある場合、それは RAG アプリケーションを構築する際にはあり得ることです。従来の検索について考えると、ええと、人々はただ 3、4 個の異なるキーワードで検索するだけです。でも通常のユースケースでは、あなたは、実際かなり長くなります。なぜなら、みんなが、より大きなモデルにはもっとコンテキストを与える必要があると言っているからですよね？そのため、人々は結果として長い、より長いプロンプトを書くようになりますよね？なので検索は、ええと、よりパフォーマンス負荷の高いものになります、はい。なので、ええと、それが mill 2. 5 で私たちが見た、ええと、ハイブリッドインデックスと呼ばれるものの理由です。そうですね。ええと、それは従来の、ええと、インデックスとは少し違っていて、ええと、主な違いが 2 つあります。まず、複数の異なるインデックス実装があります。
ええと、単に word index を使うだけではなく、graph index もあります。ええと、皆さんが Vector db に詳しければ、それは密度メーティングでも私たちが行っていることです。ええと、graph の graph、ええと、graph based index は実際かなり良いです。長いコンテキストがある場合、ええと、大きな top case がある場合です。そして graph index のより良い点は、多くの、ええと、機械学習的なものを活用できることです。
たとえば、その上で quantization を行えます。その上で多くの、ええと、ハードウェアの、ええと、acceleration のようなことができます。ええと、私たちは cmd を使い、ええと、実際の rating C plus も使っています。なので、ええと、パフォーマンスは実際かなり良いです。なので、ええと、すみません、ええと、グラフが少し小さいです。
ええと、ただ非常に簡単なイメージをお伝えすると。私たちは多くのデータセットでいくつかのタスクを実施し、その結果、es と比較してほぼ同程度の recall であることが示されています。ええと、私にとってメモリ使用量は、試し、ええと、es と比べて 2 倍少なく、パフォーマンスは 2 倍または 3 倍速いです。ええと、それは単純に、私たちが異なる quantization policy を活用しているからです。なので、ええと、recall は少し低くなりますが、ええと、高いパフォーマンスの向上と、より多くのメモリ節約が見られます。
いいですか？はい。なので、ええと、背景は本当に、時には、背景知識がないと理解するのが難しいかもしれませんが、心配しないでください、ですよね？ユーザーとしては、ええと、使い方はとても簡単です。3 つのステップを踏むだけです。最初のステップは、connection と、または scammer 情報を作成することです。なので、ええと、ここのコードから、ええと、実際に関数を指定する必要があり、それがすべての embeddings を行うのを助けます。
ええと、ここには BM 25 functions がありますよね？なので、ええと、実際には input field を指定し、それが tags で、alpha food は sparse です、はい？そして PM 25 のようなものを使って、すべての imbalance を行いますよね？それが最初のステップです。collection があります。2 番目のステップは、その上に index を構築する必要があることです。なので、ええと、私たちが実際に構築しようとしている index は inward index です。graph index version もありますよね、たくさんの parameters があり、それについては本当に、本当に心配する必要はありません。
3 番目のステップは、データを挿入する必要があることです。なので、あなたのデータは embeddings なしの純粋な tax だけです。それが mill 2. 5 と、ええと、以前のすべてのバージョンとの大きな違いです。以前のバージョンでは、ほぼ vector in vector alt でした。なので、embedding generation をすべて自分で行う必要がありましたが、今はすべての functions によって、すべての embedding generation を行うのを助けられます。
なので、あなたは、like、food tax だけを提供すればよいのです、そうですね？また、dense embedding part にも取り組んでいます。なので、ええと、私たちは多くの、like、異なる embedding models と re ranking models を統合しようとしています。なので、ええと、vector database を使うのはずっと簡単になります。つまり、embeddings をどう扱うかについて本当に心配する必要がなくなりますよね？なので、データが実際に、in search に入った後は、別の screen で検索するだけです、たとえば who started AI search。はい。
そんなに簡単に、実際に、ええと、スパースミーティングのような非常に基本的なデモを行うことができ、より良いパフォーマンスのために、スパースマッティングをデンシティミーティングと一緒に使うこともできます。いいですか？それで、ええと、私たちはこの、ええと、meal 2.5バージョンをリリースしようとしています。ちょうど来週です。ですので、ここですべての新機能について話すのはこれが初めてです。なので、ええと、気軽に私たちに話しかけてください。
ええと、このバージョンは、ええと、より多くの検索機能を持つことにかなり重点を置いています。BM 25だけでなく、キーワード、ええと、マッチングもあります。非常に長いコンテキストの場合、キーワード meals でドキュメントの1つを抽出したいなら、それは実際に可能です。私たちは、ええと、フィルタリング性能を向上させるために複数の異なるインデックスを持っています。ええと、また、ユーザーがベクター検索を行おうとするときのコストを削減するために、さまざまな conservation を多数追加していますよね？それで、ええと、現在私たちは meals 3.0 の準備をしているところです。
ですので、皆さんのフィードバックもぜひ聞かせていただきたいです。来年初めをターゲットにしている新バージョンでは、UDFや、ホットコードデータ分離のような興味深い機能もありますし、今、多くの人がマルチテナンシーをやろうとしています。実際にマルチテナンシーについてのトークもあります。ですので、ええと、ここでの重要な課題の1つは、多くの、ええと、コードテナントのコストをどう削減するかです。それが 3.0 の目標の1つです。
はい、でも気軽に、ええと、私を捕まえて、実際に必要としている機能についてもっとフィードバックをください。ですので、ええと、私たちは、ええと、多くの AI アプリケーションのために、あなたの、ええと、ようなものを改善し続けていますよね？はい。では、私たちが誰かについて簡単に。もしご存じない場合のために、私たちは GitHub 上で最も広く採用されている Vector DB のようなものです。もちろんオープンソースです。ええと、Linux Foundation の傘下にあります。
400人以上の、ええと、コントリビューターがおり、3万以上のスターがあります。はい、私たちは非常に速く動いており、そして、ええと、1000社を超えるエンタープライズ、ええと、企業が実際に Mirror を directed db として使用しています。はい。私たちについて何か質問があれば、気軽に私に連絡してください。では、ありがとうございます。
素晴らしいです。ええと、James は実際にここにいます。なので、もし、ええと、彼はすでにいくつかの質問に答えているようですが、2.5やご覧になった内容について質問がある方は、ええと、気軽にそれを Q&A か、ええと、チャットパネルに入れてください。ええと、それは viss 2.5 に関するものだけである必要はありません。
ですので、vis の現在の実装についてお持ちのどんな質問でも、ええと、あらゆる種類のバグ、あらゆる種類の、ええと、問題についてでも結構です。そして、ええと、はい、私たちはこれらの質問に答えるためにここにいます。そして、ええと、私たちのすべてのウェビナーと同様に、ええと、すべての録画とデッキは共有されます。ですので、まもなく私たちからメールが届き、ええと、それらすべての詳細が記載されています。というのも、これは、かなり短い、ええと、動画でしたが、実際には内容がかなり濃かったと思うからです。
それで、ええと、James が述べたように、ご存じのとおり、私たちは、ええと、スパースベクトルを Mil Vista 2.4 に追加するための、ええと、仕組みを提供していました。しかし 2.5 との主な違いは、実際にテキストを raw 形式で持ち込むと、ええと、私たちが実際に、ええと、ベクター変換を行い、基本的には検索を行えるという点です。ええと、例えば、ええと、Ellucian ベースの、ええと、アプリケーションで行っているかもしれないものと似ています。ですので、設定する際には、ええと、ご存じのとおり、単に、ええと、テキストフィールドを持つだけではないことを確認する必要があります。関連付ける関数を指定することを必ず確認する必要があります。
そうすることで、ええと、スパースフィールドをテキストフィールドに接続できるだけでなく、ええと、実際に、ええと、ベクター埋め込み変換を行うことも確実にできます。少し違いますが、ええと、その設定を理解してしまえば、ええと、準備は完了で、実際に、ええと、あなたの、ええと、ハイブリッド検索を始めることができます。はい。では、ええと、James、話せますか？ああ、もちろんです。はい。
えー、ありがとうございます、皆さんありがとうございます。それでは、では、えー、最初の質問から始めましょう。ハイブリッドはどうやるのですか？ えー、通常のベクトル検索と BM 25 全文検索の間でハイブリッド検索はできますか？はい、それが、それが私たちがそれをハイブリッド検索と名付けている理由ですよね？つまり、その、その、そのハイブリッドと名付けた主な理由は、BM 25 と、両方のバー、spar many、そして density many の両方で検索を行うからです。なので、えー、一般的なパターンとしては、それぞれの、えー、battery index から top K を検索します。それは BM 25 の場合もありますし、えー、dancing many の場合もあります。
そして、えー、えー、異なる index からすべての結果を取得したら、実際に行うのは再ランキングです。なので、再ランキングを行うために、えー、別のモデルを使うこともできます。私たちが推奨するのは常に、えー、while か cohere、または AWS や Google Cloud の何らかのモデルを使って、えー、再ランキングを行うことです。または、より単純な再ランキングポリシー、たとえば単に、えー、えー、com、えー、重み付きランキングを使うようなものでも構いません。つまり、すべてのスコアを組み合わせて、えー、より良いランキングを得るということです。
なので、えー、とても単純な再ランキングポリシーを使っても、性能が向上するのが見られます。えー、なぜなら BM 25 は実際、えー、優れているからです。えー、一部のユースケースでは、Lexi search は keyword に本当に強いのですが、一方で、Denman は context にかなり優れています。なので両側で検索すると、あなたは、あなたは、すでにいくつか異なる結果を見つけられますし、実際、えー、えー、つまり、えー、それらをすべて組み合わせると、えー、検索品質を向上させるのに役立ちます。はい。いいですね。
とても良いです。えー、では、Ray からの次の質問です。えー、BM 25 と splayed を比較すると、私は Zills は splayed の使用を推奨していると思っていました。えー、それは、実際よい質問です。私たちも splayed は実際、えー、ずっと優れていると見ています。多くの、えー、評価データセットで。
えー、しかし繰り返しますが、えー、split はまだ事前学習済みモデルです。なので、それは、それは、それは、えー、検索はしますが、それでも事前学習済みです。したがって、いくつかのユースケースでは、先ほど述べたように、もし、えー、あまり一般的ではない特殊な用語がある場合、それ、それは、えー、事前学習済みモデルが、えー、それらのトークンや用語を理解するには非常に、えー、扱いにくくなります。なので、えー、それは通常、えー、BM 25 の q、えー、keyword search を使いたいユースケースの一つです。つまり、えー、繰り返しますが、えー、とはいえ、えー、90% のケースでは、えー、spread の方が良い場合があります。えー、しかしそれでも一部のケースでは、より良い、えー、えー、検索結果を説明する方法が欲しい場合、検索結果を制御したい場合、もし、検索結果が実際、えー、あなたのデータ分布に関連している場合です。
そのため BM 25 は依然として、えー、非常に重要です。そして一方で、BM 25 の良い点は、本当にモデルが必要ないことです。つまり、実際の、えー、推論エンジンは必要ありませんが、それでも、えー、非常に遅くなる可能性があります。なので大規模データセットがある場合、えー、BM 25 は依然として、えー、最もコスト効率のよい検索方法になります。でも私たちは、えー、splayed もサポートしていますよね？つまり、誰かが splayed を使ってベクトル化することを選べば、それを vis に入れられるのですね。えー、まさにその通りです。なので、えー、私たちが、えー、PM 25 検索を行う方法は、他の検索エンジンや、他の従来型検索エンジンが行うこととは異なります。
えー、私たちは依然としてすべての document を sparse vector に変換します。つまり、それが、それが理由です。なぜなら私たちは、私たちは、私たちはすべて vector database なので、扱うものはすべて vector search だけです。なので、えー、すべての document を、sparsing man のようなものに変換することで、実際にいくつかの利点が得られます。conation ができたり、えー、えー、いくつかの、えー、nearest neighbor search、えー、appro pro nearest neighbor search のようなものができます。そのため、US search と比較して高速になります。
はい。いいですね。わかりました。次の質問です。えー、Bart からです。私は使っています、えー、新しい vis で array list metadata type のサポートはありますか。えー、ちょっと、えー、もう一度質問を繰り返してください。
新しい mil では、array／list のメタデータ型はサポートされるのでしょうか？ これは、ええと、実はすでにサポートされています。たぶん、ええと、2.4 までさかのぼってすでにサポートされていると思います。それで、これらの red データ型にいくつかのインデックスを追加することもサポートしています。次のステップとしては、map と set をサポートする予定です。
それも非常に重要になります。というのも、人々はすべての tag を mirror に保存したいからです。なので、ええと、次のステップは map で、ええと、3.0 では、ええと、geolocation と、おそらく date をエクスポートする予定です。はい、たしかあなたは、ええと、indexing を改善したとおっしゃっていましたよね？ ええと、array については、別の in word index があり、bid set という新しい index type をサポートしています。なので、ええと、私たちが見ているのは、多くの人が、ええと、それが tag であれ array であれ、使っていて、つまり低 cardinality だということです。
たとえば、male、female だけになるような場合です。そして bid set index を使うと、実際には高速化されます。なぜなら、in word index を使うと、inverted list が、ええと、非常に長くなり得るからです。というのも、ええと、値が 2 つか 3 つしかないからです。でも bid set を使えば、2 つか 3 つの bid set だけを保存すればよいのです。なので、ええと、これも 2.5 のリリースの一部で、bid set を使うと、ええと、低 cardinality のもとでは、ええと、元の imported index と比べて、ええと、100 倍、100 倍の高速化が見られます。いいですね。
それで Bart から追加の質問があります。彼は、ええと、haystack を使っていて、それはメタデータに arrays を使っています。なので、ええと、はい、James が言ったように、私たちはすでにそれをサポートしていると思います。ええと、haystack との integrations もありますし、たぶん tutorial もあります、ええと、Bart、それは私たちの vis documentation で見つけられると思います。コードを確認する必要があると思います。haystack al がすでに、つまり haystack integrator が、ええと、array をサポートしているかどうかです。
ただ、はい、私たちはすでに array をサポートしています。なので、おそらく enter、ええと、integration の間を更新する必要があり、確認します。はい、では Bart、そういうことです。質問してくれてありがとうございます。では次に、ええと、より具体的には、ええと、複数の検索パラメータを作成し、reran を提供して、1 つの dense vector column に対する vector search と、sparse vector column に対する BM 25 full tech search の間で hybrid search を行いたい、ということです。なので、ええと、前の質問は、つまり hybrid search はできますか、というものでした。これは、その質問に対して、かなり、ええと、より詳細な内容です。
はい、なので実際にそれをどう行うかについて簡単なデモをしました。つまり、基本的には、ええと、UDF を作成します。それは実際には generative function で、ええと、たとえば 1 つの chunk、chunk field を sparse manning に変換したい、ということを指定します。それがステップ 1 です。ええと、ステップ 2 は、検索して、re ranking function を指定することです。なので、ええと、検索では、実際には 2 つ、ええと、2 つの異なるものを渡す必要があります。
1 つは、ええと、query document です。もう 1 つは、ええと、density mannings としての query embedding です。すると何が起きるかというと、spars と dense の両方で検索し、re rank を行います。なので、ええと、これは単に、ええと、raw data をサポートする、ええと、始まりにすぎません。次のリリースでは、ええと、私たちがサポートする予定なのは、dancing embed models と re-ranking models も s に統合することです。
なので、ええと、その時点では、たぶん、ええと、embed が実際にどのように変換されるかを、そこまで気にする必要はなくなると思います。そして、ええと、あなたがやる必要があるのは、ええと、データを通すことだけです。それが image であれ、ええと、contact であれ、mulli に入れるだけです。はい。私たちは多くの integration を行っています。ええと、Mullis については、推論や model serving のようなことは絶対にやりたくありません。
なので、私たちは多くの、ええと、open source の inference engines と統合しています。ええと、たとえば Ray、たとえば、ええと、a w bedrock です。なので、ええと、それらが、ええと、あなたのためにすべての inference を行えます。つまり vis では、すべての data をそれらの inference engines に投げて、embeddings を集めるだけです。いいですね。それでは、vis で 1 行にいくつの vector fields がサポートされるのか、皆さんに思い出してもらいましょう。
ええと、ちなみに、現時点では4つという制限があると思います。2つ追加して10にしようと考えています。はい。というわけです。では、次はCharlesからの質問です。
GPUを選択する際、あ、いえ、すみません、Q10からです。VISS 2.5は単一フィールドのupsert操作をサポートしていますか？ええと、残念ながら現時点での答えはノーです。理由は、ええと、まだいくつか、うーん、インデックス処理を行っているためです。単一フィールドは可能ですが、実際にやらなければならないのは、既存のデータセットからそれを取得し、ええと、その1行を変更して挿入することです。それは、それは、それは、それは、クライアント側ではまだ行えますが、ええと、自動のobservedはサポートしていません。また、ええと、パフォーマンスも、ええと、あまり良くありませんよね？ですので、ええと、それを、それを、それを行うには、すべてのプライマリケースの上に非常に、ええと、効率的なインデックスが必要です。
残念ながら、それはまだ開発中です。ええと、ただ、ええと、これは実際に私たちのロードマップ上にあり、ええと、3.0で行う予定のことで、ええと、おそらく来年のQ1にリリースされる予定です。はい。いいですね。
では、Charles、次はあなたの番です。GPUアクセラレーションオプションを選択してデプロイする場合、BUは大規模データセットのインデックス作成と推論にGPU VRAMを自動的に使用しますか？ええと、GPUについていくつかコンサルテーションはできますが、ええと、現時点では、どのように、どれだけのメモリを、ええと、使用するかについての制御はありません。ええと、データセットが実際に、ええと、GPUメモリと比較して大きい場合、ええと、GP me、ええと、自動メモリの問題のようなものにぶつかる可能性があります。ですので、ええと、残念ながら慎重に設計する必要があります。そこで、GPUメモリとCPUメモリの間で、ええと、そのデータをスワップしようとはしています。
ええと、結果としてはパフォーマンスがあまり良くなく、実際には大きなジョブでは優れています。なので、NVIDIAチームと協力して、何ができるかをまだ検討しています。ただ、ええと、現時点でGPU Indexで非常に良いパフォーマンスを得るには、すべてのデータをGPU上にホストする必要があります。わかりました。さて、これはNilesからの次の質問にうまくつながります。つまり、vissはCPU上で実行するように最適化されていますか？エンタープライズまたはハイパースケールでvissを実行するためのメモリ要件は何ですか？また、パフォーマンス上の依存関係や影響はありますか？ええと、Vissは実際にCPUで実行するように最適化されていますか？はい、私たちは、実行できます。ええと、GPUとCPUの両方で実行できますが、ほとんどの場合、CPU上で実行することを推奨しています。なぜなら、検索の多くは、すでに、ええと、パフォーマンスが十分に良いからです。CPUはまだ非常に高価で、すべてのデータをGPメモリにホストする必要がありますよね？ですので、私たちは、ええと、inhaleとarm CPUの両方で多くの最適化を行っています。
では、ええと、mulを実行するためのメモリ要件は何ですか？それは、それは、それは実際にはデータセットに基づくようなものです。ですので、ええと、常に、ええと、4コアのようなところから始めることができます。スタンドアロンとしてはマシンを提供します。ですので、ええと、それは、それは実際に最小構成のデプロイであり、また、うーん、Kubernetes環境でも実行できます。私たちが見ている最大規模のデプロイは、ええと、500億です。
ですので、ええと、Kubernetesとすべてのクラウド依存関係を使ってカスタマーモードでデプロイすれば、実際に非常によくスケールします。はい。そして、ええと、優れたスケーラビリティとパフォーマンスを得る最も簡単な方法は、私たちのマネージドサービスであるこのクラウドを使うことです。これは実際に優れたTCOを提供し、コストを削減します。また、管理方法について本当に心配する必要もありません。
ですので、私たちは、ええと、完全マネージドサービスであるSaaS提供と、あなたのVPCにデプロイされるA-B-Y-O-Cの両方を用意しています。したがって、セキュリティ上の懸念がある場合は、それがあなたのユースケースに最も適している可能性があります。ただ、Niles、500億ベクトルというのは、かなり印象的な数字です。ええと、そして、ええと、それは、それは実際に私の意見では典型的なエンタープライズ、ええと、ええと、グレードをはるかに超えています。ええと、インターネットのようなレベルの、ええと、ええと、ベクトル埋め込みに近づき始めています。では、次はchitonからの質問です。
このアップデートで、コレクション内に4つを超えるベクトルフィールドを作成できるようになりますか？少し答えていただいたような気もしますが、ええと、もう一度答えましょう。はい、ええと、皆さんには、それを10個くらいに調整できるつまみがあります、ええと、ベクトル Fand、ええと、私たちが、ええと、実際に追加を考えているのは、 ええと、不均衡の配列で、これは実際には、ええと、 どちらかというとテンソルのようなものです。ですから、ユースケースとしては、ええと、私たちは、人々が late interaction models covert のようなものを使おうとしていて、 一連の不均衡を1つのフィールドに入れようとしているのを見ています。ええと、それは私たちが見たもので、 実際、ええと、私たちのロードマップにもあります。ただ技術的に言えば、もし、もし皆さんが、 そのようなモデルベクトルモデルを使っていないのであれば、4つ または5つのフィールドで、実際には、ええと、 ユースケースには十分すぎると思います。
おそらく、2つ または3つのベクトル、ええと、フィールドを持つだけでしょう。1つはおそらく PM 25 用、1つは spars manning like spray model 用、 そしてもう1つは、ええと、density man 用、 それで、それで十分かもしれません。それ以外で、もしもっと多くの、ええと、 埋め込みモデル、つまり複数の異なるフィールドを使うような場合、それは パフォーマンス面でも、ええと、非常に課題になると思います。なぜなら、皆さんは 複数の異なるインデックスを検索しようとしているからです。はい、そしてつまり、ベクトル埋め込みの素晴らしいところは、 文脈を理解することですよね？だからこそ、皆さんは、その、 あらゆる種類の異なるクエリから非常に興味深い検索結果を得ることができるのです。なので、ええと、そうですね、それも見失わないようにしましょう。ええと、次の質問は、ええと、 ergo からで、Gmail のデータをベクトル化できますか？ ええ、はい、つまり、それ、それ、それこそが人々が、ええと、 RAG アプリケーションを構築する理由です。
ええと、これは個人データを検索する最も簡単な方法です。実際、それを行うのを助けるツールはたくさんあります。私は、ええと、LAMA index と unstructured io の両方を見てみることをお勧めします。すでにいくつかの、ええと、コネクタがあるのを見ましたよね？ なので、ええと、さまざまな、あなたの、ええと、SaaS からすべてのデータを取得できます。あなたの Zendesk、 Gmail、Slack チャンネルなどです。そうしたデータをすべて取得し、 チャンク化や埋め込みを行うのを助けるコネクタもあります。 そして、私たちは彼らとのコネクタを持っているので、皆さんは、ええと、 すべてのデータを埋め込みに変換し、 それを、ええと、those または、 または mul、ええと、に送ることができます。それは典型的なユースケースです。
なので、ええと、ぜひ、ええと、ええと、両方のオープンソース long chains を見てください。おそらくそのうちの一方でしょう。ですから、ええと、それらのオープンソースソフトウェアを見て、 どれが最適かを確認してください。 ただ、使うのはとても簡単になるはずです。素晴らしいです。ええと、 それから、ええと、sala、 ここでは少し文脈が足りないかもしれませんが、 質問は、証明書はありますか？というものです。 その証明書が何に関連しているのか、私にはわかりません。ですので、もう少し詳しく教えていただければ、 それにお答えします。
ええと、Ali の質問です。画像の検索、 画像埋め込み、主にX線画像ではどれくらい効率的ですか、 テキストで実演したような医療画像向けの 特別な機能はありますか？ うーん。ええと、はい、 医療画像は少し違うかもしれないと思います。ええと、おそらく特別なモデルが必要です。たとえば、ええと、 埋め込みモデルは実際には機能するでしょう。それは皆さんのデータで訓練されている必要があります。ええと、一般的なものについては、たとえば多くの オープンソースの埋め込みモデルは、どちらかというと、ええと、 靴や服のような日常的な物体で訓練されています。 それは確かに、ええと、皆さんのユースケースには役立たないと思います。
なので、最初に重要なのは、使える埋め込みモデルを見つける必要があるということだと思います。もし、もしLucにそれがないなら、自分のデータセットに基づいて調整しなければならないですよね？でもそれ以外では、医療画像の埋め込みが、他の、ええと、たとえばベクトルDV側の画像検索と大きく違うとは思いません。おそらくできることの一つは、いくつかタグを持たせたり、あるいはそれらのテキストの上で何らかのフィルタリングを行ったりして、より良い結果を得るのを助けることだと思います。はい。でも、登録側から見ると、それは非常によく似たものになるでしょう。はい、つまり、Hugging Faceに行って、そこにあるさまざまなモデルを全部見てみるといいと思います。
ええと、Jamesが言ったように、もしそれが、たとえば非常に典型的なX線画像であれば、かなり簡単になると思います。でも、もし非常に、非常に特定のもの、たとえば膝とか、何か普通ではないものがある場合は、はい、自分で構築しなければならないかもしれません。ええと、Shilpaからの次の質問です。visはOpenAIと統合できますか？ああ、実は私たちはすでにOpenAIと統合しています。なので、もしOpenAI retrieval pluginの統合を確認していただければ、実際に私たちはすでにそこにいて、open aiとの記録における最初のパートナーの一つのような存在です。
はい。そして実際には、OpenAIをmealsと一緒に使う他の方法もたくさんあります。たとえば、先ほど言ったように、long chainとalumni nextを見てみると、彼らはOpenAIとZills cloudの両方をサポートしています。なので、すでにこれらを一緒に使うことができます。素晴らしいです。
それから実はZillows cloudに関する質問があります。Zillowsで許可されている最大コレクション数はどれくらいですか？たとえば、1000個のコレクションはパフォーマンスに大きく影響しますか？インスタンス内のコレクション数の妥当な上限はどれくらいですか？ええと、それは実際良い質問です。なので、現時点では非常に強い制限があり、たしか、それぞれについて1つ、私たちは64コレクションをサポートしていません。はい、その理由は現時点でいくつかの制限があるためです。ええと、私たちがサポートしているコレクション数は、どのクラスターでも実際には制限されています。
なので、多くのユーザーがマルチテナンシーを使いたいと考えているのを目にしています。各質問または各パーティションを1つのテナントとして扱いたいマルチテナンシーのユースケースを構築したいというものです。これを解決する一つの方法は、partion keyに関する私たちのドキュメントを確認することです。これは、私たちがマルチテナンシーを行うために推奨している方法です。ええ、ただし、私たちは実際にサポートできるコレクション数を改善するプロジェクトに取り組んでいます。すでに10Kを超えるコレクションをサポートできるようになっており、各コレクションには1つのクラスター上で1000を超えるパーティションがあります。
なので、その最適化が終わった後、おそらくこれは今後1〜2か月でリリースされる予定で、その後、現在のコレクション制限をおそらく10倍にすることになるでしょう。はい。素晴らしいです。わあ。質問がたくさんあります。
ええと、皆さんにお知らせしておきたいのですが、私たちにはdiscordチャンネルがあります。そこではJamesを見つけることができます。また、質問や問題をGitHub issuesに投稿することもできます。さらに今は毎週オフィスアワーも行っているので、visでの皆さんの具体的なユースケースについて、いつでもかなり深く掘り下げてお話しできます。そして、もしJamesがそこにいなければ、彼のエンジニアの一人がそこにいるでしょう。
ええと、それに、皆さんの質問に確実にお答えすることに加えて、私たちは、ええと、これは私たちにとってドキュメントにいくつか変更を加える機会でもあると認識しています。そうすることで、こうした、ええと、つまり、質問をなくし、皆さんにとって最初からずっと簡単にできるようにしたいのです。ですので、あと数分間ラインを開けておいて、さらにいくつか質問が入ってくるのを待ちますが、私は、ええと、また別の質問がいくつか入ってきているのが見えます。ただ、それに入る前に、ええと、皆さんにお伝えしたいのは、ええと、ご覧のとおり、James は何でも知っています。彼は間違いなく Mr. Vis ですが、それは彼が、ええと、皆さんのようなユーザーと多くの時間を過ごしていて、それを本当に楽しんでいるからです。ですので遠慮しないでください。GitHub に行って、Discord に行って、本当に彼に連絡してください。ええと、皆さんが何をしているのか、何が分かりにくいのか、何が足りないのかを彼が理解することは本当に重要です。そうすることで、彼はロードマップを適切に定義し、ええと、これを、すでにそうではありますが、本当に堅牢な、オープンソースの、ええと、ベクトルデータベースにしていくことができます。
では、Nitty からの質問です。OpenAI 以外で、VISS two five と一緒に使える他の LLM には何がありますか？Viss two five を使って OpenAI assistant のようなアシスタントを作れますか？はい、思うに、思うに、ええと、ローンチするにあたって、あるいは私の次の、アシスタントのようなものを作ることは、実際には非常に、ええと、非常に簡単になると思います。そして、ええと、最も良い点は、すべてがオープンソースなので、実際には誰にも、ええと、お金を払う必要がないということですよね？では、どのような、ええと、大規模モデルを使っているのか？埋め込みモデルについては、私たちの友人である Warrior AI と Frank に触れないわけにはいきません。なので、私は、私は彼らの埋め込みモデルが一番好きです。そして生成モデルについては、今のところ、ええと、ええと、私のお気に入りは quality になると思います。つまり、open eye か quality のどちらかです。
はい、ですので、Nitty、使える LLM は、ええと、たくさんあります。ええと、そして、私たちが LLM にお金を払うのを妨げたいというわけではありませんが、開発中のことを考えてみてください。ええと、私たち自身もそうしてきました。これらの LLM に対して多くの呼び出しを行うことになりますし、その追加コストは本当に発生させたくないはずです。少なくとも開発段階では。ですので、私たちの推奨は常に、つまり、オープンソースの LLM やオープンソースの埋め込みモデルを使って、ええと、アプリケーションを完璧に仕上げられるようにすることです。
本番環境に移行する準備ができて、そのうえで有料の LLM を使うことに強い確信がある場合は、そのときに、ええと、それを有効にすることをお勧めします。そしてさらに、それに加えて、実際に私たちには、つまり、さまざまなタスクに対して多くの異なる LLM を使えるということについて語っているブログがいくつもあります。たとえば、評価を行うために、自分の、ええと、結果のジャッジとして、ええと、LLM を使うことができます。そして、全体を通して同じ LLM を使う必要はありません。ですので、ええと、賢くやってください。
ええと、無制限のリソースを持っている人はいません。OpenAI や Apple でさえそうではありません。ですので、開発の、ええと、費用をどのように使うかについて、本当に賢く判断してください。はい。わあ、本当に素晴らしかったです。ここにたくさんの質問があります。
そして、ええと、James、ありがとうございます。いつものように、ええと、こちらの Mr. Melva は何でも知っています。そして、ええと、プロジェクトに対する彼の熱意は、ええと、本当に、ええと、明らかだと思います。そして、ええと、それは皆さんのようなユーザーが、ええと、コードで、質問で、ドキュメントで、そして単に、ええと、Melva を使うことで貢献してくれているからです。ですので、その調子で続けてください。
ええと、彼は、皆さんが取り組んでいるものを見るのが大好きです。ですので、本日はお時間をいただき、本当にありがとうございました。それから、ああ、Rob、もしまだ参加しているなら、あなたの動画を見てみます。素晴らしい皆さん。録画は少し後で皆さんに送られます。
ありがとうございます。またお会いしましょう。
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.