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

AI エージェントの評価は、技術的に完了した実行と実際にタスクを満たした結果を区別する場合に役立ちます。信頼性の高い設計では、実行に関するコンパクトなイベント、分析する価値のあるモデルまたはツールのアクティビティ、およびその後の評価結果が記録されます。 SQL は、トレースやモデルで生成されたスコアをグラウンド トゥルースとして扱うことなく、リリースごとに品質、コスト、レイテンシー、再試行、および人間によるハンドオフを比較できます。

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

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

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

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

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

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

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

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,
  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,
    dataset_version: datasetVersion,
    prompt_version: promptVersion,
    release,
  });
}

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

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

このクエリは、単一のメトリクスのカバレッジと合格率を計算します。明示的な評価カウントにより、未評価のリリースが人為的に成功したように見えるのを防ぎます。

WITH run_counts AS (
  SELECT
    release,
    COUNT(DISTINCT operation_id) AS completed_operations
  FROM agent_run_completed
  WHERE timestamp_utc >= now() - INTERVAL '30 days'
    AND status = 'success'
  GROUP BY release
),
evaluation_counts AS (
  SELECT
    release,
    COUNT(DISTINCT operation_id) AS evaluated_operations,
    COUNT(DISTINCT CASE WHEN passed THEN operation_id END) AS passed_operations,
    AVG(score) AS average_score
  FROM ai_output_reviewed
  WHERE timestamp_utc >= now() - INTERVAL '30 days'
    AND metric_name = 'task_quality'
    AND evaluator_version = 'quality-rubric-v3'
  GROUP BY release
)
SELECT
  r.release,
  r.completed_operations,
  COALESCE(e.evaluated_operations, 0) AS evaluated_operations,
  ROUND(
    100.0 * COALESCE(e.evaluated_operations, 0)
    / NULLIF(r.completed_operations, 0),
    1
  ) AS evaluation_coverage_pct,
  ROUND(
    100.0 * COALESCE(e.passed_operations, 0)
    / NULLIF(e.evaluated_operations, 0),
    1
  ) AS evaluated_pass_rate_pct,
  ROUND(e.average_score, 3) AS average_score
FROM run_counts r
LEFT JOIN evaluation_counts e ON e.release = r.release
ORDER BY r.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'
  GROUP BY operation_id
)
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エージェントの監視.