ブログ
セルフデプロイのMilvus Vector DatabaseとSnowparkコンテナサービスによるRAGの構築

セルフデプロイのMilvus Vector DatabaseとSnowparkコンテナサービスによるRAGの構築

Jun 28, 20243 min read

Zillizのエコシステム＆AIプラットフォーム責任者であるJiang Chenは最近、Unstructured Data Meetupでの講演で、MilvusとSnowflakeをシームレスに統合する方法について議論した。具体的には、Milvusベクトルデータベースを使ったRetrieval Augmented Generation (RAG)システムの構築方法と、Snowpark Container Service(SPCS)を使ったSnowflakeエコシステムとの統合について探求した。

< Watch Jiang Chen's talk on Youtube>

この記事では、江氏の重要なポイントをまとめ、3つの重要なトピックを取り上げる。

まず、RAGシステムの構築に不可欠なベクトル検索にMilvusを活用する方法について説明します。次に、SPCSを使ってMilvusをSnowflakeに統合する方法について説明します。最後に、RAGの今後の展望についても述べます。トピックに深く入る前に、AIが情報検索をどのように変えたかを探ってみよう。

AIが情報検索プロセスをどのように変革するか

AIの進歩と普及は、情報検索の全体像を急速に変えた。AIの台頭以前は、情報検索は統計モデルとタグ付けのようなキーワードマッチング手法に大きく依存していた。例えば、オンラインショップのオーナーは、あらかじめ定義されたカテゴリーに各商品のタグを手作業で入力する必要があった。膨大な商品カタログを持っている場合、このプロセスは現実的ではないだろう。

同様に、顧客である私たちも、欲しい商品を正確に入手するために適切なタグを入力する必要がある。問題は、正確ではないが、欲しい商品と似た意味を持つタグを入力した場合、タグ付け法による情報検索では適切な商品が得られないことだ。つまり、タグ付け法はクエリの意味的な意味を考慮していないのだ。

AIが非構造化データの使い方に革命を起こす](https://assets.zilliz.com/AI_revolutionizes_how_we_use_unstructured_data_d9c61859e0.png) AIが非構造化データの使い方に革命を起こす_」。

埋め込みモデル](https://zilliz.com/blog/choosing-the-right-embedding-model-for-your-data)の登場は、情報の検索方法を完全に変えました。ほとんどの埋め込みモデルは、有名なTransformerアーキテクチャをバックボーンとしています。Transformerモデルは、いくつかのエンコーダ・デコーダブロックを活用し、それぞれが特殊なアテンション層を含んでいる。このレイヤーは、入力シーケンス全体に対する各入力トークンの意味的な意味を感知することを可能にし、埋め込みモデルが入力単語の意味的な意味を推論できるようにする。

トランスフォーマーアーキテクチャ](https://assets.zilliz.com/Image_title_Transformer_architecture_03ed304894.jpg)

*トランスフォーマー・アーキテクチャー

埋め込みモデルは、クエリや画像、テキスト記述をベクトル埋め込みと呼ばれる数値表現に変換します。ベクトル埋め込みは、それが表現する入力の意味的な豊かさを持ち、余弦類似度または余弦距離によって、2つのベクトル埋め込み間の類似度を比較することができます。類似度が高ければ、2つのベクトル埋め込みは似た意味を持っており、逆もまた然りです。

生テキストからベクトル埋め込み.png

生テキストからベクトル埋め込み

これらの強力な特徴により、埋め込みモデルは、情報検索のコンセプトをより簡単に、より柔軟に実装することができます。

検索拡張世代 (RAG)

埋め込みモデルの急速な進歩と大規模言語モデル（LLM）の台頭により、RAGという非常に洗練された情報検索手法が誕生しました。RAGは、LLMにクエリとともに内部の知識ベースから関連するコンテキストを提供することで、LLMの応答品質を高めるように設計されている。LLMは提供されたコンテキストを利用してクエリに答える。

RAGアーキテクチャ](https://assets.zilliz.com/RAG_chatbot_03e36cd708.png)

RAGアーキテクチャ

RAGアプリケーションでは、選択した埋め込みモデルを用いて、データと入力クエリを埋め込みに変換します。そして、クエリの埋め込みと我々のデータの埋め込みとの類似度を計算する。そして、クエリに最も類似したデータが、クエリと一緒にコンテキストとしてLLMに渡される。最終的に、LLMは提供されたコンテキストに基づいてクエリに対する回答を生成することができる。このようにして、LLMを微調整することなく、LLMの応答精度を高めることができる。

Milvus Vector DatabaseとSnowflakeとSnowparkコンテナサービスの統合

Milvusはオープンソースのベクトルデータベースで、RAGアプリケーションに有用な大量のベクトル埋め込みを保存し、それに対して一瞬でベクトル検索を実行することができます。Milvusをインストールして利用するにはいくつかの方法があります：

Milvus Lite**](https://milvus.io/blog/introducing-milvus-lite.md)：迅速なプロトタイピングに適したMilvusの軽量版です。Milvus Liteはサーバーを必要とせず、ご自身のデバイス上で動作させることができます。インストールはpip installコマンドで簡単に行えます。

pip install "pymilvus>=2.4.2 "をインストールする。
from pymilvus import MilvusClient
client = MilvusClient("milvus_demo.db")

DockerにおけるMilvus](https://milvus.io/docs/install_standalone-docker.md)：Milvusベクターデータベースを本番環境で使用したいが、データ量が少ない場合は、Dockerコンテナとして実行することができます。コマンドラインでこれらのコマンドを実行するだけなので、手順も簡単です：

# インストールスクリプトをダウンロードする
$ curl -sfL <https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh> -o standalone_embed.sh

# Dockerコンテナを起動する
$ bash standalone_embed.sh start

# Python IDEで
from pymilvus import MilvusClient

client = MilvusClient(
uri="<http://milvus:19530>"、
)

KubernetesにおけるMilvus](https://milvus.io/docs/install_cluster-milvusoperator.md)：このオプションは、大量のデータがある場合や、RAGアプリケーションに大量のユーザーがいる場合に適しています。Kubernetesでは最大1000億のベクトルを保存できる。Kubernetesのインストールプロセスは、Milvus LiteやDockerよりも少し複雑です。そのため、詳細についてはインストールドキュメントを参照してください。

Milvusは、OpenAI、HuggingFace、Cohere、LangChain、LlamaIndex、Snowflakeといった一般的なAIツールキットとのシームレスな統合を提供しています。これらの統合により、独自のRAGシステムや他のGenAIアプリケーションを簡単に構築することができる。このセクションでは、Snowflakeエコシステム内でMilvusを実行する方法を紹介します。

Milvusはすべての一般的なAIツールキットとシームレスに統合することができます](https://assets.zilliz.com/Milvus_offers_seamless_integration_with_all_popular_AI_toolkits_20c34552aa.png)

Milvusはすべての一般的なAIツールキットとのシームレスな統合を提供します。

Snowflakeは、効率的かつ信頼性の高いデータの保存、処理、分析を可能にするデータウェアハウジングプラットフォームです。Snowpark Container Service（SPCS）の導入により、Snowflake環境内でコンテナ化されたアプリケーションを実行できるようになりました。これにより、アプリケーションはSnowflake内に保存されたデータとやり取りできるようになり、RAGシステムを含む幅広いアプリケーションを構築できるようになります。

このセクションでは、まずベクトル検索を実行するアプリをMilvusで構築します。次に、Dockerを使用してアプリケーションをコンテナ化し、SPCSを使用してSnowflake内でコンテナを実行します。

手始めに、Jupyter Notebookでベクトル検索を実行するMilvusアプリをビルドしてみましょう。ノートブックと埋め込みモデルを構築するスクリプトはこのリポジトリを参照してください。

from pymilvus import MilvusClient
from pymilvus import DataType
import os
インポートモード

# init クライアント
クライアント = MilvusClient(
uri="<http://milvus:19530>"、
)

# モデルの初期化
model = model.Onnx()

# クイックセットアップモードでコレクションを作成する
client.create_collection(
collection_name="quick_demo"、
dimension=model.dimension、
)

print("Collection Created!")

上記のコードでは、Milvusベクトルデータベース内に "quick_demo "というコレクションを作成し、テキストを埋め込みに変換するモデルをロードしています。埋め込みモデルにはALBERTを使います。ALBERTは入力テキストを768次元のベクトル埋め込みにマッピングします。

次に、テキストデータを "quick_demo "コレクションに挿入する。

# 埋め込みを生成するデータ
docs=[
「人工知能は1956年に学問分野として設立された、
"アラン・チューリングはAIの実質的な研究を行った最初の人物である。"、
「チューリングはロンドンのマイダベールで生まれ、イングランド南部で育った、
]

# データをコレクションに挿入する
data=[]
for i in range(len(docs))：
data.append({
'id': i、
'vector': model.to_embeddings(docs[i])、
'doc_str': docs[i].
})

res = client.insert(
collection_name="quick_demo"、
data=data
)

上記のコードでは、入力テキストをALBERTでエンベッディングに変換し、IDと生のテキストとともにコレクションに格納しています。

さて、"Who started AI research?"のようなクエリがあり、クエリに関連する答えを含む可能性のある関連コンテキストを取得したい場合、以下のようにMilvusを使って簡単にベクトル検索を行うことができます：

# テキストクエリで検索する
query = "誰がAI研究を始めたのか？"
query_embeddings = model.to_embeddings(query)

res = client.search(
コレクション名="quick_demo"、
data=[query_embeddings]、
limit=1、
output_fields=["doc_str"]、
)

print(res)
"""
期待される出力
"アラン・チューリングはAIの実質的な研究を行った最初の人物である。"
"""

Milvusアプリは以上です。

この段階で、Milvusでベクトル検索を実行するためのJupyter Notebookができた。このノートブックをコンテナ化してSnowflakeエコシステム内で実行したいとします。最初にやるべきことは、Snowflakeが提供するサービスを作成して実行するためのロールと権限を設定することです。

まず、SnowSQLのインストールdocページの指示に従ってSnowSQLをダウンロードします。次に、ターミナルで以下のコマンドを実行します：

snowsql -a ${インスタンス名} -u ${ユーザ名}.

ここで ${instance_name} のフォーマットは ${org_name}-${acct_name} で、この2つのフィールドに関する情報は Snowflake アカウントの中にあります。これで、SnowSQLシェル内で以下のコマンドを使用してロールと権限を設定することができます：

accountadmin ロールを使用します；
セキュリティ統合 snowservices_ingress_oauth を作成します。
  TYPE=oauth
  OAUTH_CLIENT=snowservices_ingress
  ENABLED=true；
  
accountadminロールを使用する；
アカウントのバインドサービスエンドポイントをsysadminロールに付与します；

セキュリティ管理ロールを使用します；
milvus_roleロールを作成する；

useradminロールを使用します；
CREATE USER milvus_user
  PASSWORD='milvususerok'
  default_role = milvus_role
  default_secondary_roles = ('all')
  must_change_password = false；
  
securityadminロールを使用する；
GRANT ROLE MILVUS_ROLE TO USER milvus_user；

Snowflakeはデータウェアハウジングプラットフォームなので、上で見たようにSQLクエリのようなコマンドを通してSnowflake内のすべてのオブジェクトとやり取りします。次に、以下のコマンドでSnowflake内にデータウェアハウスとデータベースを作成します：

ロール sysadmin を使用します；
倉庫 milvus_warehouse を次のように作成または置き換えます。
warehouse_size='x-small'
auto_suspend = 180
AUTO_RESUME = true
INITIALLY_SUSPENDED=false；

sysadminロールを使用する；
milvus_demoが存在しない場合は、データベースを作成します；
データベース milvus_demo を使用します；
イメージリポジトリ milvus_demo.public.milvus_repo を作成します；
ステージ yaml_stage を作成または置き換えます；
ステージデータの作成または置換 暗号化 = (type = 'snowflake_sse')；
ステージファイルの作成または置換 encryption = (type = 'snowflake_sse')；

-- 権限を与える

securityadminロールを使用します；
データベース milvus_demo のすべての権限を milvus_role に付与します；
milvus_role にスキーマ milvus_demo.public のすべての権限を付与します；
milvus_role に倉庫 milvus_warehouse 上のすべての権限を付与します；
ステージ milvus_demo.public.files のすべての権限を milvus_role に付与します；

-設定 acl--

accountadmin ロールを使用します；
データベース milvus_demo；
スキーマpublicを使用する；
CREATE NETWORK RULE allow_all_rule
タイプ= 'host_port'
MODE= 'EGRESS'
value_list = ('0.0.0.0:443','0.0.0.0:80')；

CREATE EXTERNAL ACCESS INTEGRATION allow_all_eai
ALLOWED_NETWORK_RULES=(allow_all_rule)
ENABLED=TRUE；

ROLE SYSADMINにINTEGRATION allow_all_eaiのUSAGEを付与します；

Snowflake内でコンテナ化されたアプリを実行するには、ローカルマシンでアプリのDockerイメージをビルドする必要があります。このプロジェクトでは、2つの異なるDockerイメージをビルドする必要があります。1つはMilvusベクトルデータベースをインスタンス化するため、もう1つは上記で作成したノートブックファイルを実行するためです。

しかし、DockerイメージをビルドするにはDockerfileが必要です。簡単にするために、以下のリポジトリをクローンしてください。このレポには、必要な2つのイメージをビルドするのに必要なファイルがすべて揃っている。このレポをクローンしたら、ローカル・ターミナルで以下のコマンドを使って2つのDockerイメージをビルドすることができる：

cd ${repo_git_root_path}
docker build --rm --no-cache --platform linux/amd64 -t milvus ./images/milvus
docker build --rm --no-cache --platform linux/amd64 -t jupyter ./images/jupyter

次に、新たにビルドした2つのイメージに、以下のコマンドで適切なタグを追加する：

docker login ${インスタンス名}.registry.snowflakecomputing.com -u ${ユーザー名}.

docker tag milvus ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker tag jupyter ${インスタンス名}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter

最後に、以下のコマンドでイメージをSPCSにプッシュします：

docker push ${インスタンス名}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker push ${インスタンス名}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter

これでイメージをSPCSにプッシュしたので、あとはSnowSQLシェル内で以下のコマンドを実行することで、イメージごとに2つのコンピューティングサービスを作成するだけです：

sysadmin ロールを使用します；
もし milvus_compute_pool が存在しなければ、計算プールを作成します。
  MIN_NODES = 1
  MAX_NODES = 1
  インスタンスファミリー = cpu_x64_s
  AUTO_RESUME = true；
jupyter_compute_poolが存在しない場合はcompute poolを作成する。
  MIN_NODES = 1
  MAX_NODES = 1
  インスタンスファミリー = cpu_x64_s
  AUTO_RESUME = true；

先ほどクローンしたレポの中に "specs" というフォルダがあります。そのフォルダの中には2つの YAML ファイルがあり、それぞれの画像に対して1つずつあります。それぞれの YAML ファイルを開き、image フィールドの ${org_name}-${acct_name} を自分の Snowflake アカウントに合わせて変更します。

次に、SnowSQL を使用して、以下のコマンドで変更した YAML ファイルをアップロードします：

PUT file://${path/to/jupyter.yaml}。PUT file://${path/to/jupyter.yaml} @yaml_stage overwrite=true auto_compress=false；
PUTファイル://${path/to/milvus.yaml} @yaml_stageyaml_stage overwrite=true auto_compress=false; PUT file://${path/to/milvus.yaml} @yaml_stage；

最後に、両方のイメージのサービスを以下のように作成する：

sysadmin ロールを使用する；
use データベース milvus_demo；
use スキーマ public；

サービス milvus を作成します。
  計算プールの milvus_compute_pool
  yaml_stageから
  SPEC='milvus.yaml'
  min_instances=1
  max_instances=1；

サービスjupyterを作成する。
  をコンピュート・プールjupyter_compute_poolに作成する。
  yaml_stageから
  SPEC='jupyter.yaml'
  min_instances=1
  max_instances=1；

ここで、SHOW SERVICEコマンドを入力すると、次のような出力が表示される：

SHOW SERVICES；

+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| 名前｜データベース名｜スキーマ名｜所有者｜compute_pool｜dns_name｜・・・・・・。
|---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| JUPYTER｜MILVUS_DEMO｜PUBLIC｜SYSADMIN｜JUPYTER_COMPUTE_POOL｜jupyter.public.milvus-demo.snowflakecomputing.internal｜.......
| MILVUS｜MILVUS_DEMO｜PUBLIC｜SYSADMIN｜MILVUS_COMPUTE_POOL｜milvus.public.milvus-demo.snowflakecomputing.internal｜・・・・・・。
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------

これで、Milvusベクトルデータベースを実行し、Snowflake内でノートブックをテストする準備ができました。まず、前に作成したロールにコンテナ化アプリへのアクセス権限を付与します。

securityadmin ロールを使用します；
milvus_role ロールに milvus_demo.public.jupyter サービスの使用権限を付与します；

次に、次のコマンドで Snowflake 内のノートブックコンテナのエンドポイントを確認します：

sysadmin ロールを使用します；
milvus_demo.public.jupyter サービスのエンドポイントを表示します；

Jupyterエンドポイント、ingress_urlに表示

ingress_url_に示されているJupyterエンドポイント

すべてがスムーズにいけば、"ingress_url "というカラムが出力されます。ブラウザーを開き、その "ingress_url "をコピーペーストすると、Jupyterがスピンアップするはずです。コンテナ内でノートブックファイルを開き、ノートブック内の各セルを普通に実行できる。

RAGの今後の展望

RAGは現在非常に人気のある技術である。しかし、現在の応用は完璧とは言い難い。ジアン・チェンによれば、RAGアプリケーションの将来的な使用と改善に関するいくつかの予測がある。

継続的な評価と観測可能性

RAGの開発プロセスを簡素化・抽象化する様々なプラットフォームやライブラリが利用可能になり、RAGの構築は容易になった。例えば、3つの異なるプラットフォームの助けを借りて、数分でRAGプロトタイプを構築することができる：Milvus、LangChain、OpenAIです。

しかし、RAGを搭載したアプリケーションをプロトタイプからプロダクションに移行する際には、しばしば課題に直面します。本番では、私たちのRAGシステムは数百万から数十億のドキュメントを扱う必要があり、LLMによって生成される応答品質を継続的に監視することが非常に重要になります。

RAGシステムの継続的評価](https://assets.zilliz.com/Continuous_evaluation_of_the_RAG_system_7e7453c4cf.png)

RAGシステムの継続的評価

RAGの質を高めるための改善を実施する前に、RAGを継続的に評価し、改善するための体系的なアプローチを確立することが重要である。

この体系的アプローチの重要な要素には、以下のようなものがあります：

専用の改善インフラ**を構築すること：このインフラストラクチャーでは、RAGの品質を向上させるための様々な方法を実施し、A/Bテストでその反応を比較することができます。
リリース・サイクルの計画**：私たちのユースケースに従ってRAGの品質を向上させるアプローチを見つけたら、それをどのようにリリースし、私たちのシステムに統合するかを計画する必要があります。
観測可能性システムの実装**：また、RAGのパフォーマンスを本番環境で観察し、その有効性を判断するシステムを構築する必要があります。もしパフォーマンスに不満があれば、専用の改善インフラを通じて改善を検討し、実施することができる。

マルチモーダルRAG

これまで、我々は主に自然言語処理でRAGを利用してきた。つまり、プロンプトやクエリとしてテキストを使用し、LLMの応答もテキスト形式である。

しかし、マルチモーダルRAGの導入により、RAGの状況は将来変わるかもしれない。マルチモーダルRAGが可能になるのは、近年のマルチモーダル埋め込みモデルの台頭によるものである。ここ数年の研究で、Transformerは自然言語を入力として処理でき、画像や音声などの他のモダリティも処理できるという結論が得られている。

Vision Transformers（ViT）とDETRモデルは、Transformersが強力な画像分類と物体検出モデルとして使用できることを実証しました。ViTをベースに、OpenAIはCLIPと呼ばれるマルチモーダルモデルを導入しました。これは、テキストと画像という異なるモダリティからの2つの入力間の類似度を計算することができます。

これらのTransformerベースのモデルが示すマルチモーダル能力は、将来のマルチモーダルRAGアプリケーションの基礎となる。このシステムでは、テキストと画像の組み合わせをクエリとして使用することができ、LLMはマルチモーダルなクエリに基づいて画像を生成する。

例として、LLMが、提供されたクエリ画像によく似た画像を生成したいとしよう。LLMに生成させたい画像の種類をさらに細かく調整するために、クエリ画像にテキストの説明を加えることができます：

マルチモーダルRAGアプリケーション、テキストと画像の組み合わせ](https://assets.zilliz.com/Multi_modal_RAG_application_combination_of_text_and_image_queries_36fd637a39.png)

マルチモーダルRAGアプリケーション、テキストと画像クエリの組み合わせ

上の可視化では、埋め込みモデルに左上の画像に似た画像を返すように依頼し、左上の画像の横に「a picture of a mountain during the golden hour,」のようなテキストプロンプトを追加しました。結果は、マルチモーダルなクエリに基づいて生成された他の3つの画像です。

このRAGのマルチモーダルなアプローチは、テキストと視覚の両方の長所を融合させ、より直感的で表現力豊かな情報検索と生成の新しい可能性を開くものである。

優れたRAGは優れたデータから生まれる

私たちのRAGシステムの品質は、私たちのデータベースにあるデータの品質に大きく依存しています。したがって、RAGによって生成された回答が最適でない場合、モデルを改善する必要があるという結論に急いではならない。まず、常にデータの質をチェックする必要がある。

すでにご存知かもしれないが、RAGの応答品質は、クエリとともに渡されるコンテキストに依存する。もし私たちのLLMが、提供されたコンテキストからクエリに対する適切な答えを見つけることができなければ、私たちのRAGシステムによって生成されるレスポンスの質が悪くなるのは当然である。

従って、RAGシステムで埋め込みモデルやLLMを改良する前に、我々は常に以下の問いを立てるべきである：

データベースに正しいデータがあるか？
データソースから利用可能なすべてのデータをデータベースに収集したか？
埋め込みモデルにデータを渡す前に、適切なデータクリーニングプロセスを実行したか？
データに対して適切なチャンキングアプローチを実施したか？
データの前処理（PDF解析、OCR解析など）を適切に行ったか？

データ関連の問題に対処することは、RAG搭載アプリケーションのパフォーマンスを最適化するための重要な第一歩です。データの品質を検証した後に初めて、埋め込みモデル、LLM、またはRAGシステムの他のコンポーネントの改良を検討する必要があります。

エージェントサブクエリによるクエリルーティング

現在、一般的なRAGシステムは、与えられたクエリに関連するコンテキストを、内部データベースに保存されたテキストと埋め込みから検索する。しかし、コンテキストが内部データベースやウェブ検索のような外部ソースから取得される可能性があるため、このアプローチは進化するかもしれない。

クエリルーティングのためのエージェントの可視化](https://assets.zilliz.com/Visualization_of_agents_for_query_routing_6a8d8ff894.png)

クエリルーティングのためのエージェントの可視化

この分野の研究はまだ進行中であるが、RAGシステム内にいわゆる "エージェント "を追加することで、与えられたクエリに対して適切なコンテキストのソースを決定するのに役立つかもしれない。

例えば、"Who started AI research? "のようなクエリが与えられた場合、エージェントはそのクエリに答えるためにRAGが必要かどうかを判断することができる。そうでない場合、システムはLLMに、追加のコンテキストなしに、クエリに対する応答を直接生成させることができる。

RAGが必要と判断された場合、エージェントはコンテキストのソースを内部データベースか外部ソースかを決定する必要がある。もう一つのアプローチは、エージェントが様々なソースからの情報を、LLMが適切な回答を生成するために使用できる単一の要約されたコンテキストに集約することである。

結論

人間のようなテキスト応答を生成するLLMの強力な性能は、情報検索の全体像を変えた。RAGの導入は、与えられたクエリに関連するコンテキストをLLMに提供することで、LLMの応答精度を高めるように設計されている。これらのコンテキストは通常埋め込みとして格納され、Milvusのようなベクトルデータベースに格納されなければならない。

高度なベクトル検索機能を備えたオープンソースのベクトルデータベースとして、MilvusはSnowflakeのような一般的なAIツールキットとのシームレスな統合を提供する。SnowflakeのSnowpark Container Service（SPCS）により、ユーザーはSnowflakeエコシステム内でMilvusを実行できるようになり、Snowflakeに保存されたデータを使用してMilvusと簡単に対話できるようになりました。

article.updateAt

Ruben Winastwan

読み続けて

Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)

Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.

Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud

We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.

Zilliz Cloud Introduces Advanced BYOC-I Solution for Ultimate Enterprise Data Sovereignty

Explore Zilliz Cloud BYOC-I, the solution that balances AI innovation with data control, enabling secure deployments in finance, healthcare, and education sectors.