re:Invent 2024: AWSが語るGenerative AI観測のベストプラクティス
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Best practices for generative AI observability (COP404)
この動画では、AWSのAI/ML Tech LeaderであるDenis V. BatalovとCloudOps分野のGreg Eppelが、Generative AIにおけるObservabilityについて解説しています。CloudWatchを活用したGenerative AIの監視について、4つのレイヤーに分けて説明が行われ、特にBedrockとLangChainを組み合わせたRAGアーキテクチャの実装例が示されています。CloudWatchが月間20クアドリリオンのメトリクスを処理する大規模システムであることや、Embedded Metric Formatを使ったユーザーフィードバックの収集方法、Guardrailsによる不適切な出力の制御など、実践的な知見が豊富に共有されています。90年代のBYTEマガジンの記事を引用しながら、現代のGenerative AIの課題と解決策を分かりやすく説明している点も特徴的です。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Generative AIのObservabilityに関する講演の導入
私はDenis V. Batalovと申します。AI/MLのWorldwide Tech Leaderを務めており、AWSのAI/ML技術の導入を支援する1000人以上のソリューションアーキテクトやカスタマーフェイシングの専門家たちの業務を取りまとめる役割を担っています。本日は、CloudOps分野から同僚のGreg Eppelを迎えています。今回は、Generative AIにおけるObservabilityという重要なテーマについてお話しさせていただきます。Generative AIは私たち全員にイノベーションの渦を巻き起こしましたが、同時に様々な試行錯誤も経験してきました。
本日は、まずPOCを本番環境に移行することが時として難しい理由について説明します。Generative AIで正しく実装することが難しい点について、そしてもちろん、アプリケーションが特定の方法で動作したり誤動作したりする理由を理解することは、明らかにObservabilityに関連しているため、その点についても触れていきます。次に、Generative AIプラットフォームのコンポーネントについてお話しします。多くのお客様がこのような性質のプラットフォームの構築を始めており、これらのプラットフォームの様々な要素とObservabilityに関する懸念事項について見ていきます。その後、Gregが最も重要な部分であるGenerative AIのObservabilityの実践方法について説明します。CloudWatchとその様々な機能についてもお話しする予定です。
AIの歴史と現在のGenerative AIの課題
このトークの準備をしている際、過去を振り返ってみるのも面白いと思いました。90年代、私はまだBYTEマガジンのコレクションを持っていました。ソフトウェアエンジニアリングやIT関係者の間で非常に人気のあった雑誌だったことを覚えている方もいらっしゃるかもしれません。私は記事の切り抜きを集めて小さなノートブックにまとめていました。 80年代前半から中頃の切り抜きをいくつか使って、いくつかの側面を説明するのも面白いと思いました。これが本物であることを証明するために、ここに当時のビジネスパーソン、今で言うObservability Engineerと呼べそうな求人広告があります。また、右側のMicrosoftのロゴにも注目してください。Microsoftの方はいらっしゃいますか？これは非常に興味深いもので、ハッチング（網掛け）された円の中にOがあるデザインで、社内では「blit」と呼ばれていたと思います。当時の人々は実際このロゴを気に入っていたんです。これは80年代半ばのものです。
こちらは1985年4月の別の切り抜きです。振り返ってみると本当に興味深いものです。注意深く読んでみると、「この補助的な脳葉はあなた自身の記憶の範囲を超えた情報で質問に答え、もっともらしい行動方針を提案し、関連する事実を引き出すのに役立つ質問をする」とあります。これは現在のGenerative AIにおけるRAG（Retrieval Augmented Generation）アーキテクチャや、もしかするとエージェントシステムを思い起こさせませんか？当時既にこのようなことを考えていたというのは興味深いですね。そしてもちろん、脳が回路基板に置き換えられた定番的な図も載っています。これは当時も今も同じように人気のあるイメージだったようです。
興味深いことに、AIを特集した同じ号に、「あなたのコードをデバッグしに来ました」と言う、エイリアンのようなナメクジの絵が載っています。このように、コーディングアシスタントについても当時から考えられていたわけです。 昨年2023年は、まさにPOCの年でした。誰もがGenerative AIでPOCを構築しようとしました。今年は、それらのPOCを本番環境に移行する年だと私は考えていますが、明らかにすべてのPOCが本番環境に到達したわけではありません。実際、いくつかの調査によると、POCの4分の3は本番環境に移行されることなく、日の目を見ることなく立ち往生してしまうそうです。
Generative AIシステムの品質と課題
これには、いくつかの理由があります。従来のMachine Learningでは、長年にわたって精度が最も重要な特性とされてきました。しかし、Generative AIではもう少し複雑になっています。特に、システム全体の品質について考える必要があります。これは、関連性が高く有用な情報を提示するという形で現れることもありますが、私たちはみな、ハルシネーション（幻覚）、つまり誤った出力についても耳にしています。そのため、事実に基づく正確性が重要です。事実の正確性は、インターネットや独自のKnowledge Baseから得られる文脈にしっかりと根ざしている必要があります。
また、これらのシステムは堅牢である必要があります。つまり、入力をわずかに変更しても、出力が大きく変化しないようにする必要があります。現在の最先端技術では、これを実現するのは本当に簡単ではありません。これらのモデルは確率的で非決定的なので、その動作の特性をよく理解する必要があります。
これは、人々が不適切に使用した際に、かなりの話題を呼んでいます。例えば、弁護士が判例を探す際に、生成的な性質を持つツールを見ることがありますが、トレーニングデータセットで十分な回数その判例を見ていれば正確な回答を生成しますが、多くの場合、不正確な回答を生成してしまいます。これは一度きりの出来事ではなく、パターンとして見られるようです。 これは、Canadaで起きた全く別のケースです。 さらに、Chatbotが提示する他の情報にも問題があります。これは必ずしもハルシネーションに関連するものではなく、おそらく提供されるアドバイスがポリシーに照らして本当に正確かどうかという問題です。
最近では、AI医療転写システムでハルシネーションが発生しているというニュースがありました。 これらの転写エラーの中には、医師が読んだ際に簡単に見分けられるものもありますが、気付かないうちに意味を大きく変えてしまう可能性のあるものもあります。医療チームがこれらの過去の転写記録を見る際には、本当に重要な問題となります。このような間違いは間違いなくコストがかかります。
パフォーマンスに関して、私たちはITのパフォーマンス指標をよく知っています。マイクロ秒単位のレイテンシー、1秒間に数百万のトランザクション - 物理法則や信号伝送の限界に迫るような、非常に高いレートに慣れてきました。しかし、Generative AIでは、まるで後退したかのように感じます。今では1分あたりのトランザクション数や、数秒単位のレイテンシーについて話しています。 興味深いことに、80年代では15秒というのがゴールドスタンダードでした。つまり、コンピュータの応答が15秒以内であれば素晴らしく、それより長いと人々はイライラし始め、不満を感じるということです。 これらの指標が頻繁に言及されているのは興味深いですが、現在のGenerative AIでも数秒単位の生成時間が必要という、同じような状況に直面しています。
これは最終的にコストの考慮につながります。システムのコストを観察する方法を確保したいと考えています - 事前に見積もりを立てることと、本番環境での実際のコストを確認することの両方が重要です。これは、単一または複数のインスタンスでモデルを実行したり、時間単位で固定費用が発生するインスタンス時間を消費したりすることに関連しています。Amazon Bedrockのようなソフトウェア・アズ・ア・サービスを使用する場合、コストは消費したトークンと出力トークンで測定されます。基盤となるITの特性は依然として非常に重要です。
Generative AIプラットフォームの構成要素
本日は、これら3つの主要な懸念事項に関連する観察可能な側面について、そして本番環境でこれらのGenerative AIシステムを正しく実装することが難しい理由について説明します。 では、現在のGenerative AIプラットフォームがどのように見えるか、そしてその主要なコンポーネントについて見ていきましょう。多くの企業が最初に取り組むのは、Foundation Modelのハブ、つまり様々なモデルへのアクセスを可能にする方法です。市場では常に競争が行われており、新しいモデルが次々と登場しているため、それらのモデルにアクセスする選択肢と柔軟性を持つことが重要です。また、モデルに組み込まれている知識だけに頼らないことも重要かもしれません。
もちろん、 自社のデータ、つまり企業独自のデータを組み込みたい場合もあるでしょう。ここでは、Retrieval Augmented Generationなどのパターンが自然な追加コンポーネントとして導入されます。あるモデルではそれで十分かもしれませんが、場合によってはモデルのカスタマイズや適応が必要になることもあります。Gen AIアーキテクチャのこの重要なコンポーネントについても考慮する必要があります。
より高レベルなアプリケーションレベルのオーケストレーションを始めると、 エージェントアーキテクチャを含む可能性のある、さらなるコンポーネントが加わります。 成熟したGen AIプラットフォームは、必ずOpsに対応する必要があります。Opsには複数の重要な懸念事項があります。例えば、プロンプトの管理、バージョン変更の把握、Foundation Modelのバージョンアップグレード、企業が保有する最新のドキュメントによるVector Databaseの更新などです。
ガバナンスと観察可能な制御プレーンは、存在する2つの重要な側面です。今回のトークではこの後者に焦点を当てます。最後に忘れてはならないのが、 すべての基盤となるITインフラストラクチャです。これが、典型的なGen AIプラットフォームの考慮事項とコンポーネントの概要です。
CloudWatchを用いたObservabilityの実践
今回のトークでは、これらすべてを網羅するわけではありません。プラットフォームのこれら3つのコンポーネントと、それらに関連する可観測性の課題、そしてAWS上でどのように可観測性を構築するかに焦点を当てていきます。このFoundation Model Hubをより詳しく見ていくと、実際にはLLM Gateway、FM Gateway、あるいはAI Gatewayのような形で実装されることが多いです。オープンソース、カスタム、そしてプロプライエタリなソリューションなど、様々な選択肢があります。ここでは、モデルへのアクセス制御、何らかの形のレジストリ、コストログ、スロットリング、そしてフェイルオーバーの仕組みを整備する必要があります。
可観測性の観点では、これらのモデルへのAPIインターフェースを扱うことになるので、基盤となるモデルの呼び出し回数、レイテンシー、消費されたトークン数、そして特定の推論に関係する様々なモデル推論パラメータに注目する必要があります。このFoundation Modelを活用する一般的な方法の1つが、Retrieval Augmented Generation（RAG）パターンです。非常に一般的なパターンなので、これに焦点を当てていきましょう。
これが一般的な高レベルの図です。Salesforceなどの様々なSaaSプラットフォームやその他のプラットフォームにロックインされた大量のデータにアクセスする可能性があります。また、情報を抽出したいログなどの非構造化形式の文書や、アプリケーションに関連する文書を生成するETLジョブがあるかもしれません。RAGの一般的な仕組みとしては、これらの文書ソースから個々の文書チャンクをインデックス化します。チャンキング戦略やチャンクの境界をどこに設定するかという決定は、結果の品質に影響を与えるため、これらについて検討する必要があります。
これらの文書チャンクをEmbeddingモデルに通します。このモデルは図では外側に示されていますが、すでにModel Hubを通じて利用可能かもしれません。Embeddingの役割は、これらのチャンクをベクトルに変換することです。これらのベクトルはVector Databaseに保存されますが、Vector Databaseにも多くの選択肢があります。最終的に、このアプリケーションを本番環境で実行する際、インデックス作成は前処理ステップとして行われ、新しい文書が入ってくるたびにオンラインで追加のインデックス作成が継続的に行われる可能性があります。
この継続的なインデックス作成プロセスのオーケストレーションは課題となることがあります。本番環境では、通常、クエリを同じEmbeddingモデルを通してベクトル空間にマッピングし、Vector Databaseを通じてコサイン類似度に基づいて類似のベクトルを検索し、すべてのチャンクを抽出してコンテキストを構築します。多くの高度なシステムでは、Embeddingベースの検索に加えて、キーワード検索などの従来の情報検索技術も組み合わせています。特に階層構造を持つポリシー文書を扱う場合、データの階層的な表現を取り入れてより複雑にすることもでき、特定のクエリのコンテキストを構築する際にその構造をナビゲートします。
このRAGシステムを自分で構築する方法をご紹介します。Amazon Bedrockを使えば、このアーキテクチャのマネージドソリューションを実現できます。Amazon Bedrock Knowledge Basesがインデックス作成とチャンキングを処理してくれるからです。この処理にはいくつかのカスタマイズオプションも用意されています。さらに、現在は単独のAPIとして利用可能になったAmazon Bedrock Guardrailsを適用することもできます。これらのGuardrailsはBedrockに限定されているわけではなく、AWS上でもAWS外でも、どのようなモデルにも適用できます。Guardrailsを使えば、ヘイトスピーチや性的なコンテンツ、侮辱的な表現、潜在的なプロンプト攻撃といった言語に関する標準的な特性に基づいて、プロンプトやコンプレーションをフィルタリングできます。また、投資アドバイスや政治などのトピックを自然言語で記述することで、拒否するトピックや範囲外の会話を設定でき、Guardrailsがプロンプトやコンプレーションをそれらのトピックに自動的に分類して、そのような会話をブロックすることができます。
最近追加された機能の1つに、文脈的な根拠付けと関連性チェックを追加する機能があります。検索で補強された文脈とプロンプトの応答を検証して、その応答が文脈に基づいており、質問に対して関連性があるかどうかを確認する方法があります。このようなオーケストレーションモデルでは、様々な観点からの可観測性に興味があるかもしれません。これから、この階層的なアプローチについて説明していきましょう。最上位層では、呼び出し回数、エラー、レイテンシー、リソース使用率などのコンポーネントレベルのメトリクスがあります。次に、Retrieve Augmented Generation、エージェントシステム、チェーントレースなど、よりオーケストレーション層に移ります。第3層では、これらのGuardrailsがトリガーされた時期、Guardrail側で行われた介入、会話トピックのベクトル空間埋め込みを調べて、そのセントロイドがシフトしているかどうかを認識する埋め込みドリフトなど、より高度なメトリクスと分析を見ることができます。最後に、エンドユーザーからのフィードバックを直接収集し、システムに組み込む方法があります。
ここで、可観測性の側面についてお話しいただくため、同僚のGregをステージにお迎えしたいと思います。私は残りの時間を使って、これら4つの層について説明していきます。それぞれの層について2～3分のデモを用意していますので、まず第1層から見ていきましょう。その前に、AWSで考えている可観測性の3つの柱について説明したいと思います。それは、メトリクス、ログ、トレースであり、CloudWatchはこれらすべてをサポートしています。
皆さんご存知かもしれませんが、CloudWatchは長い歴史があります。最初のサービスではありませんが、最も初期のサービスの1つで、大規模な可観測性システムです。私たちの可観測性担当VPがイノベーショントークで最新のメトリクスを紹介していましたが、現在、毎月20クアドリリオン（20,000兆）のメトリクスを観測しています。毎月13エクサバイト以上のログを取り込み、CloudWatch内に約半兆のトレースを保存しています。これは非常に大規模なシステムであり、多くの人々はCloudWatchが実際にどれほど大規模に運用されているかを理解していません。
メトリクス、ログ、トレース、これらはどれも他より重要というわけではありません。過去数年間、何百ものお客様と可観測性について話をしてきましたが、多くのお客様が「もはやログやメトリクスは必要なく、トレースだけで十分だ」とおっしゃいます。しかし、私はこれを三本脚の椅子のようなものだと考えています - 3つすべてが必要なのです。これら3つの異なる可観測性シグナルを相関させる必要があります。ログは、Foundational Modelへの入力プロンプトとユーザーへの出力レスポンスが何だったかを教えてくれます。メトリクスは、それらのFoundational Modelを使用する際のプロンプトレイテンシーの増加を理解するのに役立ちます。そしてトレースは、RAGアーキテクチャ間のすべての分散コンポーネントを理解するのに本当に役立ちます。
OpenTelemetryを活用したトレーシングの実装
このスライド全体を詳しく説明するつもりはありません。ただ、お伝えしたいのは - もし CloudWatch をご存知なら、以前とは全く異なるものになっているということです。この2、3年で多くの機能を追加してきましたし、今週もさらに新機能が発表される予定です。しばらく CloudWatch を見ていない方は、ぜひ改めてチェックしてみることをお勧めします。今週は多くのセッションが予定されていますが、CloudWatch には本当に豊富な機能が揃っています。
では、最初のレイヤーについて詳しく見ていきましょう。Dennis も言及していたように、多くのサービスが CloudWatch に対して、メトリクス、場合によってはログやトレースを直接送信します。通常、これらのメトリクスは自動的に送信され、お客様の追加コストは発生しません。つまり、Amazon Bedrock や Amazon OpenSearch、Amazon S3 などのサービスを使い始めると、それらのサービスチームが自動的にメトリクスをお客様のアカウントに送信し始め、サービスのパフォーマンスを把握できるようになります。
ぜひブックマークするか、スクリーンショットを撮っておくことをお勧めします。CloudWatch にメトリクスを送信する全てのサービスを一覧できるページがあります。3つのQRコードを用意しました - 1つはこのページへのリンク、残りの2つは Bedrock のページと SageMaker のページへのリンクです。新しいサービスを使い始める際、特に Generative AI 関連のサービスを使用する場合は、このページにアクセスして、私たちがお客様のアカウントに送信しているメトリクスについて理解しておくことをお勧めします。
重要でありながら見落とされがちなのが、私たちが送信するメトリクスのディメンション（次元）についての理解です。右側のスクリーンショットは、Bedrock からのレイテンシーメトリクスとトークン数の例です。ここで気づかれていないかもしれませんが、私たちはここにディメンションを適用しています。使用している全モデルの入出力トークン数の合計だけでなく、より詳細な情報も得られます。実際に Claude 2 と Claude Instant v1 を比較することができます。Bedrock の全てのモデルがこれらのメトリクスを提供し、比較検討が可能です。これは非常に有用で、Dennis が言及していた点にも関連します - これらのモデルにはそれぞれ異なるコストがかかります。あるモデルは速く、あるモデルは遅いかもしれません。この情報は使用状況を理解する上で役立ち、コストの推定にも活用できます。
もう一つの側面として、多くの方々がこれらのメトリクスをアラームに活用しています。アラーム疲れについて多くの方と話をしますが、これは本当に厄介な問題です。数年前から Composite Alarms という機能を提供していますが、多くの方がこの機能の存在を知らないようです。これは、アラームの階層構造やツリー構造を作成するという考え方です。顧客に影響を与えるイベントでは、通常1つのアラームだけでなく、一連のアラームが発生します。次回同様の事象が発生した際に、これらのアラームを相関付けることで、より賢明なアラームを作成できます。ここでは、LLM の Model A と Model B に設定した2つのレイテンシーアラームを例として挙げています。シンプルな例ですが、最大100個の異なるアラームを組み合わせた複雑なブール式を構築することができます。素晴らしい点は、50-60個のアラームが一斉に発生することがないことです。50-60個のアラームを維持しながらも、それらを1つの Composite Alarm にまとめ、そこから SRE チームに通知を送ることができます。
もう一つ注意していただきたいのは、Bedrock 内でのモデル呼び出しログについてです。Dennis もこれについて少し触れましたが、これは有効にする必要があります。Bedrock では、メトリクスは自動的に送信されますが、ログについては Bedrock 内で設定する必要があります。設定は非常に簡単で、1、2分で完了します。設定後は、左側に表示されている4つのAPIすべてにわたるモデル呼び出しのログが記録され始めます。
最後のパーツは、デモでもっと詳しくお見せしますが、このログパターン分析です。バックエンドで機械学習を使用しており、昨年リリースしました。インボケーションログを収集していく中で、例えば過去1時間に1万件のログがあった場合、それらがどこから来たのか、そしてそれらのログ内のパターンを理解したいと思うかもしれません。これは、CloudWatch Logs Insightsの新しいオペレーターで、そういった理解を助けてくれるものです。
それでは、最初のデモに移りましょう。ラップトップに切り替えます。 はい。 デモの構成について説明するために、一度別の画面に戻る必要があります。その後、ビデオに移ります。 私の4つのデモは全て、作成したChatbotアプリをベースにしています。これはStreamlitを使用したPythonアプリケーションです。 Streamlitは、主にデータエンジニア向けに設計された、Webアプリを簡単に作成できるPythonフレームワークです。Amazon Bedrockと通信するために、 Bedrock APIを直接呼び出すのではなく、LangChainを使用しています。計装にはOpenTelemetryを使用しています。OpenTelemetry は、トレースデータ、メトリクス、ログをCloudWatchエージェントに送信します。CloudWatchエージェントはOpenTelemetryをサポートしており、エンドポイントとして機能して、そのデータをCloudWatchに送信します。
これが、これから私がお見せする4つのデモ全体のアーキテクチャです。 スライドでコードを説明し、その後デモを行います。BedrockとLangChainのセットアップに必要なのは、これだけです。基本的に、ChatBedrockオブジェクトをインスタンス化し、Bedrockからランタイムを渡し、モデルIDを指定します。そして Streamlit用の引数がいくつかあります。もしStreamlitを使ったことがない方は、これから見せるアプリがこれです - 完全に機能するアプリを構築するのに必要なのは、実質的にこの30行程度のコードです。このようなプレゼンテーションでプルーフオブコンセプトを行うのに、とても良い方法です。
では、デモに移りましょう。 ここで再生ボタンを押します。これは約2分の長さです。これがLangChainとOpenTelemetryでセットアップされた、Streamlitの実際のアプリケーションです。いくつかの質問をしてみましょう。 Amazon CloudWatchについての段落を書いてください - すると、CloudWatchに関するテキストが返ってきます。続いて、Amazon Bedrockについての情報を書くように依頼してみましょう。応答を待ちます。
今行ったことで、BedrockからCloudWatchにメトリクスが自動的に送られます - 特別な設定は必要ありません。Bedrockチーム、つまりサービスチームが、それらのメトリクスを直接あなたのアカウントに送信します。そこに入って、個々のメトリクスを実際に見ることができます。私はClaude Haikuを使用していましたが、 アプリケーションで今行ったことについて、インボケーションレイテンシーとインボケーション数を見てみましょう。
ここで見えるのは小さな点が1つだけです。これは私たちが2回のプロンプトを送信しただけだからです。そのため、きれいな折れ線グラフは得られませんが、基本的に2回の呼び出しを示す2つの点があり、時間経過に伴う平均レイテンシーが表示されています。情報を継続的にBedrockに送信して応答を得る別のアプリケーションも実行しました。こちらの方が良い例で、時間の経過とともに異なるモデルのレイテンシーがどのように変化するかが分かります。メトリクスにこのような次元性があることは非常に有用で、異なるモデルを比較・対照することができます。
ログの方に移りましょう。時間経過に伴うレイテンシーの変化を確認し、その後ログを見ていきます。BedrockでInvocationロギングを既に設定してあるので、CloudWatchログに移動します。bedrock/invocationsというロググループがあります。クエリを実行すると、約4つの結果が得られるはずです。そしてこれらのログエントリが表示されます。LangChainを使用してPythonで構築したチャットボットと対話すると、Bedrockは直接CloudWatchにログを送信します。出力レスポンスで送信された情報を確認できます。
セットアップして使用するのは非常に簡単です。LLMとのユーザーの実際のやり取りに関する情報がすべて得られるため、非常に強力です。そしてこちらが、多数のメッセージ（約600〜700件）をBedrockに送信した別のアプリケーションの例です。
機械学習によるログ要約の仕組みをお見せしましょう。フィールドにパターン演算子を適用すると、600〜700のメッセージが約23の異なるパターンに分類されます。上位のパターンの1つが約45%を占めていることが分かります。ログ内の異なる要素をトークン化することで、ユーザーのBedrockの使用状況を効果的に要約し、大量のログを素早く分析することができます。
Amazon Bedrock Guardrailsによる高度なメトリクスと分析
デッキに戻って、レイヤー2に進みましょう。レイヤー2ではエージェントとチェーントレースについて扱い、トレーシングの側面についてより詳しく掘り下げていきます。トレーシングの仕組みについて、初めての方のために簡単な概要を説明します。Amazon API GatewayがAWS Lambdaと通信してAmazon S3に何かを配置するという典型的な例を使用します。これらはすべてHTTPリクエストです。理想的には、トレースがコンポーネントからコンポーネントへと流れていくことが望ましいです。これは一連のスパンを通じて機能し、スパンはトレースの一部であり、スパンの集合が1つの完全なトレースを構成します。一般的に、X-RayやCloudWatchではもっと長い文字列であるトレースIDがあります。また、これらの各スパンにもIDがあり、これら2つの要素が合わさってトレースコンテキストを構成します。
多くの場合、システム全体の完全な視野や全体像を把握することに苦労します。これは通常、境界から境界へとトレースコンテキストが失われてしまうために起こります。この例では、これらのコンポーネントすべてがX-Rayをネイティブにサポートしているため、非常にシンプルです。API Gatewayからのトレースコンテキストが、Lambdaに渡されます。 Lambdaはこれをトレースコンテキストとして認識し、さらに下流に渡すため、追加の作業なしでスムーズに動作します。では、これが実際にどのように機能するのか 、先ほどデモを行ったアプリケーションについて見ていきましょう。この場合、StreamlitとLangChainを使用したPythonアプリケーションのChatbotアプリがあります。 これらのコンポーネントは、少なくとも現時点では本来トレーシングを理解していませんが、Amazon BedrockやAmazon OpenSearchなどのサービスと連携しています。この場合の解決策はOpenTelemetryで、コード内である程度の計装が必要になります。
アプリケーションでのセットアップ方法をお見せしましょう。 このデモでは、RAGアーキテクチャ向けのAmazon Bedrockにおけるナレッジベース機能のセットアップに必要な、約20行のコードの例を示しています。Chat Bedrockインスタンスを作成し、チェーンを実行し、後で計装のために呼び出します。OpenTelemetry Python SDKを使用する場合、アプリケーションの計装に必要なコード量は基本的にこの程度です。トレースプロバイダーのセットアップ、エクスポーターの設定、スパンプロセッサーの確立、そしてAWS SDKやHTTPリクエストの追加計装を実装する必要があります。
では、より技術的な詳細に入っていきましょう。スパンには、様々なセットアップ方法があります。スパンを関数に紐付けることができ、Pythonアプリで呼び出される各関数が新しいセグメントまたはサブセグメントを作成します。ここで私が行っているのは、ネストされたスパンのチェーンを作成することです。ChatBot appという親スパンとその中にLangChainという子スパンがあります。これがCloudWatchでどのように表示されるか、デモでお見せします。ここでは、アプリケーション内で明示的にスパンと子スパンを設定しています。 これらのスパンには、様々な属性を追加できます。例えば、使用しているモデルIDやユーザーが送信したプロンプトを含めることができます。
このデモのために、デモ用ラップトップに切り替えましょう。約2分のデモになります。 ここでお見せするのは、Amazon BedrockでこのようなRAGアーキテクチャをセットアップする方法で、非常にシンプルです。 Bedrockに移動してナレッジベースをセットアップすると、ベクターデータベースとなるAmazon OpenSearch Serverlessクラスターが作成されます。ここにナレッジベースが設定されています。 以前、新しいデータソースをセットアップしました。複数のデータソースオプションが利用可能ですが、今回はシンプルにAmazon S3バケットを作成しました。そのS3バケットを見てみましょう。 単一のPDFが含まれています。このP17 PDFが何か分かりますか？これはIRSの個人税務コードであるPublication 17です。
これは 2023年版で、約120ページのテキストなので、これをS3に配置しました。Amazon Bedrockでナレッジベースを設定したので、これから対話を始めていきます。アプリケーションに戻ってrunを実行し、標準控除について質問を始めていきます。 アメリカ以外の方のために説明すると、IRSでは標準控除を選択するか、年間の控除項目を個別に申告するかを選択できます。
IRSの100ページにも及ぶPDFから情報を引き出して、標準控除額について質問してみましょう。標準控除額は既婚か独身か、また年によっても変わってくるので、その金額について尋ねてみます。その回答を得た後、税金とは無関係の質問として「CloudWatchとは何ですか？」と尋ねてみます。すると、そのナレッジベースの範囲外なので回答できないという応答が返ってきます。
既にOpenTelemetryを組み込んでいるので、もう一度詳しく見てみましょう。tracesに移動してクエリを実行します。トレースを表示して確認してみましょう。先ほどお見せした数行のコードだけで、このようなトレースが得られます。Chatbotアプリケーションから、Bedrockランタイムへの呼び出しとBedrock agentランタイムへの呼び出しの2つが確認できます。
retrieveやinvoke modelなどの異なるオペレーションを確認できます。下にスクロールすると、セグメントとその下のサブセグメントが表示されます。OpenTelemetryで追加したLangChain invokeというコードの部分があり、そこには私が設定した2つのメタデータ（model IDとprompt）が表示されています。これは分散システムを理解する優れた方法で、RAGアーキテクチャはその良い例だと思います。異なるコンポーネント間のやり取りでどこに時間がかかっているかを理解するのに役立ちます。
では、レイヤー3に移りましょう。その前に、OpenLLMetryやOpenLITなど、皆さんもご存知かもしれないOpenTelemetryのオープンソースプロジェクトについてお話ししたいと思います。これらのプロジェクトは、LLMsについてさらに詳細な可視性を提供することを目的としています。もう一つのデモはしませんが、実際にOpenLLMetryを使用したスクリーンショットを用意しました。これは、GitHubで見つけることができるこれらのプロジェクトが、LangChainの使用方法やLLMsでのモデルの呼び出し方について、さらに詳細な可視性を提供する例です。
レイヤー3の高度なメトリクスと分析に進みましょう。ここではGuardrailsに焦点を当てます。Embedding driftについては時間の関係で詳しく説明できませんが、このスライドを簡単に説明します。Dennisが既に説明したように、Guardrailsは基盤モデルに安全対策を適用し、有害なコンテンツやチャットボットに望ましくないコンテンツを検出するための方法です。これらは先ほど言及したメトリクスです。これらはAmazon Bedrock guardrailsから得られるメトリクスで、呼び出しのレイテンシー、スロットリング、そしてGuardrailによって介入された呼び出しの数などが含まれます。
こちらがもう一つの例です。デモに進みましょう。Guardrailを設定して、CloudWatchで私のアプリケーションがどのように表示されるか見てみましょう。ここにGuardrailがありますが、新しいものを作成します。試しに脱税の方法を探ってみて、どうなるか見てみましょう。COP404-guardrailと名付けて、次のステップに進みます。多くの設定オプションがありますが、今回は特に不正行為に焦点を当てます。侮辱、憎悪、暴力などのオプションがありますが、不正行為だけに注目します。
強度は高めに設定します。このGuardrailを作成しましょう。では、コンソールで直接テストしてみます。税金対策やオフショア税金対策で税金を回避する方法を探ってみましょう。「オフショアの税金対策を設定して税金を回避する方法を教えてください」とプロンプトを入力します。ご覧の通り、システムが介入してブロックしました。理由は、高い強度と高い信頼度で不正行為を検出したためです。このGuardrailは効果的なようですね。バージョン1を作成します。コードの変更点としては、一時停止しますが、LangChainのコードでGuardrailsという新しいプロパティを追加しただけです。
このユニークな識別子を貼り付けてGuardrailを参照するだけで、自動的にこのGuardrailがChatbotに適用されます。IDを入力したら、アプリケーションを再度実行してみましょう。先ほどと同じように、オフショアの税金対策で税金を回避する方法について質問すると、同様の応答が返ってくるはずです。そして、Amazon Bedrock GuardrailsがCloudWatchに直接送信しているメトリクスを確認します。予想通り、このような行為は支援できないという応答が返ってきました。素晴らしいですね - Guardrailが機能しています。
CloudWatchに戻りましょう。メトリクスを見ると、Amazon Bedrock Guardrailsのセクションがあります。作成したGuardrailの特定のIDを入力します。これらのメトリクスのいくつかを選択してみましょう。基本的にどのように見えるか、お見せします。このメトリクスにはディメンショナルなバージョニングの側面があるので、バージョン1を見てみましょう。更新すると、呼び出しのレイテンシーと介入された呼び出しの数（1回のプロンプトしか行っていないので1回）に関する情報が表示されます。これらのメトリクスは、Amazon Bedrockでそれらのguardrailsを使用し始めるとすぐにCloudWatchに自動的に表示され、必要に応じてアラームを作成することができます。
ユーザーフィードバックの収集とObservabilityの総括
では、レイヤー4に戻って詳しく見ていきましょう。レイヤー4は、「いいね」や「よくないね」のようなエンドユーザーのフィードバックに焦点を当てています。これは、ユーザーがChatbotの動作についての情報を提供し始める際に人間が関与する部分です。CloudWatchには、あまり知られていないかもしれませんが、Embedded Metric Formatという強力な機能があります。これは、メトリクスも自動的に生成する構造化されたログのようなものと考えてください。これにより、メトリクスとログを相関させることができます - すべてのテレメトリーをログとして調整でき、これらの要素間の相関関係を維持しながらメトリクスを作成します。
この実装では、チャットボットにThumbsUpとThumbsDownの機能を追加します。これらのオプションを通じてユーザーからフィードバックを求め、感情値を1か0のような指標として追跡します。また、ユーザーは追加のコンテキストを提供できるテキストボックスも利用できます。チャットボット内で否定的なフィードバックが多すぎる場合に通知を受けられるようにアラームを設定します。CloudWatch Embedded Metric Formatの仕組みは、構造化されたロギングを通じて機能します。例えば、環境タグやプロダクション環境のチャットボットサービスを示すキーバリューペアを含むテレメトリがあります。また、モデルの応答が良好で正確だったことを示す感情値やテキストフィードバックなどのメトリクスも含まれます。これらのテレメトリはすべてCloudWatchにログとして入力され、その構造に基づいて、どの情報をメトリクスに変換すべきかを識別できます。
このプロセスをさらに簡単にするライブラリもあります。左のスクリーンショットを見ると、underscore awsヘッダーが確認できます - これはCloudWatchにメトリクスの場所と、適切なディメンションで抽出する方法を伝えるためにJSONログに含めるものです。最後のデモを見ていきましょう。セットアップの方法を説明します。
アプリケーションの左側にフィードバックセクションがあり、テキストボックスでフィードバックを入力できる他、ThumbsUpとThumbsDownのオプションがあることがわかります。これはCloudWatchとEmbedded Metric Formatを使用してセットアップしています。標準控除について質問してみましょう。応答は妥当そうなので、ThumbsUpを選択します。このフィードバックを送信して、CloudWatch内で確認してみましょう。
ここで一旦止めます。呼び出しロググループとは別の新しいロググループがあります。これは特にチャットボットのフィードバック用で、chat/chatbot/feedbackというラベルが付いています。このクエリを実行してみましょう。プロンプトを1回だけ実行したので、結果は1つだけ返ってきます。このログを見せると、同じAWSヘッダー - underscore aws のJSON構造が確認できます。これによってCloudWatchは抽出すべきメトリクスを認識し、メトリクスとログデータの相関付けが可能になります。
これが最初のステップで、すべてのテレメトリをログとして取り込み、CloudWatchにメトリクスの抽出方法を指示しました。ThumbsUpを1、ThumbsDownを0とする感情値メトリクスがあります。CloudWatch EMFが作成した対応するメトリクスを見てみましょう。ここに感情値メトリクスがあります。プロンプトを1回だけ実行したので小さな点が1つだけ見えますが、値が1であることがわかります。これを基にアラームを設定することができます。
それでは、アラームを作成して設定を行っていきましょう。90%か95%を下回った場合にアラートを出すように設定します。0.95に設定しますが、これは、否定的なフィードバックが増えて95%を下回った時点で、何か問題が発生したと考えてオペレーターにアラームを発報するという意味です。CloudWatchでこのタイプのアラームを設定する際は、必ず確認しておくべき重要な設定があります。追加設定のセクションまでスクロールしてください。
CloudWatchアラームには、ドロップダウンに隠れているため多くの人が知らないオプションがあります。それは「欠損データの扱い方」です。メトリクスにデータが入ってこない場合、それを良いと見なすべきか、悪いと見なすべきか、あるいは不十分と見なすべきかという設定です。このケースでは、データが存在しないことは実は良い状態を意味します。悪い状態とは、否定的なフィードバックがゼロになった場合だけです。したがって、このアラームにおいてはデータの欠損はOKなのです。このようなメトリクスベースのアラームを設定する場合、欠損データを「良好」として扱い、閾値を超えないようにすることが重要です。Thumbs upやThumbs downのデータが入ってこない場合は、すべて正常に動作していると考えて問題ありません。
次に進んで、通知を設定します。先ほど説明したようなアラームツリーを作成するために、一連の通知を設定することもできます。次へをクリックしてアラームを作成します。作成したアラームは「negative feedback」と名付けました。これは否定的なフィードバックが多すぎる場合にアラートを出すためのものです。ページを更新して一番最後まで見ていくと、緑の線が確認できます。しばらく待てば、きれいな緑の線が1本だけ表示されるはずです。否定的なフィードバックが増えてChatbotに不満を持つユーザーが増えてくると、この線が赤に変わってアラームが発報されます。そこから必要なワークロードをトリガーすることができます。
スライドに戻って、まとめに入りましょう。先ほどの4つのレイヤーに話を戻すと、まずAWSサービスが提供するメトリクスとログでエラーやレイテンシーを確認することから始めます。Bedrockの呼び出しログを設定することで、LLMの使用状況をより深く理解するための豊富なログデータが得られます。さらに拡張する際は、オーケストレーションレイヤーの可観測性を活用し、トレーシングの活用を本格的に検討し始めます。RAGアーキテクチャの構築を始めたら、これらの異なるコンポーネント間のやり取りを理解することが非常に重要になります。
Bedrock Guardrailsなどの高度な機能を使用する場合は、CloudWatchに送信されるメトリクスを理解し、それらを活用してGuardrailsの使用状況をより深く把握できるようにすることが重要です。最後に、エンドユーザーからのフィードバックを忘れないでください。これによって可観測性のループが完成します。最後に4つのリソースを紹介させていただきます。これらは先ほど説明した4つのレイヤーに対応しています。参考にしていただきたいブログ記事とドキュメントのシリーズです。
本日は Mandalay Bay までお越しいただき、月曜日のセッションにご参加いただき、ありがとうございました。質問がございましたら、こちらか廊下でお受けいたします。アンケートへのご協力もお忘れなくお願いいたします。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion