こんにちは、セキュリティエンジニアの田所です。
現地参加した AWS Summit Japan のセッションの模様をお届けします。

セッションについて

AWS-49 生成 AI オブザーバビリティのベストプラクティス

生成 AI の採用が進む中、信頼性、透明性、最適化を確保するための包括的な可観測性が重要になっています。このセッションでは、大規模言語モデル、Retrieval Augmented Generation（RAG）アーキテクチャ、その他の新しいアプローチを含む、さまざまな生成 AI パターンの可観測性の課題について学びます。Amazon CloudWatch を幅広いメトリクス、ログ、分散トレーシングと共に使用して、生成 AI ワークロードのライフサイクルの可視性を獲得する方法を発見します。さらに、生成 AI アプリケーションを構築するための強力なフレームワークである LangChain の役割と、Amazon Bedrock や Amazon SageMaker と組み合わせて開発およびデプロイメントパイプライン全体の可観測性を向上させる方法についても探ります。

生成 AI の普及に伴って、そのセキュリティは担保されるか、意図した通りに働いているか、運用面での異常はないか、など副次的な課題が生じます。
今回は生成 AI の運用状態をいかに把握するか、つまりオブザーバビリティについて、
どのような切り口で考え、どのように AWS で実装できるか見ていきます。

 

生成 AI オブザーバビリティのレイヤー

生成 AI の運用において、高品質、高パフォオーマンス、低コストの両立が望まれます。
今回はパフォーマンスと品質（一部）を把握、コントロールする方法について見ていきます。

例えばこのような生成 AI アプリケーションの状態をどのように把握したらよいのでしょうか。

生成 AI のオブザーバビリティは大きく以下の4レイヤーに分けて考えられると言います。

  • レイヤー1：コンポーネントレベルのメトリクス
  • レイヤー2：各コンポーネントでの処理のチェーントレース
  • レイヤー3：生成 AI 特有の高度な指標
  • レイヤー4：エンドユーザーからのフィードバック

そして AWS のオブザーバビリティツールである Amazon CloudWatch が全てのレイヤーの情報把握に役立ちます。
インフラ、アプリ、ユーザー体験の監視から可視化、分析まで、オブザーバビリティのための機能を幅広く備えています。

 

レイヤー1：コンポーネントレベルのメトリクス

まずは最も基本的なオブザーバビリティのレイヤーであるコンポーネントのメトリクスです。
AWS には EC2 の CPU 使用率に始まり、マネージドサービスにおいても多数のメトリクスを提供しています。

例えば Amazon Bedrock では、呼び出し数、呼び出しのレイテンシー、ガードレールの介入数、エージェントの入出力トークン数など、
多くのメトリクスがネイティブにサポートされています。

またメトリクスではなくログですが、Amazon Bedrock ではモデル呼び出しに関するログを CloudWatch Logs や S3 に記録することができます。

CloudWatch Logs Insights でログパターンを分析すれば、ログ量が大規模になってきても簡単に傾向分析ができます。

サービス単位のメトリクスやログは AWS サービスを利用することで容易に取得、分析することが分かりました。

 

レイヤー2：処理のチェーントレース

次のレイヤーは処理の一連です。
処理をコンポーネントから別のコンポーネントに引き渡す時に、ID を保持したり付与したりすることで、
各々の処理時間（スパン）と全体の処理時間（トレース）を把握することができます。

アプリケーションコードにおいては、トレースやスパン情報をセットする記述を加えて実装します。

生成 AI アプリケーションではどのようにトレースを取得すればよいのでしょうか。

基本的な考え方は同じで、コードに組み込んで情報を取得します。
Streamlit + LangChain のような大規模言語モデルを扱うためのフレームワークを使用する場合、
OpenTelemetry に加えて、LLM アプリケーションに特化した OpenLLMetry や OpenLIT を利用することでトレース取得が容易になります。

トレースのレイヤーでもオブザーバビリティを実装できました。

例えばチャットボットのアプリのどの処理に時間がかかっているかが一目で分かるようになります。

 

レイヤー3：高度な指標

その次はガードレールの介入や埋め込みドリフトなど、生成 AI 特有の指標です。

ここでは Amazon Bedrock Guardrails について説明されていました。
ユーザーからの入力情報や、モデルからの出力情報を評価し、フィルターをかけることができます。
有害なトピックや単語を入力、出力させない、などが代表的な使い方です。

コンソールで必要なガードレールとその強度を設定し、アプリでガードレール ID を指定することにより適用できます。
標準メトリクスとしてガードレールの呼び出し数や介入数を取得でき、どのガードレールでどのくらいフィルターされたかを把握できるようになります。

 

レイヤー4：エンドユーザーからのフィードバック

最後にユーザーからのフィードバックです。
アンケートなどのサービス把握のための別の観点かと思いきや、ユーザーフィードバックをアプリケーションログに出力し、メトリクスに変換することにより、数値化して評価することが可能になります。

CloudWatch Embedded Metrics Format (EMF) を活用することで、Good ボタンの押下のようなユーザーフィードバックの傾向を把握できます。

これで生成 AI オブザーバビリティの4つのレイヤーを網羅できました。

 

まとめ

コンポーネント、トレース、高度な指標、フィードバックの4レイヤーのオブザーバビリティを見てきました。
生成 AI を活用するにあたり、そのオブザーバビリティについてもしっかりキャッチアップしていく必要があると感じました。

おしまい