ドキュメントの検索 (プレビュー REST API)

[アーティクル]
06/28/2024

: 2023-07-01-Preview に適用されます。このバージョンはサポートされなくなりました。新しいバージョンにすぐにアップグレードします。

大事な

2023-07-01-Preview では次のものが追加されます。

ベクタークエリ要求を指定するクエリパラメーター "vector" をします。各オブジェクトには、クエリのベクター表現、結果で返される最も近い近傍の数 "k"、クエリの実行中に使用するベクターフィールドが含まれている必要があります。

2021-04-30-Preview では次のものが追加されます。

"semanticConfiguration" では、特定のフィールドへのスコーピングセマンティックランク付けがサポートされます。
"captions" は、意味的にランク付けされた最も高いドキュメントの主要な箇所から抽出された語句を返します。

2020-06-30-Preview では次のものが追加されます。

"queryType=semantic" では、セマンティックの再ランク付けと応答がサポートされます。
セマンティッククエリの "searchFields" 、キャプションと回答の作成に使用されるフィールドの優先順位が確立されます。このアプローチは、2021-04-30-Preview で "semanticConfiguration" に置き換えられ、現在は廃止されています。
"スペルチェック" 、クエリ入力のスペル修正を有効にします。
"queryLanguage" は、"queryType=semantic" と "speller" の両方に必要です。
"featuresMode" は、検索スコアをアンパックし、フィールドごとの用語頻度、フィールドごとの類似性スコア、および一意の一致のフィールドごとの数を報告します。

クエリ要求は、検索サービス上の 1 つのインデックスのドキュメントコレクションを対象とします。一致条件を定義するパラメーターと、応答を形成するパラメーターが含まれます。また、インデックス名自体を使用する代わりに、インデックスエイリアスを使用して特定のインデックスをターゲットにすることもできます。

ほとんどのクエリでは GET または POST を使用できますが、ベクタークエリパラメーターが URI 内に収まらないため、ベクター検索には POST を使用する必要があります。クエリパラメーターは、GET 要求のクエリ文字列と POST 要求の要求本文で指定されます。

GET https://[service name].search.windows.net/indexes/[index name]/docs?[query parameters] 
  Content-Type: application/json   
  api-key: [admin or query key]

POST を使用している場合は、URI パラメーターとして "search" アクションを追加します。

POST https://[service name].search.windows.net/indexes/[index name]/docs/search?api-version=[api-version]  
  Content-Type: application/json  
  api-key: [admin or query key]

GET を使用して呼び出された場合、要求 URL の長さは 8 KB を超えることはできません。この長さは、ほとんどのアプリケーションで十分です。ただし、一部のアプリケーションでは、特に OData フィルター式が使用されている場合に、大規模なクエリが生成されます。これらのアプリケーションでは、HTTP POST は GET よりも大きなフィルターを許可するため、より優れた選択肢です。

POST では、POST の要求サイズ制限が約 16 MB であるため、フィルター内の句の数は制限要因であり、未加工のフィルター文字列のサイズではありません。 POST 要求サイズの制限が大きい場合でも、フィルター式を任意に複雑にすることはできません。フィルターの複雑さの制限の詳細については、「Azure AI Searchの OData 式構文」を参照してください。

URI パラメーター

パラメーター	形容
サービス名	必須。この名前を、検索サービスの一意のユーザー定義名に設定します。
index name/docs	必須。名前付きインデックスのドキュメントコレクションを指定します。インデックスエイリアスの名前は、インデックス名の代わりに使用することもできます。
クエリパラメーター	クエリパラメーターは、GET 要求の URI と POST 要求の要求本文で指定されます。
api-version	必須。その他のバージョンについては、API のバージョンを参照してください。

URL エンコードの推奨事項

GET REST API を直接呼び出すときは、URL エンコード特定のクエリパラメーターを必ずしてください。 ドキュメント検索 操作では、次のクエリパラメーターに URL エンコードが必要になる場合があります。

捜索
$filter
小面
highlightPreTag
highlightPostTag

URL エンコードは、個々のパラメーターにのみ推奨されます。誤ってクエリ文字列全体 (?の後のすべて) を URL エンコードすると、要求が中断されます。

また、URL エンコードは、GET を使用して REST API を直接呼び出すときにのみ必要です。 POST を使用する場合、またはエンコードを処理する Azure AI Search .NET クライアントライブラリを使用する場合は、URL エンコードは必要ありません。

要求ヘッダー

次の表では、必須の要求ヘッダーと省略可能な要求ヘッダーについて説明します。

田畑	形容
Content-Type	必須。この値を "application/json" に設定します
api-key	Azure ロール使用していて、要求にベアラートークンが提供されている場合は省略可能。それ以外の場合はキーが必要です。 API キーは、検索サービスに対する要求を認証する一意のシステム生成文字列です。ドキュメントコレクションに対するクエリ要求では、API キーとして管理者キーまたはクエリキーを指定できます。クエリキーは、ドキュメントコレクションに対する読み取り専用操作に使用されます。詳細については、「キー認証を使用して Azure AI Search に接続する」を参照してください。

田畑

形容

Content-Type

必須。この値を "application/json" に設定します

api-key

Azure ロール使用していて、要求にベアラートークンが提供されている場合は省略可能。それ以外の場合はキーが必要です。 API キーは、検索サービスに対する要求を認証する一意のシステム生成文字列です。ドキュメントコレクションに対するクエリ要求では、API キーとして管理者キーまたはクエリキーを指定できます。クエリキーは、ドキュメントコレクションに対する読み取り専用操作に使用されます。詳細については、「キー認証を使用して Azure AI Search に接続する」を参照してください。

要求本文

GET の場合: なし。

POST の場合:

{  
     "answers": "none" (default) | "extractive", 
     "count": true | false (default),
     "captions": "none" (default) | "extractive",
     "facets": [ "facet_expression_1", "facet_expression_2", ... ],  
     "featuresMode" : "disabled" (default) | "enabled",
     "filter": "odata_filter_expression",  
     "highlight": "highlight_field_1, highlight_field_2, ...",  
     "highlightPreTag": "pre_tag",  
     "highlightPostTag": "post_tag",  
     "minimumCoverage": # (% of index that must be covered to declare query successful; default 100),  
     "orderby": "orderby_expression",
     "queryLanguage": "en-us" (default) | (a supported language code), 
     "queryType": "simple" (default) | "full" | "semantic",
     "scoringParameters": [ "scoring_parameter_1", "scoring_parameter_2", ... ],  
     "scoringProfile": "scoring_profile_name",  
     "scoringStatistics" : "local" (default) | "global",
     "search": "simple_query_expression",  
     "searchFields": "field_name_1, field_name_2, ...",  
     "searchMode": "any" (default) | "all",  
     "select": "field_name_1, field_name_2, ...",  
     "semanticConfiguration": "semantic_configuration_name",
     "sessionId" : "session_id",
     "skip": # (default 0), 
     "speller": "none" (default) | "lexicon",  
     "top": #,
     "vectors": [
      {
        "value": "a vector representation of the query",
        "k": an integer (number of nearest neighbors to return as top results),
        "fields": "a comma-delimited list of vector fields to use in the query"
      }
     ]
   }

部分検索応答の継続

Azure AI Search では、要求されたすべての結果を 1 回の検索応答で返さない場合があります。部分的な応答は、$topを指定しないか、大きすぎる $ top の値を指定することによって、クエリが返すドキュメントが多すぎる場合など、さまざまな理由で発生する可能性があります。このような場合、Azure AI Search は応答本文に @odata.nextLink 注釈を含め、POST 要求の場合は @search.nextPageParameters します。これらの注釈の値を使用して、別の検索要求を作成し、検索応答の次の部分を取得できます。この動作は、元の Search 要求の継続と呼ばれ、注釈は継続トークン呼び出されます。これらの注釈の構文と、それらが応答本文に表示される場所の詳細については、「応答」セクションの例を参照してください。

Azure AI Search が継続トークンを返す理由は実装固有であり、変更される可能性があります。堅牢なクライアントは、予想よりも少ないドキュメントが返され、ドキュメントの取得を続行するために継続トークンが含まれている場合に常に対応できる状態にする必要があります。また、続行するには、元の要求と同じ HTTP メソッドを使用する必要があることにも注意してください。たとえば、GET 要求を送信した場合、送信するすべての継続要求でも GET を使用する必要があります (POST の場合も同様です)。

手記

@odata.nextLink と @search.nextPageParameters の目的は、ページングの一般的なメカニズムを提供せず、多すぎる結果を要求するクエリからサービスを保護することです。結果をページングする場合は、$topと$skipを一緒に使用します。たとえば、サイズが 10 のページが必要な場合、最初の要求には $top=10、$skip=0、2 番目の要求には $top=10、$skip=10、3 番目の要求には $top=10、$skip=20 などが必要です。

クエリパラメーター

クエリは、GET を使用して呼び出されたときに URL に対していくつかのパラメーターを受け入れ、POST で呼び出されたときに要求本文の JSON プロパティとして受け入れます。一部のパラメーターの構文は、GET と POST の間で若干異なります。これらの違いを次の表に示します。

名前	種類	形容
回答 (プレビュー)	糸	随意。有効な値は "none" と "extractive" です。既定値は "none" です。このパラメーターは、クエリの種類が "セマンティック" の場合にのみ有効です。 "extractive" に設定すると、クエリは、意味的にランク付けされた最も高いドキュメントの主要な箇所から回答を作成して返します。既定値は 1 つの回答ですが、カウントを追加することで最大 10 個を指定できます。たとえば、"answers": "extractive\|count-3" は 3 つの回答を返します。回答を返すには、対象フィールドに回答のような逐語的なコンテンツが存在する必要があります。回答に使用される言語モデルは、回答を生成せずに認識するようにトレーニングされます。さらに、クエリ自体は質問のように見える必要があります。
api-version	糸	必須。要求に使用される REST API のバージョン。サポートされているバージョンの一覧については、API のバージョンを参照してください。この操作では、GET と POST のどちらを使用してドキュメントの検索呼び出すかに関係なく、API バージョンが URI パラメーターとして指定されます。
captions (プレビュー)	糸	随意。有効な値は "none" と "extractive" です。既定値は "none" です。このパラメーターは、クエリの種類が "セマンティック" の場合にのみ有効です。 "extractive" に設定すると、クエリは、最もランクの高いドキュメントの主要な通路から抽出されたキャプションを返します。キャプションが 'extractive' に設定されている場合、強調表示は既定で有効になり、パイプ文字 '\|' の後に 'highlight-<true/false>' オプション ('extractive\|highlight-true' など) を追加することで構成できます。
$count	ブーリアン	随意。有効な値は "true" または "false" です。既定値は "false" です。 POST を使用して呼び出されると、このパラメーターは$countではなく名前付き count になります。結果の合計数をフェッチするかどうかを指定します。この値は、検索パラメーターと$filterパラメーターに一致するすべてのドキュメントの数であり、$topと$skipは無視されます。この値を "true" に設定すると、パフォーマンスが低下する可能性があります。インデックスが安定している場合、カウントは正確ですが、アクティブに追加、更新、または削除されたドキュメントの下または過剰レポートになります。ドキュメントなしでカウントのみを取得する場合は、$top=0 を使用できます。
ファセットまたはファセット	糸	随意。ファセットの対象となるフィールド。フィールドは "ファセット可能" として属性付けされます。 GET で呼び出されると、`facet` はフィールド (`facet: field1`) になります。 POST を指定して呼び出すと、このパラメーターの名前は `facet` ではなく `facets` になり、配列 (`facets: [field1, field2, field3]`) として指定されます。文字列には、コンマ区切りの名前と値のペアとして表されるファセットをカスタマイズするためのパラメーターを含めることができます。有効な値は、"count"、"sort"、"values"、"interval"、"timeoffset" です。 "count" はファセット用語の最大数です。既定値は 10 です。用語の数に上限はありませんが、値を大きくすると、特にファセットフィールドに多数の一意の用語が含まれている場合、パフォーマンスが低下します。たとえば、"facet=category,count:5" はファセット結果の上位 5 つのカテゴリを取得します。 count パラメーターが一意の項の数より少ない場合、結果が正確でない可能性があります。これは、ファセットクエリがシャード間で分散される方法が原因です。すべてのシャードで正確なカウントを取得するには、count を 0 に設定するか、ファセット可能フィールド内の一意の値の数以上の値に設定します。トレードオフは待機時間の増加です。 "sort" は、"count"、"-count"、"value"、"-value" に設定できます。 count を使用して、count で降順に並べ替えます。 -count を使用して、count で昇順に並べ替えます。値を使用して値で昇順に並べ替えます。 -value を使用して、値で降順に並べ替えます (たとえば、"facet=category,count:3,sort:count" は、ファセットの上位 3 つのカテゴリを取得し、各都市名を持つドキュメントの数で降順に並べ替えます)。上位 3 つのカテゴリが Budget、Motel、Luxury で、Budget が 5 ヒット、Motel が 6、Luxury が 4 の場合、バケットは Motel、Budget、Luxury の順になります。 value の場合、"facet=rating,sort:-value" は、可能なすべての評価のバケットを値の降順で生成します (たとえば、評価が 1 から 5 の場合、バケットは、各評価に一致するドキュメントの数に関係なく、5、4、3、2、1 の順に並べ替えられます)。 "values" は、ファセットエントリ値の動的なセットを指定するパイプ区切りの数値または Edm.DateTimeOffset 値に設定できます (例: "facet=baseRate,values:10 \|20" では、3 つのバケットが生成されます。1 つは基本レート 0 (ただし、10 を含まない) 用、1 つは最大 10 個 (ただし 20 個は含まない)、1 つは 20 以上用です)。文字列 "facet=lastRenovationDate,values:2010-02-01T00:00:00Z" は、2010 年 2 月より前に改装されたホテル用と、2010 年 2 月 1 日以降に改装されたホテル用の 2 つのバケットを生成します。期待される結果を得るには、値を順番に昇順で示す必要があります。 "interval" は、数値の場合は 0 より大きい整数の間隔、または日付の時刻値の場合は分、時、日、週、月、四半期、年です。たとえば、"facet=baseRate,interval:100" は、サイズ 100 の基本レート範囲に基づいてバケットを生成します。基本レートがすべて $60 から $600 の間の場合、0 から 100、100-200、200-300、300-400、400-500、500 から 600 のバケットが存在します。文字列 "facet=lastRenovationDate,interval:year" は、ホテルが改装された年ごとに 1 つのバケットを生成します。 "timeoffset" を ([+-]hh:mm、[+-]hhmm、または [+-]hh) に設定できます。使用する場合、timeoffset パラメーターは、Edm.DateTimeOffset 型のフィールドに適用される場合にのみ、interval オプションと組み合わせる必要があります。この値は、時間の境界を設定する際に考慮する UTC 時間オフセットを指定します。たとえば、"facet=lastRenovationDate,interval:day,timeoffset:-01:00" は、UTC 01:00:00 (ターゲットタイムゾーンの午前 0 時) から始まる日の境界を使用します。カウントと並べ替えは同じファセット仕様で組み合わせることができますが、間隔や値と組み合わせることはできません。また、間隔と値を組み合わせることはできません。 Interval ファセットは、時刻オフセットが指定されていない場合、UTC 時刻に基づいて計算されます。たとえば、"facet=lastRenovationDate,interval:day" の場合、日の境界は UTC の 00:00:00 から始まります。
featuresMode (プレビュー)	ブーリアン	随意。有効な値は "有効" と "無効" です。既定値は "無効" です。クエリ結果の特徴含めるかどうかを指定する値。フィールドごとの類似性など、クエリに関連するドキュメントの関連性スコアを計算するために使用されます。 "有効" を使用して、より多くのクエリ結果機能を公開します。フィールドの類似性スコアごと、フィールド用語の頻度ごと、一致した一意のトークンのフィールド数ごとです。詳細については、「類似性とスコアリングの」を参照してください。
$filter	糸	随意。標準の OData 構文の構造化された検索式。フィルターで使用できるのは、フィルター可能なフィールドだけです。 POST を使用して呼び出されると、このパラメーターは$filterではなく filter という名前になります。 Azure AI Search でサポートされる OData 式文法のサブセットの詳細については、Azure AI Search の OData 式構文のを参照してください。
ハイライト	糸	随意。ヒット強調表示に使用されるコンマ区切りのフィールド名のセット。検索可能なフィールドのみを、ヒット強調表示に使用できます。既定では、Azure AI Search はフィールドごとに最大 5 つの強調表示を返します。この制限は、フィールド名の後に "-<最大強調表示数>" を追加することで、フィールドごとに構成できます。たとえば、"highlight=title-3,description-10" は、タイトルフィールドから最大 3 つの強調表示されたヒットを返し、説明フィールドから最大 10 ヒットを返します。強調表示の最大数は、1 から 1000 までの整数である必要があります。
highlightPostTag	糸	随意。既定値は `"</em>"`です。強調表示された用語に追加する文字列タグ。 highlightPreTag を使用して設定する必要があります。 URL の予約文字はパーセントエンコードする必要があります (たとえば、#ではなく %23)。
highlightPreTag	糸	随意。既定値は `"</em>"`です。強調表示された用語の先頭に付加される文字列タグ。 highlightPostTag を使用して設定する必要があります。 URL の予約文字はパーセントエンコードする必要があります (たとえば、#ではなく %23)。
minimumCoverage	整数	随意。有効な値は 0 ~ 100 の範囲の数値で、成功として報告する前にクエリを処理するために使用できるインデックスの割合を示します。既定値は "100" です。 100% のカバレッジは、すべてのシャードが要求に応答したことを意味します (サービス正常性の問題もメンテナンスアクティビティもカバレッジが低下することはありません)。既定の設定では、完全カバレッジ未満の場合、HTTP 状態コード 503 が返されます。 minimumCoverage の削減は、503 エラーが発生していて、クエリが成功する可能性を高める場合に役立ちます (特に、1 つのレプリカ用に構成されているサービスの場合)。 minimumCoverage を設定し、検索が成功すると、HTTP 200 が返され、クエリに含まれていたインデックスの割合を示す @search.coverage 値が応答に含まれます。このシナリオでは、一致するすべてのドキュメントが検索結果に表示されるとは限りませんが、検索の可用性がリコールよりも重要な場合は、カバレッジを減らすことが実行可能な軽減策になる可能性があります。
$orderby	糸	随意。結果を並べ替えるコンマ区切り式の一覧。 POST を使用して呼び出されると、このパラメーターの名前は、$orderbyではなく orderby になります。各式には、フィールド名または geo.distance() 関数の呼び出しを指定できます。各式の後に "asc" を付けて昇順を示し、降順を示す "desc" を指定できます。並べ替えフィールドに null 値がある場合、null は先頭に昇順で表示され、最後は降順に表示されます。既定値は昇順です。同点は、ドキュメントのマッチスコアによって分割されます。 $orderbyが指定されていない場合、既定の並べ替え順序はドキュメントの一致スコアの降順になります。 $orderbyには 32 個の句の制限があります。
queryLanguage (プレビュー)	糸	随意。有効な値は、サポートされている言語です。既定値は "en-us" です。 speller=lexicon または queryType=semantic のいずれかを使用する場合は、このパラメーターを設定する必要があります。 queryLanguage で指定された言語は、スペルチェックと、結果を再ランク付けしてキャプションまたは回答を抽出するセマンティックモデルの両方に使用されます。 queryLanguage に使用されるライブラリは、インデックス作成やフルテキスト検索に使用言語アナライザーなど、他のロケールベースのフィールド属性とは無関係です。
queryType	糸	随意。有効な値は、"simple"、"full"、または "semantic" (プレビュー) です。既定値は "simple" です。この値はベクター検索では無視されますが、ハイブリッドシナリオのテキスト検索に適用されます。 "simple" は、`+`、`*`、`""`などのシンボルを許可する、単純なクエリ構文を使用してクエリ文字列を解釈します。クエリは、既定で各ドキュメントのすべての検索可能なフィールド (または searchFields で示されるフィールド) で評価されます。 "full" は、完全な Lucene クエリ構文を使用してクエリ文字列を解釈します。これにより、フィールド固有および重み付けされた検索が可能になります。 Lucene クエリ言語での範囲検索は、同様の機能を提供する$filterを優先してサポートされていません。 "セマンティック" は、キーワードではなく自然言語で表現されたクエリに対して、Bing コーパスでトレーニングされたランク付けモデルを使用して上位 50 件の一致を再ランク付けすることで、検索結果の精度を向上させます。クエリの種類をセマンティックに設定する場合は、queryLanguage と semanticConfiguration も設定する必要があります。クエリ入力が自然言語 ("...") で作成された場合も上位 3 つの回答を返す場合は、必要に応じて回答を設定できます。また、必要に応じてキャプションを設定して、最もランクの高いドキュメントから重要な箇所を抽出することもできます。
scoringParameter	糸	随意。 "name-value1,value2,..." の形式を使用して、スコアリング関数 (referencePointParameter など) で定義されている各パラメーターの値を示します。POST で呼び出されると、このパラメーターの名前は scoringParameter ではなく scoringParameters になります。また、各文字列が個別の名前と値のペアである文字列の JSON 配列として指定します。関数を含むスコアリングプロファイルの場合は、関数を入力リストから `-` 文字で区切ります。たとえば、`"mylocation"` という関数は "&scoringParameter=mylocation-122.2,44.8" になります。最初のダッシュは関数名を値リストから分離し、2 番目のダッシュは最初の値 (この例では経度) の一部です。コンマを含めることができるタグブーストなどのスコアリングパラメーターの場合は、一重引用符を使用して、リスト内のそのような値をエスケープできます。値自体に単一引用符が含まれている場合は、2 倍にすることでエスケープできます。 `"mytag"` という名前のタグブーストパラメーターがあり、タグ値 "Hello, O'Brien" と "Smith" をブーストする場合、クエリ文字列オプションは "&scoringParameter=mytag-'Hello, O'Brien',Smith" になります。引用符は、コンマを含む値にのみ必要です。
scoringProfile	糸	随意。結果を並べ替えるために一致するドキュメントの一致スコアを評価するスコアリングプロファイルの名前。
scoringStatistics	糸	随意。有効な値は "local" または "global" です。既定値は "local" です。より一貫性のあるスコアリングを行うために、ドキュメントの頻度、グローバル (すべてのシャード) など、スコアリング統計を計算するか、待機時間を短くするためにローカル (現在のシャード) で計算するかを指定します。 Azure AI Searchでのスコア付け統計のを参照してください。スコアリング統計は、あいまい検索 ('~')を使用する用語常にローカルで計算されます。
捜索	糸	随意。検索するテキスト。この値はベクター検索では無視されますが、ハイブリッドシナリオのテキスト検索に適用されます。 REST API では、searchFields が指定されていない限り、検索可能なすべてのフィールドが既定で検索されます。インデックスでは、検索可能なフィールド内のテキストがトークン化されるため、複数の用語を空白で区切ることができます (例: 'search=hello world')。任意の用語と一致するには、`` を使用します (これはブール型フィルタークエリに役立ちます)。このパラメーターを省略すると、``に設定した場合と同じ効果があります。検索構文詳細については、「単純なクエリ構文」を参照してください。検索可能なフィールドに対してクエリを実行すると、結果が驚くことがあります。トークナイザーには、アポストロフィ、数字のコンマなど、英語のテキストに共通するケースを処理するロジックが含まれています。たとえば、'search=123,456' は、個々の用語 '123' と '456' ではなく、単一の用語 '123,456' と一致します。これは、コンマが英語の大きな数値の桁区切り記号として使用されるためです。このため、検索パラメーターで用語を区切るために、句読点ではなく空白を使用することをお勧めします。
searchMode	糸	随意。有効な値は "any" または "all" です。既定値は "any" です。ドキュメントを一致としてカウントするために、検索語句の一部または全部を照合する必要があるかどうかを指定します。
searchFields	糸	随意。指定したテキストを検索するコンマ区切りのフィールド名の一覧。ターゲットフィールドは、インデックススキーマで検索可能としてマークする必要があり、`Edm.String`、`Edm.ComplexType`、または `Collection(Edm.String)`の種類である必要があります。
$select	糸	随意。結果セットに含めるコンマ区切りフィールドの一覧。この句には、取得可能としてマークされたフィールドのみを含めることができます。指定されていない場合、または `*`に設定されている場合、スキーマで取得可能としてマークされているすべてのフィールドがプロジェクションに含まれます。 POST を使用して呼び出されると、このパラメーターは$selectではなく select という名前になります。
semanticConfiguration (プレビュー)	糸	随意。 queryType="semantic" の場合は必須です。セマンティックランク付け、キャプション、強調表示、回答に使用するフィールドを一覧表示するセマンティック構成の名前。詳細については、「セマンティッククエリを作成する」を参照してください。
sessionId	糸	随意。 sessionId を使用すると、複数のレプリカを持つ検索サービスの関連性スコアの一貫性を向上させることができます。マルチレプリカ構成では、同じクエリに対する個々のドキュメントの関連性スコアに若干の違いがある可能性があります。セッション ID が提供されると、サービスは、特定の要求をそのセッションの同じレプリカにルーティングするためのベストエフォートを行います。同じセッション ID 値を繰り返し再利用すると、レプリカ間での要求の負荷分散が妨げられる可能性があり、検索サービスのパフォーマンスに悪影響を及ぼす可能性があります。 sessionId として使用される値は、'_' 文字で始めることはできません。サービスにレプリカがない場合、このパラメーターはパフォーマンスやスコアの整合性に影響しません。
$skip	整数	随意。スキップする検索結果の数。 POST を使用して呼び出されると、このパラメーターは$skipではなく skip という名前になります。この値を 100,000 より大きくすることはできません。ドキュメントを順番にスキャンする必要があるが、この制限のために$skipを使用できない場合は、インデックス内のすべてのドキュメントに一意の値を持つフィールド (ドキュメントキーなど) に対して$orderbyを使用し、代わりに範囲クエリで$filterすることを検討してください。
speller (プレビュー)	糸	随意。有効な値は "none" と "lexicon" です。既定値は "none" です。個々の検索クエリ用語をスペル修正することで、再現率を向上させます。単純、完全、セマンティックのクエリの種類で使用できます。スペルチェックパラメーターを使用する場合は、queryLanguage が必要です。詳細と例については、「クエリにスペルチェックを追加する」を参照してください。
$top	整数	随意。取得する検索結果の数。既定値は 50 です。 POST で呼び出されると、このパラメーターの名前は $top ではなく top になります。 1000 より大きい値を指定し、結果が 1000 を超える場合は、最初の 1000 件の結果のみが返され、結果の次のページへのリンクが返されます (次の例の「@odata.nextLink」を参照)。 Azure AI Search では、サーバー側ページングを使用して、クエリが一度に取得するドキュメントが多くなりすぎないようにします。既定のページサイズは 50 で、最大ページサイズは 1000 です。つまり、$topを指定しない場合、既定でドキュメント検索は最大 50 件の結果を返します。結果が 50 件を超える場合、応答には最大 50 件の結果の次のページを取得するための情報が含まれます (以下の例の「@odata.nextLink」と「@search.nextPageParameters」を参照してください)。同様に、$topに 1000 を超える値を指定し、結果が 1000 を超える場合は、最初の 1000 件の結果のみが返され、最大で 1,000 件の結果の次のページを取得する情報が返されます。
vector (プレビュー)	配列	随意。配列内のオブジェクト型はベクタークエリです。ベクタークエリのクエリパラメーター。 "value" は、検索クエリのベクター表現です。この表現は外部で形成する必要があります。 Azure AI Search は埋め込みを作成しません。 "k" は、上位ヒットとして返される最も近い近傍の数を指定する整数です。既定値は 50 です。最小値は 1、最大値は 10,000 です。 "fields" は、ベクターデータを含むコンマ区切りのリストフィールド名です。 "フィールド" リストには、`Collection(Edm.Single)` 型のフィールドのみを含めることができます。

応答

状態コード: 正常に応答するために 200 OK が返されます。この記事には、セマンティック検索と featuresMode に対してそれぞれ 1 つずつ、2 つのサンプル応答があります。

セマンティッククエリの応答のサンプル

最初の例は、セマンティッククエリの最上位の結果に対する完全な応答を示 "how do clouds form"。

"@search.answers" は、回答パラメーターを指定し、クエリとインデックス内の対象フィールドに回答として認識できるコンテンツが含まれている場合に表示されます。キー、テキスト、および強調表示を持つ @search.answers 配列。スコアは、回答の強度を示す指標です。
"value" は応答の本文です。 @search.rerankerScore はセマンティックランク付けアルゴリズムによって割り当てられ、結果のランク付けに使用されます (@search.score は BM25 類似性アルゴリズムからのものであり、最初の結果をスコア付けするときに使用されます)。キャプションには、プレーンテキストと強調表示されたバージョンが含まれます。この例は、OCR とエンティティ認識スキルを使用して作成されました。抽出されたコンテンツとマージされたコンテンツのフィールドが応答に含まれます。

{
    "@search.answers": [
        {
            "key": "aHR0cHM6Ly9oZWlkaXN0YmxvYnN0b3JhZ2UuYmxvYi5jb3JlLndpbmRvd3MubmV0L25hc2EtZWJvb2stMS01MC9wYWdlLTQ1LnBkZg2",
            "text": "Sunlight heats the land all day, warming that moist air and causing it to rise high into the atmosphere until it cools and condenses into water droplets. Clouds generally form where air is ascending (over land in this case),   but not where it is descending (over the river).",
            "highlights": "Sunlight heats the land all day, warming that moist air and causing it to rise high into the   atmosphere until it cools and condenses into water droplets. Clouds generally form<em> where air is ascending</em> (over land in this case),   but not where it is<em> descending</em> (over the river).",
            "score": 0.94639826
        }
    ],
    "value": [
        {
            "@search.score": 0.5479723,
            "@search.rerankerScore": 1.0321671911515296,
            "@search.captions": [
                {
                    "text": "Like all clouds, it forms when the air reaches its dew point—the temperature at which an air mass is cool enough for its water vapor to condense into liquid droplets. This false-color image shows valley fog, which is common in the Pacific Northwest of North America.",
                    "highlights": "Like all<em> clouds</em>, it<em> forms</em> when the air reaches its dew point—the temperature at    which an air mass is cool enough for its water vapor to condense into liquid droplets. This false-color image shows valley<em> fog</em>, which is common in the Pacific Northwest of North America."
                }
            ],
            "content": "\nA\nT\n\nM\nO\n\nS\nP\n\nH\nE\n\nR\nE\n\nE\nA\n\nR\nT\n\nH\n\n34\n\nValley Fog\nCanada\n\nFog is essentially a cloud lying on the ground. Like all clouds, it forms when the air reaches its dew point—the temperature at  \n\nwhich an air mass is cool enough for its water vapor to condense into liquid droplets.\n\nThis false-color image shows valley fog, which is common in the Pacific Northwest of North America. On clear winter nights, the \n\nground and overlying air cool off rapidly, especially at high elevations. Cold air is denser than warm air, and it sinks down into the \n\nvalleys. The moist air in the valleys gets chilled to its dew point, and fog forms. If undisturbed by winds, such fog may persist for \n\ndays. The Terra satellite captured this image of foggy valleys northeast of Vancouver in February 2010.\n\n\n",
            "metadata_storage_path": "aHR0cHM6Ly9oZWlkaXN0YmxvYnN0b3JhZ2UuYmxvYi5jb3JlLndpbmRvd3MubmV0L25hc2EtZWJvb2stMS01MC9wYWdlLTQxLnBkZg2",
            "people": [],
            "locations": [
                "Pacific Northwest",
                "North America",
                "Vancouver"
            ],
            "merged_content": "\nA\nT\n\nM\nO\n\nS\nP\n\nH\nE\n\nR\nE\n\nE\nA\n\nR\nT\n\nH\n\n34\n\nValley Fog\nCanada\n\nFog is essentially a cloud lying on the ground. Like all clouds, it forms when the air reaches its dew point—the temperature at  \n\nwhich an air mass is cool enough for its water vapor to condense into liquid droplets.\n\nThis false-color image shows valley fog, which is common in the Pacific Northwest of North America. On clear winter nights, the \n\nground and overlying air cool off rapidly, especially at high elevations. Cold air is denser than warm air, and it sinks down into the \n\nvalleys. The moist air in the valleys gets chilled to its dew point, and fog forms. If undisturbed by winds, such fog may persist for \n\ndays. The Terra satellite captured this image of foggy valleys northeast of Vancouver in February 2010.\n\n\n",
            "text": [],
            "layoutText": []
        }
    ]
}

featuresMode の応答のサンプル

この例では、featuresMode を含むクエリからの "@search.features" 出力を示します。

  {
    "@odata.count": # (if $count=true was provided in the query),
    "@search.coverage": # (if minimumCoverage was provided in the query),
    "@search.facets": { (if faceting was specified in the query)
      "facet_field": [
        {
          "value": facet_entry_value (for non-range facets),
          "from": facet_entry_value (for range facets),
          "to": facet_entry_value (for range facets),
          "count": number_of_documents
        }
      ],
      ...
    },
    "@search.nextPageParameters": { (request body to fetch the next page of results if not all results could be returned in this response and Search was called with POST)
      "count": ... (value from request body if present),
      "facets": ... (value from request body if present),
      "featuresMode" : ... (value from request body if present),
      "filter": ... (value from request body if present),
      "highlight": ... (value from request body if present),
      "highlightPreTag": ... (value from request body if present),
      "highlightPostTag": ... (value from request body if present),
      "minimumCoverage": ... (value from request body if present),
      "orderby": ... (value from request body if present),
      "scoringParameters": ... (value from request body if present),
      "scoringProfile": ... (value from request body if present),
      "scoringStatistics": ... (value from request body if present),
      "search": ... (value from request body if present),
      "searchFields": ... (value from request body if present),
      "searchMode": ... (value from request body if present),
      "select": ... (value from request body if present),
      "sessionId" : ... (value from request body if present),
      "skip": ... (page size plus value from request body if present),
      "top": ... (value from request body if present minus page size),
    },
    "value": [
      {
        "@search.score": document_score (if a text query was provided),
        "@search.highlights": {
          field_name: [ subset of text, ... ],
          ...
        },
        "@search.features": {
          "field_name": {
            "uniqueTokenMatches": feature_score,
            "similarityScore": feature_score,
            "termFrequency": feature_score,
          },
          ...
        },
        key_field_name: document_key,
        field_name: field_value (retrievable fields or specified projection),
        ...
      },
      ...
    ],
    "@odata.nextLink": (URL to fetch the next page of results if not all results could be returned in this response; Applies to both GET and POST)
  }

例

その他の例については、Azure AI Searchの OData 式構文を参照してください。

例: 単純な検索

単純なクエリ構文を使用して、インデックス内のドキュメントを検索します。このクエリでは、検索可能なフィールドに "comfort" と "location" という用語が含まれているが、"motel" は含まれていないホテルが返されます。

Get /indexes/hotels/docs?search=comfort +location –motel&searchMode=all&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "comfort +location -motel",  
      "searchMode": "all"  
    }

先端

searchMode=all を使用すると、searchMode=anyの既定値がオーバーライドされ、-motel が "OR NOT" ではなく "AND NOT" を意味します。 searchMode=allしないと、検索結果を制限するのではなく拡張する "OR NOT" が表示され、一部のユーザーは直感的に操作できません。

例: 完全な Lucene 検索

Lucene クエリ構文を使用してインデックス内のドキュメントを検索します (Azure AI Searchの Lucene クエリ構文参照)。このクエリは、カテゴリフィールドに "budget" という用語と、"最近改装された" という語句を含むすべての検索可能なフィールドが含まれるホテルを返します。 "最近改装された" という語句を含むドキュメントは、用語ブースト値の結果として上位にランク付けされます (3)

GET /indexes/hotels/docs?search=Category:budget AND \"recently renovated\"^3&searchMode=all&api-version=2021-04-30-Preview&querytype=full`

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "Category:budget AND \"recently renovated\"^3",  
      "queryType": "full",  
      "searchMode": "all"  
}

例: セマンティック検索

回答、キャプション、強調表示されたコンテンツを使用してセマンティックランク付けモデルを呼び出します。このクエリの応答は、前のセクションで確認できます。

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
{
  "search": "how do clouds form",
  "queryType": "semantic",
  "semanticConfiguration": "my-semantic-config",
  "queryLanguage": "en-us",
  "answers": "extractive",
  "captions": "extractive",
  "count": "true"
}

例: ベクター検索

Collection(Edm.Single) 型のフィールドとベクター構成を持つインデックスの場合は、ベクタークエリパラメーターを指定できます。ベクタークエリパラメーターには、クエリのスコープ内にあるベクターフィールド、返される上位ヒット数 "k"、クエリ入力のベクター表現が含まれます。

"select" パラメーターを追加すると、インデックスにテキストフィールドが含まれている場合に役立ちます。照合と関連性はベクトルに基づいていますが、人間が判読できるコンテンツを含むフィールドは、結果を読む人にとってより便利です。または、検索結果のベクターデータをテキストに変換するコードを記述することもできます。

POST https://{{search-service-name}}.search.windows.net/indexes/{{index-name}}/docs/search?api-version={{api-version}}
Content-Type: application/json
api-key: {{admin-api-key}}
{
    "search": (this parameter is ignored in vector search),
    "vectors": [{
        "value": [
            -0.009154141,
            0.018708462,
            . . . 
            -0.02178128,
            -0.00086512347
        ],
        "fields": "contentVector",
        "k": 5
    }],
    "select": "title, content, category"
}

例: orderby

インデックスを検索し、日付順に並べ替えられた結果を返します。

GET /indexes/hotels/docs?search=*&$orderby=LastRenovationDate desc&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "*",  
      "orderby": "LastRenovationDate desc"
    }

例: OData 式 を使用してフィルター処理する

特定のフィルター式に一致するドキュメントを取得します。

GET /indexes/hotels/docs?$filter=(Rooms/BaseRate ge 60 and Rooms/BaseRate lt 300) or HotelName eq 'Fancy Stay'&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "filter": "(Rooms/BaseRate ge 60 and Rooms/BaseRate lt 300) or HotelName eq 'Fancy Stay'"  
    }

例: ファセット検索

ファセット検索では、インデックスを検索し、カテゴリ、評価、タグ、および特定の範囲の baseRate を持つ項目のファセットを取得します。

GET /indexes/hotels/docs?search=*&facet=Category&facet=Rating&facet=Tags&facet=Rooms/BaseRate,values:80|150|220&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "test",  
      "facets": [ "Category", "Rating", "Tags", "Rooms/BaseRate,values:80|150|220" ]  
    }

最後のファセットがサブフィールドにあることに注意してください。ファセットは、中間サブドキュメント (Rooms) ではなく親ドキュメント (ホテル) をカウントするため、応答によって、各価格バケットに部屋があるホテルの数が決定されます。

例: ファセットクエリの を絞り込む

フィルターを使用して、ユーザーが Rating 3 とカテゴリ "Motel" を選択した後で、前のファセットクエリの結果を絞り込みます。

GET /indexes/hotels/docs?search=*&facet=tags&facet=Rooms/BaseRate,values:80|150|220&$filter=Rating eq 3 and Category eq 'Motel'&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview 
    {  
      "search": "test",  
      "facets": [ "tags", "Rooms/BaseRate,values:80|150|220" ],  
      "filter": "Rating eq 3 and Category eq 'Motel'"  
    }

例: 各カテゴリの制限を持つファセット検索

ファセット検索で、クエリで返される一意の用語に上限を設定します。既定値は 10 ですが、ファセット属性の count パラメーターを使用して、この値を増減できます。次の使用例は、city のファセットを返します。値は 5 に制限されます。

GET /indexes/hotels/docs?search=*&facet=Address/City,count:5&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "test",  
      "facets": [ "Address/City,count:5" ]  
    }

例: フィールド内検索

特定のフィールド (言語フィールドなど) 内のインデックスを検索する

GET /indexes/hotels/docs?search=hôtel&searchFields=Description_fr&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "hôtel",  
      "searchFields": "Description_fr"
    }

複数のフィールドでインデックスを検索します。たとえば、検索可能なフィールドをすべて同じインデックス内に複数の言語で格納してクエリを実行できます。同じドキュメントに英語とフランス語の説明が共存している場合は、クエリ結果の一部またはすべてを返すことができます。

GET /indexes/hotels/docs?search=hotel&searchFields=Description,Description_fr&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "hotel",  
      "searchFields": "Description, Description_fr"
    }

クエリを実行できるのは、一度に 1 つのインデックスのみです。一度に 1 つずつクエリを実行する予定がない限り、言語ごとに複数のインデックスを作成しないでください。

例: ページングの結果

アイテムの最初のページを取得します (ページサイズは 10)。

GET /indexes/hotels/docs?search=*&$skip=0&$top=10&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "*",  
      "skip": 0,  
      "top": 10  
    }

アイテムの 2 ページ目を取得します (ページサイズは 10)。

GET /indexes/hotels/docs?search=*&$skip=10&$top=10&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "*",  
      "skip": 10,  
      "top": 10  
    }

例: 結果セットのフィールドを制限する

特定のフィールドセットを取得します。

GET /indexes/hotels/docs?search=*&$select=HotelName,Description&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "*",  
      "select": "HotelName, Description"
    }

例: 結果の強調表示を

インデックスを検索し、ヒットハイライトでフラグメントを返します。

GET /indexes/hotels/docs?search=something&highlight=Description&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "something",  
      "highlight": "Description"  
    }

例: 地理空間検索

インデックスを検索し、参照場所から離れた場所に近い順に並べ替えられたドキュメントを返します。

GET /indexes/hotels/docs?search=something&$orderby=geo.distance(Location, geography'POINT(-122.12315 47.88121)')&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "something",  
      "orderby": "geo.distance(Location, geography'POINT(-122.12315 47.88121)')"
    }

例: "自分で検索" (近くの場所の関連性を高める

2 つの距離スコアリング関数を持つ "geo" というスコアリングプロファイルがあり、1 つは "currentLocation" というパラメーターを定義し、もう 1 つは "lastLocation" というパラメーターを定義している場合に、インデックスを検索します。次の例では、"currentLocation" には 1 つのダッシュ (-) の区切り記号があります。その後に経度と緯度の座標が続きます。経度は負の値です。

GET /indexes/hotels/docs?search=something&scoringProfile=geo&scoringParameter=currentLocation--122.123,44.77233&scoringParameter=lastLocation--121.499,44.2113&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "something",  
      "scoringProfile": "geo",  
      "scoringParameters": [ "currentLocation--122.123,44.77233", "lastLocation--121.499,44.2113" ]  
    }

例: シャード ではなく、完全なインデックスに対してクエリを実行する

一貫性のあるスコアリングを優先しながら、待機時間を短縮しながら、インデックス内のドキュメントを検索します。このクエリは、インデックス全体のドキュメントの頻度を計算し、同じ "セッション" 内のすべてのクエリに対して同じレプリカをターゲットにすることをベストエフォートで行います。これにより、安定した再現可能なランク付けが生成されます。

GET /indexes/hotels/docs?search=hotel&sessionId=mySessionId&scoringStatistics=global&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "hotel",  
      "sessionId": "mySessionId",
      "scoringStatistics" :"global"
    }

例: 統計のスコア付け (featuresMode)

インデックス内のドキュメントを検索し、一致したドキュメントとクエリの間のスコア付けを記述する各結果の情報取得機能の一覧を返します。このクエリでは、インデックス全体のドキュメントの頻度も計算され、より一貫性のあるスコアリングが生成されます。

GET /indexes/hotels/docs?search=hotel&featuresMode=enabled&scoringStatistics=global&api-version=2021-04-30-Preview

POST /indexes/hotels/docs/search?api-version=2021-04-30-Preview
    {  
      "search": "hotel",  
      "featuresMode": "enabled",
      "scoringStatistics" :"global"
    }

search.features を含む応答の例は、次のようになります。

    "@search.score": 0.91875637,
    "@search.features": {
        "Description": {
            "uniqueTokenMatches": 1,
            "similarityScore": 0.2917966,
            "termFrequency": 2
        },
        "HotelName": {
            "uniqueTokenMatches": 1,
            "similarityScore": 0.44458693,
            "termFrequency": 1
        }
      . . .

定義

このセクションでは、メインテーブルで扱うには複雑すぎるパラメーターについて詳しく説明します。

リンク	形容
queryLanguage をする	スペルチェックとセマンティック検索でサポートされている言語の一覧。

queryLanguage

queryLanguage パラメーターの有効な値は、次の表の "queryLanguage" 列に示され、大文字と小文字は区別されません。パラメーター全体の既定値は "en-us" です。各言語には、2 文字の言語コードごとに既定のバリアントがあります。たとえば、"es" を指定すると、"es-us" が既定で使用されます。 queryLanguage パラメーターは、"queryType=semantic" または "speller=lexicon" を含むクエリ要求に必要です。要求全体に対して queryLanguage 値は 1 つだけあり、その値はセマンティックランク付け、キャプション、回答、スペルチェックに使用されます (個々の機能にオーバーライドはありません)。

現時点では、言語のサポートは機能によって異なります。機能の完全なセットでは、英語、スペイン語、フランス語、およびドイツ語のみがサポートされていますが、スペルチェックでは実装されるバリエーションが少ないことに注意してください。

スペルチェックを使用した EN-GB など、特定の機能でサポートされていない言語コードを指定すると、サービスは HTTP 400 を返します。

各機能の使用方法の詳細については、「セマンティックランク付けとキャプションを有効にする」、「セマンティック回答を返す」、および「クエリにスペルチェックを追加する」をを参照してください。

"(プレビュー)" の指定は、すべての機能 (セマンティックランク付け、キャプション、回答、スペルチェック) の検証テストが進行中または保留中であることを示します。次の表のすべての言語バリアントを使用することをお勧めしますが、結果がコンテンツに対して有効であることを確認するために、プレビュー言語のテストを増やすることをお勧めします。チェックマークを付け、プレビューの指定がない言語は、同等のデータセットを使用して検証されており、関連性が測定可能です。

言語	queryLanguage	セマンティックランカーとキャプション	セマンティック回答	スペルチェック
英語 [`en`]	`en, en-US` (既定値)、`en-GB`、`en-IN`、`en-CA`、`en-AU`	✔️	✔️	✔️ (`en, en-US`)
フランス語 [`fr`]	`fr`、`fr-FR` (既定)、`fr-CA`	✔️	✔️	✔️ (`fr, fr-FR`)
ドイツ語 [`de`]	`de, de-DE` (既定)	✔️	✔️	✔️ (`de, de-DE`)
スペイン語 [`es`]	`es, es-ES` (既定)、`es-MX`	✔️	✔️	✔️ (`es, es-ES`)
イタリア語 [`it`]	`it, it-IT` (既定)	✔️	✔️
日本語 [`ja`]	`ja, ja-JP` (既定)	✔️	✔️ (プレビュー)
中国語 [`zh`]	`zh, zh-CN` (既定)、`zh-TW`	✔️	✔️ (プレビュー)
ポルトガル語 [`pt`]	`pt, pt-BR` (既定)、`pt-PT`	✔️	✔️ (プレビュー)
オランダ語 [`nl`]	`nl, nl-BE, nl-NL` (既定)	✔️ (プレビュー)	✔️ (プレビュー)	✔️ (`nl, nl-NL`)
アラビア語 [`ar`]	`ar, ar-SA` (既定)、`ar-EG, ar-MA, ar-KW, ar-JO`	✔️ (プレビュー)	✔️ (プレビュー)
アルメニア語	`hy-AM` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
バングラ	`bn-IN` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
バスク語	`eu-ES` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ブルガリア語 [`bg`]	`bg, bg-BG` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
カタロニア語 [`ca`]	`ca, ca-ES` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
クロアチア語 [`hr`]	`hr, hr-HR` (既定)、hr-BA	✔️ (プレビュー)	✔️ (プレビュー)
チェコ語 [`cs`]	`cs, cs-CZ` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
デンマーク語 [`da`]	`da, da-DK` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
エストニア語 [`et`]	`et, et-EE` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
フィンランド語 [`fi`]	`fi, fi-FI` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ガリシア語	`gl-ES` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ギリシャ語 [`el`]	`el, el-GR` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
グジャラート語	`gu-IN` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ヘブライ語	`he-IL` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ヒンディー語 [`hi`]	`hi, hi-IN` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ハンガリー語 [`hu`]	`hu, hu-HU` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
アイスランド語 [`is`]	`is, is-IS` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
インドネシア語 [`id`]	`id, id-ID` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
アイルランド語	`ga-IE` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
カナラ語	`kn-IN` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
韓国語 [`ko`]	`ko, ko-KR` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ラトビア語 [`lv`]	`lv, lv-LV` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
リトアニア語 [`lt`]	`lt, lt-LT` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
マラヤラム語	`ml-IN` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
マレーシア語 [`ms`]	`ms, ms-MY` (既定)、`ms-BN`	✔️ (プレビュー)	✔️ (プレビュー)
マラーティー語	`mr-IN` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ノルウェー語 [`no`]	いいえ、no-NO (既定)、nb-NO	✔️ (プレビュー)	✔️ (プレビュー)
ペルシャ語	`fa-AE` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ポーランド語 [`pl`]	`pl, pl-PL` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
パンジャブ語	`pa-IN` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ルーマニア語 [`ro`]	`ro, ro-RO` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ロシア語 [`ru`]	`ru, ru-RU` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
セルビア語 [`sr`] (キリル文字またはラテン文字)	`sr, sr-BA` (既定)、`sr-ME, sr-RS`	✔️ (プレビュー)	✔️ (プレビュー)
スロバキア語 [`sk`]	`sk, sk-SK` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
スロベニア語 [`sl`]	`sl, sl-SL` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
タミル語 [`ta`]	`ta, ta-IN` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
スウェーデン語 [`sv`]	`sv, sv-SE` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
テルグ語	`te-IN` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
タイ語 [`th`]	`th, th-TH` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
トルコ語 [`tr`]	`tr, tr-TR` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ウクライナ語 [`uk`]	`uk, uk-UA` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ウルドゥ語	`ur-PK` (既定)	✔️ (プレビュー)	✔️ (プレビュー)
ベトナム語 [`va`]	`va, vi-VN` (既定)	✔️ (プレビュー)	✔️ (プレビュー)

次の方法で共有

ドキュメントの検索 (プレビュー REST API)

URI パラメーター

URL エンコードの推奨事項

要求ヘッダー

要求本文

クエリパラメーター

応答

セマンティッククエリの応答のサンプル

featuresMode の応答のサンプル

例

定義

queryLanguage

関連項目

その他のリソース

次の方法で共有

ドキュメントの検索 (プレビュー REST API)

URI パラメーター

URL エンコードの推奨事項

要求ヘッダー

要求本文

クエリ パラメーター

応答

セマンティック クエリの応答のサンプル

featuresMode の応答のサンプル

例

定義

queryLanguage

関連項目

その他のリソース

クエリパラメーター

セマンティッククエリの応答のサンプル