次の方法で共有

あいまい検索によるスペルミスと入力ミスの修正

  • [アーティクル]

Azure AI Search では、あいまい検索をサポートしています。これは、入力された文字列内の誤字やスペルミスを補正するクエリの一種です。 あいまい検索では、類似した構成の用語をスキャンします。 ほぼ一致をカバーするように検索機能を拡張すると、いくつかの文字の場所が違う場合に、入力ミスが自動修正されます。

類似した構成の用語と一致させるクエリ拡張検索です。 あいまい検索を指定すると、検索エンジンは、クエリ内のすべての用語について、同様に構成された用語のグラフを (決定論的有限自動理論に基づいて) 作成します。 たとえば、クエリに "university of washington" という 3 つの言葉が含まれている場合、クエリ search=university~ of~ washington~ 内のすべての言葉に対してグラフが作成されます (あいまい検索では単語が削除されないため、"of" のグラフも作成されます)。

グラフは、各用語の最大 50 の展開 (または順列) で構成され、プロセス内の正しいバリアントと不適切なバリアントの両方をキャプチャします。 その後、エンジンは、応答で最も関連性の高い一致を返します。

"university" のような言葉の場合、グラフは "unversty, universty, university, universe, inverse" となる可能性があります。 グラフ内のものと一致するドキュメントすべてが結果に含まれます。 テキストを分析して同じ語の異なる形式 (「mice」と「mouse」など) を処理する他のクエリとは対照的に、あいまいクエリの比較では、テキストに対する言語分析を行わず、額面通りに分析されます。 「Universe」や「inverse」は意味が異なりますが、構文上の不一致が小さいため、一致になります。

不一致が 2 つ以下の編集に制限されている場合、つまり、編集が挿入、削除、置換、または転置文字であれば、一致と見なされます。 差異を指定する文字列修正アルゴリズムは、ダメラウ・レーベンシュタイン距離メトリックです。 これは、1 つの単語を別の単語に変更するために必要な「操作の最小数」(挿入、削除、置換、または 2 つの隣接する文字の転置) として説明されています。

Azure AI Search:

  • あいまい検索は用語全体に適用されます。 語句は直接サポートされていませんが、AND コンストラクションを使用して、複数部分から成る語句の各用語に対してあいまい一致を指定できます。 たとえば、search=dr~ AND cleanin~ のようにします。 このクエリ式では、"dry cleaning" で一致が見つかります。

  • 編集の既定の距離は 2 です。 ~0 の値は、拡張がないことを意味します (完全な用語のみが一致と見なされます)。ただし、1 つの相違点、または 1 つの編集に対して ~1 を指定することもできます。

  • あいまいクエリでは、最大 50 の順列まで 1 つの用語を拡張できます。 この制限は構成できませんが、編集距離を 1 に減らすと、展開の数を効果的に減らせます。

  • 応答は、関連する一致 (最大 50) を含むドキュメントで構成されます。

クエリの処理中、あいまいクエリでは字句解析は行われません。 クエリ入力は、クエリ ツリーに直接追加され、展開して用語のグラフを作成します。 実行される変換は、小文字の区別だけです。

これらのグラフはまとめて、インデックス内のトークンに対する一致条件として送信されます。 ご想像のとおり、あいまい検索は、本質的に他のクエリ形式よりも遅くなります。 インデックスのサイズと複雑さによって、応答の待機時間のオフセットに十分な利点があるかどうかを判断できます。

Note

あいまい検索は低速になる傾向があるため、n グラム インデックス作成などの代替手段を調査し、短い文字シーケンスを処理することができます (bigram と trigram トークンの場合は 2 つおよび 3 つの文字シーケンス)。 言語およびクエリ サーフェスによっては、n グラムを使用するとパフォーマンスが向上します。 トレードオフは、n グラムのインデックス作成が非常に多くのストレージを消費し、より大きなインデックスを生成することです。

もう 1 つの方法として、最もひどいケースのみを処理する場合にシノニム マップを使用することもできます。 たとえば、「search」を「serach、serach、sarch」、または「retrieve」を「retreive」にマッピングします。

"検索可能" の属性が付いた文字列フィールドは、あいまい検索の候補になります。

拡張グラフの作成にアナライザーは使用されませんが、あいまい検索のシナリオではアナライザーを無視すべきというわけではありません。 アナライザーは、インデックス作成中のトークン化に重要です。逆インデックスのトークンは、グラフとの照合に使用されます。

テスト クエリで期待どおりの一致が生成されない場合は、異なるインデックス作成アナライザーを試してみてください。 たとえば、言語アナライザーを試して、より良い結果が得られるかどうかを確認します。 いくつかの言語 (特に母音変更を使用する言語) では、Microsoft の自然言語プロセッサによって生成される語形変化と不規則な単語の形式を利用できます。 場合によっては、適切な言語アナライザーを使用すると、ユーザーが指定した値と互換性のある方法で用語がトークン化されているかどうか区別できます。

あいまいクエリは、完全な Lucene クエリ構文を使用して構築され、完全な Lucene クエリ パーサーを呼び出し、ユーザーが入力した各用語の後にチルダ文字 ~ を追加します。

あいまい検索を呼び出すクエリ要求の例をこちらに示します。 4 つの用語があり、そのうちの 2 つの用語のスペルが誤っています。

POST https://[service name].search.windows.net/indexes/hotels-sample-index/docs/search?api-version=2024-07-01
{
    "search": "seatle~ waterfront~ view~ hotle~",
    "queryType": "full",
    "searchMode": "any",
    "searchFields": "HotelName, Description",
    "select": "HotelName, Description, Address/City,",
    "count": "true"
}

  1. クエリの種類を完全な Lucene 構文 (queryType=full) に設定します。

  2. 各用語の末尾にチルダ (~) 演算子が続くクエリ文字列を指定します (search=<string>~)。 クエリ入力内のすべての用語に対して拡張グラフが作成されます。

    編集距離 (~1) を指定する場合は、省略可能なパラメーター (既定で 0 から 2 の間の数字) を含めます。 たとえば、"blue~" または "blue~1" を指定すると、"blue"、"blues"、および "glue" が返されます。

必要に応じて、特定のフィールドに要求のスコープを設定することで、クエリのパフォーマンスを向上させることができます。 searchFields パラメーターを使用して、検索するフィールドを指定します。 また、select プロパティを使用して、クエリ応答で返されるフィールドを指定することもできます。

単純なテストでは、クエリ式を反復処理するために Search エクスプローラーまたは REST クライアントを使用することをお勧めします。 どちらのツールも対話型なので、ひとつの用語の複数のバリエーションをすばやくステップ実行し、返された応答を評価できます。

結果があいまいな場合は、検索語句を強調表示すると応答内の一致を識別しやすくなります。

Note

あいまい一致を識別するための検索語句の強調表示には使用制限があり、基本的なあいまい検索でのみ機能します。 インデックスにスコアリング プロファイルがある場合や、追加の構文でクエリをレイヤー化する場合は、検索語句の強調表示が失敗して一致を識別できないことがあります。

例 1: 正確な用語を使用したあいまい検索

検索ドキュメントの "Description" フィールドに次の文字列が存在するとします: "Test queries with special characters, plus strings for MSFT, SQL and Java."

「special」のあいまい検索から始め、検索語句の強調表示を [説明] フィールドに追加します。

search=special~&highlight=Description

応答では、検索語句の強調表示を追加したので、書式設定が一致用語として「special」に適用されます。

"@search.highlights": {
    "Description": [
        "Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
    ]
}

複数の文字 ("pe") を取り除いて "special" を正しくないスペルにして、要求をもう一度試してみてください。

search=scial~&highlight=Description

これまでのところ、応答に変更はありません。 既定の 2 度の距離を使用して、"pe" の 2 字を "special" から削除しても、その言葉での一致が正常に行われます。

"@search.highlights": {
    "Description": [
        "Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
    ]
}

もうひとつ要求を試し、合計 3 字を削除して検索語句をさらに変更します ( "special" から "scal" に変更)。

search=scal~&highlight=Description

同じ応答が返されますが、「special」ではなく、あいまい一致は「SQL」になります。

"@search.score": 0.4232868,
"@search.highlights": {
    "Description": [
        "Mix of special characters, plus strings for MSFT, <em>SQL</em>, 2019, Linux, Java."
    ]
}

この展開例では、検索語句の強調表示があいまいな結果になる可能性があることを示しています。 どのような場合でも、同じドキュメントが返されます。 一致を確認するためにドキュメント ID を使用しましたが、「special」から「SQL」への変更を把握できなかった可能性があります。

関連項目