Next'25 速報 - 生成 AI アプリケーションにおける SRE
はじめに
現在ラスベガスで開催されている Google Cloud の旗艦イベント「Google Cloud Next'25（以下、Next'25）」に現地参加中の kazz / Shanks / 小堀内 / 岸本 です。
Google Cloud Next'25 で発表された 最新情報 を現地からお届けしています。
本記事では、Next'25 のセッション「SRE for gen AI workloads: Are you ready?」の内容に基づき、生成 AI アプリケーションにおける SRE の考え方について解説します。
セッションの主要ポイント
従来の SRE 指標の限界
CPU 使用率や単純なエラーレートだけでは、生成 AI アプリケーションの真の健全性やユーザー体験を把握できません。
なぜなら、ハルシネーションや不適切な回答など、従来にはなかったエラーが発生する上に、レスポンスの一貫性もありません。
新たな監視対象の必要性
生成 AI アプリケーションにおいては、以下の指標を監視する必要があります。
- LLM のコスト (API 呼び出し数、トークン数)
- レート制限
- 応答の安全性 (Safety) や適切性 (Appropriateness)
- ユーザー満足度
ユーザー体験の重視
生成 AI システムにおいては、ユーザーがポジティブな体験を得られているかどうかが重要な指標となります。
感情分析や直接的なフィードバック収集が鍵となります。セッションでは、ユーザーの入力を感情分析し、ユーザーの発言から感情 (肯定的/否定的/中立) を分析・測定する方法が紹介されていました。
生成 AI アプリケーションにおける SRE の新たな課題
従来の SRE プラクティスでは、CPU 使用率、メモリ使用量、リクエストレイテンシ、エラーレートといった「4つのゴールデンシグナル」が重視されてきました。しかし、生成 AI アプリケーションでは、これらの指標だけでは不十分です。
なぜなら、生成 AI アプリケーションは、以下のような特徴があるためです。
- 非決定性: 同じ入力に対しても、LLM は異なる応答を返す可能性があります。これにより、従来のエラー検知や性能測定が困難になります。
- コスト: LLM の API 呼び出しやトークン消費は、予期せぬ高コストにつながる可能性があります。特に、ユーザー入力や LLM の応答が長大な場合や、内部的に複数の LLM 呼び出しが発生する場合に注意が必要です。
- 新たなエラータイプ: ハルシネーション (もっともらしい嘘)、不適切な応答、有害なコンテンツの生成など、従来にはなかった種類のエラーが発生し得ます。これらはビジネスの評判リスクに直結します。
- ユーザー満足度の測定: 応答が技術的に正しくても、ユーザーが満足しているとは限りません。ユーザーの感情や意図を汲み取り、満足度を測定する仕組みが必要です。
- 多段パイプラインのレイテンシ: 生成 AI アプリケーションは、複数の LLM 呼び出しやデータ処理ステップからなる複雑なパイプラインを持つことが多く、全体のレイテンシ管理が重要になります。
生成 AI 向け SRE 指標と監視戦略
これらの課題に対応するため、SRE は以下の監視対象を追加する必要があります。
コストとリソース消費
- API 呼び出し数: LLM ベンダーへの API 呼び出し回数を監視します。
- トークン数: 入力トークンと出力トークンの数を追跡し、コストやモデルの制限に影響を与える要因を把握します。
- レート制限: サードパーティ API のレート制限に達していないか監視します。これは、4 つのゴールデンシグナルの「飽和度 (Saturation)」を 生成 AI の文脈で捉え直したものと言えます。
応答品質と安全性
- 安全性違反率 (Safety Issues Rate): 有害または危険なコンテンツに関連するクエリや応答の割合を追跡します。
- 不適切クエリ率 (Inappropriate Queries Rate): アプリケーションの目的外のクエリ (例: 映画ボットに天気を聞く) の割合を追跡します。
- グラウンディング/忠実性 (Grounding/Faithfulness): 提供された知識ベースや指示に基づいて応答が生成されているか (事実に基づいているか) を評価します (例: 架空の映画データベースに実在の俳優の情報がないか)。
- 関連性 (Relevance): ユーザーの質問に対して応答が関連しているかを評価します。
ユーザー体験
- ユーザー感情分析 (Sentiment Analysis): 別のLLMを評価者（ジャッジ）として利用し、ユーザーの発言から感情 (肯定的/否定的/中立) を分析・測定します。
- ユーザーエンゲージメント: 会話が継続しているか、ユーザーが積極的に対話しているかを評価します。
- 明示的なフィードバック: サムズアップ/サムズダウンボタンなどを設置し、ユーザーからの直接的な評価を収集します。
- タスク成功率/受け入れ率 (Acceptance Rate): ユーザーがボットの提案を受け入れたかどうか (例: 映画の推薦を視聴リストに追加したか) を追跡します。
これらの指標に対して SLI と SLO を設定し、エラーバジェットを管理することが、生成 AI アプリケーションの SRE においては重要です。
また、複数の SLI を組み合わせて、より包括的な目標を定義することで、全体の健全性をより正確に評価できます。
Firebase Genkit と Google Cloud Observability による実現
セッションでは、Firebase Genkit の Monitoring と Evaluate、Google Cloud Observability を駆使し、Genkit で構築された AI アプリケーション における SRE の実践方法が紹介されました。
Genkit Monitoring はOpenTelemetryに基づき、LLMとのやり取りをトレースすることができます。また、LLMジャッジ機能で感情分析や品質評価も可能です。
Genkit Evaluate は、データセットや会話ログを使って応答品質を評価し、CI/CDに組み込むことでリグレッションを防ぎます。
Google Cloud Observability は、Genkit のデータを使ってダッシュボードを作成し、生成AIの指標を可視化します。
これらを組み合わせることで、開発者は Genkit でトレースを確認し、SRE は Cloud Observability で全体を監視できます。
おわりに
生成 AI アプリケーションの SRE は、LLM 特有の課題に対応する必要があります。コスト、応答品質、安全性、そして何よりもユーザー体験の測定が重要になることがわかりました。
ユーザー体験の測定というのは、アプリケーションが何のために存在するかを考えたときに、とても重要です。
この考え方は、生成 AI に限らず様々な場面で応用できるなと感じました。
Discussion