Vanna.ai: Mit SQL-Datenbanken sprechen

• Open-Source-LLM mit RAG (Retrieval-Augmented Generation) zur präzisen Generierung von Text-to-SQL

Wie Vanna funktioniert

• Training des RAG-"Modells": Ein RAG-Modell wird auf den Daten des Nutzers trainiert.
• Fragen stellen: Stellt man mit dem trainierten Modell eine Frage, gibt es eine SQL-Abfrage zurück, die automatisch auf der Datenbank ausgeführt werden kann.

Benutzeroberflächen

• Einige mit Vanna erstellte Benutzeroberflächen sind Jupyter Notebook, vanna-ai/vanna-streamlit, vanna-ai/vanna-flask, vanna-ai/vanna-slack usw.

Erste Schritte

• Installation: Vanna kann mit dem Befehl pip install vanna installiert werden.
• Import: Mit dem Code import vanna as vn kann Vanna verwendet werden.

Training

• Training mit DDL-Anweisungen: Das Modell kann mit DDL-Anweisungen trainiert werden, die Informationen über Tabellennamen, Spalten, Datentypen und Beziehungen in der Datenbank enthalten.
• Training mit Dokumentation: Das Modell kann durch Hinzufügen von Dokumentation zu Geschäftsbegriffen oder Definitionen trainiert werden.
• Training mit SQL: Vorhandene SQL-Abfragen können als Trainingsdaten hinzugefügt werden, um neue SQL-Abfragen zu erzeugen.

Fragen stellen

• Mit der Methode vn.ask("Frage") lassen sich relevante SQL-Abfragen erhalten.

RAG im Vergleich zu Fine-Tuning

• RAG ist über verschiedene LLMs hinweg portierbar, Trainingsdaten lassen sich leicht entfernen, die Kosten sind geringer und die Anpassungsfähigkeit an die Zukunft ist höher.
• Fine-Tuning ist nützlich, wenn die Anzahl der Tokens im Prompt minimiert werden muss, startet jedoch langsamer und verursacht höhere Trainings- und Ausführungskosten.

Warum Vanna wählen?

1. Hohe Genauigkeit bei komplexen Datensätzen: Die Leistungsfähigkeit von Vanna wird durch die Trainingsdaten bestimmt.
2. Sicherheit und Datenschutz: Inhalte der Datenbank werden nicht an das LLM oder eine Vektordatenbank gesendet.
3. Selbstlernend: Bei der Nutzung über Jupyter kann Vanna erfolgreich ausgeführte Abfragen automatisch zum Lernen verwenden.
4. Unterstützung für alle SQL-Datenbanken: Es kann mit jeder SQL-Datenbank verbunden werden, die sich mit Python anbinden lässt.
5. Wahl des Frontends: Man kann in Jupyter Notebook starten und es Nutzern dann als Slackbot, Web-App, Streamlit-App oder über ein benutzerdefiniertes Frontend bereitstellen.

Vanna erweitern

• Vanna ist so konzipiert, dass es sich mit jeder Datenbank, jedem LLM und jeder Vektordatenbank verbinden lässt.
• Die abstrakte Basisklasse VannaBase definiert die Grundfunktionen und bietet eine Implementierung mit OpenAI und ChromaDB.

Weitere Materialien

• Es werden vollständige Dokumentation, eine Website und eine Discord-Gruppe für Support bereitgestellt.

GN⁺-Meinung:

• Vanna ist ein leistungsstarkes Tool zur Automatisierung von Datenbankverwaltung und SQL-Abfrageerstellung, mit dem Nutzer für komplexe Datensätze einfach hochpräzise SQL-Abfragen erzeugen können.
• Dank der benutzerfreundlichen Oberfläche und der Selbstlern-Funktionen können auch Nicht-Fachleute Datenbanken effizient nutzen, was datenbasierte Entscheidungen weiter beschleunigen kann.
• Die Erweiterbarkeit und Zukunftsanpassungsfähigkeit von Vanna bieten Unternehmen die Möglichkeit, flexibel auf technologische Veränderungen zu reagieren und ihre Datenmanagementprozesse kontinuierlich zu verbessern.

[GN⁺]

Hacker-News-Kommentare

• Erfahrung beim Entwickeln eines ChatDB.ai-Projekts

  • Es wird ein ähnliches Projekt namens ChatDB.ai entwickelt.
  • Die erfolgreichste Erfahrung mit der Kombination aus AI und SQL bestand darin, nach jeder Iteration Fehler des SQL-Anbieters als Feedback an das LLM zurückzugeben.
  • Durch die Verwendung eines Wrappers für formatierte Fehlermeldungen und das konsequente Vorschlagen von Abfragen der Systemtabellen war dies sehr effektiv, um Schema-Informationen zu entdecken.
  • Mit diesen kleinen Anpassungen wurde es überraschend geschickt darin, Abfragen zu finden, die Joins über mehr als vier Tabellen erfordern.

• Persönliche Erfahrung mit GPT-4

  • Mit GPT-4 wurden bereits ähnliche Aufgaben ausgeführt.
  • Mit dem Befehl SHOW TABLE in der MySQL-CLI wurde die Tabellenstruktur geprüft und darauf basierend eine Abfrage erzeugt, die Geschäftskennzahlen wie die Abbruchrate von Warenkörben anzeigt.
  • Diese Methode hat in der Erfahrung des Nutzers ziemlich gut funktioniert.

• Skeptische Sicht auf Systeme zur Übersetzung von natürlicher Sprache in SQL

  • Zwar wird der Entwicklungsaufwand für Systeme anerkannt, die natürliche Sprache in SQL übersetzen, dennoch besteht Skepsis, da die grundlegenden Eigenschaften natürlicher Sprache und des Modells schätzend sind und es an Präzision fehlt.
  • SQL-Datenbanken sind in den meisten Fällen für exakte und präzise Informationsverarbeitung ausgelegt, und das Einführen einer schätzenden Schicht kann die Probleme verschlimmern.
  • Es wird infrage gestellt, ob solche Versuche die Anforderungen der realen Welt tatsächlich produktiv lösen.

• Interesse an ähnlichen Produkten, einschließlich YC-geförderter Startups

  • Es werden mehrere ähnliche Produkte wie Minds DB (YC W20), Buster (YC W24) und DB Pilot verfolgt, und an diesem Bereich besteht großes Interesse.
  • Der Nutzer sucht selbst nach solchen Lösungen.

• Erfahrung mit einem auf duckdb basierenden Reporting-Service

  • Insgesamt funktioniert es gut, aber es gibt einige Probleme:
    • GPT-4 weicht trotz niedriger Temperatureinstellung gelegentlich von Beispielen oder dem Schema ab.
    • Der Service hostet generische Daten, aber Kunden verlangen die Erstellung von Berichten in ihrer eigenen Domänensprache.
    • Das Debugging von LLM-Prompts ist schwierig. Kunden können das Modell leicht verwirren.
    • Den Kunden wird eine „Erklärung“ zur generierten Abfrage bereitgestellt, um transparent zu machen, was zur Erstellung des Berichts verwendet wurde.

• Bedenken und Erklärung zur Funktionsweise von RAG

  • Es werden Bedenken hinsichtlich der Verwendung des Begriffs „train“ geäußert.
  • Es wird viel Zeit darauf verwendet zu erklären, dass RAG kein Training oder Fine-Tuning benötigt, sondern nur Datenvorbereitung, Chunking und Vektorisierung.

• Neugier auf das Halluzinationsproblem von LLMs

  • Es besteht Neugier darüber, wie ein LLM Zeitkonzepte wie „gestern“ interpretiert, und über das Problem, dass generiertes SQL zwar syntaktisch gültig sein kann, aber dennoch nicht der Absicht entspricht.
  • Besonders bei Aggregatabfragen wie MAX oder COUNT besteht das Risiko, falsche Zahlen auszugeben; um das zu prüfen, müsste man das SQL direkt lesen, was dem eigentlichen Zweck widerspricht.

• Teilen von Erfahrungen mit eigenen Datensätzen und Technologien

  • Eine ähnliche Technik wird genutzt, um einen Bot zu entwickeln, mit dem interne Mitarbeiter mit strukturierten Datensätzen interagieren können.
  • In der Praxis funktioniert es teilweise, aber es gibt einige Herausforderungen:
    • Es gibt viele spezifische arbeitsbezogene Enumerationen und Datentypen, die in bestehenden Modellen nicht enthalten sind; diese müssen manuell definiert und dem Prompt als Kontext hinzugefügt werden.
    • Die Verarbeitung zeitbezogener Fragen ist schwierig.
    • Da Nutzer alles Mögliche fragen können, werden viele Beispiel-SQL-Abfragen für eine einzelne Tabelle benötigt.
    • Die Ausweitung auf verschiedene Tabellen ist schwierig, und es wird gefragt, ob es dafür einen effizienteren Weg gibt.
    • Es wurde das Modell Llama2 70B Gen verwendet, aber es besteht Neugier, ob andere Modelle bei der Erzeugung von SQL-Abfragen bessere Leistung zeigen.

• Erfahrung bei bit.io und Reaktionen der Kunden

  • Ähnliche Arbeit wurde bei bit.io durchgeführt, und die Leute mochten es.
  • Es gibt mehrere Artikel über Erkenntnisse aus dieser Arbeit; inzwischen wurde das Unternehmen von Databricks übernommen und der Service eingestellt.
  • Es besteht Bereitschaft, so viele Fragen wie möglich zu beantworten.