AIシステムをWebサービスのように監視するのをやめよう

多くのAIシステムは、隣接するWebサービスと同じ方法で監視されています。APIゲートウェイはアップタイム、エラー率、レイテンシのパーセンタイルを出力し、ダッシュボードはインフラとともに無料で提供されます。残念ながら、これらの数値は、ユーザーが最初のトークンが表示されるまで4秒間空白の画面を見つめていること、前回のプロンプト更新以降にタスクあたりのトークン消費が2倍になったこと、モデルが取得されたコンテキストからではなくその周辺で回答をでっち上げ始めたことを教えてくれません。

このギャップは、LLMシステムがWeb監視の前提を破るために存在します。応答はトークンごとに生成されるため、「レイテンシ」はタイムライン上の位置によって少なくとも3つの異なる数値になります。コストはリクエスト数ではなくトークン数に比例します。さらに、最も有害な障害は静かです。品質の低下は500エラーを投げず、200ステータスコードで自信満々のテキストを返します。

この記事では、メトリクスをそれらが答える質問でグループ化する方法を提案しています。5つの質問で本番環境で発生する問題のほとんどをカバーします。それは、速いか、スケールできるか、正しいか、信頼できるか、そしてエージェントがループ内にいる場合、どのように振る舞うかです。この記事では、各グループ、メトリクスの機械的な意味、そしてデフォルトでは何も出力しないため自分で構築しなければならないものについて詳しく説明します。

メトリクスマップ

質問に移る前に、来週木曜日にワークショップ「AIデモからデプロイされたアプリへ」を開催します。

AIエンジニアはバックエンドを構築できますが、実際のユーザーの前で使えるフロントエンドを用意する段階になると、ほとんどの人が止まってしまいます。

参加して学びましょう：

Streamlitプロトタイプやvibecodedフロントエンドアプリをv0に移植する方法

アプリをVercelで本番環境にデプロイする方法

既存のバックエンド上に新しいUI機能をデプロイする方法

登録はこちら

6月18日 15:00 GMT

速いか？（レイテンシ）

LLMリクエストには2つのフェーズがあり、それぞれ異なるレイテンシ数値を生成します。プリフィル中、モデルはプロンプト全体を処理し内部状態を構築しますが、ユーザーには何も見えません。デコード中、モデルは出力をトークンごとに生成します。追跡する価値のあるすべてのレイテンシメトリクスは、そのタイムライン上の位置です。

最初のトークンまでの時間（TTFT）は、リクエスト送信から最初のトークンが到着するまでの時間で、キューイング時間とプリフィル時間を合わせたものです。ストリーミングUIでは、これがユーザーが感じる数値（知覚レイテンシ）であり、ユーザーが空白の画面を見つめる正確な時間です。TTFTはプロンプトの長さに応じて増加するため、大きなコンテキストをプロンプトに詰め込むRAGシステムは、知覚速度の代償を払うことになります。

トークン間レイテンシ（ITL、出力トークンあたりの時間TPOTとも呼ばれる）は、ストリーミング開始後の連続するトークン間のギャップであり、出力が流れるようなテキストとして読めるかどうかを決定します。ユーザーは、高速でフリーズするものよりも、低速でも安定したストリームの方がはるかに許容できます。

p50、p95、p99でのエンドツーエンドレイテンシは完全なスパンであり、出力長が支配します。そのため、単一のグローバルパーセンタイルはほぼ無意味です。50トークンの分類呼び出しと2000トークンのレポート生成を平均化することになります。ユースケースごとにエンドツーエンドのレイテンシを追跡し、各数値が1つのワークロードに対応するようにします。

エージェントは複合効果をもたらします。複数のLLM呼び出しを連鎖させるタスクは、呼び出しごとの数値を増倍し、許容可能な呼び出しごとのp95が、許容できないタスクレベルのレイテンシになる可能性があります。エージェントワークロードの場合は、レイテンシ予算をタスクレベルで設定し、ステップを制約させます。

スケールできるか？（スループットとコスト）

ユーザーあたりの1秒あたりのトークン数対総システムスループット。サービングシステムは同じハードウェア上で同時リクエストをバッチ処理し、バッチサイズを調整できます。バッチを大きくすると総システムの1秒あたりのトークン数は向上しますが、個々のストリームは遅くなります。2つのメトリクスは同じGPU上でトレードオフの関係にあります。したがって、ワークロードごとにどちらを保護するかを決定します。インタラクティブチャットはユーザーあたりの速度を優先し、オフラインバッチ処理は総スループットを優先します。

リクエストあたりの入力トークン数と出力トークン数。これ以上付け加えることはほとんどありません。ユニットエコノミクスの核心であり、出力トークンは通常、入力トークンの倍数で価格設定されます。リクエストごとにログし、ユースケースごとに分類し、注意深く監視します。

キャッシュヒット率。プロンプトキャッシングにより、繰り返されるプロンプトプレフィックスの処理コストが劇的に低下します。これは、安定したシステムプロンプト、ツール定義、または共有ドキュメントコンテキストを持つシステムにおける最大の単一コストレバーの1つです。また、間違えやすいものでもあります。キャッシュはプロンプトプレフィックスをバイト単位で一致させるため、プロンプトの先頭付近に挿入されたタイムスタンプや、並べ替えられたツールリストはキャッシュを無効にします。キャッシュヒット率の低下を監視します。これは、誰かがプロンプトの組み立て方法を変更したことを示す可能性があります。

タスク成功あたりのコスト。リクエストあたりのコストではありません。リクエストあたりのコストは、安価に失敗するシステムを良く見せます。コストが3分の1で成功確率が半分のリクエストは、実際にはより高価であり、失敗した試行は再試行を引き起こし、目に見えない形で支出を倍増させます。これはまた、5つのグループすべてをつなぐメトリクスです。レイテンシ、コスト、品質を個別に押し上げることができますが、タスク成功あたりのコストは、システム全体が良くなったか悪くなったかを示す数値です。

正しいか？（品質）

サービングスタック内の何も正しさを出力しません。このグループのすべてのメトリクスは自分で構築します。

ラベル付き評価セットでのタスク成功率。数十から数百の既知の正しい結果を持つ例を用意し、プロンプトの変更、モデルのアップグレード、検索の変更ごとに再実行します。これはAIシステムの回帰テストスイートです。セットは大きくなくても有用ですが、代表性があり、維持される必要があります。

RAGのグラウンディング。回答は検索されたコンテキストによってサポートされているか、それともその周辺ででっち上げられているか？システムは優れた検索を持っていても、検索されたものと書かれたものの間で幻覚を見ることがあります。強力なモデルを使えばこの問題は減りますが、実際の本番システムでは、コスト削減のために最終的に可能な限り小さなモデルを使用することになります。

検索精度と再現率@k。k個のチャンクが検索されたうち、精度@kは実際に関連するものがいくつあったかを尋ねます。再現率@kは、最初のk個の中に関連する資料がどれだけ含まれていたかを尋ねます。生成は検索が表面化しなかったものを修正できないため、回答品質が低下した場合は、プロンプトを書き換える前に検索メトリクスを確認します。検索は依然としてAIシステムにおいてより難しい問題です。

LLM-as-Judgeスコアの経時変化。人間のラベルに対して較正されます。ジャッジは品質を大量に測定可能にしますが、ドリフトします。ジャッジモデルのアップグレードは、テスト対象のシステムに変更がなくてもスコアを変える可能性があります。最初に人間ラベルのサンプルで較正し、ジャッジモデルが変更されたときやスコアの傾向が良すぎるときに再較正します。

ユーザーフィードバックシグナル。明示的な評価は稀であり、極端に偏っています。再生成率と、ユーザーが生成された出力を受け入れる前に編集する程度は、より頻繁で正直です。なぜなら、ユーザーが出力に対して行動した瞬間に記録されるからです。

信頼できるか？（信頼性）

プロバイダーごとのエラー率、タイムアウト率、レート制限率。プロバイダーごとの分割が重要です。なぜなら、集約された可用性はどの依存関係が劣化しているかを隠し、特にレート制限は特定のプロバイダーのクォータに関連してバースト的に到着する傾向があるからです。

再試行とフォールバック率。バックアップモデルへのフォールバックは可用性をグリーンに保つ一方で、品質は静かに変化します。サービングパスごとに品質メトリクスを追跡します。

ガードレールトリガー率と拒否率。これらの急上昇は、ユーザーの行動の変化、インジェクション試行の可能性、またはモデル変更による拒否境界の移動を意味します。いずれにせよ、追跡する価値があり、ガードレールアクションが適切にログ記録されればコストは低く抑えられます。

エージェントはどのように振る舞うか？（エージェントメトリクス）

エージェントは、単一のLLM呼び出しでは起こらない方法で失敗します。モデルが一連の決定を行い、それぞれが静かに劣化する可能性があるためです。

ツール呼び出しエラー率。原因別に分割します。スキーマと引数のエラーはモデルがツールを誤解していることを意味し、修正はツールの説明にあります。実行エラーはツール自体が壊れていることを意味し、修正はコードにあります。

完了したタスクあたりのステップ数とトークン数。成功率が安定しているのにタスクあたりのステップ数が増加している場合は、正確性は変わらずにコストが上昇していることを意味します。モデル交換やプロンプト変更のたびにこれを監視します。

コンテキストウィンドウ使用率。圧縮と切り捨ての問題に対する早期警告。品質は通常、コンテキストが満たされると低下するため、使用率の傾向は、障害がまだユーザーに気づかれないうちに介入するよう指示します。

ループ検出。エージェントが同一のツール呼び出しを同一の引数で繰り返す割合。ループは純粋なトークンの浪費であり、軌跡ログから数行のコードで検出可能です。

計装のギャップ

5つのグループを振り返ると、パターンが明確です。レイテンシと信頼性は初日から現れます。なぜなら、ゲートウェイ、ロードバランサー、プロバイダーSDKがトラフィックサービスの副産物としてこれらを出力するからです。品質、タスクあたりのコスト、エージェント動作メトリクスは、それらを測定するパイプライン（すべての応答からログ記録されるトークンとキャッシュフィールド、すべての変更で実行される評価セット、較正されたジャッジ、エージェントの軌跡ログ）を構築するまで生成されません。

これが、徹底的な監視と本当の死角が共存する理由でもあります。監視はインフラが報告する次元をカバーし、障害はそれが報告しない次元に存在します。結果として、予算編成に問題が生じます。品質とタスクあたりのコストのための計装は、後のレビューではなく、AI機能の初期構築見積もりに含めるべきです。

どこから始めるか

すべての対策を一度に実装しようとして開発を遅らせるべきではありません。情報密度の高い順序は次のとおりです。

TTFTとエンドツーエンドのレイテンシ。ユースケースごとに。ストリーミングする場合、TTFTはユーザーの知覚レイテンシであり、両方とも既存のタイムスタンプから得られます。

リクエストあたりのトークン数とキャッシュヒット率。両方ともAPI応答のフィールドであり、ログ記録は簡単で、ユニットエコノミクスがすぐに明確になります。

タスク成功率を含むラベル付き評価セット。50の例から始め、関連する変更ごとに再実行する規律を持ちます。

プロバイダーごとのエラー率とフォールバック率。追加は安価で、フォールバックと品質の相互作用は一般的な静かな劣化です。

エージェントメトリクス。エージェントを出荷するとき。原因別のツール呼び出しエラー、タスクあたりのステップ数、コンテキストウィンドウ使用率はすべて軌跡ログにあります。

このリストは代表的であり、網羅的ではありません。GPUレベルのサービングメトリクス（KVキャッシュ使用率、バッチ占有量）は、自分で推論をホストする場合に重要であり、別の記事でカバー予定です。また、埋め込みとデータドリフト、およびビジネスレイヤーメトリクス（封じ込め率やセッションあたりの収益など）は意図的に省略されています。

まとめ

メトリクスを、それらが答える質問でグループ化します。速いか、スケールできるか、正しいか、信頼できるか、エージェントはどう振る舞うか。

レイテンシをリクエストタイムライン上の位置として追跡します。TTFTは知覚速度用。

タスク成功あたりのコストは、すべてのメトリクスをつなぐ単一の数値です。

品質メトリクスは自分で構築する必要があります。デフォルトでは生成されません。

エージェントメトリクスは、ステップ、ツール呼び出し、ループを追跡する必要があります。

TTFTとレイテンシから始め、徐々にコスト、品質、エージェントメトリクスを追加します。