AI 評測與開發工具
GSR 將評分規則編譯成型別圖，LLM 裁判精確分數一致率最高增 6.75 點
Graph-Structured Rubrics 在看見待評答案前，先把自然語言 rubric 編譯成具型別的判斷、轉換、聚合與閘門節點。GPT‑OSS‑120B 實驗顯示它優於平面式 Prometheus 評分，但目前未公開程式，增益亦高度依賴資料集。
LLM 裁判通常把整份評分準則塞進提示，要求模型一次理解各條規則及其組合方式；規則中的「全部符合才通過」、「任一缺陷即封頂」或加權關係，往往只存在於自然語言。8 月 12 日提交的 [Graph-Structured Rubrics（GSR）論文](https://arxiv.org/abs/2608.12097)改把 rubric 視為可編譯規格：criterion 節點分別取得局部判斷，transformation、reduction 與 gating operator 經具名 port 組合結果，最後由唯一 sink 的 Readout 映射成分數或偏好。型別不相容、缺少輸入或圖結構不合法時，編譯階段便拒絕執行。
這個設計的重要限制，是評估圖必須在讀取候選答案前建立，降低因答案內容而臨時改寫評準的風險。單答案評分會先獨立判斷各維度，再由圖聚合；成對比較則讓兩個答案通過相同 criterion，並原生保留平手與棄權。作者以 GPT‑OSS‑120B 測試四個 pointwise 資料集，精確分數一致率較 Prometheus 式平面評分提高 0.62 至 6.75 個百分點；兩個 preference benchmark 上也取得最高的端到端數值準確率，但論文摘要沒有宣稱所有差異均達統計顯著。
對評測平台而言，GSR 的價值不只是再寫一種 judge prompt，而是把評分政策變成可檢查、可重用的執行圖，較適合處理安全閘門、必要條件和分層加權。現有 [Prometheus‑Eval](https://github.com/prometheus-eval/prometheus-eval) 已提供絕對與相對評分介面，卻主要仍以文字 rubric 驅動；若要採用 GSR，工程團隊還需自行建立編譯器、節點追蹤與失敗處理。論文目前沒有公開實作，所有數據也只由 GPT‑OSS‑120B 產生。下一步應觀察跨模型重現、圖編譯錯誤率，以及複雜 rubric 是否因更多裁判呼叫而顯著增加成本。