RAG（Retrieval-Augmented Generation; 取得拡張生成）を利用したチャットシステム等を構築するにあたり、検索サービスであるAzure AI Searchへの需要が高まっています。
ドキュメント検索方法には、テキスト検索、ベクター検索、ハイブリッド検索などの様々なパターンがありますが、今回はテキスト検索の精度向上に寄与する「シノニム」機能に焦点を当てます。
この記事では、Azure AI Searchのシノニムの基本的な機能や検索処理の流れについて解説します。
Azure AI Searchのシノニム
Azure AI Search（以下 AI Search）におけるシノニム（同義語）とは、同じ意味を持つ複数用語を関連付けて、1つの用語のように検索できるようにする機能です。これを利用してキーワード検索の精度を向上させることができます。
例えば、以下のような場面でシノニム機能が役立ちます。
- 略語・カタカナ表記・スペースの有無などの表記揺れがある場合
- 業界用語と一般的な用語を関連付けたい場合
- 製品やサービスの名称が変更された場合
- 多言語環境で使用する場合
ユーザーやチャットシステムによる検索ログやフィードバックを分析し、類似表現を特定してシノニムとして追加することで、検索エクスペリエンスを改善することができます。
用語やコンポーネントの整理
AI Searchのシノニム機能を説明する上で前提となる、検索の主要な要素をまず整理します。
| 用語 | 説明 |
|---|---|
| インデックス（Index） | 検索可能なデータの集合体です。検索する際は検索対象として、AI Searchの検索サービス(インスタンス)と、その中のインデックスを1つ指定します。 |
| ドキュメント（Document） | インデックス内の個々のデータです。インデックスをSQL DBのテーブルに例えると、ドキュメントは一つ一つのレコードに相当します。 |
| フィールド（Field） | ドキュメント内の個別のデータ項目です。インデックスをSQL DBのテーブルに例えると、フィールドはカラムに相当します。 |
| アナライザー（Analyzer） | アナライザーで定められている特定の規則に従って、検索クエリや文書が解析・加工されます。アナライザーは、検索可能なフィールドごとにあらかじめ設定します。AI Searchでは組み込みアナライザーとして、オープンソースのLucene言語アナライザーやMicrosoft独自の言語アナライザーが用意されています。フィールドのテキストの種類や言語によって、適切なアナライザーを選択する必要があります。 |
シノニム機能の主要コンポーネントは以下となります。
| 用語 | 説明 |
|---|---|
| ルール（Rule） | 検索クエリを同等の用語に拡張または書き換える規則です。 |
| シノニムマップ（Synonym Map） | 複数のルールを一覧としてまとめたコンポーネントです。検索可能フィールドに対して、シノニムマップを割り当てます。 |
以上をまとめると、以下の図のイメージになります。
ルールの種類
定義できるルールには、「同義性規則（Equivalency rules）」と「明示的なマッピング（Explicit mapping）」の2種類が存在します。
同義性規則（Equivalency rules）
同義性規則では、列挙したフレーズを同じフレーズのように扱える規則です。
例えば以下のようにルールを設定すると、"vehicle"で検索した際に"car"や"automobile"を含むドキュメントも検索結果に含まれます。内部的には、"vehicle"というクエリはこのルールによって、"vehicle OR car OR automobile"というクエリに置き換えられています。
car, automobile, vehicle
明示的なマッピング（Explicit mapping）
明示的なマッピングの規則は、矢印=> によって表現されます。 =>の左側に一致する検索クエリのフレーズが、右側のフレーズに置き換えられます。
例えば以下のようにルールを設定すると、"car"や"automobile"で検索した際に検索クエリが"vehicle"で置き換えられ、"vehicle"で検索した際の結果と同等になります。
car, automobile, vehicle => vehicle
検索処理の流れ
シノニムを利用したテキスト検索における検索処理の流れを簡単に説明します。
内容としては、フルテキスト検索の処理の流れ(参考)に対して、シノニムが適用される過程(参考)を加えた内容です。
(1) 検索クエリの解析
まずはユーザーから与えられた検索クエリの演算子を解釈して、サブクエリに分割します。以下のクエリが与えられたとすると、
Car, "Second-Hand" +Red
Redが必須キーワードでCar,または"Second-Hand"というキーワードを含むドキュメントを探していると解釈されます。また、"Second-Hand"についてはダブルクォーテーションで囲われているため、単語検索ではなくフレーズ検索になります。
実際に検索クエリがどのように解釈されるかは、検索リクエストのsearchModeなどの他パラメータにも依存します。
(2) アナライザーの適用
検索対象のフィールドに設定されているアナライザーによって、"単語検索"と"フレーズ検索"のサブクエリがトークンに加工されます。 プレフィックス検索、ワイルドカード検索、正規表現検索などについては、アナライザーによる加工はされず、大文字から小文字への変換がされるだけです。
先ほどの例ですと、Red、Car,、"second-hand"といったキーワードがアナライザーによって、以下のように加工されます。
| 加工前（サブクエリ） | 加工後（トークン） |
|---|---|
| Red | red |
| Car, | car |
| "Second-Hand" | second と hand |
"second-hand"についてはアナライザーで2つの単語に加工されるものの、フレーズ検索ですので検索時には連続したsecondとhandがあることが条件になります。
結果的に検索クエリは、「redが必須トークンで、carまたはsecond hand(連続)というトークンを含む」ドキュメントを探していると解釈されます。
上記の例は、"標準-Lucene"アナライザーで解析された場合であり、実際にフィールドに設定されているアナライザーの種類によって結果は大きく異なります。各アナライザーがテキストをどのようにトークン化しているかについては、Analyze APIを使うことで確認可能です。
(3) シノニムマップのルール適用
検索対象のフィールドに紐づけられているシノニムマップのルールによって、検索クエリが拡張や置換されます。
例えば、以下のルールを含むシノニムマップが今回の検索対象フィールドに紐づけられていたとします。
Car, Motor vehicle, vehicle
このルールもフィールドに設定されているアナライザーによって解釈されます。つまり、car、motor vehicle(連続)、vehicleはそれぞれ同義とされます。
結果、このルールによって、(2)で得られた以下の解釈は、
| シノニムルール適用前（(2)で得られた解釈） |
|---|
redが必須トークンで、carまたはsecond hand(連続)というトークンを含む |
carの部分が拡張されて、以下のようになります。
| シノニムルール適用後 |
|---|
redが必須トークンで、(car or motor vehicle(連続) or vehicle) or second hand(連続) というトークンを含む |
(4) ドキュメント検索
検索対象のフィールドに対して、(3)で得られた条件でドキュメント検索が実行されます。
検索の仕組みとしては、ドキュメントから転置インデックスがあらかじめ作成されていて、転置インデックスを利用して検索クエリとのトークンの一致が確認されます。
転置インデックスは以下のように作成されます。
- ドキュメントの文書内容をフィールドごとに設定されたアナライザーを用いてトークン化する。つまり、各ドキュメントにどのトークンが出現するかという情報を得ることになる。
- 各トークンがどのドキュメントに出現しているかという1.の情報を転置したインデックスを作成する。
このドキュメントを処理するアナライザーと検索クエリを処理するアナライザーは通常同一のものを使用しますが、明示的に別のものを指定することも可能です。
話が少しややこしくなりましたが、このドキュメント検索の段階で重要なポイントは、検索対象のドキュメントもアナライザーで処理されているということです。
まとめ
以上の流れを簡単に図にまとめると、以下のようになります。
注意事項
AI Searchのシノニム機能を利用するにあたって、いくつか注意事項があります。
シノニムの操作方法
シノニムマップの作成や編集に関しては、AzureポータルのGUIでサポートされていません。そのため、REST APIや各種言語のAI Search用のSDKを使用して操作する必要があります。
参考：クエリ拡張のシノニム - Azure AI Search | Microsoft Learn
価格レベルによる制限
AI Searchの価格レベルに応じて、AI Searchに定義できるシノニムマップの最大数・各シノニムマップごとのルールの最大数に制限があります。
また、「各規則には最大 20 の拡張を含めることができます。」と記載があります。実際にルールの登録を試したところ、以下の結果になりました。
| 登録を試みたルール | 結果 |
|---|---|
| 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 | ルールとして登録できる |
| 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21 | ルールとして登録できない |
| 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21 => number | ルールとして登録できる |
つまり、 「同義性規則」ルールでの同義語定義が最大20個 であり、「明示的なマッピング」ルールでの左側の用語数は20が上限ではないようです。
参考：レベルおよび SKU のサービスの制限 - Azure AI Search | Microsoft Learn
シノニムが適用される検索種別とスコアリングプロファイルについて
- シノニムは自由形式のテキストクエリにのみ適用され、フィルタ・ファセット・オートコンプリート・サジェストではサポートされていません。
- シノニムによる拡張は、ワイルドカード・プレフィックス・あいまい・正規表現検索の語句には適用されません。
- シノニムによる拡張は、内部的にはOR演算子でのクエリの書き換えです。そのため、元の用語とシノニムの用語はスコアリングにおいて同等に扱われます。
参考：クエリ拡張のシノニム - Azure AI Search | Microsoft Learn
最後に
この記事ではAzure AI Searchのシノニム機能の概要を紹介しました。シノニムは検索精度を向上させ、ユーザー体験を改善する重要な機能です。
次回の記事では、シノニム機能の具体的な使い方や動作について詳しく解説します。具体的には、REST APIを使用したシノニムの作成、フィールドへのシノニムマップの割り当て、検索実行時の挙動などを取り上げます。
