Join the Webinar
Loading...
何を学べますか？
このウェビナーでは、一歩引いて、特定のユースケースに最適なベクトルデータベースを選択するプロセスをシンプルにします。考慮すべき主要な要素を分解し、複雑な用語をわかりやすく解説し、十分な情報に基づいた意思決定に役立つ実践的な洞察を提供します。経験豊富な開発者であっても、この分野が初めてであっても、このセッションでは、ベクトルデータベースの状況を容易に把握するための知識と自信を身につけることができます。
取り上げるトピック:
- ユースケースごとに考慮すべきパフォーマンス要件とは
- ニーズとの互換性について、さまざまなベクトルデータベースを評価する方法
- さまざまなベクトルデータベースソリューションにおけるスケーラビリティと柔軟性の比較
今日は、ベクトルデータベースの選び方についてお話しします。すでにいくつか質問が来ていて、これから取り上げるんですが、まさにぴったりです。誰かが、ええと、私のためにうまく話題を振ってくれて、仕事を楽にしようとしてくれているのかは分かりませんが、本当にありがたいです。ええと、最初の質問は本当にシンプルなものです、Li。ベクトルデータベースとは何ですか？それを30秒で答えられますか？はい。
あまり、すごく良い説明は持っていないんですが、ベクトルデータベースは、ええと、ええと、保存と検索のため、そして、ええと、ええと、ベクトル検索とベクトルストアのためのデータベースです。はい、これです。完璧です。シンプルな答えですね。ええと、それからもう一つ質問があります。それは、グラフデータベースとベクトルデータベースの主な違いは何ですか？というものです。それについては最後の方で答えます。
ええと、というのも、私たちには、ええと、取り上げたい内容がたくさんあるからです。そして、その主な違いが何なのかについて、少し理解しやすくなると思います。なので、そこに深く入り込む代わりに、その質問にたどり着くころには、それがすごく明らかになるように、基礎を整えていこうと思います。いいですか？これは、ええと、とてもインタラクティブなものにする意図もあります。ですので、質問があれば、ええと、できる限りそれを見ます。
そして、ここにいる私の友人のSaachiもそれらを見ていますが、では始めましょう。もう一つ、私たち全員が認識しておきたいことがあります。それは、今日はパイの日だということです。ええと、パイの日に馴染みがないかもしれない方のために言うと、ええと、3月、ええと、14日、3. 14、ええと、この非常に神秘的な、ええと、数字に敬意を表してですね、いつも私にとって興味深いのは、ええと、それは無限の数なのに、円は世界中のいたるところにあるということです。ですので、皆さんが少しでもパイ、ピザパイ、あるいはアップルパイやチェリーパイを、この日にちなんで食べているといいですね。
そして、ええと、トピックに入りましょう。今日私たちが取るアプローチは、私たちが、私の意見やLeeの意見として、どのようにベクトルデータベースを選ぶべきかをただ押しつけるだけにはしたくない、ということを確実にしたいというものです。私たちにとって本当に重要なのは、ベクトルデータベースにおいて考慮すべき主要なポイントには何があるのかを皆さんが理解できるようにすることです。そうすることで、それが皆さんの特定のユースケースで本当にうまく機能します。ええと、今では誰もがベクトルデータベースです。万歳、それは本当に素晴らしいことです。
私が少し不満に思っていると思うかもしれませんが、実は、皆がベクトル埋め込みに興味を持っていることを本当に嬉しく思っています。なぜなら、それらは非常に強力で、ええと、私たちが行っている仕事において、すでにかなり大きな影響を与えているからです。そして、ええと、それについて私たちがもっと学べば学ぶほど、より多くの開発者に、ええと、それを活用してもらえるようになり、もっと多くの洞察を得られるようになると思います。ええと、それは本当に素晴らしいことなのですが、一方で、多くの皆さんにとって、どのベクトルデータベースを検討すべきか、そして何を見るべきかが分かりにくくなります。ですので、私たちはこの質問から始めます。それは、ベクトルデータベースの主なユースケースは何ですか？というものです。RAGが何であるかは皆さんご存じだと思います。retrieve augmented generationですが、Leeが、それは数多くある中のたった一つに過ぎない、と説明してくれます。そして、ええと、それからLee、もし皆さんにユースケースが何かを伝えるだけでなく、それらの非常に具体的なユースケースに関して、Ectorデータベースで人々が考慮すべき特定の機能、特定の要件についても教えていただけますか？では、はい、gi、gi、ベクトルデータベースとは何かについていくつか質問をいただいています。
なので、ここでいくつか、いくつか、いくつか、いくつかの概念を紹介する必要があると思います。ベクトルデータベースと、ええと、私たちは、私たちは、私たちは、私たちはデータを抽出しようとします、ええと、その、その埋め込み、つまり、ええと、グラフや、ええと、ええと、動画、音声のような非構造化データから得られるベクトルです。こういったものをベクトルデータベースにインストールし、別のベクトルに基づいて検索できます。ですので、私たちはそれを類似検索と呼びます。そして、ええと、ユースケースについては、最も、ええと、その、その、私ができる、私が単純にこれを二つの異なる、二つの異なる、ええと、部分に分類できると言います。
そして最初はオンラインのものです。つまりオンラインのものでは、最も、ええと、典型的なものは、ええと、それはラックで、ええと、最もホットなもののはずです。そしてラックは、ええと、ええと、LMモデルと連携します。つまりプロンプトが必要で、データベースに保存されている、ええと、関連情報をいくつか取得します。そして、ええと、それをあなたのクエリと組み合わせてプロンプトにし、ええと、モデルに入力して、ええと、大規模モデルが、いくつかの、より多くの情報を理解するのを助けます。
おそらくそれは、ええと、プライベート情報であったり、すでに更新された情報であったり、あるいはこの会社では、私たちはそれをラックと呼んでいます。そしてまた、ええと、ラック以外にも、実際ラックは最も難しいトピックですが、ラック以外にも、データベースの内部では非常に多くのことが起こっています。オンラインのケースでは、たとえば、グラフ検索を行います。たとえば、Amazonで似たような、ええと、商品を検索しようとしたり、Googleで、ええと、画像検索を行ったりします。ええと、基本的に画面の裏側、裏側では、ええと、グラフ検索が行われています。
そして、ええと、このグラフの背後、ええと、グラフ検索の背後にあるのは、ええと、ベクトル検索です。そしてこれが、ベクトルデータベースを使うべきところであり、また、ええと、いくつかのドキュメント検索や、ええと、不正検知にも使います。不正検知というのは、ええと、ええと、何らかのリスク、ええと、何らかの問題、何らかの危険なことが起こり、そしてある取引が、ええと、非常に疑わしいかもしれず、それを見つけ出す必要がある、ということです。そして、ええと、私たちは、それをデータベース内の何かと正確に一致させることはできませんが、何らかの類似、ええと、意味的に類似した、ええと、一致によって行います。つまりこれが理由であり、あるいはこれがそれを見つけ出す方法の問題です。
そして、ええと、これがオンラインのケースです。オンラインのケースについては、ええと、私は、言及された質問に答えます。ええと、この、ええと、このシナリオを満たすために必要な機能は何か、ということです。まずは、ええと、もちろんパフォーマンスです。そして、ええと、パフォーマンスは常に重要です。
どのような種類のデータベースであっても、そして、ええと、オンラインの、ええと、オンラインのものにとってもです。そして、たぶん、たぶん一部の人は、ええと、ラックは重要ではない、と思っているかもしれません。ラックにとってパフォーマンスは重要ではない、と。なぜなら、ええと、ログモデルは非常に遅いからです。しかし、そこには非常に多くの、ええと、テナントが存在することを考慮できます。つまり、非常に多くの異なる、非常に多くのユーザーが、ええと、ユーザー、ええと、ユーザーロジックモデルを使い、その後、ええと、彼らのデータベースに依存することができます。
ですから、私たちにも非常に高いスループットと非常に高いパフォーマンスが必要です。そして2つ目は、ええと、その、その、リアルタイム性についてで、私はそう呼びます。つまり、その、その、ええと、構築速度です。つまりインデックスの構築速度です。どれだけ速くそのデータベースに取り込み、ええと、提供し、そして、ええと、この種のデータを提供できるかです。
そしてそれはもう一つの重要なことです。つまり、パフォーマンス以外にも、いくつかの、いくつかの他の機能があります。たとえば、ええと、強力なスケーラビリティです。なぜなら、ええと、このオンラインサービスでは、常にピークと、ええと、バリュートラフィックがあるからです。そして私たちはこれを活用する必要があり、また、費用を節約するために、スキャンアウトとスキャンを、を、を、を行う必要があります。また、ええと、オンラインであるため、非常に重要なのは、決して何の、ええと、問題も起こしてはならないということです。
つまりフォールトトレランスです。そして、ええと、それには、ええと、バックアップや、ええと、ええと、障害、ええと、障害耐性など、こうしたすべてのことが含まれます。これは従来のデータベースと同じくらい非常に重要です。また、観測、ええと、観測可能性、たとえば、ええと、監視システムやトレーシングシステムがあります。そしてこれも、できるだけ早く問題を発見するのに役立ちます。
また、運用性、私は operability と呼んでいますが、それは、私たちが、問題を見つけ出し、そしてそれを修正するための良い設計、良いツールを持つということです。そしてそれが、オンラインのケースで最も重要な機能が必要な理由であり、必要な場所です。そしてオフラインのシナリオでは、たとえばデータマイニングがあります。つまり、ええと、機械学習の構築段階では、このモデルをファインチューニングするのに役立つ類似データを見つけようとしたり、あるいはモデルを、を、を、チューニングしたい、または大きなモデルをファインチューニングしたい、何であれそうしたことがあります。つまり、似たデータを見つける必要があります。この、ええと、データベースは常にその点で役立ちます。
それから、データクリーニングの作業もあります。気づいたのですが、ええと、一部の、ええと、大規模モデルのトレーニング、トレーニングプロセスでは、彼らは、彼らは大量のデータを必要とし、それを調整する必要があります。そして重複排除は、単一の単語や、ええと、文字単位の一致に基づくものではありません。これは、ある種の、ええと、意味的な、ええと、セマンティック重複排除に関するものです。ですから、ここでもベクトル検索を使う必要があります。
そして、ええと、最も重要な機能は、ええと、バッチ検索のパフォーマンスだと思います。つまり、ええと、オンラインとは少し違います。この場合、なぜ1つずつ検索するかというと、オフラインのケースだからです。私たちは常にスーパーバッチ検索を行います。また、ケーブル、ええと、機能のような他の特徴もあります。つまり、どれだけ、どれだけ、どれだけ、ええと、どれほど大きく、どれだけのデータを保存できるかということです。なぜならオフラインは常に大規模だからです。
そして、分析のためのリッチな検索セマンティクスもあります。たとえば、ええと、範囲検索フィールド、検索とそれによるグループ化、このような、ええと、従来の、ええと、OLAPデータベース、この種のリッチな検索セマンティクスも、ベクトルデータベースには必要です。では、ええと、それを少し整理しましょう。つまり、あなたが言っているのは、ええと、これらのオンラインの、ええと、ユースケースのいくつかについて、ええと、最初から見ていきましょう。RAGのようなものでは、ええと、LLMが非常に遅いのでパフォーマンスは重要ではない、という声が世の中にはたくさんあると思います。でもあなたは、いや、実際にはRAGのユースケースではパフォーマンスが重要だと言っているのですね。
そして、それは人々が考慮すべきことだということですね。ええと、それから、ええと、もし私の理解が正しければ、つまり、いくつかのユースケースでは、ええと、あなたが説明した異常検知のユースケースのように、ええと、つまり、私は、ええと、非常に正確な答えを得ることが本当に重要だと思います。そして、その結果にすべてのデータが、ええと、提示されることも重要です。なぜなら私たちはその外れ値を見つけようとしているからですよね？私たちは、その異常を引き起こしているものを見つけようとしているのです。そして、そして、皆さんに覚えておいてほしいのは、つまり、ここで私たちが行っていることの多くは、多くの場合、近似最近傍検索と呼ばれるものを行っているということです。しかし、その異常検知のユースケースでは、私たちは、私たちは、つまり、その実際のものが何であるかを見つけられるようにしたいのです。
そして、ええと、あなたのベクトルデータベースが、ええと、その外れ値の、ええと、問いに到達するためのこうしたすべての機能を持っているかを理解できるようにすることが本当に重要です。それから、あなたはまた、ええと、これらのオフラインの、ええと、ユースケースのいくつかにも言及したと思います。ええと、つまり、それは単にその最初の検索を行うことだけではなく、そのデータを取り込み、それから、ええと、そして、さらに多くのことをすること、つまり、それを使って、モデルをさらにトレーニングすることに関するものです。だから本当に多くの異なるユースケースがあります。そして、ええと、この短い時間の中で、データを検索するための非常に多くの異なる状況、非常に多くの異なる方法もあると聞いたと思います。
ええと、そしてデータベースのパフォーマンスに対して持つべき期待値にも、非常に多くの異なる種類があります。そういう理解で正しいですか？はい。そうですね、間違いなくそうです。実際、これは大まかな結論にすぎません。実際には、非常に多くの異なるエコーコーナーがあります。
このコーナーの話ではありませんが、ただ、ええと、それほどホットでも、それほど人気でもないものです。たとえば、いくつかの、ええと、私の知っているバイオ、ええと、バイオテクノロジーでも、ベクトル検索を使っています。彼らは、ええと、タンパク質予測のようなことをしていて、ええと、類似したタンパク質を見つけるために、ベクトル検索でマッチングしたいのです。なぜなら、タンパク質は常に何らかの文字に変換できるからです。ですから、生物学の観点からも、そうですね、この種のものは非常に興味深いです。はい、実際、私はちょうど、ええと、2日前に、まさにそういうことをしているユーザーに会いました。
それで、ええと、それで、ええと、何、彼は私に何と言ったんだっけ？彼はとても雄弁な、雄弁な言い方でそれを言いました。彼は、ええと、タンパク質が、ええと、アミノ酸の配列だと気づくと、そこで気づき始める、と言いました。つまり、これらのモデルは実際にタンパク質の文法を学習できるんだと。私はその視点からは考えたことすらありませんでした。それで、ええ、そうです。そしてその特定のケースでは、私たちは、まあ、非常に、ええと、関連性の高い、ええと、うーん、検索結果を得たいわけです。なぜなら彼らは最終的には、つまり、ええと、さまざまな種類のユースケースのために本当に最適なタンパク質を作ろうとしているからです。
そしてその一部は、たとえば、彼が私に話していたと思うのですが、ええと、うーん、プラスチックに油を使う代わりにこれらのタンパク質を使う、というようなことかもしれません。うーん、あるいはその一部は医薬品かもしれません。それは、ソフトウェアエンジニアリングとはまったく違う世界です。はい。素晴らしいです。
さて。では、ええと、ここで次に進みましょう。では、ええと、なぜベクトルデータベースが、ええと、スケーリングをどう扱うかが重要なのでしょうか？というのも、私たちは、ええと、つまり、スケールアップやスケールアウトができると思うのですが、なぜこれが重要で、そして、なぜこれについて考えるべきなのでしょうか？あるいは、なぜ、なぜ私たちの特定の、ええと、ユースケースに関して、これが重要であることを確認すべきなのでしょうか？わかりました。ではまず、ええと、ええと、答える前に、少しだけ基本的な、ええと、ええと、概念を紹介したいと思います。つまり、ええと、先ほど述べたスケールアウトまたはスケール、ええと、スケールアップについてです。私はそれを水平スケールまたは垂直スケールと呼びます。
そして、ええと、それから、ええと、ええと、なぜそれが重要なのかについてもです。そして間違いなく、私たちは、なぜなら、ええと、データはますます増えていて、先ほど述べたように、バイオ、ええと、生物学、ええと、バイオ、一部の、一部の、一部のバイオ、ええと、生物学企業が、ええと、より大きなモデルを使い、ベクトルデータベースを使い、そして他にも、おそらく他の、ええと、産業の世界でも、あなたは、ええと、あなたは、あなたはこれらの大規模ネットワークモデルを使います。そしてモデルに入ると、ええと、ベクトルは、常に、避けることができないものです。そして、ええと、ベクトルの話になると、私たちはさらに多くのベクトルを持つことになり、そして間違いなく、ええと、ベクトルデータベースはスケールする必要があり、そして、ええと、ええと、さまざまな種類の、ええと、スケール方法についてです。
つまり、ええと、水平スケールは、ええと、単純にホストを拡大し、ホストをどんどん大きくすることと同じくらい単純です。そして垂直は、このクラスターにより多くの、ええと、ホストを追加できることを意味します。そして、ええと、水平スケールは、ええと、ええと、水平スケールは、ええと、ええと、ええと、制限されており、無制限です。なぜなら、できるから、ああ、そう、ああ、たぶん、ええと、すみません、間違えました。つまり水平はより多くのホストを追加することで、垂直は、ええと、それを大きくすることです。そして水平は無制限です。なぜなら、ええと、ええと、望むだけ追加できるからです。
そして垂直は制限されています。なぜなら、ええと、ええと、単一のホストは決して非常に、非常に大きく成長することはできないからです、そうですよね？それは無制限に大きく成長することは決してできません。そして、ええと、多くのベクトルデータベースは。今、ええと、私たちのトピックは、どのようにして、その、あなたの、ええと、ベクトルデータベースを選ぶかについてなので、それについてもう少し言うと、ええと、多くのベクトルデータベース、そのほとんどは、ええと、ええと、通常、ええと、ええと、水平、ええと、サブサポート、ええと、垂直、ええと、スケールをサポートしています。なぜなら、それは実装するのがたいてい簡単な方法だからです。たとえば、ええと、ええと、そして他のデータベースでも、たとえば、ええと、ええと、そうですね、検索のようなものです。そしてそれらも通常、この、ええと、垂直スケールを、ええと、行うだけです。そして、ええと、ええと、これは物事をより簡単に意味のあるものにするのに役立ちます。
そして、あなたが、ええと、成長させるとき、スケールするとき、パフォーマンスは、ええと、その、その、そのパフォーマンスの改善は、どれだけスケールするかに対して線形になると思います。なぜなら、ええと、オーバーヘッドが少なくなるからです。そして問題は、それは、決して成長できない、ということです。そうですよね？つまり、それは決して成長できません。非常に大きくはなれませんが、常に、ええと、水平スケールをサポートできます。そして水平スケールについてです。つまり、ええと、つまり、つまり、垂直の場合、ええと、垂直の場合、問題は、最初の段階で、将来あなたの、ええと、データがどれくらい大きくなるか、あなたのda、あなたのDAデータベースがどれくらい大きくなるかを知ることができるということです。したがって、もし過小評価してしまうと、苦しむことになり、そして、ああ、とても混み合っていて、もうこれ以上スケールできない、と気づくことになります。
はい。はい。つまり、これは興味深いんです。というのも、これは、ええと、ご存じのように、何というか、私たちが考え出したもの、私ではなく、業界が考え出したもので、たとえば20年前、おそらくそれ以上前に、水平スケーリングという考え方として出てきたものだからです。それなのに、新しい種類のデータベースを導入するたびに、私たちは同じ罠にはまります。私たちはみな、垂直方向にスケールするデータベースから始め、時間が経つにつれて、ああ大変だ、実は、扱おうとしている項目数が本当に膨大で、今度はそれを水平方向にどう実現するかを考えなければならない、ということに気づくのです。
ですから、スケールの課題に対処するための新しい、ええと、新しい方法というわけではありません。ただ、Vector database に関しては、それを考慮する必要があるものだと思います。そして、プロトタイプを構築しているときには、たとえば10万個のベクトルがあって、まあ問題ないだろうと思うかもしれません。でも、1億個のベクトルに到達するのは本当に、本当に簡単です。そして、10億に到達するのも本当に簡単ですよね、Lee？はい。はい。
そして、そして、そして、この世界は変化していますよね？モデルは、ここ数年で非常に急速に成長していますし、おそらく、2023年の初めには、データは100万件か200万件だけだろう、と言っていたかもしれません。なぜなら、その時点では何も言っていなかったからです。しかしその後、非常に大量の、今では私たちのほとんどのユースケースは、百万単位ではなく十億単位で数えるものになっています。その通りです。その通りです。はい。
そして、もしこのセッションに参加している方の中で rag ソリューションを構築している人がいれば、テキストやPDFをチャンク化しているだけでも、それが本当に急速に増え始めるのをおそらく目にしていると思います。では、簡単な計算をしてみましょう。中規模の e-commerce サイトの例を考えてみます。販売されている商品が多数あり、各商品には簡単に、たとえば5枚の写真、1本の動画、多数のユーザーレビュー、商品説明が含まれ得ます。そうすると、販売している1つの商品だけで、さまざまな種類のベクトルが30個、50個できるというのは非常に想像しやすいですよね？そしてそれに e-commerce サイト内の商品数を掛けると、あっという間に1億、あるいは3億になりますよね？本当に、かなり多くの人が認識しているよりもずっと速く積み上がっていくのです。
わかりました。ええと、実は次の質問に行く前に、聴衆から良い質問があります。では、分散コンピューティングは水平スケーリングと垂直スケーリングの両方に適用できるのでしょうか？ええと、すみません、確認します。はい、はい、もちろんです。ですので、分散、ええと、コンピューティングに関して言えば、この説明は少し曖昧です。なぜなら、水平であれ、垂直であれ、そのどちらも分散されているからです。
ですから、答えはイエスだと思います。はい、はい、はい。ただ、Lee が述べたように、上にスケールしていくのであれば、最終的には天井にぶつかるということです。そして、それはユースケースによっては問題ないかもしれません。ですので、もう一度、現在どれくらいの、どれだけのベクトルがあると思うか、そして明日、あるいは1年後、2年後にどれくらいになると思うかを考えてください。
そして、もし垂直スケーリングで十分であれば、どの vector database が自分に適しているかを判断するためのチェックリストにそれを入れてください。もし、はるかに大きなスケールに到達すると思うのであれば、それを理解して早い段階で判断する方が、後になって、垂直スケーリングのソリューション内にあるこれら大量のベクトルを水平スケーリングのものに移行しようとするよりも良いです。では、次に進みましょう。わかりました。
それで、ええと、ほら、私たちは、思うに、ほら、世の中には、ええと、ベクトルデータベースの性能や、ある種のユニークな特徴を説明しようとして使われる用語がたくさんあります。そこで、説明していただけますか、つまり、関連性とは何を意味するのでしょうか？スケーラビリティとは何を意味し、そして、ええと、効率性とはベクトルデータベースの世界で何を意味するのでしょうか？うーん。はい。関連性については、たぶん私は、私は、私は思ったのですが、なぜなら、ええと、ベクトル検索は、ええと、厳密には検索ではないからです。つまり、ええと、ええと、得られない、得られないので、私たちはいつも top key、top key、類似、と言いますよね？でもおそらくそれは、ええと、つまり、厳密に top key ではないかもしれません。というのも、この種の、ええと、ええと、関連性やレコードと呼ばれる概念がある理由は、そこにあるからです。つまり、ええと、私たちは扱う、あるいは私たちは、これはトレードオフであり、性能を向上させるために、この種のものにおける正確性や関連性の一部を犠牲にしています。
そしてこれは、また、なぜなら、それは、ええと、も、ええと、ベクトルは、AI の背後にあるデータベースであり、そこにはモデルがあるので、モデルが非常にうまく機能するために、それほど厳密に、ええと、同じである必要はありません。はい、これは、ええと、関連性についてで、そして、ええと、スケーラビリティについては、先ほど述べたとおりです。そして、ええと、実際にはそれは言われていて、従来のデータベースと何の違いもありません。そして、ええと、それから従来のデータベースと、ええと、ええと、あなたは、アーキテクチャについて、水平スケールと、ええと、ワークスケールをスケールする必要があります。そして shard、この種の、ええと、replica、replica、この種の概念があります。基本的には同じで、しかし効率性。
つまり、ええと、それは、ええと、もしあなたが何らかの性能とコストを意味しているなら、ええと、それを意味していますか？はい、はい。わかりました。では、ええと、それはユースケースによります。そして、ええと、ええと、私たちはさまざまな種類の、ええと、つまり、その、その、ベクトルデータベースの内部で最も重い部分、最も重要な部分はインデックスに関するものです。どの種類のインデックスを選ぶか、インデックスは類似検索を行うのに役立ちます。
そして、ええと、そしてインデックスは、ええと、リソースの大部分を占有します。これは効率性に影響し、コードに影響し、そしてそれをディスクに置くことも、メモリに置くこともでき、画像を量子化することも、圧縮することもできます。そしてこれもまた、ケースによって異なる種類の効率性を持つことができます。あなたのユースケース次第だと思います。それは、それは素晴らしいですね。では、ええと、関連性についてもう少し掘り下げて、質問してみましょう。
では、ええと、ベクトルデータベースではどのような検索が利用可能なのでしょうか？というのも、あなたは、ほら、私たちは可能な限り近いものを見つけようとしている、と言いましたよね？Top K、そもそも top K とは何を意味するのでしょうか？ええと、top K とは、ええと、ええと、ベクトル検索において、類似度をどう評価するかについて、いくつか、いくつかのメトリクスがあるという意味です。L2、IP、IL2 があり、それは単に、ええと、d some L ip、そして、ええと、cosign この種の距離です。そして、ええと、ええと、もし、ええと、2 つのベクトルがこの距離において非常に近い、ええと、あるいは私たちは、私たちはこれを、ええと、ベクトル空間と呼びますが、そして、ええと、それは、それは、ええと、それは、私たちは、ええと、そこから最も近い top key を見つける、つまりこれが top key search と呼ぶものです。そして、ええと、どのような検索か？つまり top key は、ええと、ええと、その、その、私たちは in search または top key search と呼びます。これは非常に基本的なものです。
そして、ええと、実際にはそれは、ええと、それは、ええと、ベクトルデータベースというよりはベクトル検索に近いものです。そして多くの、多くのライブラリがこれを行えますよね？そして、ええと、FAISS のようなものやこの種のものでは、その上にデータベースを構築する必要はありません。そして、データベースになると、私は、ええと、私たちはより、ええと、私たちはより豊かな、ええと、検索セマンティクスに到達する必要があると思います。例えば、ええと、ええと、フィルタリング検索があります。フィルタリング検索とは、ええと、なぜなら、なぜならあなたは、あなたはできる、あなたは、ええと、ええと、あなたの、あなたのデータベースを、ええと、あなたのコレクションやあなたのデータベースを、ええと、ええと、MySQL テーブルとして扱うことができるからです。
そして、ええと、あの、列がベクトル列であり、このベクトル列に対してベクトル検索を行います。また、他の列を持つこともできます。つまり、それはスカラー列で、ストリームできたり、インデックス化できたりします。たとえば、画像があり、その説明があり、ラベルがあり、ええと、あの、その、その、その日付、取得された、撮影された、ええと、あの、そこにあります。したがって、これらすべての、ええと、データは、ええと、ベクトル検索のフィルターとして使用できます。たとえば、最も近い top K、ええと、あの、画像に最も近い top K を見つけたいが、ええと、何も関与させたくない、ええと、含めたくない、たとえば red hat を含めたくない場合です。これはフィルター検索と呼ばれます。
そしてそれは、ええと、非常に重要で、私は、ええと、ベクトル検索の中で非常に重要な、ええと、検索セマンティックだと思います。また、範囲検索も、ええと、別のものです。範囲検索とは、top K の関連性ではなく、ある、ええと、あの、いくつかの、その、そのベクトルを、ええと、距離範囲内で持ちたいということです。述べたように、距離、ええと、指標として L2、ええと、あの、そして IP があります。そして、ええと、いくつかの、いくつかの場合、たとえば、似たものを見つけたいのですが、どれくらい似ている、ええと、ものが欲しいのかわからない、どれくらい見つけたいのかわからない、という場合です。また、ここにどれくらい似たデータがあるのかも気になります。
だから、たぶん範囲だけを持つことになります。そこで、距離が 2 以内だと言うと、私は、ええと、その定義は、ええと、2 以内であれば非常に似ていて、それ以外はすべて取得しない、というものだと思います。これが範囲検索です。それから、ええと、group by 検索についてです。group by 検索とは、ええと、従来のデータベースと同じように、いくつかの、いくつかの、いくつかのデータを group by して、ええと、それを取得することを意味します。
たとえば、もしあなたが、Snoopy の、ええと、Snoopy の画像に対して類似検索を行うなら、ええと、top、ええと、あなたは、あなたは、あなたは、取得したいものとして、2 つの異なる、3 つの異なる top 3 の異なる種類の、ええと、犬を得たいかもしれません。つまり、ええと、あの、coffee を得て、他の犬を得て、Snoopy を得たいと思うわけです。しかし実際に起こるのは、まったく同じ Snoopy を 2 つ作ってしまうことです。なぜなら、そこに非常に多くの Snoopy があるからです。ですからこの場合、何かで group by したいと言いたくなります。そこで名前で group by します。
つまり、それが、それが、それが Snoopy なら、1 つだけください、ということです。そして、ええと、そうすると、最終的に、まだ coffee と他の犬も取得できます。これは、ええと、単なる例です。ですから、それを group by 検索と呼びます。そして、ええと、また、いくつかの、いくつかの、いくつかの、いくつかのベクトルで group by することもできます。
つまり、スカラーデータ上だけで group by するのではなく、私はストリームと言いますが、ベクトル上で group by することもできます。つまり、もし、ええと、距離が非常に近ければ、それを同じものとして扱うことができるということです。ですから、ええと、それは別のものです。つまり、私はそれを仮想化された、ええと、あの、その、その、その、その、その、いくつかのセマンティック検索、いくつかの、ええと、従来のデータベースやその他の、ええと、あの、文献からの検索セマンティックと呼ぶでしょう。したがって、いくつかのケースでは、ええと、Google と同じように、いくつかの似たものを検索しようとして、次のページ、次のページ、次のページを試すわけです。基本的にはそうします。そしてベクトル検索でも、ええと、top K、top、ええと、top 10、top 10、top ten two、top 30、ええと、20、top 32、top 30、このようなものを持ちたいのです。ですから検索と呼びますし、また spas spa は別のトピックです。
それで、ええと、ベクトル検索は、ええと、あの、セマンティック検索に関するものであり、ええと、つまり、その、そのモデルが抽象データからセマンティックな、ええと、情報を抽出し、それを、ええと、あの、密ベクトル、dense vector にします。ですから、ええと、そして sparse とは、ええと、あの、BM 25、TFIF、この種の、ええと、あの、従来の統計、静的な、ええと、基づく、基づく、ええと、うーん、いいえ、それはモデルではありません。いくつかの、いくつかのアルゴリズムに関するものです。そして、ええと、非常に疎なベクトルを得ます。そしてこれは、うーん、キーワードに関するより多くの情報を持っています。
これは統計に関するものです。そしてそれは、実際には、セマンティックなものについての dense なものを補完するものです。一方はコンテキスト、セマンティックに焦点を当てていて、もう一方はキーワードに、ええ、焦点を当てています。そしてそれらを組み合わせることができます。つまり最終的には、えー、この種の D の 2 つ、2 つの異なる検索をどうハイブリッドにするか、という話です。
そして、えー、複数のベクトルがあります。一つは sparse、一つは dense で、それらをどのように結合するか、えー、どのように組み合わせて検索をより良くするかです。なので、Vector database の中でサポートすべき重要なことでもあります。はい。そして、ええと、その最後の点、検索結果をより良くすることは、ええと、何を検索しようとしているのか、そしてデータベースに何が入っているのかに依存しますよね？ それは、その、その、えー、質問に対して、検索のやり方は一つです、と答えられるようなものではありません。
というのも、検索を行う可能性のあるさまざまな方法をたくさん挙げていましたから。あなたは、ええと、まず filter し、えー、その、えー、metadata の scaler data によって filter out できると言っていました。つまり基本的には、検索対象となる、えー、対象を制限しようとしているわけです。それが、あなたが最初に挙げたものです。ええと、それから、私が思うに非常に基本的なこと、つまり似たものを見つけようとしているということも話していました。
ええと、だからこそ top K results を取得しているのです。上位 5 つの類似アイテムを見つけようとしているわけです。ええと、そして時には、ええと、データの中で、ええと、その結果が期待していたものにならないことがあります。上位 5 つを見つけたい、ということを行うときです。だからこそ、ええと、range search と呼ぶものを行う能力も考慮する必要があります。そこでは基本的に、そのデータの周りに範囲のようなものを設定できます。
つまり、この、この領域内で結果を見つけたい、ということです。そして top K がその領域の外にあるかもしれないし、あるいはすべてその領域の内側にあるかもしれません。ええと、あなたは group buy についても言及していて、Snoopy を探す、あるいは Goofy や Snoopy のような犬を探す、という例は面白いと思いました。ええと、その検索をしているとき、実際に何を見つけようとしているのでしょうか？ Snoopy だけを見つけようとしているのか、それとも犬を見つけようとしているだけなのか、あるいは Snoopy に似た犬を見つけようとしているのか？ 問われうる質問はたくさんあります。もう一つ、あなたが Groupa でほのめかしていたと思うことは、ええと、rag solution のようなものを考えるとき、データの chunk に対して semantic similarity search を行いますが、では、実際に何を表面化させようとしているのか、ということです。chunks だけを表面化させようとしているのか、それとも実際の PDF、あるいは、ええと、元のデータコーパスで group by したいのか。つまり、たとえば、よし、類似した docs をすべて見たい、そして chunks に基づいて検索している、というようにです。
なので、それで group by したいかもしれません。ええと、はい、それらは似ています、従来のデバイスに似ている、みたいなものです。おそらくその後に aggregator をまだ持つことができます。つまり、PDF という考え方で group by して、それから各 paragraph の scores を、えー、aggregate したいわけです。それらを単に足し合わせるか、あるいは最大のものを見つけて、それに対して top K を行うのです。
はい、それは本当に素晴らしいポイントです。というのも、私が最初に group という言葉を聞いたとき、最初に思い浮かんだのは aggregators だったからです。なので、えー、はい。なので、えー、その aggregation を追加する可能性もあります。ええと、それから、えー、他に何を追加しましたか？ それから、ああ、そうですね、それから、あなたは、えー、つまり hybrid search について言及しましたが、業界では、すべての vector databases を見てみると、誰もがそれぞれ独自の定義を持っています。
では、「ハイブリッド検索」とは何を意味するのかを見極めることが重要です。で、ええと、ハイブリッド検索、どうぞ。ああ、はい、ちょっと割り込むだけです。ええと、すみません。で、ハイブリッド検索は、実際には、ええと、今のところ、定義のほとんどは、非常に典型的なレコメンデーションシステムでは、ええと、何らかの検索とベクトル検索を使う、というものです。その検索は、ええと、何らかの従来型の、ええと、統計、統計ベースの検索で、それからベクトル検索を行い、それぞれから top K を呼び出して、それらの結果を一緒に結合します。
リランキングモデルがあります。こうしたものを使って取り出します。私たちはこれをリハイブリッド検索と呼んでいます。そして私たちの、データ側では、つまり、ve、ええと、その、ハイブリッド検索を、ええと、もし2種類、2つ、2つのベクトル、2列のベクトルの結果を組み合わせたい場合に、その結果を組み合わせたい。そういうものをハイブリッド検索と呼んでいます。それは、ええと、スパースベクトルとデンスベクトルのどちらでもあり得ますし、また、デンスベクトルとデンスベクトルでもあり得ます。
例えば、あなたは、動画を持っていて、そして、あなたは、あなたは、あなたは、あなたはエンコードして、あなたは作り出して、ええと、映画、その、その、グラフ、あるいはその、その、その、その視覚データから埋め込みを取得します。そして、音声データから、ええと、列ベクトルを取得し、それから検索結果を組み合わせて検索し、自分が欲しいもの、欲しい動画を得ようとできます、その例です。はい、それは本当に素晴らしい例です。ええ。なので残念ながら、皆さんが、ええと、ベクトルデータベースを探しているとき、ええと、機能名を額面どおりに受け取ることはできません。
ご覧のとおり、ハイブリッド検索の下には、実はさまざまなものがあります。ですから、探す際、こうしたベクトルデータベースを選ぼうとしているときは、ええと、本当に掘り下げて、「ハイブリッド検索」とは何を意味するのかを理解してください。それは単なるメタデータフィルタリングなのか？それとも、つまり、ええと、デンスベクトルと、ええと、スパースベクトルなのか？ええと、つまり、実際には、彼らは実際には何について話しているのか？そして、ええと、実際に自分が必要としている機能要件に基づいて選択してください。ええと、これは業界では残念なことですが、重要です。私たちは、それを強調しておきたいと思います。ええと、この質問の冒頭であなたが言ったもう一つのことは、ええと、つまり、ええと、近似最近傍探索に関しては、単に、ええと、face のようなベクトル、ええと、インデックスを使えばよい、ということでした。これはデータベースではありません。
では、インデックスとベクトルデータベースの違いをどのように説明しますか？わかりました。はい、これは非常に、非常に古典的な質問です。ええと、phase は、ええと、ライブラリの集合であり、ええと、ええと、それを超えると、その、その、その、つまり phase と、ええと、例えば VUS との関係は、ちょうど、my を inband できるようなものです。つまり、3つ以上である必要があり、my は、つまりそれ以上のものを持っています。ですから、前述のとおり、スケーラビリティ、どのように、そしてデータ、永続性、フォールトトレランス、監視、そして、ええと、はい、こうしたものすべてがあります。なぜなら、ライブラリ、ライブラリは、単に、ええと、それに取り組むもので、ただのアルゴリズムであり、アルゴリズムとデータベースを比較するものだからです。ですから、私たち、私たち、その間には大きなギャップがあります。
その例えはとても良いですね。そして、つまり MySQL、それは完璧な、ええと、説明の仕方です。つまり、face や HNSW のような、ええと、ライブラリインデックスと、ベクトルデータベースの違いを説明する方法として。つまり、そして、あなたは、ライブラリで十分な場合もあると思いますか？ええと、そう思います。もし、単に、つまり活用して、何らかの実験をしていて、そして小規模な、ええと、少量のデータ、例えば100万未満を扱っているなら、ええと、遠慮なくライブラリだけで作業してください。なぜなら必要ないですし、そして、あなたは、あなたも、あなたは本番環境で提供しているわけではないからです。この種のフォールトトレランスや、この種の監視システム、あるいはセキュリティシステムを持つ必要はありません。はい。
それで、ええと、あー、次の質問は、ええと、あー、類似性メトリックと、あー、それから、あー、インデックスの違いは何ですか？つまり、どのように、説明しますか、というのも、あなたは、あー、ユークリッド L2 について話しましたし、内積について話しましたし、コサインについて話しましたよね？それらは類似性メトリックでしたが、一方で HNSW や、あー、face などのライブラリやインデックスがあります。では、その 2 つの違いは何ですか？これらの言葉は全部、なんというか、かなり混乱しますよね？あー、あー、距離は、あー、その、メトリックは、あー、単に、どれだけ近いかを決めるものです。そして、あー、あー、あー、たとえば、あー、あー、つまり、その、その、その、その 2 つ、2 つのベクトルがあります。ip を使うことができ、それはつまり、各、あー、次元ごとに掛け合わせて、それをまとめて距離とする、ということです。または、あー、L2、ユークリッドを使うこともできます。そして、あー、インデックスについては、あー、別の種類の方法で、これはこの種のものを形成するためのデータ構造で、この種のベクトルを形成し、そして、あー、それをできるだけ速く検索できるようにするものです。
そして、この、この検索、トップ K 検索はメトリックに基づいています。たとえば、IPO を使うと、検索される結果は、あー、IP の観点で類似したものになります。L2 を使うと、それは近い、あー、トップ K で、あー、トップ K の観点の下でのものになります。なので、ええ、それは、あー、2 つの異なる種類のものです。いいですね。
ええと、素晴らしいです。それから、そして、実際に、あー、ええと、インデックス構築や、ええと、クエリの構築を見ていくと、実際には、これらの多くが要件になっていることがわかります。あー、ですので、存在するさまざまな、あー、ベクトルデータベースの使い方を学ぶにつれて、これがもっと理解しやすくなるといいですね。わかりました。進みましょう。
はい。ええと、わかりました。みんな、「ああ、すごい、私たちは Hand SW をサポートしているだけです」と話しますし、今では、あー、ええと、ベクトルデータベースの世界にいる人なら誰でもその略語を知っていますが、ほかにも非常に多くのインデックスがあります。Hand SW で十分なのでしょうか？人々は、ほかのものについて知っておくべきでしょうか？それらは重要ですか？あー、私は HSW が、あー、有名なのは、あー、入手しやすく、また理解しやすいからだと思います。そして、それは、あー、データ構造、またはこの種の、あー、概念が、あー、とても、ひとつの解決策だからです。しかし、あー、それは HSW 自体が最高だという意味ではありません。つまり、最もよく知られているものですが、最高のものではありません。
ですので、純粋なアルゴリズムの観点から見ると、HS W は、あー、mutable です。つまり、そこにデータを追加でき、そこからデータを削除でき、そして検索もうまくできます。そして、いくつか、または、ほかのいくつかの immutable な、あー、グラフ、たとえば、あー、あー、たとえば、あー、そして、ああ、ちょうどその前に、知らない人のために説明すると、HWHW は、あー、グラフ、あー、データ構造です。つまり各ベクトルは、グラフ内の、あー、点またはベクトル、あー、頂点になります。そして、この、あー、頂点、この、あー、ベクトルをエッジでつなぎ、複数のレイヤーを持ち、このグラフ上で、あー、反復的に検索して、近いものをこの方法で得ることができます。そして disco の Ana や NSG のようなほかのグラフや、この種のものは immutable です。そして、あー、またそれらはより良い性能を持っています。そして、あー、またいくつかのizer は HSW やほかのグラフ、またはほかのアルゴリズムに適用できます。
そしてまた、あー、GPU ベースに変える場合、hs, w は、あー、うまくいかないかもしれません。なぜなら、あー、GPU、GPU はまったく別のものだからです。そして、nvidia からのこの種の car があります。あー、今は vu をサポートしています。これは、あー、GPU には非常に適しています。また、Asian sub は、あー、bk には、良くありません。
つまり、グラフベースのアルゴリズムは実際には bk にはあまり良くありません。ですので、K が数千程度、または、あー、10,000 以上である場合、グラフは決して、あー、あなたのニーズを決して満たすことはできません。また、バッチ検索を行う場合も、グラフはあまり良い選択ではありません。ですので、それは一般的な選択肢です。つまり人々は常にその BK を持っているわけではなく、それほど大きなバッチを持っているわけでもなく、そしてそれほど超高性能を必要としているわけでもありません。
そして、ええと、彼らはGPUの周りには置かないでしょう。ええと、私は、Asian subは良い、良い出発点だと思いますし、またいくつかの豊かなセマンティックな、ええと、特徴から見ても、Asian subには、ええと、純粋なAsian subや、フィルタリングやスパースのような問題もあります。それに対する具体的なサポートがいくつかあります。そしてユースケースの観点から言うと、私は、私は、私は、私は、ええと、CAPベクトル検索と呼ぶ概念を持っています。それはディストリビューターの話ではなく、ベクトル検索の領域における話です。
つまり、それは容量、精度、性能です。つまり、決してすべてをサポートできない三角形です。ええと、それらすべてを満たすことは決してできません。つまり2つだけが、ええと、そのうち2つだけが満たされ得ます。そしてAzure subは典型的には精度と高性能の面です。
そして、ええと、ええと、別の2つの組み合わせにも、ええと、他の2つのケース向けのユースケースがいくつかあります。たとえば、非常に大きな容量、非常に大きなストレージ容量、そして非常に正確なものが欲しい場合です。その場合は、このようなディスクベースの、ええと、インデックスを選ぶかもしれません。そして、ええと、また性能と容量が欲しくて、精度を気にしない場合、それも起こり得ます。なぜなら人々、いくつかの、いくつかのユースケースでは、人々はBKand検索を行い、結果を得て、それを機械モデルに投げて、細かい、ええと、再ランキングを行うことができるからです。
そしてこの、この場合、彼らは、彼らは必要として、彼らは、彼らは精度を気にしません。なので、ええと、I-V-F-S-Q-P-Qのような、この種のソリューションは大きな、素晴らしいものになり得ます。それは、本当に素晴らしいポイントです。なので皆さんにもう一度強調したいです。つまり、ええと、ご存じのように、データベースの場合と同じように、こうしたトレードオフがあります。
つまり、有名なCAP定理、ええと、そこで、つまり、すべてを手に入れることはできません。ええと、つまり、もし、もしあなたのユースケースが性能や可用性を必要とするなら、あるいは、ええと、pは何でしたっけ、パーティション、ええと、つまり、あなたは、あなたは何らかの選択をしなければならないわけです、そうですよね？そして、それは、そしてそれは、もし自分のユースケースが何かを考えれば、それらの選択をするのは本当に簡単です。そして、ええと、ベクトル検索にも似たような三つ組があります。そして、ええと、いったんある程度把握すれば、つまり、何が、何が最も重要なのか？それは、ええと、それは精度なのか？リコールなのか、それは、ええと、性能なのか？それは、ええと、Leeがちょうど言及したように、そのメタデータで検索できることなのか、それらが何であるかを理解し、そして、ええと、そしてデータベースを選ぶだけでなく、そのうえで、ええと、あなたの特定のユースケースの、ええと、要件に一致できるその、そのインデックスを選ぶことです。そして、ええと、HNSWは、は、素晴らしいインデックスですが、ただ、それがあなたが達成しようとしていることに合っていることを確認してください。
はい。素晴らしいです。わかりました。ええと、つまりVector databaseはデータベースですよね？では、取り込み側についてはどうでしょう？つまり、そこで何をしなければならないのでしょうか？Vector databaseにはどのような前処理が必要ですか？わかりました、これについては2つの統合があります。まずは、ええと、人々がいつも尋ねる、ベクトルはどこから来るのか？ベクトルはどこから来るのか？ということについてです。そして、ええと、ええと、通常はモデルがあり、あなたは自分の写真を入れ、自分の、ええと、ドキュメントをモデルに入れます。
それはbirdかもしれませんし、open eyeかもしれませんし、何であれ、大規模モデル企業のものです。そして、ええと、これを得ます、ええと、あなたは得る、あなたはこれを得る、ええと、ベクトルが出力され、そして、ええと、vector Davisに入力されます。そしてそれはとても長い、とても、とても、とても退屈な、非常に長い道のりのように見えます。そうです、しかし私たちは、しかし幸運なことに、助けてくれるいくつかの、いくつかの、いくつかのツールがあります。たとえば、long chainやLA Indexで、それらはそれで有名です。つまり、それらは大規模学習モデル、very database、ええと、database、ええと、そしてベクトル抽出、こうした種類のものすべてを組み合わせることができます。
そしてまた、いくつかのベクトル、私たちのデータベースはすでに、ええと、それらは、それらは、それらはデータベース内にいくつかの大規模モデルを含んでいます。つまり、単に、いくつかの、ええと、いくつかのモデルをデータベース内に持っているというようなものではありません。なので、それらは、ええと、非構造化yin instructorを行うことができ、そして、そして、ええと、そうでないものもあります。なので場合によります。つまりこれは最初の、最初の解釈、ええと、in, in, in, in depressionについてです。つまり、ええと、興味深い前処理をどう行うかについてです。
もう一つは、ええと、ある純粋な v、ええと、vector、ええと、ええと、ストリーミングで入ってくるものに関する情報です。そして、ええと、これをどうサポートするかというと、ええと、この mouse は、ええと、ええと、ええと、つまり vector が取得されて、それを検索します。そして、ええと、実際にはデータの鮮度とデータ効率を同時に満たすのはかなり難しいです。つまり、データを取り込む場合、ええと、非常に高い可視性を持たせてすぐに検索したいわけですが、それはデータベースの種類によって異なります。あるデータベースは Asian sub を直接使うので、ええと、ええと、データが入ってくると、その点を a、to、to、to the Asian sub graph に追加しようとします。それには時間がかかり、ええと、つまり今ストリームで入れたものを、ええと、すぐには検索できず、少し時間がかかるということです。
そして、ええと、これを私は、データ効率を実現するために鮮度を犠牲にする、ええと、犠牲にすると呼んでいます。そして mill の内部での私たちの設計では、ええと、2 つの lasers があります。私たちは、ええと、私たち、私たちはそれを取り込み、データの鮮度を提供するために非常に、非常に高速な構築インデックスを持ちます。そしてその後、ええと、ええと、バックグラウンドで、私たちは、私たちは、いくつかの graph based、または他の、ええと、board、ええと、インデックスを構築して、データ効率を提供するのを助けます。はい、それは、ええと、良いです。
それがどこにあるのかよくわかりません。いいえ、完璧でした。はい。ですので、あなたが述べたように、ええと、つまり、人々が vector databases について学ぶと、次の最初の質問は、ああ、つまり、どこで、どうやってそれらの embedding を手に入れるのか、ということになります。ですので、ええと、独自の models を使ってそれらの、ええと、embeddings を生成し、それから vector database に挿入することもできます。いくつかの vector databases には、実際にそれらの vector embeddings を作成する仕組みがあります。ですので、それを探してください。
vector database を選ぶときには。Lang Chain や LAMA Index、ええと、semantic Kernel などの他のツールも使えます。それらは実際に、ええと、large language model と非常に強いつながりを持っています。ですので、Vector database に保存する前に、それらと Bennys を生成するのにも役立ちます。ですので、すべては、つまり、あなたのユースケースが何か、そしてあなたの、ええと、スタックが何かによります。ええと、しかし、あなたが、つまり、vector database を選ぶときに、ええと、考えるべきことです。
わかりました、本当に素晴らしいです。では、セキュリティについてはどうでしょうか？なぜなら、つまり、これらの vectors は私には何にも見えません。私はそれらを解読できるかどうかすらわかりません。では、なぜセキュリティを心配しなければならないのでしょうか、あるいは、心配しなくてよいのかもしれません。ええと、私は、私は、常に、このセキュリティは常に重要だと思います。
ああ、常に重要です。そしてあなたがどんな種類のデータベースであっても、そして、ええと、vector なので、これはあなたにとって理解しにくいかもしれませんが、大規模な chain language model にとっては理解しやすい、簡単に理解できるかもしれません。ええと、将来的には、それに何らかの context を与えることで理解できる魔法の interpreter があるかもしれません。しかし、このようなすべての場合において、データベース内部にもセキュリティの、ええと、保証を持つことが非常に重要です。そしてもう一つの点は、vector data を超えて、私たちにはいくつかの、ええと、structured data もあります。ええと、それは string で、いつでも metadata と言及されるものです。
そして私たちはそれの sec、ええと、保つ、保つ、セキュリティを保つ必要もあります。ですので、ええと、では features、どのような secure features かというと、まず、データベースは、ええと、通過する必要があり、ええと、SOC two from SOC two、ええと、IO and GDPR などのようなセキュリティ認証を取得する必要があります。そして、ええと、もう一つはデータセキュリティについてです。データセキュリティとは、ええと、データ分離、アクセス制御、ロールベースのアクセス制御、この company、そして、ええと、ユーザー認証、認可、さらにサイバーセキュリティをどのように行うか、そして、いくつかの、ええと、IP アドレス制御、ええと、アクセス制御、private link into、ええと、転送中の暗号化、このようなすべてのことです。ですので、これ、そしてこれらは、ええと、私が表現したいもう一つのことです。ええと、face のような library と、ええと、この質問を思い出すだけの違いです。
ですから、セキュリティは間違いなくその一つです。ええ、その通りです。ですから、私が、ベクトルデータベースを選ぶときに、それが本当に重要なのか、などと言ったのは、少し皮肉を込めていたんです。ええと、そしてそれを本番環境に投入するつもりなら、社内のセキュリティチームと話をしなければならなくなります。そして、ええと、彼らはいまだに多くの場合、ベクトル埋め込みが何なのかを知りません。ですから、ベクトル埋め込みとは何かを説明しなければなりません。ええと、彼らの自然な最初の反応は、「ああ、それなら間違いなく誰かがそのベクトル埋め込みが何であるかをリバースエンジニアリングできるはずだ」となるでしょう。
そして、そこに会社の機密情報のようなものが少しでも含まれていれば、彼らは本当に、本当に懸念するでしょう。ええと、ですから、これは簡単にできることではありませんが、そのようなリバースエンジニアリングができると主張する論文はいくつか存在します。ですから、ベクトル埋め込みに関しては、セキュリティは実際に非常に重要であり、セキュリティチームは間違いなくそのことを知らせてくれるでしょう。そして、Lee が述べたように、従来のセキュリティに関する質問もすべて、いずれにせよセキュリティチームから出てくることになります。ですから、こうしたベクトルデータベースを検討するときには、それをリストに入れておく必要があります。
ベクトルデータベースを選ぶ際には、それは非常に重要になります。ええと、では、残り時間が数分ありますので、視聴者からの質問にいくつか移りたいと思います。では、Jaylynn からの質問です。現在利用可能なベクトルデータベースの例をいくつか共有していただけますか？ええと、そうですね、オープンソースのものとしては、Milvus が最も有名なものに違いありません。それから、Qdrant と Weaviate、そして、ええと、はい、いくつか、これは私が最初に思い浮かぶものですが、また軽量なものとして、Chroma や Lance、そして一部のクローズドソースのものとして、Pinecone のようなものもあります。もちろん、マネージドのプロフェッショナルなものに基づいたものもあります。そしてまた、ええと、ご存じのように、世の中にあるすべてのデータベース、NoSQL であれ SQL ベースのデータベースであれ、ベクトルインデックスを採用していないデータベースは存在しないのではないかと思います。
ええと、ですから、皆さんが理解することは本当に重要です。つまり、誰が、何がベクトルデータベースなのかということです。私たちのベクトルデータベースの定義は、最初からベクトル用に目的特化して構築されているもの、というものです。それは、今日お話しした多くの機能をサポートしています。つまり、1つまたは複数のベクトルインデックスをサポートするだけでなく、類似度メトリクスもサポートしています。また、ベクトルのライフサイクルを特定の方法で扱います。そしてまた、理解しておくことが重要なのは、類似したベクトルを見つけようとすることは計算負荷が高いということです。
ですから、ベクトルデータベースは通常、その部分で非常に高いパフォーマンスを発揮しようとすることに重点を置きます。一方で、従来のデータベースの一部は、ええと、別の目的のために構築されたものですよね。ですから、あなたの状況では機能するかもしれませんが、ただ、よく理解したうえで取り組み、ユースケースを明確に説明するようにしてください。はい。ええと、Ali からの質問です。現時点で RAG と最も相性がよい LLM はどれだと思いますか、Lee？ええと、これは答えるのが難しい、難しい質問です。というのも、モデルは常に更新され続けているからです。たとえば最近では Claude 3 がベンチマークで素晴らしい成果を出したことを知っていますし、GPT-4 は常に良い選択肢です。また、Llama はオープンソースで広く採用されています。
あまり具体的な意見はないと思います。ええ、Ali、その点はすみません。ええと、ただ覚えておいてほしいのは、世の中にはたくさんのLLMがあるということです。ええ、もちろん今最も有名なのは、ええと、あの、open aiのGPT-4で、ええと、あなたがインターフェースするための本当にシンプルなAPIがありますが、コストがかかります。なので、ええと、何かを構築していて、それが本番環境ではないなら、ええと、hugging faceに行って、そこのリーダーボードを見て、他にどんなLLMがあるか確認するとよいかもしれません。
実際にあなたのノートPC上で動くLLMもいくつかあるので、ちょっとプロトタイプを作るために、それらをダウンロードすることを検討してもよいかもしれませんし、十分かもしれないオープンソースのLLMもたくさんあります。繰り返しになりますが、自分のユースケースが何かを考えて、ええと、あの、どのモデルで十分かを見てください。ええと、だから、市場のリーダーをただ選ぶだけにはしないでください。そして残念ながら、Leeが言ったように、これらのモデルは常に変化しています。ええ、だからこれは競争ですよね？はい。
毎日のように、あの、誰か新しいものが出てきているように見えます。たしか、ええと、philanthropicは今haikuサポートを持っているような、あの、ええと、そして数週間前には、voyage AIがコードに関して本当に優れていると話していましたよね？なぜなら、コードも非常に特定的だからです。なので残念ながら、私たち全員にとって、それは、ええと、まるで何百万もの、まるで人々が絶えず私たちの横を走り抜けているように感じます。だから追いつくのは難しいです。ついていくのは難しいです。
Okay。ええと、ESHが質問しています。コレクションとは、1つ以上のインデックスを持つ可能性のあるベクトルのセットですか？同じデータセットを、異なるユースケース向けに異なるインデックスでインデックス化できますか？ええと、それは異なるデータベースによりますよね？vusでは、ええと、コレクションはVUSにおける概念で、ええと、ベクトルだけのセットではなく、前述のようにテーブルであり、MySQLのテーブルとして扱うことができます。そして1つのカラムが、ええと、最新の、ええと、ええと、ベクトル、ええと、S 2. 4からのベクトルです。なので複数のベクトルカラムを持つことができ、ええと、ハイパートランスミッションだけを行います。
それは、そして、ええと、そして、ええと、同じセルをインデックス化できます。ええと、できます、ええと、1つのベクトルカラムを、ええと、ええと、特定の、ええと、ええと、アルゴリズム、ええと、ええと、アルゴリズムテストでインデックス化できます。はい。なので、その観点からは、選ぶデータベースによります。Big niche、でも私たちが考えてもいなかった別の良い点を挙げてくれました。はい、collectionという言葉でさえ、ベクトルBAデータベースにとってvectordaysとは非常に異なります。
なので、ええと、それが何であるか、それが、ええと、特に何を意味するのかを理解するには、そこを少し掘り下げる必要があります。そして、ええと、思うに、あの、ええと、あなたは自分自身にも問いかける必要があります。あの、あなたのアプリケーションに対するマルチテナンシーの、ええと、要件は何か、なぜなら、これらのcollectionやpartition keys、またはこれらの、ええと、これらの、ええと、もののいくつかを使って、それを支援できるからです。したがって残念ながら、そこを掘り下げる必要があります。なぜなら誰もこれらの用語を一貫して使っていないからです。はい。ええと、Okay。
では、Armandoが持っていた、ええと、ある、ある、コメント質問に戻りたいと思います。彼は、2つのdense embeddingでハイブリッド検索ができますか、と知りたがっていました。答えは、ええと、はい、これも異なる種類の、ええと、ベクトル、ええと、vector baseによります。VIS 2. 4からは、それをサポートしているので、リリースを期待できます。はい、ユーザーの方々から、それを可能にするための本当に、本当に大掛かりな回避策を見たことがあると思います。なぜなら、それは間違いなく彼らが望んでいるものだからです。
ええと、visの次のリリースでは、たとえば、単一の行、単一のエンティティ内で、ええと、保存できる複数のベクトルを持てるようにしており、ええと、そのため、それに対して検索を行えます。私たちはただ、物事を、ええと、ずっと簡単にしようとしているだけです。ええと、でもこれを実装する前でさえ、私たちが見たのは、人々が、ええと、それを自分たちで構築しようとしていたことです。つまり、あの、こうしたクレイジーな種類のクエリを行っていて、それは可能です。あなたは、それをいくつかのcollectionに持つことができます。
ええ、2つくらい持つことはできます。なので、同じくらい非効率です。ですから、まあ、話を戻すと、私たちはパフォーマンスが依然として重要であることを確認しようとしているので、最高のパフォーマンスを得られるようにしましょう。ええ、わかりました、それはやりました。ええと、Abe、あなたは先ほど本当に良いコメントをしてくれましたし、それを皆さんと共有したいと思います。
今日のトークの後の私たちの今日の目標は、これをたくさんのビジュアルを含む論文にすることです。ですので、より視覚的に学ぶタイプの方々には、ええと、まあ、この情報をそうした手段で、ええと、理解できる方法を用意します。それから、Leeに答えてほしい他の質問があれば、ええと、私たちに送ってください。ええと、メモを、ええと、Leeは、明らかにベクトルデータベースに情熱を持っていますが、彼のバックグラウンドもあって、データベース全般にも非常に情熱を持っています。おそらく、ええと、Carnegie Mellonで過ごした時間から来ているのでしょう。
ええと、彼の話は、ええと、Carnegie Mellonの、ええと、ポッドキャストでも聞くことができます。たしかそれはちょうど5、6か月前くらいだったと思います。ええと、そこではデータベース側についてもかなり深く掘り下げています。ええと、最後に質問があるか見てみます。来ました。
ええと、visに非常に大きなコレクションがあります。サブ構造検索またはスーパー構造検索のどちらかを実行する予定です。検索を実行するたびにインデックスを削除すべきですか、それとも2つのコレクションを構築すべきですか？ええと、サブ構造検索とスーパー構造検索というのはどういう意味かお聞きしてもいいですか？ええと、なので、サブ構造検索とスーパー構造検索、その背後にある意味については少しよくわかりません。はい。ですので、もう少し詳細を教えていただければ、ええと、もう少し掘り下げることができます。ええと、でもできればそうしなくて済むといいですね。
ええと、あなたが尋ねているようなことをする必要はありません。インデックスを削除したりそのようなことは、私たちにはちょっと激しすぎるように聞こえます。ええと、でもこうしましょう、ええと、メールを送ってください。ええと、chris dola@zillows. com 宛に私にメールを送れます。
また、ええと、Discordチャンネルで私たちにpingしてもらっても構いません。ええと、あなたは匿名として表示されています。なので、私はあなたに返信することはできませんが、より詳細な質問を送り返していただければ、助かります。私たちで回答できるようにします。もう一度だけ確認します。
何かありますか、あ、すみません、答えがわかったと思います。つまり、ええと、あなたは、あなたは、バイナリのものを持っているはずですよね？バイナリベクトルを持っているはずです。つまり、それはバイナリデータ内の一種のメトリックです。そして、ええと、2種類の異なるメトリックを持ちたいという意味であれば、はい、間違いなくそうです。現時点では、データを再構築する必要があります。
あなたは、インデックスを再構築する必要があります。そして、ええと、削除して再構築したくない場合、つまり、そうしたくない場合は、間違いなく2つの接続を持つ必要があります。あるいは2.4からは、2つのカラムを持つことができます。なので知らせてください。状況によって異なるようですね、ええと、バイナリベクトルについて話しているのか、それとも先ほど言及した、ええと、1行に2つのベクトルを持つことについて話しているのかによって、ええと、ここには2つの異なる答えがあるかもしれませんので、質問の本当の意味を確認する必要があります。はい、いいですね。
では、皆さんありがとうございました。ええと、Mike、申し上げたように、Saachiが、ええと、できるだけ早く録画を投稿します。彼女が簡単な編集をします。ええと、Leeへの他の質問があれば、私たちのDiscordチャンネルで彼に連絡できます。また、ええと、GitHubの、ええと、GitHub discussionsエリアでも彼に連絡できます。
それから、ええと、もし、ええと、ご存じのように、これをたくさんのビジュアルを含む論文にして、これを、ええと、さらにわかりやすくします。そして、さらに質問がある場合は、私たちはいつでもフォローアップの、ええと、ウェビナーを、ええと、皆さんの好きな形式で行うことができます。ですので、もし皆さんが、ええと、こういうQ&Aだけを行う形式を気に入っているなら、またこれを行えます。あるいは、より伝統的なウェビナースタイルのほうがよければ、それもできます。ええと、今回は少し違うことを試してみたかったのです。
それで、ええと、あなたとあなたの学びにとって何が最も効果的かを教えてください。そして、ええと、この情報が、ええと、ベクターデータベースに対する、ええと、要件が何か、そして、ええと、あなたが選ぶどのベクターデータベースがあなたの要件に合うのかを判断する助けになれば幸いです。あなたが作っているクールなものが大成功することを願っています。最後に何かありますか、Lee？ええと、ありません。こうしたことを皆さんと共有できて本当にうれしいです。
そして実は、私には、私には、私たちには、私たちには、私たちには、もっともっと言いたいことが、ええと、たくさんありますが、どうやら、今はもう時間がないようなので、できればまたの機会に。ええ。わかりました。皆さんありがとうございました。また近いうちにお会いしましょう。
バイバイ。
Meet the Speaker
Join the session for live Q&A with the speaker
Li Liu
Principal Engineer
Li Liu is the Principal Engineer at Zilliz, leading the vector searching research and development. Before joining Zilliz, he was a Senior Engineer at Meta, designing and shaping numerous advertising stream data frameworks. With a Master's degree from Carnegie Mellon University, he boasts extensive experience in databases and big data. Li Liu's expertise in technology and innovation continues to drive advancements in vector searching, leaving a lasting impact on the field.