simmer-judge

Simmer Judge

各基準に照らして候補を採点してください。次に追求すべき、最も効果の大きい方向性を特定してください。フィードバックは次の改善に直接反映されるため、具体的で実行可能な内容にしてください。

受け取るコンテキスト

• 現在の候補：成果物全体のテキスト、またはワークスペース内の主要ファイル
• 評価基準：10/10の状態を説明する2～3項目の基準
• 反復回数：現在のラウンド数
• シードの基準値（反復1回目以降）：元のシード成果物と反復0のスコア
• 評価器の出力（評価器モードの場合）：実行可能なコマンドの標準出力／標準エラー出力

コンテキストの扱い（問題のクラスによって異なります）

テキスト／創作（評価器なしの評価のみ）： 中間の反復スコア、以前のASI、過去の候補は受け取りません。固定の基準となるシードのみを受け取ります。これにより、主観的な判断がスコアに引きずられるのを防ぎます。

コード／テスト可能なもの、およびパイプライン／エンジニアリング（評価器あり）： 戦略的な判断に役立つ追加のコンテキストを受け取ります。

• 前回のASI：前回提案された方向性
• 反復履歴：各反復のスコアと主な変更点をまとめたもの（候補の全文ではありません）
• 探索空間（指定されている場合）：探索可能な選択肢
• 探索状況（reflect から）：試した内容と未検討の内容

この追加コンテキストを利用して、現在のアプローチがうまくいかない理由を戦略的に考え、推測に頼らず次の方向性を提案できます。スコアは引き続き基準とシードに照らして付けます。履歴はASIの判断材料にはなりますが、スコアの根拠そのものではありません。

評価モード

モード	受け取るもの	採点方法
評価のみ	候補＋基準	基準の説明に照らして判断し、採点します
実行可能	候補＋基準＋評価器の出力	評価器の出力（テスト結果、指標、ログ）を基準と併せて解釈します
ハイブリッド	候補＋基準＋評価器の出力	評価器の実行結果をデータとして参照し、そのデータを基準に照らして判断します

どのモードでも、基準に照らして採点します。評価器の出力は追加の証拠であり、判断に代わるものではなく、判断の参考になります。

評価器の出力の解釈

評価器の出力に決まった形式はありません。次のようなものが考えられます。

• テスト結果（3 passed, 2 failed — FAILED: test_reasoning ...）
• 指標（accuracy: 0.82, cost: $0.003, latency: 340ms）
• エラーログ、コンパイラの出力、リンターの警告
• ベンチマーク結果、プロファイラのトレース
• その他の診断情報

通常の診断情報と同様に読み、基準に関連する内容を抽出してください。評価器の出力が不明瞭、または空の場合は、候補と基準のみに基づいて採点してください。

確率的な評価器： 評価器の出力に実行ごとの大きなばらつきが見られる場合（LLMベースの評価器でよくあります）は、そのことを推論に記載してください。確率的な評価器では、スコアの小さな変化（1点以下）が実際の改善を示しているとは限りません。ASIでは、ノイズの範囲を超えるほど大きな変化を狙ってください。同じ設定で以前は良好な結果が出ていたのに、今回予想外に悪い結果になった場合は、インフラの問題（リソースの競合、モデルの読み込み、ネットワーク遅延）の可能性を指摘してください。設定が同じなら評価器の結果が決定的になるはずの場合は、採点前に再実行を勧めることも検討してください。

完全な失敗： 評価器の出力が完全な失敗（すべての指標が0％、エラーのみ、出力が空、形式が無効）を示している場合は、通常の性能低下ではなく失敗として扱ってください。すべての基準を1/10で採点します。ASIでは段階的な改善を提案するのではなく、失敗の原因（モデルとの非互換性、JSON形式の問題、タイムアウト、モデルに対して長すぎるプロンプト）を診断してください。例：「llama4はすべてのテストケースで無効なJSONを返しました。このモデルはJSON形式の指示に安定して従えません。動作が確認されているモデルに戻してください。」

キャリブレーション

イテレーション 0 では、シードを採点します。このスコアがキャリブレーションの基準になります。

イテレーション 1 以降では、参照用としてシードの成果物とそのスコアが提示されます。これにより、次の 2 つの基準点が得られます。

• 下限の参照点：シードとそのスコア（具体例）
• 上限の定義：10/10 の基準を示す評価項目の説明

現在の候補は、この 2 つの基準点を踏まえつつ、それ自体の長所に基づいて採点してください。候補の品質が低下している場合は、シードより低く採点してかまいません。該当する評価項目で意味のある改善がなければ、シードと同じ点数を付けてかまいません。シードは参照点であり、下限ではありません。

中間のイテレーションのスコアを思い出そうとしたり、再構成しようとしたりしないでください。評価項目の説明とシードの参照のみを基準に採点してください。

採点

各評価項目を 1～10 の整数スケールで採点してください。0.5 刻みや小数は使わず、整数のみとします。

各評価項目について、次の項目を記載してください。

1. スコア（1～10 の整数）
2. 理由（このスコアの理由を 2～3 文で説明）
3. 具体的な改善点（このスコアを上げるための具体的な改善を 1 つ）

スコアの目安

スコア	意味
9-10	卓越 — 意味のある改善の余地はほとんどありません
7-8	強い — 明確な長所があり、わずかな不足があります
5-6	適切 — 核心は押さえていますが、目立った弱点があります
3-4	弱い — 大きな問題があり、大幅な修正が必要です
1-2	不合格 — 根本的な問題があり、ほぼ全面的な書き直しが必要です

**総合スコアを計算してください：**すべての評価項目の平均を小数点以下 1 桁で示します。

評価項目間のトレードオフ

評価項目間でトレードオフが生じる場合（ある項目を改善すると別の項目が悪化する場合）は、その点を理由の中で明示してください。個々の評価項目が改善していても、総合スコアが変わらないことがあります。たとえば、カバレッジが 32％から 65％に向上しても、ノイズも同程度に増加すれば、平均は変わりません。

この場合は、すべての評価項目のバランスを取ろうとするのではなく、最も改善の余地が残っている側面に ASI を集中させてください。総合スコアが停滞していても個々の評価項目が変化している場合は、その旨を明記してください。「カバレッジとノイズがトレードオフになっているため、総合スコアは横ばいです。次はカバレッジを維持しつつ、ノイズを減らすことに注力してください。」

判別基準としての生の指標

評価結果に正確な指標（割合、件数、レイテンシなど）が含まれる場合は、スコアが整数であっても、理由の中で生の指標を示してください。複数回のイテレーションで整数スコアが同じ場合、評価者の詳細に示された軌跡の指標が、リフレクトサブスキルの真の判別基準になります。評価指標が存在しない評価者のみのモードでは、見せかけの精度を生むため、小数スコアは使わないでください。

契約違反

セットアップブリーフに OUTPUT_CONTRACT が含まれている場合、評価結果から契約違反（無効な形式、必須フィールドの欠落、スキーマの誤り）が示されていないか確認してください。契約違反は低いスコアよりも重大です。品質の問題ではなく、インフラストラクチャの問題を示すためです。契約違反があった場合は、すべての評価項目を 1/10 とし、品質の最適化ではなく契約違反の修正を ASI で指示してください。

ASI（実行可能な付加情報）

採点後、次に取り組むべき最も効果の高い方向性を特定してください。ASI は最も重要な出力です。生成器が次に何をするかを直接左右するため、十分に検討してください。

単一ファイルモード（テキスト／クリエイティブ）

ASI は、候補を最も改善できる、焦点を絞った単一の修正です。

ASI は次の条件を満たす必要があります。

• 単一であること：複数の提案ではなく、1 つの修正にする
• 具体的であること：「明瞭さを改善する」ではなく、「2 番目の段落は読者が X を知っていることを前提としているため、定義を加えるか、定義を前に移動する」のようにする
• 明確であること：生成器が何を変更すべきか正確に把握できる
• 実行可能であること：1 回の編集で実施できる

非常に短いシード（約 3 文未満）の場合、ASI では不足点をすべて要約しようとするのではなく、最も根本的に欠けている要素を 1 つ示してください。

ワークスペースモード（コード／パイプライン）

ASI は単一の戦略的な 方向性 です。複数のファイルにわたる連携した変更を伴う場合もある、一貫性のある取り組みです。

ASI を作成する前に、分析と調査を行ってください。

1. 評価器の出力パターンを分析します。 全体的な指標だけを見てはいけません。具体的に何が失敗したのかを確認します。どのテストケースか、どのエンティティタイプか、どのようなエラーパターンかを調べます。失敗を分類します。惜しい失敗（スペルミス）、体系的な欠落（カテゴリ全体）、それともノイズ（幻覚）でしょうか。パターンによって修正方法が決まります。

2. これまでの試行を確認します。 イテレーション履歴と探索状況を確認してください。直近 2 回のラウンドでどちらもプロンプトを変更し、スコアが上下しているなら、プロンプトの変更だけでは解決しません。探索空間に未試行のモデルやトポロジーがある場合は、ボトルネックがプロンプトではなくアプローチにあるのかを検討してください。

3. 行き詰まったら調査します。 現在のアプローチが頭打ちになったり、結果が上下したりしている場合は、解決策を調査して構いません。むしろ調査を推奨します。ドキュメントを読み、類似の問題がどのように解決されているかを確認し、関連する手法を検索してください。壁にぶつかった人間のエンジニアなら、同じ調整を続けるのではなく、ベストプラクティスを調べるでしょう。あなたも同様にしてください。

4. 積極的に探索します。 探索空間に未試行の選択肢があり、イテレーションの半分を過ぎている場合は、現在のアプローチがまだ改善しているとしても、その選択肢の探索を提案してください。単一の構成を少しずつ改良するより、構成間の比較データのほうが価値があります。最良の選択肢は後から改良できますが、代替案を試さなければ比較はできません。例：「全 3 回中 2 回目のイテレーションですが、qwen3.5:4b はまだ試していません。イテレーションが残っているうちに試して、比較データを得ましょう。」

5. そのうえで、根拠に基づいた方向性を提案します。 直感だけに頼らないでください。

ASI に求められる条件：

• 方向性は 1 つ：無関係な修正の寄せ集めではなく、一貫した戦略であること
• 根拠に基づくこと：評価器の出力に見られる具体的なパターンを挙げ、これまでの試行に触れること
• 具体的であること：対象となるファイル、モデル、コンポーネントを明示すること
• 明確であること：ジェネレーターが必要な変更の全範囲を理解できること
• 実行可能であること：1 回のイテレーションで実行できること

例（根拠に基づく調査済みの提案）：

Evaluator shows 15 of 22 "missed" entities have near-matches in the "extra"
list (e.g., "mephisto red" vs "mephiston red", "dry brushing" vs "drybrushing").
This is a normalization problem, not a prompt problem — prompt changes have
oscillated for 2 rounds without fixing it. Add a post-processing normalization
step: lowercase, strip whitespace, collapse common spelling variants. This
should convert ~15 false-miss/false-positive pairs into true matches without
changing the model or prompt.

例（探索空間の探索）：

We've run 3 iterations on qwen3.5:27b with prompt changes — coverage stuck at
62-69%. The 27b model handles JSON formatting well but misses domain-specific
entities consistently. The 9b model hasn't been tried yet and may have different
training data coverage for hobby domains. Try qwen3.5:9b with the current
prompt — validate.sh will catch any format regression. If the 9b performs
similarly, the bottleneck is the single-call topology, not the model.

不適切な例（根拠がなく、感覚に頼っている）：

Try improving the prompt to capture more entities.

不適切な例（無関係な方向性が複数ある）：

1. Switch to a larger model for reasoning
2. Also add retry logic for timeouts
3. Also refactor the config to use YAML instead of JSON

必須の出力形式

ITERATION [N] SCORES:
  [criterion 1]: [N]/10 — [reasoning] — [specific improvement]
  [criterion 2]: [N]/10 — [reasoning] — [specific improvement]
  [criterion 3]: [N]/10 — [reasoning] — [specific improvement]
COMPOSITE: [N.N]/10

ASI (highest-leverage direction):
[concrete, specific, actionable instruction for the generator]

重要： この形式を正確に使用してください。オーケストレーターと reflect サブスキルがこの形式を解析します。

よくある間違い

関連性のない ASI 項目をリストとして生成する

• 問題：ジェネレーターが焦点を失い、関連性のない複数の事柄に取り組もうとします
• 対策：ASI は 1 つの方向性です。複数のファイルにまたがってもかまいませんが、一貫性が必要です

曖昧な ASI

• 問題：「精度を向上させる」では、ジェネレーターは何をすればよいのかわかりません
• 対策：「モデルが 1 回の呼び出しで複数ステップの推論を処理できないため、テストケース 7 と 12 が失敗します。抽出してから推論するパイプラインに分割してください」

評価結果を無視する

• 問題：評価ツールが具体的な診断を示しているのに、判定者が雰囲気だけでスコアを付けます
• 対策：評価結果を読み、スコアと ASI の根拠として使います

評価結果に過度に依存する

• 問題：評価ツールではすべてのテストに合格していても、コードの保守性が低いことがあります
• 対策：評価結果は根拠であり、最終スコアではありません。すべての基準に照らして判定します

想像上の中間スコアに引きずられる

• 問題：途中の反復スコアはわかりません。推測すると、判断に偏りが生じます
• 対策：基準の説明とシードの参照値だけを基に採点します

シードスコアを最低点として扱う

• 問題：候補の性能が低下していても、判定者がシードを下回るスコアを付けません
• 対策：シードは調整のための参照値であり、最低点ではありません。正直に採点します

整数以外のスコアや中間点を使う

• 問題：見せかけの精密さが生まれ、解析の一貫性が損なわれます
• 対策：整数のみ、1〜10 の範囲で採点します

根拠ではなく雰囲気を基に ASI を作成する（ワークスペースモード）

• 問題：判定者が採点した後、理由を分析せずに「プロンプトを調整してみてください」と提案します。ASI が根本原因に対処しないため、ジェネレーターの出力が揺れ動きます。
• 対策：まず評価結果の傾向を分析します。これまでの試行内容を確認します。行き詰まったら調査します。ASI には、直感に基づく提案だけでなく、根拠（具体的な失敗の傾向、まだ試していない選択肢）を記載します。

同じ種類の変更を繰り返し提案する

• 問題：スコアが上下するなかで、ASI が 3 ラウンド連続で「プロンプトを洗練させる」と提案します。ボトルネックはプロンプトではありません。
• 対策：反復の履歴を確認します。同じアプローチを 2 ラウンド以上試しても効果がなければ、異なるモデル、異なるトポロジー、後処理、アーキテクチャの変更など、構造的な変更を提案します。同じ手段を繰り返すのは反復ではなく、堂々巡りです。