QueryProof、ルールゲートで誤ったSQLを阻止——7BエージェントのBusiness Truth Rateは56.2%

新たに公開されたWarehouseReliabilityBenchは、Text-to-SQL評価の盲点を補おうとしている。SQLは実行可能で、参照クエリに似ていたとしても、誤った売上定義を採用したり、データのカットオフ日を無視したり、schemaの変更後に非推奨フィールドを読み取ったりする可能性がある。データセットには2つの合成データウェアハウスと400件の固定タスクが含まれ、通常のクエリ、ビジネス定義の曖昧性、データ不足、schema drift、prompt injectionをカバーする。問題のおよそ半数では、数値を返すのではなく、確認を求める、回答を棄権する、または要求を拒否することが正しい動作となる。

そのためQueryProofは、オープンエンドなエージェントループを採用せず、`PARSE`、セマンティックレイヤーの検索、曖昧性チェック、SQLの草案作成、AST検証、実行、結果検証からなる有限状態フローを構築した。7Bモデルが担うのは、指標候補の選択とSQLの作成だけだ。安全性の判定、日付の解析、フィールドのallowlist、回答を返すかどうかはすべて、YAMLセマンティックレイヤーと物理catalogを読み取るルールによって制御される。実行環境ではさらに、読み取り専用のDuckDB、`sqlglot` AST allowlist、タイムアウト、結果サイズ制限により、DDL、DML、外部データ関数を阻止する。

1回のみ実行する80問のテストセットでは、純粋な7B QueryProofのBusiness Truth Rateは56.2%だった。32Bへのエスカレーションルーティングを追加すると、逆に53.7%へ低下した。一方、直接プロンプトを与えた32Bベースラインは30.0%だった。ルーティング版では、正解1件当たりの推定コストが71%低く、誤りであるにもかかわらず成功した回答として扱われる割合も75.4%から35.1%へ低下した。ただし、これは公平なモデルサイズ比較ではない。32Bベースラインには同じルール基盤が与えられておらず、10の問題タイプのファミリー内には相関が存在する。ファミリー単位でリサンプリングすると、両グループ間の差の信頼区間はいずれもゼロを含んだ。プロジェクトは生の出力、事前登録済みプロトコル、ワンクリックで再計算できるワークフローを公開しているが、依然として合成データ上の研究プロトタイプである。今後本当に重要なのは、実環境のセマンティックレイヤー、権限モデル、継続的に変化するデータウェアハウス上でルールの保守コストを測定すること、そして決定論的チェックが「実行可能だがビジネス上は誤っている」回答をどれだけ見逃すのかを明らかにすることだ。