SQL Agentによるタップルのデータ利活用促進

Transcript

1. CA DATA NIGHT #6 SQL Agentによる タップルのデータ利活用促進 原 和希
2. 自己紹介: 原 和希 2021年新卒入社 株式会社タップル/ 機械学習エンジニア • Google Developer Experts (Google Cloud: AI) • CyberAgent Next Experts(Google Cloud/ MLOps)
3. 目次 1. サービス紹介 2. 今日話すこと/ 話さないこと 3. SQL Agentとは？ 4. 理想状態と検証で得た課題 5. タップルでのSQL Agentへのアプローチ 6. 今後の展望
4. 1. サービス紹介
5. 運営サービス概要 5 2014年5月にサービスを開始。グルメや映画、スポーツ観戦など、自分の趣味や行ってみたいデートスポットを きっかけに恋の相手が見つけられる国内最大級のマッチングアプリです。年収や身長などの条件だけなく、趣味 や好きなことから自然な出会いにつながることが特徴です。 https://tapple.me/
6. 2024年6月にサービスを開始。「無料でも本気の恋はできる」がコンセプトの、マッチもチャットも全員無料で 利用できるマッチングアプリです。利用を開始するためには、全50問ある「16タイプ恋愛診断」の回答が必須 となっており、しっかりと時間をかけてでも内面を重視して恋愛をしたいと考える人が集まっています。サイ バーエージェントグループが運営しており、24時間365日の監視体制と厳しい監視基準で、安心安全なお相手探 しをサポートします。 https://koigram.net/ 運営サービス概要
7. 利用者数や利用者層 7 累計会員数は国内最大規模 もっとも多い層は25～29歳 会員の半数が20代。30～34歳の利用も増加傾向に。
8. 2. 今日話すこと/ 話さないこと 【話すこと】 • SQL Agentを導入するまでの過程 • アーキテクチャ • 実装時の工夫ポイント 【話さないこと】 • タップルでの利用クエリ･質問内容
9. 3. SQL Agentとは？
10. SQL Agent 本発表では、下記を｢SQL Agent｣として話します。 • 自然言語の指示からSQLを生成、実行するアプリケーション • 自立性の有無･動的なツール選択は問わない • 今後の展望も含めて、｢Text2SQL ≒ SQL Agent｣とする
11. 他社事例 他社でも独自実装やサービス化、研究が行われている領域 Uber/ QueryGPT • RAGを活用 • 担当領域ごとに参照データを分類 • 対象テーブルをユーザーが修正可能 • 不要なカラムをコンテキストから除外 • 継続的な出力評価 LinkedIn/ SQL Bot • LangChain & LangGraphで実装 • ナレッジグラフを活用 • 選択時にテーブルの｢人気｣を表示 • ユーザーがカスタムプロンプトを定 義可能
12. 関連研究 BIRD-SQL • Text2SQL用のデータセット • リーダーボードも公開 • 研究結果のアプローチが掲載 • 参考: Papers with Code → 最新手法の調査に活用
13. 関連研究 Google Cloud や Stanford Universityの研究者による論文 ｢CHASE-SQL: Multi-Path Reasoning and Preference Optimized Candidate Selection in Text-to-SQL｣ • ｢Divide and Conquer CoT｣｢Query Plan CoT｣、 ｢Online Synthetic Example Generation｣の3つのアプローチでSQLを生成 • 構文エラーなどの実行結果を利用して、自動的にクエリを修正 • 生成された複数のSQL候補から、最適なものを選択
14. 4. 理想状態と検証で得た課題
15. SQL Agentで目指す理想状態 • SQLが書けない社員でも、データ抽出･分析を実現 • データ活用のハードルを下げる → データに基づいた意思決定、施策立案のスピードUPを狙う
16. 検証でのTry&Error まずは、Snowflakeの機能やSaaS導入での実現を検証した 【検証したツール】 • Snowflake Cortex Analyst • Snowflake Cortex Copilot • WrenAI → 期待している品質を実現するツールを選定することが出来なかった • 複数のテーブルのJOINが含まれる、複雑なクエリの品質が低い ◦ 精度向上のために、利用想定される全てのリレーションを定義必要がある • Variant型カラムがサポートされていない(2025-05-20現在･参考)
17. 検証や既存事例から得られた知見 【アーキテクチャ】 • マルチモデル/ Reflection/ RAGなどを活用して品質向上 【メタデータ】 • テーブル･カラムの説明、SQLサンプルを記述 • 質問の意図を理解しSQLに変換するために、ビジネス特有の知識が必要 • Long Contextなモデルが重要(機能によってはContext長の制限が厳しい) 【テーブル･カラムの選択･JOIN】 • 参照可能なテーブル･カラム数が大規模 → 誤った選択が増加 • Variant型(JSON)の処理難易度が高い
18. ツールを導入するのではなく、独自構築へ
19. 独自構築のメリット 柔軟性と拡張性の実現 • LLMを柔軟に選択可能 ◦ 複数のモデルベンダーから選択･複合して利用できる ▪ 日本語対応を確実にできる ▪ Long Contextなモデルも利用可能 ◦ モデルリリースに追従して、品質の向上が狙える • 生成フローをカスタマイズ可能 ◦ Reflectionやフォローアップの処理を独自実装できる ◦ 最新手法を随時取り込むことができる • 出力形式もカスタマイズできる ◦ SQLの他にも、各サブクエリの説明なども出力可能 • ドメイン知識をモデルへと柔軟に注入できる • WebアプリケーションやSlack Botなど、様々な方法で提供可能
20. 5. タップルでのSQL Agentへのアプローチ
21. 開発･導入したSQL Agent
22. 開発･導入したSQL Agent • チャットから Snowflake SQL を生成/ 実行 ◦ 作成方針やサブクエリの説明も同時に出力 ◦ 作成クエリに対して追加の質問も可能 • Difyのチャットフローで構築 • タップル独自の用語やビジネス知識をLLMコンテキストに注入
23. 導入の際に意識･工夫したこと 【アーキテクチャ】 最新の手法を取り入れつつも、シンプルにはじめる 【メタデータ】 社内用語、ビジネス知識を取り込む 【テーブル･カラムの選択/JOIN】 対象データを絞る
24. 【アーキテクチャ】
25. シンプルにはじめる 最大構成で作るのではなく、シンプルな構成ではじめる。 まずは、素早く導入して効果と課題への理解を深める。 • 導入して、理想のフローやニーズを知る ◦ 想定される質問は？ (既存クエリの修正やテーブル定義への質問もカバーする？) • 品質向上のためのデータを集める • ニーズに合わせて、既存研究などから必要なものを選択、導入
26. アーキテクチャ
27. アーキテクチャ • Workflow Agentとして実装 • Dify上に構築 ◦ 実装スピードを重視(WebUI ＋ ローコード) • LLMの責務を分ける ◦ 必要なテーブル･カラム･サンプルクエリを選択するモデル ◦ SQLの候補を生成する複数のモデル ◦ 生成クエリをレビュー･修正するモデル ◦ 候補を比較、選択するモデル
28. Workflow Agentとは？ 【LLM Agent】 動的推論と意思決定を自ら行う 【Workflow Agent】 事前定義されたロジックに基づいて、 決定論的な動作をする 参考：Google Agent Development Kit Document
29. Workflow Agentを選択した理由 まずは、シンプルなフローで最低限の生成を確実に実現 • 必要なツールと、理想としている挙動への理解を深める ◦ 上記がないと、動的に意思決定をさせても、最終評価が困難だと考えた ▪ 参考: Vertex AI Evaluation ServiceによるAgentの評価 • 必要な機能の複雑性や自律性の必要度合いに合わせて、切り替えを検討する
30. マルチモデルの利用とセレクター 複数のモデル/ロジックでSQLの候補を生成して、エラーを低減 • Google CloudとStanford大学のPourrezaらの研究を参考に実装 • Gemini Pro 2.5とo3を併用 • レビューと修正の仕組みも導入
31. 【メタデータ】
32. メタデータを充実させる 各テーブル･カラムの定義や社内知識をLLMに教える • 定義の他に、サンプルSQLを与えると品質が向上 • Snowflake Analystのセマンティックモデルを参考にしたYAMLに記載 →質問に応じてLLMが必要な情報を取得 • 社内･ドメイン特有の用語や概念を言語化 → LLMのプロンプトに注入 とはいえ、全てのテーブルに対応するのは大変...。
33. メタデータを充実させる
34. 【テーブル･カラムの選択/JOIN】
35. ｢データマネージメント × AI｣でのアプローチ。 LLMが扱いやすい専用のテーブルを作成し、生成難易度を下げる。 • 利用頻度が高いテーブル･SQLを元に作成 • ｢日付｣や｢ユーザー｣を共通するディメンションとして用意 • DevinなどのCoding Agentによって追加の工数も短縮 Agent専用のマートテーブルを作成
36. 6. 今後の展望
37. 今後の展望 • データサイエンス機能 ◦ 実行結果からシンプルな分析を行い、インサイトを提案する機能 • SQLの品質の向上 ◦ エラー発生や数値ミスを低減していく • 対象テーブルの拡充 ◦ Coding Agentの活用でAgent用マートテーブルを充実させていく • 評価 ◦ 収集した｢質問｣｢生成SQL｣｢実行結果｣｢フィードバック｣などから 継続的な評価を行う