Retrieve API を使用してナレッジベースでセマンティック検索を実行し、クエリに対して最も関連性の高いチャンクを返します。この API は、ベクトル取得、全文検索、ハイブリッド検索、メタデータフィルター、および各種リランク戦略をサポートします。
取得設定の優先順位
Retrieve API の取得設定 (retrievalConfiguration) は、以下の優先度に基づいて有効になるパラメーターを決定します:
優先順位 | ソース | 説明 |
1 (最優先) | Retrieve API パラメータ | 提供された |
2 | ナレッジベースレベルの設定 | ナレッジベースの作成時に設定します。UpdateKnowledgeBase API を使用して、いつでも変更できます。 |
3 (最低) | システムのデフォルト | WEIGHT 戦略による重み付きフュージョン (ベクトル取得 0.7:全文検索 0.3) を用いたハイブリッド検索 (ベクトル取得 + 全文検索) を実行し、20 件の結果を返します。 |
最もシンプルな検索リクエストには、knowledgeBaseName と retrievalQuery のみが必要です。システムは自動的にナレッジベースの設定またはデフォルト値を使用します。
検索タイプ
タイプ | 説明 | ユースケース |
| 意味的類似性に基づくベクトル取得。 | 意味的な意図の理解が重要な、自然言語で表現されたクエリに最適です。たとえば、「how to install」というクエリでも、「deployment steps」に関するコンテンツにマッチできます。 |
| キーワードマッチングに基づく全文検索。 | 厳密なキーワード、固有名詞、識別子を含むクエリに使用します。 |
ベクトル取得と全文検索は相補的です。ベクトル取得は意味理解に優れ、全文検索は厳密一致に有効です。両方の検索タイプを有効にし、リランクで結果をフュージョンすることを推奨します。
リランク戦略
リランクは、ベクトル取得と全文検索の結果をフュージョンし、並べ替えて最終的な結果セットを生成します。
WEIGHT (重み付きフュージョン)
この戦略では、ベクトル取得と全文検索の両方の結果に重み付きスコアを適用します。各検索手法の寄与度を細かく制御したいシナリオに最適です。これが推奨されるデフォルト戦略です。
設定パラメータ:
パラメータ | 型 | デフォルト | 説明 |
| double | 0.7 | ベクトル取得の重み付け比率。 |
| double | 0.3 | 全文検索の重み付け比率。 |
RRF (Reciprocal Rank Fusion)
この戦略では、複数の検索手法の結果を、それぞれの順位の逆数に基づいて重み付けし、フュージョンします。追加のモデル呼び出しなしで、安定したパフォーマンスと低レイテンシーを実現します。
設定パラメータ:
パラメータ | 型 | デフォルト | 説明 |
| double | 1.0 | ベクトル取得の重み。 |
| double | 1.0 | 全文検索の重み。 |
| int | 60 | RRF アルゴリズムのパラメータ。0 より大きい値を指定する必要があります。 |
設定例:
{
"rerankingConfiguration": {
"type": "RRF",
"numberOfResults": 5,
"rrfConfiguration": {
"denseVectorSearchWeight": 0.6,
"fullTextSearchWeight": 0.4,
"k": 20
}
}
}MODEL (モデルリランク)
gte-rerank-v2 などのリランクモデルを呼び出して候補結果を再ランキングすると、最高のランキング品質が得られますが、追加のレイテンシーと計算コストが発生します。
設定パラメータ:
パラメータ | 型 | デフォルト | 説明 |
| string |
| リランクモデルのプロバイダー。 |
| string |
| リランクモデルの名前。 |
戦略の選択
シナリオ | 推奨戦略 |
レイテンシーに敏感な汎用シナリオ。 | RRF |
ベクトル取得と全文検索の結果の比率を細かく制御する必要があるシナリオ。 | WEIGHT |
最高のランキング品質が求められ、追加のレイテンシーを許容できるシナリオ。 | MODEL |
メタデータフィルター
検索時に、filter パラメーターを使用してメタデータ条件で結果をフィルタリングし、候補プールを絞り込みます。フィルタリングフィールドは、ナレッジベースの作成時に metadata で定義されている必要があります。
比較演算子
演算子 | 記号 | 説明 | 適用可能な型 |
| = | 等しい | すべての型 |
| ≠ | 等しくない | すべての型 |
| > | より大きい | long、 double、 date |
| ≥ | 以上 | long、 double、 date |
| < | より小さい | long、 double、 date |
| ≤ | 以下 | long、 double、 date |
集合演算子とマッチング演算子
演算子 | 説明 | 適用可能な型 |
| 指定した集合に値が含まれます。 | すべての型 |
| 指定した集合に値が含まれません。 | すべての型 |
| 文字列のプレフィックスにマッチします。 | string |
| 部分文字列にマッチします。 | string |
| リスト型フィールドに、指定した要素が含まれるかどうかを確認します。 | list |
論理結合演算子
演算子 | 説明 |
| すべての条件を満たす必要があります。 |
| 少なくとも 1 つの条件を満たす必要があります。 |
| すべての条件を満たすわけではありません。 |
andAll、orAll、およびnotAllをネストして、複雑な複合フィルタリングロジックを構築できます。
フィルターの例
category が "technology" または "science" で、score が ≥ 60、かつ title が "Product" で始まるドキュメントを検索します:
{
"filter": {
"andAll": [
{"in": {"key": "category", "value": ["technology", "science"]}},
{"greaterThanOrEquals": {"key": "score", "value": 60}},
{"startsWith": {"key": "title", "value": "Product"}}
]
}
}orAll を使用して OR ロジックを実装し、ステータスが "active" であるか、スコアが 90 より大きいドキュメントをクエリします。
{
"filter": {
"orAll": [
{"equals": {"key": "status", "value": "active"}},
{"greaterThan": {"key": "score", "value": 90}}
]
}
}Retrieve API
リクエストパラメータ
パラメータ | 型 | 説明 |
| string | ナレッジベースの名前。必須。 |
| list<string> | サブスペースのリスト。最大 32 個。サブスペースが有効な場合は必須です。 |
| object | 取得クエリ。必須。 |
| string | クエリタイプ(必須)。 |
| string | クエリテキスト。必須。 最大 128 文字。 |
| object | 取得設定。指定しない場合は、ナレッジベースレベルの設定またはシステムのデフォルトが使用されます。 |
| list<string> | 検索タイプ。 |
| int | ベクトル取得で返す結果数。最大:100。 |
| int | 全文検索で返す結果数。最大:100。 |
| object | リランク設定。 |
| object | メタデータフィルター条件。 |
レスポンス
レスポンスフィールド
フィールド | 型 | 説明 |
| list<object> | 関連性スコアの降順にソートされた取得結果のリスト。 |
| string | チャンクが属するドキュメントの ID。 |
| int | チャンクの ID。 |
| string | ソースドキュメントの OSS パス。 |
| フロート | 関連性スコア。スコアが高いほど一致度が高いことを示します。 |
| string | チャンクの元のコンテンツ。 |
| string | チャンクが属するサブスペース。 |
| object | ドキュメントのメタデータ。 |
コード例
最小例
この例では、リクエスト内で取得パラメータを設定しません。システムはナレッジベースレベルの設定またはシステムのデフォルトを使用します:
resp = client.retrieve({
"knowledgeBaseName": "product_docs_kb",
"retrievalQuery": {"type": "TEXT", "text": "What are the installation steps for the product?"}
})
for r in resp["data"]["retrievalResults"]:
print(f"[{r['score']:.4f}] {r['content'][:80]}...")完全な例
この例では、リクエスト内で取得パラメータを設定して、ナレッジベースレベルの設定を上書きします:
resp = client.retrieve({
"knowledgeBaseName": "product_docs_kb",
"subspace": ["default"],
"retrievalQuery": {"type": "TEXT", "text": "What are the installation steps for the product?"},
"retrievalConfiguration": {
"searchType": ["DENSE_VECTOR", "FULL_TEXT"],
"denseVectorSearchConfiguration": {"numberOfResults": 10},
"fullTextSearchConfiguration": {"numberOfResults": 10},
"rerankingConfiguration": {
"type": "RRF",
"numberOfResults": 5,
"rrfConfiguration": {
"denseVectorSearchWeight": 0.6,
"fullTextSearchWeight": 0.4,
"k": 60
}
},
"filter": {
"andAll": [
{"in": {"key": "category", "value": ["Product Documentation"]}}
]
}
}
})
for result in resp["data"]["retrievalResults"]:
print(f"[score={result['score']:.4f}] {result['content'][:100]}...")
print(f" Source: {result['ossKey']}, chunkId: {result['chunkId']}")モデルクラスの使用
提供されているモデルクラスを使用してリクエストを構築することで、IDEでのコード補完と型チェックが改善されます:
from tablestore_agent_storage.models import (
RetrieveRequest, RetrievalQuery, RetrievalQueryType
)
resp = client.retrieve(RetrieveRequest(
knowledge_base_name="product_docs_kb",
retrieval_query=RetrievalQuery(
text="What are the installation steps for the product?",
type=RetrievalQueryType.TEXT
)
))レスポンス例
{
"code": "SUCCESS",
"data": {
"retrievalResults": [
{
"ossKey": "oss://example-bucket/docs/product_manual.pdf",
"docId": "96fb386e-...",
"chunkId": 3,
"subspace": "default",
"score": 0.85,
"content": "Step 1: Download the installation package...",
"metadata": {"author": "田中太郎", "category": "Product Documentation"}
}
]
},
"message": "succeed"
}注意事項
問題 | 説明 |
クエリテキストが長すぎます |
説明 特定のビジネス要件については、チケットを送信するか、Tablestore 技術交流グループ (ID:36165029092) に参加して、テクニカルサポートにお問い合わせください。 |
フィルターフィールドが定義されていません | フィルターフィールドは、ナレッジベース作成時にメタデータとして定義しておく必要があります。 |
RRF の |
|
ドキュメントのインデックス作成が完了していません | ステータスが |
| ナレッジベースでサブスペースが有効な場合、このパラメータは必須です。 |
パフォーマンスチューニング
numberOfResults パラメータの関係
取得プロセスには、numberOfResults の 3 つのレイヤーがあり、これらの関係を理解することがチューニングの鍵となります:
denseVectorSearchConfiguration.numberOfResults = N1 // ベクトル検索で取得する候補数
fullTextSearchConfiguration.numberOfResults = N2 // 全文検索で取得する候補数
rerankingConfiguration.numberOfResults = N3 // リランク後の最終結果数N1 と N2 は候補プールのサイズを決定します。値を大きくすると再現率は向上しますが、計算コストも増加します。
N3 は返す最終結果数を決定します。通常、N3 は N1 と N2 の両方より小さくする必要があります。
推奨する初期設定:N1 と N2 を 20 に設定し、N3 を 5〜10 の範囲の値に設定します。結果に基づいて段階的に調整してください。
検索タイプの選択
シナリオ | 推奨検索タイプ | 説明 |
自然言語で質問する |
| ベクトル取得は意味を捉え、全文検索はキーワードヒットを担保します。 |
厳密なキーワードや識別子で検索する |
| ベクトル取得は厳密一致に敏感ではありません。 |
純粋に意味理解が必要なシナリオ |
| たとえば、「how to install」を「deployment steps」にマッチさせます。 |
メタデータフィルターの使用
フィルターは検索フェーズの前に候補プールを刈り込み、精度とパフォーマンスの両方を向上させます。
フィルターフィールドは、ナレッジベース作成時にメタデータとして定義しておく必要があり、実行時に追加することはできません。
日付範囲のフィルタリングでは、範囲比較演算子をサポートするために、
string型ではなくdate型を使用します。