creating-online-evaluations

オンライン評価の作成

オンライン評価は、無効化されるまで、一致する各 $ai_generation またはそれを含むトレース全体を自動的に採点します。優れた評価は、推測や「ハルシネーション」「有用性」のような一般的な指標ではなく、本番トラフィックで実際に見つかった失敗モードに基づいています。このスキルでは、失敗モードが特定された後、それらを対象範囲の明確な、継続的に実行される評価にします。

失敗モードごとに評価を1つ作成し、データが正当化する数だけ作成します。 作成する数は、実際のトレースから判断してください。1つの場合もあれば、3つか4つの場合もあります。1つだけだと決めつけたり、無関係なモードを1つの評価器にまとめたりしないでください。例外は、ユーザーの依頼に回答できなかった理由など、同じチェックの結果であるモードの集合です。この場合は、モードごとにカテゴリを設けた1つのカテゴリ評価が適しています（2.1）。

作成する前に提案します。 候補となる評価の短いリストをユーザーに提示し、作成したいものを選んでもらってください（フェーズ 1.1）。ユーザーが求めていない評価を作成すると、費用とノイズが発生します。

まず、何を評価するのかを把握します。 検出すべき失敗モードを見つけて順位付けするのは、別の作業です。ユーザーが評価したい内容を指定していない場合は、確認してください。まだ曖昧で、特定の失敗モードにも触れていない場合は、exploring-ai-failures を実行してユースケースの対象範囲を定め、失敗したトレースを見つけ、失敗モードの優先順位付きリストを作成してください。

評価器の 作成と反復 の方法（Hog ソースと LLM ジャッジのプロンプト、ドライラン、稼働中の評価のデバッグ）については、exploring-llm-evaluations を参照してください。

ツール

ツール	目的
posthog:llma-evaluation-config-get	固定されていないジャッジが使用するアクティブなプロバイダーキーを確認する
posthog:llma-provider-key-list	固定するために使用可能な（ok 状態の）プロバイダーキーを見つける
posthog:llma-evaluation-judge-models	有効なプロバイダーとモデルの組み合わせを一覧表示する
posthog:llma-evaluation-directory-list	評価の整理に使用できるディレクトリを一覧表示する
posthog:llma-evaluation-directory-create	ユーザーから新しいディレクトリの作成を依頼された場合に作成する
posthog:llma-evaluation-test-hog	作成前に、最近の生成に対して Hog ソースをドライランする
posthog:llma-evaluation-create	評価を作成する（最初は必ず enabled: false にする）
posthog:llma-evaluation-run	1件の生成に対して評価のドラフトをスポット実行する
posthog:llma-evaluation-update	設定を反復した後、enabled: true に切り替える
posthog:llma-evaluation-backfill-estimate	過去のデータをバックフィルした場合に評価対象となる件数を数える
posthog:llma-evaluation-backfill-create	推定結果をユーザーが確認した後に限り、過去のデータを評価する
posthog:llma-evaluation-backfill-get	バックフィルの進行状況と対象範囲を追跡する
posthog:llma-evaluation-backfill-list	実行中のものも含め、評価のバックフィルを見つける
posthog:llma-evaluation-backfill-cancel	ユーザーから依頼された場合に、実行中のバックフィルを停止する
posthog:execute-sql	条件が想定どおりのイベントとボリュームに一致することを確認する
posthog:generate-app-url	評価への、リージョンとプロジェクトを指定したディープリンクを作成する

作成時に必要なペイロード全体（すべてのフィールド、設定スキーマ、正確な conditions の形式）は、 references/evaluation-payload.md にあります。

フェーズ 1 — 提案する内容を決めてから、ユーザーに選んでもらう

事前に選んだ指標ではなく、実際に観測された失敗から始めます。まだ失敗を把握していない場合は、 exploring-ai-failures を実行してユースケースの範囲を定め、失敗したトレースを見つけ、失敗パターンを 優先順位順にまとめてから戻ってきてください。

1.1 — 失敗パターンを候補セットにする

候補数はデータに決めてもらいます。 失敗パターンが1つなら評価も1つです。異なるパターンが4つ 優先順位順に並んでいれば、候補セットは評価4つです。すべてを検出しようとする評価器1つにまとめたり、 トレースからほかにも監視すべきパターンが明らかなのに、最上位のパターンだけで止めたりしないでください。 次の条件を満たす候補を残します。

• 影響が大きいこと。 頻繁に起きるか、深刻な問題であること。通常、いくつかのパターンで失敗の大半をカバーできます。
• 判定可能であること。 「返信はユーザーの話題から逸れてはいけない」「ツール呼び出しには order_id を含める必要がある」のように、明確な基準1つに落とし込めること。1行で言えないなら、提案する準備ができていません。
• 他と異なること。 同じ生成結果で失敗する候補が2つあるなら、評価は1つにします。

影響の大きさで順位を付け、上位5つ程度を提案します。優先度の低いものを黙って除外するのではなく、 そのような候補は今回は見送ったことを1行で伝えてください。

1.2 — 候補セットを平易な言葉で提案する

ユーザーが選んでいない評価は作成しないでください。 候補を提示し、どれを設定するか尋ねます。

ユーザーは一緒にトレースを読んでおらず、評価の用語も知らないものとして考えます。各候補は1〜2行に まとめます。評価ごとの長文では比較しにくくなりますが、何を監視し、失敗時に何がわかるのかは明確にします。 ここでは Hog のスニペット、プロパティフィルター、hog／llm_judge の内部仕様は示しません。 「1と3」のように返答できるよう、番号を付けます。

監視する価値のある失敗パターンが3つ見つかりました。どれを設定しますか？

1. 返信が話題から逸れる — 回答がユーザーの実際の質問に答えているかを確認します。 別の質問に自信たっぷりに回答してしまうサポート返信を検出します。1日あたり約40回確認されています。

2. 注文の照会で注文 ID が抜けている — lookup_order のすべての呼び出しに order_id が含まれているかを確認します。 サイレントなツールの失敗によって、エージェントが注文状況を作り上げてしまう問題を検出します。1日あたり約15回確認されています。

3. 回答できる質問を拒否する — 返信が不必要に「対応できません」としていないかを確認します。 ドキュメントに答えがあるのにユーザーを断ってしまう問題を検出します。確認ごとに LLM 呼び出しの費用がかかります。

評価ごとに、確認する内容、明らかになる問題、わかる場合はおおよその発生件数を示します（正確な件数はフェーズ 2.5 で確認します）。LLM ジャッジが必要な候補には印を付けてください。実行ごとに費用がかかるため、事前に伝えるべき仕組みはこれだけです。順位は順番で示し、スコア表は省略します。

ユーザーが迷っているようなら、まず始める候補を勧めます（通常は上位1〜2つです）。「全部」や「進めて」は、 候補セット全体への同意として扱います。プロンプトの調整でパターンを解消できそうなら、評価の代わりではなく、 評価とあわせて修正を提案します。修正が反映されたことは、合格率の上昇で確認できます。

1.3 — 何も見つからなかった場合は、感情分析を提案する

トレースを確認して評価する価値のある失敗パターンが見つからなかった場合、失敗をでっち上げず、何も提案せずに 終わることも避けてください。何を確認したかを伝えたうえで、まずは sentiment 評価を提案します。

過去7日間に明確な失敗パターンはありませんでした。まずは次の評価から始めるとよさそうです。

1. ユーザーの不満 — 各ユーザーメッセージを肯定的、中立的、否定的に分類します。 どの会話がうまくいっていないかがわかります。実際の失敗は、たいていそうした会話に隠れています。ジャッジ費用はかかりません。

プロバイダーキーは不要で、費用も安く済みます。パターンを見つけられるだけのトラフィックが集まった後に、 再び確認するための手がかりになります。

生成結果がなければ、どの評価も実行できません。 感情分析は条件に一致する $ai_generation イベントだけを スコアリングするため、プロジェクトにイベントがなければ、感情分析を含め、作成できる評価はどれも実行されないままです。 提案しないでください。まず instrument-llm-analytics を案内し、AI オブザーバビリティで生成結果を記録できるようにしてから、 トラフィックが集まった時点でこのスキルに戻ってください。

フェーズ 2 — 採用する評価をそれぞれ作成する

ユーザーが選んだ評価ごとに 2.1 から 2.5 を 1 回ずつ実行し、それぞれを検証済みのドラフトにします。すべての評価が検証されるまで、どれも無効のままにしてください。2.6 は各ループの最後の手順ではなく、完成したセット全体を対象に最後に 1 回だけ実行します。評価 3 の作成がまだ終わっていないのに評価 1 を有効にすると、一部だけが本番環境で有効になってしまい、ノイズとなるうえ、（ジャッジの場合は）ユーザーがまだ同意していない費用が発生します。

2.1 — 評価の種類を選ぶ

使用するもの…	条件…
hog	構造またはルールベースの場合（JSON の解析、長さ、正規表現、ツール呼び出しの形式など）。低コストで決定論的であり、プロバイダーキーは不要です。
llm_judge	主観的または曖昧な条件の場合（トーン、事実性、トピックとの関連性など）。実行ごとに LLM 呼び出しの費用がかかり、プロバイダーとモデルが必要です。使用可能なプロバイダーキーが必要なのは有効化するときだけで、ドラフトの作成時には不要です。
sentiment	ユーザーメッセージのセンチメントラベルが必要で、合否判定は不要な場合（非常に具体的に依頼された場合を除き、通常はこのスキルでは該当しません）。

まず hog を選び、確認したい内容を決定論的にチェックする方法がない場合は llm_judge に切り替えます。

次に、1 回の実行で返す内容を選びます。hog と llm_judge は、次の 3 種類の出力すべてに対応しています。

output_type	失敗モードが…の場合
boolean	はい／いいえで判定できる単一の条件。デフォルトです。チェックで問題を検出したときに true を返す場合は、true_is_failure: true を設定します。
numeric	程度を表す値（品質評価の 1～5 など）や、測定値（長さ、レイテンシー、費用など）の場合。
categorical	結果が、関連する複数の失敗モードのうちどれが発生したかなど、名前付きのカテゴリに分類される単一のチェックの場合。

• 数値： 範囲外のスコアが採点されずにスキップされるよう、min と max を設定します。合格率やレポートを作成するには、しきい値に対して gte または lte を指定する passing_rule を追加します。step はあくまでヒントです。ジャッジは step: 1 でも 3.7 のような小数スコアを返すことができ、そのスコアは返された値のまま保存されます。
• カテゴリ： 表示ラベルを付けた、安定した小文字のキーを options として定義します。結果が必ず 1 つだけ当てはまる場合は single を、複数の問題が同時に当てはまる場合は multiple を使います。合格率やレポートを作成するには、合格とみなすキーを passing_rule.categories に設定します。single モードでは、通常「問題なし」を示すキーを指定します。multiple モードでは「問題なし」を示すキーを定義せず、categories: [] を設定します。これにより、空の結果だけが合格します。キーが 1 つでも指定されていると、空の結果は不合格になります。
• 合格ルールがない場合でも、数値とカテゴリの結果は記録されますが、合格率やレポートはありません。

llm_judge が numeric または categorical を返す場合、PostHog はジャッジに出力形式を伝えます。プロンプトには、各スコアまたはカテゴリの意味だけを記述します。設定項目の全一覧： references/evaluation-payload.md。

2.2 — 対象を選ぶ

対象	動作
generation	一致する $ai_generation ごとに、取り込み直後に1回実行されます。これがデフォルトです。
trace	最初に一致する生成の後、設定可能なトレース完了待機時間を経て、トレース全体に対して1回実行されます。
session	セッションが落ち着いた後、$ai_session_id セッション全体に対して1回実行されます。

トレース対象では、"target": "trace" と、strategy に応じて判別される、トレースを評価するタイミングを制御する待機設定を指定します。

• { "strategy": "fixed_window", "window_seconds": 1800 } — 一致する最初の生成の後、一定時間待って評価します。10秒から2時間まで指定でき、デフォルトは30分です。strategy キーのない target_config は、この設定を意味します。
• { "strategy": "inactivity", "quiet_period_seconds": 300, "max_age_seconds": 7200 } — トレースに静穏期間中、新しいアクティビティがなかった時点で評価します（10秒から30分まで指定でき、デフォルトは5分です）。max_age_seconds は、一致する最初の生成からの総待機時間の上限を設定します（1分から2時間まで指定でき、デフォルトは2時間です。静穏期間以上である必要があります）。

session 対象では、セッションの規模に応じた上限で同じ待機設定を使用し、デフォルトは fixed_window ではなく inactivity です。

• { "strategy": "inactivity", "quiet_period_seconds": 3600, "max_age_seconds": 86400 } — セッションに静穏期間中、新しいアクティビティがなかった時点で評価します（10秒から24時間まで指定でき、デフォルトは1時間です）。max_age_seconds は、一致する最初の生成からの総待機時間の上限を設定します（1分から7日まで指定でき、デフォルトは24時間です。静穏期間以上である必要があります）。
• { "strategy": "fixed_window", "window_seconds": 1800 } — 一致する最初の生成の後、一定時間待って評価します（10秒から7日まで）。

セッション評価は、$ai_session_id を持つイベントに対してのみ実行されます。生成側はこの値をすべての生成に設定するか、まったく設定しないため、設定しない SDK ではセッション評価は実行されません。$ai_session_id は $session_id とは異なります。後者は PostHog のプロダクト分析用セッションであり、別のものです。

セッション評価は、採点されずにスキップされることもあります。その場合、出力される $ai_evaluation イベントには $ai_evaluation_skipped: true と $ai_evaluation_skip_reason が含まれます。また、評価で N/A が許可されていない場合、$ai_evaluation_result は false になります。そのため、合格率を分析する際は、スキップされた実行を失敗として数えず、除外する必要があります。セッション内のイベント数が2500件を超える場合（通常は複数の会話で同じセッション ID が共有されている場合）、評価ウィンドウ内に対象が見つからない場合、または LLM ジャッジに送信するにはトランスクリプトが長すぎる場合、セッションはスキップされます。

完了した実行が Temporal の保持期間内にある限り、各評価でセッションが評価されるのは最大1回です。評価後かなり時間が経ってから再開したセッションは、再度評価されることがあります。そのため、セッションが本当に終了していると判断できるだけの長さの静穏期間を選んでください。静穏期間を長くしても、遅延が増えるだけです。

条件は、実行のトリガーとなる生成に引き続き一致します。評価器自体には、トレースまたはセッション全体が渡されます。感情評価でサポートされるのは、generation 対象のみです。

新しい Hog ソースでは、すべての対象で共有されるグローバル変数を使用してください。

グローバル変数	意味
evaluation_events	生成ターゲットの場合は1件の生成イベント、トレースまたはセッションターゲットの場合はキャプチャされたすべてのイベントです。
target	ターゲットの type、id、total_cost_usd、total_latency_seconds です。
item.input_text / item.output_text	読み取り可能な形式へのベストエフォートな投影です。長さ、キーワード、正規表現のチェックにはこれらを使用してください。
item.input / item.output	元のシリアライズ済みの値です。評価器でキャプチャされたJSON自体を解析する必要がある場合に使用してください。

セッションターゲットでは、target.id はセッションIDであり、target.total_cost_usd / target.total_latency_seconds はセッション内のトレース全体で合算されます。total_latency_seconds はAI処理に費やされた時間であり、セッションの実時間ではありません。両者は桁違いになることがあります。セッションの実時間は、evaluation_events のタイムスタンプから算出できます。

生成評価では、引き続きトップレベルの input、output、properties、event が公開されます。トレース評価では、元の events および trace グローバル変数が引き続き公開されます。これらのグローバル変数は、保存済みの評価器との互換性のために維持されています。セッション評価には含まれません。セッションのHogソースで受け取れるのは target と evaluation_events のみです。ターゲットをまたいで動作させる必要のある新しいソースでは、ターゲット固有のグローバル変数を使用しないでください。テキストへの投影は一般的なプロバイダーペイロードを認識しますが、正式な情報源ではありません。正確な構造が重要な場合は、item.input / item.output を使用してください。

2.3 — LLM judgeを設定する

llm_judge 評価は、有効な provider と model があれば下書きとして作成できます。有効なプロバイダーキーは評価を有効にするために必要ですが、保存には不要です。そのため、ok 状態のキーがない場合は評価を無効のままにする理由にはなりますが、処理を中止する理由にはなりません。provider_key_id は、評価で特定のキーを固定するかどうかを制御します。

• provider_key_id に、同じプロバイダーの ok 状態のキーのUUIDを設定すると、そのキーに固定されます。
• provider_key_id に null を設定すると、チームのアクティブなプロバイダーキーが使用されます。これは常に有効な保存値です。評価を有効にするには、アクティブなキーが ok 状態で、model_configuration.provider と同じプロバイダーを使用している必要があります。

Hog評価とセンチメント評価では、この手順を省略します。

posthog:llma-evaluation-config-get        // check active_provider_key for an unpinned judge
posthog:llma-provider-key-list            // find an ok-state key to pin
posthog:llma-evaluation-judge-models      // {} → every provider and its models; { "provider": "openai" } narrows it

llma-evaluation-judge-models でプロバイダーとモデルを確認してください。 引数なしで呼び出すと、カタログ全体を一度に確認できます。 PostHogがモデルの料金を負担していないプロバイダーは、チームのキーのいずれかに対する key_id を渡さない限り、結果が空になります。レスポンスの providers リストで、該当するプロバイダーを確認できます。 モデルがリストされていても、無料モデルとは限りません。llm_judge の実行にはチーム独自のプロバイダーキーが必要なため、有効なキーが用意されるまで有効化は失敗します。 後からチーム全体のアクティブキーが変更されても評価の実行方法が変わらないよう、選択したキーを固定することを推奨します。 チームのアクティブキーで実行する場合は、provider_key_id を null のままにしてください。有効化する前に、llma-evaluation-config-get でアクティブキーが使用可能であり、そのプロバイダーが一致していることを確認してください。

使用可能なキーがなくても、作成を妨げることはありません。有効な provider と model を指定して、ユーザーが確認できる無効状態の下書きを作成してください。スポット実行や有効化は行わず、後で有効化できるよう、UIでキーを追加または検証するようユーザーに依頼してください。

2.4 — 無効状態で作成する

enabled: false を指定して作成し、スコープを確認するまで何も実行されないようにします。最小限の hog の例：

評価はトップレベル、または1つのディレクトリ内に作成できます。ユーザーがディレクトリを指定した場合は、 posthog:llma-evaluation-directory-list を呼び出し、その UUID を directory_id として渡します。ディレクトリの作成は、 ユーザーが明示的に求めた場合に限ります。トップレベルの場合は directory_id を省略するか、null を渡します。ディレクトリは入れ子にできません。

posthog:llma-evaluation-create
{
  "name": "Output is not empty",
  "description": "Fails when a generation has no readable output",
  "evaluation_type": "hog",
  "evaluation_config": { "source": "let count := 0\nfor (let i, item in evaluation_events) {\n    if (item.event == '$ai_generation') {\n        count := count + 1\n        if (length(trim(item.output_text)) == 0) { return false }\n    }\n}\nreturn count > 0" },
  "output_type": "boolean",
  "output_config": { "allows_na": false },
  "target": "generation",
  "target_config": {},
  "conditions": [
    { "id": "default", "rollout_percentage": 100, "properties": [{ "key": "$ai_model", "type": "event", "operator": "icontains", "value": "gpt" }] }
  ],
  "enabled": false
}

llm_judge の場合は、evaluation_config を { "prompt": "…" } に差し替え、 "model_configuration": { "provider": "openai", "model": "gpt-5-mini", "provider_key_id": null } を追加します。 特定のキーを使って実行するには、provider_key_id に llma-provider-key-list で状態が ok のキーの UUID を指定します。 null を指定すると、チームのアクティブなキーが使われます。どちらの値でも下書きとして保存されます。フィールドの全項目については、 references/evaluation-payload.md を参照してください。

2.5 — 有効化する前にスコープを確認する

conditions はオンライン評価で問題が起きやすい箇所です。広すぎると大量のイベントを評価（および課金）することになり、狭すぎると 一度も実行されません。フィルターが想定するイベントに一致することと、1日あたりのおおよその件数を確認してください。

posthog:execute-sql
SELECT count() AS matched, count() / 7 AS per_day
FROM events
WHERE event = '$ai_generation'
    AND properties.$ai_model ILIKE '%gpt%'      -- mirror each condition property
    AND timestamp >= now() - INTERVAL 7 DAY

生成を対象とする場合、count() が実行量です。トレースを対象とする場合は、空でない $ai_trace_id の一意な値を数えてください。同じトレース内で一致する生成があっても、実行は1回だけスケジュールされます。

件数が多い場合は、サンプリングするために rollout_percentage を100未満に設定します。llma-evaluation-test-hog（hog）を使うか、1つの生成に対して llma-evaluation-run（llm_judge）を実行し、評価器をスポットチェックします（2.3のとおり、使用可能なキーがない judge ではスポット実行を省略してください）。 数値またはカテゴリ型の Hog 評価では、llma-evaluation-test-hog に同じ output_type と output_config を渡してください。これにより、 プレビューで、保存された評価が受け付けるスコアまたはカテゴリキーを検証できます。 どちらのツールも現在は生成サンプルを使用します。トレースを対象とする場合、共有ソースやプロンプトの動作は確認できますが、 確定済みトレース全体を再現することはできません。ロールアウト率を上げる前に、最初のライブトレース結果を確認してください。

注意： 1つの $ai_trace_id を10万件以上のイベントで再利用する組織もあります。トレース ID のプレフィックスでスコープを指定すると、 想定よりはるかに多くのイベントに一致する可能性があります。有効化する前に、上記の SQL で件数を確認してください。

2.6 — 確認済みの対象を有効化し、結果を確認する

受け入れたすべての評価がスコープ確認済みの下書きになってから、それぞれ個別に1回ずつ呼び出して有効化します。

posthog:llma-evaluation-update
{ "evaluationId": "<uuid>", "enabled": true }

これ以降、各評価は新たに一致した生成ごとに実行されます。トレースを対象とする場合は、一致したトレースごとに1回実行されます。これは 一度限りの作業ではありません。結果を継続的に確認し、期待どおりでなければ反復して調整する必要があることをユーザーに伝えてください。結果を Slack フィードに連携する方法については、feature-usage-feed を参照してください。

全対象の結果をまとめて確認し、現在有効な評価とそれぞれのリンクを簡潔に一覧で共有してください。評価ごとの逐一の経過報告は不要です。無効のままにした候補（使用可能なプロバイダーキーがない、件数が多すぎてまだ有効化できないなど）と、それを有効化するために必要なことも伝えてください。

2.7 — 過去のデータを評価する方法を提案する

有効化された評価では、それ以降のトラフィックのみがスコアリングされます。ユーザーがすでに保有しているデータで結果を確認したい場合は、直近の期間（最大で過去 30 日間）を対象とするバックフィルを提案してください。posthog:llma-evaluation-backfill-create は無効な評価を拒否するため、先に有効化してください（2.6 を参照）。

1. ユーザーが希望する期間、conditions、rerun_existing を指定して、posthog:llma-evaluation-backfill-estimate を呼び出します。total_units、返された期間（上限が適用されるため、指定した期間とは異なる場合があります）、各ユニットのコストをユーザーに伝えてください。コストは、AI observability イベントとしてカウントされる評価の実行 1 回分に加え、llm_judge のモデル呼び出し 1 回分です。already_evaluated_units にはすでに結果があるため、rerun_existing が true でない限り対象から除外されます。
2. ユーザーが承諾してから、posthog:llma-evaluation-backfill-create を呼び出してください。指定した値ではなく、見積もりで返された window_start と window_end を使い、同じ conditions と rerun_existing を渡して、承認された内容どおりに実行されるようにします。
3. posthog:llma-evaluation-backfill-get で進捗を確認します。スキップされたユニットは評価自体によってすでに評価中だったため、処理対象に含まれており、見落とされたわけではありません。完了後、remaining_count が 0 より大きい場合は、結果がないまま残ったユニットがあります。同じ期間で別のバックフィルを提案してください。提案は 1 回だけにしてください。2 回目の実行でもユニットが残る場合、それらのユニットでは評価が引き続き失敗しているため、3 回目を提案せず、その旨をユーザーに伝えてください。
4. posthog:llma-evaluation-backfill-create が開始を確認できなかったと伝えた場合は、再試行する前に posthog:llma-evaluation-backfill-list を呼び出してください。バックフィルがすでに実行中の可能性があります。
5. バックフィルを停止するには、posthog:llma-evaluation-backfill-cancel を呼び出してください。すでに開始された評価は、そのまま完了します。

1 つの評価につき、同時に実行できるバックフィルは 1 つです。

conditions を使った対象範囲の指定

conditions は条件セットのリストです。セット同士はOR、各セット内の properties はANDで評価されます。各セットは { id, rollout_percentage, properties[] } です。conditions 内に時間範囲はなく、サンプリングに使われるのは rollout_percentage（0–100）のみです。プロパティフィルターには、標準的な PostHog の形式（key、type、operator、value）を使用します。トレースを対象にする場合も、これらのフィルターで、最終的にトレース全体の評価をトリガーする生成が選択されます。

"conditions": [
  { "id": "openai",    "rollout_percentage": 100, "properties": [{"key": "$ai_provider", "type": "event", "operator": "exact", "value": "openai"}] },
  { "id": "anthropic", "rollout_percentage": 25,  "properties": [{"key": "$ai_provider", "type": "event", "operator": "exact", "value": "anthropic"}] }
]

UI リンクの作成

リンクの作成には posthog:generate-app-url を使用してください。ホストや /project/<id>/ のプレフィックスを手書きしてはいけません。url にはカタログに登録された正規のテンプレートを指定し、具体的な ID はパスに直接埋め込まず、params で渡してください。

• 評価一覧： generate-app-url {url: "/ai-evals/evaluations"}
• 個別の評価： generate-app-url {url: "/ai-evals/evaluations/{id}", params: {id: "<evaluation_id>"}}

これらは、適切なリージョンのホストとプロジェクトのプレフィックスに解決されます（例： https://us.posthog.com/project/<id>/ai-evals/evaluations/<evaluation_id>）。作成後にリンクを提示し、ユーザーが UI で内容を確認し、有効・無効を切り替えられるようにしてください。

ヒント

• 評価は一般的な指標ではなく、実際の失敗から生まれます。 「ハルシネーションを測定しよう」ではなく、このプロダクトのトラフィックで見つかった失敗（exploring-ai-failures を使用）を出発点にしてください。実際の不適切な出力までさかのぼって追跡されていない指標は、ノイズにすぎません。
• 評価ごとに失敗モードは1つにし、データが正当化する数だけ評価を作成します。 失敗モードが異なれば、別々の評価が必要です。1つの評価ですべてを検出しようとせず、トレースで注視すべき複数のモードが示された場合に、既定で評価を1つだけ作成することも避けてください。ただし、1つのチェックで見分けられる関連モードは例外です。これらは1つのカテゴリ評価にまとめられます。
• 候補を提示し、選ばれたものを作成します。 候補を平易な言葉で、それぞれ1〜2行で示し、ユーザーが選ぶのを待ってください。評価ごとの長い説明は、読まれずに流し読みされてしまいます。
• 何も見つからなかった場合にも、答えはあります。 トレースを確認しても評価に値する失敗モードが見つからなかった場合は、手ぶらで終わらせず、sentiment 評価を提案してください。例外は、$ai_generation イベントがまったくない場合です。評価を実行できないため、代わりに instrument-llm-analytics を案内してください。
• 可能であれば、評価と併せて変更も提案します。 たとえば、プロンプトの変更で問題が解決すると明らかな場合は、評価を設定するだけでなく、プロンプトを変更するようユーザーにも提案してください。そうすれば、評価の合格率が低い状態から高い状態へと改善するのをすぐに確認できるはずです。
• まずは hog を使います。 プロバイダーキーが不要で、AI による承認も不要、かつ決定論的です。基準をコードで表現できない場合に限り、llm_judge を選んでください。
• 必ず無効の状態で作成し、対象範囲を確認してから有効にします。 間違ったイベントで評価が実行されるのは、評価がないよりも悪いことです。ノイズが発生し、（llm_judge の場合は）コストもかかります。
• ジャッジのドラフトに必要なのはプロバイダーとモデルだけです。 有効化には使用可能なプロバイダーキーが必要ですが、保存には不要です。そのため、ok キーがない場合は無効のままにしてください。処理を中止する必要はありません。チームのアクティブキーで実行する場合、provider_key_id は null にできます。
• hog 評価の bytecode はサーバー側で書き込まれます。決して渡さず、evaluation_config.source のみを送信してください。
• クラスターを対象とする評価では、exploring-llm-clusters でクラスターを特定してから、そのイベントフィルターを conditions に変換してください。

関連スキル

• exploring-ai-failures — 評価すべき失敗モードを見つけて優先順位を付けます。最初に実行してください
• exploring-llm-evaluations — 既存の評価をデバッグおよび管理します
• exploring-llm-clusters — クラスターを対象とした評価条件の範囲を決めるために、クラスターを特定します