SQLでLLM判定を最大14倍速くするQuail

5,000件の医療レポートから「心臓血管系の反応と神経の反応が両方書かれている、重大なもの」を探したいとしよう。キーワード検索では拾いきれない。かといって1件ずつAIに読ませてコードで判定させると、レポートの件数だけAPIを呼ぶことになり、時間もコストもかさむ。この作業を、SQLの中に自然言語の条件を書くだけで済ませる道具が出てきた。カーネギーメロン大学のFull Stack Data Labが2026年9月24日にオープンソースのAI-SQLエンジン「Quail」を公開した。素朴な実装より最大14倍速く終わらせる。

SQLにどう書くのか

Quailは、SQLのWHERE句にAI.IFという関数を挟み、その中にPROMPTで自然言語の質問を書く。公式ブログが挙げている例はこうだ。

SELECT r.review_id
FROM reviews AS r
WHERE AI.IF(
    PROMPT('Does this review discuss the ending of the movie?\n\n{0}', r.review),
    {'selectivity': 0.25}
)
AND AI.IF(
    PROMPT('Does the reviewer recommend watching the movie?\n\n{0}', r.review),
    {'selectivity': 0.5}
)

映画レビューの行に対して「結末について触れているか」「視聴を勧めているか」という2つの条件を、そのままWHERE句に書いている。{'selectivity': 0.25}は「この条件を通るのは全体のだいたい25%程度」という見積もりで、この数字が後の順序の判断に使われる。SnowflakeのAI_FILTER、BigQueryのAI.IF相当の構文に対応しており、行ごとにAPIを呼ぶコードを書かずに済む。ここまでは「SQLで自然言語条件を書ける」という新しい書き方の話だが、Quailの売りは書き方ではなく速さにある。同じことをするツールは他にもありそうなのに、何が違うのか。

なぜ順番を工夫するのか

Quailの公式ブログは、速さの理由の1つとして順序付けを挙げている。条件の見積もりコストと選択性(selectivity、その条件で行がどれだけ絞り込まれるか)にもとづく判断で、「よく知られた既存の手法にならった」ものだという。データベースの世界では、WHERE句に複数の条件がある場合、絞り込みが強い条件を先に評価して残りの行数を早く減らすという最適化が昔からある。Quailはこの発想を、LLMによる判定にもそのまま持ち込んだ。

先の例で言えば、「結末について触れているか」(selectivity 0.25)を先に評価すれば、その時点で全体の75%の行が脱落する。次の「視聴を勧めているか」を評価するのは、残った25%の行だけでよくなる。順番を逆にすれば、50%しか絞り込めない条件を先に全行へかけることになり、無駄が増える。ここまでは条件の「順番」の工夫だが、Quailはもう1つ、行の中身そのものの扱い方も工夫している。それが次の疑問になる。

なぜキャッシュを使い回すのか

順番の工夫だけでも速くなるが、Quailの公式ブログが挙げる医療レポートの実例では、これだけでは説明のつかない差が出る。5,000件のレポートを、4,144種類の反応用語のそれぞれと「この用語の反応が書かれているか」で2回ずつ照合する処理だ。レポート1件につき、反応用語8,288通りとの比較が発生する計算になる。

ここで差を生むのが、KVキャッシュの使い回しだ。LLMは文章を読むとき、内部に「KV(キー・バリュー)」と呼ばれる下ごしらえ済みの状態を作る。公式ブログによれば、比較対象のstock vLLMは、同じレポート(アンカー)を新しい反応用語と比べるたびに、そのアンカーのKVを毎回読み直している。自分はここで、同じ資料をなぜ毎回読み直すのか最初は不思議に思った。自分の理解では、比べる処理を1回ごとに独立した計算として扱っているからで、前の計算で作ったKVを次へ持ち越す仕組みがなければ、読み直す以外の選択肢がない。

Quailはこの読み直しを無駄だとみなし、レポート側(アンカー)のKVを1回作ったら使い回し、比べる相手(反応用語)だけを差し替える設計にしている。資料を開いたままにして、隣に並べる相手だけを取り替えるようなものだ。同じ資料を読み直さない分、その読み直しに使っていた計算がまるごと浮く。

この2つの工夫(順番とキャッシュの使い回し)を合わせた結果、実際の数字はどうなるのか。

どれだけ速く安くなるか

Quailは29個のクエリからなる自社ベンチマーク「QUAIL-B」で、比較対象のstock vLLMより27個で高速だったと報告している。自分はここまでの説明から、平均でも数倍は縮むと予想していた。実際の平均は1.84倍(幾何平均)、最大でも11.22倍(BIO-2というクエリ)にとどまり、拍子抜けした。ただしこの数字は「スケールファクター0.1」という小さめの条件で測ったものだ。

先に挙げた医療レポートの実例(BIO-4)は、これとは別に、実データに近い「スケールファクター1.0」で測っている。

この図が示すとおり、stock vLLMで6.84時間かかっていた処理が、Quailでは29.26分で終わる。公式ブログの計測では、1クエリあたりのコストも27.03ドルから1.93ドルに下がり、14.04倍という数字になる。理論上の下限(「Speed of Light」、GPUが常に最大効率で動き続けたと仮定した楽観的な見積もり)は14.91分とされている。Quailの29.26分はそこまでは届かないものの、6.84時間からは大きく縮まっている。

ただし、この2つの数字は同じ条件で測ったものではない。

• QUAIL-B平均1.84倍・最大11.22倍: スケールファクター0.1という小さめの条件、29クエリの総平均
• BIO-4の14.04倍: スケールファクター1.0という実データに近い規模、医療レポート5,000件・反応用語4,144件という単独のクエリ

つまり、「順番とキャッシュを工夫すれば常に14倍速くなる」わけではない。QUAIL-Bの平均が1.84倍にとどまったのに対し、BIO-4だけ14倍に達している。同じアンカーを何千通りもの相手と繰り返し比べる結合処理を含み、その処理の形がキャッシュの使い回しに向いていたからだ。この数値はいずれもFull Stack Data Lab自身の計測で、第三者による再現は確認できていない。効果の大きさは、自分のクエリが同じような「同じ行を何度も比べる」形をしているかどうかで変わってくる。

自分で試すには何がいるか

Quailを動かすには、いくつか前提が要る。

• MITライセンスで公開されており、uv pip install quail-engine(バージョン0.1.0)で導入できる
• Python 3.12以上とCUDA対応GPUが必須。公式ブログの計測はH100 SXM 1基が基本で、RTX PRO 6000 Blackwellでの評価も併記されている
• 対応モデルはQwen3 4B FP8・Qwen3 32B FP8・DiffusionGemma 26B-A4B FP8の3つに限られる

つまり現時点では、自分のノートPCにインストールしてすぐ試せる道具ではなく、GPUを用意できる開発者向けの部品になる。GitHub上の今後の開発予定には、GPU以外のメモリ層の活用や、より軽量なモデルでの実行が挙がっており、対応の幅は今後変わる可能性がある。

まとめ

Quailは、SQLのWHERE句に自然言語の条件を書けるAI-SQLエンジンだ。データベースが昔からやってきた「絞り込みの強い条件を先に評価する」という最適化と、LLMの下ごしらえ(KVキャッシュ)を使い回す工夫を組み合わせている。29クエリの自社ベンチマーク平均は1.84倍にとどまる。だが同じ行を何度も比較する医療レポートの実例では、6.84時間かかっていた処理が29.26分、コストは27.03ドルから1.93ドルまで縮んだ。効果の大きさはクエリの形に左右されるため、自分が処理したいデータが「同じ行を繰り返し比べる」形をしているかどうかが、試す価値があるかどうかの目安になる。