Join the Webinar
Loading...
セッションについて
多くのLLMで強力なマルチモーダル機能が急速に増えています。このチュートリアルでは、テキストと画像のデータセットを同じ埋め込み空間にベクトル化し、Milvusに保存し、LLMクエリに対して関連するすべてのデータを取得し、マルチモーダルデータをコンテキストとしてGPT-4oに入力します。
扱うトピック
- マルチモーダル埋め込みモデル
- Milvusマルチベクトルハイブリッド検索
- マルチモーダル生成モデル
- MilvusとZillizを使用したマルチモーダルのデモ
本日は、Melva と GPT-4o によるセッション Multimodal Rag、そしてゲストスピーカーの Jung Chen をご紹介できることをうれしく思います。Jung は Zillow の AI プラットフォームおよびエコシステムの責任者です。彼はデータインフラストラクチャとクラウドセキュリティにおいて長年の経験を持っています。Zillow に入社する前は、Google でテックリードおよびプロダクトマネージャーを務め、革新的な検索プロダクトを支える Webscale Semantic Understanding and Search、そしてショート動画検索などを支える検索インデックスの開発を主導しました。彼は、大規模な非構造化データとマルチメディアコンテンツ検索を扱う豊富な業界経験を有しています。
彼はまた、クラウド認可システムやデータプライバシー技術に関する研究にも携わってきました。Jung は University of Michigan でコンピューターサイエンスの修士号を取得しています。ようこそ、Jung。こんにちは。ご紹介ありがとうございます。
Amli、ええと、ここに来られて本当にうれしいです。ええと、まず、簡単に自己紹介します。ええと、私の名前は Jung で、検索およびデータインフラストラクチャのバックグラウンドがあります。そして現在は、vus のエコシステムと開発者体験に取り組んでいます。ええと、こちらが私のメール、LinkedIn、Twitter です。
ですので、もしよろしければ、ええと、ソーシャルチャンネルで、ええ、私をフォローしてください。後ほどつながってお話しできれば、ええ、本当にうれしいです。さて本日の、ええと、私の共有内容は、MIL と GBT four Oh による Multimodel RAC についてです。ええと、聴衆の多くの方は rac について聞いたことがあると思います。Multimodel rag はまだ少し新しいものですが、ここ数か月で、ええと、大きく進化しています。
そして zills では、ええと、私たちは vus と呼ばれる高性能で高信頼性の bacteria database の作成者です。また、ええと、zills Cloud も提供しており、これはクラウド上で完全に管理された VUS です。ええと、そのため私たちは Multimodel Rack に関して多くの研究と実験を行ってきており、これが多くのお客様のユースケースに適用されているのを見てきました。そこで本日は、Multimodel に関する背景と歴史、そして特に Multimodel をめぐる情報検索について共有します。その後、VUS で動作する Multimodel Rack の簡単なデモを行います。
それでは早速、トピックに入りましょう。Multimodel について話すには、情報検索について話す必要があると思います。なぜなら、これは Multimodel がこれほど興味深いものになっている理由の、いわば出発点だからです。ええと、マルチモーダル環境での情報検索は clip から始まったようなもので、これは、ええと、テキストモデルの情報と画像モデルの情報の両方を同じ意味的な、ええ、潜在空間に埋め込むことができるアーキテクチャです。そしてこのアプローチを使うことで、たとえばテキストで画像を検索でき、またその逆、つまり画像に基づいてテキストを検索することもできます。
このアプローチの背後にある考え方は、テキストエンコーダーと画像エンコーダーを同じライトスペースにほぼ整列させることでした。そして、ええと、これに先立って存在したのは、ええと、機械学習モデル、より具体的にはディープラーニングモデルで、画像を異なる意味に分類できるものでした。しかし、その制限は、分類先として、ええと、有限のリストの、ええ、ええ、カテゴリーしか事前定義できないことです。例えば、cat car dog と限定された意味リストを定義できます。そして、分類器が、この写真が犬や猫にどれくらいの確率で見えるかを検出できるように、モデルを訓練できます。
しかし、これには実務上あまり柔軟ではないという制限があります。多くの場合、私たちは出発点となるような事前定義されたセマンティクスのリストなしに、画像のセマンティクスを知りたいだけです。そのため、いくつかのスマートで慎重な学習テクニックによって、CLIPモデルは、ええと、テキストエンコーダーと画像エンコーダーを整列させ、具体的には両方のモデルが生成したベクトル埋め込みを同じ潜在空間にそろえることができます。その結果、テキストの一部と、ええと、何かの写真の背後にある情報またはセマンティクスが同じであれば、それらは潜在空間内で非常に近い、ええと、ええと、距離を持つことになります。ええと、私の理解では、このアプローチは必ずしも画像の背後にあるセマンティクスの本質を捉えるものではなく、むしろ2つの分布を1つに整列させているだけに近いものです。ええと、そしてこのアプローチのもう一つの制限は、他方の検索、ええと、1つの次元の検索しかサポートしていないことです。ええと、1つの情報モダリティからの検索しかサポートしていません。
例えば、ええと、もしテキストの一部と画像を組み合わせて検索したい場合、ええと、この、このアーキテクチャでは、ええと、それはできません。これを基盤として、テキストと画像情報の両方で情報検索をどのように行うかについての改良や新しい研究が進められてきました。そして、ええと、すみません、次の段階の情報、ええと、マルチモデルによる情報検索に進む前に、ええと、CLIPで何ができるかの具体例がここにあります。つまり、画像が与えられると、例えば、その画像を一連の、ええと、セマンティクスに分類し、最も高い確率を持つ、ええと、正しいセマンティクスだけを出力できます。
ええと、例えば、この、ええと、飛行機の写真と、鳥の写真、車の写真、ええと、といったセマンティクスのリストとの近さについて、このモデルは、この写真の、ええと、ベクトルを、ええと、「飛行機の写真」というテキスト片に整列させるように学習されており、そしてそれらが他の、ええと、誤ったセマンティクスよりも潜在空間内で最も近い距離を持つようにします。ですので、ええと、前述したように、ええと、このアプローチは、ええと、画像またはテキスト、あるいはさらにテキスト＋画像データのセマンティクスを本質的に把握できるものというよりは、分類器を学習しているようなものです。そして、この、ええと、このモデルに関するもう一つのニュアンスは、このクロスモダリティ検索を行うために実際には2つのモデルが必要だということです。ええと、テキストは、ええと、テキストモデルで埋め込み、画像は画像モデルで埋め込む必要があります。たとえそれらが一緒になって、CLIPモデルのペアを形成しているとしてもです。
そして、そのため、より新しいアプローチでは実際に、ええと、画像とテキストデータのエンコーディングを両方組み合わせ、ええと、さらにいくつかの、ええと、よりスマートな、ええと、学習テクニックを適用して、ええと、モデルがそれらの情報の背後にあるセマンティクスをよりよく把握できるようにしています。ええと、このモデルの表現の一つは、ええと、Vistaと呼ばれています。ええと、そしてこのアプローチで学習されたモデルはvisualized bgeと呼ばれています。ええと、これはある研究機関によって行われた研究であり、この新規性は、以前のアプローチと比較して、テキストと画像データの深い融合を確立できる点にあります。ええと、これは実際に画像とテキストの両方からの情報を融合できますし、ええと、ご存じのように、画像データのみ、またはテキストデータのみでもある程度機能します。
ええと、そしてこれに関するもう一つの特性は、それが、ええと、このモデルアーキテクチャで利用している、ええと、汎用テキスト埋め込みの強力な性能をある程度保持していることです。ええと、ここにモデルアーキテクチャの視覚的な図があります。つまり、ええと、典型的な例として、ここではマルチモデルデータと呼んでいる画像とテキストデータの両方が与えられます。画像データについては、vision transformerエンコーダーを使用して、この画像の、ええと、トークン表現を抽出します。つまり、ええと、これの比喩、これの類推としては、ええと、同じ情報を持つ画像をテキスト表現に変換するようなものです。
正確に言うとそうではありませんが、ある程度は、ええと、画像をピクセルの集合として表されたものからトークンの集合へ変換するようなことをしています。そのトークンは実際には、ええと、ええと、あの、事前学習済みのテキストエンコーダーが実際に理解できるトークンによって表現される情報を含んでいます。そしてテキストデータについては、特別なことは何もなく、通常のテキストトークナイザーを使ってテキストをトークンの集合へトークン化するだけです。そしてここで、ええと、あの、魔法のようなのは、視覚コンテンツのトークンと、自然言語で表現された、ええと、テキストコンテンツのトークンを実際に連結し、そのうえで事前学習済みのテキストエンコーダーを使ってこの情報を1つの単一ベクトルへエンコードすることです。そしてこの後に生成されるものは、画像とテキストの両方の背後にある意味をある程度把握します。さらに、画像とテキストの意味をある程度組み合わせることで、この、ええと、画像とテキストを組み合わせた検索を行えるようになります。
ええと、このアーキテクチャによって、clip の制限を克服します。clip はモデル自体はある意味、あの、クロスモダリティであるにもかかわらず、1つのモダリティのデータしか受け付けることができません。そして、ええと、ここで使われているテキストエンコーダーは汎用のテキスト埋め込み、ええと、モデルなので、ええと、世界の中のあらゆるものの意味を理解する優れた能力を、ええと、継承することもできます。つまり、画像とテキストの埋め込みエンコーディングを機械的に整列させるだけではなく、実際に、ええと、は、あの、あの、画像とテキストの背後にある意味を理解するうえで、より良い仕事をすることができます。そしてここに、このモデルの能力についての具体的な例があります。これはまた、あの、学習データが、ええと、オフラインでどのように生成されるかを示す図解でもあります。
ですが、ええと、ここでこの例を見てみましょう。つまり、ええと、このモデルの目的は、テキストの断片が与えられたときに、それが、あの、この画像に関連しているか、あるいは、ええと、ある種の、ええと、この画像をどのように追加したいかを説明する情報であり、その結果、ええと、検索された結果が編集後の画像のように見えるようにすることです。つまりこの例では、実際にはこの画像を説明しているだけで、あの、あるアーティストによる、バルコニーにいる男性、ええと、mito print として説明しています。ええと、これをそのまま、ええと、visualized BG モデルに入力すると、実際には、ええと、この画像に似たものを検索します。なぜなら、基本的にそれらは同じことについて話しているからです。
ええと、実際には追加の情報は何も加えていません。ええと、なのでそれほど面白くはありません。面白いのは、もし画像が実際に説明されている、あ、すみません、もしテキストが実際にはこの画像とは少し異なるものを説明しているけれども、この画像にも関連している場合です。つまり、ええと、このモデルの目的はそのような種類の情報を検索することであり、学習も、つまり学習データの構築もこの原則に沿うようになっていて、そのために、ええと、大規模言語モデルと、ええと、私たち、あの、そして、視覚コンテンツ生成技術を使って合成データを構築し、ええと、学習を助ける、ええと、学習データセットの構築を助けます。つまりこれは、ええと、まずキャプション付きの、ええと、画像のリストを収集することで行われ、そのキャプションは、あの、画像が何についてのものかを説明します。
これは既存のデータセットから来ており、その後、ええと、プロンプトの一部を開発し、それによって、ええと、大規模言語モデルが画像に関する内容を変更する際に創造的になれるようにします。たとえば、この、この例では、変更された情報は、ええと、やはりバルコニーにいる人物ですが、鳥の群れがいる、というものです。つまり、ええと、これによって、この情報に関する、ええと、別の合成画像を生成します。そしてそれを扱い、さらに大規模言語モデルを使って、ええと、新しい画像キャプションを編集指示へ要約し、ある程度簡略化して短くし、その後フィルターを使って、実際には意味をなさないものを取り除きます。そして残るのは、コンテンツの一部と、画像が何についてのものかを説明する画像からなる合成データセットです。
つまり、この訓練データを構築する技術では、ええと、訓練用の大量の、ええと、サンプルを生成することができます。そして、このような大規模な、ええと、この、この大規模なサンプルがあって初めて、最初に設計した仕事、つまり、ええと、画像の説明と、その、画像そのものの両方に基づいてコンテンツを取得するという仕事を、信頼性をもって、ええと、実行できるモデルを訓練することが可能になります。これはマルチモーダルにおけるアプローチの1つです。もう1つのアプローチは、ええと、最近Googleによって開発されたもので、ええと、議論の余地はありますが、さらに、さらに、ええと、印象的な結果を出しています。そしてそれは、ええと、ええと、公開WebからデータをスクリプトしてWebスケールのデータを利用し、その後データマイニングを行って、ええと、訓練データサイトを生成することで、訓練技術を適用しています。
ええと、訓練技術については、ええと、少し後で説明しますが、まずはこのモデルからの、いくつかの印象的な結果を見てみましょう。つまり、同様のアイデアとして、クエリ画像と、ええと、自然言語で表現された指示が与えられると、両方の、ええと、両方のモダリティからの情報の組み合わせを表現できる、ええと、画像を見つけることができます。最初の例は、ええと、まったく同一の画像を見つけたいというもので、これは、ええと、ほとんど、私は、私はこれに対して編集指示を一切出したくない、というものです。そして、それはまったく同じ画像を取得できます。ええと、つまり、これは、かなり良い、ええと、ベースラインを持っていることを示していて、面白いことは何もしていないのですが、興味深いのは、ええと、その帽子を世界一高い建物と比較せよ、という指示が与えられると、実際に、類似した、ええと、建築物、類似した建物の高さ比較を示す画像を取得できるということです。
そしてこれは、他の、ええと、マルチモーダル検索技術と比べて非常に印象的です。他のものは、ええと、つまり、これはただ、これに似て見える、ええと、別の、ええと、個別の建物を示すだけで、それもスクラッチ、スクラップ、スクレイパーです。しかし、ええと、これは、画像とテキスト情報の両方の、ええと、組み合わせに対する意味的な近さという点では、これほど近くありません。そしてこれは、ええと、さらに印象的で、ええと、モデルに何かを見つけるよう指示しています。ええと、この建物の内側から見た、ええと、その、ええと、写真です。正確にこの、ええと、この、ええと、この高級ホテルからの眺めの写真があるかどうかはわかりませんが、しかしそれは、同じ建物のように見えるけれども、ええと、その建物を外側から見ている、ええと、このような情報を、ある程度排除できているように見えます。
そして次のもの、ええと、これは実際にここにある情報の本質の一部を掴んでいる、把握している、ええと、あるいは何らかの知性を持っていると思います。ええと、それは他の観光名所を見つけるというものです。ええと、この、このホテルはUAEにあると思うので、これは、ええと、おそらくPalm Islandsで、ええと、UAEの有名な観光名所の1つです。したがって、これにより、このモデルは実際に、ええと、推論において、また、ええと、画像と指示の両方の背後にある意味を、かなりよく理解するような、ある種の知性を持っていることを示しているように思えます。ええと、そして、ええと、このようなモデルを訓練するためには、相当量のデータが必要であり、それは、ええと、手動でラベル付けされたもの、あるいは、ええと、worldwideのような、ええと、より大きなデータセットからマイニングされたものです。ええと、そこでGoogleは実際に、ええと、Webスケールのデータを管理する深い専門知識を活用しています。
つまり、彼らが訓練例を構築する方法は、まず、ええと、公開されている、ええと、ウェブページ、HTMLをいくつかクロールし、それから同じウェブページ内の画像を抽出するというものです。なぜなら、それらは同じウェブページ、ウェブページ内にあるので、意味的に互いに近い、または互いの間に何らかのつながりがあるからです。そしてそれは、ええと、うーん、ええと、vision log、ええと、vision、視覚大規模言語モデルを使って、ええと、すみません、指示を生成するのですが、つまり、大規模言語モデルを使って、ええと、この、このウェブページ内のテキスト記述を理解します。したがって、すべての情報が同じウェブページ内に存在することを考えると、そのテキストは、同じウェブページに現れる2つの画像の関係を説明している可能性が非常に高いのです。ですのでこの場合、ええと、これは実際に、その、ウェブページからテキスト片を見つけることができ、そのテキスト片は、下のページ、ええと、下の写真がバッテリー、または充電器であり、実際には上のカメラの、カメラの充電器であることを説明しています。そしてそれは大規模言語モデルを使って、ええと、オレンジ色のウェブページからの、ええと、そのテキスト片を言い換え、ええと、要約し、ええと、どのテキスト片で説明される、ええと、指示を生成します。
そしてこの下の、ええと、この上のページを、あなたは、ええと、うーん、ええと、人間なら下の、ええと、写真に参照させることができます。そしてこのプロセスはその後、大規模に、全体の、ええと、世界中をスクレイピングし、ええと、より高度なグルーピングとクリーニングを行うことによって実行されます。そうすることで、類似した、ええと、類似した意味を持つ画像がまとめられ、そして前述のように、ええと、指示が生成されます。そして最終的には、大量の高品質な訓練データを生成できるようになります。それは、ええと、この、この例で見ることができるように、ええと、どのような、ええと、種類の変換または編集によって、右の、右の画像が、ええと、左の画像に一致するか、またはその逆を説明するものです。そして訓練段階では、ええと、その、ええと、左の画像と指示を使って、ええと、右側の画像を見つけます。
そして、ええと、補正と大規模な訓練によって、この情報を、ええと、言語へ、ええと、ええと、この仕事を達成できる、ええと、招待モデルへ蒸留することができます。つまり、これは、ええと、ええと、マルチモデル検索の背後にある理論のようなものです。そしてこれを現実、または本番環境に適用するには、実際には、ええと、それらのマルチモデル、多くのモデルから生成されたベクトルを保存し、それらを大規模に効率よく検索できるインフラストラクチャの一部を、ええと、見つける必要があります。ええと、さらに、私たちは、ええと、この情報検索段階を大規模言語モデルの生成段階に適用できます。ええと、いわゆる検索拡張生成アプローチです。ええと、ただし典型的な、ええと、従来の検索拡張生成は、ええと、テキスト情報のみを検索し、それを大規模言語、ええと、大規模言語モデルへ送るのに対して、ええと、このアプローチは実際に、ええと、画像情報を検索し、それを視覚言語モデル、またはマルチモデル大規模言語モデル、大規模タイムリモデルへ送り、それから興味深い、ええと、ええと、アプリケーションを行うことができます。
それで、ええと、ベクトルの保存と検索に関しては、ええと、vuを使うことができ、これは、ええと、2つまたは4つ、2つのデプロイ形態のようなものを提供します。ええと、軽量なmill lightがあり、これはラップトップやノートブック上にローカルにデプロイできます。そして今日のデモでは実際にmul lightを使って、ええと、この画像、ええと、ええと、マルチモデル検索とマルチモデル生成を紹介します。また、より高性能な、ええと、DockerおよびKubernetesデプロイメントもあり、さらにこのクラウド上の完全マネージドmulもあります。これは、より大規模な検索、ええと、ええと、ワークフローにより適しています。そしてMills、ええと、プロジェクトはracの多くのフレームワークとも統合されています。
ええと、たとえば、LAMA Index には、ええと、ええと、マルチモデル検索の、あー、コンポーネントがあり、オープンソースコミュニティの、ええと、フレームワークと連携することで、ええと、より包括的なレコメンドやその他の AI 搭載アプリケーションを開発しやすくなります。ええと、いったん、あー、いったん、あー、インフラストラクチャスタックを選択したら、マルチモデル情報をデータベース、あー、VU vector database のようなものに適合させられるデータモデルを設計する必要があります。そして、このモデルを設計する方法は 2 つあり、どのようなモデルを使用しているかによって異なります。たとえば、ええと、単一モダリティの埋め込みモデルを使用している場合でも、ここでハイブリッド検索技術を適用することで、このワークロードを実行できます。その仕組みは、実際には画像とテキストのベクトル埋め込みを別々に保存するというものです。
そしてこれは、ええと、その、そのベクトルは、ええと、2 つの埋め込みモデルによって生成できます。この場合、たとえば、視覚コンテンツだけを理解できる vision transformer を持つことができ、その後、従来のテキスト埋め込みモデルを使って、ええと、テキスト情報を埋め込むことができます。あるいは clip を使って、それらを別々の、ええと、ベクトルフィールドに保存することもできます。そして検索時には、実際に、ええと、対象情報を埋め込みます。たとえば、あー、2 つの対象情報を持つことができます。
1 つは、あー、テキストで、もう 1 つは、画像の、あー、画像です。そしてそれらを別々に埋め込んで、それから 2 つのクエリベクトルを持ち、その 2 つのベクトルフィールドに別々にクエリをかけることができます。そしてそれらを、ええと、相互、ええと、reran function や、あー、weighted rerun curve のようなマージ技術によって結合します。そしてそれらを 1 つの単一リストにマージします。ええと、つまり、たとえば、ええと、ええと、あー、RF によってマージし、ID のリストを得ることができます。そしてその情報を使って、ええと、それらを組み合わせて、それを、ええと、あなたの、ええと、あなたの、あなたの u あー、アプリケーションの、あー、ui に表示することができます。あるいは、あー、それらをさらに、ええと、マルチモデル大規模言語モデルに送って、他の理解を行うこともできます。
もう 1 つの技術は、実際には、ええと、テキストと画像の、ええと、情報の両方を入力として受け取り、それらを、あー、1 つの単一ベクトルに埋め込むことができるマルチモデルモデルを使うことです。つまり、このベクトルは実際には、あー、両方の情報の背後にある情報や意味を組み合わせています。そして検索時には、もう、あー、ハイブリッド検索を行う必要はなく、ええと、同じモデルを使って、ええと、クエリ画像とクエリテキスト片を埋め込みモデルに渡し、1 つの単一クエリベクトルを生成して、それから Vos で単純なベクトル検索を行うだけでよいのです。ええと、これの少しのバリエーションとして、clip モデルを使う場合があります。これは技術的には、技術的には 2 つのモデルなのですが、ええと、それでもこれを行うことはできます。ただし、ええと、この、ええと、それぞれのエンティティの識別子を定義する際には、少し注意が必要です。たとえば、ええと、あー、このデータ構造は、ええと、どちらかというと、ええと、1 つのフィールドがあり、それは image RL か text のどちらかです。
そして、ええと、画像とテキストをほぼ 2 つの異なる、あー、情報として扱い、それらを別々の、あー、別々の行に保存できます。そして各行について、それはテキストまたは画像のいずれかのベクトルになります。そして検索時には、単一フィールド、あー、単一のベクトルフィールドに対して検索することができますが、返される結果はアプリケーションによってはテキストまたは画像のどちらかになる可能性があります。これは実際には理にかなっていますが、ええと、データ構造設計をアプリケーションの要件に合わせるよう注意してください。はい。
では、ええと、ライブデモに入る前に質問を確認させてください。ええと、はい、ここは大丈夫だと思います。1 つだけあります。ええと、たぶんそれは、あー、pre-trained という意味だと思います。事前学習済みのテキストエンコーダは、画像とテキストの両方の意味をどのように理解するのですか？はい。
ええと、トレーニング段階に少し戻ると、つまり、ええと、それは、つまり、トレーニング段階では、実際には、ええと、テキストと画像を理解する能力があるとは言いません。実際には、分布を整列させるというトレーニング目的を通じて、ええと、症状をたどることで、まるで理解している、ええと、画像とテキストの間の意味を理解する能力があるように見えるのです。では、ええと、この背後にある直感を少し説明します。つまり、ええと、膨大な量の例を見ることで、人間は何かを学ぶことができるのと同じように、ええと、大規模言語モデル、すみません、その、その、その、ええと、深層ニューラルネットワークモデルのトレーニング、ええと、プロセスは、ええと、このプロセスをある種模倣しているのです。ええと、つまり、トレーニングデータが、ええと、ラベル付けされた出力を、その、入力に整列させている限り、たとえば、トレーニングデータはモデルにだいたい、よし、hold、ええと、これはこう見える、と伝えています。
つまり、この画像、水の中の島であるこの画像について、ええと、このテキスト片、ええと、同じ島、夕日のとき、あなたはこの画像を指し示すべきだ、ということです。ですから、これを繰り返し行うだけで、画像とテキストの両方の背後にある意味を理解したように見える状態に、ある種近づくことができます。つまり、このプロセスは深層ニューラルネットワークにおけるあらゆる種類のトレーニングに、ある程度一般的なものです。これで特別なのは、モデルアーキテクチャを設計して、入力として2つの情報を受け取り、その出力を、ええと、入力情報の1つのモダリティだけでなく、2つのモダリティの両方からの情報の組み合わせに整列させることができるようにしている点です。これでこの質問への答えになっているかはわかりません。
ええと、遠慮なく、ええと、q and aで追加の質問をしてください。では。ええと、ここで、ええと、デモに移ります。ええと、よし、セットアップします。ええと、これを事前に実行して、あまり長く待たなくて済むようにします。では、ええと、このデモはマルチモデル検索を行うためのものです。ええと、この例では、ええと、画像があり、これは、ええと、猫の写真で、それから、テキストの指示があり、それはこの画像のテーマに合うイヤホンを見つける、というものです。
そして、それは、ええと、入力の両方からの意味を組み合わせたものを検索でき、具体的には、その、これは検索から返された2番目に良い結果だと思います。実際には、ええと、猫耳の付いたヘッドサイド、まあ、のペアです。ですので、ええと、ここでの意図に非常に近いです。ええと、そしてこのデモでは、このような、ええと、マルチモデル検索をどのように実装するかを示します。そして、ええと、ええと、最後に、GPT-4 ohに再ランキングをさせ、結果をさらに強化して、ええと、望ましい、ええと、対象結果が実際に結果の中で1位にランクされるようにします。
そして GBT four oh は、ええと、検索品質をさらに強化するのをある種手助けできます。ええと、何かをする前に、vis のクライアントライブラリである vus を含む依存関係のベンチと、画像を処理し、inviting モデルの重みをダウンロードし、その後推論を行うために使用する他の、ええと、ユーティリティをインストールします。では、まず、ええと、この例では、以前紹介したBGE visual、ええと、モデルを使用します。そしてこのモデルで、ええと、このモデルで推論を行うには、この flag embedding、ええと、フレームワークをダウンロードする必要があります。これはこのモデルの便利なラッパーです。また、いくつかの、ええと、画像、ええと、画像データ、ええと、検索したい対象候補の、ええと、その、ええと、ええと、プールとして、ダウンロードする必要があります。ええと、ここでは公開されているAmazon reviewsデータサイトをダウンロードします。
ええと、さらに、ええと、b BG visualizedモデルの、ええと、重みもダウンロードする必要があります。ええと、ご覧のとおり、このモデルはそれほど大きくなく、約300〜400メガバイトです。では、すべて揃ったので、ええと、エンコーダーを構築しましょう。これは、ええと、テキストと画像情報を単一のベクトル埋め込みにエンコードするために使われるものです。ええと、これは先ほどダウンロードした、ええと、BG visualizedモデルを使用します。ええと、正式には visualized BG English way 1 と呼ばれます。
- これでデータをロードできるようになりました。これを試してみます。はい、ここでは、このデータセットから900枚の画像をサンプリングし、その後このBGE visualizedモデルを通じてベクトル埋め込みを生成しています。そしてこれらが生成されると、すべての埋め込みモデル、ええと、すべての埋め込み、つまりベクトル埋め込みをVUSベクトルデータベースに保存します。
ここで起きていることは、実際には画像フォルダを読み込み、それから900枚の画像をサンプリングしているということです。そしてこれは encoder image で、flag embeddingフレームワークの抽象化です。はい、すべての埋め込みが生成されメモリに保存されたので、これらをmillベクトルデータベースにロードできます。ここでは実際にmill lightを使っています。これはかなり便利で、ローカルファイルを指定するだけで、データをローカルファイルに永続化してくれます。そして、それ以外には、データを保存したいベクトルコレクションを定義する以外、ほとんど何もする必要がありません。
それから、データを取り込むだけです。では実行してみます。まず、このように動きます。ご覧のとおり、900個のbintsを取り込むのはかなり高速です。なので、それほど大きな負荷ではありません。meals lightを起動するには、Mvuからmill clientをインポートし、それからベクトルの次元、ベクトルを保存したいコレクション名など、いくつかのパラメータを定義します。そして、mul demo dot dbというローカルファイル名のファイルを使ってmills clientをインスタンス化するだけです。
そして、この新しく作成されたMills clientを使って、指定した名前と次元でコレクションを作成できます。またここでは dynamics、ええと、di dynamic field も有効にします。これはメタデータを保存するために使われます。より効率的なメタデータフィルタリングが必要な場合もあります。たとえば、何かに対してセマンティック検索をしたいけれど、条件を満たすものだけに限定したい場合です。たとえば公開時刻が何かより大きい、または著者が誰かである、というような条件です。その場合は、dynamic fieldを無効にして、スキーマを定義できます。正式には、はい、このようなデータモデルを定義できます。
たとえば publish timestamp をスキーマ内で定義できます。そして、Scala index と呼んでいるものを作成します。これは非ベクトルフィールドのインデックスです。そして検索を行うときに、何かのセマンティック類似度が欲しいが、published timestamp が何らかの unique ebook より大きいものだけを指定したい、というように指定できます。そして together index を持つことで、これはこの dynamic schema と比べて非常に効率的に実行できます。dynamic schema には、この scatter index が実際にはありません。ただし利便性のために、ここではこの方法で進めましょう。そうすれば、スキーマを正式に定義するのを省略でき、その後、先ほど生成したすべてのベクトルを使ってこのクライアント上で insert を呼び出し、コレクション名を指定するだけで済みます。これで、900個すべてのベクトルがすでに取り込まれました。
はい、これでベクトルデータベースに保存されたデータに対して、マルチモーダル検索を行う準備ができました。では、leopard の画像を選択し、instruction を「この画像のように見える ear form が欲しい」と定義します。そして、このテキストと画像の両方の情報を、multimodel inviting model でエンコードし、単一のベクトルを生成できます。そして、この単一のベクトルをターゲットベクトルとして使い、VUS search APIを使って検索を実行できます。それ以外には、検索のためにいくつかのパラメータを指定するだけです。たとえば、スキーマ内のどのフィールドをこの検索で返したいか、ということです。この場合、私たちが関心があるのは image path で、ここにあります。
私たちは、ええと、それを画像の識別子として扱い、そして limit、つまり、ええと、top K を定義するもので、検索に返してほしい結果の数です。ええと、この場合、9 というのは、ターゲット画像にセマンティックな意味で最も近い 9 つの、ええと、候補画像、ええと、画像が欲しいという意味です。そして search parameters を定義できます。これはベクトル検索におけるかなり細かい詳細で、ええと、たとえば、ええと、metric type で、co-signed にしたいです。ええと、ip のような他の metric type もあります。ええと、これで必要なのは、結果を、ええと、検索結果から、ええと、取得された画像を抽出して、それらを表示するだけです。
ではここで、実行してみましょう。するとこれは画像を、ええと、ええと、画像とテキストによって定義された、ええと、ものにセマンティックに類似した上位 9 枚の画像の image pass を出力します。ええと、それが何か見てみましょう。ここでは、ええと、画像を 5 by 5 の Panera、ええと、pan、ええと、panoramic、ええと、view に結合し、さらにターゲットとして使っている画像も表示します。ええと、もう一度実行しますが、ええと、見た目はこんな感じです。
ええと、左のヒョウは、ええと、実際には 3 by 3 の、ええと、Panera view、ええと、view です。つまり左側がヒョウの画像です。右側は上位 9 枚の画像で、この、ええと、画像のように見えますが、同時に、ええと、イヤホンのセマンティックもある程度持っています。もう一度実行してみましょう。はい。
ええと、はい、ええと、ライブデモで面白いことが起きました。実はデータを 2 回 ingest してしまったので、結果に重複が見えています。見てみましょう。修正する時間はあるかな？実は、修正したいです。やってみます。
ええと、ここでは別の、ええと、たとえば 2、ええと、別の、ええと、persistent file を定義してハックします。つまり、これはほぼ別の mailbox market Davis を作成しているようなものです。そしてもう一度 ingest するので、ええと、重複はなくなります。では、もう一度実行してみましょう。はい、できました。
ええと、9 枚のユニークな画像があります。これはここでのセマンティックの組み合わせのように見えますが、ただし、ええと、少し詳しく見ると。ええと、つまり、ええと、そのうちいくつかは、ええと、ターゲットにより似て見え、いくつかはそうではありません。たとえば、これは、ただの、ヘッドセットのペアのように見えるだけで、特別なものは何もなく、ヒョウに関連するものもなく、あの派手な模様も本当にありません。なので、ええと、GPD four oh を使って re-ranking をしてみましょう。ええと、GBD four oh は非常に知的で、この、ええと、ええと、画像情報の背後にあるセマンティックを理解できるという意味で優れています。
そして実際に、私たちは、ええと、ターゲット画像と、ランキング付きの画像のサイト、ええと、を含む 1 つの画像を構成しました。そしてそのため、この、ええと、大規模言語モデルへの指示では、テキストと画像の両方へのセマンティックな近さに基づいて、ええと、re-ranking を行うように伝えています。そして、ええと、inch four、G PT four が、ええと、ええと、このワークロードでどのように動作するか見てみましょう。ええと、コードの大部分は実際には、ええと、G PT four をトリガーするためのものです。そしてここで、ええと、ええと、興味深いのは、ええと、種類、つまり、ええと、背景を説明する情報が与えられ、モデルに対して、最も適したものから、ええと、最も適さないものまでのインデックスの新しいランク付きリストを提供するように具体的に伝えている点です。
そしてこれで、ええと、大規模言語モデルからの、ええと、この生成を行い、さらにここで結果も表示してみましょう。実際にはこれが返ってきますが、このケースではそれほど印象的ではありません。ええと、そして生成の背後にはある程度のランダム性があるので、2 回目では、ええと、どう動くか見てみましょう。ただし今回のものについて、ええと、ここで達成しようとしている目的がどのようなものか見てみましょう。つまり、私たちは、ほぼ GPT four oh に推論を行わせています。
ええと、左側の画像の意味をあなたが理解したうえで、右側の9枚の画像をランク付けし、その理由を示します。大規模言語モデルへのプロンプトで少しトリッキーなテクニックの一つは、いわば声に出して考えさせると、たいてい推論が少し良くなるというものです。なので理由も示してくれます。つまり、ええと、最も適切なものは2番だということです。それは、ええと、ご存じのように、よりinfoのように見えるし、それから、ええと、画像からの情報も保持しているからです。ええと、全部は読みません。
ではこれを再生成してみて、ああ、実際にはここで再生成しましょう、ええと、ここで再生成して、2回目にどのように動作するか見てみます。はい。今回は少し違う結果を出していて、私は、ええと、最初のものより良いと思います。つまり、ええと、言語モデルの性能という点では、必ずしもそれほど安定しているわけではないということです。ええと、ただ今回はより信頼できる結果を出しており、ええと、つまりこのパターンは、議論の余地はありますが、ヒョウの皮膚の模様にかなり似ています。
そしてこれは間違いなく、イヤホンのペアです。もう一度生成したら、おそらく違う結果になると思います。はい、まだ同じものです。ええと、では、少しこれで遊んでみましょう。クエリを別のものに変えてみます。
ええと、前回はイヤホンについて話していましたが、ええと、今回は、ええと、スマホケースについて確認してみるのはどうでしょう。ヒョウの模様のように見えるスマホケースが欲しいのですが、ええと、それは動物ではなくスマホケースです。これを実行して、ここで何が起こるか見てみましょう。今回はいくつか結果を取得しており、ここではかなり違う結果になると思います。はい、出ました。
ええと、モデルは、ええと、かなりすべてあなたのスマホ、ええと、ええと、ほぼすべてスマホケースを出しています。そして、ええと、まあ私の、ええと、人間の目から見ると、6番は実際にはもう少し有望だと思います。なぜなら、この、ええと、美しい模様があるからです。では、ええと、見てみましょう。つまり、これは、これはすでに、ええと、印象的な結果です。たとえ、ええと、6番が1位にランクされていなくても、まだ、かなり限られた、ええと、結果セットの中にあります。有望な結果を、ええと、一つ出しています。あとは、ええと、それをもう少し先に進めて、最初のものをトップにランク付けする必要があります。そうすることで、ええと、最終ユーザーに、ええと、無関係な結果を表示してしまうようなリスクを避けたいのです。
では同じことをやりましょう。ええと、GPD four ohで再ランキングし、それからpre、ええと、それから最終結果をここに出力します。はい。今回は非常に印象的な結果です。この、ええと、スマホケースを出してくれています。これは、ええと、ご存じのように、ええと、まず第一にスマホケースであり、同時に、ええと、ヒョウ柄のパターンも備えていて、ええと、テキストと画像の両方の背後にある意図に非常によく合っています。
はい。ええと、私が共有したかったことはだいたい以上です。ええと、聴衆から何か質問があるか確認します。いくつか質問があります。ええと、clipは、つまり、clipは基本的に2つのモデルなのですか。
それがmilsで検索を行う方法にどのように影響するのか、もう一度説明してもらえますか？はい。clipは、ええと、クロスモダリティモデルです。つまり、テキストと画像の両方の情報を同じ潜在空間にマッピングできます。ただ実際には、ええと、詳細を見ると、ええと、それは2つの異なるエンコーダを使っています。つまりclipは、ええと、画像には画像エンコーダを使い、テキストには、ええと、テキストエンコーダを使います。そしてそれらは実際には技術的に2つの異なるモデルであり、異なるモデル重みを持っています。
そのため、ええと、検索システムの設計に2つの側面で影響します。一つは、ええと、埋め込みフェーズに関して、ええと、GPUメモリにモデル重みのコピーを2種類ロードする必要があるということです。そして、それはほぼ2つのモデルを使っているのと同じです。そして、それから、ええと、テキストが1つ与えられた場合、ええと、GPUメモリの一部を利用して、この、この特定のモデルを使って推論を行い、そうでなければもう一方を使う、というのが一つです。ええと、もう一つはデータストレージについてです。
ええと、なのでここでは、実は、ええと、clip の、ええと、ええと、招待結果を、ええと、うーん、正確にどう保存するかは示していません。というのも、ええと、もし私が clip を使うなら、おそらくそのどちらも使わないからです。かなり高い確率でモデル、ええと、データモデルを設計するとしたら、うーん、画像またはテキストを一意の、ええと、一意のエンティティとして持つようにします。そしてそれらを別々に識別します。なので、うーん、私がその、そのデータモデルを設計する方法は、ええと、単一のベクターフィールドを持ち、それが clip embedding ベクトルを保存する、というものです。テキストモデルまたは画像モデルのどちらからのものでもです。
そして、ええと、ある種の共有された、うーん、非アクターフィールドを持ちます。おそらく image URL または text と呼ぶでしょう。そしてこの中には、ええと、文字列を1つ保存するだけで、その文字列は、その、その、その生のテキストでもよいし、あるいは例えば画像の URL でもよいです。そして、ええと、私はある程度、うーん、決めます、うーん、その型が何かを、おそらく別のフィールドを持って、それがこの情報の断片の型を定義します。それがテキストなのか画像なのかを、enumerator を使ってそれを保存するか、あるいは単に、あ、あ、数値で示します。うーん、そして、ええと、取り込み時には、まずこれが画像なのかテキストなのかを検出し、それから推論にどのモデルを使うかを決めます。
そしてそれらに対してベクトル embedding を生成し、それを、そのフィールドに保存します。そしてそれがテキストか画像かに基づいて、この、この、ええと、この単一のフィールドに、その、うーん、その情報の表現のようなものを保存します。ええと、画像の表現は you RL で、テキストの表現はテキストです。ではその質問に続きがあり、それは、clip は画像を1つのベクトル空間にエンコードし、テキストを完全に別のベクトル空間にエンコードする、という意味ですか？いいえ、ええと、まったくそうではなく、実際にはエンコードします、うーん、エンコードには2つの、うーん、異なるモデルの方法を使っているにもかかわらず、実際にはテキストと画像を同じ潜在空間にエンコードします。だからこそ、このクロスモダリティ検索ができるのです。つまり、doc と呼ばれるテキストの断片から doc の画像を検索できる、ということです。
素晴らしい。ええと、もう1つ質問です。GPT-4 oh は、私たちのカスタムモデルのスキーマをどうやって知るのですか？それは生のベクトルデータを理解しているからですか、それとも embedding の型が同じだからですか？わあ、それはとても良い質問です。うーん、実際にはそうではなく、ええと、ベクトルを理解しているわけではありません。画像のピクセルを理解しています。
なのでここでは、うーん、この、うーん、GPTO フェーズでランク付けするところでは、実際にはこの、この、この文字どおりの画像、または、あ、ピクセルの集合を G PT four に送っていて、ええと、例えば10個のベクトルを g PT four に送っているわけではありません。なので、実際にはベクトルそのものについて知っているわけではありませんが、それでもかなり印象的です。なぜなら、それは理解できるからです、うーん、まず非常に複雑な指示があり、うーん、すみません、下のほうです。うーん、非常に複雑な指示があり、「わかった、この画像の右側のものを、blah, blah, blah のセマンティクスに基づいて再実行する必要がある」ということを伝えています。そして第二に、それはある程度、うーん、指示の中で表現された情報をこの画像に結び付け、それからこの画像を理解できます。この画像は単なるピクセルの集合であるにもかかわらずです。なので、それは、つまり、私にとっては今でもかなり印象的で、それができること、ええと、この、この素晴らしい仕事ができること、うーん、例えばこれら9枚の画像の中から6番を選び出すことができることです。そして、そしてさらに、つまり、その、その、ええと、うーん、空間情報の理解レベルも非常に印象的で、ある程度、「なるほど、ここは横に並んでいるので、ええと、つまり、それは、うーん、0 1 2 とランク付けされているのであって、0 1 2 ではない、ええと、縦方向ではない、ええと、縦に、というように」分かっているのです。
それはかなりきれいというか、わかりませんが、未来的で、ええ、すでにそうなっています。ええ、それともう一つ触れておきたいのは、ええ、GP four oh はこのようにセマン、関連コンテンツを選択するという非常に印象的な仕事ができるとはいえ、ええ、この規模で行うと非常に高コストになるということです。なので、ええ、たとえ、つまり見たところ、このマルチモデル検索モデルは GP four oh ほど良い仕事をしていないとしても、ええ、ある意味、ええ、やはり強い、ええ、利点があります。それはこれをスケールして実行できるという点です。これをオフラインインデックス化で行い、クロスモダリティモデルを使って画像をベクトルにインデックス化し、ええ、それらをベクトルデータベースに保存することで、ある程度、ストレージコストを払って時間を節約できます。そして検索時には、検索はほとんど瞬時です。ええ、GPD four, oh だけで、9つの中から1つを選ぶだけの場合と比べても、そうです。
ええ、前回はだいたい5秒くらいかかったと思います。ええ、そうですね、こうした生成、または、ええ、推論を行うのに5秒くらいです。ええ、しかし、ベクトル検索の場合は、ええ、確認してみましょう、おそらく1秒未満です。ええ、ええ、検索対象の候補が900個しかないからです。はい。で、0秒です。
はい、つまり、かなり速いです。これはたぶん、ええ、10ミリ秒程度だと思います。ですので、検索の、ある種の従来技術を適用することにはまだ多くの利点があります。つまり、インデックス化を通じてオフラインで多くの作業を行い、その後オンラインのクエリ処理時には、これが非常に効率的で、非常に、ええ、非常に大規模配信に適用しやすいということです。そして、ええ、非常に価値の高いユースケースの一部でのみ、GPD four oh を使用して、このような情報の細かい、ええ、細かな処理を行うために、あなたのキャッシュを消費し、ええ、つまり、大量の remodel トークンを燃やす価値があるでしょう。ありがとうございます。
ええ、このデモコードを利用可能にできますか、というリクエストがあります。ああ、はい。ええ、実はこれは公開されている、ええ、VUS のウェブサイトなので、vu の、ええ、docs に行くことができますし、あるいは少し下にスクロールして直接そこにジャンプすることもできます。rag image search と multimodel examples があります。これにより、ええ、nav、ええ、ホストされた、ある種のオンラインデモに移動できますので、それを試すことができます。そしてこちらの docs には、ええ、これを自分で実装する方法の手順があります。これは、私がちょうど示した内容をカバーしています。また、ええ、stream list のようなものを使ってこれをデプロイすることもできますので、フロントエンド体験を持つことができます。
これをクリックするだけで、GitHub に移動します。そうすると、ええ、この、ええ、ローカルのラップトップ、ええ、ラップトップまたはノートブック上で、これに似た UI 体験を持つ、ええ、モデル、すみません、デモをデプロイできます。そして、録画と一緒にフォローアップメールで、それらのリンクも共有できます。なので、それらをお待ちください。はい。ええ、また、このオンラインデモでは、ええ、事前設定された例のリストで試すことができます。
たとえば、ここでは、この、ええ、この機械のおもちゃを検索できます。ええ、そして reran もできます。これは surgery sauce のランクをシャッフルします。では、皆さんを数分オーバーさせてしまいました。最後の質問が1つありますので、それで今日は終わりにします。ええ、multimodal rag において、dolia を使った画像生成、LMS のようなものはありますか？たとえば、ええ、ヒョウのようなイヤホンと尋ねた場合、それは検索しているだけです。なぜヒョウとイヤホンの検索画像を使って、完全に新しい画像を生成しないのですか？ええ、長い質問ですね。
そうですね、Q&Aボックスにあります。はい。ええと、まず最初に、ええと、この種のデモを行うもっと創造的な方法として、何かを検索して、その検索結果を、ええと、ええと、Stable Diffusion のようなモデルに送って、そこから何かを生成することができます。ええと、質問の他の部分が何だったか確認させてください。ええと、少しお待ちください。ええと、ご友人に尋ねているときに、たとえば、なぜ完全に新しい画像を生成していないのか、という答えですが、以前お見せしたデモが何も生成していなかった理由は、ええと、生成するように指示していなかったからです。実際には生成とは少し違うことをしていました。ええと、まあ本質的には、それも生成ではあるのですが、新しい情報を生成しているわけではなく、テキストの一部を生成しているだけで、それは、ええと、3×3のボックスに表示されているものの中で、画像と私の指示に最もよく一致する最適な画像がどれかを教えてくれるものです。
したがって本質的には、それは依然としてインサイトを生成しているのですが、実際には別の、ええと、画像そのものを生成しているわけではありません。つまり、eコマースのウェブサイトなどで見られるようなものですね。たとえば、さまざまな入力を使って、特定の種類の商品を探すようなもの、という理解でよいですか？はい。ですから、これを行うより創造的な方法としては、まあ、実際のアプリケーションでは、この画像とテキストの両方によって表現されるこのセマンティックに似た画像をいくつか取得し、それからビジネスロジックを適用して何かを生成し、ユーザーにインスピレーションを与える、ええと、ええと、つまり、ユーザーが本当に興味深いものを買いたくなるように促したり、あるいはアーティスト向けに何かを描いたりすることができます。John、この素晴らしいセッションを本当にありがとうございました。ご参加いただいた皆さまにも感謝します。
本日の録画と、彼が今日共有したリンクもお送りします。ええと、遅い時間までご参加いただきありがとうございます。そちらのタイムゾーンでは、ええと、遅い時間だと思いますので、本当に感謝しています。そして、今後のウェビナーで皆さまにまたお会いできることを願っています。本当にありがとうございました。光栄です。
皆さん、ありがとうございました。
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.