エージェント型AIシステムに関するIBMガイド

概要

エージェント型AIシステムは、大規模言語モデル（LLM）の汎用性と柔軟性と、従来のプログラミング・モデルの精度を融合させたものです。エージェント型AIシステムは、ユーザーや別のシステムに代わってタスクを自律的に計画し、実行することができます。エージェント型AIシステムは、複雑な問題を一連の小さなタスクに分割し、利用可能なツールを使用して外部システムと対話したり、計算タスクを実行したりすることで解決します。

これらの機能により、エージェント型AIシステムは、LLM単独の場合よりもはるかに幅広いタスクとはるかに複雑なタスクを処理できるようになります。例えば、LLMにどの車を購入するべきかを推奨するようにプロンプトした場合、モデルがトレーニングされた時点で利用可能なデータに基づいて推奨事項のリストが忠実に生成されます。一方、エージェント型AIソリューションでは、車両の使用目的（楽しみ、職場への通勤、大きな荷物の運ぶ）についての追加の詳細をプロンプトし、月末までにメーカーからのリベートが利用可能であることを知らせることができます。

生成AIアーキテクチャー・パターン

概念アーキテクチャー

ユーザーのリクエストがAIアプリケーションによって処理されるプロセスを示すフローチャート

エージェント型AIシステムは、以下のコンポーネントで構成されています。

Agent Orchestrationコンポーネントは、一連のエージェントのアクションを管理および調整します。Agent Orchestrationコンポーネントは、LLMを利用して複雑なタスクを解決するためのワークフローを分解し動的に生成する場合もあれば、ビジネス・プロセス・モデリング表記法（BPMN）、ビジネス・プロセス実行言語（BPEL）、またはその他のワークフロー・テクノロジーを用いて定義された静的に定義されたワークフローのみを使用している場合もあります。
1つ以上のエージェントは、指定された目標を達成するためにアクションを自己決定して実行できるソフトウェアです。エージェントは通常、LLMを使用して、タスクを完了するための計画を動的に生成します。エージェントは、ツールを利用して外部システムと対話（例：エンタープライズ・アプリケーションAPI）したり、ナレッジ・ストアを検索（例：Wikipediaへのアクセス）したり、計算を実行（例：LLMだけでは正確または効果的に実行できない数学的オペレーション）したりできます。
最後に、ツールは企業や外部のソースおよびシステムと連携して情報を取得し、記録システムを更新します。

エージェントには、以下の図に示す独自の概念アーキテクチャーがあります。

エージェントは次のコア・コンポーネントで構成されています。

インプット・コンポーネントは、エージェントにアクションを実行するトリガーとなる1つ以上のインプット・ソースです。一般的に、これはユーザーからの自然言語クエリーまたはタスクですが、ファイルの作成、Kafkaキュー上のメッセージ、構造化されたAPI呼び出しなどのシステムイベントである場合もあります。
実行コンポーネントは、必要なタスクを実行するためにエージェントのアクティビティーを調整します。一般に、実行コンポーネントによって実行される最初のタスクは、（i）エージェントが利用できるツールとリソースのリストをマーシャリングすること、（ii）Planning and Reflectionコンポーネントを呼び出して、タスクを実行するためのアクティビティー・プランを生成することです。実行コンポーネントは、生成された計画を実行し、必要に応じてツールやリソースを呼び出して情報を収集したり、エージェントの外部環境を変更したりします。また、計画とリフレクションコンポーネントを定期的に再呼び出し、ツールの応答/障害に応じてアクティビティー・プランを適応させることができます。
計画とリフレクションコンポーネントは、一般的にLLMであり、エージェントは段階的なアクションプランを作成してインプットに応じてタスクを達成し、アクションの成果を反映してそれに応じて計画を適応させることができます。
ツール統合コンポーネントは、エージェントが「ツール」を使用してAPIを呼び出し、リソースにアクセスしてアクションを完了し、タスク全体の完了に貢献する情報を収集することを可能にします。
メモリー・コンポーネントは、短期的なタスク内、コンテキストに加えて長期的な知識も管理します。これにより、エージェントはタスクの呼び出し（例：「最後の発注書を取り消す」など）全体でコンテキストを維持し過去のアクションの分析基盤や将来のアクションの最適化を提供することができます。

図に示されていない追加のコンポーネントを追加することで、運用上のエージェント管理、性能監視、およびID伝播やデータ漏洩防止などのセキュリティー制御を提供できます。

概念チュートリアル

以下の図は、概念アーキテクチャーを介した制御と情報の流れを示しています。

ユーザーが生成AIアプリケーション（チャットボットやエンタープライズ・アプリケーション内のクエリー・インターフェースなど）にクエリーを送信します。
生成AIアプリケーションは、ユーザーのクエリーを、生のクエリー（例：AIアプリケーションがチャット・インターフェース）か、事前定義されたワークフローのトリガー（例：購入申請の開始）のいずれかとなる形態でAgent Orchestratorに受け渡します。ウォークスルーでは、未加工のクエリーが想定されます。
ルーターは調整されたLLMを使用して、ユーザーのクエリーを回答に到達するために必要な一連のアクションまたはステップに分割します。例えば、「カナダのマニトバ州ウィニペグの現在の気温は？この一年間の過去の平均と比較してどうなるでしょうか？」という質問に答えるため、LLMは、次の概念アクションのリストで応答する可能性があります。
- Weatherエージェントを使用してウィニペグの現在の気温を検索します。
- カレンダー・エージェントを使用して現在の日付を検索します。
- 検索エージェントを使用して、この日付のウィニペグの平均気温を検索します。
- 計算エージェントを使用して、現在の気温と過去の平均の差を求めます。
- 言語エージェントを使用して自然言語応答を作成します。
その後、Orchestratorはリスト内の各アクションに適切なエージェントを呼び出します。ステップ3の例に進みます。
- OrchestratorはWeatherエージェントを呼び出して、ウィニペグの現在の気温（-1°C）を取得します。
- Orchestratorはカレンダー・エージェントを呼び出して、現在の日付2023年11月9日を取得します。
- Orchestratorは検索エージェントを使用して、11月9日のウィニペグの正常気温1.4℃を検索します。
- OrchestratorはCalculatorエージェントを呼び出して、2つの温度の差（-1 - 1.4 = -2.4）を検索します。
- Orchestratorは、言語エージェントを使用して、収集されたデータを使用して最初のクエリーに対する応答を作成します。
エージェントが呼び出されると、Orchestratorと同様にLLMを使用してアクションを計画できます。例を続けると、Weatherエージェントが「ウィニペグの現在の気温はいくらですか？」というリクエストを受け取り、それに対して次の計画を生成します。
- Winnipegが所在する国を検索します。
- ウィニペグの国の権威ある国立気象局を調べます。
- Weather APIを使用して、ウィニペグの現在の気温について天気予報サービスに照会します。
- エージェントは、Winnipegが所在する国（カナダ）をLLMまたは外部サービスを使用して検索し、その値を使用してカナダの全国気象サービス（Environment Canada）を検索し、Weather APIを使用してWinnipegの現在の気温を取得します。
結果の応答は生成AIアプリケーションに返されます。この例では、「ウィンニペグの現在の気温は-1℃です。これは、従来の標準である1.4°Cよりも2.4°C低い値です」
定式化された応答がユーザーに返されます。

IBM製品アーキテクチャー

上の図は、IBM製品とエージェント型AIアーキテクチャーのマッピングを示しています。

watsonx Orchestrateは、以下を組み合わせた「オールインワン」のエージェント型AIソリューションです。

ツール（watsonx Orchestrateではスキルと呼ばれる）の公開と管理。
宣言型ワークフローを使用した複雑な複数ステップのプロセスへのスキルの構成。
人事や購買などの水平ビジネス分野向けに、事前構築された分野特化型エージェント。

watsonx.aiのAgent Builderは、開発者がエージェントを構築し、事前構築されたフローを使用してツールを定義および管理できるローコード/ノーコード・ツールです。

アーキテクチャーの決定と考慮事項

オーケストレーションストラテジー

Agentオーケストレーションはさまざまなアプローチを用いて実装できます。集中型オーケストレーションのアプローチでは、単一のマスター・オーケストレーション・コンポーネントを使用して、システム内の他のすべてのエージェントのアクションを管理します。設定と管理を一元化することで、システム全体の管理と制御が簡単になり、トラブルシューティングも容易になります。欠点は、リクエスト量やエージェントの数が増加するにつれて、単一の制御ポイントがボトルネックになり、拡張性の課題につながる可能性があることです。

分散型オーケストレーションアプローチは、エージェントがタスクを引き出し、結果をポストするタスクキューを実装し、黒板システムのように、エージェント間でマルチパートのタスクをルーティングします。分散型オーケストレーション・ソリューションは、堅牢で耐障害性が高くなりますが、システムがより優れた機能を備えて大規模になるにつれて、設計とトラブルシューティングが困難になります。

最後に、階層的オーケストレーションアプローチは、集中型アプローチと分散型アプローチの要素を組み合わせます。階層型オーケストレーションでは、マスター・オーケストレーターを使用して高レベルのエージェントのアクションを調整し、高レベルのエージェントが他のエージェントを呼び出して複雑なタスクを完了できます。これにより、集中型アプローチの管理と制御の容易さの多くが維持されますが、リクエスト量が多い場合やエージェントの数が多い場合に、中央制御コンポーネントがボトルネックになる可能性は低減されます。

エージェントの粒度

AIエージェントの粒度は、エージェントが実行できるタスクの複雑さを指します。高粒度エージェントは、多くのタスクまたは少数のタスクを詳細に実行できますが、低粒度エージェントは、少数のタスクまたは1つのタスクのみを低詳細レベルで実行できる場合があります。これをより明確にするために、カスタマー・サービス担当者を考えてみましょう。粒度の低いエージェントは、製品に関する単純な質問（例：「黒ですか？」）しか回答できませんが、粒度の高いエージェントは、現地の在庫を確認し、製品を顧客の自宅に届けるための配送を手配することができます。

エージェント・ソリューションの設計者は、システム内の個々のエージェントの粒度をどの程度にするかを決定する必要があります。例えば、少数の高粒度エージェント、あるいは多数の低粒度エージェントを持つようにします。高粒度エージェントの幅広い機能により、コストとなるコンピューティング・リソース要件が大きくなり、タスクの完了時間が長くなります。低粒度エージェントは能力が低いですが、焦点が狭いため、必要なコンピューティング・リソースが少なく、一般にタスクをより速く完了します。

「適切な」レベルの粒度はまだ不明ですが、初期のエクスペリエンスから、重点を置いたビジネス・プロセスに合わせて低粒度エージェントを作成すること（例：Purchase_Order_Processing_Agent）は、リソース要件、処理速度、ソリューションの複雑さのバランスが取れていることを示唆しています。その後、低粒度エージェントを静的ワークフローに組み込んだり、大規模なプロセスの一部として高粒度エージェントによって呼び出したりすることができます。

静的ワークフローと動的ワークフローの違い

エージェント型AIソリューションの設計者は、事前定義された静的なプロセスおよびワークフローに従うエージェントと、ユーザーのプロンプトに応じて動的に生成されるワークフローのバランスを取る必要があります。正しい答えや不正確な答えはありませんが、アーキテクトは次の推奨事項と考慮事項を考慮することをお勧めします。

静的ワークフローは、ナレッジ・ドメイン（法務や会計など）をまたぐ複数の複雑なステップで構成されたビジネス・プロセスや、規制当局の監督対象となるビジネス・プロセスに使用する必要があります。このような場合、静的ワークフローを使用すると、アーキテクトに次のようなメリットがもたらされます。
- 静的ワークフローは、計測、監視、監査が（比較的）簡単であり、ワークフロー自体が規制遵守の証拠として使用できます。動的に生成されたワークフローは、実行され、個々のプロセスの実行を個々のエージェントのログから再構築する必要があるため、監視がより困難になります。動的なワークフローは、タスクの順序を変更して、監査とコンプライアンス監視をさらに複雑にする可能性もあります。
- 専門分野間の「ハンドオフ」を明確に定義することで、責任が明確に分離され、渡される情報が完全で正確であることを容易に確認できるようになります。動的に生成されたワークフローでも同じことを実現できますが、そのためには、設計と実装においてより細やかな注意が必要となります。
動的ワークフローは、時間的に近接して実行され、ナレッジ・ドメインを横断せず、実行は規制の監督や管理の対象とならない「シングル・ステップ」のアクティビティーまたは機能に使用する必要があります。