Azure AI Search でエージェント検索用のインデックスを設計する

Azure AI Search では、 エージェント検索 は、クエリの計画にチャット完了モデルを使用し、検索可能で関連性のあるものの範囲を広げるサブクエリを生成する新しい並列クエリ アーキテクチャです。

サブクエリは内部的に作成されます。 サブクエリの特定の側面は、検索インデックスによって決定されます。 この記事では、クエリ ロジックに影響を与えるインデックス要素について説明します。 必須要素のいずれも、エージェント検索に新しい要素や固有の要素はありません。つまり、以前のバージョンの API を使用して作成された場合でも、この記事で特定された条件を満たしている場合は、既存のインデックスを使用できます。

エージェント検索で使用される検索インデックスは、ナレッジ エージェントのナレッジ ソースとして指定され、次のいずれかになります。

• 検索可能なコンテンツを含む既存のインデックス。 このインデックスは、検索インデックスのナレッジ ソース定義を介してエージェント取得で使用できます。

• BLOB インデクサー パイプラインから作成された生成されたインデックス。 このインデックスは、BLOB ナレッジ ソースの情報を使用して生成され、設定されます。 これは、ナレッジ エージェントとエージェント取得のすべての条件を満たすテンプレートに基づいています。

エージェント取得の条件

エージェント取得で使用されるインデックスには、次の要素が必要です。

• searchableおよびretrievableとして属性付けされた文字列フィールド
• defaultSemanticConfiguration を使用するセマンティック構成
• ベクトル クエリをパイプラインに含める場合は、ベクトル フィールドとベクトライザー

また、ドキュメント名、ファイル名、ページ名、チャプター名、または少なくともチャンク ID など、引用に使用できるフィールドも必要です。

必要に応じて、次のインデックス要素によって最適化の機会が増えます。

• 関連性を高めるための、scoringProfile を使用する defaultScoringProfile
• synonymMaps (用語または専門用語の場合)
• analyzers 言語ルールまたはパターン (空白の保持、特殊文字など) の場合

インデックス定義の例

エージェント検索に機能するインデックスの例を次に示します。 必須要素の条件を満たしています。

{
  "name": "earth_at_night",
  "description": "Contains images an descriptions of our planet in darkness as captured from space by Earth-observing satellites and astronauts on the International Space Station over the past 25 years.",
  "fields": [
    {
      "name": "id", "type": "Edm.String",
      "searchable": true, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
      "key": true,
      "stored": true,
      "synonymMaps": []
    },
    {
      "name": "page_chunk", "type": "Edm.String",
      "searchable": true, "retrievable": true, "filterable": false, "sortable": false, "facetable": false,
      "analyzer": "en.microsoft",
      "stored": true,
      "synonymMaps": []
    },
    {
      "name": "page_chunk_vector_text_3_large", "type": "Collection(Edm.Single)",
      "searchable": true, "retrievable": false, "filterable": false, "sortable": false, "facetable": false,
      "dimensions": 3072,
      "vectorSearchProfile": "hnsw_text_3_large",
      "stored": false,
      "synonymMaps": []
    },
    {
      "name": "page_number", "type": "Edm.Int32",
      "searchable": false, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
      "stored": true,
      "synonymMaps": []
    },
    {
      "name": "chapter_number", "type": "Edm.Int32",
      "searchable": false, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
      "stored": true,
      "synonymMaps": []
    }
  ],
  "scoringProfiles": [],
  "suggesters": [],
  "analyzers": [],
  "normalizers": [],
  "tokenizers": [],
  "tokenFilters": [],
  "charFilters": [],
  "semantic": {
    "defaultConfiguration": "semantic_config",
    "configurations": [
      {
        "name": "semantic_config",
        "flightingOptIn": false,
        "prioritizedFields": {
          "prioritizedContentFields": [
            {
              "fieldName": "page_chunk"
            }
          ],
          "prioritizedKeywordsFields": []
        }
      }
    ]
  },
  "vectorSearch": {
    "algorithms": [
      {
        "name": "alg",
        "kind": "hnsw",
        "hnswParameters": {
          "metric": "cosine",
          "m": 4,
          "efConstruction": 400,
          "efSearch": 500
        }
      }
    ],
    "profiles": [
      {
        "name": "hnsw_text_3_large",
        "algorithm": "alg",
        "vectorizer": "azure_openai_text_3_large"
      }
    ],
    "vectorizers": [
      {
        "name": "azure_openai_text_3_large",
        "kind": "azureOpenAI",
        "azureOpenAIParameters": {
          "resourceUri": "https://YOUR-AOAI-RESOURCE.openai.azure.com",
          "deploymentId": "text-embedding-3-large",
          "apiKey": "<redacted>",
          "modelName": "text-embedding-3-large"
        }
      }
    ],
    "compressions": []
  }
}

重要なポイント:

エージェント検索では、大規模言語モデル (LLM) が 2 回使用されます。 まず、クエリ プランを作成するために使用します。 クエリ プランが実行され、検索結果が生成されると、その結果は、今回は、回答の作成に使用されるグラウンディング データとして再び LLM に渡されます。

LLM は、人間が判読できるプレーン テキスト コンテンツのトークン化された文字列を実行して出力します。 このため、プレーンテキストの文字列を提供するsearchableフィールドと、応答に含まれるretrievableが必要です。 ベクトル フィールドとベクトル検索も、情報の取得に類似性検索を追加するために重要です。 ベクターは、グラウンディングデータを生成する検索の品質を向上させますが、それ以外では必ずしも必要ではありません。 Azure AI 検索には、ベクトル化を簡素化および自動化する機能が組み込まれています。

前の例のインデックスには、クエリ時に使用されるベクトル フィールドが含まれています。 このベクトルは、人間またはLLMには判読できないため結果には必要ありませんが、ベクトル検索では searchable であることに注意してください。 応答にベクトルは必要ないため、 retrievable と stored の両方が false になります。

ベクター検索構成で定義されているベクターライザーは重要です。 クエリの実行中にベクター フィールドを使用するかどうかを決定します。 vectorizer は、ベクトルに対する類似性検索のために、クエリ時に文字列サブクエリをベクターにエンコードします。 ベクター化は、インデックス内にベクトルを作成するために使用されるのと同じ埋め込みモデルである必要があります。

searchableフィールドはすべてクエリ実行に含まれます。 クエリするフィールドを明示的に示す select ステートメントはサポートされていません。

説明を追加する

インデックス description フィールドは、クエリに特定のインデックスを使用することを決定するときに、LLM およびモデル コンテキスト プロトコル (MCP) サーバーにガイダンスを提供するために使用できるユーザー定義文字列です。 この人間が判読できるテキストは、システムが複数のインデックスにアクセスし、説明に基づいて決定を下す必要がある場合に非常に重要です。

インデックスの説明はスキーマの更新であり、インデックス全体を再構築しなくても追加できます。

• 文字列の長さは最大 4,000 文字です。
• Unicode では、コンテンツは人間が判読できる必要があります。 ユース ケースでは、使用する言語 (英語や別の言語など) を決定する必要があります。

セマンティック構成を追加する

インデックスには、少なくとも 1 つのセマンティック構成が必要です。 セマンティック構成には次のものが必要です。

• defaultSemanticConfiguration は名前付き構成に設定されています。
• prioritizedContentFields と searchable の両方である少なくとも 1 つの文字列フィールドに設定された retrievable。

構成内では、 prioritizedContentFields が必要です。 タイトルとキーワードは省略可能です。 チャンクされたコンテンツの場合、どちらも持っていない可能性があります。 ただし、 エンティティ認識 または キー フレーズ抽出を追加すると、検索シナリオ (スコアリング プロファイルなど) で役立つ可能性のあるキーワードが各チャンクに関連付けられている場合があります。

次に、エージェント的な検索のためのセマンティック設定の例を示します。

"semantic":{
   "defaultConfiguration":"semantic_config",
   "configurations":[
      {
         "name":"semantic_config",
         "flightingOptIn":false,
         "prioritizedFields":{
            "prioritizedFields":{
               "titleField":{
                  "fieldName":""
               },
               "prioritizedContentFields":[
                  {
                     "fieldName":"page_chunk"
                  }
               ],
               "prioritizedKeywordsFields":[
                  {
                     "fieldName":"Category"
                  },
                  {
                     "fieldName":"Tags"
                  },
                  {
                     "fieldName":"Location"
                  }
               ]
            }
         }
      }
   ]
}

ベクターライザーを追加する

インデックスにベクター フィールドがある場合、クエリ プランには、それらが searchable され、 vectorizer 割り当てがある場合に含まれます。

vectorizer は、クエリ時にテキストからベクターへの変換を提供する埋め込みモデルを指定します。 インデックス内のベクター コンテンツをエンコードするために使用されるのと同じ埋め込みモデルを指す必要があります。 Azure AI Search でサポートされている任意の埋め込みモデルを使用できます。 ベクター 化は、ベクトル プロファイルを使用して ベクター フィールドで指定されます。

インデックスの例の ベクター フィールド定義 を思い出してください。 ベクター フィールドの属性には、モデルによって生成された次元または埋め込みの数、およびプロファイルが含まれます。

  {
    "name": "page_chunk_text_3_large", "type": "Collection(Edm.Single)",
    "searchable": true, "retrievable": false, "filterable": false, "sortable": false, "facetable": false,
    "dimensions": 3072,
    "vectorSearchProfile": "hnsw_text_3_large",
    "stored": false,
    "synonymMaps": []
  }

ベクター プロファイルは、ベクター化、アルゴリズム、および圧縮手法の構成です。 各ベクター フィールドで使用できるプロファイルは 1 つだけですが、すべてのベクター フィールドに一意のプロファイルが必要な場合は、インデックスに多数のプロファイルを含めることができます。

ベクターのクエリを実行し、ベクターライザーを呼び出すと、要求全体に待機時間が長くなりますが、類似性検索が必要な場合は、トレードオフの価値がある可能性があります。

次に示すのは、vectorSearchの設定に例示される、主体的取得に対応するベクトルライザーの例です。 ベクターライザーの定義には、エージェンティックリトリーバルと組み合わせて動作させるために変更する必要があるものはありません。

"vectorSearch": {
  "algorithms": [
    {
      "name": "alg",
      "kind": "hnsw",
      "hnswParameters": {
        "metric": "cosine",
        "m": 4,
        "efConstruction": 400,
        "efSearch": 500
      }
    }
  ],
  "profiles": [
    {
      "name": "hnsw_text_3_large",
      "algorithm": "alg",
      "vectorizer": "azure_openai_text_3_large"
    }
  ],
  "vectorizers": [
    {
      "name": "azure_openai_text_3_large",
      "kind": "azureOpenAI",
      "azureOpenAIParameters": {
        "resourceUri": "https://YOUR-AOAI-RESOURCE.openai.azure.com",
        "deploymentId": "text-embedding-3-large",
        "apiKey": "<redacted>",
        "modelName": "text-embedding-3-large"
      }
    }
  ],
  "compressions": []
}  

スコアリング プロファイルを追加する

スコアリング プロファイル は、関連性ブーストの基準です。 これらは非ベクター フィールド (テキストと数値) に適用され、クエリの実行中に評価されますが、正確な動作はインデックスの作成に使用される API バージョンによって異なります。

2025-05-01-preview 以降を使用してインデックスを作成した場合、スコアリング プロファイルは最後に実行されます。 以前のバージョンの API を使用してインデックスが作成された場合、スコアリング プロファイルはセマンティック再ランク付けする前に評価されます。

インデックスに適したスコアリング プロファイルを使用できます。 特定のフィールドで一致が見つかった場合に、一致の検索スコアを上げる例を次に示します。 フィールドはブースト乗数によって重み付けされます。 たとえば、[カテゴリ] フィールドに一致が見つかった場合、ブースト スコアに 5 が乗算されます。

"scoringProfiles": [  
    {  
      "name": "boostSearchTerms",  
      "text": {  
        "weights": {  
          "Location": 2,  
          "Category": 5 
        }  
      }  
    }
]

アナライザーを追加する

アナライザーは テキスト フィールドに適用され、特殊文字や空白文字の保持など、インデックス内のトークン化を制御する言語アナライザーまたはカスタム アナライザーにすることができます。

アナライザーは検索インデックス内で定義され、フィールドに割り当てられます。 fields コレクションの例には、テキスト チャンクのアナライザー参照が含まれています。 この例では、既定のアナライザー (標準 Lucene) が Microsoft 言語アナライザーに置き換えられます。

{
  "name": "page_chunk", "type": "Edm.String",
  "searchable": true, "retrievable": true, "filterable": false, "sortable": false, "facetable": false,
  "analyzer": "en.microsoft",
  "stored": true,
  "synonymMaps": []
}

シノニム マップを追加する

シノニム マップでは、 名前付き用語のシノニムを追加してクエリを展開します。 たとえば、一般的な用語に対して科学的用語や医療用語を使用する場合があります。

シノニム マップは、検索インデックスの最上位リソースとして定義され、フィールドに割り当てられます。 fields コレクションの例にはシノニム マップは含まれませんが、シノニム マップに国名のバリエーションのスペルがある場合は、仮定の "場所" フィールドに割り当てられた場合の例を次に示します。

{
    "name":"locations",
    "type":"Edm.String",
    "searchable":true,
    "synonymMaps":[ "country-synonyms" ]
}

関連コンテンツ

• Azure AI Search でのエージェント検索

• Agentic RAG: Azure AI Search を使用して推論検索エンジンを構築する (YouTube ビデオ)

• 主体的な情報取得を特徴とする Azure OpenAI デモ