LLM judge、文書の33-67%で一貫性の崩れを隠した
Original: Diagnosing LLM Judge Reliability: Conformal Prediction Sets and Transitivity Violations View original →
LLM-as-judgeはmodel eval、summary評価、agent benchmarkで急速に標準部品になった。4月16日に公開されたarXiv論文Diagnosing LLM Judge Reliabilityは、その前提にある見落としやすい弱点を突く。全体平均では安定して見えるjudgeが、個別入力では矛盾した判断をかなり出している可能性がある。
著者らはSummEvalに2つの診断を適用した。1つ目はtransitivity analysisだ。aggregate violation rateは0.8-4.1%と低く見える。しかし文書単位では、33-67%の文書に少なくとも1つのdirected 3-cycleがあった。つまりAをBより良い、BをCより良いとしながら、同じ評価関係の中でCをAより良いとするような循環判断が起きていた。
2つ目は1-5のLikert scoreに対するsplit conformal prediction setである。この方法は理論上>=1-alpha coverageを与え、prediction setの幅をinstance-level reliabilityのsignalとして扱う。論文はpooled settingで、set widthとabsolute errorがr_s=+0.576、N=1,918、p < 10^-100で結びつくと報告した。幅の広いsetは、judgeが間違えやすい入力を示す実用的な警告になる。
criteria別の結果も実務上重要だ。4つのjudgeと4つのcriteriaを比べると、judgeの種類よりcriterionの違いが大きかった。Relevanceは平均set sizeが約3.0で比較的安定していた。Coherenceは約3.9。Fluencyとconsistencyは約4.9で、1-5のほぼ全域を必要とするほど不安定だった。同じLLM judgeでも、何を評価するかによって信頼度は大きく変わる。
この論文は自動評価を捨てるべきだと言っているわけではない。単一のLLM-judge scoreをきれいな測定値として扱うな、という警告に近い。著者らはcode、prompts、cached resultsを公開するとしている。今後のleaderboardや社内evalでは、scoreだけでなくuncertaintyとinconsistency checkを並べて示す必要が強まった。
Related Articles
HNの熱量は新model名より、adaptive thinking、tokenizer変更、safety filterが実務のagent workflowをどう揺らすかに向かった。Opus 4.7は期待と同時に、最近のClaude品質不信も背負って見られている。
r/LocalLLaMAでMiniMax M2.7が一気に伸びた理由は、Hugging Face公開が単なるchat modelではなく、tool use、Agent Teams、deployment guideまで含むagent systemとして提示されたからだ。初期の関心はbenchmarkの数字だけでなく、実運用を意識したpackagingにも向いている。
Metaは2026年4月8日、Meta Superintelligence Labs初のモデルMuse Sparkを発表した。このモデルはすでにMeta AI appとwebを支えており、WhatsApp、Instagram、Facebook、Messenger、AI glassesにも拡大される予定だ。
Comments (0)
No comments yet. Be the first to comment!