GSR、採点ルールを型付きグラフにコンパイルし、LLMジャッジの完全スコア一致率を最大6.75ポイント向上

LLMジャッジでは通常、採点基準全体をプロンプトに詰め込み、各ルールとその組み合わせ方をモデルに一度で理解させる。「すべてを満たした場合のみ合格」「欠陥が1つでもあればスコアに上限を設ける」といった条件や重み付けの関係は、多くの場合、自然言語としてしか表現されていない。8月12日に提出された[Graph-Structured Rubrics（GSR）の論文](https://arxiv.org/abs/2608.12097)は、rubricをコンパイル可能な仕様として扱う。criterionノードがそれぞれ局所的な判定を取得し、transformation、reduction、gating operatorが名前付きportを介して結果を合成する。最後に、唯一のsinkであるReadoutが、結果をスコアまたは選好へマッピングする。型に互換性がない場合、入力が不足している場合、あるいはグラフ構造が不正な場合は、コンパイル段階で実行が拒否される。

この設計における重要な制約は、候補回答を読み込む前に評価グラフを構築しなければならない点だ。これにより、回答内容に応じて評価基準がその場で書き換えられるリスクを抑えられる。単一回答の採点では、まず各評価軸を独立に判定し、その後グラフで集約する。ペア比較では、2つの回答を同一のcriterionに通し、同点と棄権もネイティブに保持する。著者らがGPT‑OSS‑120Bを用いて4つのpointwiseデータセットで検証したところ、完全スコア一致率はPrometheus方式のフラットな採点と比べて0.62～6.75ポイント向上した。2つのpreference benchmarkでも、end-to-endの数値精度で最高値を記録した。ただし、論文の要旨では、すべての差が統計的に有意であるとは主張していない。

評価プラットフォームにとって、GSRの価値は単に新たなjudge promptを作ることにとどまらない。採点ポリシーを検査・再利用できる実行グラフへ変換するため、安全性ゲート、必要条件、階層的な重み付けの処理に適している。既存の[Prometheus‑Eval](https://github.com/prometheus-eval/prometheus-eval)は絶対評価と相対評価のインターフェースを提供しているものの、現在も主にテキスト形式のrubricによって駆動される。GSRを採用するには、エンジニアリングチームがコンパイラ、ノードトレーシング、失敗処理を独自に構築する必要がある。論文では現時点で実装が公開されておらず、すべてのデータもGPT‑OSS‑120Bのみで生成されている。今後は、モデルをまたいだ再現性、グラフのコンパイルエラー率、複雑なrubricによってジャッジの呼び出し回数が増え、コストが大幅に上昇するかどうかを注視すべきだ。