- Events
秋のライブデモイベントでZilliz Cloudの最新機能をご覧ください
ウェビナー
秋のライブデモイベントでZilliz Cloudの最新機能をご覧ください
Join the Webinar
Loading...
セッションについて
こんにちは！Zilliz Cloud Fall Live Demo がまもなく開催されることをお知らせします。このイベントは、当社の最新の進歩について技術的な詳細を深く掘り下げ、最新情報を把握したい方にとって必見です。ベストプラクティスや新機能を直接確認し、それらをプロジェクトに取り入れる方法を当社のプロダクトエキスパートから学ぶことができます。
取り上げるトピック:
- 新機能のライブデモンストレーション: Range Search、Cosine Similarity、Upsert など
- Zilliz Cloud のインターフェースのツアー
- Zilliz Cloud のセットアップを最適化するためのベストプラクティス
- 技術的な質問にお答えする Q&A セッション
VUS のアーキテクチャについて少し掘り下げていきます。分散システム、分散システムのデータベースが、ええと、何によって特別なものになるのか、そしてそれが何をするのに役立つのかについて少し話します。それから、ええと、Zillow's Cloud について少し話します。これは Viss のフルマネージド版で、さらに、ええと、何らかのハードウェア最適化も組み込まれています。そして Zillow's Cloud を少し宣伝して、私たちの顧客が誰なのか、何に取り組んでいるのかについて話します。そして、ええと、最後に少し時間を取って、皆さんがしたい質問を何でもできるようにします。
ではここから始めます。画面を共有します。うんうん。いきます。おお。
よし。皆さんこれ見えていますか？皆さん見えていますか？よし。ええと、今日は少人数の参加者のようですね。なので、ええと、これはもう少し、ええと、インタラクティブなセッションにする機会になると思います。ですので、ええと、もしよろしければ、皆さんがソフトウェアエンジニアなのか、データサイエンティストなのか、あるいはどんな役割なのかを、ええと、チャットに入れていただけると嬉しいです。そうすれば、皆さんにとって役立つ内容により合わせやすくなります。
よし。ソフトウェアエンジニア。いいですね。いいですね。よし。
よし。ソフトウェアエンジニアですね。よし、では、ええと、かなり、ええ、しっかりしたエンジニアリング系の参加者がいるようですね。実際、それは素晴らしいです。なぜなら、VIS と miland のインフラストラクチャ、ええと、そういった、私が本当に好きなことについて話せるからです。
おっと、営業の方もいますね。よし、いいですね、いいですね。営業なんですね。では、私は、私は、ええと、ええと、皆さんはホストとパネリストにだけメッセージを送っています。ええと、だから私には皆さんの、すべてのメッセージが見えています。
ええと、そしてそれが、私がそれらを声に出して読んでいる理由です。ええ、皆さんには見えないのを知っているので。ああ、LOL そうです。皆さんが入力していることは全部見えています。よし、クール。
では、ええと、営業側のことについても少し話しますが、ええと、最初は、ええと、アーキテクチャやエンジニアリング関連の内容に焦点を当てます。よし。プロダクトとエンジニアリング。クール。クール。
ええ、では、プロダクトについても触れますが、ええと、エンジニアリングの内容から始めます。これが Viss について私が最も興味深いと思っている部分です。ここには私についての紹介スライドはありません。通常はあるのですが、ええ、なので、今ここでそれも少しカバーします。私の名前は Yugen Tang です。
私はここ Zillows でデベロッパーアドボケイトをしています。ええと、私のバックグラウンドはソフトウェアエンジニアリングです。Zillow に来る前は、自分で作成した自然言語処理 API を運営していました。ええと、Amazon で 1 年弱の間に約 250 万を、ええと、達成しました。
ええと、そして、ええと、私は 16 歳のときに IBM で働き始めました。そして機械学習に関して、ええと、第一著者として 2 本の論文を発表しています。ええ、かなり機械学習寄りのバックグラウンドです。そしてこれは、ええと、私が思うに、ベクターデータベースで私たちがやっていることは、新しい LLM のようなパラダイムにおいて、ええと、最も重要な要素の 1 つになると思っています。では、なぜ私たちが Novus をこのように構築しているのかから始めましょう。
Novus が分散システムのベクターデータベースであることは、なぜ重要なのでしょうか？では、現在、ええと、私が理解している限り、外部の人々が Vector database をどう見ているかというと、ええと、人々はベクターデータベースを見て、「これは同じものだ」と思っています。これは 1 つの塊ですよね？つまり、それは、それは、ただ、それは、それはベクターデータベースです。しかし実際には、ええと、ベクターデータベースの実装は、その、その、その機能レベルで非常に異なります。すべてのベクターデータベースは類似性検索を行うという点では同じことをします。しかし私たちにとって、VUSs は 1 つの目標を念頭に置いて構築されたベクターデータベースです。
そしてその目標とは、途方もない規模をどう扱うかです。ばかげたほどの規模をどう扱うかです。Alibaba は5兆個のベクトルを持っており、それが私たちの目標です。今後数年以内にそれを扱えるようになること、そのような規模を扱えるようになることです。そして、私たちがこれを非常に重要だと考える理由、この分野で解決すべき最も重要な問題はスケールを扱うことになると考える理由は、本質的にベクトルは非構造化データを表現できる方法だからです。つまり、ええと、ベクトルは世の中にあるデータの80%以上を表現するために使われるようになる、ということですよね？ 皆さんも Gartner の資料を見たことがあると思います。あの、あの、あの、つまり、世の中にあるデータの80%は非構造化データだと言っている、そういう市場調査のものすべてです。つまりこれが意味するのは、現在分析されておらず、使われていないデータが、使われているデータの4倍も存在するということです。私たちは文字どおり、世の中に存在すると推定しているデータの20%にしか触れていないのです。
そして、そのすべてを分析して使っているわけですらありません。もし皆さんが会社にいるなら、実際、これは聴衆からも少し、ええと、意見をもらうのにとても良いでしょう。もし会社で働いているなら、あなたの会社はすべてのデータを活用していますか？ あなたの会社はそのデータをすべて使っていますか？ それとも、データの多くはただそこに置かれているだけですか？ ぜひ教えてください。私は話を続けますが、教えていただければ、見つけ次第コメントしますね。そうですよね？ それで、ええと、私の推測では、あなたの会社はおそらく、そこにあるすべてのデータを使ってはいないでしょう。では、Mil Vista のアーキテクチャについて少し話しましょう。そして、なぜこの構築が、なぜこれが、スケールするものを構築できるようにするものなのかについてです。これは高レベルの概要であり、Mil Vista のアーキテクチャがどのように見えるかを示した高レベルの図です。
まず SDK から始めます。私たちには2つの、ええと、コア SDK があります。これは、ええと、スケーラビリティの目標を明確にしてもらえますか？ それは Mils 向けですか、それとも Zillow 向けですか？ そうですね。ええと、これについては少し後で触れます。ええと、viss はオープンソースで商用利用可能です。無料で使える、ええと、選択肢です。
そして私たちの目標は、viss がこれをサポートできるようにすることです。それが何であれ、サポートされる必要のある規模が何であれです。兆単位のベクトルであっても、Viss がそれを簡単にサポートできるようにしたいのです。Zillow は viss の商用提供版です。それは私たちの、ええと、クラウド管理型の、完全管理型の選択肢です。そして私はいつも人々に言っています。zills での私の役割は、人々に viss を使ってもらうこと、ベクトルデータベースを使ってもらうこと、そして viss について教えることです。
なぜなら viss は本当に、本当に、少なくとも私の意見では、非常に革新的だからです。そしてそれを構築した人たち、つまり、それを構築したチームは、本当に、本当に、どのようにこれに取り組むかについて思慮深かったのです。SQL データベースや no SQL データベースのアーキテクチャを見たことがあるなら、これが革新的なアーキテクチャだと言う意味がわかるでしょう。ええと、しかし Zillow は当然ながら私たちの商用提供版です。私たちはビジネスなので、人々を Zillow に移行させたいと思っています。
そして私は人々に言います。DevOps をもう扱いたくなくなるまでは Viss を使うべきです。そして DevOps を扱いたくなくなったら、Zillow に行くべきです。なぜなら、ほとんどの企業にとって、DevOps を扱うことは本当にビジネスの中核なのでしょうか？ あなたにとってミッションクリティカルなのでしょうか？ もしそうなら、自分で DevOps を扱えばよいのです。私たちは、ええ、私たちは、そのための商用無料の選択肢として Novus を提供しており、それを行えるようにしていますよね？ ええと、しかし DevOps を扱うことがあなたにとってミッションクリティカルでないなら、それが収益を生み出さないなら、zills を使うべきです。なぜなら、おそらくそのほうが安くなるからです。おそらく支払う DevOps エンジニアの数は少なくて済むでしょうし、おそらく DevOps コストも少なくて済むでしょう。なぜならベクトルは非常に、ええと、負荷の高い、ええと、非常に、非常に、ええと、ええと、ええと、計算負荷の高いデータ型だからです。したがって、これらを扱うには、EC two インスタンスやその他のそのようなものを最適化できなければなりません。
したがって、もしそれをやりたくないのであれば、そこで Zillow が本当に役に立ちます。ええと、h Kraus、ええと、Zillow のサービスは AWS のようなオンプレミスまたはクラウドプラットフォームとどのように統合されるのでしょうか？私たちは AWS marketplace に出ています。ええと、ですので、AWS marketplace 上で Zillow と直接統合できます。オンプレミスについては、1つ、ええと、くそ、ええと、実はこれがもう出ているかどうか分かりません。実はこれがもう出ているかどうか分かりません。ええと、ちょっと恥ずかしいですね。
これは出ていると思います。私たちは、ええと、データプレーンを維持できるようにし、私たちは、ええと、コントロールプレーンだけを維持し、触れるのもコントロールプレーンだけである、というサービスを提供しています。つまり、私たちはお客様のデータに一切触れません。お客様のデータを見ることもありません。これは、多くのセキュリティ志向の企業が非常に関心を持っており、非常に、まあ、やりたがっていることだと私は知っています。
ええと、ですので、これは私たちが提供しているものです。現在利用可能かもしれませんし、ええと、一般には利用できないかもしれませんが、エンタープライズ向けには間違いなく利用可能です。ええと、ですので、もしこれが、オンプレミスの選択肢があなたにとって重要なものであれば、その場合は、ええと、まあ、こちらのチームに連絡を取り、そして、そして、それについて、ええと、ええと、その形でより詳しく話すことをお勧めします。ええと、では、アーキテクチャについて話しましょう。viss がコアです。ここでのコア機能、コアとなる設計判断は、柔軟なスケーリングを可能にし、ええと、データ移行のようなことをしなくて済むようにし、システムで実行しなければならない計算負荷の高いタスクの量を減らすことを容易にするシステムを、どのように構築するかを中心にしています。
そしてこれは、SQL や no SQL データベースにおける設計判断とは異なります。なぜなら、SQL データベース、たとえば SQL データベースでは、異なるテーブル間でより複雑な操作が必要になるからです。これは、SQL データベースにおけるデータの背後にある意味が、これらのテーブル全体に分散しているためです。そうですよね？リレーショナルな、ええと、データがあります。だからリレーショナルデータベースと呼ばれるのです。そうですよね？それらは ID を照合し、これらの ID に対してパラメータ、または、ええと、属性を照合します。そして、それがデータベース内のデータの背後にある意味を判断する方法です。ベクトルデータベースは非常に異なります。なぜなら、ベクトルは必要な意味的意味のほぼすべてをエンコードするからです。そして、それにメタデータを追加できますし、追加すべきです。それによってデータが豊かになり、検索体験がより良くなります。
Novus はフィルタリングを可能にします。ですので、ええと、まあ、ここでの主な点は、データベースを接続する必要がないということです。クエリの複雑さは行固有の操作に限定されます。つまり、必要なのは行レベルでの asset だけです。そして、これを可能にするために私たちがどのようにモデル化しているかというと、viss 全体、いずれにせよ Viss におけるデータ操作全体を、ええと、パブリッシング、つまり pub sub サービスとしてモデル化しています。基本的に Kafka に対して、Kafka を通じて、Pulsar を通じて、何らかのストリームを通じて、データをパブリッシュしているのです。
そして data node がそれをサブスクライブし、それを読み取ります。そしてそれが、そこに取り込まれる方法です。したがって、それは実際に、ええと、機能的な、ええと、システム内のほぼすべての機能の分離を可能にします。ただし、ええと、それが同じ、ええと、基本的には同じ機能性の中にない限りです。これをどう行うかというと、一連のものがあります。ここ下部に表示されているように、一連の worker nodes があります。これらの worker nodes はステートレスです。
これらは単なるノードです。これらは本質的には、必要なときに起動する CPU のようなものです。その上で、私たちが、ええと、これらの worker nodes とどのように連携するかというと、coordinator service があります。そして coordinator service は本質的にノードに何をすべきかを指示します。そしてデータを保存するために、min io、s three blob storage など、必要な任意のユニットのような object storage があります。
これが非常に重要である理由は、このアーキテクチャ、この設計によって、真の関心の分離をオーケストレーションできるからです。検索システムを構築しているとき、つまり、それを可能にするもの、その、その、その、スケールした検索に焦点を当てたものを構築しているとき、本当に3つの別々の、3、3、3つの別々の関心事があります。1つ目は、どうやって自分のデータをクエリするか？ 2つ目は、どうやって自分のデータを取得するか？ どうやって自分のデータをストレージに入れるか？ そして3つ目は、どうやって自分のデータにアクセスするか？ です。だから私たちは、これらをクエリ、データ、インデックスに分けており、これらのノードはすべて一種のものです。つまり、これらの、こうした、これらの機能は互いにデカップリングされている必要があり、互いに分離されている必要があります。なぜなら、それぞれ異なる使われ方をするからです。ええと、クエリノードは、クエリに使われますよね？ システム内でデータを見つけるために使われ、データを取得するために使われます。そしてデータを取得することは、データをシステムに入れることとは何の関係もありません。
したがって、データノードとクエリノードはデカップリングされていなければなりません。そしてここでのインデックスノードもデカップリングされていなければなりません。なぜなら、その方法、つまりデータにアクセスする方法を作るために何かを使うことは、データが入ってくるかどうかとは何の関係もないからです。特定のデータを要求しているかどうかとも何の関係もありません。ですから、これら3つの関心事はすべて互いに分離されている必要があります。
そしてそれが、私たちがこれらのデカップリングされた機能を持っている理由です。さらに、その上に、私たちはこの、ええと、1つの、私たちはこの、この、データを書き込み、そして一貫性を保てるようにするという概念を持っていますよね？ このように絶えず更新されるシステムで対処するのが最も難しい問題の1つは、このデータの一貫性です。どうすれば自分のデータが、最新のデータ、あるいは少なくとも許容できる範囲で最新のデータであることを保証できるのか？ そして、分散システムではないもの、単一インスタンスでスケールアップするものを構築する際の問題の1つは、ハードウェアの問題に直面することです。たとえば、ええと、ここでは名前は出しませんが、これを行っている競合企業があります。ええと、そして仮にあなたがそのうちの1つを使っていて、単一インスタンス上にいて、スケールアップしていて、突然100、そして、まあ、128ギガバイトのRAMに達しているとしましょう。
それがどれくらいなのかもよくわかりません、どれくらい大きく、本当にどれくらいまでスケールアップできるのかはわかりませんが、たとえば128ギガバイトのRAM、256ギガバイトのRAMにいるとしましょう。では、そのとき何が起こるのでしょうか？ それを超えてスケールする必要があるとき、何が起こるのでしょうか？ データ移行を行う必要があります。だから私たちはこれを完全に抽象化して、あなたがそんなことをしなければならない理由はない、と言っています。なぜなら、解決すべき主な課題はスケールだと考えているからです。ですから私たちは、あなたがデータを入れやすくし、そのデータをそこに保持し続け、持っているデータ量を増やし続けられるようにしたいのです。そして、再インデックス化やデータ移行のようなことをしなくても、それを、そうすることをより簡単にしたいのです、ですよね？ データ移行を行うときは、新しいデータと古いデータの間のデータ一貫性を気にしなければなりません。
入ってくる新しいデータはどこにWR、書き込まれているのか？ 古いデータに書き込まれているのか？ 新しいデータに書き込まれているのか？ それはどこに書き込まれているのか？ そして私はどこからデータを取り出しているのか？ 古いデータを取り出しているのか？ 新しいデータを取り出しているのか？ いつこの種類のデータを取り出すべきなのか、ですよね？ だからデータ移行は、私もソフトウェアエンジニアとして、Amazonで、こうしたものを見てきました。データ移行は、いずれにしても私がやりたいものではありません。ですからこれは、私たちがシステムを設計したときに念頭に置いていたことの1つであり、それが、ええと、それが、まさに私たちがこうしたステートレスなワーカーノードを持っている理由です。それらはあなたのデータをオブジェクトストレージに保存するだけで、読み取り専用バージョンを取得してそれで作業できます。そしてそれが、私たちがこれらの、これらの、ええと、セグメント上にこれらの、これらの、ええと、インデックスを構築するということを行うインデックスノードを持っている理由です。ええと、つまりインデックスノードは構築します、512メガバイトのセグメントがあるたびに、私たちはあなたのデータ上にインデックスを構築します。
システムに512メガバイトを入れるたびに、512メガバイトというのは単なるデフォルトの数値です。必ずそれを使わなければならないわけではありません。256メガバイトにしたいなら、1ギガバイトにしたいなら、完全にあなた次第で、そうできます。これはシステムの設定可能な側面です。これは私たちが提案しているだけです。
そして、これは良いだけでなく、再インデックスする必要がないからです、そうですよね？データを追加するたびに、やっていることは、ええと、ただ新しいインデックスを作成しているだけです。インデックスを完全に停止して、より大きなインデックスを作る必要はありません、そうですよね？つまり、単一インスタンスのスケールアップの問題の一つは、たとえば、データが100ギガバイトに達したとします、ええと、それがあなたの、ええと、何らかのストレージの si 制限かもしれません。ええと、そしてさらにデータを追加したいとします。そうなると、今度はデータを2つの異なる場所に置かなければならず、そのデータをインデックスする方法を見つけなければなりません。そしてインデックス作成は非常に計算コストの高いタスクです。なぜならインデックス作成では、実際に一通り見て、これらすべてのベクトル計算を行わなければならないからです。
そしてベクトルは非常に、非常に長い、ええと、数値の列です。通常、私たちが見るベクトルは数百次元、あるいは1000、2000、ええと、次元のものです、そうですよね？だから、fif、ええと、open ai、ええと、ベクトル埋め込みは1536次元です。ええと、そうですね、この作業を進めるにつれて、非常に、非常に複雑なデータを扱う必要があります。ええと、今たくさん質問が来ているようです。なので、ええと、質問に答えます。それからアーキテクチャについてさらに質問があれば、アーキテクチャについての質問に答えて、それから、続けます。
では見てみましょう。ええと、LLM はこのアーキテクチャのどこに統合されますか？類似性検索のようなもののために mils を呼び出す API は何ですか？ええと、そして、この、この、この、このアーキテクチャはデータベースシステムのアーキテクチャです。LLM は実際には rag の部分、検索拡張生成の一部です。そして、それは現在非常に人気があると私たちが見ているベクトルデータベースのユースケースの一つではありますが、ベクトルデータベースの唯一のユースケースではありません。ええと、たとえば、ええと、私たちの最初の最大の顧客は、製品レコメンデーションに私たちを使っていました。
そして製品レコメンデーションは l lms とは何の関係もありません。rag とも何の関係もありません。そしてもう一つのユースケースとしては、ええと、DNA 分子のような検索、生成的な、ええと、正直それがどのように機能するのか完全には分かっていませんが、ええと、彼らは分子構造のようなもので何かをしていて、それも LMS とは何の関係もありません。ですから LLMs は実際には、私たちは非データベースシステムの側面には触れていません。なぜなら、データベースシステム自体が十分に複雑なので、最良のデータベースシステムをどのように提供するかに集中すべきだと考えているからです。そして類似性検索は、ええと、私たちには ilves という SDK があり、ええと、それを使うことができます。
ええと、あるいは Zillow に行くこともでき、zillow. com には、ええと、API とどのように統合できるか、あるいは API をどのように使えるかについてのさまざまな例がたくさんあります。しかし本質的には、どんなサーバーに接続するのとも同じです。何らかのサーバーに接続したことがあるなら、ホストがあり、ポートがあることを知っているでしょう。そしてこのホストポートを AURI に変換できます。そして通常、何らかの API トークンを渡します。私たちの場合、その API トークンはユーザー名とパスワードです。
そして私たちは、viss の API と対話できます。任意のサーバーベースのシステムの API と対話するのとまったく同じ方法で、です、そうですよね？なぜなら viss はサーバー側のベクトルデータベースだからです。viss はサーバー上に存在するものです。そしてその理由は、繰り返しになりますが、私たちがスケールを信じているからです。Viss はすべてのデータを Delta Lake 形式で保存しますか？いいえ、実際には Parquet だと思います、ええと、ただし望むならその形式をいじることもできると思います。Parquet がデフォルトだと思います。
ええと、でもそれは良い質問です。持ち帰って、データを保存する他の方法があるかどうかも確認してみます。ええと、おお、ライブで回答します。worker node には query、data、index の3種類があるようです。これらはすべて複数のマシンにスケールアウトできますか？はい、これらはすべて複数のマシンにスケールアウトできます。実際には、でも、ええと、つまり、私は、私は、ええと、各 node は基本的に一種のマシンです。つまり1台のマシンです。
そして実際にスケールアウトする方法は、sharding を行うことです。ですので shard は配置でき、必要であれば複数の shard を持つことができます。1個、2個、3個、いくつでも shard を持てます。そして shard delegator、または shard leader と呼ばれるものがあります。これが行うのは、すべての shard を集約し、すべてのデータがどこにあるかというローカライゼーションを追跡することです。
ですので1つの query node を持つことができ、これは、このこれは query node 上にあります。したがって query node は、ええと、通常 shard を保持できます。そして起こることとしては、個々の shard は segment にもアクセスできます。segment とは、segment とは、ええと、index を行う512メガバイトの segment です。つまり、scalability を制御するのは shard であり、shard を複数の node に配置できます。
そして、ええと、これは1対1ではありません。必要であれば複数にできます。replications に基づいて、高可用性が必要な場合や、それを使ってやりたいことが何であれ、そうできます。ユースケース次第です。しかし答えははいで、この3つはすべてスケーラブルで、独立してスケールでき、互いに合わせてスケールする必要はなく、疎結合です。ええと、はい。まだ index されていないデータを query できますか？素晴らしい質問です。
答えははいです。はい、できます。私たちには、ええと、vis の中に growing segment と呼ばれる概念があります。growing segment とは、入ってきたデータが message store に行き、message store で timestamp が付けられるものです。そしてそれが consistency の仕組みです。
私たちは Delta consistency と呼ばれるものを使っています。それが意味するのは、ええと、まあ、strong consistency と eventual consistency がありますよね？つまり eventual consistency は本質的に、ええと、無限大の delta であり、strong consistency は delta がゼロです。ですので、すべてのデータに timestamp を付けて、query のどれくらい前までのデータが必要かを把握できるようにしています。ええと、ただ、このデータが入ってくると、増えていき、growing segment の中にあります。起こることとしては、query node と data node がこの growingsegment を追跡します。
そしてあなたが、query する必要がある場合、または query するとき、query node は growing data にアクセスでき、あなたのデータ、つまりその growing segment のサイズに応じて、すでに index を作成している場合もあります。つまり、それが segment size の10%に達すると、つまり、私が示したデフォルト例の50メガバイト程度では、そこに index を作成します。そうすると検索が速くなりますが、それ以前は、それらの、ええと、それらの vector を単純に brute force search するだけです。ですので答えははい、それはできます。自分たちの datacenter で viss を実行した場合、これは心配する必要があるものですか？ええと、私は、私は、私は、これについてもう少し詳しく説明してもらう必要があります。
ええと、この、これが何を指しているのかよくわかりません。viss を動かす engine は何ですか？Java ベースですか？ええと、おお。ああ、つまり、viss は Go で書かれている、というようなことです。Delta lake は transaction log が追加された Parquet です。ああ、ええと、それ、それ、それは正しいかもしれません。私は、私たちは多くの logging を行っていますし、基本的にシステム全体を pub sub の log service として構成しています。
はい、いいですね。そこの質問は全部終わったようです。ええと、この質問、つまり「これは心配しなければならないことですか？」について、もしもう一度質問し直したいのであれば、ええと、私が答えることはできますが、ただ、ええと、アーキテクチャについて他に質問がなければ、次のスライドに進みます。ええと、アーキテクチャについて質問があるなら、たぶんこれについて数時間かけて深掘りできると思います。というのも、月曜日の早い時間にこれについて1時間くらい、文字どおりシャーディングとセグメントのことだけに費やしたばかりなので。はい、ではここからはZillowについて話す、より広告っぽい内容です。
Zillow cloud は完全マネージドの vis サービスですよね？ なので、そこに何らかの、ええと、AI ML ツールキットを載せています。つまりここで、ええと、LMS に関する質問が少し意味を持ってきます。私たちは多くのことを行っていて、皆さんのデータをパイプで取り込んだり、embeddings などをパイプで取り込んだりできるようにしやすくしようとしています。そして、これを行っているパートナー企業もいくつかあります。ええと、そして真ん中に viss があります。
そしてこれが本質的に Zillow cloud の提供内容です。これは完全マネージドの viss であり、さらに Viss が完全マネージドであることに加えて、私たちはハードウェア、ええと、ハードウェア機能も最適化しています。つまり、これは自分でもできますが、ご存じのとおり、当然ながら私たちはこれに多くの人員を投入しています。これを行うための専門知識も豊富にあります。ええと、そしてごく最近、ええと、最近ではないかもしれませんが、何を最近と考えるかによりますね。
ええと、ただ今年の3月頃に NVIDIA 統合を開始し、今年の早い時期にそれを完了しました。正確にいつだったかはよくわかりませんが、NVIDIA 統合を完了し、現在 Novus は、ええと、ハードウェアアクセラレーションされたGPU上で実行できます。これを行った理由の1つは、つまり、それは、そうですね、繰り返しになりますが、ベクトルは扱うのに計算コストの高いデータ型だからです、ですよね？ 私たちは何百もの数値を扱っており、それらを比較する方法は、つまり、これらの、ええと、ベクトルを比較する基本的な方法が3つあります。1つはユークリッド、または L2 ノルムですよね？ これは X の二乗プラス Y の二乗の平方根です。私たちの実装では、順位は、平方根を取るかどうかにかかわらず同じになるので、平方根を取り除いていますよね？ X の二乗プラス y の二乗は、つまり、平方根を取ったものと、同じ順位になります。
ええと、これを行う他の方法としては、ええと、ええと、内積があります。これは DOT product で、単に、つまり、すべての数値を掛け合わせてからそれらを足し合わせて、そして、そして、そして、ええと、それがどう見えるかを確認するものです。ええと、そしてもう1つは cosign similarity で、そこで私たちは、異なるベクトル間の角度を測定します。そして、ええと、これらはすべて、ベクトルに対して計算を実行する必要があるものです。したがって、その計算を効率的かつ効果的かつ正確に実行できるものが必要です。だからこそ、私たちはGPU統合を行いました。
ええと、viss の上で Zillows として提供している他のものには、たとえば、マルチテナンシーがありますよね？ AWS を使うこともできますし、GCP を使うこともできますし、Azure を使うこともできます。ええと、Aldi cloud も使えると思います。ええと、そして、ええと、はい、なのでそれが、ああ、セルフホストオプションですね。はい。はい。わかりました。
これはスライドにあります。ええと、セルフホストオプションというのは、もしあなたがエンタープライズで、大量のデータを持っていて、それを管理したくない場合、私たちのところに来て、「私たちのデータを管理してほしい、ベクトルデータベースの管理方法を管理してほしい、でも、データをあなたたちに公開したくない」と言う、というものです。そしてそれが、先ほどコントロールプレーンとデータプレーンの分離について話していたことです。来年には、本当にオンプレのデプロイメントが可能になります。ええと、ただし、ええと、現時点ではそれはまだありません。
ええと、そして私たちはまた、たとえば、多くのセキュリティとコンプライアンス、ええと、取り組みや、セキュリティとコンプライアンスに関するものも持っています。どこかにあるはずです。はい。はい。ここにあります。
SOC 2、タイプ2、ISO 27,001、ええと、つまり、ロールベースのアクセス制御、データ暗号化、組み込みフェイルオーバー、99.9%の稼働率、こういったものです。ええと、私たちはおそらく99.99%、99.999%の稼働率に取り組んでいますよね？皆さんは、皆さんは全員ソフトウェアエンジニアです。皆さんは理解して、全員ではありませんが、多くの方はソフトウェアエンジニアなので、稼働率のことは理解していますよね。ええと、さて、Euclidean、dotproduct、co-sign distanceのどれを選ぶかを説明しているZillowの記事はありますか？ええと、私がその、うわ、うわ、うわ、何が起きたんですか？ええと、何が起きているんですか？皆さん、ここで何が見えていますか？はい、私のラップトップに何が起きたのかわかりません。ええと、いや、何、何だ、すみません、技術的な問題が発生しています。
何が起きているんですか？はい、ええと、これらの、ええと、基礎について、Zillowで話している私のYouTube動画をいくつかリンクします。ええと、役に立つといいのですが。ではこれを皆さんに入れます。どうぞ。これは、ええと、私が話しているもので、とても短い動画で、ただ話しています。L2とは何か？dot productとは何か？cosignとは何か？これらの異なる利点は何か？そして、それらがどのように見えるかをある程度見られるようなビジュアルを提供しています。
Zillowsには、アーキテクチャ、機能、スケール、パフォーマンスのような点で、他のvector dbsと比較したvissに関する比較情報はありますか？スケールとパフォーマンス、アーキテクチャについてはあります。ええと、つまり、ええと、たとえば、ええと、まあ、自分のコードをドキュメント化してもらうだけでも十分大変です。他人のコードをドキュメント化してもらうのは、非常に、非常に難しいです。ええと、ですので、chroma、wvi quadrantについてのドキュメントはありませんし、当然ながら誰もpine conesのコードを見ることはできません。これは、つまり、その理由の一部で、ええと、つまり、Pine Coneが、私たちにとって本当に、ええと、競争力のあるソリューションになるとは思わない理由の一部です。なぜなら、私たちはオープンソースのエコシステムを信じているからです。私たちはオープンソースの精神を非常に重視しています。
オープンソースソフトウェアは物事をより良くすると信じています。ええと、pine Coneはクローズドソースです。ですから、私は、つまり、本当にファンではないというわけでもないのですが。ええと、とにかく、機能、スケール、パフォーマンス、ええと、それについては何かあります。探してみます。ええと、機能は難しいですが、スケールとパフォーマンス、はいどうぞ。
ええと、はい、完了。はい。それは、and so much more than Vissのスライドです、スライドが見えています。ええと、はい、よし、よし、よし。ええと、はい、いいですね。技術的な問題が起きていたので、確認してくれてありがとうございます。では、pine Coneは、メタデータを追加しすぎると検索パフォーマンスが低下する可能性があると言っています。Vissについてその点を話してもらえますか？ええと、それはvissです。はい、これは実際、これは実際にVissがメタデータを扱う方法についての非常に面白いポイントです。vissでは、どのメタデータフィールドを返してほしいかを選択できます。
つまり検索では、もし気にしないなら、もし特定して返してほしいメタデータフィールドがあるなら、つまり、それらを入れることができます。でも気にしないなら、つまり返してもらう必要がないなら、そうですよね？それらは必要ありません。実行するすべてのクエリについて、すべてのメタデータが必要なわけではありません。ええと、あなたは多くのタイプを行うことになります、その、その、その、非常に高い可能性で、非常に多くの異なるタイプのクエリを行うことになります。そして多くの、多くのタイプを行うことになるので、毎回同じメタデータを返して、取得して、取得して、取得する必要はありません。VUSがメタデータを扱う方法の面白い点の一つは、メタデータでフィルタリングできることです。
そして私は、ええと、私たちのメタデータをフィルタリングする方法は本当にたくさんあると思っています。どこかに、すべての式について説明しているページがあります。そしてNovusでメタデータフィルタリングが行われる方法は、これは本当に素晴らしいと思うのですが、実際にはビットマスクで実装されています。つまり、それが意味するのは、はい、メタデータフィルタリングのために時間の追加は発生しますが、その時間の追加はほぼ定数時間の追加になるということです、ですよね？それは、ベクトル検索を行うという計算コストの高いタスクに実際にかかる時間と比べれば、とても、とても、とても小さいものになります。ですから、それが私たちのメタデータの扱い方であり、ええと、だからこそVISもその方向に沿ってスケールでき、メタデータをどんどん追加してもパフォーマンスの、ええと、あー、あー、あー、差があまり出ないのです。
ええと、milli、ええと、Zillowの他の機能としては、ええと、自動インデックスがあります。なので、ええと、皆さんがface、ええと、Facebook ai、ええと、similarity searchについて聞いたことがあるなら、私たちにはfaceのために大量のコードを書いた人の一人がいます。ええと、faceというのは、ええと、インデックスを構築するための方法、本質的には、ええと、インデックスを効率的に構築し、ええと、それらに対してクエリを実行するための方法、方法、フレームワークです。ですからfaceはおそらくこの中のどこかで動いているのですが、私たちはあなたのデータを自動でインデックス化します。つまり、インデックスを選ぶ必要がなく、インデックスの種類について考える必要がありません。Novusでは、インデックスの種類について考えるべきであり、実際、正しいインデックスの種類を使うことは非常に重要です。なぜなら、異なるユースケースでは異なるインデックスの種類が必要になるからです。
たとえば、ええと、商品レコメンデーションをしている場合、良い再現率が得られなくても問題ないかもしれません。たとえば、ねえ、100件返してほしい、そのうち30件、または40件が、まあ、自分が必要としているものに十分近ければ、つまり返ってきた100件のうち実際にL 30が、実データの中で最も近い30件であれば、それで十分、という感じで問題ないかもしれません。ええと、商品レコメンデーションがそれでよい理由は、商品レコメンデーションエンジンを構築しているとき、商品がある可能性が非常に高く、ええと、販売している商品があり、ものを買いたい人々はクリックして進んでいき、必要なものを正確には見つけられなくても、似たものを見つけるので、複数のものをクリックしていくからです。私はAmazonでいつもこれをしています。
Amazonをスクロールしていて、オンラインショッピングをしています。ああ、うん、わかった、これは欲しいものにちょっと近いけど、まさに欲しいものではないな。似ているものを見に行ってみよう、似ているものを、見に行ってみよう、という感じです。今のところ、AmazonはVector databaseを使っていませんが、考え方は同じです、ですよね？たとえばeBayは私たちを使っていますし、Walmartも私たちを使っています。ですから、eBayにいる場合、あるいはWalmartにいる場合、たとえばeBayにいて、こう思うとします。ええと、私は、 shiny char art が欲しい、あるいは、何かそんなものが欲しい、ですよね？si が欲しい、shiny char art が欲しい、でも、見えているのは shiny blast、toys か何かだとします。
では、ここで似ているものを見てみよう、ですよね？そしてたぶん、返ってくるコレクションの中には、Pokemonカードがたくさんあって、それらは全部、全部、全部、全部Pokemonカードで、全部Blast toysに似ていて、もしかするとその中にchararは一つもないかもしれません。でもクリックしていって、こう言うわけです。ねえ、これはBlainだ。ああ、これもfire typeだ。ああ、いいね、次のものにはardがある、そしてそれを見て、手に入れるわけです。だから商品レコメンデーションでは、人々はあまり気にしないんです、ですよね？でもその一方で、もしかすると、もしかすると、あなたが、ええと、DNAを扱っていたり、ええと、分子構造を扱っていたりする場合、その場合はおそらく100パーセントの再現率が欲しいはずです。返ってくるものすべてが最も近いものであること、つまり、それが、それが、実際に返ってくるものの中で最も近いものであることを確実にしたいはずです。
あなたが求めているのは、実際に正確な構造です。でもその場合、必要ないもの、気にしなくていいものもありますよね？重視するのはスループットかもしれませんが、たとえば一貫性レベルのようなものは気にしないかもしれません。結果整合性でよい場合もあります。つまり、Vector databaseを構築し、それを使うには多くのカスタマイズが関わってきます。そしてそれは本当に、本当にユースケース次第です。
だからこそNovusには、こうしたさまざまな機能が組み込まれているのです。そしてだからこそZillowでは実際に、auto indexが基本的にあなたのデータを見て、そのデータにとって最適な、最適なインデックスに基づいてインデックスを構築してくれます。ええと、これらに加えて、OpenAI、cohere、などなど、多くのインテグレーションがあります。ええと、データ移行もサポートしています。先ほどデータ移行について話していたのを覚えていますよね？データを入れる必要がありますし、新しいデータもあれば古いデータもあり、それらが一貫していることを確認する必要がありますよね？ですから、こうした一貫性レベルをサポートし、データ移行を行えるようにサポートしています。ええと、そしてオンデマンドスケーリングもあります。
つまり、ええと、オンデマンドの、たとえば、ロードバランシングやスケーリングを心配する必要はありません。ですから、たとえば、ああ、明日は、ええと、例えばあなたがeBayだとして、明日はeBay dayだ、みたいなことを心配しなくていいのです。それが実在するものかどうかは知りませんが、Amazonにはprime dayがありますよね？だから明日はeBay dayで、ええと、たとえば、ええと、トラフィックが10倍になると予想している。だからスケールアップする必要がある。まあ、Zillowではそれをする必要はありませんよね？DevOpsエンジニアにそれをさせる必要はありません。
DevOpsエンジニアに予測システムを構築させる必要もありません。ただ、よし、私たちはZillow上にいる、と言えばいいのです。Zillowが自動的にスケールアップしてくれます。ええと、それに加えて、ログ関連のような監視機能もたくさんあります。使用状況についてアラートを出します。
たとえば、そのコレクションを使ったことがありますか？空のままですか？たくさん使っていますか？希望する予算を超えていますか？などなどをお知らせします。あなたのアーキテクチャのスライドにはDDLが示されていましたが、これはスキーマ定義を意味します。vissのようなvector databaseでは、スキーマをどのように設計しますか？わあ、素晴らしい質問ですね。ええと、スキーマは、はい。ええと、つまり、私たちのやり方、やり方、ええと、私はスキーマ設計について、ええと、会社として私たちが推奨しているスキーマ設計の考え方とは少し違った考え方をしています。
ええと、ただ、必要なmetadataに基づいてスキーマを定義すべきだと思います。IDフィールドが必要で、embeddingsフィールドが必要です。embeddingsフィールドは必要です。そうすることで、vector embeddingsを、ええと、vectorやembeddings全体で比較できますし、IDフィールドが必要なのは、ええと、特定のvectorsを取得できるようにするためです、そうですよね？ええと、それから最近Dynamic schemaという機能を導入しました。これは基本的に、embeddingフィールドにIDがある限り、JSONドキュメントをそのまま投入できるもので、他のフィールドが何であっても私たちは気にしません。これを行う理由は、あなたがそこに入れるデータに柔軟性を持たせたいからです。というのも、ええと、どれだけ、つまり私はすべてのデータスキーマは強制されるべきだと思っていますが、現実には人々はそういう使い方をしていないからです。
それは人々が物を使うやり方ではないですよね？ どれだけ「こういうふうに使ってください」と伝えても、彼らはあなたの言うことを聞くわけではありません。だから、それを考慮に入れ、それに対処し、人々が自分たちの使いたい方法で使えるように必要なツールを提供できなければならないんです、そうですよね？ つまり最終的に、この dynamics team のようなものがあるのは、ユーザーが私たちの想像した使い方とは違う形で使いたいからです。私たちが、私たちが、私たちが彼らはそう使うだろうと想像していたやり方とは違うからです。なので、これによって柔軟性とユースケースが可能になります。これによって、より高いユーザビリティ、使いやすさ、必ずしも「より簡単なユーザビリティ」という意味ではなく、より多くのカスタマイズ性、そしてより幅広いユースケースとより良いユーザー体験が可能になります。vis の公開されているプロダクトロードマップはありますか、ええと、Christie、これ知っているかどうかわかりません。
ええと、もしこれを知っていたら、ぜひ入れてください。ええと、私はこれはわかりません。vis で古くなったデータや更新されたデータをどのように圧縮または削除しますか？ いい質問です。現時点では、ええと、だからこそ ID があるんですよね？ ええと、だからこそ、ええと、基本的には ID フィールドがあるんです。なのでデータを取得して削除し、再挿入できます。
つまり、そうですね、実は upsert と呼ばれるものを追加したばかりです。なので、それが今の Zillows の新機能で、今ではこのようにデータを挿入できるようになっています。ええと、ただ、以前の delete の動作としては、ええと、soft delete を行っていました。つまり本質的には、ええと、データを保存していて、ええと、ええと、ええと、すべてのデータは、ある意味、ええと、bits のように保存されていますよね？ それで私たちがやっていたこと、やっていることは、先頭に bit を持たせて、削除するには soft delete を行うというものです。単に bit を反転させます。
これによりデータ復旧が容易になり、その後、将来的に hard delete を行うことができます。そして hard delete を行うと、かなり、そして、そして、元々 512 メガバイトだった 500、512 メガバイトのセグメントが、もはや 512 メガバイトのセグメントではなくなる可能性が出てきます。その一部は小さくなるかもしれません。なので、そうした delete を行った後、私たちが行うのは、時々、これは、おそらくユーザー設定によるものだと思いますが、少なくとも Vis では、Zillow では自動化されています。ええと、これらすべてのセグメントを結合して、小さなセグメント単位で re-index できます。
したがって、これは依然として計算コストの高いタスクですが、データセット全体を re-index するよりは、はるかに計算コストが低いです、そうですよね？ なので、ええと、より多くのデータを削除していくと、特定の sparse な、あるいは sparse なセグメントができます。ある時点で、たぶん 10、20% くらいだと思いますが、「このセグメントを結合して re-index します」と言うことになります。なので、ある時点でそれらは reindexed されます。ええと、ただ最初の delete は、delete は bit flip です。そしてその後、実際の overwrite で、auth zero は何を、ああ、ええと、ふむ。見てみます。
ええと、これは違う、これは、ええと、待って、先に進んでいますね。戻るつもりでした。AU zero LDP。これがどこにあるか見てみます。私は、何、これはどこですか？ 他の方にありますか？ ここにありますか？ ああ、ああ、ああ、ああ、ああ、はい、はい。ああ、わかりました。
ええと、私は、ええと、はい、はい、はい。ありがとうございます。私は、私は、これがこのスライドに関するものだとは気づいていませんでした。わかりました？ ええと、これは auth zero ではないと思います。これは、ええと、auth o と呼ばれるものだと思います。ええと、正直なところ、これが何なのか、ええと、完全にはわかりません。
ええと、これは Zillow の cloud 関連のものの一部です。ええと、後で確認します。答えを見つけて、これについて後ほどお返しします。ええと、おそらくおわかりのとおり、私は Zillow 側のことより Novus 側のことの方にはるかに詳しいです。ええと、でも、そうですね、基本的に Zillow は多くの authorization 関連のことを処理してくれます。
そして私はこれを信じています。これが何に関係しているかというと、これは、ええと、関連していると思います、えっと、ええと、ええと、ロールベースのアクセス制御みたいなものですよね？つまり、こうしたシステムを構築するときには、適切な認可が存在することを確認する必要があります。そして、それが、これの目的です。Auth zero は人気があります、はい、知っています、auth zero のことは知っていますが、これは auth zero ではないと思います。もしかすると、GitHub でサインアップできるようにしていますし、ええと、それから Google とか、その他いろいろでもできるようにしているので、そうかもしれません。で、えっと、Zillow の仕組みですが、これが Zillow のアーキテクチャです。
これは本質的に、私たちがコントロールプレーンとデータプレーンを分離できるようにしている方法でもありますよね？えっと、つまり基本的には、あなたのプライベートクラウド、あなたの VPC がありますよね？VPC トンネリングができます。実際、VPC トンネリングはできると思います。企業向けには間違いなく利用可能です。一般公開はまだされていないかもしれません。えっと、でもここで言っているのは基本的に、ねえ、この Kubernetes エージェントを使って、Kubernetes が、私たちのプロキシで何が起きているか、そういうものを処理する、ということです。ロードバランシングとか、そういう s**t 全部です。
そしてそれを使って viss を実行します。Kubernetes help charts とか何とかを使って、viss をオーケストレーションします。Kubernetes はオーケストレーターで、viss はエンジンです、そうですよね？えっと、それから、えっと、もし、あなたが AV、VP C を持っていて、その中に何か実行される必要があるものがあるなら、ええと、私たちはピアリンクを行えますし、ええと、それをあなたの VPC で実行できます。ええと、ほかにどんな質問があるでしょうか、彼らが ld、IDP、そしてアイデンティティプロバイダーのことを言っていたのでなければ。えっと、はい、私は、私はわかりません。
本当に、この質問の答えはわかりません。ええと、この質問の答えを見つけますし、あなたに返答できます。ああ、何が起きたんだ？なんてことだ、もっと技術的な詳細がある。わかりました、いきましょう。えっと、そうですね、これらが Zillow の使い方です。
えっと、スターターティアがあります。これはサーバーレスティアです。これは無料です。えっと、私たちが会社として存在する限り無料です。えっと、少なくともそれが現在の、ええと、現在の、ええと、ええと、ええと、取り組みです。これに関する現在のガイドラインです。
えっと、これにより、最大 500 K の 768 次元ベクトルのコレクションを 2 つ、または 256 K の 1536 次元ベクトルを利用できます。これをこのように設定した理由は、たとえば、ええと、半分の cu とか 1 CU とかのようにするよりも、ベクトル数やサイズのほうが人々にとって理解しやすいからです。ええと、稼働時間や SLA は提供していません。単一のアベイラビリティゾーンです。これには GCP しかありません。えっと、セキュリティについては何も約束していません。
えっと、そしてスターターティア、サーバーレスティア、無料ティアで得られる主なサポートは、コミュニティに来てコミュニティにサポートを求められる、というものです。えっと、そして私たちには Discord チャンネルがあり、えっと、それは、まあ、基本的にはコミュニティサポート用です。えっと、それからスタンダードティアがあります。これは専用ティアです。これは、まあ、ええと、本番対応です。
えっと、これにより、コスト最適化、ストレージ最適化、パフォーマンス最適化があります。基本的に、これに使用できるさまざまなティアがあります。そしてそれぞれ異なるコストがあり、ええと、それぞれ本質的に異なるユースケースがあります。えっと、そして必要なだけのデータをここに置くことができます。えっと、そしてこれには、基本的なセキュリティ関連のものが全部含まれていますよね？データ暗号化、ロールベースのアクセス制御、SOC two などです。
ええと、それからメールサポートを受けられて、あなたの、あなたの会社から最大2名の技術担当者が来て、そして、そして、そして、そして、ええと、その方々からの質問にお答えします。ええと、それからここに dedicated enterprise があります。これは、ベクターデータベースがあなたの会社のミッションクリティカルな、ええと、あなたの会社にとってミッションクリティカルな一部である場合です。もし類似性検索の利用が、もし非構造化データを比較できることの利用が、あなたの会社で収益を生み出すうえで重要であるなら、そのとき enterprise のような階層を使うことになります。ですので、ここでもまた、ええと、パフォーマンス向けに同じような種類のオプションがあります。ええと、ただし追加の SLA も提供しています。たとえば 99.9% の稼働率、複数のアベイラビリティゾーン、VPC private link、データバックアップ、そして最大4名の、ええと、連絡先です。
そして、必要であれば、あなたの組織は複数のクラスター、ええと、クラスターの種類を使うことができます。サーバーレスから専用クラスターへ移行するオーバーヘッドは何ですか？何もないと思います。実際かなり、私は、私は、ええと、その際に、何らかの中断を経験することはないと思います。つまり、文字どおり、それを行うことでサービスの中断は発生しないはずです。HCTP メトリクスは Grafana、Tableau、D three のような可視化ツールで使えますか？はい。実際、今朝、Tableau が Zillow'sCloud に統合されたというメッセージを受け取りました。
ですので答えははい、これはできますし、Grafana も利用可能です。ええと、Terraform や ACLI のような IAC を使って viss データベースを管理できますか？はい。はい、できます。ええと、おお、待って、待って、待って、待って、待って、待って、待って、待って。ええと、Terraform については、完全には確信がありません。
Terraform や Ansible にはあまり詳しくありません。ええと、ただ Kubernetes 関連については、間違いなく、ええと、私が自分の非 Mils lightdatabase を管理している方法は、ええと、Docker Compose 経由です。ええと、それは単に、私が信じられないほど巨大なものを扱っているわけではないからです。ええと、私は主にこれを、ええと、つまり、概念実証、ええと、MVP、そのようなものに使っています。ええと、ただ Helm charts は、Salesforce や atand t のような多くの企業が Novus を使っているのを私が見る方法です。
Novus には3種類の cuse があります。1つはコスト最適化で、基本的には、ええと、つまり、最高のパフォーマンスは必要ないけれど、ええと、動作する必要がある、というものです。そして、ええと、それでも他のもののパフォーマンスを上回るはずです、まあ、はずではなく、実際に上回ります。ベンチマークを見れば、自分のデータを持ち込んでいつでも自分でテストできます。ただベンチマークを見ると、世の中の他のほとんどのベクターデータベースのパフォーマンスをかなり上回っています。ええと、そしてこれにより、ストレージに行くと、1 CU は 3.
75 million、10、24 次元ベクトルです。ええと、同じ違いです。ええと、ただパフォーマンスになると、実際には、ストレージは、ストレージ量が少なくなりますが、それはよりコンピュート負荷が高いからです。これはより高速な、ええと、つまり、より低いレイテンシと、ええと、より良いスループットのためのものです。どう、どう、どう、おお、さらに質問があります。
誰かが Terraform Terraform provider を作成して、novis のようなものを見つけて管理できるようにする必要があります。もしかすると Zills がそれに取り組んでいるかもしれません。ええと、Christie Satchi、この質問の答えを知っているかどうか分かりませんが、私は知りません。あり得ます。私たちは、その、私たちはその領域に関心がありますし、ですので間違いなく、ええと、より柔軟な利用を可能にし、そして、そして、そして、可能な限り最高のユーザー体験を構築しようとする方向に進んでいくと思います。
Lummi はもう1つの人気のある IAC 製品です。わかりました、ありがとうございます。私は、これは聞いたことがありません。VIS に admin、CLI があるなら、その方法で独自のスクリプト作成ができます。実際に存在すると思います。
そこには、cl みたいなものがあるというか、つまり、VIS とは、ええと、GRPC を通じて、または、ええと、ええと、rest を通じてやり取りできます。ええと、それで CII は、たぶん、できます、そうですね、CLI でそれができると思います。私は、それが問題になる理由はないと思います。必要な、すべての、その、その、パラメータを提供できる限り。ええと、これの残りは説明しましたっけ？ええと、performances はこれらのどちらよりもずっと速いです。
ええと、これらは全部同じだと思います。ええと、ああ、ここ、ユースケースの例。これはたぶん皆さんが知っておくといいものです。つまり、データラベリング、重複排除、クラスタリング、外れ値検出、本質的には、データクリーニング、データ分析をしたいなら、cost optimized が向いています。ええと、storage、ええと、はもっと、そうですね、たくさんの、たくさんのものを比較したい場合です。たくさんのものがあるけれど、多くの比較をする必要はない場合です。
ええと、または小規模な比較をする必要があるけれど、本当に、本当に、本当に、本当に重視しているのが、膨大な量のデータを保存できることなら。そのときに storage optimized を使うことになります。そして performance については、よりリアルタイム性、よりスピード、より、ええと、よりスループット、こういう類の s**t が必要な場合です。そのときに、ええと、performance optimized のものを使うことになります。Gen ai、レコメンデーションシステム、chat bot、不正検知、そうですよね？リアルタイム、つまり本当に、ええと、ええと、パフォーマンスクリティカルな、ええと、ユースケースです。
ええと、なので先ほど言っていたように、そうですよね？ええと、私たちは rag のためだけではありません。rag は今とても人気があるものにすぎません。LMS によってベクトルデータベースに多くの注目が集まりましたが、実際には、それが唯一のユースケースではありません。そして、私は、それが最大のユースケースになるとも思いません。なぜなら実際には、創薬や商品レコメンデーションのようなものは、在庫管理も含めて非常に大きいからです。そうですよね？不正検知。銀行などは、そうですね、例えば私は数週間前にクレジットカードを盗まれました。だから、こういうもの、そして、そうですね、こうしたものこそが、この非構造化データを比較できる能力を持つことが重要な理由なのです。ええと、横断的に、単に、それは、LMS に入力するだけのものではないんです。そうですよね？それは、類似性検索を行っているので、扱えるようにしたいものなのです。
リレーショナルデータベースでは、アクセラレーションのために頻繁にアクセスされるカラムにインデックスを持つことができます。ベクトルデータベースにもこれに似たものはありますか？ええと、例えば、ええと、この質問についてもう少し詳しく説明してもらう必要があります。例えば、ええと、キャッシュのようなものを意味していますか？ええと、私たちには、セマンティックキャッシュを行う GPT Cache というツールがあります、seman。これはスケールするセマンティックキャッシュです。Viss のクエリ言語は何ですか？Viss のクエリ言語は、ええと、sql ではありません。
ええと、本質的に何をするかというと、ベクトルを提供すると、それがベクトル検索を行います。そしてフィルターを行う必要がある場合は、式を提供すると、それが式検索を行います。ええと、なので私は、たぶん、これについての例を開いているかもしれません。これを開いているかどうかは分かりません。ええと、da da。
私の visual studio code はどこですか？Basic usage。わかりました、ではこれの共有を停止して、VS を共有します。Code share screen vs code。これはこれについて話していると思います、はい。わかりました。
なので、これは raw search と novis がどのように見えるかです。見えるように拡大します。つまり本質的に何をするかというと、いくつかの embeddings を送信して、それから approximate nearest Sameer search をどの field で実行するかを伝え、検索のためのいくつかの parameters を渡します。ええと、この場合、L two を渡しています。なぜならそれが保存時に使ったものだったからです。そして、ええと、どれくらいの数の、ああ、これは、これを IVF、つまり inverted file index を使って保存したという事実に固有のものです。これは、ええと、cluster のリスト、ええと、すみません、OID のリストを作成します。
そしてこれは、検索したいOIDの数を指定しているだけです。Limitは返してほしい結果の数です。そしてoutput fields、ここが私が話していたメタデータの部分ですよね？このメタデータが必要なら、それを取得します。メタデータに関心がなければ、取得しません。なのでこの例では、この2つのメタデータフィールドだけを取得していますが、実際に何が起きたかというと、ええと、実際のフィールドはこんな感じです。
つまり、私は大量のメタデータを保存していて、そのうち2つのフィールドだけを取得しています。ええと、それからここにexpressionがありますよね？さっき話していたようなフィルタリング式です。そして、ええと、これは、ええと、こうやって式をフィルタリングします。これは、とても、これは、なんというかsqlみたいなものだと思います。つまり、expression fieldsはsqlみたいなものだと考えられますよね？同じように、たとえばgreater than equal toみたいなものがあります。なので、ええと、検索言語はSDKによるAPI、いいですか？それが何を意味するのかは分かりません。
ああ、クレジットカードが盗まれたようなユースケースについて詳しく説明できますか？いや、無理です。私のクレジットカードは本当に盗まれたんです。これは例として使っているわけではありません。ユースケースではなく、実際に盗まれただけです。不正取引を特定するためにLSS TMモデルを使わないのはなぜですか、vector storeはどこに入ってくるのですか？つまりLtmsは不正取引を特定できません。
Ltmsは、ええと、sequence、ええと、sequence to sequenceの変換のためのものです。そして、ええと、vector storeは類似性検索を行うことができます。なので、ええと、不正取引が、ええと、ええと、行われる方法というのは、あなたが、あなたが、ユーザーに関する情報を持っていて、その、ええと、情報をベクトル化する、ということだと思います。そして、ええと、その情報を他のベクトルと比較しますよね？つまり取引が発生するたびに、その取引に関する多くの情報があります。そこでその情報をベクトル化して、そのユーザーの他の取引と比較し、場合によってはそのユーザーが行っている他のようなこととも比較します。
例えば、ええと、つまり、例えば、ええと、もし、ええと、もし、もし、ええと、私の支出のほとんどがシアトルで行われているのに、突然オハイオで何かを買っていたら、警告サインですよね？そしてそれはベクトル距離で見ることができます。そういったことが基本的に、不正検知が、行われる、行われる、行われる方法です。普段とは違う異常なものを見つけて、それを行うわけです。ええと、なので、これが以前どのように行われていたかというと、ええと、実際にはcollaborative filteringと呼ばれるものを通じて行われていました。ええと、あるいはcollaborative filteringは商品推薦のためのものでした。でも同様に、ええと、anomaly detectionで、これに似たことができます。はい、これはベクトル距離であって、AIモデルではありません。
私たちはそれを計算するためにAIを使っているわけではありません。ベクトル距離を使う方が実際にははるかに、はるかにシンプルで、はるかに速いのです。さて、データをベクトル化するためには機械学習モデルを使う必要がありますが、それ以降は、ええと、それは単純に、ええと、ええと、その、使わないベクトル距離です。ええと、私たちは、私たちは、私たちは、基本的にそれを何らかのモデルに通しているわけではありません。ええと、分かりました、待って、私の、どこ、私の画面はどこですか？もう自分の画面がどこにあるのか分からないので、画面共有を止めます。
はい。ええと、はい、ここに質問はありましたか？ええと、いくつかあります、ええと、時間になりました。ええと、なので、最後のいくつかの質問に答えて、それから他に質問がある場合は、ええと、私の名前は隅にありますので、LinkedInで気軽に連絡してください。ええと、または、ええと、Christie、Discordリンクを投稿してもらえますか？ええと、そして、ええと、そうですね、私たちはDiscordでも、ええと、ええと、ええと、気軽に連絡してもらって大丈夫です。ええと、これは、これは終了です。
ベクトル構造とその使い方はスキーマや利用方法の関係で、SQLのようなデータベースとはまったく異なるため、インデックスのようなもの、つまり実用的にインデックスを作成する方法はないのではないかと思っています。4つのリレーショナルシステム。これについては先ほど話しましたが、インデックス作成については、私たちはインデックスを作成しますよね？ええと、つまりインデックス作成とは、ベクトルデータにアクセスする方法であり、ベクトルデータを比較する方法です。そして、それはあまり、インデックスがキャッシュか何かとして行われるということではなく、インデックス作成は、たとえば検索したい60億個のベクトルがあるけれど、60億回の比較はしたくない、というものにかなり近いです。そこでそれに対してインデックスを作成します。インデックスの例としては、IVF、つまり inverted file index のようなものがあり、そこでは大量の OID を作成します。
そしてその仕組みは、まず OID だけを検索します。そして oid に基づいて、最も近い可能性のあるものを選び出すことができます。つまり、検索しなければならないベクトル空間を大幅に削減し、実行しなければならない計算量も削減できます。ほかのインデックスの例には、HNSW、hierarchal navigable small worlds のようなものがあり、基本的に各層はより疎なグラフになっています。そして、最上位のグラフからずっと下へ検索していき、ええと、下まで、下まで到達するまで進みます。
そしてこのグラフでは、これらすべての距離をエンコードしているので、それほど多くの計算を行う必要がありません。つまりインデックスは存在しますし、実際のところ、インデックスはベクトルデータベースにとってほぼ必須で、必要なものです。なぜなら、それがなければ単にフラットな比較を行うことになるからです。そして最も計算上優れた、つまり最も計算的に最適化されたシステムであっても、それでは遅くなります。ですのでインデックスはあります。ただし、リレーショナルシステムで機能するのと同じようには機能しません。
ええと、本質的には、それは唯一の、データに効率よくアクセスする方法であるだけではありません。大規模にそれを実際に扱うための、ほとんど唯一の方法です。はい。ええと、皆さんありがとうございます。それから、h Kraus さん。確か、以前お会いしたことがあると思います。
また近いうちにシアトルのイベントのどれかでお会いできることを願っています。ええと、皆さんありがとうございます。それでは、よい一日を。
Meet the Speaker
Join the session for live Q&A with the speaker
Yujian Tang
Developer Advocate at Zilliz
Yujian Tang is a Developer Advocate at Zilliz. He has a background as a software engineer working on AutoML at Amazon. Yujian studied Computer Science, Statistics, and Neuroscience with research papers published to conferences including IEEE Big Data. He enjoys drinking bubble tea, spending time with family, and being near water.