LLM オブザーバビリティ：トレース、指標、欠けている根拠

執筆：Ai Flowi · 公開日 2026-10-11

LLM オブザーバビリティは、言語モデルへのリクエスト中に何が起きたかを説明するため、実行の記録を収集する取り組みです。ログはイベントを記述し、指標は測定値を集約し、トレースは同じリクエストの各段階を結び付けます。評価は回答の品質に関する判断を加えます。実行ステータスが成功であるだけでは、回答に裏付けがあるとは判断できません。

4種類の根拠と、それぞれが答える問い

これらの根拠は関連付けられますが、互いに置き換えられるものではありません。エラーカウンターは増加を示せても、原因となった入力を特定できないことがあります。トレースは検索の失敗箇所を特定できても、最終回答が事実として正しいかは判断できません。品質基準と、通信やノードのステータスは分けて扱います。

観測の記録仕様を定義する

複数の段階を持つリクエストでは、外部で収集する観測レコードの設計案として、親リクエストID、スパンID、親スパンID、処理段階、入力バージョン、ステータス、個別に測定した開始時刻と終了時刻を含められます。任意項目として、評価基準とそのバージョンを伴う品質評価の結果を追加します。欠損値を、問題がないように見せる既定値で埋めるのではなく、時間測定や評価が存在するかどうかを記録します。

リクエストIDは、1件のリクエストに属する段階を結び付けます。スパンIDは、ある段階の1回の試行を識別し、親スパンIDは、その段階を含む上位の段階との関係を記録します。入力バージョンは、すべてのログに全文を保存せずに、確認済みのプロンプトや情報源のスナップショットを識別するためのものです。新規リクエストと再試行を区別します。

これはアプリケーションのスキーマの設計案であり、AI Flowi Workflowが出力するフィールドについて述べたものではありません。コンポーネントカタログからは、自動トレース収集機能があるとは確認できません。durationという名前のフィールドであっても、実際の測定元が必要です。

関連情報：データ品質 指標：不明な事実を推測せずに欠陥を測る。

2種類の失敗を含む架空のトレース

仮想的な外部トレースです。AI Flowiから出力されたログでも、記録されたテストでもありません。この例では、すべての段階の親リクエストIDはrequest_demoです。数値は、同じ時計の起点からの経過ミリ秒として作った架空の値です。本番環境のレイテンシを示しているわけではありません。

検索段階のレイテンシは、終了時刻の測定値が欠けているため不明です。回答段階には、例として50ミリ秒の測定区間がありますが、それだけでは検索の所要時間やリクエスト全体のレイテンシを再現できません。回答の開始時刻から検索の開始時刻を引くと、各段階が連続し、すべて観測されていると誤って仮定してしまいます。

根拠のない回答は、検索エラーとは別の失敗です。生成処理は正常に応答しましたが、品質レビューでは回答に根拠がないと判明しました。トレースからは、必要な検索コンテキストがないまま生成段階が進んだのか、という調査すべき問いが浮かびます。しかし、検索結果の欠落が、根拠のない主張の原因だったと証明するものではありません。

指標に分母と集計期間が必要なのはなぜですか？

成功率の集計単位が、完了したリクエスト、モデル呼び出し、スパン、記録された課金のどれなのかを定義します。再試行では、ユーザーのリクエスト数が増えなくても、呼び出し回数が増えることがあります。観測期間より前に始まったリクエストや、期間終了後に終わったリクエストが集計から漏れる場合もあります。各指標とともに、単位と集計期間のルールを保持します。

レイテンシの集計には、互換性のある有効な開始・終了測定値を持つレコードだけを含め、除外された対象や測定値が欠けた対象も報告します。所要時間の欠落は不明を意味し、ゼロではありません。起点が異なる時計のタイムスタンプを平均しないでください。1つのプロセス内の区間では、単調増加時計を使うことで、実時間時計の補正を作業の経過時間と取り違えずに済みます。

モデルのトークン使用量とワークフローノードの課金にも、別々の単位が必要です。トークン使用量の欠落は、プロンプトの単語数を数えても補えません。それぞれの測定元を記録し、推定値には推定であると明記します。

AI Flowi WorkflowのUsageページで確認できること

ワークフローの使用量とトークン履歴のガイドでは、課金レコードを説明しています。そこには所要時間の記録がないため、提案したトレースでは時間情報を別途収集する必要があります。

request_demoでは、検索の終了時刻が未測定なのか、収集中に失われたのか、まだ届いていないのかを、まず確認します。それぞれ必要な修正が異なります。調査用スナップショットとともに収集の締め切り時点を保存し、遅れてイベントが届いたら更新します。その時点でイベントがないことは、根拠に欠落があることを示すだけで、検索段階の完了やキャンセルを示すものではありません。

評価とJSONコンポーネント

LangWatch連携リファレンスには、この例で回答段階の評価に使う、評価器へのリクエスト仕様が記載されています。

別途用意した観測フィールドをレコードにまとめる際は、JSON Object Builderリファレンスに従ってください。

設定例です。記録されたテストではありません。

ご自身のLangWatchアカウント/APIキーと、別途課金されるプロバイダーへのアクセスを用意し、品質基準に適した、利用可能なLangWatch Evaluatorのevaluator_nameを選択します。inputには許可されたrequest_demoの質問を、outputには保存してある回答を設定します。評価でcontextsを使用する場合は、その生成の試行時に実際に利用できた根拠を渡します。後から追加した参考資料は、異なる評価条件として記録します。

別途提案するレコード組み立ての段階では、JSON Object Builderのfield_namesを、リクエストの参照、スパンの参照、評価器のバージョン、評価結果に合わせて設定します。生成されたフィールドと出力の構造を確認してから、結果を接続します。相関IDは外部システムの設計に基づいて渡すものです。このカタログで説明する評価器は、トレースIDを出力しません。この観測レコード設定案について、LangWatch EvaluatorとJSON Object Builderはカタログに記載されていますが、Ai Flowiによる本番環境でのテストは行われていません。評価器とレコード組み立てを組み合わせた設定も未テストです。

評価はrequest_demoだけに結び付けるのではなく、回答の試行に結び付けます。そのリクエストで生成を2回試みた場合、親IDだけで結合すると、最初の回答の評価が、その置き換え後の回答に結び付くことがあります。正確な回答バージョンと評価時刻を、スパンの参照とともに保持します。後の評価が成功しても、先に判明した根拠のない回答という所見を上書きしたり、検索が成功したと示唆したりしてはいけません。

関連情報：AIOps とは：アラートの相関分析とその限界。

記録する内容を最小限に抑え、欠けている根拠を調べる

各スパンにプロンプトの全文をコピーするのではなく、評価対象の回答の情報源を参照できるようにし、アクセス制御を設けます。根拠の一部をマスキングした場合は、許可されたサンプルがどの情報源バージョンを表すか、また内容が非開示であることを記録します。request_demoでは、調査担当者が検索内容を確認できなければ、回答がそれを無視したかどうかを確定できません。その診断上の限界を、品質に関する所見とともに保持します。認証情報を観測ペイロードに含めてはいけません。

失敗したリクエストでは、どの段階の観測記録が存在するか、どの測定値が欠けているか、回答について別途レビュー済みの品質評価結果があるかを確認します。評価がないことを、評価に合格したこととして扱わないでください。手順の実施記録は記録されたユースケースを、根拠のない出力に関する用語はLLMのハルシネーションをご覧ください。