LLM審査員はなぜ失敗するのか：Text-to-SQL本番監査の教訓

導入

Text-to-SQLでは、自然言語からSQLを生成するだけでなく、そのSQLが質問に忠実かを判定する工程が必要になる。本番システムでは、この判定を別の大規模言語モデルに任せる構成が広がっている。しかし、判定役のLLM自体が人間の基準と一致するかは、十分に検証されないまま運用されがちだ。今回のarXiv論文は、実運用のLLM-as-Judgeを人間のアノテーションと比較した。

主な結果

• 本番で使われていたgpt-4o-miniは、モデル間の意見の食い違いを多く含む評価セットで、2人の著者によるゴールド判定とのCohenのκが0.04だった。均一ランダムな抽出による確認でも0.42にとどまった。
• 不一致を強調したセットでは、人間がFAITHFULと判定した例の77.1%を問題ありとして扱った。つまり、誤ったSQLを見逃すだけでなく、正しい回答を過剰に拒否していた。
• こうした過剰フラグの大半は、研究者が「GRADE-HALLUCINATION」と名付けた失敗機構に結び付けられた。審査時に、入力に存在しない評価根拠や前提を持ち込む現象だ。
• 自ホストのQwen3.6-27Bはκ 0.72で、Claude Opus 4.7の0.71と近い値だった。直接比較は96件と小規模で、一般的な優劣を決めるには不十分だが、Qwenの1回あたりコストはおよそ300分の1だった。
• モデルを増やせばよいとは限らない。弱い審査員と強い審査員の組み合わせは一致度を下げた一方、強い審査員3体を全会一致ルールで運用するとκ 0.79、89.7%の自動処理率に達した。

意義と影響

最も重要な示唆は、LLM審査員を評価基盤ではなく、独立して検証すべきモデル部品として扱うことだ。ランダムなサンプルだけでなく、モデル同士が意見を異にするサンプルも人間と比較し、単一の平均指標では見えない過剰拒否や系統的な誤判定を調べる必要がある。

また、品質とコストは必ずしも反比例しない。今回の小規模な比較では、自ホストモデルが高価なクローズドモデルに近い一致度を示した。これは普遍的な勝者を意味しないが、導入判断では精度だけでなく、運用費、データ管理、再現性も見るべきだということを示す。

さらに、アンサンブルの設計も重要になる。弱い審査員を混ぜるだけでは誤りが伝播する可能性がある。全会一致を要求する保守的なルールなら、自動判定率を維持しながら、意見が割れた例を人間や追加監査へ回せる。

研究チームがBIRD-financialに同じ監査手順を適用したところ、専門家作成のゴールドSQLの25.5%が、研究のアノテーション基準の下で潜在的な問題としてフラグ付けされた。これは全てが誤りだという意味ではない。ベンチマークの正解データにも曖昧さがあり得るため、金標準も継続的に監査すべきだという示唆である。

再利用できる実務上の教訓は、事前登録、人間との比較、失敗機構の分類、代替モデルの検証、リスクを考慮したルーティング、そしてゴールドデータの定期的な再点検からなる閉ループだ。

出典：arXiv