生成AIを用いたText to SQLの最前線

社内の勉強会で紹介しました。
ブログ記事は以下です。
https://aitc.dentsusoken.com/column/The_Forefront_of_Text_to_SQL

Transcript

1. ⽣成AIを⽤いたText-to-SQLの最前線 2024年01⽉19⽇ 株式会社電通総研 XI本部 AIトランスフォーメーションセンター 太⽥真⼈
2. 2 アジェンダ ▍Text-to-SQLとは ▍評価データセット ▍⽣成の失敗と課題 ▍精度向上⽅法 ▍ユーザーインタラクション ▍SoTA⼿法の紹介 ▍実装⽅法
3. 3 はじめに ▍ Text-to-SQLの研究はChatGPTが広まる前から存在します。 ▍ この資料では⼤規模⾔語モデル登場以降の研究に焦点を当てています。 ▍ 最新モデルを利⽤するとおそらく違った精度結果になると思います。 ▍ 最後にLangChainでの実装⽅法と改善⽅法の道筋を紹介します。 ▍ DB連携の別アプローチにテーブルデータの表現学習やCoTもありますが対象外にしています。 ▍ 社内のDBデータを使ったChatGPTとの対話アプリケーションの実現を⽬指しましょう！
4. Text-to-SQLとは 概要 なぜ求められるのか ⽤語の定義 シンプルな解法 研究から⾒た実⽤的な範囲 4
5. ▍Text-to-SQLは、⾃然⾔語で表されたクエリをSQL⽂に変換する技術 ▍SQLを知らないユーザーでもデータベースから情報を簡単に抽出できる点が魅⼒ ▍対話ベースの⽣成AIの発展により、DBの実⾏結果を対話AIに利⽤する点で注⽬が集まる 5 Text-to-SQL の概要 地域別の前四半期の売上⾼ を教えてください。 SELECT region, SUM(sales) AS total_sales FROM sales_data …(略) Text-to-SQL 地域 売上⾼ 東京 50万 ⼤阪 35万 出⼒整形 +----------+---------------+ | region | total_sales| +----------+---------------+ | Tokyo | 500000 | | Osaka | 350000 | +----------+---------------+ ⽣成AI DB ユーザー
6. 6 なぜ求められるのか ▍SQLを知らないユーザーが⾃然⾔語でDBの内容に問い合わせたいニーズがある ▍特にBI、データ分析、⽣成AIとの対話Webアプリケーションで求められている ▍最近ではAIエージェントのツールとしてもDBが挙げられる
7. 7 ⽤語の定義 ⽤語 説明 Natural Language Querying ⾃然⾔語からデータベースクエリに変換するプロセス。ユーザーは専⾨的なクエリ ⾔語を知らなくてもデータベースから情報を取得できる。 Text-to-SQL NLQの⼀部で、⾃然⾔語からSQLクエリに変換する技術のことを指す DB（データベース） この資料ではRDBを前提とします。DBには複数のスキーマを持つ スキーマ データベース内のデータの構造を定義。テーブル、カラムとそれらの関係性が記録 される。複数のテーブルを保持する。 テーブル ⾏（レコード）と列（カラム）の集まり カラム テーブル内の列で、各カラムは⼀定のデータタイプ（例：⽂字列、数値）を持つ レコード テーブル内の⾏で、特定のエンティティやオブジェクトのすべてのデータを含む 外部キー 他のテーブルのレコードを参照するために使⽤されるカラム 主キー テーブル内の各レコードを⼀意に識別するために使⽤されるカラム
8. 8 シンプルなText-to-SQL ⼿法 DBのスキーマ Table singer, columns = [*, Singer_ID, Name, …] Few shot サンプル Q: 歌⼿は何⼈いますか？ A: SELECT COUNT(Singer_ID) FROM singer 質問⽂ プロンプト設計 ⼿法の説明 ▍ 性能の⾼いモデル（GPT-4）を使う ▍ DBのスキーマはプロンプトに記述できる範囲内 で書く。 ▍ Few-shotサンプルは指定したDBスキーマのテー ブル情報を使って8~10件程度記述しておく。 ▍ ⽣成結果をSQL実⾏する。 プロンプトにDBのスキーマとFewShotの必要性を 次に紹介します。 タスクの説明 Create SQL Query only for the given questions.
9. 9 DBスキーマの与え⽅による精度向上 ▍外部キーや主キーを記述する⽅が良い ▍データセットによっては精度に⼤きな差はない Table(Column) ・テーブルの後にそのカラムを各⾏に列挙 Table(Column)(PF) ・Table(Column)の最後に主キーと外部キーを追加 Create(NoPF) ・SQL⽂で “create table ” ⽤のすべてのテーブルとカラムを記述 Create(EoC) ・Create(NoPF)に基づいて主キーと外部キーを各カラムの末尾に追加 Create(EoT) ・Create(NoPF)に基づいて主キーと外部キーをテーブルの末尾に追加 Create(EoC) 形式 ACT-SQL: In-Context Learning for Text-to-SQL with Automatically-Generated Chain-of-Thought ※ 精度は数字が⼤きいほど良い
10. 10 Few-shot Learningによる精度向上 ▍質問と同じスキーマ内の質問とSQLクエリのペアを増やすほど精度は向上する l JOIN⽅法、DBの値、ORDER BYやGROUP BYの⽅法が明確になるため Selective Demonstrations for Cross-domain Text-to-SQL ※ 精度は数字が⼤きいほど良い
11. 11 研究結果から⾒た実⽤そうな範囲 ▍精度が出そうな範囲 l 少ないテーブル数 （~5テーブル以内） l 各テーブルのカラム数が10程度 l DBのテーブル設計がきちんとされており、整備されている l 列の詳細説明とサンプル値がある l よくある質問のQAペアが数⼗件程度ある l ⽣成したいSQLクエリがドメイン知識不要な単⼀条件 l 質問内容から曖昧性が極⼒排除されている ▍論⽂を読んだ結果、上記範囲に近い設定でGPT4を使えばそれなりの精度が出るかもしれない l まずはやってみましょう。
12. 12 Text-to-SQLの実応⽤の課題 ▍ユーザーが尋ねる質問はDBのスキーマや値と関係する⽤語を含むとは限らない l 複雑な暗黙条件、専⾨⽤語、略語、ビジネスルール、必要な個別計算、SQL以外の操作が含まれる l ユーザーの質問が「過去5年間、毎年、年初から現在の⽇付までの同じ⽇付範囲を取り、アジア地域の 国々の貿易収⽀損益を選択し、これらの値を通年の予測損益の値と連結してください」とはならない ▍Text-to-SQLの⼀般的な要件は100%に近い精度を持つこと l ユーザーはSQLクエリを出⼒根拠にされてもわからない。出⼒結果を正しいものとして、 後続の意思決 定をしてしまう。UXや説明性が求められる。 ▍精度向上⼿段が⼀般化されず、個別エンジニアリングが必要なこと l データがあればどのDBでも問題なく利⽤できる汎⽤的なアルゴリズムがあると理想 l 実際は、DBごとにQAぺアの準備やスキーマの説明を充実させるなどが必要
13. 評価データセット 評価指標 よく利⽤されるデータセット３選 データセットの特徴と分類 使⽤事例と精度結果 13
14. 14 評価指標 ▍有効SQL(VA) l 正常に実⾏できるSQLクエリの割合 ▍完全⼀致(EM) l ⽣成されたSQLクエリが真値と完全に⼀致した割合 l 別表現で同様の結果を表すクエリを⾒逃す ▍実⾏精度(EX) l 実⾏結果が真のSQLクエリの結果と⼀致した割合 l クエリ効率が悪くても評価される l すべての正しいSQLクエリを捕捉することはできない A comprehensive evaluation of ChatGPT’s zero-shot Text-to-SQL capability Evaluating Cross-Domain Text-to-SQL Models and Benchmarks 実⾏精度で本当は正解なのにエラーとされるケース
15. 15 よく利⽤されるデータセット３選 ▍Spider(2018) l SQLクエリの難易度を4段階に定義し、⻑く定番のベンチマークになっている l https://yale-lily.github.io/spider ▍KaggleDBQA(2021) l Kaggleのデータセット8つから構成される。ナレッジ⽂書も含まれる l https://github.com/chiahsuan156/KaggleDBQA ▍BIRD（2023） l レコード数を増やした33.4GBのデータセットで、最新ベンチマークになっている l https://bird-bench.github.io/ ▍+紹介 MultiSpider(2023) l 7つの⾔語に翻訳した多⾔語 データセット l https://huggingface.co/datasets/dreamerdeo/multispider
16. 16 Spider データセットの特徴 ▍SQLクエリの複雑さをEasy, Medium, Hard, Extra-Hardに定義 ▍DB数も200と多く、ドメインが多いのが特⾊ ▍注意：DBの値が必要なSQLクエリは正解値がわかる前提 l 理想は質問⽂から⽣成するか、DBの値を事前確保して予測するべき Spider: A large-scale human-labeled dataset for complex and cross-domain semantic parsing and text-to-sql task. Natural Language Interfaces for Tabular Data Querying and Visualization: A Survey
17. 17 Spider 使⽤事例と精度結果 ▍実⾏精度（EX）を⾒⽐べると、難易度があがるにつれて精度が悪化 ▍最⾼精度でもExtra Hardが4〜5割程度、EasyやMediumの難易度であれば8割に近い DAILの詳細は後ほど https://yale-lily.github.io/spider Din-sql: Decomposed in-context learning of text-to-sql with self-correction.
18. 18 KaggleDBQA データセットの特徴 ▍8つのKaggleデータセットをランダムに選択している (a)SQLiteデータベースを含む (b)ライセンス的に問題ない (c)テーブルとカラムの意味を説明する関連⽂書がある ドメインの概要、テーブルやカラムの説明、サンプルクエリ、オリジナルソースなど KaggleDBQA: Realistic evaluation of text-to-SQL parsers.
19. 19 KaggleDBQA 使⽤事例と精度結果 ▍実⾏精度は5割程度に留まる ▍エラー分析では、スキーマリンクが１番難しく、次に制約条件と続く Selective Demonstrations for Cross-domain Text-to-SQL
20. 20 BIRD データセットの特徴 ▍DBがノイジーなデータタイプを持ち、DBの値に関する外部知識もあり、効率的なSQLクエリを 評価できる。より現実問題に即した最新のデータセット Can llm already serve as a database interface? a big bench for large-scale database grounded text-to-sqls.
21. 21 BIRD データセットの特徴 ▍質問の種類はDBの値を理解しなくても答えられる基本タイプとDBの値とその意味を必要とする 推論タイプの２種類がある。 推論タイプ 基本タイプ Can llm already serve as a database interface? a big bench for large-scale database grounded text-to-sqls.
22. 22 BIRD 使⽤事例と精度結果 ▍実⾏精度は6割程度に留まる ▍質問のタイプでは、基本タイプのランキングと推論 タイプの計算が苦⼿ Can llm already serve as a database interface? a big bench for large-scale database grounded text-to-sqls.
23. 23 MultiSpider データセットの特徴と分類 ▍右図の７ヶ国語に対応したデータセット ▍Spiderのスキーマと質問⽂を翻訳している l 質問⽂からDBの値に関する問題は差し引いてい る。DBの値は翻訳していないため 翻訳の⼿続き MultiSpider: Towards Benchmarking Multilingual Text-to-SQL Semantic Parsing
24. 24 MultiSpider 使⽤事例と精度結果 ▍実験結果はLLMではないが、⽇本語が最も精度がでなかった模様 l スラング（中国語）、ひらがな、カタカナ（⽇本語）は、質問とスキーマがマッチしない l ⽇本の場合、⽇本語の質問⽂で英語スキーマとマッチングする必要がある MultiSpider: Towards Benchmarking Multilingual Text-to-SQL Semantic Parsing
25. ⽣成の失敗と課題 SQLクエリ⽣成のエラー原因 具体的なエラー例 課題 25
26. 26 SQLクエリ⽣成のエラー原因 SELECT region, SUM(sales) AS total_sales FROM sales_data …(略) Text-to-SQL 地域 売上⾼ 東京 50万 ⼤阪 35万 出⼒整形 +----------+---------------+ | region | total_sales| +----------+---------------+ | Tokyo | 500000 | | Osaka | 350000 | +----------+---------------+ ⽣成AI DB ユーザー 質問の曖昧さ … 集約して スキーマリンク SQLの複雑さ ドメイン知識の不⾜ データの複雑さ ▍ユーザー、モデル、データの３つの視点で問題点を整理する
27. 27 ⼀般的な⽣成失敗の分類 ▍ 質問の曖昧さ（Question Understanding） l 曖昧な質問の意図を間違え、DBの要素やSQLクエリ変換に失敗する。 ▍ ドメイン知識の不⾜（Knowledge Reasoning） l クエリを⽣成するのにドメイン知識が必要なケース（DBの値の”F”がfemaleを指す、1980sは1980~1989までの期間を指すなど） ▍ データの複雑さ（Data Complexity） l データにノイズが含まれる、単純な集計で処理できないケース（⾦額が数字でなく、⽂字列で記録されているなど） ▍ SQLの複雑さ（SQL Complexity） l JOIN：必要とされるすべてのテーブルや、テーブルを結合するための正しい外部キーを特定することが難しい l GROUP BY ：何をグルーピングすべきか不明 l ネストと集合操作を含むクエリ：⼊れ⼦構造を認識しないか、正しい⼊れ⼦または集合操作を検出できない ▍ スキーマリンク（Schema Linking） l 質問の意図と違ったデータベース要素（テーブル、カラム、値）でSQLクエリが⽣成される。 l 「2011年の最優秀⼥優は誰か？」というクエリでは、「⼥優」はデータベースのActor.name 属性に対応させる必要がある。 ▍ その他 l 余分な述語を含むSQLクエリ、述語の⽋落、DISTINCTやDESCキーワードの⽋落や冗⻑など
28. 28 質問理解の難しさ A survey on deep learning approaches for text-to-SQL ▍語彙的曖昧さ（Lexical ambiguity, multiple meanings ） Ø 1つの単語が複数の意味を持つこと Ø 例：「Paris」は都市であったり、⼈名であったりする ▍構⽂的曖昧さ（Syntactic ambiguity） l 構⽂構造に基づいて複数の解釈を持つ⽂のこと l 例：「ドイツの映画監督をすべて教えて」という質問は、「ドイツ映画を監督したことがある監督」ま たは「映画を監督したことがあるドイツ出⾝の監督」とも受け取れる。 ▍意味的曖昧さ（Semantic ambiguity ） l 複数の意味的解釈を持つ⽂を指す l 例："Are Brad and Angelina married?” は、2⼈がお互いに結婚しているという意味かもしれないし、 別々に結婚しているという意味かもしれない。
29. 29 質問理解の難しさ ▍⽂脈依存の曖昧さ（Context-dependent ambiguity ） l クエリの⽂脈やドメインで異なる意味を持つ⽤語を指す 例：“top ”と “best ” Ø クエリの⽂脈による違いでSQLの句が変わる p "Who was the best runner of the marathon? "は、レースを速く完⾛した⼈（min操作）が返されるはず p "Which was the best nation of the 2004 Olympics?" は、最も多くのメダルを獲得した⼈（max操作）が返されるはず Ø ドメインによる違いでカラムリンクが変わる p 映画DBの”Return the top movie” では、”top” はレビュー評価を意味する p サッカーDBの ”Return the top scorer” では、”top” はゴール数を意味する p ビジネスアナリストの“Return the top product”は、 “top” は最も収益性の⾼い製品を意味する
30. ▍ ドメイン知識とSQLクエリの対応づけが難しい l ドメイン知識をプロンプトに追加しても間違えることがある l SQL⽂を考慮せずに、ドメイン知識の内容を複製してしまうなど 30 知識推論の難しさ Can llm already serve as a database interface? a big bench for large-scale database grounded text-to-sqls.
31. 31 データの複雑さ ▍粒度（data granularity ） l 各レコードに1つのイベントを記録しているか、それとも集約を記録しているか l 単純なCOUNT(*) で⼗分なのか、COUNT(distinct match) で重複を考慮する必要があるのか ▍値の⼀貫性（value consistency ） l 値は⼀貫した形式に従っているか l サッカーの試合であれば「ホームチーム名 – アウェイチーム名」で統⼀。異常値はないなど l マッチ操作に関係する ▍データのカバレッジ（data coverage ） l イベント全体を表しているのか、特定の⽅法（時間／場所など）のサブセットなのか l あるカラムが2009-2013 の範囲のみ保持しているなど l union や deduplication操作に関係する
32. 32 複雑なクエリの難しさ ▍JOIN l 結合するための正しい外部キーの特定 ▍GROUP BY SELECT句とGROUP BY句での問題 l SELECT句の中での⾮集約列、集約列と⾮集約列の混在 ▍NESTED l ⼊れ⼦になったSQLクエリに⼀意でないカラムを使⽤ ▍WHERE l 列の幻想、必要な条件の省略 ▍LIMIT N l 同順位が複数ある場合 l 同順位を返すこともあれば、1 つだけを返すこともある DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction
33. ▍ DBのスキーマは理解しているが、不適切なカラムやテーブルを誤って関連付ける 33 スキーマリンクの難しさ スキーマリンクのイメージ図 誤ってカラムやテーブルを対応づける例 Can llm already serve as a database interface? a big bench for large-scale database grounded text-to-sqls. A Survey on Text-to-SQL Parsing: Concepts, Methods, and Future Directions
34. 精度向上⽅法 全体像 各⽅法の紹介 34
35. 35 全体像 ▍Text-to-SQLの精度改善⽅法 ▍質問の曖昧さ（Question Understanding） ▍ドメイン知識の不⾜（Knowledge Reasoning） ▍データの複雑さ（Data Complexity） ▍SQLの複雑さ（SQL Complexity） ▍スキーマリンク（Schema Linking） Text-to-SQL の課題 質問の⾔い換え 質問の分解 スキーマ検索 スキーマ説明 デモ選択 ⾃⼰改善 Fine Tuning
36. 36 質問の⾔い換え ▍曖昧さをなるべく排除し、質問の意図を汲み取り、スキーマリンクしやすくすることを⽬指す LLM知識で⾔い換え ・1980s -> 1980-1989の期間に⾔い換え ・⻑すぎる質問⽂の分割や簡略 ・略語の正式名称変換 ・SQLクエリライクな表現 外部知識で⾔い換え ・「今」「先⽉」といった時間情報を指定⽅式で置き換える ・スキーマの説明で補完する ・デモデータから補完する ・専⾨⽤語の補完 • 質問から抽出、変換、置換の3つのステップで書き換える • 扱うスキーマが絞られている場合、スキーマに基づいて質問意図を⽣成する Reboost Large Language Model-based Text-to-SQL, Text-to-Python, and Text-to-Function - with Real Applications in Traffic Domain 質問の⾔い換え 質問の分解 スキーマ検索 スキーマ説明 デモ選択 ⾃⼰改善 Fine Tuning
37. 37 質問の分解 ▍難しい問題をいくつかの簡単な問題に分解して解くようにする 質問を難易度分類 ・Easy, Nested, Non-Nestedに応じてプロンプトを変更する 質問を単純化 ・Chain-of-Thougt で段階的に難易度を上げていく。その度にSQLクエリを⽣成させる。 ・ReAct形式で実⾏を間に⼊れ、中間テーブルを作成しながら質問の要求を⼩さく満たす 質問を分割 ・サブセンテンスごとにSQLに対応させる ・モジュール化され質問分解可能なクエリプラン⾔語（QPL）と呼ぶ新しい中間⾔語を作 る 部分問題を順に解く 質問の⾔い換え 質問の分解 スキーマ検索 スキーマ説明 デモ選択 ⾃⼰改善 Fine Tuning
38. 38 スキーマ検索 ▍トークン制約や幻覚防⽌のため、不必要なテーブルを減らし、最低限必要なものを探す プロンプト内から特定 全てのスキーマ情報（テーブル名、列名、データ型、主キー、外部キー）をプロンプトに ⼊れ、CoTの処理内でスキーマリンクする(左図) ・スキーマ特定とSQL⽣成を分ける。スキーマ特定では⽣成AIに質問に関するテーブルを選 ばせ、その後にカラムを絞らせる DBから検索 (右図) DWH内に数⼗テーブルがある場合、スキーマをプロンプトに全て⼊れられない ・質問から仮想的なスキーマを⽣成させ、対応する実在のスキーマを検索 ・スキーマグラフを構築し、探索するスキーマルーティング ・質問から重要単語を抽出し、スキーマ検索 質問の⾔い換え 質問の分解 スキーマ検索 スキーマ説明 デモ選択 ⾃⼰改善 Fine Tuning
39. 39 スキーマ説明 ▍スキーマリンクの精度向上のためにはメタデータで補⾜を増やす メタデータを記述 ・カラムの説明など レコードの記述 ・レコードをプロンプト記⼊することがセキュリティ的に可能なら追加する ドキュメントを記述 ・値の⼀貫性、値のカバレッジ、値の粒度、略語の詳細を各カラムごとにドキュメント化 し、プロンプトに組み込む。DBとの同期が課題 カラム間の関係を記述 ・DBのカラム間の構造を線形で表現する プロンプト組み込み ・スキーマにインラインで組み込む ・別ブロックで書き出す 質問の⾔い換え 質問の分解 スキーマ検索 スキーマ説明 デモ選択 ⾃⼰改善 Fine Tuning
40. 40 デモ選択 ▍Few-Shot Learning⽤のデモを⽤意し、複雑なSQLクエリを克服する デモは、QAのペアで与えられる。事前に⽤意しておく必要がある。 準備コストが⾼いが、場合によってはCoTの内容もデモで⽤意する。 デモのおかげで、テーブル間のJOIN⽅法やDBの値に関して事前情報を得られる。 質問の類似選択 • 質問の⾻格を抽出し、質問の構造的な類似性に基づいてデモを検索（Skelton Retrieval） • ドメイン内デモとドメイン外デモをプロンプトに加える（ドメイン外は別DBを指し、仮 ⽣成したクエリで類似度の⾼いものを選ぶ。ドメイン内は同じスキーマ） SQLクエリの類似選択 • 多様性と類似性の両⽅を追求するため、仮SQLクエリを⽣成し検索 • 近傍（類似性）とk-meansクラスタリングのクラスタ代表（多様性）を追加 • 複雑なSQLクエリを含むデモを多めに⼊れる戦略 質問の⾔い換え 質問の分解 スキーマ検索 スキーマ説明 デモ選択 ⾃⼰改善 Fine Tuning
41. 41 ⾃⼰改善 ▍最後にSQLクエリを磨き上げる SQL実⾏前に改善 • SQLクエリの実⾏前にBUGGY SQLの修正が必要か⾃⼰評価と修正 • SQLインジェクション： 悪意のあるユーザーが不正操作する攻撃 • パフォーマンスの問題： ⾮効率なクエリにより、DBのパフォーマンスが低下する • ロジックの誤り： 誤ったSQL⽂や構造 • SQLクエリ⽣成のよくあるミスをプロンプトに書きセルフチェックさせる • 異なるプロンプト戦略の多数決で⼀貫した回答をおこなう SQL実⾏後に改善 • ⽣成したSQLクエリの実⾏結果をもとにSQLクエリを⽣成し直す。 • スキーマフィルタリングをしていた場合、全てのスキーマを⼊れて再度クエリ⽣成 するなど Prompting GPT-3.5 for Text-to-SQL with De-semanticization and Skeleton Retrieval 質問の⾔い換え 質問の分解 スキーマ検索 スキーマ説明 デモ選択 ⾃⼰改善 Fine Tuning
42. 42 ファインチューニング ▍ドメインに特化して精度向上を⽬指す 質問の⾔い換え 質問の分解 スキーマ検索 スキーマ説明 SQLite⽂でファインチューニング データセット：Spiderで8659 件利⽤ 精度 ・LLAMA-13Bと30Bでは、davinci-003 と並ぶがGPT4やgpt-3.5-turboには劣る ・微学習後はFew shot Learningの効果がない Snowflake SQLとGoogleSQL⽂でファインチューニング データセット：GPT4を使⽤しながら、3732件QAを作成し、8:2分割 精度 ・GPT4より精度が向上し、回答までの⽣成時間が短い Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation FINE-TUNING LANGUAGE MODELS FOR CONTEXT-SPECIFIC SQL QUERY GENERATION デモ選択 ⾃⼰改善 Fine Tuning
43. ユーザーインタラクション SQL⽣成の説明 対話 43
44. 44 SQLクエリ⽣成の説明 ▍Text-to-SQLを使いたいユーザーが⾮技術者の場合、実⾏結果が失敗または間違っているとき、 次にどのような質問をすれば、正しい答えが返ってくるか考える必要がある。 ▍システムとして回答の説明ができるのかが重要になる パターン l クエリプラン⾔語（QPL）と呼ぶ新しい中間⾔語を提案しユーザーに⾒せる l SQLのクエリ意図を⾔語化してユーザーに返す Semantic Decomposition of Question and SQL for Text-to-SQL Parsing
45. 45 対話的にSQLクエリを⽣成 ▍⽣成AIの発展で対話形式のQAがスタンダードになっている ▍対話からSQLクエリを⽣成する必要がある l 会話の応答にSQLの説明を付与しユーザー⽀援も必要か MIGA: A Unified Multi-Task Generation Framework for Conversational Text-to-SQL
46. SoTA⼿法の紹介 DAIL-SQL 46
47. 47 DAIL-SQLとは ▍Alibabaグループが23年8⽉に提案した⼿法 ▍Spider のダッシュボードで2位と3位、BIRD では5位に位置付けている ▍デモの選択に埋め込みとスケルトンをうまく活⽤している⼿法
48. 48 DAIL-SQLのアルゴリズム詳細 1. ターゲットとデモの質問のうち、スキーマと関するワードをマスクする （後にSQLクエリで条件⽂やカラム名に関係しそうなドメイン単語を隠す） 2. ターゲットの質問からSQLクエリ⽣成 3. デモのSQLクエリと⼀緒にクエリの⾻格抽出（類似度評価のため） 4. マスクされたターゲット質問とデモ質問の埋め込みをコサイン類似度順でソート （マスクされていることでドメインに基づかない類似質問が上位に来る） 5. マスク質問の類似度が⾼い順にSQLクエリ⾻格の類似度を評価（0.85以上を優先） 6. 質問構造が似ており、SQLクエリ⾻格の類似度の⾼いデモを使ってクエリ⽣成 質問とクエリ からデモ選択
49. LangChainで実装 SQLDatabaseChain SQL Agent 49
50. 50 LangChainで実装 ▍ ここまでデータセット、⽣成の課題と精度改善⽅法を紹介しました。 ▍ 最後に⼿元で実現するまでのギャップを埋めます。 ▍ LangChainでは、Text-to-SQLを実装するクラスが⽤意されています。 ▍ 実装⽅法は、公式のユースケースから確認してください。 l https://python.langchain.com/docs/use_cases/qa_structured/sql#case-2-text-to-sql-query-and-execution ▍ この資料では、LnagChainではどこまで精度改善⽅法が適応されているかに焦点をあてます。 ▍ さらに適応できそうな精度改善⽅法を紹介します。
51. 51 SQLDatabaseChainで実装する ▍LangChainのSQLDatabase クラスとSQLDatabaseChain クラスを利⽤します DBの有名所は対応してます。 デフォルトはtext2sqlの⽣成から実⾏結果を取得 し、質問の回答を返します。 出⼒結果 Spiderのcar_1のDBを利⽤してます。
52. 52 デフォルトで利⽤されるプロンプト You are a PostgreSQL expert. Given an input question, first create a syntactically correct PostgreSQL query to run, then look at the results of the query and return the answer to the input question. Unless the user specifies in the question a specific number of examples to obtain, query for at most {top_k} results using the LIMIT clause as per PostgreSQL. You can order the results to return the most informative data in the database. Never query for all columns from a table. You must query only the columns that are needed to answer the question. Wrap each column name in double quotes (") to denote them as delimited identifiers. Pay attention to use only the column names you can see in the tables below. Be careful to not query for columns that do not exist. Also, pay attention to which column is in which table. Pay attention to use CURRENT_DATE function to get the current date, if the question involves "today". Use the following format: Question: Question here SQLQuery: SQL Query to run SQLResult: Result of the SQLQuery Answer: Final answer here Only use the following tables:{table_info} Question: {input} PostgreSQL⽤のプロンプトを載せます。 他のDBはLnagchainのリポジトリで確認してください。
53. 53 SQLDatabaseChain で精度改善 ▍ SQLDatabase クラスのポイント l 無視するテーブルか、関連するテーブルを指定できる l テーブル情報を取得できる Ø テーブルの作成コマンド（CREATE TABLE）全て Ø 各列の名前、データ型、主キーと外部キー制約情報 Ø テーブルのインデックス情報（オプション） Ø テーブルのサンプルレコード3⾏（変更可能） ▍ SQLDatabaseChain クラスのポイント l Text-to-SQLプロンプトを変更できる Ø デフォルトプロンプトは各SQL⽅⾔で⽤意されている Ø テーブル情報をプロンプトに⾃動で⼊⼒される Ø クエリ実⾏結果の取得レコード数上限を変数で指定できる l 返り値をSQL、クエリ実⾏結果、質問の回答から選べる l ⽣成したSQLクエリの⾃⼰修正もできる（promptを変更可） l SQLDatabaseSequentialChain を利⽤するとスキーマ検索可能 l モデルを変更できる 質問の⾔い換え 質問の分解 スキーマ検索 スキーマ説明 デモ選択 ⾃⼰改善 Fine Tuning デフォルト設定 プロンプト修正 コード追加
54. 54 SQL Agent で実装する ▍LangChainのReAct形式のエージェントを利⽤する（ツールとしてSQLDatabaseを渡す） 出⼒結果 繰り返し回答を⽣成するが最終的に間違っている..
55. 55 デフォルトで利⽤されるプロンプト You are an agent designed to interact with a SQL database. Given an input question, create a syntactically correct {dialect} query to run, then look at the results of the query and return the answer. Unless the user specifies a specific number of examples they wish to obtain, always limit your query to at most {top_k} results. You can order the results by a relevant column to return the most interesting examples in the database. Never query for all the columns from a specific table, only ask for the relevant columns given the question. You have access to tools for interacting with the database. Only use the below tools. Only use the information returned by the below tools to construct your final answer. You MUST double check your query before executing it. If you get an error while executing a query, rewrite the query and try again. DO NOT make any DML statements (INSERT, UPDATE, DELETE, DROP etc.) to the database. If the question does not seem related to the database, just return "I don't know" as the answer. Begin! Question: {input} Thought: I should look at the tables in the database to see what I can query. Then I should query the schema of the most relevant tables. {agent_scratchpad}
56. 56 SQL Agent で精度改善 ▍⽣成されたクエリを実⾏し、トレースバックをキャッチして正しく再⽣成できる ▍繰り返し修正をしてくれる デフォルトのツール l クエリの作成と実⾏ l クエリ構⽂をチェックする l テーブルの説明を取得する l テーブルのリストを取得する 質問の⾔い換え 質問の分解 スキーマ検索 スキーマ説明 デモ選択 ⾃⼰改善 Fine Tuning デフォルト設定 プロンプト修正 コード追加 ツールの追加
57. まとめ 57
58. 58 まとめ ▍Text-to-SQLのデータセットから⽣成の課題、精度改善、実装など⼀通り紹介しました ▍ぜひ、SQLクエリ⽣成を通して⽣成AIでのQAを挑戦してみてください ▍社内のビジネスユーザーが⾃然⾔語で簡単にデータから⽰唆を得られる世界を⽬指しましょう
59. 59 参考⽂献 ▍ サーベイ Zhang, Weixu, et al. "Natural Language Interfaces for Tabular Data Querying and Visualization: A Survey." arXiv preprint arXiv:2310.17894 (2023). ▍ サーベイ Katsogiannis-Meimarakis, George, and Georgia Koutrika. "A survey on deep learning approaches for text-to-SQL." The VLDB Journal (2023): 1-32. ▍ サーベイ Qin, Bowen, et al. "A survey on text-to-sql parsing: Concepts, methods, and future directions." arXiv preprint arXiv:2208.13629 (2022). ▍ NLQシステム Conversing with databases: Practical Natural Language Querying (Kochedykov et al., EMNLP 2023) ▍ 曖昧さ Huang, Zezhou, Pavan Kalyan Damalapati, and Eugene Wu. "Data Ambiguity Strikes Back: How Documentation Improves GPT's Text-to-SQL." arXiv preprint arXiv:2310.18742 (2023). ▍ ⼤量のスキーマ対策 Guo, Chunxi, et al. "Prompting GPT-3.5 for Text-to-SQL with De-semanticization and Skeleton Retrieval." Pacific Rim International Conference on Artificial Intelligence. Singapore: Springer Nature Singapore, 2023. ▍ ⼤量のスキーマ対策 Kothyari, Mayank, et al. "CRUSH4SQL: Collective Retrieval Using Schema Hallucination For Text2SQL." arXiv preprint arXiv:2311.01173 (2023). ▍ ⼤量のスキーマ対策 Wang, Tianshu, et al. "DBCopilot: Scaling Natural Language Querying to Massive Databases." arXiv preprint arXiv:2312.03463 (2023).
60. 60 参考⽂献 ▍ CoT Liu, Xiping, and Zhao Tan. "Divide and Prompt: Chain of Thought Prompting for Text-to-SQL." arXiv preprint arXiv:2304.11556 (2023). ▍ CoT Tai, Chang-You, et al. "Exploring Chain-of-Thought Style Prompting for Text-to-SQL." arXiv preprint arXiv:2305.14215 (2023). ▍ CoT Zhang, Hanchong, et al. "ACT-SQL: In-Context Learning for Text-to-SQL with Automatically-Generated Chain-of-Thought." arXiv preprint arXiv:2310.17342 (2023). ▍ ZSL Liu, Aiwei, et al. "A comprehensive evaluation of ChatGPT's zero-shot Text-to-SQL capability." arXiv preprint arXiv:2303.13547 (2023). ▍ スキーマリンク Li, Haoyang, et al. "Resdsql: Decoupling schema linking and skeleton parsing for text-to-sql." Proceedings of the AAAI Conference on Artificial Intelligence. Vol. 37. No. 11. 2023. ▍ デモ選択 Nan, Linyong, et al. "Enhancing Text-to-SQL Capabilities of Large Language Models: A Study on Prompt Design Strategies." Findings of the Association for Computational Linguistics: EMNLP 2023. 2023. ▍ デモ選択 Gao, Dawei, et al. "Text-to-sql empowered by large language models: A benchmark evaluation." arXiv preprint arXiv:2308.15363 (2023). ▍ デモ選択 Chang, Shuaichen, and Eric Fosler-Lussier. "Selective Demonstrations for Cross-domain Text-to-SQL." arXiv preprint arXiv:2310.06302 (2023).
61. 61 参考⽂献 ▍ ReAct Zhang, Yunjia, et al. “ReAcTable: Enhancing ReAct for Table Question Answering.” arXiv preprint arXiv:2310.00815 (2023). ▍ 簡易化 Eyal, Ben, et al. “Semantic Decomposition of Question and SQL for Text-to-SQL Parsing.” arXiv preprint arXiv:2310.13575 (2023). ▍ 簡易化 Yi, Jiawen, and Guo Chen. "Decoupling SQL Query Hardness Parsing for Text-to-SQL." arXiv preprint arXiv:2312.06172 (2023). ▍ ⼀貫性 Sun, Ruoxi, et al. "SQLPrompt: In-Context Text-to-SQL with Minimal Labeled Data." arXiv preprint arXiv:2311.02883 (2023). ▍ マルチターン Fu, Yingwen, et al. "MIGA: a unified multi-task generation framework for conversational text-to-SQL." Proceedings of the AAAI Conference on Artificial Intelligence. Vol. 37. No. 11. 2023. ▍ データセット Yu, Tao, et al. "Spider: A large-scale human-labeled dataset for complex and cross-domain semantic parsing and text- to-sql task." arXiv preprint arXiv:1809.08887 (2018). ▍ データセット Lee, Chia-Hsuan, Oleksandr Polozov, and Matthew Richardson. "KaggleDBQA: Realistic evaluation of text-to-SQL parsers." arXiv preprint arXiv:2106.11455 (2021). ▍ データセット Li, Jinyang, et al. "Can llm already serve as a database interface? a big bench for large-scale database grounded text- to-sqls." arXiv preprint arXiv:2305.03111 (2023). ▍ データセット Dou, Longxu, et al. "MultiSpider: towards benchmarking multilingual text-to-SQL semantic parsing." Proceedings of the AAAI Conference on Artificial Intelligence. Vol. 37. No. 11. 2023.
62. 62 参考⽂献 ▍ クエリ書き換え ⾃⼰修正 Sui, Guanghu, et al. "Reboost Large Language Model-based Text-to-SQL, Text-to-Python, and Text-to- Function--with Real Applications in Traffic Domain." arXiv preprint arXiv:2310.18752 (2023). ▍ エラー分析 Pourreza, Mohammadreza, and Davood Rafiei. "Evaluating Cross-Domain Text-to-SQL Models and Benchmarks." arXiv preprint arXiv:2310.18538 (2023). ▍ ファインチューニング Rebei, Amine. "Fine-Tuning Language Models for Context-Specific SQL Query Generation." arXiv preprint arXiv:2312.02251 (2023). ▍ DIN-SQL Pourreza, Mohammadreza, and Davood Rafiei. "Din-sql: Decomposed in-context learning of text-to-sql with self- correction." arXiv preprint arXiv:2304.11015 (2023). ▍ DAIL-SQL Gao, Dawei, et al. "Text-to-sql empowered by large language models: A benchmark evaluation." arXiv preprint arXiv:2308.15363 (2023). ▍ Table Representation Learning Workshop（https://nips.cc/virtual/2023/workshop/66546）