15 Punkte von xguru 2024-02-07 | 1 Kommentare | Auf WhatsApp teilen
  • Erreicht 76,5 % bei SQL-Eval und zeigt damit die beste Leistung in seiner Modellgrößenklasse
    • Zwar unter GPT-4 (83 %), aber besser als GPT-3.5-Turbo (65 %) / Claude-2 (64,5 %)
    • Höher als sqlcoder-7b (71 %) und ähnlich wie sqlcoder-15b (78 %)
  • ChatDB wurde entwickelt, ein Tool, mit dem sich Dashboards ohne SQL-Schreiben als No-Code erstellen lassen

Beispiel

  • Frage: Bestimmen Sie den Kunden mit dem höchsten Bestellwert im vergangenen Monat und listen Sie alle von ihm bestellten Produkte samt Menge auf.
  • Ausgabe:
    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 liefert auch bei komplexen Fragen wie der obigen, bei Subqueries und bei Verhältnissen sehr gute Ergebnisse.

1 Kommentare

 
xguru 2024-02-07

Hacker-News-Kommentare

  • Die Leistungsbewertung in SQL-Eval liegt bei 76,5 %, also etwas hinter GPT-4 mit 83 % und sqlcoder-15b mit 78 %.

    • Für welche Anwendungsbereiche könnte ein solcher KI-Datenwissenschafts-Praktikant nützlich sein? Was kann man mit einer KI bauen, die eine Genauigkeit von 75 % hat?
    • Als Programmierer, der bei SQL-Arbeiten oft Referenzen nachschlägt, könnte ich eine solche KI zum Erstellen eines ersten Query-Entwurfs nutzen.
    • Größere Modelle liefern in einem einzelnen Fall vielleicht bessere Ergebnisse, aber ein 15b-Modell lässt sich problemlos auf einem 64-GB-M1 ausführen.
    • In Unternehmensumgebungen möchte man Schema-Informationen nicht in die Trainingsdaten von OpenAI durchsickern lassen, und manchmal möchte man Queries auch offline ausführen.
    • Wenn man viele Queries ausführen möchte, ist ein kleines lokales Modell nützlich, auch aus Kostengründen.
    • Ein Mini-Datenwissenschaftler, den auch nichttechnische Personen befragen können, wäre großartig, aber ich frage mich, wie man erkennen soll, ob eine Query zu den 25 % „ungenauen“ Fällen gehört.
    • Vielleicht könnte man die Gesamterfolgsquote mit einem RAID-ähnlichen Konsensalgorithmus erhöhen, bei dem mehrere KIs gegenseitig ihre Antworten verifizieren.
    • Das meiste davon ist eher ein Sortieren meiner Gedanken, aber andere haben vielleicht noch mehr Ideen. Glückwunsch an OP zum Launch!
  • Ich glaube nicht, dass Text-to-SQL-Modelle das richtige Problem lösen.

    • Der schwierige Teil ist nicht die Syntax oder nicht zu wissen, wie man eine group by-Query schreibt, sondern die Bedeutung der Daten zu verstehen.
    • Wenn man eine Snowflake-Tabelle mit 50 Spalten sieht, kann man allein anhand der Spaltennamen nicht erraten, was sie bedeuten.
    • Wenn es zum Beispiel eine Tabelle mit 10 Spalten gibt, die alle auf ...price enden, muss man im Wiki nachsehen oder die DBT-Definitionen lesen, um die tatsächliche Bedeutung zu verstehen.
    • Man kann den vom Modell generierten Queries nicht vertrauen; das Modell versteht die Daten nicht, sondern nur die Query-Syntax.
  • Es wird darauf hingewiesen, dass dies kein Open Source ist; wegen der nutzungsbasierten Einschränkungen würde ich es eher „source available“ nennen.

  • Das ist interessant und gehört zu einem Bereich, der mich interessiert, aber ich halte das nicht für eine komplexe Frage, sondern für eine grundlegende Analysefrage.

    • Die meisten Analysten könnten so etwas im Schlaf schreiben.
    • Ich habe ChatGPT zum Schreiben von SQL verwendet, und es war eher mittelmäßig, aber es wird sicher besser werden.
  • Wie bei vielen Einsatzmöglichkeiten von KI ist es als „Seed“ sehr gut, besonders wenn es Ideen wie Gruppierungen nach Bereichen vorschlägt.

    • In fast jeder Datenbank steckt das Problem jedoch im Detail.
    • Verschiedene Produkte interpretieren „Menge“ unterschiedlich, etwa Boxen gegenüber Einheiten, Coupons und Rabatte werden auf seltsame Weise modelliert, Gewichte werden als Pfund/Kilogramm angenommen und ohne Einheitenangabe gemischt usw.
  • Wer sagt, das sei nutzlos, weil es nur zu 75 % korrekt ist, sollte zwei Dinge bedenken:

    • Das ist die erste Version, und sie ist für Product Owner und Analysten bereits tausendmal nützlicher als jedes Airtable, das man sich vorstellen kann.
    • Natürlich möchte man bei allen Herausforderungen korrekt sein, aber wir leben bereits in einer „good enough“-Ökonomie, und wenn das nah genug dran ist, ist es für Unternehmen gut genug.
  • Ich frage mich, wie es bei Bird abschneidet, einem komplexeren und realistischeren Benchmark.

  • Aus meiner Erfahrung in der Datenbranche heraus bekommen viele Leute Fragen von Führungskräften, müssen das Data Warehouse gut genug verstehen, um SQL zu schreiben, das diese Fragen beantwortet, und manchmal auch eine schön formatierte Antwort liefern.

    • Manchmal muss man Folgefragen wie „Warum ist diese Zahl so niedrig? So niedrig kann sie doch unmöglich sein“ vorhersehen und deshalb Dateningenieure bitten, auf Bugs zu prüfen.
    • Wie bei allen LLMs bin ich mir nicht sicher, ob das diese Verantwortung deutlich leichter macht oder sie vollständig überflüssig macht.
  • Wirklich cool, und trotz der nicht standardmäßigen Lizenz wirkt es wie Open Source.

    • Das eigentliche Modell findet man hier: NaturalSQL-6.7B-v0
    • Das scheint ein hervorragendes Basismodell zu sein, aber ich frage mich, ob Text-to-SQL für kleine Modelle ein guter Anwendungsfall ist.
    • Wir entwickeln in diesem Bereich ebenfalls Tools und würden lieber GPT-4 verwenden, in der Hoffnung, dass es die Antworten besser kennt. Selbst GPT 3.5 ist für den produktiven Einsatz nicht gut genug.
  • Sehr cool, aber ich frage mich, ob diese Lizenz zusammen mit Vanna verwendet werden kann: Vanna