Self-Contrastive Loop of Thought Method for Text-to-SQL Based on Large Language Model

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

# Self-Contrastive Loop of Thought Method for Text-to-SQL Based on Large Language Model
- 自然言語の質問を SQL に変換する text-to-SQL について、少数例プロンプトへの依存を弱める SCL-SQL を提案する。
- 質問をエンティティ部分と骨格部分に分け、関連するスキーマと似た構造の正例を取り出し、失敗例を次の試行で負例として用いる。
- SPIDER と BIRD で評価し、GPT-4o を用いた場合に BIRD 開発セットで実行精度 64.73%、テストセットで 65.23% を報告している。

## 論文の面白いところ

この論文の中心は、SQL 生成を一度で終わらせず、実行結果を見ながら短い反復にする点にある。大規模言語モデルは、似た例を与えると SQL を書きやすくなるが、その例の選び方に結果が左右される。SCL-SQL は、成功した例だけでなく、失敗した SQL とその理由も明示して、次の生成を調整する。ここでいう負例は、単に「間違い」として捨てるものではない。次に同じ誤りを避けるための手掛かりとしてプロンプトに戻される。論文は、この反復を「loop of thought」と呼ぶ。思考過程を長く書かせるよりも、SQL を実行し、結果を確認し、悪い候補を記録するという作業に寄せている。text-to-SQL では、SQL が文法的に正しいだけでは足りず、質問の意図に合った結果を返す必要がある。このため、生成文の自然さではなく、実行と結果を中心に検査する設計は筋がよい。方法は複雑な学習を要しないため、既存の LLM ベースの仕組みに比較的載せやすい。

## 問題設定

text-to-SQL は、利用者の自然言語による質問を、データベースに対する SQL 文へ変換する課題である。たとえば「Alpine 郡にある開校中または閉校済みの学校はいくつあるか」という質問から、適切な表、列、条件を選び、集計を行う SQL を作る。難しさは、質問文とデータベースのスキーマが同じ語を使うとは限らない点にある。表名や列名を誤ると、SQL は実行できないか、別の意味の結果を返す。近年の手法は大規模言語モデルを用い、少数の例をプロンプトに入れて生成を助けることが多い。しかし、少数例の作り方や選び方が変わると性能も変わり、別のドメインでは同じ手順が効きにくい。さらに、複雑な質問を段階的に分解する手法では、途中の誤解が後段へ残ることがある。この論文は、固定された少数例の構成に強く頼らず、実行結果を使って候補を検査しながら SQL を改善する問題として text-to-SQL を扱う。

## 提案手法

提案手法 SCL-SQL は、質問分割、スキーマリンク、正例検索、反復生成、候補選択から成る。まず YAKE により質問からキーワードを取り出し、質問をエンティティ部分と骨格部分に分ける。エンティティ部分は、表名や列名を探すスキーマリンクに使われる。骨格部分は、質問の構造が似た既存例を探すために用いられ、Jaccard 係数で類似度を測る。取り出された Question-SQL 対は [valid] の印を付けた正例としてプロンプトに入る。次に、LLM が SQL 候補を生成し、それを実際に実行する。実行に失敗した SQL、空の結果を返す SQL、質問の意図に合わない結果を返す SQL は、理由付きの [invalid] 例として次の反復に入れられる。反復の上限は実験では 3 回に設定される。負例が増えるにつれて正例数を減らす減衰も入れており、後半の修正が古い正例に引きずられにくくしている。複数の妥当な候補が残る場合は、SQL と実行結果の対を LLM が見比べ、投票により最終出力を選ぶ。

## 結果

実験は SPIDER と BIRD で行われた。SPIDER は 200 データベース、138 ドメインを含む代表的な cross-domain text-to-SQL データセットである。BIRD はより実務寄りで大規模なベンチマークとして扱われ、12,751 件のデータと 95 データベースを含む。評価には、生成 SQL の実行結果が正解に合うかを見る EX と、妥当な SQL の効率も加味する VES が用いられた。SCL-SQL は GPT-4o と組み合わせた場合、SPIDER 開発セットで EX 87.13%、テストセットで 87.37% を示した。BIRD では開発セットで EX 64.73%、VES 66.48%、テストセットで EX 65.23%、VES 70.75% であった。BIRD テストでは、比較対象の MAC-SQL + GPT-4 が EX 59.59%、VES 67.68% であり、提案手法が上回る。基礎モデル別の比較でも、GPT-3.5、GPT-4、GPT-4o のいずれに対しても SCL を加えると実行精度が上がった。特に GPT-4 では BIRD 開発セットの総合精度が 46.21% から 62.25% へ上がり、中程度と難問の部分集合で大きな差が出ている。アブレーションでは、思考ループを外すと 64.73% から 58.34% へ落ち、負例、正例、投票、正例減衰のいずれも寄与している。誤り分析では、残る誤りの多くが条件構築に関わるもので、複雑な WHERE 句の扱いにはなお課題がある。

## 具体例

学校データベースに、schools 表、satscores 表、frpm 表があるとする。入力は「Fresno 郡で、直接資金を受け、受験者数が 250 人以下の学校はいくつあるか」という質問である。SCL-SQL はまず Fresno、directly funded、250 などをエンティティとして扱い、これらに関係しそうな列を探す。同時に、「いくつあるか」「条件を満たすものを数える」という骨格から、COUNT と WHERE を使う似た例を取り出す。最初の SQL が schools 表の City 列だけを見てしまうと、郡名を示す列を取り違える可能性がある。実行結果が得られても、質問が「郡」を聞いているのに「市」を条件にしていれば、論理検証で疑わしい候補になる。この失敗した SQL と理由は [invalid] として次のプロンプトへ戻される。次の反復では、frpm 表の Charter Funding Type や County Name、satscores 表の NumTstTakr を使う方向へ候補が修正される。期待される出力は、該当する学校を数える SELECT COUNT(...) の SQL であり、単に実行できる SQL ではなく、質問の条件を過不足なく含む SQL である。間違えやすい点は、似た名前の表や列を選ぶこと、返すべき値を増やしてしまうこと、日付や数値範囲などの条件を余計に変えることである。

Self-Contrastive Loop of Thought Method for Text-to-SQL Based on Large Language Model

自然言語の質問を SQL に変換する text-to-SQL について、少数例プロンプトへの依存を弱める SCL-SQL を提案する。
質問をエンティティ部分と骨格部分に分け、関連するスキーマと似た構造の正例を取り出し、失敗例を次の試行で負例として用いる。
SPIDER と BIRD で評価し、GPT-4o を用いた場合に BIRD 開発セットで実行精度 64.73%、テストセットで 65.23% を報告している。

論文の面白いところ

この論文の中心は、SQL 生成を一度で終わらせず、実行結果を見ながら短い反復にする点にある。大規模言語モデルは、似た例を与えると SQL を書きやすくなるが、その例の選び方に結果が左右される。SCL-SQL は、成功した例だけでなく、失敗した SQL とその理由も明示して、次の生成を調整する。ここでいう負例は、単に「間違い」として捨てるものではない。次に同じ誤りを避けるための手掛かりとしてプロンプトに戻される。論文は、この反復を「loop of thought」と呼ぶ。思考過程を長く書かせるよりも、SQL を実行し、結果を確認し、悪い候補を記録するという作業に寄せている。text-to-SQL では、SQL が文法的に正しいだけでは足りず、質問の意図に合った結果を返す必要がある。このため、生成文の自然さではなく、実行と結果を中心に検査する設計は筋がよい。方法は複雑な学習を要しないため、既存の LLM ベースの仕組みに比較的載せやすい。

問題設定

text-to-SQL は、利用者の自然言語による質問を、データベースに対する SQL 文へ変換する課題である。たとえば「Alpine 郡にある開校中または閉校済みの学校はいくつあるか」という質問から、適切な表、列、条件を選び、集計を行う SQL を作る。難しさは、質問文とデータベースのスキーマが同じ語を使うとは限らない点にある。表名や列名を誤ると、SQL は実行できないか、別の意味の結果を返す。近年の手法は大規模言語モデルを用い、少数の例をプロンプトに入れて生成を助けることが多い。しかし、少数例の作り方や選び方が変わると性能も変わり、別のドメインでは同じ手順が効きにくい。さらに、複雑な質問を段階的に分解する手法では、途中の誤解が後段へ残ることがある。この論文は、固定された少数例の構成に強く頼らず、実行結果を使って候補を検査しながら SQL を改善する問題として text-to-SQL を扱う。

提案手法

提案手法 SCL-SQL は、質問分割、スキーマリンク、正例検索、反復生成、候補選択から成る。まず YAKE により質問からキーワードを取り出し、質問をエンティティ部分と骨格部分に分ける。エンティティ部分は、表名や列名を探すスキーマリンクに使われる。骨格部分は、質問の構造が似た既存例を探すために用いられ、Jaccard 係数で類似度を測る。取り出された Question-SQL 対は [valid] の印を付けた正例としてプロンプトに入る。次に、LLM が SQL 候補を生成し、それを実際に実行する。実行に失敗した SQL、空の結果を返す SQL、質問の意図に合わない結果を返す SQL は、理由付きの [invalid] 例として次の反復に入れられる。反復の上限は実験では 3 回に設定される。負例が増えるにつれて正例数を減らす減衰も入れており、後半の修正が古い正例に引きずられにくくしている。複数の妥当な候補が残る場合は、SQL と実行結果の対を LLM が見比べ、投票により最終出力を選ぶ。

結果

実験は SPIDER と BIRD で行われた。SPIDER は 200 データベース、138 ドメインを含む代表的な cross-domain text-to-SQL データセットである。BIRD はより実務寄りで大規模なベンチマークとして扱われ、12,751 件のデータと 95 データベースを含む。評価には、生成 SQL の実行結果が正解に合うかを見る EX と、妥当な SQL の効率も加味する VES が用いられた。SCL-SQL は GPT-4o と組み合わせた場合、SPIDER 開発セットで EX 87.13%、テストセットで 87.37% を示した。BIRD では開発セットで EX 64.73%、VES 66.48%、テストセットで EX 65.23%、VES 70.75% であった。BIRD テストでは、比較対象の MAC-SQL + GPT-4 が EX 59.59%、VES 67.68% であり、提案手法が上回る。基礎モデル別の比較でも、GPT-3.5、GPT-4、GPT-4o のいずれに対しても SCL を加えると実行精度が上がった。特に GPT-4 では BIRD 開発セットの総合精度が 46.21% から 62.25% へ上がり、中程度と難問の部分集合で大きな差が出ている。アブレーションでは、思考ループを外すと 64.73% から 58.34% へ落ち、負例、正例、投票、正例減衰のいずれも寄与している。誤り分析では、残る誤りの多くが条件構築に関わるもので、複雑な WHERE 句の扱いにはなお課題がある。

具体例

学校データベースに、schools 表、satscores 表、frpm 表があるとする。入力は「Fresno 郡で、直接資金を受け、受験者数が 250 人以下の学校はいくつあるか」という質問である。SCL-SQL はまず Fresno、directly funded、250 などをエンティティとして扱い、これらに関係しそうな列を探す。同時に、「いくつあるか」「条件を満たすものを数える」という骨格から、COUNT と WHERE を使う似た例を取り出す。最初の SQL が schools 表の City 列だけを見てしまうと、郡名を示す列を取り違える可能性がある。実行結果が得られても、質問が「郡」を聞いているのに「市」を条件にしていれば、論理検証で疑わしい候補になる。この失敗した SQL と理由は [invalid] として次のプロンプトへ戻される。次の反復では、frpm 表の Charter Funding Type や County Name、satscores 表の NumTstTakr を使う方向へ候補が修正される。期待される出力は、該当する学校を数える SELECT COUNT(...) の SQL であり、単に実行できる SQL ではなく、質問の条件を過不足なく含む SQL である。間違えやすい点は、似た名前の表や列を選ぶこと、返すべき値を増やしてしまうこと、日付や数値範囲などの条件を余計に変えることである。