NaturalSQL-7B - 自然言語をSQLに変換する強力なモデル

(github.com/cfahlgren1)

15 ポイント投稿者 xguru 2024-02-07 | 1件のコメント | WhatsAppで共有

SQL-Eval で 76.5% を達成し、モデルサイズ基準で最高の性能を示す
- GPT-4(83%) には及ばないが、GPT-3.5-Turbo(65%) / Claude-2(64.5%) を上回る
- sqlcoder-7b(71%) より高く、sqlcoder-15b(78%) と同程度
SQL を書く必要なく、ダッシュボードをノーコードで作成できるツール ChatDB を開発

例

質問: 先月に最も多い注文金額を持つ顧客を特定し、その顧客が注文したすべての製品と数量を列挙せよ。

出力:

WITH LastMonthOrders AS (  
  SELECT o.customerid, o.orderid, op.productid, op.quantity, p.productname, op.quantity * p.unitprice AS total_order_value  
  FROM orders o  
  JOIN order_details op ON o.orderid = op.orderid  
  JOIN products p ON op.productid = p.productid  
  WHERE o.orderdate >= date_trunc('month', CURRENT_DATE) - INTERVAL '1 month'  
  AND o.orderdate < date_trunc('month', CURRENT_DATE)  
),  
CustomerTotalOrderValue AS (  
  SELECT customerid, SUM(total_order_value) AS total_value  
  FROM LastMonthOrders  
  GROUP BY customerid  
  ORDER BY total_value DESC  
  LIMIT 1  
)  
SELECT c.customerid, c.companyname, lm.productid, lm.productname, lm.quantity  
FROM CustomerTotalOrderValue ctov  
JOIN LastMonthOrders lm ON ctov.customerid = lm.customerid  
JOIN customers c ON c.customerid = lm.customerid;

NaturalQuery は上記のような複雑な質問、サブクエリ、比率に対して非常に高い性能を発揮する。

1件のコメント

xguru 2024-02-07

Hacker Newsのコメント

SQL-Evalでの性能スコアは76.5%で、GPT-4の83%やsqlcoder-15bの78%にやや及ばない。
- このようなAIデータサイエンス・インターンが役立ちそうな応用分野は何だろうか？精度75%のAIを使って何が作れるのだろう？
- SQL作業中によく資料を調べるプログラマーとして、こうしたAIは最初のクエリ草案作成に使えそうだと思う。
- より大きなモデルは単発のケースではより良い結果を出せるかもしれないが、15bモデルを64GBのM1で簡単に動かせる。
- 企業環境では、スキーマ情報をOpenAIの学習データに漏らしたくないし、オフラインでクエリを実行したい場合もある。
- 多くのクエリを実行したいときは、小さくてローカルなモデルが有用だ（コスト削減）。
- 非技術者でも質問できるミニ・データサイエンティストは魅力的だが、クエリが25%の「不正確な」ケースに入るかどうかをどう判断するのか気になる。
- 複数のAIが互いの回答を検証する、RAIDのような合意アルゴリズムで全体の成功率を上げられるかもしれない。
- こうした考えの多くは頭の中を整理しているだけだが、他の人はもっと多くのアイデアを持っているかもしれない。OPのリリースおめでとう！
text-to-SQLモデルは正しい問題を解いていないと思う。
- 難しいのは文法やgroup byクエリの書き方が分からないことではなく、データの意味を理解することだ。
- Snowflakeの50カラムあるテーブルを見ても、カラム名だけでそれが何かを推測することはできない。
- たとえば、すべて...priceという名前の10個のカラムがあるテーブルなら、実際の意味を知るためにWikiを調べたりDBT定義を読んだりする必要がある。
- モデルが生成するクエリは信頼できない。モデルはデータを理解しておらず、クエリ文法だけを理解している。
これはオープンソースではない点を指摘しておく。利用ベースの制限があるので、「ソース利用可能」と呼ぶべきだろう。
これは興味深く、自分の関心分野でもあるが、複雑な質問だとは思わない。基本的な分析クエリだ。
- たいていのアナリストなら寝ながらでもこういうものは書ける。
- ChatGPTをSQL作成に使ってみたが凡庸だった。ただ、確実に良くなっていくだろう。
AIの多くの用途と同様に、これは「シード」として非常に良い。特に範囲ごとのグループ化のようなアイデアを出すときに有効だ。
- しかし、ほぼすべてのデータベースで問題は細部にある。
- 製品ごとに「数量」の解釈が異なり（例: 箱単位か個別単位か）、クーポンや割引が奇妙な形でモデリングされ、重量がポンド/キログラム前提で単位指定なしに混在していたりする、など。
これが75%しか正確でないからといって役に立たないと言う人は、次の2点を考慮すべきだ。
- これは第一版であり、すでに想像できるどんなAirtableよりも、プロダクトオーナーやアナリストにとって1000倍有用だ。
- どの課題でも正確さを求めたくなるものだが、私たちはすでに「十分に良い」経済の中で生きており、これが十分近ければビジネスには十分だろう。
より複雑で現実的なベンチマークであるBirdではどうなのか気になる。
データ分野で働いた経験から言うと、多くの人は経営陣から質問を受け、その質問に答えるSQLを書けるだけデータウェアハウスを理解し、ときには見栄えよく整形した回答を届ける責任を負っている。
- ときには経営陣が「なぜその数字はこんなに低いんだ？そんなに低いはずがない」といった追加質問をしてくるのを見越し、データエンジニアにバグ確認を依頼しなければならない。
- すべてのLLMと同様に、これがその責任をずっと楽にするのか、それとも完全になくしてしまうのかは分からない。
本当にクールだし、ライセンスが標準的ではないにもかかわらずオープンソースのように見える。
- 実際のモデルはここで見つかる: NaturalSQL-6.7B-v0
- これは優れたベースモデルに見えるが、小規模モデルにとってtext-to-SQLが良いユースケースなのかは気になる。
- 私たちもこの分野でツールを開発しており、答えをよりよく知っていてほしいという期待からgpt-4を使いたい。gpt 3.5でさえ本番運用には十分ではない。
とてもクールだが、このライセンスがVannaと一緒に使えるのか気になる: Vanna

NaturalSQL-7B - 自然言語をSQLに変換する強力なモデル

例

関連記事

1件のコメント

Hacker Newsのコメント