Amazon Bedrock Agents を使用して堅牢な生成 AI アプリケーションを構築するためのベストプラクティス – Part 1

本ブログは2024年10月2日に公開された「Best practices for building robust generative AI applications with Amazon Bedrock Agents – Part 1」を翻訳したものです。

ユーザーのクエリを正確に理解して応答できる、インテリジェントなエージェントの構築には、複数ステージにわたる慎重な計画と実行が必要です。カスタマーサービスチャットボットや仮想アシスタントを開発する場合、エージェントの範囲と機能を定義することから、堅牢で拡張性のあるインフラストラクチャを設計することまで、多くの点に留意する必要があります。

この 2 部構成のシリーズでは、Amazon Bedrock Agents を使用して生成 AI アプリケーションを構築するためのベストプラクティスを探ります。エージェントは、マルチステップタスクを調整することで、生成 AI アプリケーション開発を加速するのに役立ちます。また、基盤モデル (FM) の推論能力を利用して、エージェントはユーザーからのリクエストに回答するための複数のタスクに分割します。さらに、開発者が提供した指示を使用して、オーケストレーションプランを作成し、そのプランに従って企業の API を呼び出したり、検索拡張生成 (RAG) を使用してナレッジベースにアクセスしたりして、ユーザーのリクエストに対する回答を提供します。

パート 1 では、正確で信頼できるエージェントの作成に焦点を当てます。パート 2 では、アーキテクチャの考慮事項と開発ライフサイクルの実践について説明します。

基礎の構築: 正解データの収集

優れたエージェントの基盤となるのは、高品質な正解データです。つまり、モデル、アルゴリズム、システムのパフォーマンスを評価するための基準となる、現実世界の正確な観測データです。エージェントアプリケーションを構築する前に、エージェントのライフサイクル全体を推進する一連の正解となる対話や受け答えを収集することが不可欠です。このデータにより、エージェントに接続されている既存の API、ナレッジベース、ガードレールとの対話に対して、エージェントの振る舞いとして期待される基準が得られます。これにより、正確なテストと評価が可能になり、エッジケースや潜在的な問題点を特定するのに役立ちます。

堅牢な正解データセットを構築するには、さまざまなユーザーの意図やシナリオをカバーする多様なシナリオに焦点を当てることが重要です。データセットには、単純な対話と複雑な対話の両方について、入力と期待される出力を含める必要があります。さらに、ユーザーの行動について理解を進めると共に、データセットを定期的に更新、拡張することが重要です。実際のユースケースに沿った顧客との対話に基づいてデータを構築しますが、データの匿名化と非識別化を確実に行ってください。

次の表は、銀行アシスタントエージェントのために収集された正解データの一部を示しています。このエージェントは、check_account_balance と book_appointments の API と連携し、検索拡張生成のナレッジベースとして bankingFAQ を使用し、ガードレール BlockInvestmentAdvice に接続されています。この例では、エージェントをテストするために使用されたクエリのごく一部のみを示しています。これには、他のシステムから使用されたセッション情報で、sessionAttributes を使ってエージェントに渡されたものが含まれます。また、プロダクションシステムでエージェントに共有される追加情報を収集することも、ベストプラクティスです。これには、アクショングループ実行関数にのみ共有されるセッション属性、プロンプトを補強するために使用される情報 (プロンプトセッション属性)、およびナレッジベースで使用される情報 (ナレッジベース構成) が含まれます。

スコープと対話サンプルの定義

正解データを用意できたので、次は各エージェントのスコープを明確に定義します。これには、エージェントが処理すべきタスクと処理すべきでないタスクを含め、想定されるユーザーとのやり取りの具体例が含まれます。このプロセスでは、主要な機能と能力、制限事項と範囲外のタスク、想定される入力形式と種類、そして出力形式とスタイルを特定します。

例えば、HR アシスタントエージェントを検討する場合、以下のようなスコープが考えられます。

主要機能：

– 会社のHR方針に関する情報提供
– 休暇申請と休暇管理の支援
– 基本的な給与に関する質問への回答

スコープ外：

– 機密性の高い従業員データの取り扱い
– 採用や解雇の決定
– 法的アドバイスの提供

想定される入力：

– HR方針に関する自然言語での質問
– 休暇や休暇情報に関する要求
– 基本的な給与に関する問い合わせ

期待される出力：

– 方針に関する質問への明確で簡潔な回答
– 休暇申請のための順序に沿ったガイダンス
– 新しい休暇申請、過去の申請情報の取得、編集、削除タスクの完了
– 複雑な問題に対する適切なHR担当者への紹介
– エージェントが対応できない質問に対するHRチケットの作成

エージェントの範囲を明確に定義することで、境界線と期待値を明確にし、開発プロセスを円滑にし、焦点を絞った信頼できる AI エージェントの開発につながります。

ソリューションのアーキテクチャ設計: 相互に作用する小規模で集中したエージェントの構築

エージェントのアーキテクチャに関しては、「分割統治（divide and conquer）」の原則が当てはまります。私たちの経験では、単一の大規模なモノリシックエージェントを構築するよりも、相互に作用する小さな専門的なエージェントを構築する方が効果的であることが証明されています。このアプローチは、モジュール性とメンテナンス性の向上、簡単なテストとデバッグ、特定のタスクに異なる基盤モデルを使用する柔軟性、スケーラビリティと拡張性の強化をもたらします。

例えば、組織内の従業員をサポートする HR アシスタントと、給与チームの従業員をサポートする給与チームアシスタントを考えてみましょう。両方のエージェントには、給与ポリシーに関する質問に答えたり、従業員間の会議をスケジューリングするなどの共通機能があります。機能は似ていますが、スコープと権限は異なります。たとえば、HR アシスタントは社内で利用可能な知識に基づいて質問に回答できますが、給与エージェントは給与従業員のみが利用できる機密情報も処理できます。さらに、HR エージェントは従業員と割り当てられた HR 担当者との間で会議をスケジューリングできますが、給与エージェントは給与チーム内の従業員間の会議をスケジューリングします。単一エージェントアプローチでは、これらの機能がエージェント自体で処理されるため、次の図に示すように、各エージェントで利用可能なアクショングループが重複します。

この例では、ミーティングアクショングループ（ Action Group: handle meetings ）に変更があった場合、その変更を各エージェントに伝播させる必要があります。

ここで、マルチエージェントコラボレーションのベストプラクティスを適用すると、 HR と給与チームのエージェントは、それぞれの範囲に特化した小さなタスク指向のエージェントをオーケストレーションします。そして、それぞれのエージェントは独自の指示を持ちます。そのような場合、ミーティングアクショングループは次の図に示すように、2 つのエージェントで再利用される単独のエージェントによって処理されるようになります。

ミーティングアシスタントエージェントに新機能が追加された場合、 HR エージェントと給与チームエージェントはその機能を処理できるように更新する必要があるだけです。このアプローチはアプリケーションでも自動化でき、エージェントソリューションのスケーラビリティを高めることができます。スーパーバイザーエージェント ( HR エージェントと給与チームエージェント) は、アプリケーションのトーンを設定し、エージェントの各機能 (ナレッジベースまたはサブエージェント) の使用方法を定義することができます。これには、エージェントアプリケーションの一部として、ナレッジベースフィルターとパラメーター制約の実施が含まれます。

ユーザー体験の作り込み: エージェントのトーンの計画

エージェントの個性は、ユーザーとの対話全体の雰囲気を左右します。エージェントの口調を慎重に計画することが、一貫性のあり魅力的なユーザー体験を作り出すために重要です。ブランドの声とパーソナリティ、ターゲット層の好み、フォーマリティのレベル、文化的な配慮など、さまざまな要因を考慮する必要があります。 例えば、フォーマルな HR アシスタントの場合は、敬称と名字を使用してユーザーに丁寧に話しかけ、会話全体を通して専門的で礼儀正しいトーンを維持するよう指示されるかもしれません。一方で、フレンドリーな IT サポートエージェントの場合は、下の名前でユーザーに話しかけ、適切な絵文字やテクノロジー関連のジョークを交えながら、カジュアルで明るいトーンを使用して、会話を軽快で魅力的にするかもしれません。

以下は、フォーマルな HR アシスタントのプロンプト例です。

あなたは人事AIアシスタントです。
従業員が会社の方針を理解し、福利厚生を管理するのを支援します。
常にユーザーに対して敬称（様など）と苗字を使用し、フォーマルに対応してください。
会話全体を通して、プロフェッショナルで丁寧な態度を維持してください。

以下は、フレンドリーな IT サポートエージェントへのプロンプト例です。

あなたはITバディです。技術的な問題の解決をサポートします。
カジュアルで明るい話し方を使い、ユーザーのファーストネームで呼びかけてください。
会話を軽快で楽しいものにするために、適切な絵文字やIT関連のジョークを自由に使ってください。

エージェントのトーンがブランドアイデンティティと一致し、さまざまな対話で一貫していることを確認してください。複数のエージェントでコラボレーションする場合は、アプリケーション全体でトーンを設定し、サブエージェントに対しても強制するとよいでしょう。

明確さの維持: 明確な指示と定義の提供

明確なコミュニケーションは、効果的な AI エージェントの礎となります。指示、関数、ナレッジベースとの対話を定義する際は、誤解を招かない明確な言葉遣いを心がけてください。複雑な概念については、簡潔で直接的な言葉を使い、具体例を示してください。類似した機能の間に明確な境界線を設け、重要なアクションには確認のメカニズムを実装してください。次の例は、明確な指示と曖昧な指示の違いを示しています。

以下は曖昧なプロンプト例です。

ユーザーに利用可能な休暇があるかどうかを確認し、可能であれば予約してください。

以下は明確なプロンプト例です。

1. ユーザーの利用可能な休暇残高を確認するために、`checkTimeOffBalance` 関数を使用します。
2. 要求された休暇が利用可能な場合、`bookTimeOff` 関数を使用して予約します。
3. 休暇が利用できない場合は、ユーザーに通知し、代替日を提案します。
4. 休暇の予約を確定する前に、必ずユーザーに確認を取ります。

明確な指示を与えることで、エラーの可能性を減らし、エージェントが予測可能で信頼できる動作をするようになります。

アクショングループの関数を定義する際も同じアドバイスが当てはまります。曖昧な関数名や定義は避け、パラメータの説明を明確にしてください。次の図は、関数が実際に返す内容とユーザー ID の予想される値のフォーマットに基づいて、ユーザーの詳細情報を取得する 2 つの関数の名前、説明、パラメータを変更する方法を示しています。

最後に、ナレッジベースの説明には、ナレッジベースに何が含まれているか、ユーザーのクエリに答えるためにいつ使用するべきかを明確に記載する必要があります。

以下は曖昧なプロンプト例です。

Knowledge Base 1: このナレッジベースを使用して文書から情報を取得する

以下は明確なプロンプト例です。

Knowledge Base 1: 保険契約と内部文書を含むナレッジベース。
ユーザーが契約条件や内部システムについて質問した場合、このナレッジベースを使用してください

組織の知識活用: ナレッジベースの統合

エージェントに企業の知識を提供できるよう、組織の既存のナレッジベースと統合することが重要です。これにより、エージェントは膨大な情報を活用し、より正確で状況に応じた応答を提供できるようになります。最新の組織データにアクセスすることで、エージェントは応答の正確性と関連性を高め、信頼できるソースを引用し、頻繁なモデル更新の必要性を減らすことができます。

Amazon Bedrock と知識ベースを統合する際は、次の手順を実行してください。

1. Amazon Bedrock Knowledge Bases を使って、ドキュメントに対してベクトルデータベースのインデックスを作成します。
2. エージェントが対話中にナレッジベースにアクセスできるように設定します。
3. レスポンスで参照元のドキュメントを引用するメカニズムを実装します。

ナレッジベースを定期的に更新し、エージェントが最新の情報に一貫してアクセスできるようにしましょう。これは、StartIngestionJob API と Amazon EventBridge ルール を使用して、定期的、あるいはナレッジベースの Amazon Simple Storage Service (Amazon S3) バケット内のファイル更新で呼び出されるイベントベースの同期を実装することで達成できます。

Amazon Bedrock Knowledge Base をエージェントに統合すると、アプリケーションにセマンティック検索機能を追加できます。InvokeAgent リクエスト時に、エージェントの SessionState の knowledgeBaseConfigurations フィールドを設定することで、必要な結果数やフィルタを指定し、エージェントがナレッジベースとどのように対話するかを制御できます。

成功の定義: 評価基準の設定

AI エージェントの効果を測定するには、具体的な評価基準を定義することが不可欠です。これらの指標を使用すると、パフォーマンスを評価し、改善が必要な領域を特定し、時間の経過に伴う進捗状況を追跡できます。

次の主要な評価指標を検討してください。

• 応答の正確性 – あなたの応答が基準データとどの程度一致しているかを測定します。応答が正しいかどうか、エージェントのパフォーマンスと品質が良好かどうかなどの情報を提供します。
• タスク完了率 – エージェントの成功率を測定します。この指標の基本的な考え方は、エージェントが要求されたタスクを問題なく完了し、ユーザーの意図を満たすことができた会話やユーザー インタラクションの割合または比率を測定することです。
• レイテンシーまたは応答時間 – タスクの実行にかかった時間と応答時間を測定します。入力やクエリを受け取ってから、エージェントが応答または出力を提供するまでの時間を測定します。また、システムで最適化が必要なステップを特定するために、各ステップの実行時間を中間的な指標として採用するのもよいでしょう。
• 会話の効率性 – 会話が必要な情報を効率的に収集できたかどうかを測定します。
• エンゲージメント – エージェントがユーザーの意図を理解し、関連性があり自然な応答を提供し、双方向の会話の流れを維持できるかどうかを測定します。
• 会話の一貫性 – 応答間の論理的な進行と連続性を測定します。セッション中のコンテキストと関連性が維持されているか、適切な代名詞と参照が使用されているかをチェックします。

さらに、エージェントがあなたのユースケースのタスクをどの程度満たしているかを判断する、ユースケース固有の評価指標を定義する必要があります。例えば、HR のユースケースでは、カスタム指標として、作成されたチケット数を指標にすることができます。エージェントが質問に自力で答えられない場合、チケットが作成されるためです。

堅牢な評価プロセスを実装するには、以下が必要です。

• 正解データに基づいて包括的なテストデータセットを作成
• 定量的な指標を測定するための自動評価スクリプトを開発
• 異なるエージェントのバージョンや構成を比較するための A/B テストを実装
• 定性的な要因の人的評価を定期的に実施

評価は継続的なプロセスです。エージェントのパフォーマンスとユーザーニーズについて、より多くのことが明確になることに合わせて、評価基準と測定方法を継続的に改善していきましょう。

人間による評価の利用

自動化された指標は価値がありますが、人間による評価は AI エージェントのパフォーマンスを評価し改善する上で重要な役割を果たします。人間の評価者は、自然言語の理解と生成の評価、コンテキストに応じた応答の適切性の評価、潜在的なバイアスや倫理的懸念の特定、ユーザーエクスペリエンスと満足度への洞察など、自動化では定量化が難しい側面について、ニュアンスのあるフィードバックを提供できます。

人間による評価を効果的に活用するには、以下のベストプラクティスを検討してください。

• 異なる視点からの多様な評価観点を作成する
• 明確な評価ガイドラインと評価基準を作成する
• 専門性の高い評価者 (業界有識者など) と、代表的なエンドユーザーの組み合わせを使用する
• 定量的な評価と定性的なフィードバックを収集する
• トレンドと改善の余地を特定するために、定期的に評価結果を分析する

継続的改善: テスト、反復、改良

効果的な AI エージェントを構築するには反復的なプロセスが必要です。動作するプロトタイプができたので、徹底的なテストを行い、フィードバックを収集し、エージェントの性能を継続的に改善することが重要です。このプロセスには、正解データセットを使用した包括的なテスト、ベータグループを使用した実環境でのユーザーテスト、エージェントのログと会話トレースの分析、指示、関数定義、プロンプトの定期的な更新、様々な基盤モデルにおける性能比較が含まれます。

徹底的なテストを行うには、AI を使用して多様なテストケースを生成することを検討しましょう。以下は、HR アシスタントのテストシナリオを生成するためのプロンプト例です。

従業員とHR AIアシスタントの間の10の多様な会話シナリオを生成してください。
一般的な要求（例：休暇予約、規約に関する質問）とエッジケース（例：複雑な状況、範囲外の質問）を組み合わせて含めてください。
各シナリオについて、以下を提供してください：
1. 初期ユーザークエリ
2. 期待されるエージェントの応答
3. 潜在的なフォローアップ質問
4. 望ましい最終結果

テストフェーズの最高のツールの 1 つは、 エージェントトレース ( agent trace ) です。トレースにより、エージェントのオーケストレーション中に実行された各ステップでエージェントが使用したプロンプトが提供されます。エージェントの思考の連鎖 ( Chain of thought ) とリーズニングプロセスの洞察が得られます。テストプロセス中の InvokeAgent 呼び出しでトレースを有効にし、エージェントが検証された後に無効にすることができます。

正解データセットを収集した次のステップは、エージェントの動作を評価することです。まず、エージェントの動作を評価するための基準を定義する必要があります。HR アシスタントの例では、エージェントが提供した結果と、休暇データベースを直接クエリした結果を比較するテストデータセットを作成できます。その後、人間による評価を使用してエージェントの動作を手動で評価するか、Agent Evaluation などのエージェント評価フレームワークを使用して評価を自動化できます。モデル呼び出しログが有効になっている場合、Amazon Bedrock Agents は Amazon CloudWatch のログも提供します。これらのログを使用して、エージェントの動作を検証し、予期しない出力をデバッグし、エージェントを適宜調整できます。

エージェントのテスト段階の最後のステップは、デプロイ段階で A/B テストグループを計画することです。フォーマルな HR アシスタントのトーンや非フォーマルなトーンなど、ユーザーグループの一部で検証できるエージェントの振る舞いの異なる側面を定義する必要があります。その後、初期デプロイ時に各グループに異なるエージェントバージョンを提供し、各グループのエージェントの振る舞いを評価できます。Amazon Bedrock Agents には、このテストの重要な部分を支援するための バージョニング機能 ( AgentVersion API ) が組み込まれています。

結論

これらのベストプラクティスに従い、継続的にアプローチを改善することで、Amazon Bedrock を使用して強力で正確かつユーザー指向の AI エージェントを開発することに大きく貢献できます。このシリーズの第 2 部では、アーキテクチャの考慮事項、セキュリティのベストプラクティス、および本番環境での AI エージェントのスケーリング戦略について探ります。

これらのベストプラクティスに従うことで、Amazon Bedrock を使用して、セキュリティ、正確性、スケーラビリティ、責任ある生成 AI アプリケーションを構築できます。はじめるための例については、Amazon Bedrock Agents GitHub リポジトリをご覧ください。 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 年初頭以降、AWS の主力生成 AI 製品である 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 年にアマゾンに入社する前、Andrew Gordon Wilson 教授の指導の下、Cornell 大学でオブジェクト検出に関する研究を行い、学位を取得しています。

本連載の第2部は「Amazon Bedrock Agents を使用して堅牢な生成 AI アプリケーションを構築するためのベストプラクティス – Part 2」です。

翻訳はプロフェッショナルサービスの相川遼介が担当しました。原文はこちらです。