Tablestore:アーキテクチャとテクノロジーの選定

システムアーキテクチャ

ナレッジストレージサービスは、フルマネージドのサーバーレスアーキテクチャ上に構築されています。お客様は API を介してサービスを利用し、基盤となるインフラストラクチャはプラットフォームが自動的に管理します。データフローは次のとおりです。

1. AddDocuments API を呼び出して、Object Storage Service (OSS) 内のファイルへのパスを指定するか、SDK を使用してローカルファイルをアップロードします。

2. サービスが OSS からファイルを読み取り、ドキュメントを自動的に解析してチャンクに分割します。

3. 各チャンクについて、サービスが埋め込みモデルを呼び出してベクトルを生成し、Tablestore のチャンクテーブルに書き込みます。

4. サービスがベクトルインデックスと全文検索インデックスを自動的に構築します。

5. Retrieve API を呼び出すと、サービスがハイブリッド検索を実行し、関連するチャンクを返します。

元のドキュメント、解析結果、ベクトルデータを含むすべてのデータは、お客様のアカウント内の OSS インスタンスおよび Tablestore インスタンスに保存されます。サービス自体はお客様のデータを保持しません。ストレージとコンピュートは分離されており、それぞれ個別に課金されます。

データモデル

ナレッジベースは、4 層のエンティティ構造で構成されます。

サービスは、対応するデータテーブルを Tablestore に自動的に作成します。

• ドキュメントテーブル：{knowledge_base_name}_{knowledge_base_id}

• チャンクテーブル：{knowledge_base_name}_{knowledge_base_id}_chunk

• インデックス テーブル： {knowledge_base_name}_{knowledge_base_id}_index

データソース

ナレッジベースのデータソースは OSS です。アップロード方法にかかわらず、元のドキュメントはお客様自身の OSS バケットに保存されます。

ナレッジベースには、OSS バケットに対する読み取りおよび書き込み権限が必要です。解析とチャンク分割のために元のドキュメントを読み取り、解析プロセスの中間結果を OSS に書き戻します。

次の 3 つの方法のいずれかで、ドキュメントをナレッジベースにインポートできます。

• ローカルファイルのアップロード：ローカルのファイルまたはディレクトリを指定します。SDK が自動的に OSS にアップロードし、その後ナレッジベースに追加します。ディレクトリを指定した場合、SDK はその配下のすべてのファイルを再帰的に探索します。

• OSS ファイルの追加：ファイルがすでに OSS に存在する場合は、OSS パスを指定してナレッジベースに直接追加できます。

• OSS ディレクトリからの一括インポート：OSS ディレクトリパスを指定します。サービスは、ディレクトリ内のすべてのファイルを自動的かつ再帰的にスキャンします。inclusionFilters と exclusionFilters を使用して、ファイル名のパターンに基づいてファイルをフィルタリングできます。

各方法の詳細な手順については、「Document management」をご参照ください。

埋め込み設定

埋め込み設定は、ドキュメントチャンクをどのようにベクトルに変換するかを決定します。この設定は、ナレッジベースの作成時に指定します。

embeddingConfiguration を指定しない場合、サービスはデフォルトで、ほとんどのユースケースに適した Model Studio の text-embedding-v4 モデル (1024 次元) を使用します。

モデル選定の推奨事項：

• 汎用的な中国語および英語のシナリオでは、text-embedding-v4 (1024 次元) を推奨します。これは、意味理解とパフォーマンスのバランスに優れています。

• 自社開発またはサードパーティの埋め込みサービスをすでにお持ちの場合は、custom モードを使用して統合することで、一貫した技術スタックを維持できます。

• 次元が高いほど、より豊かな意味を表現できますが、ストレージとコンピュートのコストが増加します。ほとんどのユースケースでは 1024 次元を推奨します。

検索戦略

Retrieve API を呼び出すと、取得設定 (retrievalConfiguration) は、以下の優先順位に基づいて決定されます：

マルチテナンシー向けの Subspace

Subspace は、ナレッジベース内にデータ分離パーティションを提供します。この機能は、同じナレッジベース内でユーザー、部門、またはテナントごとにデータを分離する必要があるシナリオに最適です。有効にするには、ナレッジベースを作成するときに "subspace": true を設定します。

主なルール：

• Subspace を有効にすると、すべてのドキュメント操作 (追加、クエリ、削除、リスト) および取得呼び出しで必ず subspace フィールドを指定する必要があります。そうしないと、サービスはエラーを返します。

• Retrieve API は、Subspace 名のリストを渡すことで、複数の Subspace を同時にクエリできます。最大 32 件まで指定できます。

• Subspace 名の最大長は 128 文字です。

• Subspace の設定は、ナレッジベース作成後に変更できません。

例えば、企業環境では、部門の各従業員は独自のドキュメントセットを持っています。 部門の管理者は、Subspace が有効化された単一のナレッジベースを作成し、各従業員に一意の Subspace (例えば、employee_alice や employee_bob など) を割り当てることができます。 これにより、各従業員のドキュメントは他の従業員から分離される一方、管理者はナレッジベースの設定を一元管理できます。 従業員を横断した検索を実行するには、管理者は、単一の Retrieve コールで複数の Subspace 名を渡して、フェデレーテッド検索を実行できます。

適合性評価

推奨：

• 大規模言語モデル (LLM) アプリケーション向けに、検索拡張生成 (RAG) の機能を構築する場合。

• ベクトル検索と全文検索を組み合わせたハイブリッド検索を実装する場合。

• マルチテナンシーのデータ分離が必要な場合。

• 数百から数十億までスケールするドキュメントコレクションを管理する場合。

• すべてのデータをご自身のアカウント内に保持する必要があるなど、厳格なデータセキュリティを求める場合。

• 従量課金で、運用管理が不要なソリューションを求める場合。

要検討：

• インデックスの鮮度が極めて重要なシナリオ。ドキュメント取り込みは非同期プロセスであるため、コンテンツが検索可能になるまでにレイテンシが発生します。

• カスタムのドキュメントチャンク分割戦略が必要なシナリオ。現時点では、サービスは自動チャンク分割プロセスを使用します。

非推奨：

• 構造化データのみをクエリする場合。この用途には、Tablestore のワイドカラムモデル、またはリレーショナルデータベースの使用を推奨します。

• リアルタイムのストリーミングデータのインデックスを作成する場合。この用途には、Tablestore の Search Index 機能を直接使用することを推奨します。