AWS の技術ブログ

全3894件

2023/10/23

Amazon BedrockとAmazon CloudWatchの統合による生成系AIアプリケーションのモニタリング

Amazon Bedrock は、基盤モデル (FM) を使用して生成系AI アプリケーションを構築およびスケーリングする簡単な方法です。フルマネージドサービスとして、AI21 Labs、Anthropic、Cohere、Meta、Stabability AI、Amazon などの主要な AI 企業が提供する高性能な FM を選択できます。また、生成系 AI アプリケーションの構築に必要な幅広い機能も備えているため、プライバシーとセキュリティを維持しながら開発を簡略化できます。 BedrockはAmazon CloudWatchと統合されているため、使用状況のメトリクスを追跡し、監査目的でカスタマイズされたダッシュボードを構築できます。これらのメトリックスを使用して、単一アカウントの 1 つのファンデーションモデルから、複数のアカウントにわたるすべての基盤モデルへのモデル呼び出しやトークン数などの使用状況を把握できます。また、Bedrockではmodel invocation loggingと呼ばれる、アカウント内のすべてのモデル呼び出しのメタデータ、リクエスト、レスポンスを収集できる機能を顧客に提供しています。デフォルトではこれらの機能は無効になっているため、model invication loggingを開始するにはユーザが有効にする必要があります。このブログ記事では、CloudWatch を使用して Bedrock をほぼリアルタイムで監視する方法について詳しく説明します。メトリクスとログを使用して、値が事前定義されたしきい値を超えたときにアラームをトリガーしたり、アクションを実行したりできます。CloudWatch には、クロスアカウントでのオブザーバビリティ、ログとメトリクスの相関関係、複合アラーム、ログ分析、アプリケーションパフォーマンスモニタリングなど、他にも活用できる豊富な機能が備わっています。 Model Invocation Loggingの設定 Model Invocation Loggingは現在プレビュー段階であるため、この機能に変更が加えられる可能性があることに注意してください。ロギングを有効にすると、アカウント内のすべてのモデル呼び出しのメタデータ、リクエスト、レスポンスが収集されます。ロギングを設定するには、左側のナビゲーションバーからBedrockコンソールの設定ページに移動します。次に、Model Invocation loggingボタンを切り替えます。ロギングを有効にする前に入力する必要のあるフィールドがいくつか表示されます。図 1: ログ (テキスト、画像、埋め込み) に含めるデータタイプの複数選択制御次に、ロギング先を選択します。オプションは3つあります。1 つ目のオプションは S3 only で、選択した S3 バケットにのみログを送信するように Bedrock を設定します。2 つ目のオプションは CloudWatch Logs only で、ログを CloudWatch に送信し、モデルの入出力データが 100 KBを超える場合、またはバイナリ形式の場合は、オプションで S3 に送信できます。最後のオプションは S3 と CloudWatch のログの両方で、ログは S3 と CloudWatch の両方に送信され、モデルの入出力データのどちらかが 100 KB を超える場合やバイナリ形式のデータの場合は S3 にのみ送信されます。どのオプションを選択しても、KMS による暗号化や保存期間など、モデルの入力と出力を制御できます。このブログの場合は、 CloudWatch Logs のみのオプションを選択しました。 CloudWatch ログ設定セクションで、ロググループ名を指定します (この場合は /aws/bedrock を選択しました)。最初にこのロググループを CloudWatch で作成する必要があることに注意してください。次に、 Create and use a new role オプションを選択し、ロールの名前を指定します。今回は BedrockCloudWatchLogs を選びました。最後に S3 に移動して S3 バケットを作成します。私の場合は、バケット名に bedrock-logging-[ACCOUNTID]-[REGION] という形式を選択しました。次に BedrockのSettingsメニューに戻り、”S3 location for large data delivery“ フィールドで新しく作成したバケットを選択し、「設定を保存」をクリックして設定を完了します。 Bedrock からのログデータの生成 Bedrockでのロギングの設定が完了したので、AWSコンソールからBedrockのモデルを試せるプレイグラウンドを使用してログデータを生成してみましょう。 Bedrockのチャットプレイグラウンドに移動し、モデルを選択してプロンプトを表示します。このケースでは、Amazon CloudWatch の概要について簡単に説明してもらうようお願いしています。図 2: BedrockのChat プレイグラウンド。Claude Instant V1.2 モデルを選択し、Amazon CloudWatch の概要を簡単に説明させている Logs Insights からロググループにクエリを実行すると、ほぼリアルタイムで新しく作成されたロググループのログが表示されるようになります。図 3: CloudWatch ログインサイトクエリ。Bedrock のModel Invocation Logging用に新しく作成されたロググループからのログイベントを示しているモデル呼び出しログが配信されたら、CloudWatch の 2 つの機能を使用してログを調べることができます。1 つは Live Tail で、もう 1 つは Log Insights です。 Live Tail を使用したストリーミングログ CloudWatch Logs の Live Tail は、ログが取り込まれるとほぼリアルタイムでインタラクティブに表示できる、インタラクティブなログ分析エクスペリエンスを提供する機能です。Live Tail は、受信したログの問題をすぐに確認して検出できる豊富なエクスペリエンスを顧客に提供します。さらに、問題のトラブルシューティング中に、フィルタリング、関心のある属性の強調表示、ログの一時停止/再生をきめ細かく制御できます。図 4: CloudWatch LogsのLive TailBedrock。Chat Playground によって生成された Bedrock モデル呼び出しログからのログイベントを表示する Log Insightsによるログ分析 CloudWatch Log Insightsを使用すると、CloudWatch ログのログデータをインタラクティブに検索して分析できます。クエリを実行することで、運用上の問題により効率的かつ効果的に対応できます。 Bedrockの場合、Log Insightsを使用してモデル呼び出しログを検索および分析し、特定のキーワードまたは単に最新の呼び出しログを検索できます。コマンドの全リストは、こちらでご覧いただけます。図 5: Log Insights クエリ。ModelID、操作、入出力トークンの数、プロンプトを含む最新のログイベントを 100 件表示している Log Insightsは最近、MLベースのパターンクエリコマンドも導入しました。これにより、顧客はログの傾向やパターンをより簡単に識別できます。パターンコマンドは AWS Machine Learning アルゴリズムを使用して、ログデータ内のパターンを自動的に認識し、関連するログを集約し、数千のログ行を視覚化しやすいグループにまとめます。以下の例では、この新しいパターンコマンドをモデル呼び出しログのプロンプトフィールドに使用して、Bedrockへのプロンプトのパターンを認識しています。図 6: 1時間にわたるLog Insightクエリ。pattern コマンドを使用してプロンプトテキストを要約している。機械学習によるCloudWatch ログのデータ保護 CloudWatch には、パターンマッチングと機械学習 (ML) を活用して転送中の機密データを検出して保護する一連の機能もあります。まず、ロググループのデータ保護ポリシーを有効にします。ポリシーを作成するときは、保護するデータを指定します。その際、100 を超えるマネージドなData identifiers (下図) から選択できます。図 7: データ保護ロググループポリシーの設定上の例では、ロググループ内の IP アドレスを検索するようにデータ保護ポリシーを設定しました。Bedrockに「192.168.0.1とは」と尋ねると、モデルの入出力ログイベントで検出されたIPアドレスをマスクします。図 8: プロンプトフィールドで IP アドレスをマスクした JSON での単一モデル呼び出しのログイベント Bedrock ランタイムメトリクス BedrockはほぼリアルタイムのメトリクスをCloudWatchに送信します。これを使用して、特定のしきい値を監視するアラームを設定し、値がそのしきい値を超えたときに通知を送信したり、アクションを実行したりできます。また、 CloudWatch でメトリクスの異常検出を有効にすることもできます。これにより、統計アルゴリズムと機械学習アルゴリズムを適用して、メトリクスを継続的に分析し、通常のベースラインを決定し、最小限のユーザー操作で異常を検知します。図 9: CloudWatch の Anthropic Claude v1 メトリックと Anthropic Claude v2 メトリクスを含む積み上げ型面グラフで 15 分間の呼び出し数を示すビジュアライゼーション。 Bedrockが提供するランタイムメトリクスを以下に示します。こちらでも確認できます。メトリクス名単位説明 Invocations SampleCount InvokeModelもしくはInvokeModelWithResponseStreamのAPI操作によるリクエストの数 InvocationLatency MilliSeconds モデル実行のレイテンシー InvocationClientErrors SampleCount クライアントサイドのエラーに至ったモデル実行の数 InvocationServerErrors SampleCount サーバサイドのエラーに至ったモデル実行の数 InvocationThrottles SampleCount システムがスロットリングしたモデル実行の数 InputTokenCount SampleCount 入力テキストのトークン数 OutputTokenCount SampleCount 出力テキストのトークン数 ContentFilteredCount SampleCount 出力テキストコンテントがフィルターされた数 OutputImageCount SampleCount 出力画像の数これらの指標は、次のようなさまざまなユースケースに使用できます。 InvocationLatency メトリクスと ModelID ディメンションを使用して、異なるモデル間のレイテンシーを比較します。 InputTokenCount と OutputTokenCount を分析してトークン数 (入力と出力) を測定し、プロビジョニングされたスループットの購入に役立てます InvocationThrottles メトリクスを使ってスロットリングを検出し、 CloudWatch アラームによってアラートを発信します表示をシンプルにするために、BedrockがCloudWatchに送信するログとメトリクスは、CloudWatchダッシュボードを使用して単一のビューとして表示できます。複数の AWS アカウントをお持ちの場合は、CloudWatch のクロスアカウントオブザーバビリティを設定して、モニタリングアカウントに豊富なクロスアカウントダッシュボードを作成できます。図 10: CloudWatch Dashboard には、モデル別の呼び出し数、モデル別の呼び出しレイテンシー、入出力別のトークン数、モデル呼び出しログからの最新のプロンプトが表示されます。上のダッシュボードには、以下の情報が表示されています。モデル別の呼び出し回数の推移モデル別の呼び出しレイテンシー入力トークンと出力トークン別のトークン数モデル、操作、入出力トークンの数を示す呼び出しログの最新のプロンプト結論このブログでは、CloudWatch で Bedrock を監視し、基盤モデルと生成系 AI アプリケーションの使用状況に関する洞察を得る方法を示しました。Bedrock は、主要な AI プロバイダーの基盤モデルを使用して、生成系 AI アプリケーションの開発とスケーリングを簡単に行えるフルマネージド型サービスです。CloudWatch と統合して、メトリクスとログによるほぼリアルタイムの監視、監査、使用状況分析機能を提供します。Bedrock は CloudWatch との統合により透明性と制御を実現しつつ、大規模な生成系AI アプリケーションの構築を簡素化します。原文はこちらをご覧くださいこのブログ記事は機械学習ソリューションアーキテクトの卜部が翻訳しました。

AWS の技術ブログ

コンテンツ