ABACUS-SQL: A Text-to-SQL System Empowering Cross-Domain and Open-Domain Database Retrieval

生成日: 2026-05-24 02:20

# ABACUS-SQL: A Text-to-SQL System Empowering Cross-Domain and Open-Domain Database Retrieval

- ABACUS-SQL は、複数のデータベースがある環境で、自然言語の質問から対象データベースを探し、SQL を生成する text-to-SQL システムである。
- 主な工夫は、open-domain database retrieval、ドメインに合わせた demonstration の拡張と選択、Pre-SQL、Self-debug を組み合わせた点にある。
- Chase-C、SParC、CoSQL の multi-turn text-to-SQL 評価で、Qwen2.5-Coder 単体より実行精度を上げ、特に中国語データセット Chase-C で差が大きい。

## Abstract（日本語訳）

既存の text-to-SQL システムは SQL クエリ生成において大きく進歩してきたが、なお多くの課題を抱えている。既存システムは open-domain データベースに対する検索機能を欠くことが多く、ユーザーは関連するデータベースを手作業で選別しなければならない。さらに、cross-domain transferability が限られているため、多様な問い合わせ要求に対応することが難しい。これらの問題に対処するため、本論文は ABACUS-SQL を提案する。ABACUS-SQL は、open-domain データベース環境において必要なデータベースを正確に特定するために、データベース検索技術を用いる。また、データ拡張手法により、システムの cross-domain transfer 能力を高める。加えて、ABACUS-SQL は Pre-SQL と Self-debug を用いることで、SQL クエリの正確性を向上させる。実験結果は、ABACUS-SQL が multi-turn text-to-SQL タスクで良好に機能することを示し、提案手法の有効性を実証している。ABACUS-SQL は https://huozi.8wss.com/abacus-sql/ で公開されている。

## 論文の面白いところ

この論文の面白さは、text-to-SQL を「SQL を一つ生成する問題」ではなく、「多くのデータベースの中から、会話に合うものを選び、必要な表だけを見て、失敗したら直す問題」として扱う点にある。業務で自然言語からデータを引く場面では、ユーザーが正しいデータベース名やスキーマを知っているとは限らない。既存の実験設定では、対象データベースが最初から与えられていることが多いが、実際の利用ではそこがすでに難所になる。ABACUS-SQL は、この前処理の部分を独立した機能として組み込み、Murre による multi-hop table retrieval を使って関連する表やデータベースを絞り込む。

また、単に retrieval を足しただけではなく、選んだデータベースの性質に近い demonstration を用意する。Fused と呼ぶデータ拡張手法で、既存の question-SQL 例を混ぜ合わせ、新しい demonstration pool を作る。そのうえで BM25 により、現在の質問、schema、対話履歴に近い例を選んでプロンプトへ入れる。ここは、LLM に任せ切るのではなく、古典的な検索と in-context learning を地味に組み合わせているところが実用的である。

## 問題設定

対象は multi-turn text-to-SQL である。ユーザーは自然言語で質問し、システムは SQL を生成し、会話の続きでは前の質問や結果を踏まえて別の SQL を生成する。通常の単発 text-to-SQL と違い、「それを地域別に見せて」や「去年だけにして」のような省略を扱う必要がある。さらに本論文が想定する環境では、対象データベースが一つとは限らない。複数の業務データベースがアップロードされているとき、システムはまずどのデータベースを見るべきかを選ばなければならない。

この設定では、誤ったデータベースを選ぶと、その後の SQL 生成がどれだけ流暢でも意味を失う。反対に、関係のない表を大量にプロンプトへ入れると、LLM は列名や条件を取り違えやすくなる。論文は、この二つを実用上の障害として置いている。評価では、各発話ごとの実行結果を見る Question Execution Accuracy（QEX）と、対話全体で全 SQL が正しいかを見る Interaction Execution Accuracy（IEX）を用いる。IEX は一度の誤りが対話全体に影響するため、multi-turn の難しさをよく表す指標である。

## 提案手法

ABACUS-SQL の処理は、前処理、multi-turn text-to-SQL、提示の三段階で構成される。前処理では、まずユーザーの質問とアップロード済みデータベースの schema やメタデータを照合し、関連しそうなデータベースを探す。ここで用いられる Murre は、関連表を beam search 的に取り出し、取り出した表に関する情報を質問から除きながら、残りの情報に対応する表をさらに探す。これにより、一つの質問が複数の表やデータベースにまたがる場合でも、候補を段階的に集められる。

次に、システムは demonstration を選ぶ。ユーザーが独自データを与えた場合は、その schema と question-SQL 例を使い、与えない場合は既定のデータセットから demonstration を拡張する。Fused は、SQL の構造的特徴に基づいて例をクラスタリングし、そこからサンプルを選び、LLM で新しい question-SQL 例を生成する。生成した例は schema との整合性や冗長性を検査してから pool に加える。推論時には BM25 が、現在の質問、schema、対話文脈に近い demonstration を選ぶ。

SQL 生成では、Pre-SQL と Self-debug が加わる。Pre-SQL は、まず仮の SQL を作り、そこから関係の薄い表や列を落として、最終生成に渡す情報を減らす。Self-debug は、生成 SQL の実行時エラーや構文エラーを、schema と元の質問とともにモデルへ戻し、修正版 SQL を作らせる。バックエンドは FastAPI で実装され、標準の SQL 生成には Qwen2.5-Coder-7B を用いるが、GPT-4o や DeepSeek-R1 などのリモート LLM API も利用できる。フロントエンドは Streamlit で、SQL 生成過程、生成された SQL、実行結果をユーザーに示す。

## 結果

実験は Chase-C、SParC、CoSQL の三つの multi-turn text-to-SQL データセットで行われている。Chase-C は中国語の cross-database、context-dependent text-to-SQL データセットで、280 を超えるデータベースにまたがる。SParC と CoSQL は英語の cross-domain multi-turn text-to-SQL データセットである。評価モデルには Qwen2.5-Coder の 7B と 32B が使われ、推論は 3-shot、temperature 0 に設定されている。

主結果では、ABACUS-SQL を加えることで全データセット、全設定で QEX と IEX が改善している。たとえば Chase-C では、Qwen2.5-Coder-32B の QEX が 46.5 から 53.5、IEX が 18.0 から 23.1 へ上がる。7B 設定でも Chase-C の QEX は 40.4 から 45.5、IEX は 11.1 から 15.0 へ改善する。SParC と CoSQL でも改善はあるが、Chase-C ほど大きくない。論文は、中国語の曖昧性や複雑な schema 対応において、Pre-SQL と Self-debug の効果が出やすいと述べている。

アブレーションでは、Pre-SQL と Self-debug を外すと性能が下がる。特に Self-debug を外した場合、Chase-C の低下が大きい。Qwen2.5-Coder-32B の Chase-C IEX では、Self-debug なしで 23.1 から 19.8 へ落ちる。これは、生成後に実行エラーや解釈のずれを戻して修正する処理が、対話型 SQL 生成で有効であることを示している。一方で、この論文はシステムデモ論文であり、retrieval の失敗例やユーザー研究は詳しく扱っていない。実用システムとしては、誤ったデータベースを選んだときにユーザーへどう確認するかが次の論点になる。

## 具体例

たとえば、会社の分析担当者が、営業データ、顧客サポート、在庫管理の三つのデータベースをまとめて ABACUS-SQL に接続しているとする。ユーザーが「先月、返金が多かった商品の売上も見たい」と質問すると、システムはまず「返金」に関係するサポートまたは注文履歴の表と、「商品」「売上」に関係する販売データの表を探す。Murre は、最初に高く関連する表を取り出し、その表で説明できた情報を質問から取り除き、残った「売上」や「商品」に対応する表をさらに探す。次に、選ばれた schema と似た過去の question-SQL 例を BM25 で選び、LLM に渡すプロンプトを作る。

この段階で Pre-SQL は、在庫数や配送予定のような不要な表を落とし、返金履歴、注文、商品マスタに絞る。モデルは、先月の返金件数で商品を絞り、その商品の売上を集計する SQL を生成する。もし列名を `refund_date` と誤って書いたが、実際には `returned_at` しかない場合、実行エラーが Self-debug に戻される。Self-debug は schema とエラー内容をもとに列名を修正し、再び SQL を出す。間違えやすいのは、「返金が多かった商品」を返金額で見るのか返金件数で見るのかという解釈である。このような曖昧さは SQL の構文だけでは解けないため、システム側が候補 SQL と実行結果を見せ、必要ならユーザーが条件を言い直せる設計が重要になる。

ABACUS-SQL: A Text-to-SQL System Empowering Cross-Domain and Open-Domain Database Retrieval

ABACUS-SQL は、複数のデータベースがある環境で、自然言語の質問から対象データベースを探し、SQL を生成する text-to-SQL システムである。
主な工夫は、open-domain database retrieval、ドメインに合わせた demonstration の拡張と選択、Pre-SQL、Self-debug を組み合わせた点にある。
Chase-C、SParC、CoSQL の multi-turn text-to-SQL 評価で、Qwen2.5-Coder 単体より実行精度を上げ、特に中国語データセット Chase-C で差が大きい。

Abstract（日本語訳）

既存の text-to-SQL システムは SQL クエリ生成において大きく進歩してきたが、なお多くの課題を抱えている。既存システムは open-domain データベースに対する検索機能を欠くことが多く、ユーザーは関連するデータベースを手作業で選別しなければならない。さらに、cross-domain transferability が限られているため、多様な問い合わせ要求に対応することが難しい。これらの問題に対処するため、本論文は ABACUS-SQL を提案する。ABACUS-SQL は、open-domain データベース環境において必要なデータベースを正確に特定するために、データベース検索技術を用いる。また、データ拡張手法により、システムの cross-domain transfer 能力を高める。加えて、ABACUS-SQL は Pre-SQL と Self-debug を用いることで、SQL クエリの正確性を向上させる。実験結果は、ABACUS-SQL が multi-turn text-to-SQL タスクで良好に機能することを示し、提案手法の有効性を実証している。ABACUS-SQL は https://huozi.8wss.com/abacus-sql/ で公開されている。

論文の面白いところ

この論文の面白さは、text-to-SQL を「SQL を一つ生成する問題」ではなく、「多くのデータベースの中から、会話に合うものを選び、必要な表だけを見て、失敗したら直す問題」として扱う点にある。業務で自然言語からデータを引く場面では、ユーザーが正しいデータベース名やスキーマを知っているとは限らない。既存の実験設定では、対象データベースが最初から与えられていることが多いが、実際の利用ではそこがすでに難所になる。ABACUS-SQL は、この前処理の部分を独立した機能として組み込み、Murre による multi-hop table retrieval を使って関連する表やデータベースを絞り込む。

また、単に retrieval を足しただけではなく、選んだデータベースの性質に近い demonstration を用意する。Fused と呼ぶデータ拡張手法で、既存の question-SQL 例を混ぜ合わせ、新しい demonstration pool を作る。そのうえで BM25 により、現在の質問、schema、対話履歴に近い例を選んでプロンプトへ入れる。ここは、LLM に任せ切るのではなく、古典的な検索と in-context learning を地味に組み合わせているところが実用的である。

問題設定

対象は multi-turn text-to-SQL である。ユーザーは自然言語で質問し、システムは SQL を生成し、会話の続きでは前の質問や結果を踏まえて別の SQL を生成する。通常の単発 text-to-SQL と違い、「それを地域別に見せて」や「去年だけにして」のような省略を扱う必要がある。さらに本論文が想定する環境では、対象データベースが一つとは限らない。複数の業務データベースがアップロードされているとき、システムはまずどのデータベースを見るべきかを選ばなければならない。

この設定では、誤ったデータベースを選ぶと、その後の SQL 生成がどれだけ流暢でも意味を失う。反対に、関係のない表を大量にプロンプトへ入れると、LLM は列名や条件を取り違えやすくなる。論文は、この二つを実用上の障害として置いている。評価では、各発話ごとの実行結果を見る Question Execution Accuracy（QEX）と、対話全体で全 SQL が正しいかを見る Interaction Execution Accuracy（IEX）を用いる。IEX は一度の誤りが対話全体に影響するため、multi-turn の難しさをよく表す指標である。

提案手法

ABACUS-SQL の処理は、前処理、multi-turn text-to-SQL、提示の三段階で構成される。前処理では、まずユーザーの質問とアップロード済みデータベースの schema やメタデータを照合し、関連しそうなデータベースを探す。ここで用いられる Murre は、関連表を beam search 的に取り出し、取り出した表に関する情報を質問から除きながら、残りの情報に対応する表をさらに探す。これにより、一つの質問が複数の表やデータベースにまたがる場合でも、候補を段階的に集められる。

次に、システムは demonstration を選ぶ。ユーザーが独自データを与えた場合は、その schema と question-SQL 例を使い、与えない場合は既定のデータセットから demonstration を拡張する。Fused は、SQL の構造的特徴に基づいて例をクラスタリングし、そこからサンプルを選び、LLM で新しい question-SQL 例を生成する。生成した例は schema との整合性や冗長性を検査してから pool に加える。推論時には BM25 が、現在の質問、schema、対話文脈に近い demonstration を選ぶ。

SQL 生成では、Pre-SQL と Self-debug が加わる。Pre-SQL は、まず仮の SQL を作り、そこから関係の薄い表や列を落として、最終生成に渡す情報を減らす。Self-debug は、生成 SQL の実行時エラーや構文エラーを、schema と元の質問とともにモデルへ戻し、修正版 SQL を作らせる。バックエンドは FastAPI で実装され、標準の SQL 生成には Qwen2.5-Coder-7B を用いるが、GPT-4o や DeepSeek-R1 などのリモート LLM API も利用できる。フロントエンドは Streamlit で、SQL 生成過程、生成された SQL、実行結果をユーザーに示す。

結果

実験は Chase-C、SParC、CoSQL の三つの multi-turn text-to-SQL データセットで行われている。Chase-C は中国語の cross-database、context-dependent text-to-SQL データセットで、280 を超えるデータベースにまたがる。SParC と CoSQL は英語の cross-domain multi-turn text-to-SQL データセットである。評価モデルには Qwen2.5-Coder の 7B と 32B が使われ、推論は 3-shot、temperature 0 に設定されている。

主結果では、ABACUS-SQL を加えることで全データセット、全設定で QEX と IEX が改善している。たとえば Chase-C では、Qwen2.5-Coder-32B の QEX が 46.5 から 53.5、IEX が 18.0 から 23.1 へ上がる。7B 設定でも Chase-C の QEX は 40.4 から 45.5、IEX は 11.1 から 15.0 へ改善する。SParC と CoSQL でも改善はあるが、Chase-C ほど大きくない。論文は、中国語の曖昧性や複雑な schema 対応において、Pre-SQL と Self-debug の効果が出やすいと述べている。

アブレーションでは、Pre-SQL と Self-debug を外すと性能が下がる。特に Self-debug を外した場合、Chase-C の低下が大きい。Qwen2.5-Coder-32B の Chase-C IEX では、Self-debug なしで 23.1 から 19.8 へ落ちる。これは、生成後に実行エラーや解釈のずれを戻して修正する処理が、対話型 SQL 生成で有効であることを示している。一方で、この論文はシステムデモ論文であり、retrieval の失敗例やユーザー研究は詳しく扱っていない。実用システムとしては、誤ったデータベースを選んだときにユーザーへどう確認するかが次の論点になる。

具体例

たとえば、会社の分析担当者が、営業データ、顧客サポート、在庫管理の三つのデータベースをまとめて ABACUS-SQL に接続しているとする。ユーザーが「先月、返金が多かった商品の売上も見たい」と質問すると、システムはまず「返金」に関係するサポートまたは注文履歴の表と、「商品」「売上」に関係する販売データの表を探す。Murre は、最初に高く関連する表を取り出し、その表で説明できた情報を質問から取り除き、残った「売上」や「商品」に対応する表をさらに探す。次に、選ばれた schema と似た過去の question-SQL 例を BM25 で選び、LLM に渡すプロンプトを作る。

この段階で Pre-SQL は、在庫数や配送予定のような不要な表を落とし、返金履歴、注文、商品マスタに絞る。モデルは、先月の返金件数で商品を絞り、その商品の売上を集計する SQL を生成する。もし列名を refund_date と誤って書いたが、実際には returned_at しかない場合、実行エラーが Self-debug に戻される。Self-debug は schema とエラー内容をもとに列名を修正し、再び SQL を出す。間違えやすいのは、「返金が多かった商品」を返金額で見るのか返金件数で見るのかという解釈である。このような曖昧さは SQL の構文だけでは解けないため、システム側が候補 SQL と実行結果を見せ、必要ならユーザーが条件を言い直せる設計が重要になる。