Microsoft Ignite 2025 Day2のラボセッションに参加しました。
AI Searchの新機能として、Agentを使用したナレッジベースが実装されました。このAgentはインデックス、OneLake、SharePoint、Bingから回答を生成でき、またコストを切り替えることで、精度を求めるか、速度やトークン数を抑えるかなど、ユーザーの要望に柔軟に対応するような機能が提供されます。
こちらの内容について、セッションの詳細を最速でご紹介いたします。
セッションリンク
【LAB 511】Build Agentic Knowledge Bases: Next-Level RAG with Azure AI Search
現地の様子
本日、こちらの会場でラボセッションに参加させて頂きました！
ただ、非常に残念なことに、本日のLAB Sessionでは世界的な障害が起きたらしく、デモ用のPCがうまく動きませんでした。他にもLAB Sessionを見る予定だったのですが、残念ながらセッション自体が中止となってしまいました。
デモ内容解説
ナレッジベース概要
Azure AI Search に Knowledge Base という機能が実装されました。
from azure.search.documents.knowledgebases import KnowledgeBaseRetrievalClient
現地では「ライブラリで動作するAgentが、構築済みAI Searchのインデックスに問い合わせを行って回答生成する」デモを見ることができました。
おおまかに以下のようなイメージです。
ユーザー質問 ↓ Azure OpenAI が質問の意図を理解 ↓ Azure AI Search に Search Query を発行 ↓ 関連ドキュメント（hrdocs index）を取得 ↓ Azure OpenAI が回答を合成（citation 付き） ↓ 回答を返す
notebooksフォルダのNotebookを Part1~8まで順番に追っていくことで理解を進めていくことができます。
AI Searchのインデックスなどは、同じくリポジトリのdataフォルダに格納されているものを使用していたようです。infraフォルダのBicepで環境が再現可能となります。
デモではすでにAI Search等各種リソースがデプロイされ、インデックスも構築されている状態でした。WebUIによるデモと、ノートブックによるデモを順番に見せて頂きました。
データソース（Knowledge sources）
利用できるデータソースは以下の通り紹介されていました。
- Search Indexes
- One Lake
- Share Point
- Bing
現地で確認しましたが、これらは既存機能として実装されており、ライブラリをimportすることで使用することができます。外部のMCPサーバーなどは対象外と回答いただきました。
アウトプット
Agentが生成する成果物は以下の通りです。
基本的にはユーザーの質問に対する回答と、生成過程のログが見えるという理解でよいと思います。
| 用語 | 説明 |
|---|---|
| Marged Results | 最終回答（Agent が複数の検索処理を行ったときに、検索結果を一つに統合したもの） |
| Activity Log | Agent が “何をどう考えて何をやったか” をすべて追跡するログ |
| Answer Synthesis | 検索結果の “生データ” を LLM で自然言語にまとめる工程 |
コストの概念
Agentの生成においては、コストの概念が存在するようです。
最初の説明で、以下のような回答生成プロセスを辿ると記載しました。
ユーザー質問 ↓ Azure OpenAI が質問の意図を理解 ↓ Azure AI Search に Search Query を発行 ↓ 関連ドキュメント（hrdocs index）を取得 ↓ Azure OpenAI が回答を合成（citation 付き） ↓ 回答を返す
上記は単純化した概念で、実際にはどこまでコストをかけるかによって挙動が変わります。
具体的には、検索速度や消費トークン数、データソースの種類が異なり、回答生成の精度仕組みが違ってきます。これについて次に説明します。
Minimal
最小のコストで実行するケースは、次の通り紹介されていました。
- ユーザーの入力したクエリを特段変換せずに入力する
- Bing検索は使用しない
- OutputはMarged ResultsとActivity Logのみ（ユーザーの入力したクエリを変換する過程がないため）
ユーザーの入力したクエリをそのままInputとして採用 ↓ AI Searchのインデックス、OneLake、SharePointを検索 ↓ Azure OpenAI が回答を合成 ↓ Outputを返す
low
低コストで実行するケースは、次の通り紹介されていました。
- ユーザーの入力したクエリを1:nで変換する
- 4種類のデータソースを使用する
- OutputはMarged Results、Activity Log、Answer Synthesis
ユーザーの入力したクエリを「Query Planning」を使用して整形する（複数個生成） ↓ 生成した複数のクエリを使用して、 AI Searchのインデックス、OneLake、SharePoint、Bingを検索 ↓ Outputを返す
Query Planningで、ユーザの入力から複数のクエリを生成する意味としては、以下の通りです。
- 同じ文章でも 別の観点で検索すると別の文書がヒットする
- マルチホップリーズニングのため（ユーザーの入力を一度にすべて使って答えを出すのではなく、順を追って推論を重ねていく手法。1回のチャットの複数の要求が入っている場合などに有効）
- 情報欠損・曖昧性・表現ゆれへの耐性を強化
これにより中間の処理が増えますが、より精度の高い回答を生成します。
Medium
lowの処理でOutputを生成するところまでは同様ですが、ここで「Iterative Retrieval（反復的リトリーバル）」を行います。
Iterative Retrievalとは、結果が不足していればクエリを作り直して再検索する仕組みです。lowではOutputをそのまま返していましたが、mediumではOutputをAgentが確認して、不足があればAgentが過去のユーザーの入力＋検索結果から、再度Query Planningを行います。
これにより検索結果に基づいたクエリが生成されるため、よりユーザーの求める回答に近い結果が生成できるという仕組みです。
おわりに
今回のセッションを通じて、Azure AI Search に実装された「Agent を用いたナレッジベース」の全体像と価値が、かなり具体的に見えてきました。
インデックス、OneLake、SharePoint、Bing といった複数ソースを横断し、Minimal/Low/Medium といったコストプロファイルで精度・速度・トークン消費をコントロールできる点は、現場の要件に合わせた運用のしやすさにつながります。また、Activity Log や回答合成（Answer Synthesis）といった出力の可視化は、エージェントの判断を検証・改善していくうえで重要な透明性を提供してくれます。
残念ながら現地 LAB は世界的な障害の影響で十分なハンズオンができませんでしたが、公開リポジトリのノートブック（Part1〜8）と Bicep により、手元での再現が可能です。
本稿はセッション当日の情報に基づく速報です。スピードを優先しているため、記載内容に誤りや変更が含まれる可能性があります。誤り等がございましたらご容赦ください。
