Vanna.ai: SQLデータベースと対話する

 (github.com/vanna-ai)
3 ポイント 投稿者 GN⁺ 2024-01-15 | 1件のコメント | WhatsAppで共有
  • RAG（Retrieval-Augmented Generation）を適用したLLMで、正確なText-To-SQLを生成するオープンソース

Vannaの仕組み

  • RAG「モデル」の学習: ユーザーのデータに対してRAGモデルを学習させる。
  • 質問する: 学習済みモデルを使って質問すると、データベース上で自動実行可能なSQLクエリを返す。

ユーザーインターフェース

  • Vannaを使って構築されたユーザーインターフェースには、Jupyter Notebook、vanna-ai/vanna-streamlit、vanna-ai/vanna-flask、vanna-ai/vanna-slack などがある。

はじめ方

  • インストール: pip install vanna コマンドでVannaをインストールできる。
  • インポート: import vanna as vn のコードでVannaを利用できる。

学習

  • DDL文で学習: データベースのテーブル名、カラム、データ型、リレーションなどの情報を含むDDL文を使ってモデルを学習できる。
  • ドキュメントで学習: ビジネス用語や定義に関するドキュメントを追加してモデルを学習できる。
  • SQLで学習: 既存のSQLクエリを学習データとして追加し、新しいSQLを生成できる。

質問する

  • vn.ask("質問") メソッドを使って質問すると、関連するSQLクエリを受け取れる。

RAGとファインチューニングの比較

  • RAGはLLMをまたいで移植しやすく、学習データを簡単に削除でき、低コストで将来への適応力が高い。
  • ファインチューニングは、プロンプト内のトークンを最小限に抑える必要がある場合に有用だが、立ち上がりが遅く、学習および実行コストが高い。

Vannaを選ぶ理由

  1. 複雑なデータセットに対する高い精度: Vannaの性能は学習データに基づいて決まる。
  2. セキュリティとプライバシー保護: データベースの内容がLLMやベクターデータベースに送信されない。
  3. 自己学習: Jupyter経由で使う場合、正常に実行されたクエリについて自動学習できる。
  4. あらゆるSQLデータベースをサポート: Pythonで接続できるすべてのSQLデータベースに接続できる。
  5. フロントエンドを選べる: Jupyter Notebookから始めて、Slackbot、Webアプリ、Streamlitアプリ、またはカスタムフロントエンドとしてユーザーに提供できる。

Vannaの拡張

  • Vannaは、あらゆるデータベース、LLM、ベクターデータベースに接続できるよう設計されている。
  • VannaBase抽象基底クラスは基本機能を定義し、OpenAIとChromaDBを使う実装を提供する。

追加資料

  • 完全なドキュメント、Webサイト、サポート用のDiscordグループなどが提供されている。

GN⁺の意見:

  • Vannaは、データベース管理とSQLクエリ生成を自動化する強力なツールであり、ユーザーが複雑なデータセットに対して高精度のSQLクエリを簡単に生成できるようにする。
  • ユーザーフレンドリーなインターフェースと自己学習機能により、非専門家でも効率的にデータベースを活用できるようになり、データに基づく意思決定をさらに加速できる。
  • Vannaの拡張性と将来適応力は、企業が技術変化に柔軟に対応し、継続的にデータ管理プロセスを改善できる機会を提供する。

関連記事

1件のコメント

 
GN⁺ 2024-01-15
Hacker Newsのコメント

  • ChatDB.ai プロジェクトを開発中のユーザー体験

    • ChatDB.ai という類似プロジェクトを開発中。
    • AI と SQL を組み合わせて最も成功した体験は、SQL プロバイダーのエラーを各反復の後に LLM にフィードバックすることだった。
    • フォーマット済みのエラーメッセージラッパーを使い、システムテーブルのクエリを強く提案することで、スキーマ情報の発見に非常に効果的だった。
    • こうした小さな調整により、4 テーブル以上の結合が必要なクエリを見つけるのが驚くほどうまくなった。

  • GPT-4 を使った個人的な経験

    • GPT-4 を使って、すでに似たような作業を行っている。
    • MySQL CLI の SHOW TABLE コマンドでテーブル構造を確認し、そのテーブルをもとにカート放棄率のようなビジネス指標を示すクエリを生成している。
    • この方法はかなりうまく機能するという経験をしている。

  • 自然言語を SQL に翻訳するシステムへの懐疑的な見方

    • 自然言語を SQL に翻訳するシステムの開発努力は認めつつも、自然言語とモデルの根本的な性質が推測的で精度に欠ける点から懐疑的である。
    • SQL データベースは多くの場合、正確で精密な情報処理のために設計されており、推測的なレイヤーを導入すると問題をさらに悪化させる可能性がある。
    • このような試みが現実世界の要求を効果的に解決するうえで生産的なのか疑問を呈している。

  • YC 支援スタートアップを含む類似製品への関心

    • Minds DB (YC W20)、Buster (YC W24)、DB Pilot など、いくつかの類似製品を追っており、この分野に大きな関心がある。
    • 自分自身もこうしたソリューションを探している。

  • duckdb ベースのレポーティングサービスに関する経験

    • 全体としてはうまく動作するが、いくつかの問題にぶつかっている:
      • 低い temperature 設定にもかかわらず、GPT-4 がときどきサンプルやスキーマから逸脱する。
      • サービスは一般的なデータをホスティングしているが、顧客は自分たちのドメイン言語でレポート生成を求める。
      • LLM プロンプトのデバッグが厄介。顧客がモデルを簡単に混乱させてしまうことがある。
      • 生成されたクエリについての「説明」を顧客に提供し、レポート作成に何が使われたのかを透明化している。

  • RAG の動作方式に関する懸念と説明

    • 「train」という用語の使用に懸念を示している。
    • RAG は学習やファインチューニングなしに、データ準備、チャンク化、ベクトル化だけを必要とすることを強調して説明するのに多くの時間を費やしている。

  • LLM のハルシネーション問題への疑問

    • LLM が「昨日」のような時間概念をどう解釈するのか、また生成された SQL が文法的に有効でも意図と異なる可能性がある問題について疑問を持っている。
    • 特に MAX、COUNT のような集計クエリでは誤った数値を出す危険があり、それを確認するには SQL を直接読まなければならず、これは本来の目的に反する。

  • 独自データセットと技術を使った経験の共有

    • 社内スタッフが構造化データセットと対話できるボットを開発するのに類似の技術を使っている。
    • 実際にはある程度機能するが、いくつかの課題がある:
      • 既存モデルにはない特定業務向けの列挙型やデータ型が多く、それらを手動で定義してプロンプトに文脈として追加する必要がある。
      • 時間関連の質問の処理が難しい。
      • ユーザーは何でも質問できるため、単一テーブルに対しても多くの SQL クエリ例が必要になる。
      • 複数テーブルへの拡張が難しく、より効率的な方法があるのか気になっている。
      • Llama2 70B Gen モデルを使ったが、SQL クエリ生成では他のモデルの方がより良い性能を示すのか気になっている。

  • bit.io での経験と顧客の反応

    • bit.io で類似の取り組みを行い、人々に好評だった。
    • 作業中に発見したことについての記事がいくつもあり、現在は Databricks に買収されてサービスを終了している。
    • 可能な限り質問に答える用意がある。