MilvusによるマルチテナントRAGの設計: 拡張可能なエンタープライズ知識ベースのベストプラクティス

はじめに

ここ数年、RAG（Retrieval-Augmented Generation：検索支援型ジェネレーション）は、大企業がLLMを利用したアプリケーション、特に多様なユーザーを持つアプリケーションを強化するための信頼できるソリューションとして台頭してきた。このようなアプリケーションが成長するにつれて、マルチテナンシーフレームワークの実装が不可欠になります。マルチ・テナントは、異なるユーザー・グループに対して安全で隔離されたデータ・アクセスを提供し、ユーザーの信頼を確保し、規制基準を満たし、運用効率を向上させます。

Milvusは、高次元のベクトルデータを扱うために構築されたオープンソースのベクトルデータベースです。RAGの不可欠なインフラストラクチャーコンポーネントであり、外部ソースからのLLMのコンテキスト情報を保存し、検索します。Milvusは、データベースレベル、コレクションレベル、パーティションレベルのマルチテナンシーなど、様々なニーズに対応した柔軟なマルチテナンシー戦略を提供しています。

この投稿では、以下の内容を取り上げます：

• マルチテナンシーとは何か、なぜ重要なのか

• Milvusにおけるマルチテナンシー戦略

• 例RAGを利用した企業ナレッジベースのマルチテナンシー戦略

マルチテナンシーとは何か？

マルチテナンシーとは、「テナント」と呼ばれる複数の顧客やチームが、アプリケーションやシステムの単一のインスタンスを共有するアーキテクチャです。各テナントのデータと設定は論理的に分離され、プライバシーとセキュリティが確保される一方で、すべてのテナントが同じ基盤インフラを共有します。

複数の企業にナレッジベースのソリューションを提供するSaaSプラットフォームを想像してみてください。各企業はテナントです。

• テナントAは、患者向けのFAQやコンプライアンス文書を保管する医療機関です。

• テナントBは、社内のITトラブルシューティングのワークフローを管理するハイテク企業。

• テナントCは小売業で、返品に関するカスタマーサービスFAQを保管しています。

各テナントは完全に分離された環境で運用されており、テナントAのデータがテナントBのシステムに漏れたり、逆にテナントCのデータがテナントBのシステムに漏れたりすることはありません。さらに、リソースの割り当て、クエリのパフォーマンス、およびスケーリングの決定はテナントごとに行われるため、あるテナントでワークロードが急増しても、高いパフォーマンスが保証されます。

マルチテナントは、同じ組織内の異なるチームにサービスを提供するシステムにも有効です。ある大企業が、HR、法務、マーケティングなどの社内部門にサービスを提供するために、RAGを利用したナレッジベースを使用しているとします。この設定では、各部門が独立したデータとリソースを持つテナントとなります。

マルチテナントには、コスト効率、拡張性、堅牢なデータセキュリティなど、大きなメリットがあります。単一のインフラを共有することで、サービス・プロバイダーはオーバーヘッド・コストを削減し、より効果的なリソース消費を実現できる。また、シングル・テナント・モデルのようにテナントごとに個別のインスタンスを作成するよりも、新しいテナントを追加する際に必要なリソースがはるかに少なくて済みます。重要な点として、マルチテナントでは、テナントごとに厳重なデータ分離を行い、アクセス制御と暗号化によって機密情報を不正アクセスから保護することで、堅牢なデータセキュリティを維持します。さらに、アップデート、パッチ、新機能をすべてのテナントに同時に展開できるため、システムのメンテナンスが簡素化され、管理者の負担が軽減されるとともに、セキュリティとコンプライアンスの基準が一貫して維持されます。

Milvusにおけるマルチテナント戦略

Milvusがどのようにマルチテナントをサポートしているかを理解するためには、まずユーザデータをどのように整理しているかを見ることが重要です。

Milvusのユーザーデータ整理方法

Milvusはデータを3つのレイヤーに分け、大まかなものから細かいものへと分類しています：データベース、コレクション、パーティション/パーティション・キーです。

図- Milvusによるユーザーデータの整理方法 .png

図：Milvusによるユーザデータの整理方法

• データベース：これは論理的なコンテナとして機能し、従来のリレーショナルシステムにおけるデータベースに似ている。

• コレクション：データベース内のテーブルと同様に、コレクションはデータを管理可能なグループに整理する。

• パーティション/パーティション・キー：コレクション内では、データをパーティションでさらに区分することができる。パーティション・キーを使用すると、同じキーを持つデータが一緒にグループ化されます。たとえば、ユーザーIDを パーティション・キーとして使用すると、特定のユーザーのすべてのデータが同じ論理セグメントに保存されます。これにより、個々のユーザに関連付けられたデータを簡単に取得できます。

データベースから コレクション、パーティション・キーに移行するにつれて、データ編成の粒度は徐々に細かくなります。

より強固なデータセキュリティと適切なアクセスコントロールを実現するため、Milvusは堅牢なロールベースアクセスコントロール（RBAC）も提供しており、管理者は各ユーザに特定の権限を定義することができます。許可されたユーザのみが特定のデータにアクセスすることができます。

Milvusは、データベースレベル、コレクションレベル、パーティションレベルのマルチテナンシーなど、アプリケーションのニーズに応じた柔軟なマルチテナンシーを実装するための複数の戦略をサポートしています。

データベースレベルのマルチテナンシー

データベースレベルマルチテナンシーでは、各テナントは同じMilvusクラスタ内で独自のデータベースを割り当てられます。この戦略により、強力なデータ分離が実現し、最適な検索パフォーマンスが保証されます。しかし、特定のテナントが非アクティブのままである場合、非効率的なリソース利用につながる可能性があります。

コレクションレベルマルチテナンシー

ここで、コレクションレベルのマルチテナントでは、2つの方法でテナントのデータを整理することができます。

• すべてのテナントに1つのコレクション：すべてのテナントが1つのコレクションを共有し、テナント固有のフィールドがフィルタリングに使用されます。実装は簡単ですが、この方法ではテナントの数が増えるにつれてパフォーマンスのボトルネックが発生する可能性があります。

• テナントごとに1つのコレクション：各テナントは専用のコレクションを持つことができ、分離とパフォーマンスが向上しますが、より多くのリソースが必要になります。テナント数がMilvusのコレクションキャパシティを超えた場合、この設定はスケーラビリティの制限に直面する可能性があります。

パーティションレベルのマルチテナント

Partition-Level Multi-Tenancy は、単一のコレクション内でテナントを編成することに重点を置いています。ここでは、テナントデータを整理する2つの方法もあります。

• テナントごとに1つのパーティション：テナントはコレクションを共有しますが、データは別々のパーティションに保存されます。各テナントに専用のパーティションを割り当てることで、データを分離し、分離と検索パフォーマンスのバランスをとることができます。しかし、このアプローチはMilvusの最大パーティション数制限に制約されます。

• パーティションキーベースのマルチテナント：これは、単一のコレクションがパーティション・キーを使用してテナントを区別する、よりスケーラブルなオプションです。この方法はリソース管理を簡素化し、より高いスケーラビリティをサポートしますが、大量のデータ挿入をサポートしません。

以下の表は、主なマルチテナンシー・アプローチの主な違いをまとめたものです。

粒度	データベースレベル	コレクションレベル	パーティション・キー・レベル
最大テナント数	~1,000	~10,000	~10,000,000
データ編成の柔軟性	高：ユーザーはカスタムスキーマで複数のコレクションを定義できる。	中：ユーザはカスタムスキーマで1つのコレクションに制限される。	低：すべてのユーザーがコレクションを共有し、一貫したスキーマが必要。
ユーザーあたりのコスト	高	中	低
物理的リソースの分離	あり	あり	なし
RBAC	はい	はい	いいえ
検索パフォーマンス	強い	中	強い

例RAGナレッジベースのマルチテナント戦略

RAGシステムのマルチテナント戦略を設計する際には、お客様のビジネスとテナントの具体的なニーズに合わせたアプローチが不可欠です。Milvusは様々なマルチテナント戦略を提供しており、テナントの数、要件、必要なデータ分離のレベルによって適切な戦略を選択することができます。ここでは、RAGを利用したエンタープライズナレッジベースを例に、これらの決定を行うための実践的なガイドを示します。

マルチテナント戦略を選択する前にテナント構造を理解する

RAGを利用したエンタープライズナレッジベースは、多くの場合少数のテナントにサービスを提供しています。これらのテナントは通常、IT、営業、法務、マーケティングなどの独立したビジネスユニットであり、それぞれが個別のナレッジベースサービスを必要とします。例えば、人事部門は、入社案内や福利厚生方針などの機密情報を管理し、人事担当者のみがアクセスできるようにします。

この場合、各事業部門は独立したテナントとして扱われるべきであり、データベースレベルのマルチテナント戦略が最適であることが多い。各テナントに専用のデータベースを割り当てることで、組織は強力な論理的分離を実現し、管理を簡素化し、セキュリティを強化することができる。この設定はテナントに大きな柔軟性を提供します。テナントはコレクション内でカスタムデータモデルを定義し、必要な数のコレクションを作成し、コレクションのアクセス制御を独立して管理することができます。

物理的リソースの分離によるセキュリティの強化

データ・セキュリティが非常に優先される状況では、データベース・レベルでの論理的な分離では不十分な場合があります。例えば、ビジネス・ユニットによってはクリティカルなデータや機密性の高いデータを扱う場合があり、他のテナントからの干渉に対してより強力な保証が必要になることがあります。このような場合、データベースレベルのマルチテナント構造の上に物理的な分離アプローチを実装することができます。

Milvusではデータベースやコレクションなどの論理コンポーネントを物理リソースにマッピングすることができます。この方法により、他のテナントの活動が重要なオペレーションに影響を与えないようにすることができます。このアプローチが実際にどのように機能するのかを探ってみよう。

図- Milvusによる物理リソースの管理方法.png

図：Milvusの物理リソース管理方法

上図に示すように、Milvusのリソース管理には3つのレイヤーがある：クエリノード、リソースグループ、データベースです。

• クエリノード：クエリタスクを処理するコンポーネント。物理マシンまたはコンテナ（KubernetesのPodなど）上で動作する。

• リソースグループ：論理コンポーネント（データベースとコレクション）と物理リソースの橋渡しをするQuery Nodeの集まり。1つのResource Groupに1つ以上のデータベースやコレクションを割り当てることができる。

上図の例では、3 つの論理データベースがあります：X、Y、およびZです。

• データベースX：コレクションAを含む。

• データベースY：コレクションBと Cを含む。

• データベースZ:コレクションDと Eを含む。

データベースXには、データベースYまたはデータベースZからの負荷の影響を受けたくない重要な知識ベースが格納されているとします：

• データベースXは、その重要な知識ベースが他のデータベースからのワークロードの影響を受けないことを保証するために、独自のリソースグループを割り当てられます。

• コレクションEも親データベース（Z）内の別のリソースグループに割り当てられます。これにより、共有データベース内の特定のクリティカル・データのコレクション・レベルでの分離が実現します。

一方、データベースYと Zの残りのコレクションはリソースグループ2の物理リソースを共有します。

論理コンポーネントを物理リソースに注意深くマッピングすることで、組織は特定のビジネス・ニーズに合わせた柔軟で拡張性のあるセキュアなマルチテナンシー・アーキテクチャを実現できます。

エンドユーザーレベルのアクセス設計

エンタープライズRAGのマルチテナント戦略を選択するためのベストプラクティスを学んだところで、このようなシステムにおけるユーザーレベルのアクセスをどのように設計するかを探ってみよう。

このようなシステムでは、エンドユーザは通常、LLMを通じて読み取り専用モードでナレッジベースと対話します。しかし、組織は、ナレッジベースの精度を向上させたり、パーソナライズされたサービスを提供したりするなどのさまざまな目的のために、ユーザーによって生成されたそのようなQ&Aデータを追跡し、特定のユーザーにリンクする必要があります。

病院のスマート相談窓口を例にとってみよう。患者は、"今日の専門医の予約は空いていますか？"とか、"今度の手術に必要な特別な準備はありますか？"といった質問をするかもしれない。これらの質問はナレッジベースに直接影響を与えるものではありませんが、病院にとってこのようなやり取りを追跡することはサービス向上のために重要です。これらのQ&Aペアは通常、インタラクションのログ専用の別のデータベース（必ずしもベクトルデータベースである必要はない）に保存される。

図- エンタープライズRAGナレッジベースのマルチテナンシーアーキテクチャ .png

図エンタープライズRAG知識ベースのマルチテナンシーアーキテクチャ

上の図は、エンタープライズRAGシステムのマルチテナンシーアーキテクチャを示しています。

• システム管理者は、RAGシステムを監督し、リソースの割り当てを管理し、データベースを割り当て、リソースグループにマッピングし、スケーラビリティを確保します。システム管理者は、図に示すように、各リソースグループ（リソースグループ1、2、3など）が物理サーバー（クエリノード）にマッピングされる物理インフラストラクチャを処理します。

• テナント（データベースの所有者と開発者）は、図に示すように、ユーザーが生成したQ&Aデータに基づいて知識ベースを反復して管理する。異なるデータベース（データベースX、Y、Z）には、異なるナレッジベースのコンテンツを持つコレクションが含まれます（コレクションA、Bなど）。

• エンドユーザーは、LLMを通じて読み取り専用でシステムと対話します。彼らがシステムに問い合わせると、その質問は別のQ&Aレコードテーブル（別のデータベース）に記録され、貴重なデータが継続的にシステムにフィードバックされます。

この設計により、ユーザーとのやり取りからシステム管理まで、各プロセス層がシームレスに機能し、組織が強固で継続的に改善されるナレッジベースを構築できる。

まとめ

このブログでは、マルチテナンシー・フレームワークが、RAGを利用したナレッジベースのスケーラビリティ、セキュリティ、およびパフォーマンスにおいて、いかに重要な役割を果たすかについて説明しました。テナントごとにデータとリソースを分離することで、企業はプライバシー、規制遵守、共有インフラ全体での最適なリソース割り当てを確保することができます。Milvusの柔軟なマルチテナント戦略により、企業はデータベースレベルからパーティションレベルまで、特定のニーズに応じて適切なデータ分離レベルを選択することができます。適切なマルチテナンシー・アプローチを選択することで、多様なデータやワークロードを扱う場合でも、企業はテナントに合わせたサービスを提供することができます。

ここで説明するベストプラクティスに従うことで、企業は優れたユーザーエクスペリエンスを提供するだけでなく、ビジネスニーズの成長に合わせて容易に拡張できるマルチテナントRAGシステムを効果的に設計・管理することができます。Milvusのアーキテクチャは、企業が高レベルの分離、セキュリティ、およびパフォーマンスを維持できることを保証し、エンタープライズグレードのRAGを搭載したナレッジベースを構築する上で極めて重要な要素となっています。

マルチテナントRAGの詳細について

このブログでは、Milvusのマルチテナント戦略がどのようにテナントを管理するように設計されているかを説明しましたが、テナント内のエンドユーザを管理するようには設計されていません。エンドユーザーとのやり取りは通常アプリケーションレイヤーで行われ、ベクターデータベース自体はエンドユーザーを意識することはありません。

あなたは疑問に思うかもしれない：各エンドユーザーのクエリ履歴に基づいてより正確な回答を提供したい場合、Milvusは各ユーザーにパーソナライズされたQ&Aコンテキストを維持する必要があるのではないでしょうか？

素晴らしい質問ですね。答えはユースケースによります。例えば、オンデマンドの相談サービスでは、クエリはランダムであり、ユーザーの過去のコンテキストを追跡することよりも、ナレッジベースの質に主眼が置かれます。

しかし、他のケースでは、RAGシステムはコンテキストを認識する必要がある。このような場合、Milvusはアプリケーション層と連携して、各ユーザーのコンテキストをパーソナライズして記憶する必要がある。この設計は、大規模なエンドユーザーを持つアプリケーションでは特に重要である。さらなる洞察にご期待ください！