Azure Cognitive Search - よく寄せられる質問 (FAQ)

Azure Cognitive Search に関連する概念、コード、シナリオについてよく寄せられる質問の回答を見つけることができます。

検索サービス

Azure Cognitive Search と DBMS の全文検索の違いは何ですか?

Azure Cognitive Search は、複数のデータ ソース、多数の言語の言語分析興味深く普通とは異なるデータ入力のカスタム分析スコアリング プロファイルによる検索ランク制御、ユーザー エクスペリエンス機能 (先行入力、検索結果の強調表示、ファセット ナビゲーションなど) をサポートしています。 また、シノニム、高度なクエリ構文などの機能も含まれていますが、一般的に特別な機能ではありません。

Azure Cognitive Search サービスを一時停止し、課金を停止することはできますか?

サービスを一時停止することはできません。 サービスの作成時に、お客様専用の計算およびストレージ リソースが割り当てられます。 そのリソースを必要に応じて解放し、再請求することはできません。

インデックス作成操作

インデックスまたはインデックスのスナップショットを移動、バックアップ、復元しますか?

開発フェーズで、検索サービス間でのインデックスの移動が必要になることがあります。 たとえば、Basic または Free の価格レベルを使用してインデックスを作成し、運用環境で使用するために Standard 以上のレベルにそれを移動することが必要になる場合があります。

また、後で復元するために使用できるファイルにインデックス スナップショットをバックアップしたい場合もあります。

これらのことはすべて、こちらの Azure Cognitive Search .NET サンプル リポジトリにある index-backup-restore サンプル コードを使用して実行できます。

また、Azure Cognitive Search REST API を使用して、いつでもインデックス定義を取得することができます。

削除されたインデックスまたはサービスは復元できますか?

いいえ。Azure Cognitive Search インデックスまたはサービスを削除した場合、復旧できません。 Azure Cognitive Search サービスを削除すると、サービス内のすべてのインデックスは完全に削除されます。 1 つ以上の Azure Cognitive Search サービスを含む Azure リソース グループを削除すると、すべてのサービスが完全に削除されます。

インデックス、インデクサー、データ ソース、スキルセットなどのリソースを再作成するには、コードからそれらを再作成する必要があります。

インデックスを再作成するには、外部ソースからデータのインデックスを再作成する必要があります。 そのため、元のデータのマスター コピーまたはバックアップを、Azure SQL Database や Cosmos DB などの別のデータ ストアに保持することをお勧めします。

別の方法として、こちらの Azure Cognitive Search .NET サンプル リポジトリindex-backup-restore サンプル コードを使用して、インデックス定義とインデックス スナップショットを一連の JSON ファイルにバックアップすることができます。 後で、必要に応じてツールとファイルを使用してインデックスを復元できます。

SQL Database レプリカからインデックスを作成することはできますか (対象: Azure SQL Database インデクサー)

最初からインデックスを構築するときに、データ ソースとしてのプライマリまたはセカンダリ レプリカの使用に制限はありません。 ただし、(レコードの変更に基づく) 増分更新によるインデックスの更新には、プライマリ レプリカが必要です。 この要件は SQL Database に由来するものです。SQL Database は変更追跡をプライマリ レプリカでのみ保証しています。 インデックス更新ワークロードにセカンダリ レプリカを使用しても、すべてのデータを取得する保証はありません。

検索操作

複数のインデックスを対象に検索できますか?

いいえ。この操作はサポートされていません。 検索は常に単一のインデックスが対象です。

ユーザー ID によって検索インデックス アクセスを制限できますか?

search.in() フィルターを使用するセキュリティ フィルターを実装できます。 このフィルターは Azure Active Directory (Azure AD) などの ID 管理サービスに適切に構成でき、定義されたユーザー グループ メンバーシップに基づいて検索結果を絞り込むことができます。 現在パブリック プレビューのロールベース アクセスにサインアップすることもできます。

存在するとわかっている用語でも一致数が 0 件なのはなぜですか?

よくある例は、クエリの種類ごとにサポートされる検索動作と言語分析のレベルが異なることを把握していない場合です。 主要なワークロードである全文検索には、用語を原形に分解する言語分析フェーズが含まれています。 トークン化された用語は、より多くの数の変形と一致するため、このようなクエリ分析はより広い網を一致候補にかけます。

ただし、ワイルドカードを含むクエリ、あいまいなクエリ、正規表現のクエリの分析は、通常の用語やフレーズのクエリとは異なります。クエリが検索インデックス内の語の分析済みの形と一致しない場合は、再現率が低くなることがあります。 クエリの解析と分析について詳しくは、クエリのアーキテクチャに関する記事をご覧ください。

ワイルドカード検索に時間がかかります。

ほとんどのワイルドカード検索クエリ (プレフィックス、あいまい、正規表現など) は、検索インデックス内の一致する用語を使用して内部で再作成されます。 この追加の処理により、待ち時間が増えます。 また、a* のような広範な検索クエリは、多数の用語を使用して再作成される可能性が高く、非常に遅くなることがあります。 ワイルドカード検索のパフォーマンスを向上させるには、カスタム アナライザーの定義を検討してください。

毎回、検索順位が 1.0 の定数または同じスコアなのはなぜですか?

既定で、検索結果は一致する用語の統計プロパティに基づいて評価され、結果セットで高位から下位の順序が付けられます。 ただし、一部の検索の種類 (ワイルドカード、プレフィックス、正規表現) は、文書全体のスコアに対して常に一定のスコアをもたらします。 この動作は仕様です。 Azure Cognitive Search では、定数にスコアを付与することで、ランクには影響を与えずに、クエリの拡張で見つかった一致を結果に反映することができます。

たとえば、ワイルドカード検索に「tour*」と入力すると、「tours」、「tourettes」、「tourmaline」との一致が生成されます。 こうした結果の性質上、語句の相対的な重みを適切に推測することができません。 そのため、ワイルドカード検索、プレフィックス検索、正規表現検索では、結果のスコア付けを行う際に、語句の出現頻度が無視されます。 予期しない一致に対するバイアスを回避するために、部分的な入力に基づく検索結果には一定のスコアが与えられます。

スキルセットの操作

インジェストにかかる認知サービス料金を下げるためのヒントやコツはありますか?

組み込みのスキルやカスタム スキルを必要以上に実行したくないことは理解できます。何百万ものドキュメントを処理する場合は特にそうです。 このことを念頭に置いて、スキルセットの実行に "インクリメンタル エンリッチメント" 機能を追加しました。 基本的に、"中間" エンリッチメント手順の出力を格納するために使用されるキャッシュの場所 (BLOB ストレージの接続文字列) を指定できます。 これにより、エンリッチメント パイプラインがスマートになり、スキルセットを変更するときに必要なエンリッチメントのみを適用できます。 これにより、パイプラインが効率的になるため、当然ながらインデックス作成の時間も短縮されます。

インクリメンタル エンリッチメントの詳細情報

設計パターン

ローカライズされた検索を実装するには、どのような方法が推奨されますか?

多くのお客様は、同じインデックスで複数のロケール (言語) をサポートすることになったときに、コレクションよりも専用フィールドを選択しています。 ロケール固有のフィールドがあると、適切なアナライザーを割り当てることができます。 たとえば、フランス語の文字列を含むフィールドに Microsoft French Analyzer を割り当てることができます。 また、フィルター処理も簡単になります。 フランス語のページに対してクエリが開始されたことがわかっている場合は、検索結果をこのフィールドに制限することができます。 また、スコアリング プロファイルを作成して、フィールドにより多くの相対的な重み付けを与えます。 Azure Cognitive Search では、50 を超える言語アナライザーを選ぶことができます。