本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。

OpenSearch-SQL: Text-to-SQL技術の進化と詳細分析

著者: Wenyun

1. はじめに

Text-to-SQLタスクは、自然言語のクエリをStructured Query Language (SQL)に変換し、技術的知識がなくてもデータベースへのアクセスや操作を容易にすることを目指しています。最近、アリババクラウドのOpenSearchエンジンは、一貫性調整技術のおかげでBIRDデータセットのリーダーボードでText-to-SQLタスクにおいてトップランクを達成しました。この記事では、Text-to-SQL技術の進化について紹介し、OpenSearch-SQLアプローチの詳細な分析を行います。

出典: 2024.8.29

さらに、Text-to-SQL機能はアリババクラウド OpenSearchで利用可能です。ぜひ試してみてください。
プラットフォーム: https://www.alibabacloud.com/help/en/open-search/search-platform/

2. 背景

Text-to-SQL分野の研究には長い歴史があり、その核心は自然言語で質問を投げかけ、正確なSQLクエリ結果を得ることです。過去には、複雑な文法と論理的な要件により、Text-to-SQL分野は主に学術的に重要でした。しかし、大規模モデル技術の発展により、産業レベルのText-to-SQLソリューションが登場し始めました。Text-to-SQL技術の主な課題は、ユーザーの意図を正確に解析し、質問内のエンティティと関係を特定し、それらをデータベースのテーブル、列、対応するSQL操作にマッピングすることです。この過程では、モデルが強い言語理解能力を持つだけでなく、SQL構文の深い理解と様々なデータベース構造に対する良い汎用性も必要です。

この分野の進歩のために、WikiSQL、Spider、BIRDなどの公開データセットとベンチマークテストが導入されました。これらはモデルのトレーニングと評価の基準を提供し、技術的な交流と競争を促進しています。これらの豊富なリソースにより、Text-to-SQLシステムは単純なクエリから複数の推論、比較操作、集約関数を含む複雑なSQLクエリまで対応できるようになり、適用範囲が大幅に拡大しました。以下は、Text-to-SQLの簡単な例です：

深層学習によるText-to-SQLアプローチの調査

3. 技術の進化

3.1 伝統的手法

3.1.1 スケッチベース

これらの手法はSQLの構造に基づいており、SQL生成プロセスをSELECT、AGG関数、WHERE条件など複数のサブモジュールに分解します。その後の生成では、これらのモジュール内の各スロットに対して具体的な手法を選択することで、生成されるSQLの柔軟性と精度を高めます。Seq2SQLは、このアプローチの初期の代表的なもので、ニューラルネットワークの分類タスクを使用して分解された構造内のスロットの内容を予測および埋め込みます。このアーキテクチャベースの分解はText-to-SQLタスクの複雑さを大幅に簡素化しますが、より複雑なSQLに対処する能力を制限します。例えば、WikiSQLのような比較的単純なデータセットでは良好な結果を達成できますが、Spiderのような複雑な構文を含む問題では、多くの場合望まれる結果を達成できません。

Seq2SQL: 強化学習を使用した自然言語からの構造化クエリ生成

他の類似のアプローチにはCoarse2FineとRYANSQLがあります。これらは特定の構造内のスロットの内容だけでなく、自然言語クエリ（NLQ）の構造を最初に生成しようとするモデルも試みています。この強化により、複雑な構文と多様なデータベース環境を扱う際のスケーラビリティが向上します。

3.1.2 中間言語ベース

一部の研究者は、直接SQLを生成するよりも、デコードプロセス中に他のコンテンツを生成することで自然言語との一貫性を維持することが容易であることに気づきました。これは中間言語を生成し、その後にSQLを生成する中間言語ベースのアプローチです。

クロスドメインデータベースでの複雑なText-to-SQL向けの中間表現

例えば、IRNetはSemQL専用の中間言語を構築し、この中間表現を通じてSQL生成プロセスを簡素化します。中間言語が生成されると、最終的なSQLの生成プロセスが続きます。

3.1.3 まとめ

伝統的なモデルベースの手法には、従来のエンコーダーの代わりに事前学習モデルを使用するアルゴリズム、グラフ構造で構文木を解析するアルゴリズム、データベース情報のフィルタリングに焦点を当てるアルゴリズムなどが含まれます。全体として、スケッチベースと中間言語ベースの方法は、モデルの能力の制限を補完するために役立ちますが、最終的に生成されるSQLの効果は研究者が設計した手動の構造の表現力に大きく依存し、これらの方法の転送可能性を制限します。

3.2 LLM手法

LLMの能力が向上するにつれて、LLM駆動のアプローチは伝統的な方法と比べてより高い転送可能性と推論能力を示しており、Text-to-SQLタスクを新たな段階へと進めています。この段階では、手動で設計されたフレームワークに束縛されることなく、より複雑なSQLタスクを効果的に処理することができます。データセットの観点から、LLM駆動の方法が直面するタスクの難易度は、徐々にSpiderからBIRDへと移行しており、より複雑なクエリを扱う能力が大幅に改善していることを示しています。例えば、伝統的な方法で使用される古典的なモデルT5-Baseは、Spiderで71.1%の精度を達成しますが、BIRDではわずか7.06%です。一方、GPT-4はSpiderで83.9%、BIRDで54.89%の精度を達成しています。この比較は、LLM駆動の方法が転送可能性とより複雑な問題への対処において顕著な利点を持っていることを反映しています。

3.2.1 標準フレームワーク

LLM駆動のText-to-SQLタスクの明確に定義された統一フレームワークはありませんが、現在有効なフレームワークは以下の4つの部分に要約できます：

準備フェーズ: データベースに必要な情報を収集し、各ステップで使用されるDDLをクリーニングします。データベースに保存されている値を処理し、ベクトルデータベースを維持します。Few-shotの例を準備

最適化エージェント

生成されたSQLの実行結果に基づいて、SQLを修正・改善し、最終的に最適化されたSQLクエリを作成します。v1バージョンでは良い結果が得られましたが、深層分析により、マルチエージェント協調時の生成フェーズの複雑さと指示の従わないことが、LLMが正確なSQLを生成しない主な理由であることがわかりました。具体的な問題は以下の通りです。

生成フェーズの高複雑性:
テーブル、列、値などのSQLコンポーネントを完全なSQLクエリに変換するプロセスには複雑な推論が必要です。現在の方法では、モデルが直接この変換を完了することが求められることが多いですが、これは生成タスクの難易度を増加させます。
指示の従わない:

フィールドと値の抽出: 抽出された内容が不完全または一貫していない。
生成フェーズ: 生成フェーズで抽出された情報を十分に活用していない。
SQLスタイルの不一致: 生成されたSQLは論理的には正しいかもしれませんが、データベースが期待するスタイルと一致しない場合がある。
要件の無視: プロンプトで明確に要件が述べられている場合でも、LLMはこれらの要件を無視する可能性がある。

OpenSearch-SQL, v2

v1バージョンの問題を解決するために、OpenSearch-SQL, v2では最初に次の2つの問題を定義しました。

SQL生成の難易度をどのように低減するか: 逐次生成
LLMの指示遵守率をどのように向上させるか: 一貫性の調整

4.2.1 逐次生成

SQL生成プロセスの複雑性を低減するために、新しいアプローチを導入して生成タスクを分解しました。既存のいくつかの方法では、SQL生成をサブタスクに分割し、その後結合しますが、実際のシナリオでは、この分解は生成チェーンを長くし、分解と再結合の過程で誤差を引き起こす可能性があり、個々のサブSQLを効果的に組み合わせることが難しくなります。したがって、我々の目標は、生成プロセスを簡素化しながら誤差の蓄積を減らし、全体的なSQL生成の精度と効率を向上させるより効率的な分解方法を設計することでした。我々は、SELECT、WHERE、GROUP BYなど、SQLの異なる部分を逐次生成することを提案します。そのため、COTアプローチを使用して、SQL内のSELECT、列、値、およびSQL自体を徐々に生成し解析します。

例：「数学の平均点が最も高い学校の電話番号は何ですか？」

#reason: 問題は学校の電話番号を求めているため、SQL SELECT schools.Phone であり、条件は数学の平均点が最も高い学校である。
#columns: schools.Phone, schools.CDSCode, satscores.AvgScrMath
#values: 数学の最高平均点は ORDER BY satscores.AvgScrMath DESC LIMIT 1 で表される。
#SELECT: 学校の電話番号は schools.Phone である。
#SQL-like: SELECT schools.Phone FROM schools ORDER BY satscores.AvgScrMath DESC LIMIT 1
#SQL: SELECT T1.Phone FROM schools AS T1 INNER JOIN satscores AS T2 ON T1.CDSCode = T2.cds ORDER BY T2.AvgScrMath DESC LIMIT 1

このようなアプローチの利点は以下の通りです：

ステップ間のギャップが最小限に抑えられるため、SQL生成プロセスのどの部分が問題を引き起こしているのかを特定しやすくなります。
逐次生成では、JOINのような文法的に重要度が低い情報は後回しにすることができます。
COTフレームワーク内で一度にタスクを完了することで、マルチエージェント協調による不一致を避けることができます。

4.2.2 一貫性の調整

2つ目の問題については、まず、サブタスクのパフォーマンスを向上させる古典的な方法であるポストトレーニングを分析しました。SFT、RLHF、DPOなどのポストトレーニング手法は、一般的な能力を低下させる可能性がありますが、サブタスクのスタイルを迅速に整えるのに効果的です。しかし、この調整にはいくつかの課題があります。

データ準備と不確実性: サブタスクの調整には大量のデータを準備し、不確実なトレーニング結果に対処する必要があります。一般的な方法は、Text-to-SQLタスクのSQL生成ステップにのみSFTを適用し、他の部分はGPT-4のような大規模なベースモデルに依存することです。この戦略はデータ要求を減らしますが、モデルの潜在能力を完全に活用できない可能性があります。
一般的な能力の損失: このトレーニングアプローチは、多くの場合、モデルの一般的な能力を低下させます。例えば、パラメータ数が少ない大規模モデルでは、SFTは単純な問題に対するパフォーマンスを大幅に向上させるかもしれませんが、より複雑または挑戦的な問題に対してはパフォーマンスが逆に低下する可能性があります。これは、タスク固有のトレーニングに依存すると、モデルの幅広いアプリケーションへの適応性が損なわれる可能性があることを示しています。

したがって、サブタスクの調整においては、一般的な能力を犠牲にすることなく整合性を達成する方法を見つける必要があります。実践的には、大規模なベースモデルは複雑なタスクを扱う際に指示を正確に従えないことが多く、これがSFTモデルよりも性能が劣る大きな理由であることがわかりました。そこで、Agentフレームワーク内で大規模モデルの指示遵守を改善できるかどうかというアイデアから、一連の実験を行い、以下の2つの重要な現象を観察しました。

難易度の相関: 複雑なタスクを単純なサブタスクに分解すると、これらのサブタスクの指示遵守率が高くなる。
生成の変動性: モデルが正しく生成できるSQLクエリであっても、一定の確率で誤りが発生し、この確率は問題の難易度と正の相関がある。実験的には、同じプロンプトでも2つの実験で約10%の悪影響が見られる。

これらの観察に基づいて、OpenSearch-SQLではDouble Check + Voteメカニズムを実装しました。このメカニズムは以下の手順で動作します。

a) タスクの分解:

タスクを単純なサブタスクに分解して、LLMが処理する必要のある複雑性を低減する。これにより、LLMの指示遵守の品質をチェックしやすくし、必要に応じて再生成を行うことができる。
分解されたサブタスクが単純であるため、その結果を確認するのが容易になる。実際には、このステップは簡単な整合性チェックだけで行うことも可能であり、LLMがAgent内で作業する必要はありません。

b) SQLの誤り訂正:

SQLの実行結果の分析に基づいてさらにSQLを訂正する。
異なるタイプの誤りに対して異なるプロンプトを使用する。
生成された複数のSQL結果を投票することで、モデルの変動性の影響を軽減する。

c) 投票:

自己整合性と投票メカニズムを使用して、最も整合性が高いSQL結果を選択し、同じ結果の中から最も短い実行時間を選択する。このステップは、SQLの精度と効率を向上させる。

4.3 展望

一貫性の調整に関しては、まだ多くの最適化の余地があります。モデルの出力を原子化することで、Text-to-SQLタスクの上限を大幅に引き上げる可能性があります。Agentタスクを原子化することで、大規模モデルは様々なタスクのチェーンを迅速に構築し、ホットスワッピング機能を持つことができます。これにより、異なるタスクとの柔軟な統合が可能になり、モデルの適応性が向上するとともに、開発者は特定のニーズに基づいて特定の機能を迅速に実装し、全体的な効率と効果を向上させることができます。

5. OpenSearch-SQLの開始

OpenSearch-SQLの具体的な