AWS、マルチモデルエージェントを移行
- •AWSのガイドは、マルチモデル医療エージェントをAmazon Bedrock AgentCore runtimeへ移行する手順を示した
- •AgentCoreは、主要なエージェントロジックを変えずに3つのモデルバックエンドとベクトル強化検索を維持する
- •デプロイはAgentCore CLI、Python 3.10+、Node.js 20を使い、所要時間は10〜15分だ
AWSはSeptember 18、マルチモデル医療AIエージェントを、自前管理のAmazon ECSとAWS Fargate基盤からAmazon Bedrock AgentCore runtimeへ移す移行ガイドを公開した。エージェントは既存ロジックを維持し、AgentCore runtimeがコンテナのライフサイクル、スケーリング、アイデンティティ、可観測性を担う。サンプルエージェントは3つのモデルバックエンドで医療クエリを処理し、Amazon OpenSearch Serviceを通じてベクトル強化型の知識検索を使う。
アーキテクチャでは、Hugging Face smolagentsを使う単一のAgentCore管理コンテナ内に医療エージェントを配置する。smolagentsは、数行のコードでエージェントを構築するためのオープンソースPythonライブラリだ。専門的な生物医学クエリはAmazon SageMaker AI上のBioM-ELECTRA-Large-SQuAD2に送り、より広い医療推論はAmazon Bedrock上のMetaのLlama 3.1 70B Instructに送る。コンテナ化されたBioM-ELECTRAモデルサーバーは自前ホスト型デプロイを支える。従来のスタンドアロン版はAnthropicのClaude 3.5 Sonnet V2を使っていたが、ガイドはLlama 3.1 70B Instructへの切り替えにより、AgentCore runtimeがモデル非依存であることを示すとしている。
移行はbring-your-own agent方式を使うため、チームは既存のエージェントコードを特定フレームワーク向けに書き直さずにデプロイできる。AgentCore runtimeは、同じhealthcare_agentcore.pyコードをBedrockAgentCoreApp、@app.entrypoint、app.run()によるデコレーターパターンで包む。ソースによると、デコレーターとreturn文の間にあるエージェントコードはスタンドアロン版から変わらない。
デプロイスタックには、Amazon Bedrock AgentCore runtime、Amazon Bedrock、Amazon SageMaker AI、Amazon OpenSearch Service、コンテナ化モデルサーバー、AWS Identity and Access Managementが含まれる。3つのモデルバックエンドはHugging Face Messages API互換性を実装し、選択されるモデルサービスがAmazon SageMaker AI、Amazon Bedrock、コンテナ化バックエンドのいずれであっても、一貫したリクエスト形式とレスポンス形式を提供する。
ウォークスルーの前提条件には、Amazon Bedrock AgentCore runtimeへアクセスできるAWSアカウント、IAMロールとAmazon OpenSearch Serviceドメインを作成する権限、AWS Command Line Interface version 2.0以降、Node.js 20以降、AWS Cloud Development Kit、AgentCore CLI、Python 3.10以降、Docker、bedrock-agentcore Python SDKが挙げられている。実装はPython 3.10+、smolagents framework、transformers 4.55.0+、boto3を使う。ガイドは、.dockerignoreでコンテナイメージを2 GB制限内に保つべきだとも述べている。
AgentCore CLIはプロジェクトを作成し、既存エージェントをbring-your-own agentとして追加し、コンテナをビルドしてAmazon Elastic Container Registryへプッシュし、AgentCore runtime agentを作成する。デプロイは単一のagentcore deployコマンドで実行され、約10〜15分かかる。テストはAgentCore CLIまたはboto3を使ってプログラムから実行でき、agentRuntimeArnがデプロイ済みエージェントを識別し、contentTypeがリクエスト形式を設定し、payloadがプロンプトとモデル選択を運ぶ。
ソースは2つのデプロイ経路を対比している。Amazon ECSとAWS Fargateでは、チームがECSタスク定義、サービス設定、オートスケーリングポリシー、サービスごとのIAMロール、Amazon CloudWatch可観測性を定義する必要がある。Amazon Bedrock AgentCore runtimeは、同じAmazon Bedrock、Amazon SageMaker AI、コンテナ化バックエンド、Amazon OpenSearch Serviceの統合を維持しながら、管理型オーケストレーション、セッションベースのスケーリング、IAMアイデンティティ統合、組み込みのトレースとロギングを追加する。
ガイドは、医療またはその他の機微なクエリを扱う本番デプロイでは、コンテンツフィルタリングとグラウンディング検証の標準的な制御としてAmazon Bedrock Guardrailsを使うべきだとしている。クリーンアップ手順では、将来の課金を避けるため、AgentCore runtime agent、ローカル設定リソース、Amazon SageMaker AIエンドポイント、Amazon OpenSearch Serviceドメインを削除する。