sc-evaluate

LLM 評価スキル

オラクル LLM-as-judge スコアリングを使用して、ゴールドスタンダードのデータセットで LLM パイプラインの評価を実行します。重み付けされた評価軸に沿って出力品質を測定し、弱いステップを特定して、プロンプトの改善案を提案します。

クイックスタート

# Full evaluation (all test cases, all steps)
/sc:evaluate

# Quick spot check
/sc:evaluate --cases=case_1,case_2 --steps=1,2,3

# Re-evaluate existing results without re-running pipeline
/sc:evaluate --skip-pipeline

# Generate outputs only (no evaluation)
/sc:evaluate --skip-eval

# Specify judge model
/sc:evaluate --judge-model=gpt-4o

# Dry run to preview plan
/sc:evaluate --dry-run

動作フロー

1. 検出 - 評価スクリプト、ゴールドスタンダード、プロンプトファイルを探します
2. 設定 - 対象範囲（ケース、ステップ、モデルの上書き）を解析します
3. 実行 - ゴールドスタンダードの入力でパイプラインを実行します
4. 評価 - LLM-as-judge を使用して、出力をゴールドスタンダードと照合してスコアリングします
5. 分析 - 弱いステップ、評価軸ごとの内訳、パターンを特定します
6. 推奨 - スコアの低いステップに対して、具体的なプロンプト改善案を提案します
7. レポート - JSON と Markdown の評価レポートを生成します

フラグ

フラグ	型	デフォルト	説明
--cases	string	all	評価するテストケース ID（カンマ区切り）
--steps	string	all	評価するステップ番号（カンマ区切り）
--model	string	env default	パイプラインモデルを上書きします
--judge-model	string	env default	ジャッジ／オラクルモデルを上書きします
--skip-pipeline	bool	false	パイプラインの実行をスキップし、既存の結果を評価します
--skip-eval	bool	false	パイプラインのみを実行し、評価をスキップします
--dry-run	bool	false	API を呼び出さずに実行計画をプレビューします
--output	string	eval_runs/YYYYMMDD_HHMMSS/	出力ディレクトリ
--concurrency	int	5	ジャッジ呼び出しの並列数
--threshold	int	70	「改善が必要」と判定するスコアのしきい値

フェーズ 1：プロジェクト構成の検出

評価コンポーネントを特定します。

コンポーネント	一般的な場所	目的
評価スクリプト	scripts/run_eval.py、eval/run.py	パイプラインとスコアリングを統括します
ゴールドスタンダード	gold_standards/、test_data/、fixtures/	期待される出力
プロンプト	prompts/、templates/	パイプラインのプロンプトテンプレート
評価基準	eval/rubrics.py、config/rubrics.yaml	スコアリングの評価軸と重み

標準的な構成が見つからない場合は、パスを指定するようユーザーに尋ねます。

フェーズ 2：対象範囲の設定

引数を解析して、次の項目を決定します。

• 実行するテストケース（デフォルト：検出されたすべてのケース）
• 評価するパイプラインのステップ（デフォルト：すべて）
• パイプラインとジャッジのモデルの上書き
• 出力ディレクトリ（デフォルト：タイムスタンプ付き）

出力ディレクトリを作成します。

OUTPUT_DIR="${output:-eval_runs/$(date +%Y%m%d_%H%M%S)}"
mkdir -p "$OUTPUT_DIR"

フェーズ 3：パイプラインの実行

ゴールドスタンダードの入力でパイプラインを実行します。

python <eval_script> \
  --output "$OUTPUT_DIR" \
  --verbose \
  [--cases CASES] \
  [--steps STEPS] \
  [--model MODEL] \
  [--skip-pipeline] \
  [--skip-eval]

API 呼び出し数の見積もり：

• パイプライン：ステップ数 × ケース数分の API 呼び出し
• 評価：スコアリング対象の評価軸数 × ケース数分のジャッジ呼び出し

簡単な検証として、まず 1～2 件のケースと 2～3 個のステップで実行することをおすすめします。

フェーズ 4：LLM-as-Judge による評価

各ステップの出力を、オラクル LLM-as-judge を使用してゴールドスタンダードと比較します。

評価軸（プロジェクトごとにカスタマイズ可能）：

評価軸	測定内容
内容の一致度	出力は同じ主要なポイントを網羅していますか？
構成の一致度	構成や形式は似ていますか？
詳細の正確性	具体的な主張やデータは正確ですか？
完全性	期待される要素がすべて含まれていますか？

各評価軸には重み（0.0～1.0）があり、ステップごとの合計は 1.0 になります。

フェーズ 5：結果の分析

評価レポートを読み込み、分析します。

1. すべてのケースとステップを通じた全体の類似度スコア
2. ステップごとのスコア — しきい値（デフォルト：70/100）を下回るものを強調します
3. ケースごとのスコア — 一貫して弱いテストケースを特定します
4. 弱いステップの評価軸ごとの内訳

スコアの解釈：

スコア範囲	評価	対応
85-100	優秀	変更は不要です
70-84	良好	軽微な調整が可能です
60-69	改善が必要	プロンプトの改訂をおすすめします
60 未満	不良	プロンプトの書き直しが必要な可能性があります

フェーズ 6：改善案の提案

しきい値を下回るスコアの各ステップについて：

1. 現在のプロンプトテンプレートを読む
2. ゴールドスタンダードの出力（期待値）を読む
3. パイプラインの出力（実際の結果）を読む
4. 比較してギャップを特定する：
   • ゴールドスタンダードに含まれている指示の不足
   • 出力の乖離を招く、広範すぎる指示
   • 形式や構造の違い
   • 具体性の不足

実行可能な提案を提示します：

### Step N: <step_name> (Score: XX/100)

**Weakest Dimension**: <dimension> (XX/100)

**Gap Analysis**:
- Gold standard includes <X> but prompt doesn't instruct it
- Output format diverges: gold uses <format>, output uses <other>

**Suggested Prompt Changes**:
1. Add instruction: "<specific instruction>"
2. Clarify format: "<format guidance>"
3. Add example: "<example output snippet>"

出力構造

eval_runs/YYYYMMDD_HHMMSS/
  results/                    # Pipeline outputs
    case_1/
      step_01_<name>.md
      step_02_<name>.md
      ...
    case_2/
      ...
  evaluation/                 # Judge scores
    evaluation_report.json
    evaluation_report.md
    per_step_scores.csv
    per_case_scores.csv

MCP 連携

PAL MCP（任意）

ツール	使用するタイミング	目的
mcp__pal__thinkdeep	スコアの低いステップ	出力が乖離する理由を深く分析する
mcp__pal__consensus	プロンプトの改訂	提案した変更を複数のモデルで検証する
mcp__pal__codereview	評価スクリプト	評価パイプラインのコードをレビューする

Rube MCP（任意）

ツール	使用するタイミング	目的
mcp__rube__RUBE_REMOTE_WORKBENCH	大規模な評価の実行時	Python サンドボックスで結果を処理する
mcp__rube__RUBE_MULTI_EXECUTE_TOOL	通知時	Slack／メールに結果を報告する

エラー処理

状況	対応
評価スクリプトが見つからない	ユーザーにスクリプトのパスを尋ねる
ゴールドスタンダードが見つからない	ユーザーにゴールドスタンダードのディレクトリを尋ねる
API のレート制限	同時実行数を減らし、遅延を追加する
パイプラインのステップが失敗する	エラーをログに記録し、残りのステップを続行する
評価者が無効なスコアを返す	1 回再試行し、その後、手動レビューの対象としてフラグを付ける
出力ディレクトリが存在する	タイムスタンプのサフィックスを追加する

ガードレール

• 進行状況を確認できるよう、常に --verbose を指定する
• 全件実行の前に API 呼び出し回数について警告する
• 全件評価の前に、サブセットで簡易検証することを提案する
• デバッグ用に、中間出力をすべて保持する
• ゴールドスタンダードのファイルは決して変更しない

ツールの連携

• Bash - 評価スクリプトを実行する
• Read - プロンプト、ゴールドスタンダード、出力、レポートを調べる
• Write - レポートを生成する
• Grep - 出力内のパターンを検索する
• PAL MCP - スコアのギャップを深く分析する