Foundry IQ を探索する

これで、RAG によって AI エージェントの知識の問題がどのように解決されるかがわかります。 ただし、RAG システムをゼロから構築することは、ベクター データベースの構成、埋め込みパイプラインの実装、取得アルゴリズムのチューニング、検索インフラストラクチャの維持を意味します。 組織全体で 3 つの異なる AI エージェントが必要な場合はどうなりますか? 3 つの個別の RAG システムを構築します。

より良いアプローチがあります。

Foundry IQ とは

Foundry IQ は、Azure AI Search 上に構築された AI エージェント用のマネージド ナレッジ プラットフォームです。 RAG で学習した取得機能を提供しますが、複数のエージェントが使用できる共有サービスとして提供されます。

一般的なシナリオを考えてみましょう。 組織には、SharePoint に保存されている製品ドキュメント、Azure Blob Storage の顧客ポリシー、OneLake のトレーニング資料があります。 従来の RAG では、エージェントごとに個別に各データ ソースのインデックスを作成します。 Foundry IQ では、ナレッジ ベースを 1 回作成し、任意のエージェントをそれらに接続します。

これは、インフラストラクチャの構築からエージェント エクスペリエンスの設計に焦点を移すからです。 あなたは、エージェントがどのように情報にアクセスするかではなく、どの情報にアクセスするかの改善に時間を費やします。

ナレッジ ベースで情報を整理する方法

Foundry IQ のナレッジ ベースは、技術的な保管場所ではなく、ビジネス ドメインごとに情報を整理します。 この設計は、人々が実際に情報についてどのように考えるかを反映しています。

"SharePoint サイト A" または "BLOB コンテナー B" を検索するエージェントの代わりに、"製品ドキュメント" または "人事ポリシー" を検索します。各ナレッジ ベースは、格納場所に関係なく関連情報をまとめます。

たとえば、製品ドキュメントのナレッジ ベースには次のものが含まれます。

• SharePoint の技術仕様
• Azure Blob Storage の API ドキュメント
• OneLake からの使用状況分析
• 既存の検索インデックスからのサポート チケット

エージェントに対して、これは 1 つの統合ナレッジ ソースとして表示されます。 あなたにとって、これは個別の取得システムを管理するのではなく、データソースをナレッジベースに接続することを意味します。

データ ソースの接続

Foundry IQ は、データ ソース統合を介して既存のストレージに接続します。 SharePoint サイト、Blob コンテナー、または OneLake インスタンスを指定します。 Foundry IQ は、インデックス作成、埋め込み生成、検索の最適化を自動的に処理します。

データ ソースを追加すると、次のようになります。

1. 検出: Foundry IQ は、ストレージの場所でドキュメントをスキャンします
2. 処理: ドキュメントはチャンクされ、セマンティック検索用に埋め込まれます
3. インデックス作成: ナレッジ ベースを介してコンテンツが検索可能になる
4. 監視: ドキュメントに対する変更により、自動インデックス再作成がトリガーされる

これは、データ ソースごとに 1 回構成します。 そのナレッジ ベースに接続されているすべてのエージェントは、すぐに更新プログラムの恩恵を受けます。

組み込みの情報検索インテリジェンス

RAG で学習した取得戦略を覚えていますか? Foundry IQ は、これらを自動的に実装します。 エージェントがナレッジ ベースに対してクエリを実行すると、プラットフォームは次のようになります。

質問を分析 して、エージェントに必要な情報を理解します。 "破損したアイテムの返品ポリシーとは" のような質問では、"すべての返品ポリシーを一覧表示する" とは異なる取得が必要です。

クエリに基づいて取得方法を選択します。 単純な事実に基づく質問では、キーワード検索が使用されます。 複雑な質問は、セマンティック検索とクエリ拡張を組み合わせたものになります。

関連性スコアリングを使用して結果をランク付けします。 最もコンテキストに応じて適切な情報が最初に表示され、エージェントの応答に必要なトークンが減ります。

エージェントがソース ドキュメントを参照できるように、引用文献を提供します。 これにより、信頼が構築され、ユーザーが情報を確認できるようになります。

このインテリジェンスは、カスタム コードなしで実行されます。 ナレッジ ベースに含まれるものを定義します。 Foundry IQ は、そこから取得する方法を決定します。

エージェントを知識に接続する

エージェントに組織の知識へのアクセス権を与えるのがいかに簡単かを見てみましょう。 この例では、製品ドキュメントを使用して質問に回答できるサポート エージェントを作成します。

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition, MCPTool

project_client = AIProjectClient(endpoint=project_endpoint, credential=credential)

# Connect to the product documentation knowledge base
knowledge_tool = MCPTool(
    server_label="product-docs",
    server_url=f"{search_endpoint}/knowledgebases/product-documentation/mcp"
)

# Create an agent with knowledge access
agent = project_client.agents.create_version(
    agent_name="product-support-agent",
    definition=PromptAgentDefinition(
        model="gpt-4o-mini",
        instructions="Answer product questions using the knowledge base. Always cite your sources.",
        tools=[knowledge_tool]
    )
)

エージェントは、他のツールを使用する場合と同様に、ナレッジ ベースから情報を取得するようになりました。 取得ロジックを記述したり、検索インフラストラクチャを管理したりすることはありません。

共有された知識の利点

Foundry IQ の実際の値は、1 つのエージェントを超えてスケーリングすると発生します。 組織のニーズを想像してみてください。

• 顧客の質問に回答するサポート エージェント
• 人事ポリシーを支援する従業員アシスタント
• API の使用状況を説明する開発者エージェント

従来の RAG では、3 つの取得システムを構築して維持します。 Foundry IQ では、複数のエージェントが共有するナレッジ ベースを作成します。

• 製品ドキュメントのナレッジ ベースは、サポート エージェントと開発者エージェントの両方に対応します
• 人事ポリシーナレッジ ベースは、従業員アシスタントのみを提供します。
• 各エージェントは、必要な知識に正確にアクセスします

データ ソースを追加したり、コンテンツを絞り込んだりしてナレッジ ベースを改善すると、接続されているすべてのエージェントがすぐにメリットを得られます。 これは、組織が一貫性のあるスケーラブルな AI エージェント システムを構築する方法です。