review-llm-annotations-and-improve-prompt

レビューで見つかった不一致に基づくメトリクスの改善

これは開発用であり、判定器の較正を宣言するためのものではありません。信頼性やリリースに関する主張をする場合は、インストール済みであれば coval-calibrate-metric を使用してください。以下の制約を守れば、このワークフロー単独でも使用できます。

組織／ワークスペースとテキスト判定メトリクスを1つ確認します。現在の CLI context と --help を使って、その定義、バージョン、プロジェクト、人による完了済みのアノテーションを読み取ります。バイナリ、カテゴリ、数値のテキスト判定では、それぞれ異なる誤り分析が必要です。ある種類を別の種類に暗黙に変換しないでください。

実際に完了した人によるラベルとレビュアーのメモ、機械出力の正確な ID／バージョン、関連するトランスクリプトを収集します。CLI で完全性を証明できない場合は、公開レビュー API をページネーションして取得します。ゼロは有効なラベルです。null または保留中の値は欠損として扱います。AI が提案したラベルは、人による正解データではありません。同じ呼び出しを複数のレビュアーが評価している場合は、重複して数えるのではなく裁定が必要です。アノテーションの simulation_output_id はアップロードされた会話を特定する場合があります。元のコレクションを保持し、対応する公開 API／CLI リソースから元のメトリクスを取得します。

調整を始める前に、関連する呼び出しを train（プロンプト例）、開発用、未使用のテスト用グループに分けます。開発用の不一致と、一致しているサンプルだけを確認します。バイナリ判定器では、単純な一致率だけでなく、失敗の検出と合格の再現率も含めます。数値判定器では、スコアを確認する前に許容誤差を固定します。一致率を上げるために許容誤差を広げないでください。カテゴリ判定器では、実際の混同行列の件数を示します。

各不一致をルーブリックに照らして確認します。人または判定器のどちらが間違っている可能性もあります。人によるラベルに異議がある場合は、ドメイン専門家が裁定する必要があります。「人によるすべてのラベルを機械に一致させる」ことを近道として提案してはいけません。元のラベルとメモは保持します。

観察された証拠で裏付けられる、最小限のプロンプト変更案を作成します。評価基準、出力タイプ、正しく機能している境界条件は維持します。例には train のものだけを含めます。保留中の例をプロンプトに漏らしてはいけません。更新に必要な権限が不足している場合は、その権限を求める前に、変更前／変更後のプロンプトと影響を受ける失敗パターンを示します。実稼働環境のデフォルト設定と過去との比較を維持できるよう、別の候補メトリクスを優先します。

権限がある場合は、上限を設定した coval --agent metrics test <candidate-id> --simulation-output-ids <ids> リクエストを使って、既存の出力をスコアリングします。項目ごとの応答を確認し、返された各 metric_output_ulid を simulated-conversations metric-detail <simulation-id> <output-ulid> または GET /v1/conversations/simulated/{simulation_id}/metrics/{metric_output_id} でポーリングします。API では explanation が公開されています。認証情報を出力したり、存在しないネストされた outputs ルートを使用したりしないでください。再スコアリングの回数を、合意済みのメトリクス予算と照らして数えます。曖昧さがある場合は、重複をキューに入れずに停止します。

開発用データでの変更点と残っているエラーを報告します。未使用の、人によるラベル付きグループで一度測定する前に、候補を固定します。その証拠がない場合は、「開発用の例でプロンプト候補が改善した」と述べ、「判定器を検証済み」とは述べないでください。自動再シミュレーション、人によるラベルの編集、デフォルトへの適用、通知は行いません。