本文へ移動
Telemetry
ドキュメントを見る

ガイド更新日: 2026年9月29日5 最小読み取り時間

コーディング エージェントでこのドキュメントを使用してください

Claude Code、Codex、Cursor、または別のコーディング エージェント用の集中プロンプト パックを開き、それをここで説明するワークフローに適応させます。

このページの内容
  1. 最初に評価単位を定義します
  2. 個別の実行、要求、評価イベント
  3. いくつかの種類の証拠を使用する
  4. レビューされた結果イベントを発行する
  5. リリースごとに品質を比較する
  6. 受け入れられた結果ごとのコストを計算する
  7. 回帰ゲートを構築する
  8. 専用の評価プラットフォームを保持する場合

構造化イベントと SQL を使用して AI エージェントを評価する

エージェントの実行が終了しても、タスクを達成できたとは限りません。実行、分析に必要なモデルやツールの呼び出し、評価結果を別々のイベントとして記録します。SQL でリリースごとの品質、コスト、レイテンシー、再試行、人への引き継ぎを比較できます。モデルが生成したスコアは、他の証拠と照合してから正しいかどうかを判断してください。

Telemetry は、このワークフローの分析レイヤーです。スコアラーの実行、プロンプト バージョンの管理、評価データセットの管理、プロンプトと完了のリプレイの提供は行いません。これらのワークフローをアプリケーションまたは専用の評価システムに保持し、集計分析に必要な承認済みの結果フィールドを送信します。

operation_id はリリースをまたいで一意にします。

最初に評価単位を定義します

「スコアを受け取ったものは何ですか?」と答える行を選択してください。指標を選択する前に。一般的な単位には次のものがあります。

  • ユーザーに示される最後の答え。
  • 1 回の完了したエージェントの実行。
  • 解決済みのサポート ケース 1 件。
  • ツール選択の決定が 1 つあります。
  • 凍結された例に対して 1 つの回答が得られました。
  • 1 つのビジネス操作に複数のエージェントの試行が含まれる場合があります。

そのユニットに次のような安定した識別子を与えます。 operation_id。別の識別子を使用する run_id, response_id、そして evaluation_id。再試行では 1 つの操作に対して複数の実行が作成され、1 つの出力が複数の評価を受ける可能性があります。すべてのグレインに対して単一の識別子を再利用すると、不正確な結合が発生し、コストが二重にカウントされます。

個別の実行、要求、評価イベント

実際の開始コントラクトでは、3 つまたは 4 つのイベント テーブルを使用します。

イベント 穀物 役立つ分野
agent_run_completed 1 つのターミナル エージェントの実行 operation_id, run_id, workflow, status, duration_ms, tool_call_count, human_handoff, prompt_version, release
llm_request_completed 1 つのプロバイダー リクエスト operation_id, run_id, response_id, provider, model, input_tokens, output_tokens, estimated_cost_usd, latency_ms
agent_tool_completed 1 つのツールの試行 run_id, tool_call_id, tool_name, status, duration_ms, retry_count, error_type
ai_output_reviewed 1 人の評価者の結果 operation_id, evaluation_id, evaluator_type, evaluator_version, metric_name, score, passed, review_outcome, is_final, dataset_version, release

4 つの穀物すべてを無理に 1 つの幅の広い列に並べないでください。 5 回のツールの試行と 2 回の評価を伴う実行では、結合時のコストや成功数が倍増します。

いくつかの種類の証拠を使用する

すべてのエージェント ワークフローに単一の評価者だけでは十分ではありません。実際の決定に対応する信号のみを結合します。

  1. 決定論的チェック スキーマ、必要な引用、許可されたツールの選択、正確な計算、ポリシー ルール、または既知の最終状態を検証します。
  2. 人間によるレビュー 正しい、部分的に正しい、安全ではない、エスカレーションが必要など、境界のあるルーブリックをキャプチャします。査読者の個人的なメモではなく、ルーブリックと査読者のプロセスを記録します。
  3. モデルベースのスコアリング 再現可能なルーブリックをより大量に適用できます。審査員モデル、指示、およびしきい値をバージョン管理し、スコアを人間によるレビューと定期的に比較します。
  4. 製品の成果 ユーザーが結果を受け入れ、保存、修正、再生成、エスカレーション、または放棄したかどうかを記録します。

LLM 審査員は測定手段であり、客観的なラベルではありません。意見の不一致、評価の欠落、審査員構成の変更を追跡します。の Langfuse の評価コンセプト そして アライズフェニックスの評価ドキュメント Telemetry の上流に残すことができる追加の評価ワークフローについて説明します。

レビューされた結果イベントを発行する

この JavaScript の例では、スコアラーまたは人間によるレビューのワークフローが終了した後に、コンパクトな評価結果を送信します。

import telemetry from "telemetry-sh";

telemetry.init(process.env.TELEMETRY_API_KEY);

export async function recordAgentEvaluation({
  operationId,
  evaluationId,
  evaluatorType,
  evaluatorVersion,
  metricName,
  score,
  threshold,
  reviewOutcome,
  isFinal,
  datasetVersion,
  promptVersion,
  release,
}) {
  await telemetry.log("ai_output_reviewed", {
    operation_id: operationId,
    evaluation_id: evaluationId,
    evaluator_type: evaluatorType,
    evaluator_version: evaluatorVersion,
    metric_name: metricName,
    score,
    threshold,
    passed: score >= threshold,
    review_outcome: reviewOutcome,
    is_final: isFinal,
    dataset_version: datasetVersion,
    prompt_version: promptVersion,
    release,
  });
}

isFinal を true にするのは、操作、指標、評価器のバージョン、リリースごとに権威ある最終決定が一つある場合だけです。エージェントの実行完了はレビューの確定を意味しません。

デフォルトでは、生のプロンプト、補完、取得したドキュメント、ツールの引数、シークレット、および自由形式のレビュー担当者のメモをイベントから除外します。安定したカテゴリとバージョン識別子を優先します。コンテンツの保持が承認された場合は、そのアクセスおよび削除ポリシー用に設計されたシステムにコンテンツを保存し、制限された識別子と関連付けます。

リリースごとに品質を比較する

この例では、操作、リリース、指標、評価器のバージョンごとに is_final = true のレビューを一件だけ最終結果として扱います。暫定レビューは is_final = false にします。最終決定を修正する場合は、評価器の新しいバージョンか別の確定イベントを使います。クエリは重複した最終レビューを除外し、完了した操作だけを数えます。重複を調べずにカバレッジや合格率を解釈しないでください。

WITH completed AS (
  SELECT release, operation_id
  FROM agent_run_completed
  WHERE timestamp_utc >= now() - INTERVAL '30 days'
    AND status = 'success'
  GROUP BY release, operation_id
),
final_reviews AS (
  SELECT release, operation_id, MAX(score) AS score,
    MAX(CASE WHEN passed THEN 1 ELSE 0 END) AS passed
  FROM ai_output_reviewed
  WHERE timestamp_utc >= now() - INTERVAL '30 days'
    AND metric_name = 'task_quality'
    AND evaluator_version = 'quality-rubric-v3'
    AND is_final = true
  GROUP BY release, operation_id
  HAVING COUNT(*) = 1
)
SELECT
  c.release,
  COUNT(*) AS completed_operations,
  COUNT(f.operation_id) AS evaluated_operations,
  ROUND(
    100.0 * COUNT(f.operation_id)
    / NULLIF(COUNT(*), 0),
    1
  ) AS evaluation_coverage_pct,
  ROUND(
    100.0 * SUM(CASE WHEN f.passed = 1 THEN 1 ELSE 0 END)
    / NULLIF(COUNT(f.operation_id), 0),
    1
  ) AS evaluated_pass_rate_pct,
  ROUND(AVG(f.score), 3) AS average_final_score
FROM completed c
LEFT JOIN final_reviews f
  ON f.release = c.release AND f.operation_id = c.operation_id
GROUP BY c.release
ORDER BY c.release;

この結果でリリースを判断する前に、除外された最終レビューの重複を確認します:

SELECT release, operation_id, COUNT(*) AS conflicting_final_reviews
FROM ai_output_reviewed
WHERE timestamp_utc >= now() - INTERVAL '30 days'
  AND metric_name = 'task_quality'
  AND evaluator_version = 'quality-rubric-v3'
  AND is_final = true
GROUP BY release, operation_id
HAVING COUNT(*) > 1
ORDER BY release, operation_id;

異なるルーブリックを使用したリリースを比較したり、モデル、しきい値、データセットのバージョン、またはサンプリング ルールをそれらの次元を分離せずに判断したりしないでください。評価者変更後のスコアの変化は、製品の回帰の証拠ではありません。

受け入れられた結果ごとのコストを計算する

まず操作単位でコストを集計し、一つの最終決定に結合します。この例の operation_id はリリースをまたいで一意です。そうでない場合は両方の結合キーに release を含めてください。重複した最終決定は除外されるため、別途調査が必要です。

WITH operation_cost AS (
  SELECT
    operation_id,
    SUM(estimated_cost_usd) AS total_cost_usd
  FROM llm_request_completed
  WHERE timestamp_utc >= now() - INTERVAL '30 days'
  GROUP BY operation_id
),
terminal_outcome AS (
  SELECT
    operation_id,
    MAX(CASE WHEN review_outcome = 'accepted' THEN 1 ELSE 0 END) AS accepted
  FROM ai_output_reviewed
  WHERE timestamp_utc >= now() - INTERVAL '30 days'
    AND metric_name = 'task_quality'
    AND evaluator_version = 'quality-rubric-v3'
    AND is_final = true
  GROUP BY operation_id
  HAVING COUNT(*) = 1
)
SELECT
  COUNT(*) AS evaluated_operations,
  SUM(accepted) AS accepted_operations,
  ROUND(SUM(total_cost_usd), 4) AS evaluated_cost_usd,
  ROUND(
    SUM(total_cost_usd) / NULLIF(SUM(accepted), 0),
    4
  ) AS cost_per_accepted_operation_usd
FROM operation_cost c
JOIN terminal_outcome o ON o.operation_id = c.operation_id;

この指標は、「受け入れられた」という定義が安定している場合にのみ意味を持ちます。コピーされた回答、ユーザーに表示される回答、再オープンせずに解決されたケース、および人間によるルーブリック パスは、結果が異なります。

回帰ゲートを構築する

提案されている各リリースについて:

  1. 同じ凍結されたデータセットを同じエバリュエーター構成で実行します。
  2. 候補者を記録する release, prompt_version, dataset_version、そして evaluator_version.
  3. 合格率、重度障害率、ハンドオフ率、p95 期間、および承認された操作ごとのコストを承認されたベースラインと比較します。
  4. ソース評価システムで失敗した例を検査します。
  5. 実行前に選択したしきい値を使用して、リリースを承認または拒否します。
  6. 凍結されたデータセットはすべてのライブ入力を表すことができないため、本番の結果を個別に監視します。

決定により保証される場合は、最小サンプル サイズと信頼区間を含めます。分母が小さい割合に関するアラートは避けてください。評価範囲も追跡します。レビューされた 20 回の実行での合格点は、未レビューの 10,000 回の実行を表すものではありません。

専用の評価プラットフォームを保持する場合

チームが即時および完了検査、データセットのキュレーション、アノテーション キュー、プロンプト管理、実験の実行、トレースの再生、または組み込みの評価器を必要とする場合は、専門のプラットフォームを使用します。 Telemetryは、バージョン付きのスコアと結果を受け取り、SQLで分析できます;機能ごとに置き換えるものではありません。

次に、 AI 品質回帰レシピ, エージェントタスクの成功とハンドオフレシピ、そして 1 ドル当たりの許容生産量レシピ。より広い実装境界については、を参照してください。 AIエージェントの監視.

関連機能

エージェントの実行、ツールの使用、トークンのコスト、品質、製品の成果を結び付けます。

ページの著者と参考資料

Telemetry 編集チームがこの説明を所有しています。製品チームは動作、例、境界をレビューします。

ドキュメントのレビュー方法