Events
Milvus Liteの紹介：GenAIアプリ向けのインストールしやすく使いやすいベクトルデータベース

ウェビナー

Milvus Liteの紹介：GenAIアプリ向けのインストールしやすく使いやすいベクトルデータベース

Zilliz ウェビナー | Zoom

Join the Webinar

何を学べますか？

ノートブックやラップトップ上で実行でき、Milvus と同じ API を共有し、あらゆる人気の GenAI フレームワークと統合できるベクトルデータベース、Milvus Lite を紹介します。このウェビナーは、GenAI アプリ向けに使いやすく、統合性に優れたベクトルデータベースを求める開発者に最適です。

取り上げるトピック

Milvus Lite 概要：ローカル利用向けに軽量でありながら強力なバージョンを作り上げる際の考え方。
設計原則：スムーズな開発者体験を保証する主要機能とアーキテクチャ上の選択。
クイックスタートガイド：お使いのマシンで Milvus Lite を起動して実行するためのヒント。
ライブ RAG デモ：Milvus Lite を使用したライブ RAG アプリの構築をご覧ください。

Milvus Lite があなたの GenAI アプリ開発の歩みにどのように適合するかを発見し、すぐに構築を始めるためにご参加ください。

View presentation slides

Transcript

本日のセッションでは、えー、Mils Lightsをご紹介する、えー、ゲストスピーカーをご紹介できて嬉しく思います。Yang Chenは、ZillizでAIプラットフォームおよびエコシステムの責任者を務めており、データインフラストラクチャと情報検索において長年の経験を持っています。Yangは以前、Googleで検索インデックスのテックリードおよびプロダクトマネージャーを務めていました。彼はUniversity of Michiganのコンピューターサイエンスの修士号を取得しています。Ann Arbor、Yangを歓迎します。このステージはあなたのものです。

こんにちは。皆さんようこそ。えー、はい、まず簡単に自己紹介をさせてください。えー、Stefanが紹介してくれたように、えー、私は現在、エコシステムとAIプラットフォームを担当しています。えー、ここ数か月は、エコシステム統合に取り組む以外にも、この、えー、mul lifeプロジェクトもリードしてきました。

えー、そして今日は、この、皆さんに向けたWareの新しい提供物をご紹介できることをとても楽しみにしています。これは、AIアプリケーション内でPythonライブラリとして実行できる軽量なベクトルデータベースです。インストールが非常に簡単で、始めるのも非常に簡単です。気に入っていただけることを願っています。では、前置きはこれくらいにして、えー、少し背景を振り返ってみましょう。えー、なぜ私たちがベクトルデータベースを構築したいのか、そして特に、えー、使いやすく、インストールしやすいベクトルデータベースを構築したいのか、ということです。これは、えー、AI開発者が自分たちの、えー、AI開発スタックを始めるのに最適なものです。ベクトル検索のこの話は、ディープラーニングとニューラルネットワークの進歩から来ているようなものです。

えー、従来は確率による検索がありました。えー、用語やトークンによる検索があり、これは転置インデックスや、えー、Elastic Searchのようなスタックが使われていたものです。考え方はだいたい、えー、ドキュメントをトークンやキーワードに分解し、それからキーワードも見つける、えー、つまり、えー、クエリからキーワードを生成し、それからクエリのキーワードをドキュメントに照合し、そして検索を完了する、というものです。しかしこれは非常に機械的で、検索を行う機械的な方法であり、えー、いくつか望ましくない挙動を生みます。たとえば、ドキュメントがクエリとほぼ同じアイデアについて話しているにもかかわらず、キーワードが正確に一致しないために取得できない、というようなことです。たとえば、what's your ageはhow old are youとは非常に、非常に違います。

えー、共通するキーワードはあまり多くありませんが、実際には同じセマンティクス、同じ意味を共有しています。そこでディープラーニングとニューラルネットワークが登場します。これは検索における確率の考え方を使うものです。つまり、この考え方は、えー、ディープニューラルネットワークを用いることで、ドキュメントをベクトルとしてエンコードし表現でき、そのベクトルがドキュメントの意味の感覚をある程度捉える、というものです。同じことがクエリにも行われるので、クエリとドキュメントの2つの表現を照合するとき、それらがこのように近い距離、えー、潜在空間上で近い場合、別の言い方をすると、そのクエリと他のドキュメントと比較してベクトル間の距離が短い場合、それらが同じセマンティックな意味を共有している可能性が高い、ということになります。この考え方により、これを中心に構築された多くの技術や機械学習モデル、またデータインフラストラクチャが存在するようになりました。

えー、皆さんの中には、valueモデルのようなものをご存じの方もいるかもしれません。えー、えー、たとえば、BERTや、さらには、えー、Transformer、えー、アーキテクチャの中の、えー、アーキテクチャです。そしてベクトルデータベースは、このために導入されたインフラストラクチャの一部です。つまり、優れたモデルによって埋め込みベクトルを生成できるようになった今でも、そのベクトルを保存し、効率的に取得するための何かが必要です。それがベクトルデータベースの役割です。そしてこの優れた技術により、過去12か月で、AIアプリケーションや開発者の間で非常に人気になっている、もう一つの、えー、技術的パラダイムが生まれました。それはretrieval augmented Generationと呼ばれています。

そのアイデアは、インバウンドモデルとベクトル検索を大規模言語モデルと組み合わせて使用し、特定の知識領域における大規模言語モデルの能力を向上させることです。たとえば、社内データを持つ企業で、そのデータを外部のコミュニティと共有したくない、あるいは大規模言語モデルの学習データとして使用されたくない場合があります。その場合でも、このデータを使って、ベクトル検索によりユーザーに優れた質問応答体験を提供するチャットボットを構築できます。仕組みとしては、まず知識ベースをベクトルとしてインデックス化し、左下に示されているようにベクトルデータベースに保存します。これらのベクトルにより、効率的に検索および取得できる知識ベースを構築したことになります。

そしてユーザーが特定の質問をしたとき、この場合、ユーザーは vus に関する非常に具体的なインデックスタイプの質問をしたいかもしれませんが、大規模言語モデルはおそらくそれを知りません。なぜなら、そのケースに特化したドキュメントで学習されていないからです。このクエリは、ドキュメントに使用したものと同じインバウンドモデルによってクエリベクトルに変換されます。そしてそのクエリは、近似最近傍探索によってベクトルデータベース内で検索され、クエリと非常に近い意味、または関連するセマンティクスを持つ可能性が高い最も近いベクトルを見つけます。その場合、それらのドキュメントが質問に答える可能性が非常に高くなります。そこで、ベクトルデータベースから上位 K 件のドキュメントを取得したら、ユーザーの質問、取得したドキュメント、いくつかの指示を含むプロンプトを構成し、それを大規模言語モデルに送信できます。すると大規模言語モデルは十分に賢く、推論を行い、要約を行い、最終的にはユーザーの期待に合った高品質な回答を提供します。

この例では、単に何かをでっち上げるのではなく、先月時点では 11 種類のインデックスタイプがあった、というように回答します。この背景を踏まえて、なぜ mil light を構築するのでしょうか？それは、MIL がこの領域で非常にうまく機能しているからです。その理由は、VU は多くの開発者に愛されているにもかかわらず、使い始めるのがそれほど簡単ではないことに気づいたからです。たとえば現在、Ware を使う最も簡単な方法は Docker デプロイメントを通じたものです。

そして Docker を使うには、いくつかのスクリプトをダウンロードし、そのスクリプトを実行する必要があります。コマンドの数は多くないとしても、Python や pip を使ったアプリケーション開発に慣れている開発者にとっては、まだ少し怖く感じられます。また、ホストマシンや開発マシンに Docker をインストールする必要もありますよね？もっと簡単なものがあったらどうでしょう？たとえば、現時点でスケーラビリティを気にしないなら、もっとシンプルなものを使えないでしょうか？答えは yes です。なぜなら s slide はそのために設計されているからです。つまり、Docker や大量のスクリプトをダウンロードする代わりに、Python 環境を用意して pip install PY mailbox を実行するだけでよいのです。それで必要なことはすべて実行されます。これはほとんど単なる Python ライブラリであり、下に示したように、from Pine mailbox import mill client のようにインポートできます。そして SQ lite を使うのと同じように、ローカルファイルを指定してクライアントをインスタンス化します。

このローカルファイルでは、この後に挿入するデータをメモリに読み込むだけでなく、ここで指定されたファイルとしてそれらを具体化し、永続化します。この場合は NS Demo db と呼ばれ、このようにして、Docker や Kubernetes 上にデプロイされた Milvus と同様の体験を提供します。また、これは非常に軽量かつ効率的なので、Jupyter Notebooks 上のノートパソコンでも、スマートホームデバイスやモバイルのようなエッジデバイス上でも実行できます。その仕組みとしては、分散システム上でのスケーラビリティを目的として設計された VU の重い処理コンポーネントをすべて取り除いている、ということです。以前のアーキテクチャを見ると、クエリノード、データノードがあり、メッセージキュー用に Kafka があります。高スループット、高トラフィックを処理し、水平スケーラビリティのために設計された、非常に多くの優れたものがあります。

つまり、より多くのマシンを投入するだけで、よりスケーラブルになります。数百億のベクトルに対して、検索の KPI が数千という規模まで耐えることができます。しかし、それはほとんどの AI アプリケーションには必要ありません。というのも、それらはまだ非常に初期段階にあるからです。単純に、データがそれほど多くありません。100万ベクトルすらないかもしれませんし、あるいは現時点ではスケーラビリティについて考えたくないかもしれません。私の最優先事項は速く進めること、あるいは単に技術、AI の技術スタックについて学びたいだけです。

Docker や Kubernetes を前提条件としてインストールしなければならないのではなく、RAG を構築する方法を学びたいだけです。それは要求が大きすぎます。そこでこの問題を解決するために、重い処理コンポーネントをすべて取り除き、ローカルの、たとえばノートパソコン、あるいはエッジデバイスのように計算リソースが非常に限られたマシンにも収まるほど、スリムで小さくできるようにしました。ここで保持しているのは、非常に基本的で最小限のベクトルインデックス作成と検索、そして永続ストレージだけです。では、左から右へ順に見ていきましょう。左側にはユーザーアプリケーションがあり、たとえば AI チャットボットです。

そしてそのチャットボットの中で mails client をインポートし、クライアントが、ええと、すみません。つまりクライアントが Mailbu のコアと通信できるようにしています。この場合、それはサーバーとコードです。クライアントは middle slide を通じて、データレコードを挿入、upsert、削除できます。そして最初にパーサーと通信し、クエリを解析できるようにします。パーサーが必要な理由は、クライアントが、たとえばこのベクトルを挿入してほしいというセマンティクスを表現するだけではなく、クエリの場合には、メタデータフィルタリング機能のために、このベクトルに最も近い、たとえば上位10個のベクトルを見つけるが、同時に次のフィルター式にも従う、たとえば subject を history にしたい、version を 2. 2 0. 3 0.

0 ではなく 2. 4 0. 0 にしたい、といった指定も行うことがあるからです。そういうことです。つまり、そこには式が付随しています。そのためパーサーは主に、その式を解析し、それをこのクエリ意図の内部表現、私たちが実行計画と呼ぶものに変換するために使用されます。そして実行計画は、さらなる処理のためにコアに渡されます。一方で、データの挿入と削除も具体化しておきたいと考えています。そうすることで、次回プログラムを再起動したときに、すべての状態が失われないようにするためです。

それは、ええと、mills クライアントのインスタンス化で指定するローカルの永続ファイルから再読み込みされます。ええと、そこにはストレージ系のコンバーターがあり、それが、ええと、挿入および削除操作をファイル操作に変換し、それからそれらのデータをローカルファイルにロードし、ええ、実体化します。なので、それを行うと、実際のベクトル検索や、ええと、最近の挿入と削除を反映するための更新やインデックス作成を行う準備が整います。コアは実際には、私たちが、ええと、メモリ内に保持している状態であるインメモリインデックスとやり取りし、ベクトルが追加または削除されるようにインデックスを更新します。そしてそれが検索であれば、指定した任意の検索、ええと、アルゴリズム、たとえば HHW や IIVF のようなものを使って、インデックスで検索を行います。これは、ええと、それを気にするかどうかによります。

それを気にしないのであれば、何も指定しないことができ、そうすると auto index が選んでくれます。ええ、アルゴリズムを気にするのであれば、どの、ええ、インデックス作成またはアルゴリズムを使うかを指定することもできます。なので、ええと、すべてが完了すると、それは Parer に戻され、最終的に mills クライアントに戻されます。これで、ユーザーアプリケーションはベクトルを取得するか、ベクトルストレージ上の操作を完了します。この設計により、今では VUS をほぼどこでも使うことができます。

ええと、gen アプリケーション上では、VUS 関連のクライアントコードを書くだけです。一度、たとえばクライアントをインスタンス化し、挿入検索を行います。そしてこのコードは、どのような種類の mill デプロイメントでも動作します。それが計算リソース上で動作する mill light であっても、li ええ、非常に制限された、ええ、非常に限られた計算リソースのデバイスであっても、あるいは Docker、Kubernetes、さらには vu と同じ API を共有する Zeus Cloud のようなクラウド上でも実行できます。必要な唯一の変更は、やはり mill クライアントのエンドポイントを切り替える必要があることです。というのも、基本的には新しいサーバーをセットアップしているので、クライアントを確立する際に、サーバーエンドポイントを示したいからです。

しかし、それがほとんどすべてです。そしてデータについても、データを効率的に移動する方法、ええ、あるデプロイメントから別のデプロイメントへ便利にデータを移動する方法を考えています。なので現在 MI は、ええ、このデータインポート機能をサポートしており、JSO または、のいずれかのファイルを指定すると、任意の mills デプロイメント上の新しいコレクションに、ええと、API 呼び出しだけで自動的にデータをロードできます。また、これを行うのを助ける便利なコマンドラインツールの開発も進めており、ええと、API コードを書くために数行のコードさえ書く必要がなくなります。デプロイメントに加えて、デプロイメント上の柔軟性です。

ええと、私たちは VUS を、LAMA index long chain のような、ええと、よく知られたものを含む、ほぼすべての人気のある AI 開発ツールキットにも統合しました。そして、ええと、それ以外にも、ええと、Voya AI や Gina、Gina ai、ええと、そして open ai のような多くの inviting model プロバイダーとも統合しています。彼らは inviting model をサービスとして提供しています。ええ、私たちは Bento ml とも統合しており、これは、ええと、ご存じのとおり、モデル推論の、ええ、ホスティングを行います。彼らにはオープンソース版とクラウド提供があります。

また、ええと、非常に斬新なコンセプトを持つ、ええと、他のプロジェクトとも実装しています。たとえば ragas です。彼らが行っているのは、ええと、rag、rag 品質評価のプロセスをある種合理化することで、バニラ rag を開発した後、通常はその品質を気にし、いくつか実験を行い、そして品質の測定をしたいですよね？なので ragas を使うと、ええと、ええ、RA 実装から、ええ、定性的な、ええ、すみません、定量的な数値を得ることができ、次に実装を変更したり、いくつか最適化を行ったりしたときに、異なる数値が返され、それによってそれが良くなったのか悪くなったのか、あるいはどのくらい良くなったのかを知ることができます。また、ええと、メモリを持つエージェントに取り組んでいる MAP GPT とも統合しました。ええと、つまりベクトルデータベースと埋め込みモデルです。

これは、つまり、エージェントがユーザーから過去に聞いたことを覚えていられるように、エージェントのメモリをエンコードして保存するための素晴らしい方法です。ええと、vu、ええと、クラスが、ええと、MAM GPT に統合されているので、この、ええと、MAM gtt によって実装されたエージェントでは、BU を使って状態を保存でき、bu の柔軟なデプロイメントモードの恩恵を共有できます。また、データソースフレンズもあります。ええと、たとえば、ええと、それは、つまり、ええと、ええと、データ処理パイプラインを構築するのに役立ち、あるソースから別のソースへデータを移動するのを助け、ええと、inviting やその他の変換を代わりに行ってくれますし、さらに多くの他のプロジェクトがあります。では、ここで質問のためにいったん止めます。ええと、その後で、mulli のドキュメントといくつかのライブコード例をお見せします。

聴衆から何か質問はありますか？今のところ直接の質問はありません。わかりました。誰かがただ、とても感銘を受けていて、ええと、middle slide 全般について満足していました。使うのがどれほど簡単か、ということです。では、次の章に進めると思います。ええと、Mul light と、ええと、vus に関する詳細情報については、Mills io のウェブサイトにアクセスできます。そして、より多くの情報を反映するために、ウェブサイトをちょうど再設計しましたよね？なので、ええと、前に言ったように、ええと、今では Mul light の体験は、pip style ひとつ分の距離にあります。

ええと、つまり PIP style すれば、mul on Docker と Covid ES、そして Mul Light の間で共有される同じ API を使って、コレクション作成、作成、データ挿入、検索などを行うことができ、それらはかなり直感的です。そして、私たちはまた、ええと、さまざまな種類の employ、ええと、deployment を行う方法についての手順へのポインターも載せました。それは、まあ、かなりわかりやすく、ただ P ping install するだけです。しかし Docker と Kubernetes では少し複雑です。ただし、詳細については、ええと、つまり、ドキュメントサイトで詳しく確認できます。ええと、この install middle セクションから、ええと、役立つスクリプトも見つけることができます。そこには、ええと、those light と docker があります。

ええと、Docker にはさまざまな、ええと、モードが利用可能で、Kubernetes もあります。ええと、これは少し複雑です。operators をセットアップするか、HEL を使ってデプロイメントを行う必要があります。また、ええと、多くのパートナーとの統合ドキュメントへのリンクもあります。ええと、これは完全なリストではありません。ドキュメントにはさらに多くあります。

そして最後に、しかし重要なこととして、ええと、Unstructured Data Meetup と呼ばれる対面のミートアップもあります。これは、ええと、世界中の多くの都市で開催されており、ええと、San Francisco、south Bay から、Seattle の Berlin、そして今後数か月のうちにたぶん New York でも開催されます。ですので、今後のミートアップで席を予約して、つまり、私たちと、ええと、直接話すことを歓迎します。では、ええと、これ以上の前置きはなしに、ドキュメントも確認してみましょう。そこには、lighting を実際にどう使うかを示す、非常に優れたコーディング例がたくさんあります。ええと、ここでは quick start から始めます。ええと、このドキュメントは notebook としても設計されているので、コマンドをコピー＆ペーストして、ええと、ローカルの、ええと、開発環境で実行することに加えて、実行することもできます。

そして基本的な内容以外にも、ええと、mill におけるさまざまな概念、たとえば consistency、multi-tenancy などについての deep dive もあります。これらは主に、ええと、新しいサーバーで使われる概念です。また、検索性能を高速化するために、ええと、さまざまな種類の index をどのように使うか、そして schema と data model design の詳細な説明もあります。ええと、ここでは扱いません。なぜなら、それはまた別の大きなトピックだからです。ええと、しかし、本当に非常に効率的なシステムを設計し、非常に複雑な操作を行えるようにしたいのであれば、ええと、schema design について学ぶことは非常に重要です。それに加えて、非常に包括的な統合ドキュメントもあります。

ええと、ここでご覧いただけるように、このリストにある多くの、ええと、パートナーと統合しています。そして、ええと、お見せします。たとえば、長いチェーンですが、うーん、retrieval augmented generation に取り組んでいる人なら、おそらく long chain と LAMA index は、データパイプラインの設計を支援する、よく知られており、最もよく使われているフレームワークです。インデックス作成やデータ処理、また検索にも使われ、さらに agent、ええと、あるいは agent capability を提供しているものもあります。ええと、時間があれば、あると思いますが、long chain を使って、rac の高度な概念を実装する方法について、より深く掘り下げます。そうすれば質問応答の品質を向上できますが、基本的な内容はここにあります。

では、ええと、get started に戻って、実際にこれを動かしてみましょう。ええと、先ほど述べたように、最初のステップは PPP install を行うことです。そしてこの、ええと、このコマンドでは、Pan Mills のクライアントだけでなく、Milland のサーバー部分、ええと、すみません、Mill Light のサーバー部分もインストールされます。ええと、私がサーバーを code の下に CO として置いているのは、先ほど述べたように lightweight だからです。内部で実際に行っていることは、ええと、GRPC を使ってクライアントとサーバー間で通信することですが、ネットワークを通じてではなく、ローカルファイルを通じて行います。

ローカルファイルは、データを永続化するためのローカルファイルとは異なります。ある種の、ほら、一時的なローカルファイルで、基本的には情報交換のための掲示板として使われるだけです。mill client と mul light の、ええと、サーバーコンポーネントの間で使われます。ええと、利便性のために、すべてのコンポーネントを Pine Mill に含めているので、Pine Mill を使用できます。もし、ええと、mill server を持っているなら、基本的に Pine Mills に求めるものはクライアントとしての機能だけです。しかし、Pine Mills と一緒に mill、ええと、mul Light も使いたい場合は、サーバー部分も含まれています。milless をより簡単に使うためだけに、別の Python package をインストールする必要はありません。

つまり、PIP install だけで、Mul client を、ええと、import できます。これは Milless と通信するために使う abstraction です。ええと、Mills client では、いくつか異なる方法でインスタンス化できます。ええと、この場合、Mills Light を使いたいので、ファイル名を指定するだけで、クライアントは Mills Light とともにインスタンス化され、このファイルを作成してくれます。もし以前にデプロイした何らかのサーバーと通信したい場合は、mill server endpoint と token を指定する必要がありますよね？たとえば Docker 上の Mill server であれば、それはおそらく port 付きの local host になります。そして token は、password を設定しているかどうかによります。username と password になります。

ええと、たとえば ZI Cloud を使っている場合は、ええと、Zis cloud cluster、ええと、Vector、CL vector database cluster の network endpoint になります。そしてその後に token として API key が続きます。つまり、同じ function、ええと、すみません、同じ API を共有していますが、少し異なる形になります。ひとまずこれを実行します。はい。

これで、ええと、新しい database を作成しました。そして現在この database には、ええと、collections はありません。なので、なので新しい collection を作成し、指定する必要がある最小限のものは dimension です。つまり、Vector が何次元か、何個の dimensions を持っているかです。ええと、ただしこれ以外にも、より多くの、ええと、parameters を指定できます。たとえば schema を自分で設計したい場合は、schema object を作成し、それをここで spec、指定する必要があります。たとえば、この vector と一緒にどのような、ええと、labels を持たせるかを指定したい場合は、それを schema で指定します。

ええと、ただし、もしアイデアがない場合、ええと、現時点でどのような、ええ、ラベルを持っているのか、または単にそれらを省略して何でも使い、あの、パフォーマンスへの影響を気にしない場合です。というのも、スキーマを定義することで、非、非、非アクター・フィールドのような特定のスケールフィールドにインデックスを定義できるからです。その場合、より効率的なメタデータフィルターが行われます。しかし、メタデータがない場合、たとえば数千または数万のベクトルしかない場合、それは、それは非常に小さい、ええ、ええ、データ規模なので、それを指定する必要はありません。そしてここで行っているのはそれです。

ええと、つまりこれが作成するのは、ID ベクトルだけを持つベクトルデータベーススキーマで、そこに入れたい任意のラベルを持てるものです。すぐに実際に見てみます。ええと、ただしその前に、ベクトル検索を行うには、まず factory が必要で、そのためには、ええと、モデルを招待するための、ええ、パッケージをインストールする必要があり、そうすることで、たとえばテキストをベクトルに変換できます。そして私たちは model という便利なラッパーを提供しています。ええと、このサブパッケージは、ええ、このサブパッケージは、前に述べたような多くのモデルプロバイダー、open ai、Voya、ai、ええ、Gina、ai、そして BGE のようなオープンソースの、ええ、埋め込みモデルや、ええ、sentence transformers をラップしており、これは、ええ、多くのオープンソースの埋め込みモデルに適しています。これを使えば、テキストを変換できます。

この場合、私は、ええ、3つの例の、ええ、テキスト文字列をドキュメントとして置きました。ええと、関数呼び出しだけでそれらを factory buyings に変換できます。つまりここで行っていることは、ええ、つまりここで行うことは、ええと、Pine から model パッケージをインポートし、ええ、新しい埋め込み関数をインスタンス化します。ええと、この場合、なぜなら、私たちは、この時点ではどの埋め込みモデルを使うかをあまり気にしていないからです。しかし、一度、ええと、これに慣れれば、おそらく自分自身の、ええと、どの埋め込みモデルを、ええ、使うかについての考えがあるでしょう。なぜなら、それらには異なる品質上の影響があり、ときには、ええと、プロバイダーが、ええ、いわゆる垂直型の、ええ、埋め込みモデルも開発しているからです。たとえば、ええ、法律会計に適したものもあれば、医療会計や金融、ええ、金融に関するものに適したものもあります。

ええと、自分に合うものや、異なる言語に適したモデルを自由に選んでかまいません。ええ、ただしデモ目的では、Outward Small V two という小さなモデルを使いましょう。これはわずか 50 メガバイトです。なので、ええ、数秒以内にダウンロードされ、ええと、それを使って埋め込みの中で変換できます。ここには、AI または活性化 activational intelligence の概念の創始者のような人物について話している3つのドキュメント片があります。そして、ドキュメントのリストを使って in embedding function dot encode documents を使用し、ベクトルを生成します。

これでベクトルのリストもでき、それぞれが、ええと、このリストの各、ええ、ドキュメント要素に対応するような形になります。そして、私たちが、ええ、単に encode ではなく incode documents を見る理由は、なぜなら、ええと、invite model の設計上、いくつかは異なる方法、またはわずかに異なる、ええ、わずかに異なる、ええ、いわば salt を、ええ、エンコード処理に追加して、ドキュメントとクエリを少し違ってエンコードするからです。そこで私たちは、ええと、2つの便利な関数を提供することでこれに対応しました。1つは encode documents と呼ばれ、もう1つは encode vectors、ええ、すみません、encode queries と呼ばれます。そうすることで、これについて考えたり、覚えたりする必要がなくなり、ただ、ただドキュメントには encode documents を使い、クエリの、ええ、文字列には encode queries を使うようにすればよいのです。そしてそのような違いがないものについては、単に code function をそのまま提供しています。

そして、もし、ええと、埋め込みモデルと招待モデルによって生成されるベクトルの両方の次元を出力すると、ええと、それらはあなたが指定した次元と一致するはずです。ええと、それはたしか、ええと、ちょっと待ってください、ええと、768次元です。ここで、メールモデルをダウンロードした後、ええと、コレクションのスキーマに指定したものと次元が一致していることが出力されているのがわかります。そうでなければ動作しません。ええと、なぜなら、挿入するものがスキーマで定義したものと一致している必要があるからです。そして、ええと、私たちはまた、ええと、全体の、ええと、データオブジェクト全体も構築します。それは、ええと、ベクトルデータベースに、ええと、1回の操作で挿入されます。

そして、先ほど生成したベクトルに加えて、id も持ちます。これは主キーとして使用され、また text も持つので、ベクトルを取得するときに、そのテキストも一緒に持ち出すことができ、別の場所でテキストを探す必要がありません。つまり、このためだけに別の SQL ストレージを設定する必要はありません。また、ちょっとしたお遊びとして、subject と呼ばれるラベルも追加しました。これは、ええと、これがどんな主題について話しているのかを説明します。たとえば、もしクエリを実行したいけれど、biology などではなく history という subject の中だけで実行したい場合、ええと、Milvus のクエリ言語でフィルタリングを指定できます。これは少し後でお見せします。今、3つの文字列オブジェクトにマッピングされる3つのエンティティを持つ、ええと、データオブジェクトがあります。

ええと、それぞれが、ええと、それぞれが、ええと、ええと、それぞれ4つのフィールドを持っています。Id、vector、text から subject までです。ええと、もし何らかの理由でモデルをダウンロードできなかった場合、たとえばネットワークの問題などで、ええと、ローカル環境では、デモを完了するためだけに偽のベクトルを生成することもできます。しかしそれは面白くありませんし、その部分については扱いたくありません。今、テキストの意味を表す本物のベクトルがあります。そしてそれぞれに、ええと、subject という非常に興味深いラベルが付いています。

ええと、これらをベクトルデータベースに挿入する準備ができました。現時点ではサーバーを設定する必要はありません。なぜなら、すでに Milvus Lite の環境があるからです。そして、この直感的な API client cer insert を使って、少し前に作成したコレクション名とデータオブジェクトを指定し、これで ID が 0、1、2 の3つの要素が挿入されました。これでセマンティック検索を行う準備ができました。ええと、「Alan Turn とは誰か」というようなクエリを適当に作ってみましょう。

そして前に言ったように、これを、ええと、クエリベクトルにエンコードする必要があります。なので、ええと、この encode queries は便利なようにクエリのリストを受け取り、複数のクエリを同時に実行できるようになっています。しかしこの場合は、ええと、1つのクエリだけにして、単一のクエリのリストを作り、サイズ1のクエリベクトルを生成します。これで検索の準備ができました。この search クエリ配列が、ええと、どのように構成されているか見てみましょう。まず、再びコレクション名を指定する必要があります。先ほど作成し、データを挿入したのと同じコレクションです。

そして data はクエリベクトルを受け取ります。ええと、すみません、data フィールドはクエリベクトルのリストを受け取り、それには1つのベクトルだけが含まれています。そして limit を指定する必要があります。これは興味深い点で、この limit は top K の K に相当します。つまり、このコレクションに保存されているすべてのベクトルの中で、今回は3つのベクトルがありますが、どれだけ多くの、ええと、最も近いベクトルを、ええと、取り出したいかという意味です。ええと、この場合は2を指定しましょう。

ええと、すべてのベクトルが欲しいわけではありません。そうすると面白くなくなります。それ以外にも、出力フィールドを指定することもできます。たとえば、ベクトルだけでなく、ベクトルに変換される前の生データや、いくつかのラベルも欲しい場合、それらを output field に指定すれば、結果の中でベクトルと一緒に、ええと、持ち出されます。ではこれを実行してみましょう。結果には、ええと、多くの興味深い情報が含まれていることがわかります。

ええと、まずデータオブジェクトが含まれていて、これは各結果についての結果のリストです。ええと、ID と距離を指定しています。距離は、ターゲットベクトルの類似度スコアのようなものです。この場合、モラトリアムについて話しているこの文のベクトルのほうが、ええと、クエリベクトル、つまり who is atory と、どの、あー、インデックスアルゴリズムと距離メトリックを使ったかに依存します。ええと、この場合は特にそれを指定していないので、デフォルトを使いました。

ただし、指定できる場合は、例えば、私のインデックス、あー、インデックスアルゴリズムを HSW にし、私の、ええと、あー、ベクトル距離を、あー、あー、例えばコサイン類似度や ip、つまり内積類似度で定義できます。つまり、どれを定義したかによります。距離は異なる方法で計算されます。この場合、ええと、距離は実際には 2 つの、あー、ベクトルがどれだけ類似しているかを表します。

ええと、しかし他の、ええと、距離、あー、距離メトリックでは、ええと、距離は文字どおり 2 つのベクトルがどれだけ離れているかを意味する場合があるので、それが、それによって昇順でソートされるか降順でソートされるかに影響します。いずれにしても、ええと、結果の、その、ランキングは、それらの間の意味的類似度によってランク付けされます。ええと、この場合、最も、あー、最も意味的に近いものは、ええと、where touring was born です。そして 2 番目は island touring kind of invented the concept of ai です。また、出力フィールドを tax と subject に指定しているので、ベクトル自体に加えて、結果には text と subject も出力されます。

はい。ええと、聴衆から質問があるか見てみます。はい、1 つあります。ええと、クエリの優先順位付けに関するものです。チャットで見たかどうか分かりませんが、はい、Alice から直接チャットにあります。必要なら読み上げます。

質問は、クエリ、あー、ベクトルをパラメータ化できるかどうかです。ええと、それから、各レコードを反復処理することが可能かどうか、つまり、SQL Server MySQL と同じように、答えを取得するために、ええと、SQL Server では sql によって各レコードを反復処理し、他のデータベースで答えを取得する、というものです。そしてこれは上の質問からのフォローアップです。なるほど。結果は実際には、ええと、結果は実際には単に、データベース内に保存されている、ええと、エンティティのリストです。

したがって、結果を反復処理したい場合は、そのための full loop を実装すればよいだけです。ええと、でも例えば、質問が、例えば多くのアイテムを検索したい、ええと、そして 101 件目を取得してからさらに 100 件、というようにページネーションのようなものを持てるか、ということなのか気になります。それが質問ですか？コメントが追加されたばかりですか？あー、いいえ。クエリベクトルを反復処理したいそうです。つまり、アイテムのリストやアイテムのデータベースを検索するということです。

ああ、なるほど。そしておそらくそれらを J Doc に入れる。はい。複数のクエリを実行する方法は 2 つあります。1 つの方法は、ええと、単一のクエリのリストを指定してから検索を実行することです。

例えば、ええと、同時に 10 個のクエリを実行したいとしますよね？10 回検索を実行することもできますが、それはそれほど効率的ではありません。ええと、さらに、data をサイズ 10 のクエリベクトルのリストとして指定することもできます。そして 10 個のクエリが、1 回の単一の、1 回の単一の、あー、あー、API 呼び出しまたは操作で同時に実行されます。それからもう 1 つ質問があり、それは、この notebook ではなぜ距離が大きいほどより良い一致を示すのか、というものです。ああ、それは良い質問です。それはこの場合の距離メトリックに依存します。

ええと、私の記憶が間違っていなければ、ここでの距離はコサイン類似度として定義されていて、コサイン類似度では、大きければ大きいほど、より良いです。しかし他のものでは、ええと、たぶんここは推測ですが、ええと、ip では、ええと、短いほど、ええと、その、距離が短いほど、より良いと思います。つまり、それはこの場合に使用した、あー、あー、距離セメ、あー、すみません、距離メトリックに本当に依存します。ありがとうございます。それから、前の質問からのフォローアップも、あー、あります。

読んだかどうか分かりません。うん。ええと、でもそれは尋ねています、先生、10項目の制限はありますか？つまり、10を超える場合は、反復するために何かを分数のようなものに入れる必要があるのでしょうか？基本的には、10の倍数ごとに反復しなければならないのか、ということです。はい、つまり制限があります。たしか、ええと、それが10かどうかは分かりません。10か、または100のどちらかです。

ええと、でも制限はあります。そしてその制限について、たとえば、もし1000個のクエリがある場合、私は、ええと、1000個のクエリを1つの単一の検索リクエストに収められるかどうか分かりません。なので、はい、たとえば一度に100個ずつ処理して、それらを10個のバッチに分ける必要があります。これで質問への答えになっていれば幸いです。ありがとうございます。

ええと、今のところ質問はそれだけでした。質問には答えられたようです。はい。わかりました。はい、ご質問ありがとうございます。

では、ここでより興味深いトピックに移りましょう。いいですね、いいですね、いいですね。ええと、前に述べたように、異なるドキュメントに対して異なるsubjectを定義できましたよね？そして検索中には、すべてではなく、1つの単一のsubjectに関連する結果だけを取得したい場合があります。いいですか？では、ここに異なるsubjectのドキュメントをさらに挿入しましょう。私はさらに3つのドキュメントを作りました。ええと、この場合はbiologyに関連していて、ええと、またmachine learningとaiにもある程度関連しています。

それで、ええと、IDについては、少しインクリメントしたいです。なぜなら、同じ重複したidで異なるコンテンツを持ちたくないからですよね？それでドキュメントをベクトルにエンコードした後、ここでdataオブジェクトを構成しましょう。ええと、過去に使用したもの、たとえば0 1, 2を飛ばすために、IDを2だけ増やします。ええと、vectorフィールド、taxフィールド、subjectも指定します。以前に挿入したベクトルのschemaと同じものに合わせたいのです。ええと、そしてこの全体について、技術的にはこれをentityと呼びますよね？つまりdataはentityのリストを含んでいます、ええと、用語としてはそうです。

これでdataを再度挿入できます。今、この場合、ベクトルデータベースには6つのitem、ええと、すみません、6つのentityがあると思います。そしてfilterを指定して検索できます。唯一異なる部分はfilterです。ええと、同じように、同じcollectionを使い、ええと、queriesもエンコードしました。

ここでは複数のqueriesを指定できます。私は、私は、これをお見せできます、ええと、少しだけ。そして再度、limitを2に指定します。なぜなら、biologyのsubjectにおいて、AI関連の情報を教えてくれるものに最も近い2つの、ええと、2つのドキュメントだけを見つけたいからです。そしてtextとsubjectsだけを返してください。なぜなら、他のものには興味がないからです。

ではこれを実行して、何が起こるか見てみましょう。今、ええと、2つの異なる結果を取得しました。1つは、ええと、biologyとaiについてのものです。もう1つもbiologyについてです。ええと、ここで見て分かるように、ええと、まず第一に、すべてのものはsubjectがbiologyであり、ええと、たとえばhistoryのsubjectではありません。

そして第二に、両方の、つまり上位2つのcontentは、aiに関連しています。私は意図的にこれをDDR ones involving cancersand fibrosisのようにしました。これはaiには関連しておらず、semantic searchの結果には表示されませんでした。これを削除すると、結果は異なると思います、そう信じています。では見てみましょう。ああ、ここで間違えたと思います。

ええと、少なくとも同じidのままではdataを再度挿入すべきではありません。そうしないと重複データができます。ええと、でも大丈夫です。ポイントを見てみましょう。今、結果には、ええと、history subjectとbiology subjectに関連するものが表示されています。clean filterが指定されたのではなく。

はい、基本的なセマンティック検索については、ええと、これで全部だと思います。ええと、ごく簡単に、もし、ええと、他の操作をしたい場合、たとえば検索はしたくなくて、データベースから何かを取得したいだけの場合です。たとえば、ここで history に関するすべてをください、というような場合です。ええと、別のクエリ、ええと、すみません、別の、ええと、ええと、関数である query というものも使えます。これは、ベクトル類似度を考慮せずに、特定のフィルターに一致する結果を、ええと、返すことができます。ええと、ID によってエンティティを直接取得することもできます。

そしてこれらすべての後で、ええと、もしデータを削除したい場合、たとえば biology に関するすべてを削除したい場合です。ええと、コレクションとフィルターを指定することで delete 関数も使えます。そして、たとえば、この、このものを終了した後、ええと、次回、既存のデータを、ええと、メモリに読み込みたい場合は、同じファイル名でクライアントのインスタンス化を指定するだけでできます。この場合、既存のデータはすべて読み込まれます。また、それらが不要であれば、コレクションを drop することもできます。ええと、Milvus Lite での開発を、ええと、終えて、それに満足した後、でもおそらくユーザーが、たとえば 10,000 人から 5 億人に増えたとします。

ええと、よかったですね。ええと、その場合は、よりスケーラブルなバージョンに移行できます。これは多くの場合、Docker または Kubernetes にデプロイされます。スケールする場合、おそらく Kubernetes が必要です。ベクトル検索には、クラスター、巨大なクラスターですね。その場合は、URI をネットワークエンドポイントとトークンに置き換えるだけでよいです。ええと、セルフデプロイしたものがある場合は、ユーザー名とパスワードを指定すれば、はい、他のすべてのコードは Milvus サーバーで動作します。

はい。ええと、この、ええと、このウェビナーでお見せしたいことは以上です。ええと、質問のための時間が、たぶん少しあると思います。はい、ありがとうございます。皆さんかなり感心されています。

ええと、また、ええと、フィルタリングや私たちが持っているさまざまなものにも本当に満足されています。どなたか質問はありますか？もしかして皆さん満足ですか？はい、サポートありがとうございます。ええと、最後に、ええと、ちょっとした、簡単な、ええと、私たちが持っているドキュメントについて手短に見ていきます。最近、私たちは多くの統合ドキュメントを追加しました。私たちの、ええと、お気に入りの、あるいは素晴らしいパートナー向けのものです。ええと、LangChain や LlamaIndex のようなよく知られた名前も含まれています。これにより、この中でも Milvus Lite を使うことができます。

ええと、LangChain の場合は、LangChain の、ええと、ベクトルストア API で、ええと、ローカルファイル名を指定するだけで、Milvus Lite からのベクトルストアを持つことができます。また、OpenAI や Voyage AI の、ええと、多くのモデルプロバイダーと一緒に使うこともできます。そして、それらを組み合わせてセマンティック検索、RAG、または画像検索を構築する方法の例を示しています。また、ええと、ごく最近、私は Display というプロジェクトがあることに気づきました。これは非常に人気があります。ええと、Display との統合もあります。そこでは、ええと、Mul RMin Buy と呼ばれる Milvus の抽象化を使うことができ、これは、ええと、Milvus Lite と Milvus、ええと、サーバー、Docker、Kubernetes の両方で動作します。

ああ、ありがとうございます。ええと、はい。私は今、参加者からの質問に直接答えています。ええと、内容は主にミートアップについてです。ええと、サンフランシスコでのミートアップは配信していますよね？直接配信されています。

ええと、はい、そうでなければ録画されています。そして、ええと、常に YouTube にあります。はい。ミートアップについては、ええと、ミートアップの録画と配信があります。ええと、過去のミートアップの、その、そのコンテンツを確認したい場合は、ええと、私たちの YouTube チャンネルをご覧ください。今後のミートアップに向けて、素晴らしい録画がすべてそこにあります。

ここで RSVP できます。ええと、ライブ配信があります。ええと、Twilio 上で、だったと思います。はい。はい。そして、はい、録画は共有されます。ええと、コードも共有されます。

つまり、コードはすでにドキュメント上で直接入手できるので、コードが欲しい場合は、ええと、そこに直接行ってもらっても大丈夫です。でも、以上だと思います。ええと、ウェビナーにご参加いただき、すみません、そしてvis lightsをお見せできて、どうもありがとうございました。そうですね、皆さん、ええと、ウェブサイトvis ioをチェックしてください。GitHubも直接チェックしてください。そして、ええ、Elvisによるpeep installedみたいな感じでやってみてください。

自分のマシンで思いっきりやってみてください。もう一度ラップトップを壊してください。はい、ぜひ、ぜひ試してみて、どんな感じで、どのように動作するか教えてください。はい。それから、ええと、もしできれば、GitHubでスターを付けていただけると、これに素敵な追加になります。

それから、私たちは、ええと、Pro Product HuntでS Lightのローンチを発表しました。そして今日は、更新してみると、ランキングが、ええと、そうですね、17位、ええと、です。でも、そこでアップロードをしていただけると、リンクを、ええと、チャットに含めたリンクですが、それは素晴らしいです。ご支援、本当にありがとうございます。どうもありがとうございました。皆さん、ありがとうございました。

素敵な朝、午後、夕方をお過ごしください。どこにいても、そして次回お会いしましょう。バイバイ。

Meet the Speaker

Join the session for live Q&A with the speaker

Jiang Chen
Head of Ecosystem and Developer Relations
Jiang is currently Head of Ecosystem and Developer Relations at Zilliz. He has years of experience in data infrastructures and cloud security. Before joining Zilliz, he had previously served as a tech lead and product manager at Google, where he led the development of web-scale semantic understanding and search indexing that powers innovative search products such as short video search. He has extensive industry experience handling massive unstructured data and multimedia content retrieval. He has also worked on cloud authorization systems and research on data privacy technologies. Jiang holds a Master's degree in Computer Science from the University of Michigan.