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

メモ

Azure AI 検索は、Azure ポータル、REST API、およびAzure SDKから使用できます。また、Foundry IQ は、エンタープライズコンテンツを、Microsoft Foundry ポータルのエージェントの再利用可能なアクセス許可に対応したナレッジベースに変換するマネージドナレッジレイヤーです。

この記事では、エージェント検索に必要なインデックスフィールドと構成について説明します。これらの要件のいずれも新しい要件はありません。以前のバージョンの API で作成された場合でも、条件を満たす既存のインデックスを使用できます。

インデックス付きナレッジソースはそれぞれ、基になるインデックスに依存します。パイプラインの設定方法に応じて、インデックスは次のいずれかになります。

既存： 検索インデックスナレッジソースを介して公開されるスタンドアロンインデックス。インデックスは、この記事の条件を満たしている必要があります。
生成: インデックス付きナレッジソースによって自動的に作成されるインデックス。生成されたインデックスは、既定ですべての条件を満たします。

エージェントによる取得の基準

次の表は、要件レベルによるエージェントの取得に影響を与えるインデックス要素を整理しています。

インデックス要素	要件	注
`searchable` および `retrievable` の文字列フィールド	Required	クエリの実行と結果の取得に使用されます。
セマンティック構成	Required	ナレッジソースで `defaultSemanticConfiguration` を使用するか、セマンティック構成をオーバーライドします。
引用文献フィールド	推奨	ドキュメント名、ページ番号、チャンク ID など、ソースコンテンツへの応答を属性とするユーザー定義フィールド。
ベクターフィールドとベクター化	推奨	クエリ時にテキストからベクターへの変換を有効にします。
スコアリングプロファイル	Optional	特定のフィールドの関連性を高めます。 `defaultScoringProfile`を自動的に適用するように設定します。
アナライザー	Optional	空白文字や特殊文字の処理など、テキストのトークン化方法を制御します。
シノニムマップ	Optional	用語または専門用語を使用してクエリを展開します。

インデックス定義の例

次の例は、エージェント検索に機能するインデックスを示しています。必須要素の条件を満たし、ベストプラクティスとしてベクターフィールドが含まれます。

{
  "name": "earth_at_night",
  "description": "Contains images and 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": []
    }
  ],
  "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",
          "modelName": "text-embedding-3-large"
        }
      }
    ],
    "compressions": []
  }
}

生成型 AI または検索拡張生成 (RAG) 用に適切に設計されたインデックスには、次のコンポーネントがあります。

インデックスを使用するかスキップするかを判断するために LLM またはエージェントが使用できる説明。
回答を生成するために LLM に入力トークンとして渡すことができる、人間が判読できるテキストのチャンク。
エージェント検索が最も関連性の高いチャンクを識別するためにレベル 2 (L2) のセマンティックランク付けを使用するので、これに合わせたセマンティックランカーの設定が必要です。
(省略可能)補完的ベクター検索のための人間が判読できるテキストチャンクのベクターと同等のバージョン。

チャンク化されたテキストが重要なのは、LLM が人間が読めるプレーンテキストの内容をトークン化した文字列を入力として受け取り、出力するためです。このため、プレーンテキスト文字列を提供し、応答内でsearchableされるretrievableフィールドが必要です。 Azure AI 検索では、組み込みまたはサードパーティ製のソリューションを使用して、チャンク化されたテキストを作成できます。

チャンクされたコンテンツの前提条件として、元のソースドキュメントには大量の冗長なコンテンツが含まれていることがあります。ソースコンテンツが製品データベースなどの構造化データである場合、インデックスはチャンクを省略し、代わりに、製品名、カテゴリ、説明など、元のデータソースにマップされるフィールドを含める必要があります。 searchableとretrievableの属性は、構造化データにも適用されます。 searchable は、クエリのスコープ内にコンテンツを作成し、 retrievable 検索結果 (グラウンドデータ) に追加します。

ベクターコンテンツは、情報の取得に 類似性検索 を追加するため便利です。クエリ時に、インデックスにベクターフィールドが存在する場合、エージェント検索エンジンはテキストクエリと並行してベクタークエリを実行します。ベクタークエリは一致する単語ではなく類似したコンテンツを検索するため、ベクタークエリはテキストクエリが見逃す可能性のある関連性の高い結果を見つけることができます。ベクターを追加すると、グラウンドデータの品質を向上させることができますが、厳密には必要ありません。 Azure AI 検索には、ベクター化のための組み込みアプローチがあります。

ベクターフィールドは、Azure AI 検索でのクエリ実行にのみ使用されます。結果にベクターは必要ありません。これは、人間または LLM が読み取り可能でないためです。領域の要件を最小限に抑えるには、 retrievable と stored を false に設定することをお勧めします。詳細については、「ベクターストレージと処理の最適化」を参照してください。

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

既定では、すべての searchable フィールドがクエリの実行に含まれており、すべての retrievable フィールドが結果で返されます。検索インデックスナレッジソース定義の各アクションに使用するフィールドを選択できます。

説明を追加する

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

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

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

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

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

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

名前でセマンティック構成を指定するには、2 つの方法があります。インデックスに名前付き構成 defaultSemanticConfiguration 設定されている場合、取得ではインデックスが使用されます。または、検索インデックスナレッジソース内でセマンティック構成を指定することもできます。

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

次の例は、エージェント型検索で有効なセマンティック構成を示しています。

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

メモ

応答では、 title、 terms、および contentが提供され、この構成の優先順位付けされたフィールドにマップされます。

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

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

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

インデックスの例の ベクターフィールド定義 には、 dimensions(モデルによって生成された埋め込みの数)、および vectorSearchProfileの主要なフィールド属性が示されています。

  {
    "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",
        "modelName": "text-embedding-3-large"
      }
    }
  ],
  "compressions": []
}

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

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

インデックスが構造化データに基づいている場合、スコアリングプロファイルはソリューションに価値を追加する可能性が高くなります。構造化データは複数の不連続フィールドにインデックスが付けられます。つまり、スコアリングプロファイルには、特定のフィールドのコンテンツまたは特性を対象とする条件を設定できます。

2025-05-01-preview 以降を使用してインデックスを作成した場合、スコアリングプロファイルは最後に実行されます。以前のバージョンの API を使用してインデックスが作成された場合、スコアリングプロファイルはセマンティック再ランク付けする前に評価されます。意味的にランク付けされた結果の実際の順序は、インデックスの rankingOrder プロパティによって決定されます。これは、 boostedRerankerScore (スコアリングプロファイルが適用されました) または rerankerScore (スコアリングプロファイルなし) に設定されます。

インデックスに適したスコアリングプロファイルを使用できます。次の例は、特定のフィールドで一致が見つかった場合に一致の検索スコアをブーストするスコアリングプロファイルを示しています。フィールドはブースト乗数によって重み付けされます。たとえば、"Category" フィールドで一致が見つかった場合、ブーストされたスコアは 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 コレクションの例にはシノニムマップは含まれていませんが、次の例では、国/地域名のバリアントスペルを持つシノニムマップを仮定の "locations" フィールドに割り当てる方法を示しています。

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

ナレッジソースにインデックスを追加する

ナレッジソースによって既に存在し、生成されていないスタンドアロンインデックスがある場合は、次のオブジェクトを作成します。

インデックス付きコンテンツをカプセル化するための検索インデックスナレッジソース。
エージェント検索用の 1 つ以上のナレッジソースとその他の命令を表すナレッジベース。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-06-05