Azure AI 検索でハイブリッド クエリを作成する

ハイブリッド検索 では、テキスト (キーワード) クエリとベクター クエリが 1 つの検索要求に結合されます。 どちらのクエリも並列で実行されます。 結果は、新しい検索スコアによってマージおよび並べ替えられ、逆ランク融合 (RRF) を使用して統一された結果セットが返されます。 多くの場合、 ベンチマーク テストごとに、セマンティック ランク付けを使用したハイブリッド クエリは最も関連性の高い結果を返します。

この記事では、次の方法について説明します。

• 基本的なハイブリッド要求を設定する
• パラメーターとフィルターを追加する
• セマンティック ランク付けまたはベクターの重みを使用して関連性を向上させる
• 入力を制御してクエリの動作を最適化する (maxTextRecallSize)

この記事の終わりまでに、キーワードとベクター検索とオプションのセマンティック ランク付けを組み合わせたハイブリッド クエリを実行できます。

前提 条件

• Azure サブスクリプション。 無料で作成します。

• Azure AI 検索 サービス。 サービスの作成または既存のサービスを見。

• ベクター フィールドと非ベクトル フィールド searchable 含む検索インデックス。 インデックスをすばやく作成するには、 データのインポート ウィザード をお勧めします。 それ以外の場合は、「 インデックスの作成」 と 「検索インデックスへのベクター フィールドの追加」を参照してください。

• アクセス許可: インデックスのクエリを実行するには、 インデックス データ閲覧者を検索 する必要があります。 インデックスを作成または更新するには、 検索インデックス データ共同作成者が必要です。 詳細については、「 ロールを使用した接続」を参照してください。

• (省略可能) SDK のインストール:

  • パイソン: pip install azure-search-documents
  • C#: dotnet add package Azure.Search.Documents

• (省略可能)クエリ文字列の組み込みのテキストからベクターへの変換が必要な場合は、検索インデックス内のベクター フィールドに ベクター 化を作成して割り当てます 。

API、ツール、実行可能パターンを選択する

• Azure ポータルの検索エクスプローラー (安定した API 検索構文とプレビュー API 検索構文の両方をサポート) には、ハイブリッド要求を貼り付ける JSON ビューがあります。

• Azure SDKの新しい安定したパッケージまたはプレビュー パッケージ (SDK 機能サポートの変更ログを参照)。

• maxTextRecallSize や countAndFacetMode (プレビュー) などのプレビュー機能を使用している場合は、安定した REST API または最新のプレビュー API バージョン。

  読みやすくするために、REST の例を使用して、API のしくみを説明します。 REST 拡張機能でVisual Studio Codeのような REST クライアントを使用して、ハイブリッド クエリを作成できます。 Azure SDKを使用することもできます。 詳細については、「 クイック スタート: ベクター検索」を参照してください。

実行可能なハイブリッド パターン

ハイブリッド検索を初めて使用する場合は、1 つのパターンを選択し、小さな手順で調整します。 同じ要求で、最大ベクター呼び出し、大きなテキストの再呼び出し、セマンティック再ランク付けから始めないでください。

• バランスの取れたハイブリッド (既定) : ほとんどのワークロードで最初に使用します。 30 ~ 50 の範囲の k から開始し、10 ~ 20 の範囲で top し、測定された関連性が向上した場合にのみセマンティック ランク付けを有効にします。

• 再現率優先ハイブリッド: カバレッジが目標となる難しいクエリに用います。 maxTextRecallSizeを徐々に増やし、ベクター設定を中程度に保ちます。 マージ コストの増加が予想されます。

• 精度優先ハイブリッド: 大規模な待機時間が短い場合に使用します。 kとtop控えめにし、選択的フィルターを適用し、価値を追加しないセマンティック機能を回避します。

オーバーロードされたクエリがスロットルされる理由

ハイブリッド クエリでは、テキストとベクターの取得が並列で実行され、結果が RRF とマージされます。 字句の貢献度を高める場合 (たとえば、BM25 を優先してハイブリッド重みを変更するなど)、ベクター候補とマージする必要があるテキスト候補の数を増やします。 これを高価なベクター設定とセマンティック再ランク付けと組み合わせると、CPU とメモリの負荷が急速に上昇します。

容量構成が小さい場合、この追加のマージと再ランク付け作業によって、次の原因が生じる可能性があります。

• レイテンシーの上昇と p95/p99 スパイクの増加
• 429 スロットリング応答
• クライアントが再試行動作を構成していない場合、中止またはタイムアウトした要求を観察しました。

スケールアウト前のチューニング順序

レプリカを追加する前に、クエリとベクターの設定を調整します。

1. まず、コストのかかるベクター検索設定を減らします。 たとえば、 efSearch と maxConnections が積極的に設定されている場合は、スケールアウトする前にそれらを小さくします (たとえば、 efSearch を約 800 から 128 から 192 に減らし、 maxConnections を 64 から 32 に減らします)。
2. セマンティック再ランク付けスコープを、その恩恵を受けるケースに制限します。
3. 代表的な負荷の下で待機時間と 429 のレートを再テストします。
4. チューニング後もスロットリングが続く場合のみ、レプリカをスケーリングします。

このシーケンスを使用して、最初に安定性を向上させ、スケーリングする前にコストを制御します。

ハイブリッド クエリを設定する

このセクションでは、ハイブリッド クエリの基本的な構造と、Search Explorer または REST クライアントで実行するクエリを設定する方法について説明します。

結果は、 retrievableとしてマークされたフィールドのベクターを含むプレーン テキストで返されます。 数値ベクトルは検索結果では役に立たないため、インデックス内の他のフィールドをベクター一致のプロキシとして選択します。 たとえば、インデックスに "descriptionVector" フィールドと "descriptionText" フィールドがある場合、クエリは "descriptionVector" で一致しますが、検索結果には "descriptionText" と表示されます。 結果で人間が判読できるフィールドのみを指定するには、 select パラメーターを使用します。

POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version=2026-04-01
Content-Type: application/json
api-key: {{admin-api-key}}
{
    "vectorQueries": [
        {
            "vector": [
                -0.009154141,
                0.018708462,
                . . . 
                -0.02178128,
                -0.00086512347
            ],
            "fields": "DescriptionVector",
            "kind": "vector",
            "exhaustive": true,
            "k": 10
        },
        {
            "vector": [
                -0.009154141,
                0.018708462,
                . . . 
                -0.02178128,
                -0.00086512347
            ],
            "fields": "DescriptionVector",
            "kind": "vector",
            "exhaustive": true,
            "k": 10
        }
    ],
    "search": "historic hotel walk to restaurants and shopping",
    "select": "HotelName, Description, Address/City",
    "top": 10
}

import os
from azure.identity import DefaultAzureCredential
from azure.search.documents import SearchClient
from azure.search.documents.models import VectorizedQuery

# Set up the client
endpoint = os.environ["AZURE_SEARCH_ENDPOINT"]
index_name = "hotels-sample"
credential = DefaultAzureCredential()

client = SearchClient(endpoint=endpoint, index_name=index_name, credential=credential)

# Define your vector (typically from an embedding model)
query_vector = [-0.009154141, 0.018708462, ...]  # Your embedding values

# Create the vector query
vector_query = VectorizedQuery(
    vector=query_vector,
    k_nearest_neighbors=10,
    fields="DescriptionVector",
    exhaustive=True
)

# Execute hybrid search
results = client.search(
    search_text="historic hotel walk to restaurants and shopping",
    vector_queries=[vector_query],
    select=["HotelName", "Description", "Address/City"],
    top=10
)

for result in results:
    print(f"{result['HotelName']}: {result['Description']}")

using Azure;
using Azure.Identity;
using Azure.Search.Documents;
using Azure.Search.Documents.Models;

// Set up the client
string endpoint = Environment.GetEnvironmentVariable("AZURE_SEARCH_ENDPOINT");
string indexName = "hotels-sample";

SearchClient client = new SearchClient(
    new Uri(endpoint),
    indexName,
    new DefaultAzureCredential());

// Define your vector (typically from an embedding model)
float[] queryVector = new float[] { -0.009154141f, 0.018708462f, /* ... */ };

// Execute hybrid search
SearchResults<SearchDocument> results = client.Search<SearchDocument>(
    "historic hotel walk to restaurants and shopping",
    new SearchOptions
    {
        VectorSearch = new()
        {
            Queries = {
                new VectorizedQuery(queryVector)
                {
                    KNearestNeighborsCount = 10,
                    Fields = { "DescriptionVector" },
                    Exhaustive = true
                }
            }
        },
        Select = { "HotelName", "Description", "Address/City" },
        Size = 10
    });

await foreach (SearchResult<SearchDocument> result in results.GetResultsAsync())
{
    Console.WriteLine($"{result.Document["HotelName"]}: {result.Document["Description"]}");
}

maxTextRecallSize と countAndFacetMode を設定する (プレビュー)

ハイブリッド クエリを調整して、各サブクエリが結合された結果にどの程度寄与するかを制御できます。 maxTextRecallSize パラメーター (プレビュー) を設定すると、ハイブリッド ランク付けモデルに渡される BM25 ランク付け結果の数が指定されます。

要求にファセットが含まれている場合は、インデックスで facetable としてマークされている非ベクトル フィールドを使用します。 ベクトル フィールドはファセット化できません。

ファセットの数は、クエリの種類によって異なります。

• テキストのみのクエリでは、ファセットはテキスト クエリに一致するドキュメントをカウントします。
• ベクターのみのクエリでは、ファセットはベクター クエリによって返された k ドキュメントをカウントします。
• ハイブリッド クエリでは、ファセットはベクターとテキストの両方の結果を考慮します。 ベクター側は、 k 最も近いドキュメントを提供します。 テキスト側は、BM25 ランクのドキュメントを提供します。 countAndFacetMode パラメーター (プレビュー) は、カウントとファセットの計算で、すべてのテキスト一致を使用するか、ランク付けに取得されたテキスト一致のみを使用するかを決定します。

maxTextRecallSizeを使用する場合は、countAndFacetModeを設定することもできます。 このパラメーターは、 count と facets テキスト クエリに一致するすべてのドキュメントを含めるか、 maxTextRecallSize ウィンドウ内で取得したドキュメントのみを含めるかを決定します。 既定値は countAllResults です。

既定の countAllResults モードでは、カウントとファセットには、RRF ランク付けのために取得されないテキスト側のドキュメントを含めることができます。これは、 maxTextRecallSize ウィンドウ外にあるためです。 maxTextRecallSizeを増やすと、ランク付けに使用できる BM25 ランク付けドキュメントの数が増えますが、kを超えてベクターの貢献度は増加しません。 ハイブリッド ランク付けのために取得したドキュメントを対象にカウントとファセットの計算を行う場合は、 countRetrievableResults を使用します。

これらのオプションを設定するには、 最新のプレビュー REST API をお勧めします。

1. プレビュー パラメーターを指定するには 、検索 - POST (プレビュー) または 検索 - GET (プレビュー) を使用します。

2. hybridSearch クエリ パラメーター オブジェクトを追加して、ハイブリッド クエリの BM25 ランクの結果で呼び出されるドキュメントの最大数を設定します。 次の 2 つのプロパティがあります。

   • maxTextRecallSize は、ハイブリッド クエリで使用される逆ランク Fusion (RRF) ランカーに提供する BM25 ランクの結果の数を指定します。 既定値は 1,000 です。 最大値は 10,000 です。

   • countAndFacetMode は、ハイブリッド クエリの数とファセット スコープを報告します。 既定の countAllResultsでは、テキスト クエリに一致するすべてのドキュメントを含む、完全なハイブリッド結果セットが使用されます。一部のテキストの一部が maxTextRecallSize ウィンドウ外にあるため、RRF ランク付けに対して取得されない場合でも同じになります。 countRetrievableResults を使用して、ランク付け用に取得されたドキュメントの範囲とファセットを指定します。これには、maxTextRecallSize の BM25 ランク付けされたドキュメントと k 件のベクターの一致が含まれます。

3. maxTextRecallSizeを設定します。

   • ベクター類似性検索が一般にハイブリッド クエリのテキスト側を上回る場合は、 maxTextRecallSize を減らします。

   • インデックスが大きく、既定値で十分な数の結果がキャプチャされていない場合は、 maxTextRecallSize を増やします。 BM25 ランクの結果セットを大きくすると、 top、 skip、 next を設定して、それらの結果の一部を取得することもできます。

次の REST の例は、 maxTextRecallSizeを設定するための 2 つのユース ケースを示しています。

最初の例では、 maxTextRecallSize を 100 に減らし、ハイブリッド クエリのテキスト側を 100 ドキュメントのみに制限します。 また、カウントとファセットの計算に取得可能なドキュメントのみを含むように countAndFacetMode も設定します。

POST https://[service-name].search.windows.net/indexes/[index-name]/docs/search?api-version=2026-08-01-preview

    { 
      "vectorQueries": [ 
        { 
          "kind": "vector", 
          "vector": [1.0, 2.0, 3.0], 
          "fields": "my_vector_field", 
          "k": 10 
        } 
      ], 
      "search": "hello world", 
      "hybridSearch": { 
        "maxTextRecallSize": 100, 
        "countAndFacetMode": "countRetrievableResults" 
      } 
    } 

2 番目の例では、 maxTextRecallSize は 5,000 に上げます。 また、top、skip、next を使用して、大きな結果セットから結果をプルします。 この場合、要求は、位置1,500から2,000までのBM25ランクの結果を、RRF合成結果セットへのテキストクエリのコントリビューションとして取得します。

POST https://[service-name].search.windows.net/indexes/[index-name]/docs/search?api-version=2026-08-01-preview

    { 
      "vectorQueries": [ 
        { 
          "kind": "vector", 
          "vector": [1.0, 2.0, 3.0], 
          "fields": "my_vector_field", 
          "k": 10 
        } 
      ], 
      "search": "hello world",
      "top": 500,
      "skip": 1500,
      "next": 500,
      "hybridSearch": { 
        "maxTextRecallSize": 5000, 
        "countAndFacetMode": "countRetrievableResults" 
      } 
    } 

リファレンス: hybridSearch | maxTextRecallSize | countAndFacetMode

ハイブリッド クエリの例

このセクションには、ハイブリッド クエリ パターンを示す複数のクエリ例があります。

例: フィルターを使用したハイブリッド検索

次の使用例は、検索インデックスの非ベクトル フィールド filterable に適用されるフィルターを追加します。

POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version=2026-04-01
Content-Type: application/json
api-key: {{admin-api-key}}
{
    "vectorQueries": [
        {
            "vector": [
                -0.009154141,
                0.018708462,
                . . . 
                -0.02178128,
                -0.00086512347
            ],
            "fields": "DescriptionVector",
            "kind": "vector",
            "k": 10
        }
    ],
    "search": "historic hotel walk to restaurants and shopping",
    "vectorFilterMode": "preFilter",
    "filter": "ParkingIncluded",
    "top": "10"
}

重要なポイント:

• フィルターは、フィルター可能なフィールドの内容に適用されます。 この例では、ParkingIncluded フィールドはブール値であり、インデックス スキーマで filterable としてマークされています。

• ハイブリッド クエリでは、クエリの実行前にフィルターを適用して、クエリの表面を減らしたり、クエリの実行後に結果をトリミングしたりできます。 "preFilter" が既定値です。 postFilterまたはstrictPostFilter (プレビュー) を使用するには、この例に示すようにフィルター処理モードを設定します。

• クエリ結果をポストフィルター処理すると、結果の数が top-n 未満になる可能性があります。

リファレンス: filter | vectorFilterMode

例: ベクター サブクエリを対象とするフィルターを使用したハイブリッド検索 (プレビュー)

最新の プレビュー REST API を使用すると、ハイブリッド要求のベクター サブクエリのみを対象とするセカンダリ フィルターを適用することで、検索要求のグローバル フィルターをオーバーライドできます。

この機能では、フィルターがベクター検索結果にのみ影響を与え、キーワードベースの検索結果は影響を受けないようにすることで、きめ細かく制御できます。

ターゲット フィルターは、 セキュリティ トリミング や地理空間検索に使用されるフィルターを含め、グローバル フィルターを完全にオーバーライドします。 セキュリティ トリミングなど、グローバル フィルターが必要な場合は、セキュリティやその他の制約が一貫して適用されるように、最上位レベルのフィルターと各ベクター レベルのフィルターの両方にこれらのフィルターを明示的に含める必要があります。

ターゲット ベクター フィルターを適用するには:

• 最も新しいプレビューの Search Documents REST API または機能を提供するAzure SDKベータ パッケージを使用します。

• 新しい vectorQueries.filterOverride パラメーター セットを OData フィルター式に追加して、クエリ要求を変更します。

フィルターのオーバーライドを追加するハイブリッド クエリの例を次に示します。 グローバル フィルター "Rating gt 3" は、実行時に filterOverrideに置き換えられます。

POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version=2026-08-01-preview

{
    "vectorQueries": [
        {
            "vector": [
                -0.009154141,
                0.018708462,
                . . . 
                -0.02178128,
                -0.00086512347
            ],
            "fields": "DescriptionVector",
            "kind": "vector",
            "exhaustive": true,
            "filterOverride": "Address/City eq 'Seattle'",
            "k": 10
        }
    ],
    "search": "historic hotel walk to restaurants and shopping",
    "select": "HotelName, Description, Address/City, Rating",
    "filter": "Rating gt 3",
    "debug": "vector",
    "top": 10
}

例: セマンティック ハイブリッド検索

インデックス定義に セマンティック構成が含まれていると仮定すると、マージされた結果セットに対するセマンティック ランク付けを使用して、ベクター検索とキーワード検索を含むクエリを作成できます。 必要に応じて、キャプションと回答を追加できます。

ベクトルでセマンティック ランク付けを使用するときは常に、 k が 50 に設定されていることを確認します。 セマンティック ランカーでは、入力として最大 50 個の一致が使用されます。 50 未満を指定すると、必要な入力のセマンティック ランク付けモデルが奪われます。

POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version=2026-04-01
Content-Type: application/json
api-key: {{admin-api-key}}
{
    "vectorQueries": [
        {
            "vector": [
                -0.009154141,
                0.018708462,
                . . . 
                -0.02178128,
                -0.00086512347
            ],
            "fields": "DescriptionVector",
            "kind": "vector",
            "k": 50
        }
    ],
    "search": "historic hotel walk to restaurants and shopping",
    "select": "HotelName, Description, Tags",
    "queryType": "semantic",
    "semanticConfiguration": "my-semantic-config",
    "captions": "extractive",
    "answers": "extractive",
    "top": "50"
}

重要なポイント:

• セマンティック ランカーは、マージされた応答から最大 50 件の結果を受け入れます。

• "queryType" と "semanticConfiguration" が必要です。

• "captions" と "answers" は省略可能です。 値は、結果内の逐語的なテキストから抽出されます。 回答は、クエリに対する回答の特性を持つコンテンツが結果に含まれている場合にのみ返されます。

リファレンス: queryType | semanticConfiguration | captions | answers

例: フィルターを使用したセマンティック ハイブリッド検索

この例では、セマンティック ハイブリッド クエリに ParkingIncluded フィルターを追加します。

POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version=2026-04-01
Content-Type: application/json
api-key: {{admin-api-key}}
{
    "vectorQueries": [
        {
            "vector": [
                -0.009154141,
                0.018708462,
                . . . 
                -0.02178128,
                -0.00086512347
            ],
            "fields": "DescriptionVector",
            "kind": "vector",
            "k": 50
        }
    ],
    "search": "historic hotel walk to restaurants and shopping",
    "select": "HotelName, Description, Tags",
    "queryType": "semantic",
    "semanticConfiguration": "my-semantic-config",
    "captions": "extractive",
    "answers": "extractive",
    "filter": "ParkingIncluded",
    "vectorFilterMode": "preFilter",
    "top": "50"
}

重要なポイント:

• フィルター モードは、セマンティック ランカーで使用できる結果の数に影響を与える可能性があります。 ベスト プラクティスとして、セマンティック ランカーにドキュメントの最大数 (50) を指定します。 プレフィルターまたはポストフィルターが選択しすぎる場合は、処理するドキュメントが 50 個未満にすることで、セマンティック ランカーが不足する可能性があります。

• preFilter はクエリの実行前に適用されます。 プレフィルターによって検索領域が 100 個のドキュメントに縮小された場合、ベクター クエリは、これらの 100 個のドキュメントに対して DescriptionVector フィールドに対して実行され、k= 50 の最適な一致が返されます。 その後、一致する 50 個のドキュメントが RRF に渡され、マージされた結果が得られ、セマンティック ランカーに渡されます。

• postFilter は、クエリの実行後に適用されます。 k=50 がベクター クエリ側で 50 個の一致を返し、その後に 50 個の一致に適用された後フィルターを返す場合、結果はフィルター条件を満たすドキュメントの数だけ減少します。 これにより、セマンティック ランカーに渡すドキュメントが 50 個未満になります。 セマンティック ランク付けを使用している場合は、この点に留意してください。 セマンティック ランカーは、入力として 50 個のドキュメントがある場合に最適です。

• strictPostFilter (プレビュー) は、クエリの実行後にフィルター処理されていない上位k 結果に適用されます。 常に、 k ドキュメント以下を返します。 フィルター処理されていない k=50 が 50 個のフィルター処理されていない結果を返し、フィルターが 30 個のドキュメントと一致する場合、インデックスにフィルターに一致するドキュメントが 30 個を超える場合でも、結果セットには 30 個のドキュメントのみが返されます。 このモードでは再現率が最も低いため、セマンティック ランカーで使用することはお勧めしません。

クエリ応答を構成する

ハイブリッド クエリを設定するときは、応答構造について考えてください。 検索エンジンは、一致するドキュメントをランク付けし、最も関連性の高い結果を返します。 応答はフラット化された行セットです。 クエリのパラメーターによって、各行に含まれるフィールドと、応答内の行数が決まります。

応答のフィールド

検索結果は、検索インデックスの retrievable フィールドで構成されます。 結果は次のいずれかになります。

• すべての retrievable フィールド (REST API の既定値)。
• クエリの select パラメーターに明示的に一覧表示されているフィールド。

この記事の例では、 select ステートメントを使用して、応答のテキスト (非ベクトル) フィールドを指定しました。

結果の数

検索条件が弱い場合は、クエリが任意の数のドキュメントと一致する場合があります (たとえば、null クエリの場合は "search=*")。 無制限の結果を返すことはめったに実用的ではないので、 応答全体の最大値を指定する必要があります。

• "top": n キーワードのみのクエリの結果 (ベクターなし)
• "k": n ベクターのみのクエリの結果
• "top": n "search" パラメーターを含むハイブリッド クエリの結果 (セマンティックありまたはセマンティックなし)

kとtopはどちらも省略可能です。 指定しない場合、応答の結果の既定の数は 50 です。 topとskipをページに設定して、より多くの結果を表示したり、既定値を変更したりできます。

セマンティック ランカーの結果

2024-05-01-preview 以降でセマンティック ランカーを使用している場合は、 k と maxTextRecallSize を合計 50 以上に設定することをお勧めします。 その後、 top パラメーターを使用して、ユーザーに返される結果を制限できます。

2024-05-01-preview より前の API バージョンでセマンティック ランカーを使用している場合は、次の手順に従います。

• キーワードのみの検索 (ベクトルなし) top 50 に設定する場合
• ハイブリッド検索 k 50 に設定されている場合は、セマンティック ランカーが少なくとも 50 件の結果を取得するようにします。

ランキング

オプションの セマンティック再ランク付けの有無にかかわらず、ハイブリッド クエリ用に複数のセットが作成されます。 結果のランク付けは、逆ランク 融合 (RRF) によって計算されます。

このセクションでは、単一ベクトル検索と単純なハイブリッド検索の間で、上位の結果の応答を比較します。 この場合、HNSW の類似性メトリックと RRF という異なるランク付けアルゴリズムによって、大きさが異なるスコアが生成されます。 この動作は仕様です。 RRFスコアは、類似度の高い一致率でも、非常に低く示されることがあります。 RRF アルゴリズムの特性はスコアが低いことです。 RRF を使用したハイブリッド クエリでは、純粋ベクター検索ではなく、RRF ランク付けドキュメントのスコアが比較的小さい場合、ランク付けされたドキュメントの逆数の多くが結果に含まれます。

単一ベクトル検索: コサイン類似性で並べ替えられた結果の @search.score (既定のベクトル類似性距離関数)。

{
    "@search.score": 0.8399121,
    "HotelId": "49",
    "HotelName": "Swirling Currents Hotel",
    "Description": "Spacious rooms, glamorous suites and residences, rooftop pool, walking access to shopping, dining, entertainment and the city center.",
    "Category": "Luxury",
    "Address": {
    "City": "Arlington"
    }
}

ハイブリッド検索: リシプロカルランクフュージョンを使用してランク付けしたハイブリッド結果の@search.score。

{
    "@search.score": 0.032786883413791656,
    "HotelId": "49",
    "HotelName": "Swirling Currents Hotel",
    "Description": "Spacious rooms, glamorous suites and residences, rooftop pool, walking access to shopping, dining, entertainment and the city center.",
    "Category": "Luxury",
    "Address": {
    "City": "Arlington"
    }
}

ハイブリッド クエリのトラブルシューティング

次の表を使用して、ハイブリッド クエリに関する一般的な問題を診断します。

関連コンテンツ

• ハイブリッド検索の概要
• RRF を使用したハイブリッド検索ランキング
• ベクター検索の使い方
• セマンティックランク付け
• ベクター検索フィルター
• Python、C#、または JavaScript