LLMアプリのSLOとは？速さ・成功・品質を一つの稼働率に混ぜない
LLM APIがHTTP 200を返していても、回答が空、根拠が違う、道具を誤る、数十秒待たされるなら、利用者にとって正常とは言いにくい。LLMアプリの信頼性は、サーバーが動いている割合だけでは測れない。
SLOは、利用者に提供したいサービス水準を、測定方法と期間を含めて定めた目標である。LLMアプリでは、可用性、遅延、業務上の成功、回答品質、安全性を別の指標として定義し、どれか一つの平均へ押し込まないことが重要になる。
SLI、SLO、SLAを分ける
Google SREは、SLIを提供したサービス水準の一側面を表す定量的な指標、SLOをそのSLIの目標値または目標範囲として説明している。SLAは、未達時の結果を含む外部との合意として使われることが多い。
例えば、回答画面を持つサービスでは次のように分けられる。
- SLI: 対象要求のうち、10秒以内に利用可能な回答を返した割合
- SLO: 28日間で、その割合を99%以上にする
- SLA: 契約上の約束と、未達時の補償や対応
社内の運用目標をすべてSLAと呼ぶと、技術目標と契約責任が混ざる。まず利用者体験を測るSLIと、その目標であるSLOを決める。
監視できる値からではなく利用者の期待から始める
モデルAPIの状態コード、トークン数、GPU利用率は測りやすい。しかし、利用者が欲しいのはHTTP 200ではなく、期限内に役立つ結果を得ることである。
先に機能ごとの利用者体験を書く。
- 問い合わせ回答なら、質問を受け付け、根拠に沿う回答を待てる時間内に返す
- 文書抽出なら、必須項目をSchemaどおりに取り出し、後続システムへ一度だけ保存する
- 操作エージェントなら、許可された道具だけを使い、意図した変更を重複なく完了する
- バッチ評価なら、期限までに全対象の結果または明確な失敗理由を返す
その後で、実際に計測できる代理指標へ落とす。測れるから選んだ指標ではなく、利用者が困る失敗を捉える指標にする。
一つの成功率へ全部を混ぜない
「成功」を、通信成功、形式成功、業務成功、品質合格のどれにするかで数字は変わる。一つの割合だけを出すと、どこが壊れているか判断できない。
LLMアプリでは、少なくとも次のSLIを分ける。
可用性
対象要求のうち、サービスが受け付けて最終状態を返した割合である。タイムアウト、未処理、内部エラーを失敗に含める。利用者の入力不備や権限不足を分母へ含めるかは、先に規則を決める。
遅延
対象要求のうち、定めた時間内に結果を返した割合である。ストリーミングでは、最初の意味ある表示と最終完了を別に測る。平均時間だけでは少数の極端な遅延が隠れるため、しきい値以内の良好イベント率や上位百分位を見る。
業務上の成功
HTTP応答ではなく、利用者の目的が達成された割合である。抽出結果の保存、予約の確定、必要な根拠の提示など、機能ごとに完了条件を定める。
品質
評価対象のうち、固定した採点基準に合格した割合である。RAGなら根拠との一致、抽出なら項目単位の正確性、エージェントなら道具選択と最終状態を測る。
安全性
禁止された情報開示、無許可の操作、重大なポリシー違反が起きなかった割合である。重大事故は件数が少なくても影響が大きいため、通常の品質平均に埋めず、独立した上限や即時停止条件を持つ。
分母となる対象要求を先に固定する
SLOは分子だけでなく分母の定義で変わる。試験アクセス、監視用の合成要求、利用者が途中で取り消した要求、入力不備、提供者障害、再試行をどう数えるかを明記する。
再試行を別の成功要求として数えると、失敗した一つの利用者操作が複数件になり、成功率を歪める。利用者の一つの仕事に作業IDを付け、最終結果を一件として数える方法がある。
除外条件を障害のたびに追加してはいけない。計測開始前に対象と除外を文書化し、変更には版と適用日を付ける。
品質は遅れて分かる
可用性や遅延は要求直後に測れるが、回答品質は正解ラベル、人の確認、利用者の再問い合わせ、後続業務の結果がそろうまで分からない場合がある。
そこで、速い指標と遅い指標を分ける。
- 即時: 状態コード、完了状態、形式検証、道具エラー、遅延
- 数時間から数日後: 自動評価、抽出値の照合、根拠一致
- さらに後: 利用者の解決率、修正率、業務成果、人の監査
即時のSLOを満たしていても、後から品質SLOが悪化することがある。運用画面では確定済みの期間と、品質ラベルがまだ集まっていない期間を区別する。未採点を合格扱いしない。
オンライン代理指標だけを品質と呼ばない
JSON Schemaに通った、拒否がなかった、引用が付いたという事実は、内容の正しさを保証しない。これらは壊れた出力を早く見つける代理指標として有用だが、品質評価の代わりではない。
オンラインでは形式、空回答、根拠の存在、道具結果との矛盾などを監視し、別途サンプルを評価データセットで採点する。人の判断が必要な機能では、無作為な標本と重大例の重点監査を組み合わせる。
評価モデルを使う場合は、採点プロンプトとモデル版もSLOの測定系に含める。採点器を変更した日を境に、品質率が上がっても本体が改善したとは限らない。
全体値と重要なスライスを両方見る
全体のSLOが達成されていても、長文入力、特定言語、画像付き要求、ある顧客、特定の道具だけが継続して失敗する場合がある。
機能、入力形式、顧客区分、言語、モデル、構成版など、利用者体験が変わる軸で分けて見る。ただし、データが少ない区分に毎回厳密な判定を出すと偶然の変動へ反応しすぎる。
重大な利用者群には独立したSLOを置き、それ以外は監視スライスとして傾向を見る。個人情報や本文を指標ラベルへ入れず、安全な区分IDを使う。
SLOを100%にしない理由
すべての要求を常に完全に処理する目標は魅力的だが、現実の分散システムでは達成困難である。100%を掲げると、小さな変更にも過剰な手続きが必要になり、実際には守れない暗黙の目標になる。
Google SREは、まず現実的な目標から始め、必要に応じて厳しくする考え方を示している。利用者が必要とする水準、現在の実績、改善費用、失敗時の影響から目標を決める。
安全性では、重大な無許可操作の許容目標をゼロに近付ける必要がある。しかし、観測漏れや分類誤りがあり得るため、「事故が0件だった」だけで安全を証明したと考えない。レッドチーミング、承認、権限制限と組み合わせる。
エラーバジェットを変更判断へ使う
SLOが99%なら、測定期間の1%が目標上許容された不良イベントになる。この余地をエラーバジェットとして扱う。
目的は失敗を正当化することではなく、機能追加と信頼性改善の優先順位を共通の数字で決めることである。バジェットを急速に消費しているなら、新しいモデルやプロンプトの展開を止め、原因調査と回帰評価を優先する。余裕があるなら、限定公開や実験に使える。
バジェットを使い切ったときの行動を先に決める。
- 自動展開を停止する
- 高リスク機能を縮退する
- 直近の構成へ戻す
- 失敗が多い入力区分を限定する
- 回帰評価と原因修正を公開条件にする
単に赤いダッシュボードを出すだけでは、SLOは意思決定に使われないKPIになる。
複数のSLOを相殺しない
速いが間違った回答と、正しいが期限後の回答を平均して「総合点は良好」としてはいけない。品質、遅延、可用性、安全性には、それぞれ最低条件を置く。
変更の比較では、品質SLOを満たす構成の中で遅延と費用を下げる。費用を削減するために品質を落とすなら、利用者と関係者が新しい目標を明示的に承認する必要がある。
一方、すべての指標へ厳しい目標を増やすと、運用が判断不能になる。利用者体験に直結し、未達時の行動が決まっている少数のSLOから始める。
計測地点による差を理解する
サーバー側のログだけでは、利用者の端末からバックエンドへ届かなかった要求や、画面描画の遅れを見落とす。ブラウザ、アプリの入口、モデルAPI、道具、保存先で測る時間は異なる。
例えば、モデルAPIが2秒で完了しても、検索、待ち行列、ストリームのバッファリング、画面更新を含めて利用者には8秒かかる場合がある。SLOの仕様には「どこからどこまで」を書く。
計測系自体が停止した場合も考える。データ欠落を成功にも失敗にも自動で寄せず、欠測率を別に監視する。欠測が多い期間に精密なSLO達成率を断定しない。
最初のSLO文書に必要な項目
初版は短くてよいが、次を一つの文書に残す。
- 対象の機能と利用者体験
- SLIの分子、分母、しきい値
- 計測地点、データ源、集計期間
- 対象と除外の規則
- 遅れて確定するラベルの扱い
- 全体と重要スライスの見方
- SLO値と選んだ根拠
- エラーバジェット消費時の行動
- 所有者、承認者、見直し日
まず過去の実績へ仮の定義を当て、失敗例を読んで指標が利用者の不満を捉えているか確認する。目標値を先に固定し、都合のよい計測方法を後から選ばない。
LLMアプリのSLOは、モデルAPIの稼働率へ目標値を付けるだけではない。利用者の一つの仕事を単位にし、速さ、完了、品質、安全性を別々に測り、未達時の行動まで決める仕組みである。測定しやすい値ではなく利用者が困る失敗から始めれば、信頼性改善と新機能のどちらを優先するかを同じ基準で判断できる。