[アップデート] AWS Well-Architected Framework に Generative AI Lens が登場しました
こんにちは!クラウド事業本部コンサルティング部のたかくに(@takakuni_)です。
AWS Well-Architected Framework に Generative AI Lens が登場しました。
AWS Blog も公開されていますね。
Generative AI Lens
はじめに AWS Well-Architected Framework における Lens は特定の技術領域やドメインに最適化された拡張フレームワークを指します。
今回新たに、生成 AI ワークロードに特化した Generative AI Lens が公開されました。
シンプルにいうと、AWS 上で生成 AI ワークロードを設計するためのベストプラクティス集になります。
AWS Well-Architected Framework で提唱されている 6 つの柱に沿って解説されています。
- 運用上の優秀性
- モデルのパフォーマンス評価
- 運用健全性の監視と管理
- ワークロードの可観測性
- ライフサイクル管理を自動化
- モデルのカスタマイズ
- セキュリティ
- エンドポイントセキュリティ
- 応答の検証
- イベント監視
- 迅速なセキュリティ
- 過剰な代理権限の付与
- データ汚染
- 信頼性
- スループットクォータを管理する
- ネットワークの信頼性
- 迅速な修復および回復措置
- 迅速な管理
- 分散型可用性
- 分散コンピューティングタスク
- パフォーマンス効率
- パフォーマンス評価プロセスを確立する
- モデルのパフォーマンスを維持する
- 高性能コンピューティングを最適化
- ベクトルストア最適化
- コストの最適化
- モデル選択とコスト最適化
- 生成AIの価格モデル
- コストを考慮したプロンプト
- コスト情報に基づくベクトルストア
- コスト情報に精通したエージェント
- 持続可能性
- エネルギー効率の高いインフラとサービス
- 持続可能なデータ処理およびストレージサービスを利用する
- エネルギー効率の高いモデルを消費する
設計原則
AWS で生成 AI ワークロードをホストする設計原則です。
(個人的に大事だなと思った部分を太字にしたのと、最後に感想入れてみました。)
制御された自律性の設計
AI システムの運用、拡張、相互作用を制御する包括的なガードレールと境界を実装することが求められます。
明確な運用要件、セキュリティ管理、障害条件を確立することで、信頼性を維持しながら、 AI システムを安全、効率的、かつ費用対効果の高いワークロードが実装できます。
本システムがどのようなシステムなのか、どのフローで LLM を利用するのかを明確に定義することで、上がりがちな期待値を調整するのは大切だと思います。
包括的な可観測性を実装
セキュリティやパフォーマンスからコストや環境への影響まで、生成AIシステムの特定の側面を監視・測定します。
ユーザーからのフィードバック、モデルの挙動、リソース使用率、セキュリティイベントなど、あらゆるレイヤーにわたる指標を収集することで、システムの動作を最適化しながら運用の卓越性を維持できます。
生成AIワークロードの体験向上に直結するため、観測できる仕組みは必要だと思いました。
リソース効率の最適化
AI コンポーネントの選択と構成は、仮定ではなく経験的な要件に基づいて行います。
モデルの適正化、データ操作の最適化、そして動的なスケーリングを実装することで、パフォーマンスニーズとコスト、そして持続可能性の目標のバランスをとることができます。
ついつい、新しいモデルを選びがちですが、実は古いモデルで十分な効果が出ているケースもあったりします。また、XX が得意、YY が得意といった向き不向きもあります。PoC を実施し、効果測定を行うことが重要です。
分散型レジリエンスの確立
コンポーネントまたは地域的な障害が発生しても運用を継続できるシステムを設計します。
冗長性、自動復旧メカニズム、リソースの地理的分散を実装することで、コストとパフォーマンスを管理しながら、一貫したサービス提供を維持できます。
LLM アプリケーションに限った話ですが、耐障害性/可用性の必要なワークロードでは冗長性を持たせましょう。
リソース管理の標準化
プロンプト、モデル、アクセス権限といった重要なコンポーネントについて、一元化されたカタログとコントロールを維持します。
構造化された管理システムを導入することで、セキュリティの維持、リソース使用量の管理、バージョン管理の実現、そして運用効率を維持しながらコストの最適化を実現できます。
一元化されたダッシュボードや、デプロイ含めた仕組みの実装は運用効率を高めます。標準化できるものは仕組み化していきましょう、
セキュアなインタラクション境界
データフローとシステムインターフェイスを保護・制御します。
最小権限アクセス、セキュアな通信、入出力のサニタイズ、包括的な監視を実装することで、システムのセキュリティを維持しながら、信頼性と効率性に優れた運用を実現できます。
こちらも LLM に限った話ではないですが、最小権限や通信の暗号化/ネットワーク制御/データフローを意識して設計していきましょう。RAG やファインチューニングで利用するデータなどのサニタイズも意識しましょう。
設問リスト
作成してみました。数えてみると全 29 問でした。
運用上の優秀性(5つ)
ID | 設問 | ポイント |
---|---|---|
GENOPS01 | 一貫したモデル出力品質をどのように実現し、検証するのでしょうか? | この質問は、主要な指標の追跡、アラートの設定、問題への対応に使用する戦略とツールに焦点を当てています。生成AIアプリケーションの運用上の健全性とパフォーマンスを維持するには、アプリケーションのすべてのレイヤーにわたって包括的な監視および管理戦略を実装することが不可欠です。従来のベストプラクティスは適用できますが、基盤モデルはソフトウェアやデータと従来のシステムとは異なる方法でやり取りします。 |
GENOPS02 | アプリケーションの動作健全性をどのように監視および管理しますか? | この質問は、主要な指標の追跡、アラートの設定、問題への対応に使用する戦略とツールに焦点を当てています。生成AIアプリケーションの運用上の健全性とパフォーマンスを維持するには、アプリケーションのすべてのレイヤーにわたって包括的な監視および管理戦略を実装することが不可欠です。従来のベストプラクティスは適用できますが、基盤モデルはソフトウェアやデータと従来のシステムとは異なる方法でやり取りします。 |
GENOPS03 | モデル、プロンプト、アセットのトレーサビリティをどのように維持しますか? | 生成AIワークフローにおけるトレーサビリティ、再現性、そして継続的な改善を確立するために、プロンプト、モデル、そして関連資産をどのように管理し、バージョン管理していますか?これには、プロンプトエンジニアリング、モデルのバージョン管理、そしてパフォーマンス評価への構造化されたアプローチを維持するためのプラクティスとツールが含まれます。これには、バリアントのテスト、ベースラインの取得、そして定義されたメトリクスとグラウンドトゥルースデータに基づく最適化の方法も含まれます。 |
GENOPS4 | 生成 AI ワークロードのライフサイクル管理をどのように自動化しますか? | Infrastructure as Code(IaC)の原則を用いて、生成AIワークロードのライフサイクル管理を自動化するための戦略を探求します。ツールの選択、CI/CDの実装、環境管理、バージョン管理、ガバナンスの実践といった側面を網羅します。一貫性、セキュリティ、コンプライアンスを維持しながら、開発と展開のさまざまな段階において、AIアプリケーションのための再現性、拡張性、保守性に優れたインフラストラクチャを構築することに重点を置いています。 |
GENOPS05 | Gen AI モデルのカスタマイズをいつ実行するかをどのように決定しますか? | 生成AIモデルのカスタマイズへの戦略的アプローチを検討し、タスクの特異性、データの可用性、リソースの制約といった要素を考慮します。運用ニーズに合わせて、モデルの高度なカスタマイズを調整します。まずは迅速なエンジニアリングから始め、RAG、微調整、カスタムモデルの構築といったより高度な手法へと進めます。モデルの評価とカスタマイズにはクラウドベースのツールを活用することで、セキュリティの維持と定期的な更新に役立ちます。カスタマイズプロセス全体を通して、モデルのパフォーマンス、リソース要件、メンテナンスコストのバランスを取ります。 |
セキュリティ(6つ)
ID | 設問 | ポイント |
---|---|---|
GENSEC01 | 生成 AI エンドポイントへのアクセスをどのように管理しますか? | 基盤モデルは、マネージド、サーバーレス、またはセルフホスト型のエンドポイントを通じて利用できます。それぞれのパラダイムには、独自のセキュリティ上の考慮事項と要件があります。この質問は、生成AIワークロードに関連するエンドポイントに固有のセキュリティ上の考慮事項を理解することを目的としています。 |
GENSEC02 | 生成 AI アプリケーションが有害、偏った、または事実上誤った応答を生成するのをどのように防ぐのでしょうか? | とくにガードレールが適切に実装されていない場合、あるいはまったく実装されていない場合、基盤モデルが有害、偏向的、あるいは事実誤認の応答を生成する可能性があります。このリスクにより、生成AIアプリケーションを本番環境に導入する前に、追加の検討事項が生じます。この質問は、有害、偏向的、あるいは事実誤認の応答のリスクを軽減するためのベストプラクティスについて述べています。 |
GENSEC03 | 生成 AI ワークロードに関連するイベントをどのように監視および監査しますか? | 生成AIシステムのセキュリティとパフォーマンスを向上させるには、イベントの包括的な監視と監査を実装することが効果的です。このアプローチにより、迅速な特定が可能になります。 |
GENSEC04 | システムとユーザープロンプトをどのように保護しますか? | プロンプトは、生成AIワークロードにとって重要な要素です。ユーザーまたはアプリケーションが基盤モデルとどのように対話するかを定義します。プロンプトのエンジニアリングとテストは重要なプロセスであり、最適化には時間と労力が必要です。システムとユーザープロンプトのセキュリティは、生成AIワークロードのセキュリティにとって重要な要素です。 |
GENSEC05 | モデルの過剰な代理権をどのように防いでいますか? | 過剰なエージェンシーは、OWASP(Open Worldwide Application Security Project)がLLMに対するトップ10のセキュリティ脅威として挙げているもので、通常はエージェントアーキテクチャを通じてシステムに導入されます。エージェントはユーザーに代わってアクションを実行するように設計されています。過剰なエージェンシーのリスクは、エージェントが本来の目的を超えたアクションを実行してしまう可能性があることです。 |
GENSEC06 | データ汚染リスクをどのように検出し、修復しますか? | データポイズニングは、モデルのトレーニングやカスタマイズ中に発生する可能性のあるエクスプロイトの一種です。これは、モデルのトレーニングやカスタマイズに使用されないデータがトレーニングやカスタマイズに使用され、完成したモデルに望ましくない影響を与える可能性があります。データポイズニングは検出が困難で、修復も困難な場合があります。 |
信頼性(6つ)
ID | 設問 | ポイント |
---|---|---|
GENREL01 | 基盤モデルのスループット割り当て (またはニーズ) をどのように決定しますか? | 基盤モデルは詳細な入力に対して複雑なタスクを実行するため、一度に処理できる推論リクエストの数には制限があります。これは、マネージド型およびサーバーレス型のモデルホスティングパラダイムにおいて特に顕著です。 |
GENREL02 | 生成 AI アーキテクチャのさまざまなコンポーネント間で信頼性の高い通信を維持するにはどうすればよいでしょうか? | 生成AIワークロードは、複数の独立したシステムで構成される場合があります。基盤モデルは、データベース、データ処理パイプライン、プロンプトカタログ、さらにはエージェント用APIによって補完されることがよくあります。これらのシステムはネットワークを介して通信するため、信頼性の高い接続が必要です。 |
GENREL03 | 生成 AI ワークロードのループ、再試行、および障害に対する修復アクションをどのように実装しますか? | 生成AIワークロードは、論理ループ、再試行、そして場合によっては障害の影響を受けやすい場合があります。適切なベストプラクティスを通じてこれらの問題に対処することで、アプリケーションの信頼性を維持し、ユーザーエクスペリエンスを向上させることができます。 |
GENREL04 | プロンプト、モデル パラメーター、および基礎モデルのバージョンをどのように維持しますか? | プロンプトは、ワークロードごとにモデルのパフォーマンスを差別化します。プロンプトのキュレーションは時間のかかるプロセスになる場合があり、信頼できるプロンプトストアを用意することが重要です。Foundationモデルのパフォーマンスはバージョンごとに異なり、推論ハイパーパラメータがモデルのパフォーマンスに与える影響も異なります。これらの差異を標準化し、バージョン管理することで、より信頼性の高いエクスペリエンスを実現できます。 |
GENREL05 | 推論ワークロードを複数の利用可能なリージョンにどのように分散しますか? | 生成AIアプリケーションは、単一の基盤モデルに対する迅速な応答ワークフローのようなシンプルなものから、マルチエージェント・オーケストレーションのような高度なものまで、多岐にわたります。生成AIワークロードに関連する様々なコンポーネントは、利用可能なリージョンにサービスを提供するために必要です。可用性は、明確に定義されたゾーンに限定されることもあれば、広大な地理的領域をカバーする拡張性を持つこともあります。このような変動性を考慮したアーキテクチャの構築は複雑な問題です。 |
GENREL06 | 成功率を最大化するために、高性能分散計算タスクをどのように設計しますか? | 生成AIにおけるモデルのカスタマイズやその他の高性能分散計算タスクは、実行時間が長く、コストが高く、脆弱になりやすい場合があります。これらの分散型高性能計算タスクは、信頼性を重視して意図的に設計することが重要です。そうすることで、結果として得られる基盤モデルは高いパフォーマンスを発揮し、タイムリーに学習されます。 |
パフォーマンス効率(4つ)
ID | 設問 | ポイント |
---|---|---|
GENPERF01 | 運用中の生成 AI モデルのパフォーマンスをどのようにキャプチャして改善しますか? | 基礎モデルは幅広いタスクで優れたパフォーマンスを発揮し、その全体的なパフォーマンスはリーダーボードやその他の公開メトリック追跡ソリューションによって追跡されています。しかし、基礎モデルは必ずしも特定のタスクに適しているわけではありません。例えば、基礎モデルを使用して、特定の形式に従い、特定の単語(数学や法律文書など)を使用して文書を作成するといったタスクが考えられます。ここでは、特定のタスクにおけるモデルのパフォーマンスを向上させる方法について説明します。 |
GENPERF02 | 生成 AI ワークロードが許容可能なパフォーマンス レベルを維持していることをどのように確認しますか? | 基盤モデルは本質的に非決定論的です。システムにランダム性の要素を導入するため、その要素を考慮する必要があります。さらに、基盤モデルは柔軟で多目的に使用できる一方で、計算集約型のリソースであるため、組織の要件に合わせて調整やカスタマイズが必要になる場合があります。 |
GENPERF03 | 高性能分散計算タスクに必要な計算リソースをどのように最適化しますか? | 基盤モデルをカスタマイズし、大規模な推論を実行するには、高い処理能力が必要です。基盤モデルに使用される高性能コンピューティングを最適化し、パフォーマンス要件を満たします。 |
GENPERF04 | データ検索システムのパフォーマンスをどのように向上させますか? | ベクターデータベースなどのデータ検索システムは、生成AIシステムで最も一般的な設計パターンのいくつかをサポートしています。データ検索システムのパフォーマンスボトルネックは、下流に連鎖的な影響を及ぼす可能性があり、その特定と対応は困難です。 |
コスト最適化(5つ)
ID | 設問 | ポイント |
---|---|---|
GENCOST01 | コストを最適化するために適切なモデルを選択するにはどうすればよいでしょうか? | 基盤モデルのコストは、基盤モデルプロバイダー、モデルファミリーとサイズ、そしてモデルホスティングパラダイムによって大きく異なります。モデルを選択する際には、コストを要素として評価することが効果的です。この質問では、コストを考慮したモデル選択を実現するためのベストプラクティスについて説明します。 |
GENCOST02 | コスト効率の高い価格モデル (プロビジョニング、オンデマンド、ホスト、バッチなど) をどのように選択しますか? | 基盤モデルのホスティングと推論は、様々な方法で実行できます。ワークロードによっては即時のレスポンスが求められるものもあれば、バッチ処理で実行できるものもあります。また、管理されていないインフラストラクチャでホストされるものもあれば、サーバーレス技術を使用してホストされるものもあります。推論とホスティングのパラダイムの選択は総コストに影響を与えるため、コストを考慮して決定する必要があります。 |
GENCOST03 | コストを最適化するためにプロンプトをどのように設計しますか? | プロンプトは、ワークロードのコストとワークロードのパフォーマンスを最適化するように設計されています。 |
GENCOST04 | ベクトルストアをコストの観点から最適化するにはどうすればよいでしょうか? | Retrieval Augmented Generation(RAG)のような生成AIアーキテクチャは、その効果を維持するために堅牢なデータバックエンドを必要とします。ベクターストアはアプリケーションの実行コスト全体を増加させる可能性があるため、最適化する必要があります。 |
GENCOST05 | コストの観点からエージェントのワークフローを最適化するにはどうすればよいですか? | エージェントアーキテクチャは、あらゆるドメインにわたる大幅な自動化の可能性を秘めています。しかし、構成を誤ると、必要な追加コストが発生する可能性があります。 |
持続可能性(3つ)
ID | 設問 | ポイント |
---|---|---|
GENSUS01 | 生成 AI ワークロードのトレーニング、カスタマイズ、ホスティングに必要な計算リソースを最小限に抑えるにはどうすればよいでしょうか? | 生成AIワークロードのトレーニング、カスタマイズ、ホスティングのための計算リソースを最適化するには、サーバーレスアーキテクチャと自動スケーリング機能の導入を検討してください。効率的なリソース利用とインフラストラクチャ管理を提供するマネージドサービスを利用しましょう。インスタンスの最適化、コンテナのキャッシュ、モデルの高速読み込みといった戦略を実装することで、パフォーマンスを向上させ、環境への影響を軽減できます。生成AI向けに設計された専用インスタンスを検討することで、スループットの向上とコスト削減を実現できます。 |
GENSUS02 | エネルギー消費を最小限に抑え、効率を最大化するために、データ処理とストレージをどのように最適化できますか? | 生成AIワークロードにおけるデータ処理パイプライン、ストレージシステム、インフラストラクチャの計算リソースを最適化するには、サーバーレスアーキテクチャと自動スケーリングメカニズムの導入を検討してください。列指向形式と圧縮を採用することで、転送と処理の要件を最小限に抑えます。サーバーレスクエリとETLサービスを実装することで、永続的なインフラストラクチャの必要性を軽減し、効率的なリソース利用と持続可能性を促進します。 |
GENSUS03 | 大規模な言語モデルを扱う際に、モデルの効率性とリソースの最適化をどのように維持しますか? | 大規模言語モデルにおけるモデル効率とリソース最適化を向上させるための戦略を探求します。量子化、プルーニング、特定のタスクに合わせた小規模モデルのファインチューニングといった手法に焦点を当てます。モデル蒸留のメリットを考慮し、効率的でタスク固有のモデルを作成します。パフォーマンスと計算要件のバランスを取り、生成AIアプリケーションにおける最適なリソース利用を実現します。 |
参考資料
実装ガイダンス
Well-Architected Tool を利用して各項目に回答していくわけですが、実装できているか分かりづらいシーンがあると思います。その際は実装ガイドを見ながら、できている/できていないを判断していくのが良いかと思います。たとえば、GENOPS01
では GENOPS01-BP01
と GENOPS01-BP02
が用意されています。
GENOPS01-BP01 をさらに深掘りしてみます。
GENOPS01
の 一貫したモデル出力品質をどのように実現し、検証するのでしょうか?
の手段として、Amazon Bedrock のモデル評価機能、 OSS だと fmeval, ragas が紹介されています。
GENOPS01-BP01 Periodically evaluate functional performance - AWS Well-Architected
OWASP Top 10 for LLM Applications
セキュリティの柱によりますが、LLM アプリケーションをホストするにおいて意識したいセキュリティ対策の事項として、OWASP Top 10 for LLM Applications という資料があります。
実装ガイドを読んでいるとよく出てきていたため、合わせて読んでおくと良いかと思います。
2025 年対応資料
2024 年資料
Well-Architected Tool
今回アップデートのあった、Generative AI Lens は Well-Architected Tool ですでに利用可能になっています。
実際の回答は Well-Architected Tool で行っていきましょう。
まとめ
以上、「AWS Well-Architected Framework に Generative AI Lens が登場しました。」でした。
サービスアップデートが激しい領域ですが、ベストプラクティス集が出てきてありがたいですね。
ゴールデンウィークの読み物として、ブックマークしておきたいですね。このブログがどなたかの参考になれば幸いです。クラウド事業本部コンサルティング部のたかくに(@takakuni_)でした!