Amazon Web Services ブログ
Amazon Bedrock Agents を使用して堅牢な生成 AI アプリケーションを構築するためのベストプラクティス – Part 2
本ブログは2024年10月21日に公開された「Best practices for building robust generative AI applications with Amazon Bedrock Agents – Part 2」を翻訳したものです。
この連載の第 1 部では、Amazon Bedrock Agents を使用して正確で信頼性の高いエージェントを作成するためのベストプラクティスを探りました。Amazon Bedrock Agents は、複数ステップのタスクをオーケストレーションすることで、生成 AI アプリケーションの開発を加速するのに役立ちます。エージェントは、基盤モデル (FM) の推論能力を利用して、問題を複数のステップに分解する計画を立てます。また、開発者が提供した指示とモデルを組み合わせてオーケストレーション計画を作成し、その計画を実行します。さらに、エージェントは企業の API や、検索拡張生成 (RAG) を通じて外部の知識を利用することができます。
この第 2 部では、堅牢で拡張性が高く、セキュアなインテリジェントエージェントを構築するのに役立つ、アーキテクチャ上の考慮事項と開発ライフサイクルのプラクティスについて詳しく説明します。会話型 AI の世界を探索し始めたばかりの方も、既存のエージェントのデプロイメントを最適化したい方も、この包括的なガイドは長期的に価値のある洞察と実践的なヒントを提供し、目標達成の助けとなるでしょう。
包括的なログ記録とオブザーバビリティの実現
エージェント開発の初期段階から、徹底的なログ記録とオブザーバビリティの実現を行う必要があります。これはエージェントのデバッグ、監査、トラブルシューティングに不可欠です。包括的なログ記録を実現する第一歩は、Amazon Bedrock モデル呼び出しログを有効にして、プロンプトとレスポンスをアカウントで安全に取得することです。
Amazon Bedrock Agents は、トレースも提供します。ここでは、エージェントがオーケストレーションしているステップ、 FM の呼出し元となるプロンプト、ナレッジベースから返される参照結果、エージェントによって生成されるコードの概要が示されます。トレースイベントはリアルタイムでストリーミングされるため、エンドユーザーにリクエストの進捗状況を通知するための UX キューをカスタマイズできます。エージェントのトレースをログに記録し、エージェントを追跡、およびトラブルシューティングすることができます。
エージェントアプリケーションを本番環境に移行する際は、ログを継続的に分析するためのモニタリングワークフローを設定することがベストプラクティスです。カスタムソリューションを作成するか、Bedrock-ICYM などのオープンソースソリューションを使用することができます。
Infrastructure as Code (IaC) の利用
他のソフトウェア開発プロジェクトと同様に、反復的で信頼性の高いデプロイを容易にするために、Infrastructure as Code (IaC) を使用する必要があります。これにより、繰り返し可能で本番環境に対応したエージェントを作成し、簡単に再現、テスト、監視できるようになります。Amazon Bedrock Agents では、AWS CloudFormation、AWS Cloud Development Kit (AWS CDK)、または Terraform で IaC コードを記述できます。また、Agent Blueprints コンストラクトを使用して始めることをお勧めします。Amazon Bedrock Agents の最も一般的な機能のブループリントテンプレートを提供しており、単一の AWS CDK コマンドでデプロイと更新ができます。
アクショングループを使用するエージェントを作成する場合、関数定義を JSON オブジェクトとしてエージェントに指定するか、OpenAPI スキーマ形式の API スキーマを提供できます。すでにアプリケーション用の OpenAPI スキーマがある場合は、それを出発点にするのがベストプラクティスです。エージェントが各関数をいつ使うべきかを理解するために、関数には適切な自然言語の説明を付けることが重要です。既存のスキーマがない場合、エージェントにツールのメタデータを提供する最も簡単な方法は、シンプルな JSON 関数定義を使うことです。いずれの場合も、Amazon Bedrock コンソールを使って、アクションやツールの実装を始めるためのデフォルトの AWS Lambda 関数を素早く作成できます。
エージェントの開発を拡大し始めると、エージェントのコンポーネントの再利用性を検討する必要があります。IaC を使用すると、Amazon Bedrock Guardrails を使用して事前に定義されたガードレール、Amazon Bedrock Knowledge Bases を使用したナレッジベース、複数のエージェントで再利用可能なアクショングループを作成できます。
タスクを実行するエージェントを構築するには、関数定義と Lambda 関数が必要です。このコードの開発とメンテナンスを加速するためのもう 1 つのベストプラクティスは、生成 AI を活用することです。これは、Amazon Bedrock の invoke model 機能を直接使用するか、Amazon Q Developer のサポートを利用するか、あるいはアクショングループのメタデータに基づいて Lambda 関数のフレームワークを作成する AWS PartyRock アプリケーションを作成することで実現できます。生成 AI を使用して、関数定義と Lambda 接続を使用したエージェントを作成するために必要な IaC を直接生成できます。選択したアプローチに関わらず、IaC を検証して実行するテストパイプラインを作成することで、エージェントソリューションを最適化するのに役立ちます。
エージェントの追加コンテキストに SessionState を利用
SessionState を使用して、エージェントに追加のコンテキストを提供することができます。SessionAttribute
を使用してアクショングループ内の Lambda 関数でのみ利用可能な情報を渡し、SessionPromptAttribute
を使用してプロンプトで利用可能にすべき情報を渡すことができます。例えば、アクションで使用するユーザー認証トークンを渡したい場合は、SessionAttribute
に設定するのが最適です。一方、大規模言語モデル (LLM) が推論時に必要とする情報として、現在の日付やタイムスタンプなどを渡したい場合は、SessionPromptAttribute
に設定するのが最適です。これにより、エージェントは基盤となる LLM モデルの推論機能を使って、次の支払い期日までの日数や注文からの経過時間などを推測できるようになります。
コストとパフォーマンスのためのモデル選択の最適化
エージェントを構築するプロセスの重要な部分は、エージェント (または各サブエージェント) の基盤となる FM を選択することです。コスト、レイテンシー、精度の要件に基づいて、利用可能な FM を試し、アプリケーションに最適なものを選択してください。評価指標を収集するための自動化されたテストパイプラインを実装することで、データに基づいたモデル選択の意思決定が可能となります。このアプローチにより、シンプルなエージェントには Amazon Bedrock 上の Anthropic の Claude 3 Haiku のような高速で低コストのモデルを使用し、より複雑なアプリケーションには Anthropic の Claude 3.5 Sonnet や Anthropic の Claude 3 Opus のような高度なモデルを使用できます。
堅牢なテストフレームワークの実装
エージェントまたは生成 AI システムの評価を自動化すると、開発プロセスを加速し、お客様によりよいソリューションを提供できるようになります。エージェントのコスト、レイテンシー、精度など、複数の側面で評価を行いましょう。Agent Evaluation のようなフレームワークを使用して、事前に定義された基準に対するエージェントの動作を評価してください。Amazon Bedrock のエージェントバージョニングとエイリアス機能を使用すると、デプロイの段階で A/B テストを実行できます。フォーマルまたはインフォーマルな HR アシスタントの口調など、エージェントの動作の異なる側面を定義し、ユーザーグループの一部でテストすることができます。その後、初期デプロイ時に各グループで異なるエージェントバージョンを利用可能にし、各グループのエージェントの動作を評価できます。Amazon Bedrock Agents には、このテストの重要な部分を支援するためのバージョニング機能が組み込まれています。次の図は、テストと評価のフェーズの後に HR エージェントが更新され、モデル呼び出し用に選択されたエージェントバージョンを指す、新しいエイリアスが作成される方法を示しています。
テストケース生成への LLM の活用
エージェントの期待するユースケースにおけるテストケースを生成するために 、LLM を活用できます。ベストプラクティスとして、テストデータを生成する LLM は、エージェントを実行している LLM とは異なるものを選択することをお勧めします。このアプローチにより、包括的なテストスイートの構築が大幅に加速し、潜在的なシナリオを徹底的にカバーできます。例えば、従業員の休暇予約を支援する HR アシスタントエージェントのテストケースを作成するために、次のようなプロンプトを使用できます。
強固な確認とセキュリティメカニズムの設計
エージェントのワークフローにおいて、重要なアクションに対しては強固な確認メカニズムを実装することが重要です。特にデータを変更したり、機密性の高い操作を実行する関数については、ユーザーの確認を求めるよう、エージェントの指示に明確に記述してください。このステップは、 PoC やプロトタイプの段階を超えて、本番環境でエージェントが確実に動作することを検証するのに役立ちます。例えば、次のエージェントへの指示では、データベースを更新する前に、休暇申請アクションを実行するかどうかをユーザーに確認させています。
関数スキーマ定義の requireConfirmation
フィールド、または API スキーマ 定義の x-requireConfirmation
フィールドを使用して、新しいアクションの作成時にAmazon Bedrock Agents の組み込み機能を有効にし、アクショングループ内のアクションを呼び出す前のユーザー確認要求を行うこともできます。
柔軟な認証と暗号化の実装
エージェントのリソースを暗号化するには、カスタマーマネージドキーを提供する必要があります。また、AWS Identity and Access Management (IAM) の権限が最小特権の原則に従っていることを確認し、エージェントが必要なリソースとアクションにのみアクセスできるように制限してください。アクショングループを実装する際は、sessionState
の sessionAttributes
パラメータを活用して、ユーザーの役割と権限に関する情報を提供し、アクションが細かい権限制御を実装できるようにします (サンプルコードを参照)。もう 1 つのベストプラクティスは、sessionState
の knowledgeBaseConfigurations
パラメータを使用して、ナレッジベースに追加の設定を提供することです。それは例えば、ナレッジベースのメタデータフィルタリングを通じて、ユーザーがアクセスできるドキュメントを定義するユーザーグループなどです。
責任ある AI の実践の統合
生成 AI アプリケーションを開発する際は、倫理的で透明性が高く、説明責任のある方法でシステムを構築するために、責任ある AI の実践を適用する必要があります。Amazon Bedrock の機能は、責任ある AI の実践をスケーラブルな方式で開発するのに役立ちます。エージェントを作成する際は、Amazon Bedrock Guardrails を実装して、機密情報を避け、ユーザー入力とエージェント出力から有害なコンテンツをフィルタリングし、ユーザープライバシーを保護するために機密情報を編集する必要があります。複数の生成 AI アプリケーションで再利用できる組織レベルのガードレールを作成することで、一貫した責任ある AI の実践を維持できます。ガードレールを作成したら、Amazon Bedrock Agents の組み込みガードレール統合(サンプルコードを参照) を使用してエージェントに関連付けることができます。
再利用可能なアクションカタログの構築と段階的な拡張
最初のエージェントのデプロイが成功した後、アクショングループ、ナレッジベース、ガードレールなどの共通機能を他のアプリケーションで再利用する計画を立てることができます。Amazon Bedrock Agents は、AWS Management Console を使った手動でのエージェント作成、エージェント API で利用可能な SDK を使用したコーディング、CloudFormation テンプレート、AWS CDK、または Terraform テンプレートを使った IaC での作成をサポートしています。機能を再利用するためのベストプラクティスは、IaC を使ってそれらを作成およびデプロイし、コンポーネントをアプリケーション間で再利用することです。次の図は、HR アシスタントと銀行アシスタントの 2 つのエージェント間で、ユーティリティアクショングループを再利用する例を示しています。
クロール・ウォーク・ランでエージェントの利用を拡大
最後に強調したいベストプラクティスは、クロール・ウォーク・ランの方法論に従うことです。まず内部アプリケーションから始め (クロール)、次に小規模で制御された外部ユーザー向けにアプリケーションを展開し (ウォーク)、最終的にはすべての顧客向けにアプリケーションを拡大 (ラン) し、マルチエージェントコラボレーションを活用します。このアプローチは、ミッションクリティカルなビジネス運用をサポートする信頼性の高いエージェントを構築しつつ、新しいテクノロジーの導入に伴うリスクを最小限に抑えることができます。このプロセスを以下に示します。
結論
これらのアーキテクチャと開発ライフサイクルのベストプラクティスに従うことで、ユーザーに効果的にサービスを提供し、既存のシステムとシームレスに統合できる、堅牢で拡張性が高く、セキュアなエージェントを作成する準備が整います。
具体的な始め方として、Amazon Bedrock サンプルリポジトリをチェックしてください。Amazon Bedrock Agents の詳細を学ぶには、Amazon Bedrock ワークショップと、より深く掘り下げたAmazon Bedrock Agents ワークショップを始めてみてください。さらに、AWS re:Invent 2023 からのサービス紹介ビデオもチェックしてください。
著者について
Maira Ladeira Tanke は、AWS の Senior Generative AI Data Scientist です。機械学習の経験を持ち、10 年以上にわたり、さまざまな業界の顧客向けに AI アプリケーションのアーキテクチャ設計と構築を行ってきました。テクニカルリードとして、Amazon Bedrock 上の生成 AI ソリューションを通じて、顧客のビジネス価値の実現を加速させるのを支援しています。プライベートでは、旅行、猫と遊ぶこと、家族と温かい場所で過ごすことを楽しんでいます。
Mark Roy は、AWS のプリンシパル機械学習アーキテクトで、顧客が生成 AI ソリューションを設計・構築するのを支援しています。2023 年初頭から、 Amazon Bedrock のローンチに向けたソリューションアーキテクチャの取組を主導しています。保険、金融、メディア・エンターテインメント、ヘルスケア、公益事業、製造業を支援してきました。AWS 入社前は、25 年以上にわたってアーキテクト、開発者、テクノロジーリーダーを務め、うち 19 年間は金融業界でした。
Navneet Sabbineni は、AWS Bedrock のソフトウェア開発マネージャーです。ソフトウェア開発者およびマネージャーとして 9 年以上の業界経験があり、Amazon Bedrock Agents のような生成 AI サービスや Amazon Lex のような対話 AI サービスなど、AWS のスケーラブルな分散サービスの構築と保守に携わってきました。仕事以外では、家族や友人と一緒に太平洋北西部を旅行したり探索したりするのが好きです。
Monica Sunkara は、AWS の Senior Applied Scientist で、Amazon Bedrock Agents に従事しています。10 年以上の業界経験があり、そのうち 6 年間は AWS で勤務しています。Monica は、Alexa 音声認識、Amazon Transcribe、Amazon Lex ASR などの AI および ML の取り組みに貢献してきました。最近では、Amazon Titan テキストモデルに関数呼び出し機能を追加する作業に携わりました。Monica は、2018 年に Amazon に入社する前、Andrew Gordon Wilson 教授の指導の下、Cornell 大学でオブジェクト検出に関する研究を行い、学位を取得しています。
本連載の第1部は「Amazon Bedrock Agents を使用して堅牢な生成 AI アプリケーションを構築するためのベストプラクティス – Part 1」です。
翻訳は AWS プロフェッショナルサービスの相川遼介が担当しました。原文はこちらです。