Microsoft FoundryのFoundry IQについて
ソースは下記2つの記事です。Foundry IQとは何なのかまとめていきます。
Foundry IQはエージェントのための統合ナレッジレイヤーです。
Foundry IQを含む4つの主要機能により、エージェントはユーザーの権限に応じて、インデックスや MCPを経由して社内データへアクセスしたり、Web検索で外部データを取得できます。
さらに、検索時には実行計画（Query Planning）と改善（Reflective Search）を繰り返す仕組みが働くため、より精度の高い回答を生成できるようになっています。
-
Foundry IQ ナレッジベース：Foundry IQは、インデックス化されたリモートナレッジソース（ M365 SharePoint、Fabric IQ、OneLake、Azure Blob Storage、Azure AI Search、Web、プライベートプレビュー版のMCP）からデータにアクセスし、すべて同じナレッジベースに集約。
-
インデックス化および統合されたナレッジソースへの自動アクセス：インデックス化されたナレッジソースとリモートナレッジソースの両方に接続することで、エージェントがアクセスできるデータの範囲を拡大。
-
ナレッジベースのエージェント検索エンジン: AIを使用してソース全体の回答を計画、検索、および統合する自己反映型クエリエンジン。
-
エンタープライズグレードのセキュリティとガバナンス: ドキュメントレベルのアクセス制御、既存の権限モデルとの整合、インデックスデータとリモートデータの両方のオプションをサポート。
主にナレッジベースのエージェント検索エンジンについてのまとめになります。
Defining agentic retrieval in knowledge bases
ナレッジベースの検索では検索推論努力レベル（retrieval reasoning effort）が「minimal」「low」「medium」の3種類選択できます。
| 機能 | minimal | low | medium |
|---|---|---|---|
| ソース選択とクエリ計画 | サポートされていません | はい | はい |
| 統合検索（複数の知識ソースを並行して検索） | すべて一度に | ソース選択に基づく | ソース選択に基づく |
| Webの基盤となる知識源 | サポートされていません | はい（回答生成と併用） | はい（回答生成と併用） |
| セマンティックランキング（SR） | はい | はい | はい |
| 意味分類器（SC） | いいえ | いいえ | はい |
| 反射的な検索 | いいえ | いいえ | 最大1つの追加取得ステップ |
| 回答生成 | いいえ | はい | はい |
mediumの際の検索実行フローは下記のようになるようです。
各ステップを図示すると下記。
個人的にはStep4、5、6が気になったので、読んでいきます。
Step4. Ranking and Filtering
直訳
Azure AI Search以外を含むすべてのソースからの上位の結果は、セマンティックランカーを使用してスコア付けされ、ランク付けされます。セマンティックランカーは、コンテンツタイプ全体で正規化され調整されたスコアを提供し、取得されたすべてのコンテンツを一貫したスケールに配置できます。また、各コンテンツチャンクのクエリ依存の要約として使用できる抽出キャプションも生成します。ドキュメントは、サブクエリによってナレッジソース全体からグループ化されます (たとえば、同じサブクエリのすべてのドキュメントは、セマンティックランカースコアによって並べ替えられます)。次に、各グループの上位10件のドキュメントが、下流のRAGタスクに最適化されたより強力なスコアを提供する新しいセマンティック分類器を使用して再度スコア付けされます。図では、セマンティックランカーをL2、セマンティック分類器(SC)をL3と呼んでいます。
一つのIndexではなく様々なリソースにアクセスするため、検索リソースごとのセマンティックランカー評価(L2)と様々なリソースのスコアを評価するセマンティック分類器（L3）で評価し、終了判定（More Information Required）をしているようです。
このL3にSLMが利用されていて、余計なLLM利用を抑えていそうです。
Step5. Reflective search
直訳
別の呼び出しで、上位10件のドキュメントのキャプションが連結され、セマンティック分類器によって検査され、次の検索ラウンドが必要かどうかが判断されます。サブクエリの情報ニーズが返された情報で満たされているように見える場合、検索フェーズは完了です。セマンティック分類器がクエリが複雑であるか、情報ニーズが満たされていないと判断した場合、キャプションのコレクションは別のLLMプロンプトに送信されます。このプロンプトは、サブクエリが満たされているかどうかを「反映」します。満たされている場合、検索フェーズは完了です。満たされていない場合は、最適なドキュメントが保持され、新しい知識ソースとクエリのセットが生成されます。この2回目の検索で検索フェーズは完了します。この機能は反復検索と呼ばれます。
Reflective searchは、簡単な質問のときは追加検索を避け、難しい質問のときだけ追加検索するための仕組み。
Semantic Classifier（SC）という小型モデルが「もう十分答えに必要な情報が得られているか」を判定し、必要に応じてLLMがその判定を上書きする。
- 簡単なクエリ：SCとLLMが「追加検索は不要」と一致し、早期終了する
- 中くらいの難度：SCは慎重で、LLMが追加検索を指示するケースが増える
- 最も難しいクエリ：SCとLLMが一致して「もう1回検索しよう」と判断する
これにより、品質を落とさずコスト（LLM呼び出し）とレイテンシを削減できる。
下記、いくつかのデータセットでの終了判定精度を比較したものです。
| Dataset | KS Type | SC Exit % | SC+LLM Exit % | Minimal Answer Score | Assessment |
|---|---|---|---|---|---|
| nq | Web | 89 | 89 | 97 | SC and LLM agree |
| hotpot | Web | 26 | 26 | 79 | |
| sec-open | AZS | 21 | 79 | 81 | SC defers to LLM |
| sec-hard | AZS | 13 | 77 | 83 | |
| sec-harder | AZS | 4 | 77 | 64 | |
| Frames | Web | 4 | 4 | 54 | SC and LLM agree |
| sec-hardest | AZS | 3 | 3 | 59 |
SCは簡単な問題では終了判定をLLMと同様に実行可能で、難易度が高くなると終了判定をLLMに委ねるようです。
ちなみに、SCは推論速度にも優れているようです。
| Document Length (tokens) | Latency (ms for 11 inferences) |
|---|---|
| 2048 | 148 |
| 1024 | 81 |
| 512 | 49 |
| 256 | 42 |
最大22kトークンのバッチでも150ms未満（H100のGPU）
エージェント処理は多段ステップで遅延が蓄積するため、高速なSCが重要になります。
速度面でもSLMを使う理由があるようです。
Step6. Results merging
直訳
結果は、多層ラウンドロビン方式を用いて、反復処理、知識ソース、クエリ間でマージされます。検索推論処理（または顧客によるオーバーライド）によって設定されたトークンバジェットに基づいて、最適なドキュメントからレスポンスが構築されます。
このロジックについては詳細がないので、妄想にはなりますが、
Reflective Searchで下記のようなパターンを同時に扱うため、順番・重複・優先度・品質判断が必要になりそうです。
- 複数の検索ラウンド
- 各ラウンドに複数のサブクエリ
- 各サブクエリに複数の検索ソース
- 各ソースに最大50件の文書
マージ範囲：ソースごとのReranked top-Kを収集（L2 & L3で精査済み）
前工程（Ranking & Filtering）で絞られた品質が高いtopK（top10？）が対象
Round Robin Merge
Reflective Searchが3回行われた場合、Result1、2、3を均等に取り込む
→詳細は不明
Dedupe(重複削除)
明記はされていない
Token Budget Filtering
Effort設定ごとのToken Budgetに合わせて制限。
| Effort | 目的 |
|---|---|
| Minimal | 高速・低コスト |
| Low | 通常 |
| Medium | 最大推論能力 |
各Effortにはtoken budgetがあり、Result Mergingではこれを超えないように調整される。
→詳細不明
Final Merged Context
LLMに渡す最終コンテキストを作成→詳細不明
Foundry IQシステム全体のフロー
-
ナレッジベース構成 – 開発者はFoundryポータル(UI)またはAzureポータル上でナレッジベースを作成し、データソースやモデル設定を行います。必要に応じ、ローカルファイルやクラウドストレージ上の文書は自動インデックス化されます。
-
エージェントからの質問 – ユーザーがエージェントに質問を投げると、その問い合わせはナレッジベースのAPIに渡されます。エージェント（例えばAgent Framework上のChatAgent）は KnowledgeBaseRetrievalClient などを経由してFoundry IQにクエリを送信します。
-
バックエンドでの検索・推論 – Foundry IQエンジンが問い合わせを受け取ると、内部でAIモデルによるクエリ解析と複数ソースへの検索オーケストレーションが行われます（詳細は次節）。Azure AI Searchがベースとなっており、ベクトル検索＋キーワード検索によりインデックスに対する照会や、外部Web/SharePoint検索APIへのクエリ発行が自動で行われます。
-
結果の統合と応答 – バックエンドは各ソースから集約した情報を元に必要ならLLMで回答を生成し、出典と共にエージェント側へ返します。エージェントは受け取ったコンテキストや回答をユーザーに提示します。
このように、Foundry IQによりエージェント開発者は個別のデータ接続や検索手順を実装することなく、「ナレッジベースに聞く」という単一の操作で組織内外の知識にアクセスできます。実際、エージェントに必要な知識をプラグインする感覚で利用でき、新規エージェントごとにRAGのパイプラインを一から構築する負担が大幅に軽減されます。
Agentic Retrievalの処理フロー
MS Foundryの方に下記のようなフローを見せていただいたので、一応載せます。
こちらの方がわかりやすいかなと。
まとめ
AzureAISearchは2つの検索モードを選択できると言っています。
このMulti-hop reasoningってどんな仕組みというのがなんとなくわかった気がしました。
| Aspect | Semantic Mode | Agentic Mode (Foundry IQ) |
|---|---|---|
| Speed | Fast | Slower (includes query planning) |
| Accuracy | Good for simple queries | Excellent for complex queries |
| Query Complexity | Single-hop lookups | Multi-hop reasoning |
| Best For | Speed-critical applications | Research / analytical understanding tasks |
富豪なアプローチというだけでなく、データソースの選択、SC評価、ResultMergeと精度とコストを考えたアプローチになっていると思いました。
また、AI Searchが単なるIndexではなく大きく進化したとも思いました。
ちなみに、この一連の仕組みで、どうやって精度が向上していくかをFoundryチームの人に聞いたら、
この仕組みで出力された回答が精度が高いので、自身の回答を学習していくというような回答をいただきました。
個人的にはインデックス改善など、出典元のデータの整備とか、HLRFの仕組みが必要なのかなーと思いましたが、そこは今後出てくるか、ワークフローと紐付けてのFB利用とかになっていくのかなと思いました。
この辺のFoundry IQのサンプルPJで、試せるみたいです。
Discussion