メモ
一部のエージェント検索機能は、プログラムによるアクセスを介して 2026-04-01 REST API バージョンで一般提供されています。 Azure ポータルと foundry ポータルMicrosoftは、引き続きすべてのエージェント検索機能へのプレビュー専用アクセスを提供します。 一般公開されている内容とプレビューの残りの部分の内訳など、移行ガイダンスについては、「 エージェントの取得コードを最新バージョンに移行する」を参照してください。
ナレッジソースは、エージェントによる情報取得に使用されるコンテンツを指定します。 外部データによって設定された検索インデックスをカプセル化するか、直接クエリされるBingやSharePointなどのリモート ターゲットへの直接接続です。 ナレッジ ソースは、ナレッジ ベースで必要な定義です。
検索サービスで最上位レベルのリソースとしてナレッジ ソースを作成します。 各ナレッジ ソースは、 エージェント検索の条件を満たす 検索インデックスまたはサポートされている外部リソースのいずれか、正確に 1 つのデータ構造を指します。
ナレッジ ベース内の 1 つ以上のナレッジ ソースを参照します。 エージェント検索パイプラインでは、1 つの要求で複数のナレッジ ソースに対してクエリを実行できます。 サブクエリは、ナレッジ ソースごとに生成されます。 上位の結果が取得応答で返されます。
特定のナレッジ ソースでは、ナレッジ ソース定義を使用して、エージェントベースの検索に機能する完全なインデクサー パイプライン(データ ソース、スキルセット、インデクサー、インデックス)を生成できます。 知識源の情報は、手動で複数のオブジェクトを作成する代わりに、すべてのオブジェクトと分割され検索可能なインデックスの生成に使用されます。
ナレッジ ベースを作成する前に、少なくとも 1 つのナレッジ ソースがあることを確認します。 ナレッジ ソースとナレッジ ベースの完全な仕様については、 REST API リファレンスを参照してください。
ナレッジソースとの協働
作成パス: 最初にナレッジ ソースを作成してから、ナレッジ ベースを作成します。
削除パス: ナレッジ ベースを更新または削除してナレッジ ソースへの参照を削除し、ナレッジ ソースを最後に削除します。
ナレッジ ソース、そのインデックス、ナレッジ ベースはすべて、同じ検索サービス上に存在する必要があります。 外部コンテンツは、パブリック インターネット (Bing) または Microsoft テナント (リモート SharePoint) を介してアクセスされます。
サポートされているナレッジ ソース
次のナレッジ ソースを作成できます。
| サブタイプ | インデックス付きまたはリモート |
|---|---|
"searchIndex" API は 既存のインデックスをラップします。 |
インデックス 付き |
"azureBlob" API は、BLOB コンテナーからプルするインデクサー パイプラインを生成します。 |
インデックス 付き |
"indexedOneLake" API は、レイクハウスからプルするインデクサー パイプラインを生成します。 |
インデックス 付き |
"indexedSharePoint" API (プレビュー) は、SharePoint サイトからプルするインデクサー パイプラインを生成します。 |
インデックス 付き |
"remoteSharePoint" API (プレビュー) は、SharePointから直接コンテンツを取得します。 |
リモート |
"web" API は、Microsoft Bingからリアルタイムの接地データを取得します。 |
リモート |
インデックス付きナレッジ ソースは、Azure AI 検索のターゲット インデックスを指します。 クエリの実行は、検索サービスの検索エンジンに対してローカルです。 キーワード (フルテキスト検索)、ベクター、およびハイブリッド クエリ機能は、インデックス付きナレッジ ソースからデータを取得するために使用されます。
クエリ時にリモートナレッジソースにアクセスします。 エージェント検索エンジンは、プラットフォーム (Bing API または SharePoint API) にネイティブな取得 API を呼び出します。
取得されたすべてのコンテンツ (インデックス付きまたはリモート) は、関連性のスコア付け、マージ (複数のクエリを想定)、再ランク付け、取得応答で返されるAzure AI 検索のランク付けパイプラインに取り込まれます。
ナレッジ ソースの作成
ナレッジ ソースをスタンドアロン オブジェクトとして作成します。 次に、"knowledgeSources" 配列内のナレッジ ベースで指定します。
検索サービスでオブジェクトを作成するには、 Search Service 共同作成者 のアクセス許可が必要です。 インデクサー パイプラインを作成するナレッジ ソースを使用している場合は、インデックスを読み込むには 、インデックス データ共同作成者の検索 アクセス許可も必要です。 または、ロールの代わりに API 管理者キーを使用 することもできます。
Azure ポータル、REST API、またはAzure SDK パッケージを使用してナレッジ ソースを作成します。 ナレッジ ソースを作成する手順については、次のリンクを参照してください。
- 検索インデックス知識ソースを作成する方法 (既存のインデックスを覆う)
- BLOB ナレッジ ソースを作成する方法 (インデクサー パイプラインを生成する)
- OneLake ナレッジ ソースを作成する方法 (インデクサー パイプラインを生成します)
- SharePoint (インデックス付き) ナレッジ ソースを作成する方法 (インデクサー パイプラインを生成する)
- SharePoint (リモート) ナレッジ ソースを作成し、直接SharePointにクエリを送信する方法
- Web ナレッジ ソース リソースを作成する方法 (Bingのパブリック エンドポイントに接続)
ナレッジ ソースを作成したら、ナレッジ ベースで参照します。
知識ソースの使用
ナレッジ ソースの定義に alwaysQuery を設定するか、クエリの計画中に使用されるステアリング命令を使用して、ナレッジ ソースの使用状況を明示的に制御できます。 ステアリング命令は、インデックスに関する説明、またはナレッジ ソースの明示的な取得命令を参照します。この説明では、インデックスを使用するタイミングに関するガイダンスが提供されます。 クエリ計画は、LLM からの低または中程度の 取得推論作業を使用する場合に行われます。 最小限の推論努力で、ナレッジベースにリストされているすべての情報源は、すべてのクエリの範囲に含まれています。 低と中の場合、ナレッジ ベースと LLM はクエリ時に、最適な検索コーパスを提供する可能性が高いナレッジ ソースを決定できます。
ナレッジ ソースの選択ロジックは、次の要因に基づいています。
alwaysQueryが設定されていますか? "はい" の場合、ナレッジ ソースはすべてのクエリで常に使用されます。ナレッジ ソースの
name。インデックスされた知識ソースを想定したインデックスの
description。retrievalInstructionsまたはナレッジ ベース定義で指定されたは、ナレッジ ソースを含む、または除外するガイダンスを提供します。 プロンプトに似ています。 簡潔さ、トーン、書式設定を取得命令として指定できます。outputModeナレッジ ベースでは、クエリの出力と応答の内容にも影響します。
検索推論を用いて LLM の使用を管理する
すべてのソリューションが LLM クエリの計画と実行の恩恵を受けるわけではありません。 単純さと速度が LLM クエリの計画とコンテキスト エンジニアリングによって提供される利点を上回る場合は、パイプラインでの LLM 処理を防ぐための最小限の推論作業を指定します。
低および中の場合、LLM 処理のレベルは、関連性を向上させるバランスの取れたアプローチまたは最大のアプローチです。 詳細については、「取得理由付けの努力を設定」を参照してください。
メモ
前のプレビューで attemptFastPath を使用した場合、そのアプローチは retrievalReasoningEffortminimal に設定されて置き換えられました。