Zenn
🦁

Multi-Agent Orchestrator クイックスタートしてみた

2024/11/22に公開
Python
LangChain
LangGraph
multiagentorchestr
tech

マルチエージェント構築システムとして一強と思っていたLangGraphでしたが、awsやmicrosoftも特化したものを開発してきました。今回は、awsのMulti-Agent Orchestratorについて書いきます

Multi-Agent Orchestratorとは？

概要

Amazon Web Services（AWS）が提供するMulti-Agent Orchestratorは、複数の専門的なAIエージェントを管理し、ユーザーからの要求を適切なエージェントにルーティングするための強力なフレームワークです。このフレームワークにより、スケーラブルでモジュール化されたAIアプリケーションを迅速に開発・デプロイでき、複雑な会話やタスクを効率的に処理可能です。

特徴

  • 🧠 知的なインテント分類
    ユーザーのリクエストを動的に解析し、最適なエージェントにルーティング。

  • 🌊 柔軟なエージェント応答
    ストリーミング応答と非ストリーミング応答の両方をサポート。

  • 📚 コンテキスト管理
    複数のエージェント間で会話のコンテキストを維持し、一貫したインタラクションを実現。

  • 🔧 拡張可能なアーキテクチャ
    新しいエージェントの統合や既存エージェントのカスタマイズが容易。

  • 🌐 ユニバーサルデプロイ
    AWS Lambda、ローカル環境、他のクラウドプラットフォームなど、どこでも実行可能。

  • 🚀 スケーラブルな設計
    複数の同時会話を効率的に処理し、シンプルなチャットボットから複雑なAIシステムまでスケーリング可能。

  • 📊 エージェントのオーバーラップ分析
    エージェント間の機能重複を分析し、最適化するためのツールを提供。

  • 📦 事前構成されたエージェント
    Amazon Bedrockモデルを活用したすぐに使えるエージェントを用意。

仕組み

Multi-Agent Orchestratorは以下のプロセスでユーザーのリクエストを処理します：

  1. リクエストの開始
    ユーザーがオーケストレーターにリクエストを送信。

  2. 分類
    Classifierがユーザーのリクエスト、エージェントの説明、全エージェントの会話履歴を分析し、最適なエージェントを特定。

  3. エージェントの選択
    Classifierが選択したエージェントの名前を返す。

  4. リクエストのルーティング
    ユーザーの入力が選択されたエージェントに送信。

  5. エージェントの処理
    エージェントは自身の会話履歴を用いてリクエストを処理し、応答を生成。

  6. 会話の保存
    オーケストレーターがユーザーの入力とエージェントの応答を保存し、コンテキストを維持。

  7. 応答の配信
    オーケストレーターがエージェントの応答をユーザーに返す。

このプロセスにより、ユーザーのリクエストが最も適切なエージェントにルーティングされ、一貫した会話体験が提供されます。

エージェントの役割

エージェントは次のような要素を組み込めます：

  • LLM（大規模言語モデル）
    Amazon Bedrockや他のクラウド/オンプレミスのLLM。

  • APIコール

  • AWS Lambda関数

  • ローカルプロセス

  • Amazon Lex Bot

  • 特定のタスクやプロセス。

各エージェントには名前と説明が必要で、これがオーケストレーターによる適切なルーティングの鍵となります。

エージェントの抽象化：統一された処理

Multi-Agent Orchestratorは、エージェントの標準化された実装により、異なるクラウドプロバイダー、LLMモデル、クラウドおよびローカルソリューションなど、さまざまな環境で一貫したインターフェースを提供します。

主なコンポーネント

  • Orchestrator
    中央の調整役で、Classifier、Agents、Storage、Retrievers間の情報の流れを管理。

  • Classifier
    ユーザーの入力や会話履歴を分析し、最適なエージェントを特定。

  • Agents
    特定のタスクを実行するエージェントで、ビルトインやカスタムのエージェントを利用可能。

  • Conversation Storage
    会話の履歴を保存し、コンテキストを維持。

  • Retrievers
    エージェントのパフォーマンスを向上させるため、必要な情報をオンデマンドで提供。

実際に始めてみる

セットアップ

bash
mkdir test_multi_agent_orchestrator
cd test_multi_agent_orchestrator

python -m venv venv
source venv/bin/activate

AWS CLIの設定を確認し、現在のAWSアカウント情報を取得：

bash
aws sts get-caller-identity

出力例：

json
{
  "UserId": "XXXXX",
  "Account": "123456789012",
  "Arn": "arn:aws:iam::123456789012:user/your-username"
}

Amazon Bedrockでのモデルアクセスリクエスト

Amazon Bedrockのモデルにアクセスするためには、事前にアクセス権限をリクエスト。

インストール

bash
pip install multi-agent-orchestrator

コードの実装

オーケストレーターの作成

quickstart.py
import uuid
import asyncio
from typing import Optional, List, Dict, Any
import json
import sys
from multi_agent_orchestrator.orchestrator import MultiAgentOrchestrator, OrchestratorConfig
from multi_agent_orchestrator.agents import (BedrockLLMAgent,
 BedrockLLMAgentOptions,
 AgentResponse,
 AgentCallbacks)
from multi_agent_orchestrator.types import ConversationMessage, ParticipantRole

orchestrator = MultiAgentOrchestrator(options=OrchestratorConfig(
  LOG_AGENT_CHAT=True,
  LOG_CLASSIFIER_CHAT=True,
  LOG_CLASSIFIER_RAW_OUTPUT=True,
  LOG_CLASSIFIER_OUTPUT=True,
  LOG_EXECUTION_TIMES=True,
  MAX_RETRIES=3,
  USE_DEFAULT_AGENT_IF_NONE_IDENTIFIED=True,
  MAX_MESSAGE_PAIRS_PER_AGENT=10
))

エージェントの追加

quickstart.py
class BedrockLLMAgentCallbacks(AgentCallbacks):
    def on_llm_new_token(self, token: str) -> None:
        # handle response streaming here
        print(token, end='', flush=True)

tech_agent = BedrockLLMAgent(BedrockLLMAgentOptions(
  name="Tech Agent",
  streaming=True,
  description="Specializes in technology areas including software development, hardware, AI, \
  cybersecurity, blockchain, cloud computing, emerging tech innovations, and pricing/costs \
  related to technology products and services.",
  model_id="anthropic.claude-3-sonnet-20240229-v1:0",
  callbacks=BedrockLLMAgentCallbacks()
))
orchestrator.add_agent(tech_agent)

クエリの送信

quickstart.py
from multi_agent_orchestrator.agents import AgentResponse

async def handle_request(_orchestrator: MultiAgentOrchestrator, _user_input: str, _user_id: str, _session_id: str):
    response: AgentResponse = await _orchestrator.route_request(_user_input, _user_id, _session_id)
    print("\n選択されたエージェント:", response.metadata.agent_name)
    if response.streaming:
        pass  # ストリーミング応答はコールバックで処理済み
    else:
        print("応答:", response.output.content[0]['text'])

if __name__ == "__main__":
    USER_ID = "user123"
    SESSION_ID = str(uuid.uuid4())
    print("Multi-Agentシステムへようこそ。'quit'と入力すると終了します。")
    while True:
        user_input = input("\nあなた: ").strip()
        if user_input.lower() == 'quit':
            print("プログラムを終了します。さようなら！")
            sys.exit()
        asyncio.run(handle_request(orchestrator, user_input, USER_ID, SESSION_ID))
bash
python quickstart.py

以下のようにchatが使えます。

bash
python quickstart.py
INFO:botocore.credentials:Found credentials in environment variables.
Welcome to the interactive Multi-Agent system. Type 'quit' to exit.

You:

エラーが出た場合

bash
ERROR:multi_agent_orchestrator.utils.logger:Error processing request:An error occurred (AccessDeniedException) when calling the Converse operation: You don't have access to the model with the specified model ID.
ERROR:multi_agent_orchestrator.utils.logger:Error during intent classification: An error occurred (AccessDeniedException) when calling the Converse operation: You don't have access to the model with the specified model ID.

このエラーは、aws bedrock上で、モデルへのアクセス権限がない。というエラーです。
aws bedrockへアクセスしてモデルへのアクセス権限を許可しましょう。

これは、Amazon Bedrock上のモデルへのアクセス権限がないことを示しています。事前にモデルへのアクセスリクエストを行い、許可を得る必要があります。

実行結果

bash
Multi-Agentシステムへようこそ。'quit'と入力すると終了します。

あなた: こんにちは

選択されたエージェント: DEFAULT
応答: こんにちは！今日はどのようにお手伝いできますか？

あなた: 最新のAI技術について教えてください

選択されたエージェント: Tech Agent
応答: 現在の最新AI技術としては、生成系AIや大規模言語モデル（LLM）が注目されています。これらは、大量のデータを学習し、人間のような自然な言語生成や理解を可能にします。また、ディープラーニングの進化により、画像認識や音声認識、自動運転などの分野でも大きな進歩が見られます。

あなた: quit
プログラムを終了します。さようなら！

主要な違い

Multi-Agent Orchestrator と LangGraph の比較

項目 Multi-Agent Orchestrator LangGraph
基本コンセプト 複数の専門エージェントを管理・ルーティングするエージェント中心のフレームワーク グラフベースでLLMやツールを接続し、ワークフローを設計する視覚的なフレームワーク
設計思想 階層的（オーケストレーターがエージェント間の流れを一元管理） モジュール的（各コンポーネントを自由に繋ぎ合わせる構造）
主な用途 複雑なマルチエージェントシステムの構築やインテリジェントルーティング 視覚的・柔軟なデータフローおよびツールやエージェント間の連携の設計
AWS統合 強固な統合（Amazon Bedrock、Amazon Lex、AWS Lambdaなど） AWSを含むクラウド・オンプレミスの多様な環境に対応可能
ルーティングの管理 Classifierによる自動インテント分類とルーティング グラフ構造に基づいた手動または設計済みのルーティング
コンテキスト管理 オーケストレーターが会話のコンテキストを一元管理 ユーザーがグラフ設計時にコンテキスト設計をカスタム設定
スケーラビリティ AWSのスケーラブルなインフラ（Lambda、DynamoDB）を活用 プラットフォーム非依存で、任意のクラウドまたはオンプレミスにスケール可能
エージェントの種類 Bedrock LLM Agent、Amazon Lex Bot Agent、Lambda Agent、Chain Agent などのビルトインエージェント ノードとしてエージェントやツールを自由に登録可能
デプロイ 主にAWS環境（Lambda、CloudFormationなど） 任意のクラウドまたはオンプレミス対応
適用ユースケース AWS環境に深く統合された信頼性とスケーラビリティが必要なケース ビジュアルな設計が求められ、プラットフォーム非依存な環境で稼働したいケース

どちらを選ぶべき？

  • Multi-Agent Orchestrator:

    • AWSを活用したスケーラブルかつ信頼性の高いシステムを構築したい場合。
    • インテリジェントなエージェント選択、会話コンテキスト管理が必須な大規模プロジェクトに適している。
    • AWSの既存リソースを最大限に活用しつつ、構築を加速させたい場合。

  • LangGraph:

    • 複雑で自由な設計をしたい。
    • クラウド依存ではなく、オンプレミスやマルチクラウド対応を重視する場合。

感想

Multi-Agent Orchestrator確かに、マルチエージェント実装できました。
しかし、aws依存、開発者の自由な発想による自由性はあまり感じられなかった。

とはいえ、aws依存はawsそもそも最強なので依存していることは問題にならないケースも多いだろう。
また、自由な発想と言っても、それを社会実装するとなった時は自由よりも確実に実装できる。確実に制御できるという方に重きを置くべきなので、問題にならないと思っている。

よって、今後の発展が楽しみです。

Discussion