使い方・開発 上級

LLMオブザーバビリティ

Observability

LLMアプリの内部で何が起きたかを、入力・出力・途中の処理・費用・遅延などの記録から後で追えるようにする仕組みです。不具合の原因究明や品質改善に欠かせません。運用では必須の考え方です。

別の呼び方オブザーバビリティ、LLM監視、トレーシング

例回答がおかしい報告を受け、トレースで検索結果とプロンプトを確認して原因を特定した。

詳しく

LLMオブザーバビリティ(可観測性)とは、LLMを使ったアプリケーションが本番で動いている間の様子を記録・可視化し、内部で何が起きたかを後から確認できるようにすることです。もともとはシステム運用の用語で、外から観測できる情報から内部の状態を推し量れる度合いを意味します。

なぜLLMアプリに必要か

LLMアプリは、1つの質問に対して内部で多くのことをします。たとえばRAGなら、質問の書き換え、検索、リランキング、プロンプトの組み立て、生成、後処理といった段階があり、エージェントなら、さらにツールの呼び出しを何度も繰り返します。最終的な回答がおかしいとき、どの段階が原因なのかを、出力だけから判断するのは困難です。

また、LLMの出力は毎回変わるため、「手元では再現しない」ことがよくあります。本番で起きた事象を後から再現するには、そのときの入力と途中経過の記録が必要です。

何を記録するのか

  • トレース:1回のリクエストが通った処理の流れを、段階ごとの入出力とともに、階層構造で残したもの。エージェントの「考え→ツール呼び出し→結果→次の判断」の連鎖を追えます。
  • プロンプトと応答:実際にモデルへ送った全文と、返ってきた内容。
  • メタ情報:使ったモデル名、設定値(temperatureなど)、バージョン。
  • 性能の指標:遅延(latency)、エラー率、レート制限への到達状況。
  • コスト:入力・出力のトークン数と、それをもとにした費用。ユーザー別・機能別に集計すると、無駄が見つかります。
  • 品質の評価:利用者の高評価・低評価、自動採点の結果。

具体例

社内ヘルプボットで、「経費の上限額を間違えて答えた」という報告が上がったとします。トレースを見ると、検索の段階で古い規程が上位に出ており、生成モデルはそれを忠実に要約していただけだった、と分かります。原因が検索側のデータ更新漏れだと特定でき、モデルやプロンプトをいじる無駄な試行を避けられます。

使うときの注意

  • 個人情報・機密情報の扱いに注意します。 入出力をそのまま保存すると、個人情報が含まれます。マスキング、保存期間の設定、アクセス権の管理を設計しましょう。
  • 記録量と費用のバランスを取ります。 全件を詳細に保存すると、保管費用が膨らみます。重要な機能だけ詳細に残す、サンプリングするなどの工夫があります。
  • 記録は見るためのものです。 溜めるだけで確認しなければ意味がありません。異常を知らせる通知や、定期的な見直しの習慣とセットにします。
  • ツールは多数あります。 OpenTelemetryのような標準的な仕組みに対応したものを選ぶと、乗り換えや既存の監視との統合がしやすくなります。

関連する考え方

観測した結果をもとに品質を測る仕組みがevalsで、運用全体の枠組みがLLMOpsです。エージェントでは、ツール呼び出しの履歴が特に重要になります。

あわせて知りたい言葉

「使い方・開発」の言葉をすべて見る