Dataherald ist eine KI-Konvertierungs-Engine für natürliche Sprache in SQL auf Unternehmensebene, die es technisch nicht versierten Benutzern ermöglicht, die Datenbank direkt durch Konversation abzufragen, ohne SQL-Anweisungen schreiben zu müssen.

Dataherald

Kernparameter und Statistiken von Dataherald

Dataherald ist offiziell als Konvertierungs-Engine für natürliche Sprache in SQL auf Unternehmensebene positioniert. Sein Kernwert besteht darin, technisch nicht versierten Benutzern die direkte Abfrage relationaler Datenbanken durch tägliche Gespräche zu ermöglichen, ohne dass das Datenteam SQL-Anweisungen schreiben muss. Der grundlegende Unterschied zu herkömmlichen BI-Tools besteht darin, dass es nicht auf voreingestellten Dashboards oder festen Berichtsvorlagen basiert, sondern Benutzerabsichten in Echtzeit analysiert, Abfrageanweisungen dynamisch generiert und mehrere Dialogrunden unterstützt, um Anforderungen schrittweise zu verfeinern.

Projekte	Öffentliche Informationen
Offizielle Positionierung	Natural Language to SQL-Engine der Enterprise-Klasse
Kernkompetenzen	NL2SQL, Mehrrunden-Dialogkontext, komplexe SQL-Generierung (JOIN/Unterabfrage/Aggregation/Fensterfunktion)
Unterstützte Datenbanken	PostgreSQL, MySQL, BigQuery, Snowflake, Databricks, MS SQL Server, ClickHouse, MariaDB, Redshift
Vektorspeicher	Tannenzapfen, Astra, Chroma
Bereitstellungsmethode	Selbsthosting (Docker Compose), Cloud-Hosting (Enterprise Edition)
Eingabemethode	Natürliche Sprache (hauptsächlich Englisch)
Ausgabeformat	SQL-Anweisung + Abfrageergebnis + CSV-Export
Open-Source-Lizenz	Apache-2.0
GitHub-Sterne	~3.600
GitHub Forks	~264
Code-Mitwirkende	19
Neueste Version	v1.0.3 (30.04.2024, GitHub-Veröffentlichungen)
Gesamtveröffentlichungen	9 Versionen
Kernsprachen	Python (58,5 %), TypeScript (39,3 %)
Systemkomponenten	Engine, Enterprise API, Admin-Konsole, Slackbot

Bereitstellungsarchitektur: Dataherald übernimmt eine Microservice-Architektur, die vier unabhängige Komponenten umfasst: Engine (Kern-NL2SQL-Engine), Enterprise (Benutzer-/Organisations-/Authentifizierungsverwaltung), Admin Console (Verwaltungsschnittstelle) und Slackbot (Slack-Integration). Jede Komponente wird einheitlich über Docker Compose orchestriert und unterstützt so die geteilte Bereitstellung bei Bedarf.

Breite der Datenbankabdeckung: Von v0.0.1 bis v1.0.3 hat Dataherald nach und nach 9 Arten relationaler Datenbanken und 3 Arten von Vektorspeicher integriert und deckt Mainstream-OLTP (MySQL, PostgreSQL, SQL Server), OLAP (ClickHouse, Redshift) und Cloud-Data-Warehouses (BigQuery, Snowflake, Databricks) ab. Dies ist der Hauptunterschied zur NL2SQL-Lösung, die nur einen einzigen Datenbanktyp unterstützt.

Iterationsrhythmus: Die erste öffentliche Veröffentlichung v0.0.1 (2023-08), v1.0.0 (2024-01), v1.0.3 (2024-04), danach sank die GitHub-Commit-Häufigkeit deutlich und befindet sich derzeit in einer Wartungsphase. Bei der Auswahl müssen Sie die Community-Aktivität und die langfristigen Supportrisiken bewerten.

Dataheralds Benutzer und Marktbekanntheit

Die Marktanerkennung von Dataherald spiegelt sich hauptsächlich im Feedback der Open-Source-Community und der PoC-Verifizierung von Unternehmen wider. Der Beamte hat keine spezifischen Umsatzdaten, die Anzahl der zahlenden Kunden oder Einzelheiten zu den SLA-Verpflichtungen bekannt gegeben.

Beliebtheit in der GitHub-Community: Über 3.600 Sterne und 264 Forks, was im NL2SQL-Open-Source-Track auf einem oberen mittleren Niveau liegt. Vergleich ähnlicher Projekte: SQLChat hat etwa 4.000 Sterne, Vanna hat etwa 12.000 Sterne und DB-GPT hat etwa 14.000 Sterne. Dataherald zeichnet sich durch die Bereitstellung eines vollständigen Satzes von vier Komponenten (Engine + Enterprise + Admin Console + Slackbot) aus, was einer Bereitstellungsform auf Unternehmensebene näher kommt als die meisten Projekte, die nur eine Kern-Inferenz-Engine bereitstellen.

Unternehmensüberprüfungsszenario: Zu den typischen Anwendungsfällen, die in der offiziellen Dokumentation und der GitHub-README-Datei hervorgehoben werden, gehören eingebettete Q&A-Funktionen in SaaS, auf Slack basierende Zählroboter in natürlicher Sprache und Self-Service-Zählportale für Geschäftsteams. Diese Anwendungsfälle richten sich an mittlere und große Unternehmen, die in Data Warehouses investiert haben, denen es aber an analytischen Arbeitskräften mangelt, und nicht an kleine und Kleinstteams.

Ökologische Zusammenarbeit: Das Projekt integriert LangSmith zur Beobachtbarkeit, unterstützt die drei Vektordatenbanken Pinecone/Astra/Chroma als Schema-Kontextspeicher und kann mit gängigen LLM-Diensten (OpenAI GPT-Serie Anthropic Claude, selbst gehostete Modelle) verbunden werden. Dies zeigt, dass es modellunabhängig und nicht an einen einzelnen KI-Anbieter gebunden ist.

Voraussetzungen für die Einführung: Die echte Wertfreigabe von Dataherald erfordert, dass das Unternehmen bereits über ① strukturierte relationale Datenbestände, ② klare Schemadokumente oder goldene Abfragebeispiele (Golden SQLs) verfügt und ③ IT-Teams bereit sind, zusätzliche selbstgehostete Infrastruktur zu unterhalten. Ohne eines davon wird der Landeeffekt erheblich verringert.

Kostenvorteile von Dataherald

Die Kostenstruktur von Dataherald muss getrennt von den drei Ebenen „C-Seite/einzelne Benutzer“, „API/Entwicklerintegration“ und „Enterprise/privatisierte Bereitstellung“ untersucht werden.

C-Client/einzelne Benutzer:

• Explizite Kosten: Die Open-Source-Community-Edition ist völlig kostenlos und die Apache-2.0-Lizenz ermöglicht die beliebige Nutzung, Änderung und Weiterverbreitung. Einzelne Entwickler müssen lediglich die Betriebskosten ihrer eigenen Server tragen (Ausführung von 4 Containern im Docker Compose-Modus und die geschätzte Mindestkonfiguration beträgt 4 Kerne und 8G Speicher).
• Versteckte Kosten: Sie müssen den LLM-API-Schlüssel (z. B. OpenAI, Anthropic) selbst konfigurieren und die LLM-Anrufgebühr wird per Token abgerechnet. Eine typische Abfrage einschließlich Schema-Scanning + SQL-Generierung verbraucht etwa 2.000–8.000 Token, was mit der Komplexität der Abfrage zunimmt. In Szenarien mit häufigen Aufrufen kann der LLM-API-Overhead schnell die Infrastrukturkosten übersteigen.

API/Entwickler-Integration:

• REST-API-Schicht: Die Open-Source-Versionen der Engine- und Enterprise-Komponenten bieten eine vollständige RESTful-API (einschließlich Eingabeaufforderungen, SQL-Generationen, NL-Generationen, Feinabstimmung und anderen Endpunkten), die Entwickler kostenlos in ihre eigenen Anwendungen integrieren können.
• Tuning-Kosten: Dataherald unterstützt die Feinabstimmung (Finetuning) basierend auf Golden SQLs, aber der Feinabstimmungsprozess verbraucht OpenAI-Schulungsguthaben und erfordert die Vorbereitung hochwertiger gepaarter Question-SQL-Beispiele. Die empfohlene Anzahl an Proben beträgt 50–200, und die Kosten für eine einzelne Feinabstimmung liegen in der Größenordnung von mehreren zehn Dollar.
• Implizite Integrationskosten: Sie müssen die Schemabeschreibung für jede Datenbankverbindung manuell konfigurieren (oder einen automatischen Scan ausführen), die Golden SQLs-Beispielbibliothek verwalten und sich mit der versteckten Logik auseinandersetzen, dass das LLM-generierte SQL nicht den Erwartungen entspricht. Dieser technische Aufwand ist oft höher als die Kosten der API-Aufrufe selbst.

Unternehmens-/Privatbereitstellung:

• Preise für die Enterprise Edition: Der offizielle Preis der Enterprise Edition wurde nicht bekannt gegeben. Entsprechend der Branchenpraxis wird spekuliert, dass ein Abonnementsystem eingeführt wird. Die Abrechnungsdimensionen umfassen normalerweise: Anzahl der Datenbankverbindungen, API-Aufrufkontingent und SLA-Ebene des Benutzerplatzes. Der Mehrwert der Enterprise Edition umfasst SSO-Integration, Audit-Protokollierung und dedizierte SLA-Unterstützung.
• Infrastrukturkosten: Bei der privaten Bereitstellung muss das Unternehmen Docker verwalten, um die begrenzte MongoDB-Datenbank, Vektordatenbank und Netzwerkkonfiguration auszuführen. Bei einer moderaten Auslastung von 1.000 Abfragen pro Tag werden die monatlichen Infrastrukturkosten auf 100–500 US-Dollar geschätzt (Cloud-Host + Vektorspeicher + Bandbreite).
• Personelle Betriebs- und Wartungskosten: Mindestens ein Entwicklungs- oder Betriebs- und Wartungspersonal, das mit Docker- und LLM-Aufrufen vertraut ist, ist für die Systemwartung, die Verwaltung von Golden SQLs und die Überwachung der Abfragequalität verantwortlich. Diese versteckten Kosten betragen in der Regel das Drei- bis Fünffache der Infrastrukturkosten.

Kostenvergleich: NL2SQL Open-Source-Lösung

Lösung	Open-Source-Lizenz	Komplexität der Bereitstellung	Datenbankabdeckung	Feinabstimmungsunterstützung	Unternehmensfunktionen	Gemeinschaftsaktivität
Datenherald	Apache-2.0	Mittel (4 Komponenten Docker)	9 Arten von DB + 3 Arten von Vektorspeicher	✅ Integrierte Feinabstimmungs-API	✅ Admin-Konsole + Slackbot + Enterprise	Mittel (3,6.000 Sterne)
Vanna	MIT	Low (Python-Bibliothek)	Unterstützt hauptsächlich SQLite/PG	✅ Schulung über DDL-Dokumente	❌ Keine	Hoch (12.000 Sterne)
SQLChat	MIT	Niedrig (Knotenbibliothek)	Unterstützt hauptsächlich MySQL/PG	❌ Keine	❌ Keine	Mittel (4.000 Sterne)
DB-GPT	Apache-2.0	Hoch (Mehrere Komponenten)	Mehrere DBs	✅ Unterstützung	✅ Vollständige Unternehmensfunktionen	Hoch (14.000 Sterne)

Highlights der Kostenunterschiede:

– Dataherald bietet das umfassendste Paket auf Unternehmensebene in der Open-Source-NL2SQL-Lösung (Admin-Konsole Slack-Integration, Mandantenfähigkeit, Audit-Log-fähig), geeignet für Teams, die „out-of-the-box“ benötigen, anstatt alles von Grund auf neu zu erstellen.

• Wenn Sie bereits über LLM-API-Credits verfügen und eine geringe Toleranz gegenüber der Komplexität der Bereitstellung haben, haben Vanna (Installation einer einzelnen Python-Bibliothek) oder SQLChat (Node.js-Paket) niedrigere anfängliche Startkosten.
• DB-GPT ist führend in Bezug auf funktionale Vollständigkeit und Community-Skala, aber seine Bereitstellungskomplexität ist auch höher und es ist hauptsächlich für chinesische Szenarien optimiert, was sich von der englischsprachigen Positionierung von Dataherald unterscheidet.

Hauptfunktionen von Dataherald

• Natural Language to SQL (NL2SQL): Geben Sie „Umsatzranking nach Region im letzten Quartal“ ein, die Engine erkennt automatisch die Aggregationsabsicht und generiert SQL-Anweisungen mit GROUP BY und ORDER BY. Der Kernmechanismus besteht darin, Benutzerfragen über LLM dem Datenbankschema zuzuordnen und dann den Konversationskontext zu kombinieren, um ausführbares SQL zu synthetisieren. Der Unterschied zu herkömmlichen BI-Tools besteht darin, dass es keine voreingestellte Berichtsstruktur gibt und Benutzer beliebige Abfragedimensionen frei beschreiben können.

• Mehrere Runden zur Erhaltung des Dialogkontexts: Stellen Sie weiterhin Fragen basierend auf dem ersten Abfrageergebnis (z. B. „Nur Ostchina anzeigen“ oder „Zur Anzeige nach Monat wechseln“). Die Engine behält die Filterbedingungen und die Aggregationslogik des Vorbestellungs-SQL bei und ändert die WHERE-Klausel oder das GROUP BY-Feld nur inkrementell. Der eigentliche Vorteil für Geschäftsanwender besteht darin, dass nicht alle Anforderungen auf einmal beschrieben werden müssen und der Umfang der Abfrage wie bei einem Gespräch mit einem Menschen schrittweise eingegrenzt werden kann. Die interaktiven Runden einer einzelnen Analyseaufgabe werden in der Regel von 1 Runde auf 3–5 Runden erweitert, jede Runde bleibt jedoch semantisch kohärent.

• Automatische Erkennung des Datenbankschemas: Die Engine scannt automatisch die Datenbanktabellenstruktur, Feldnamen, Feldtypen, Primär- und Fremdschlüsselbeziehungen und gleicht Feldaliase und zugehörige Schlüssel beim Generieren von SQL automatisch ab. Schema-Scan-Ergebnisse werden in MongoDB und Vektordatenbanken gespeichert. Beim Generieren von SQL ruft LLM nur Tabellen und Felder ab, die sich auf Benutzerfragen beziehen, als Kontext, wodurch vermieden wird, dass das gesamte Schema in Prompt gestopft wird und eine Token-Erweiterung verursacht.

• Erklärung der Abfrageergebnisse in natürlicher Sprache (NL-Generierung): Für die generierten SQL-Anweisungen und Ausführungsergebnisse generiert die Engine automatisch Erklärungen in natürlicher Sprache, um zu erklären, „welche Filterung für diese SQL durchgeführt wurde, welche Dimensionen aggregiert wurden und was die Grundlage für die Sortierung ist“. Der Hauptvorteil dieser Funktion für technisch nicht versierte Benutzer besteht darin, dass sie selbst dann, wenn sie SQL nicht verstehen, nachvollziehen können, ob die Abfragelogik korrekt ist, und so Vertrauen in die von der KI generierten Ergebnisse aufbauen können.

• Golden SQLs-Verwaltung und Modellfeinabstimmung: Unterstützt das Speichern verifizierter „Frage-SQL“-Paare in der Golden SQLs-Sammlung und die automatische Feinabstimmung (Feinabstimmung) von Modellen der GPT-Serie basierend auf diesen Beispielen. Die Genauigkeit des fein abgestimmten Modells für ähnliche Geschäftsabfragen wird erheblich verbessert. Hierbei handelt es sich um einen Mechanismus, der umso genauer ist, je mehr Sie ihn verwenden: In der Anfangsphase stützt er sich auf das Wissen des allgemeinen LLM, und wenn das Unternehmen proprietäre Abfragebeispiele sammelt, nähert sich die Genauigkeit allmählich einer Genauigkeit von über 90 % an.

• Visualisierung der Zwischenschritte (Streaming): Der in v1.0.2 eingeführte Streaming-Endpunkt zeigt die Zwischenschritte der SQL-Generierung – vom Schemaabruf über die SQL-Synthese bis zur Ergebnisausführung – und ermöglicht Benutzern und Entwicklern einen Einblick in die KI-Denkkette, was das Debuggen und den Vertrauensaufbau erleichtert.

• Integrierter Abfrageroboter von Slack: Über die Slackbot-Komponente können Benutzer direkt natürliche Sprache verwenden, um Fragen an die Datenbank im Slack-Kanal zu stellen, und der Roboter gibt Abfrageergebnisse oder CSV-Dateien zurück. Dies ist besonders nützlich für Betriebs-, Marketing- und Vertriebsteams ohne technischen Hintergrund: Es ist nicht erforderlich, BI-Tools zu öffnen, um die Datenerfassung in täglichen Arbeitsabläufen abzuschließen.

• CSV-Export und Dateispeicherung: Abfrageergebnisse können direkt in CSV exportiert und in S3 gespeichert werden (durch Konfigurieren von AWS-Anmeldeinformationen), was für die anschließende Sekundäranalyse in Excel oder Google Sheets geeignet ist. Verwenden Sie automatisch den Dateispeicher, wenn die Anzahl 50 Zeilen überschreitet, um zu verhindern, dass die API-Antwortnutzlast zu groß wird.

Modell- und Versionsentwicklung von Dataherald

Die Versionsgeschichte von Dataherald spiegelt deutlich den Entwicklungspfad von der Prototypenverifizierung über die Verbesserung der Unternehmensfunktionalität bis hin zur ökologischen Erweiterung wider. Das Folgende wurde auf der Grundlage öffentlicher Informationen von GitHub Releases zusammengestellt.

Mainline-Veröffentlichung

Version	Erscheinungsdatum	Kernänderungen	Meilensteine ​​
v0.0.1	2023-08	Erste Version, grundlegende NL2SQL-Abfragefunktion	Projektgenehmigung, MVP-Verifizierung
v0.0.2	14.09.2023	RESTful-Endpunktrekonstruktion, Standardisierung des MongoDB-Sammlungsnamens, Einführung der db_connection_id-Zuordnung	Finalisierung der API-Struktur, Übergang vom Rapid Prototyping zur Standardisierung
v0.0.3	26.09.2023	LLM Credentials unterstützt SSH-Verbindungsoptimierung und asynchrones Schema-Scanning	Die Verbindungsfunktionen für Unternehmen werden verbessert und die Scanleistung optimiert
v0.0.4	07.10.2023	Endpunkt benennt ObjectId-Fremdschlüssel-NL-Generierungsaufteilung um	API-Semantik klar, bereiten Sie sich auf 1.0 vor
v0.0.5	26.10.2023	llm_api_key-Feld vereinfachte S3-CSV-Speicherung, Fehlercodesystem	Vereinfachte Konfiguration und verbesserte Beobachtbarkeit
v0.0.6	14.11.2023	CSV-Generierungsflag S3-Zertifikat konfigurierbar	Verbesserte Datenexportfunktionen
v1.0.0	17.01.2024	Finetuning-API, Prompt/SQL-Generation/NL-Generation dreiphasige Aufteilung der Golden SQLs-Sammlung	Meilenstein zur Architekturreife
v1.0.1	05.03.2024	ClickHouse unterstützt den offiziellen MariaDB-Support, den Aktualisierungsendpunkt und die Fehlercodeverfeinerung	Erweiterung der Datenbankabdeckung
v1.0.2	04.04.2024	MS SQL Server, Astra/Pinecone serverlose Unterstützung Streaming-Zwischenschritt LangSmith-Integration	Ökologische Verbindung und Verbesserung der Beobachtbarkeit
v1.0.3	30.04.2024	Redshift-Unterstützung, Unterstützung mehrerer Schemata (PG/BigQuery/Snowflake/Databricks)	Die neueste Version, perfekt für Unternehmensszenarien mit mehreren Schemata

Interpretation des evolutionären Kontexts

Phase 1: Prototypenüberprüfung (v0.0.1-v0.0.2): Die ersten beiden Versionen haben hauptsächlich den End-to-End-Prozess „von natürlicher Sprache zu SQL“ abgeschlossen. Das RESTful API-Refactoring in v0.0.2 legt den Grundstein für alle nachfolgenden Unternehmensfunktionen.

Phase 2: Aufbau von Unternehmensverbindungsfähigkeiten (v0.0.3–v0.0.6): Schrittweise vollständige SSH-Verbindungen, mehrere Datenbanken, die den CSV-Export in den S3-Speicher unterstützen, Fehlercodesysteme und andere unternehmensnotwendige, aber nicht zum Kerngeschäft gehörende KI-Funktionen. Diese Phase zeigt, dass das Dataherald-Team erkennt, dass das Hindernis für die Implementierung von NL2SQL in Unternehmen nicht nur die Genauigkeit der KI, sondern auch die Datenkonnektivität sowie die Beobachtbarkeit von Betrieb und Wartung ist.

Phase drei: 1.0-Architekturreife (v1.0.0): v1.0.0 ist eine große Architekturänderung, die den ursprünglichen einzelnen „Frage → Antwort“-Prozess in eine dreistufige Pipeline aufteilt – Eingabeaufforderung (Problemverständnis) → SQL-Generierung (SQL-Synthese) → NL-Generierung (Ergebnisinterpretation) und die Feinabstimmungs-API einführt. Durch die dreistufige Aufteilung kann jeder Abschnitt unabhängig voneinander optimiert, zwischengespeichert und geprüft werden, was eine wichtige Designentscheidung für die Bereitstellung auf Unternehmensebene darstellt.

Phase 4: Ökologische Erweiterung und Wartung (v1.0.1-v1.0.3): Fokus auf die Erweiterung der Datenbankabdeckung (ClickHouse, MariaDB, SQL Server, Redshift) und Vektorspeicheroptionen (Astra, Pinecone serverless) bei gleichzeitiger Verbesserung der Beobachtbarkeit durch Streaming-Endpunkte. Nach Version 1.0.3 trat für das Projekt eine Wartungsphase mit geringer Aktivität ein und es wurden keine neuen Funktionsversionen veröffentlicht.

Kandidatenverifizierung und Community-Beitrag

Zusätzlich zu den Mainline-Releases fördert Dataherald die Teilnahme von 19 Mitwirkenden durch Pull Requests und Issues, die Fehlerbehebungen, Dokumentationsverbesserungen und kleinere Funktionserweiterungen abdecken. Aber insgesamt wird die Kernentwicklung des Projekts intern vom Team geleitet und die Community-Mitwirkenden konzentrieren sich hauptsächlich auf die Dokumentation und Randfunktionen.

Bewertung der Versionsstrategie: Die Versionsbenennung von Dataherald folgt der semantischen Versionsspezifikation (SemVer), aber es dauerte nur 8 Monate von v0.0.1 bis v1.0.3 und stagnierte dann. Bei der Auswahl müssen Sie Folgendes bewerten: ob die aktuellen Funktionen den Anforderungen entsprechen und ob Sie bereit sind, das Risiko einer Community-Abzweigung oder einer Selbstwartung in Kauf zu nehmen.

Die technischen Vorteile von Dataherald

Der technische Vorteil von Dataherald liegt nicht im Durchbruch eines einzelnen Algorithmus, sondern im Entwurf der technischen Architektur – wie man die NL2SQL-Funktionen von LLM in ein System auf Unternehmensebene kapseln kann, das implementiert, beobachtbar und iterierbar ist.

Dreistufige Pipeline-Architektur

Dataherald unterteilt die Verarbeitung einer Abfrage in natürlicher Sprache in drei unabhängige Phasen:

„ Benutzereingabe → [Eingabeaufforderung] → [SQL-Generierung] → [NL-Generierung] → Benutzerausgabe ↓ ↓ Schema-Vektorabruf Golden SQLs-Abgleich „

• Prompt-Phase: Empfangen Sie Benutzereingaben in natürlicher Sprache, kombinieren Sie den Konversationsverlauf (falls vorhanden) und relevante Schemainformationen, die aus der Vektordatenbank abgerufen wurden, und fügen Sie sie zu einer LLM-freundlichen Eingabeaufforderung zusammen. Die entscheidende Optimierung besteht darin, dass nicht das gesamte Datenbankschema auf einmal eingefügt wird, sondern nur die Tabellen und Felder, die für das Problem des Benutzers am relevantesten sind, durch Vektorähnlichkeitsabruf ausgewählt werden, was den Tokenverbrauch erheblich reduziert und die Ablenkung durch LLM verringert.
• SQL-Generierungsphase: Senden Sie die zusammengestellte Eingabeaufforderung an LLM, um SQL zu generieren. Wenn das Feinabstimmungsmodell von Golden SQLs konfiguriert ist, verwenden Sie zuerst das Feinabstimmungsmodell, um die Genauigkeit zu verbessern. Andernfalls greifen Sie auf das allgemeine Modell zurück. Der in Version 1.0.2 eingeführte Streaming-Endpunkt ermöglicht die Echtzeitanzeige von Zwischenschritten der SQL-Generierung – LLMs Gedankenkette, Feldabgleichsprozess JOIN-Bedingungsauswahl – was für das Debuggen und den Vertrauensaufbau von entscheidender Bedeutung ist.
• NL-Generierungsphase: Erklären Sie dem Benutzer in natürlicher Sprache, „was diese Abfrage bewirkt hat“ für die generierten SQL- und Ausführungsergebnisse. Dies ist ein unterschätztes, aber äußerst wertvolles Design: Nicht-technische Benutzer können SQL normalerweise nicht lesen, können aber durch Interpretation in natürlicher Sprache schnell beurteilen, ob die Abfragelogik korrekt ist, und entscheiden, ob sie die Ergebnisse akzeptieren.

Zusammenarbeit von Schemabewusstsein und Vektorabruf

Der Schema-Verarbeitungsmechanismus von Dataherald ist die zentrale Trennlinie zwischen ihm und dem einfachen Prompt-Wrapper:

1. Automatisches Scannen: Durchsuchen Sie die Datenbank über die asynchrone Hintergrundaufgabe des Endpunkts „POST /api/v1/table-descriptions/sync-schemas“, um Tabellennamen, Feldnamen, Feldtypen, Kommentare sowie Primär- und Fremdschlüsselbeziehungen zu erhalten.
2. Schema-vektorisierte Speicherung: Vektorisieren Sie die Tabellen- und Feldbeschreibungsinformationen (Name + Kommentar) mithilfe des Einbettungsmodells und speichern Sie sie in der Pinecone/Astra/Chroma-Vektordatenbank.
3. Abruf zur Laufzeit: Wenn der Benutzer eine Frage stellt, führen Sie zunächst eine Einbettung in die Frage durch, rufen Sie die Top-K-bezogenen Tabellen und Felder in der Vektorbibliothek ab und fügen Sie nur diese Kontexte in die LLM-Eingabeaufforderung ein.
4. Inkrementelles Caching: Scan-Ergebnisse werden in MongoDB zwischengespeichert und unterstützen inkrementelle Aktualisierungen anstelle einer vollständigen Rekonstruktion. Der Endpunkt „POST /api/v1/table-descriptions/refresh“ (eingeführt in v1.0.1) dient dazu, die Tabellenliste effizient zu aktualisieren, ohne alle Daten erneut zu scannen.

Die technische Bedeutung dieses Mechanismus besteht darin, dass Unternehmensdatenbanken oft Hunderte von Tabellen und Tausende von Feldern enthalten. Wenn sie alle in den LLM-Kontext eingefügt werden, ist der Token-Verbrauch inakzeptabel und LLM wird ernsthaft abgelenkt. Vektorabruf + dynamische Injektion steuern den Schemakontext jeder Abfrage innerhalb von 3–8 Tabellen unter Berücksichtigung von Genauigkeit und Kosten.

Golden SQLs mit Iteration geschlossen

Der Finetuning-Mechanismus von Dataherald stellt einen kontinuierlichen Optimierungsprozess dar:

„ Geschäftsabfrage → SQL-Generierung → Manuelle Überprüfung → In Golden SQLs speichern → Feinabstimmung des Modells → Genauigkeit verbessern ↑ Lösen Sie die Feinabstimmung regelmäßig aus „

• Golden SQLs Collection: Speichert validierte „Natural Language Question ↔ Standard SQL“-Paare. Jedes Paar enthält Frage, SQL, db_connection_id und Metadaten.
• Feinabstimmungsprozess: Rufen Sie „POST /api/v1/finetuning“ auf, um eine Feinabstimmungsaufgabe zu erstellen, und die Engine formatiert Golden SQLs automatisch in das für die OpenAI-Feinabstimmung erforderliche Datensatzformat und übermittelt es. Nachdem die Feinabstimmung abgeschlossen ist, können Sie den Status über „GET /api/v1/finetuning/{id}“ abfragen. Wenn der Status SUCCEEDED ist, kann er für die SQL-Generierung verwendet werden.
• Tatsächliche Ergebnisse: Der offiziellen Dokumentation zufolge verbessert das fein abgestimmte Modell die Genauigkeit der SQL-Generierung in proprietären Geschäftsdomänen erheblich. Obwohl der genaue Wert nicht offengelegt wird, ist er logisch sinnvoll: Das allgemeine Modell versteht möglicherweise, dass „Umsatz“ SUMME(Betrag) ist, versteht jedoch nicht den unternehmensspezifischen Wert „Nettoumsatz = SUMME(Betrag)-SUMME(Rabatt)-SUMME(Rendite)“; Nach der Feinabstimmung kann das Modell diese Geschäftsregeln lernen.

Modellunabhängigkeit und Austauschbarkeit

Dataherald behält die Abstraktion des zugrunde liegenden LLM auf Architekturebene bei: Die Engine greift über Konfigurationsschnittstellen auf verschiedene Modelle zu und ist nicht an einen einzelnen OpenAI-Anbieter gebunden. Die offizielle Unterstützung umfasst GPT-4/GPT-3.5, die Claude-Serie und selbst gehostete Modelle (über lokale Bereitstellung, die mit dem OpenAI-API-Format kompatibel ist). Dieses Design hat einen praktischen Wert in der Unternehmensbeschaffung: Sie können GPT-4 verwenden, um die Obergrenze der PoC-Verifizierungsgenauigkeit zu erreichen, und nach dem Online-Gehen zu einem selbstgehosteten Modell wechseln, um Inferenzkosten zu reduzieren und die Datensouveränität zu kontrollieren.

Mandantenfähigkeit und Berechtigungsisolierung

Die Enterprise-Komponente bietet organisationsweite Benutzerverwaltung, Rollenberechtigungen und Isolierung von Datenbankverbindungen. Jede Datenbankverbindung kann mit einem unabhängigen LLM-API-Schlüssel konfiguriert werden, der den schreibgeschützten Modus (wodurch die Generierung von UPDATE/DELETE/DDL-Anweisungen verhindert wird) und die Desensibilisierung von Daten unterstützt. Diese Mechanismen sind in Szenarien mit mehreren Abteilungen oder mehreren Kunden unbedingt erforderlich – verschiedene Abteilungen können Tabellen und Daten nur innerhalb des Berechtigungsbereichs abfragen.

So verwenden Sie Dataherald

Dataherald bietet mehrere Zugangs- und Integrationsmethoden und deckt unterschiedliche Nutzungsszenarien von der Entwickler-API-Integration bis zur Slack-Interaktion des Geschäftsteams ab.

Vergleich der Bereitstellungseinträge

Eingang	Anwendbare Personen	Startmethode	Voraussetzungen
Engine-API (Kern-Engine)	Entwickler	Docker Compose führt den Engine-Dienst aus	Docker, MongoDB, LLM API-Schlüssel
Enterprise API (voll funktionsfähig)	Entwickler/IT-Administrator	Docker Compose führt alle 4 Dienste aus	Docker, MongoDB, Vector Database LLM API-Schlüssel
Admin-Konsole (Administrationsoberfläche)	Datenanalyst/Administrator	Gestartet mit Enterprise, Browserzugriff	Enterprise-API läuft
Slackbot	Geschäftsteams	Gestartet mit Enterprise, Slack-App-Konfiguration	Enterprise API + Slack-App-Berechtigungen
REST-API	Entwickler	Engine/Enterprise-Endpunkt direkt aufrufen	Bereitgestellte API-Basis-URL

Schnelle Bereitstellung und Inbetriebnahme (selbst gehostet)

Mindestkonfigurationsanforderungen (PoC-Ebene):

„Bash

1. Klonen Sie das Repository

Git-Klon https://github.com/Dataherald/dataherald.git cddataherald

2. Kontextvariablen konfigurieren (siehe .env.example in jedem Dienstverzeichnis)

Mindestens Konfiguration erforderlich: OPENAI_API_KEY, MONGODB_URI

3. Starten Sie alle Dienste mit einem Klick

./docker-run.sh „

Der obige Befehl startet Engine (Port 80), Enterprise (Port 81), Admin Console (Port 3000) und Slackbot und erstellt automatisch ein Docker-Netzwerk. Nach dem Start kann über „http://localhost:3000“ auf die Verwaltungskonsole zugegriffen werden.

Beispiel für einen API-Aufruf

Datenbankverbindung erstellen:

„Bash curl -X POST http://localhost:80/api/v1/database-connections \ -H „Inhaltstyp: application/json“ \ -d '{ „alias“: „produktion_db“, „connection_uri“: „postgresql://user:password@host:5432/mydb“, „llm_api_key“: „“ }' „

Schema synchronisieren:

„Bash curl -X POST http://localhost:80/api/v1/table-descriptions/sync-schemas \ -H „Inhaltstyp: application/json“ \ -d '{"db_connection_id": ""}' „

Initiieren Sie eine Abfrage in natürlicher Sprache:

„Bash curl -X POST http://localhost:80/api/v1/prompts/sql-generations \ -H „Inhaltstyp: application/json“ \ -d '{ „db_connection_id“: „“, „question“: „Umsatzranking nach Region im letzten Quartal“ }' „

Feinabgestimmtes Modell:

„Bash curl -X POST http://localhost:80/api/v1/finetuning \ -H „Inhaltstyp: application/json“ \ -d '{ „db_connection_id“: „“, „golden_sql_ids“: [““, „“] }' „

Typischer Nutzungsprozess

1. Initialisierung: Dienst bereitstellen → Datenbankverbindung erstellen → Schema synchronisieren → Bestätigen Sie, dass der Scanstatus SYNCHRONISIERT lautet.
2. Überprüfung: Senden Sie mehrere grundlegende Abfragen (einfaches SELECT, bedingte Filterung), um die Generierungsqualität und die Richtigkeit der Ausführung zu überprüfen.
3. Sammeln Sie Stichproben: Speichern Sie für hochfrequente Geschäftsabfragen die verifizierten Frage-SQL-Paare in Golden SQLs.
4. Feinabstimmung: Die Feinabstimmung wird nach dem Sammeln von mehr als 50 Proben ausgelöst, um die Genauigkeit der vertikalen Domäne zu verbessern.
5. Online gehen: Rollenberechtigungen der Admin-Konsole konfigurieren → Für Geschäftsteams öffnen → Abfrageprotokolle und Fehlerraten überwachen.
6. Iteration: Überprüfen Sie regelmäßig die Abfrageprotokolle, fügen Sie neue Abfragemuster zu Golden SQLs hinzu und fahren Sie mit der Feinabstimmung fort.

Voreingestellte Notizen

• Wenn die Datenbanktabellen- und Feldnamen des Benutzers nicht auf Englisch (z. B. Chinesisch) vorliegen, werden die Schema-Überprüfung und das LLM-Verständnis von Dataherald erheblich eingeschränkt – dies ist eine der Hauptspracheneinschränkungen der aktuellen Version. – Für Produktionsbenutzer wird empfohlen, zuerst den schreibgeschützten Modus zu aktivieren und dann die Berechtigungen zu lockern, nachdem sichergestellt wurde, dass die SQL-Generierung keine unerwarteten UPDATE/DELETE-Vorgänge verursacht.
• Das automatische Scannen von Schemas kann bei großen Bibliotheken mehrere Minuten dauern. Der in v1.0.1 eingeführte Endpunkt „/refresh“ kann die inkrementelle Aktualisierungszeit erheblich verkürzen.

Produktpreise für Dataherald

Das Preissystem von Dataherald ist in zwei Pfade unterteilt: Open-Source-Community-Version und kommerzielle Unternehmensversion. Der offizielle Preis der Enterprise-Version wurde nicht bekannt gegeben.

Open Source Community Edition (Apache-2.0):

• Gebühr: Völlig kostenlos, keine Begrenzung der Anzahl der Benutzer, des Abfragevolumens oder der Datenbankverbindungen.
• Inhalt enthalten: Gesamter Quellcode von Engine (Kern-Engine) + Enterprise (Multi-Tenant-API) + Admin-Konsole (Verwaltungsschnittstelle) + Slackbot (Slack-Integration).
• Anwendbare Bedingungen: Sie benötigen Ihren eigenen Server oder Cloud-Host, um Docker Compose auszuführen und MongoDB, Vektordatenbank und LLM-API-Schlüssel selbst zu konfigurieren.
• Einschränkungen für die kommerzielle Nutzung: Die Apache-2.0-Lizenz erlaubt die kostenlose Nutzung und Änderung, das Produkt darf jedoch nicht direkt als SaaS-Dienst weiterverbreitet werden (vorbehaltlich der Lizenzbedingungen).

Enterprise Edition (unbekannte Preise):

• Schätzungsweise enthalten: SSO-Integration (SAML/OIDC), Prüfprotokolle, dedizierter SLA-Support, vorrangiger technischer Support, Bereitstellungsleitfaden für Unternehmen.
• Spekulationen zur Abrechnungsdimension: Ein kombiniertes Abonnementmodell basierend auf der Anzahl der Datenbankverbindungen + monatlichen API-Aufrufen + Anzahl der Benutzerplätze. In Bezug auf ähnliche Open-Source-Kommerzialisierungsprojekte (wie N8n, Appsmith) kann die jährliche Gebühr für die Unternehmensversion zwischen 5.000 und 50.000 US-Dollar liegen, dies ist jedoch nur eine Branchenschlussfolgerung und das offizielle Angebot ist maßgebend.
• Erwerbsmethode: Sie müssen sich an das offizielle Verkaufsteam wenden, um ein Angebot und eine Testversion zu erhalten. Die offizielle Website bietet keinen Selbstbedienungseingang für den Kauf.

LLM-Anrufgebühren (getrennt von den Dataherald-Produktgebühren):

– Hierbei handelt es sich um zusätzliche Kosten für die Nutzung von Dataherald, die direkt von der Wahl des LLM-Anbieters durch den Benutzer und dem Anrufvolumen abhängen. – Eine typische NL2SQL-Abfrage von GPT-4 verbraucht ungefähr 2.000–5.000 Token (Eingabeschema + Frage) und kostet basierend auf GPT-4 ungefähr 0,01–0,03 USD/Zeit. Die monatliche LLM-Gebühr für Hochfrequenzszenarien (durchschnittlich 10.000 Mal pro Tag) beträgt 3.000 bis 9.000 US-Dollar. – Durch die Verwendung von GPT-3.5-Turbo oder einem selbst gehosteten Modell können diese Kosten um das 10- bis 30-fache gesenkt werden, was möglicherweise auf Kosten der Build-Genauigkeit geht.

• Es wird empfohlen, die Kosten für LLM-Anrufe im Budgetmodell zu reservieren, die in der Regel die Kosten der eigenen Infrastruktur von Dataherald übersteigen.

Anwendungsszenarien von Dataherald

Szenario 1: Das Geschäftsteam sammelt selbst Daten

Aufgabenbeschreibung: Nicht-technische Teams wie Marktbetrieb, Vertriebsmanagement und Finanzanalyse müssen häufig Berichte aus dem Data Warehouse abrufen. Der traditionelle Prozess erfordert ① die Beantragung von Berichten im BI-Tool → ② das Warten auf die Planung durch das Data-Warehouse-Team → ③ die wiederholte Kommunikation von On-Demand-Details → ④ das Erhalten statischer Berichte. Dataherald vereinfacht es wie folgt: Benutzer stellen Fragen in natürlicher Sprache direkt in Slack oder der Admin-Konsole und erhalten sofort Abfrageergebnisse.

Tatsächliches Einkommen:

• Der einzelne Abfragezyklus verkürzt sich von durchschnittlich 4-6 Stunden auf 1-3 Minuten (Abzug). – Das Datenteam wird von der wiederkehrenden „SQL schreiben und SQL ändern“ befreit und konzentriert sich auf Datenmodellierung und Governance.
• Geschäftsteams können Daten frei erkunden, ohne auf die Planung warten zu müssen, und die Reaktionsgeschwindigkeit bei der Entscheidungsfindung wird verbessert.

Schwerpunkt der Implementierungsüberprüfung: Ob Geschäftsanwender bereit sind, die Gewohnheit des „Wartens auf Berichte“ zu ändern und aktiv Fragen in natürlicher Sprache zu stellen; und ob die Genauigkeitsrate der ersten Generation bei häufigen Abfragen 70 %+ erreicht (unterhalb dieses Wertes werden Benutzer aufgeben).

Szenario 2: Q&A-Funktionen für eingebettete Daten im SaaS-Produkt

Aufgabenbeschreibung: Datenintensive SaaS-Produkte wie CRM, ERP und Projektmanagement sollen es Endbenutzern ermöglichen, produktinterne Daten in natürlicher Sprache abzufragen, anstatt sich durch komplexe Filterschnittstellen zu kämpfen. Die Engine-API von Dataherald kann als „Datenanalyse-Assistent“-Funktion eines Produkts eingebettet werden.

Tatsächliches Einkommen:

• Reduzieren Sie die Lernkosten für Benutzer – Sie müssen die Filtersyntax nicht erlernen, Sie können Daten erhalten, indem Sie Fragen in Ihrer Muttersprache stellen.
• Reduzieren Sie den Entwicklungs- und Wartungsaufwand voreingestellter Berichte im Produkt – dynamische Generierung ersetzt feste Berichte.
• Verbessern Sie die Benutzerbindung und Datenaktivität und verwandeln Sie passives Betrachten in aktive und passive Erkundung.

Schwerpunkt der Implementierungsüberprüfung: Ob die Datenisolierung mehrerer Mandanten genau erreicht werden kann (Benutzer von Mandant A können die Daten von Mandant B nicht durch SQL-Injection sehen); und ob die Reaktionsleistung der Engine bei hoher Parallelität (z. B. zu Spitzenzeiten von SaaS) in einem akzeptablen Bereich liegt.

Szenario 3: Beschleunigung der Datenanalyse – komplexe Abfragegerüstgenerierung

Aufgabenbeschreibung: Wenn professionelle Datenanalysten mit komplexen Analyseanforderungen konfrontiert sind, die Multi-Table-JOIN, Fensterfunktionen und Unterabfragen erfordern, verwenden sie Dataherald, um schnell SQL-Grundgerüste zu generieren und dann auf dieser Grundlage eine Feinabstimmung und Optimierung durchzuführen.

Tatsächliches Einkommen:

• Es wird geschätzt, dass die SQL-Schreibeffizienz um das Zwei- bis Dreifache steigt, insbesondere bei unbekannten Tabellenstrukturen (keine manuelle Überprüfung der Schemadefinition erforderlich).
• Reduzieren Sie Syntaxfehler auf niedriger Ebene. JOIN-Bedingungsfehler, GROUP BY-Auslassungen, Missbrauch von Aggregatfunktionen usw. können durch KI-Generierung vermieden werden.
• Analysten können sich mehr auf die Datenanalyse und Geschäftsinterpretation statt auf das Debuggen der SQL-Syntax konzentrieren.

Wichtige Punkte der Implementierungsüberprüfung: Dataheralds Generierungsqualität für komplexe Abfragen (mehr als 4 Tabellen JOIN, rekursiver CTE, dynamischer PIVOT). Die aktuelle Version weist bei sehr komplexen Abfragen eine begrenzte Stabilität auf, und Analysten benötigen SQL-Funktionen zum Überprüfen und Korrigieren, anstatt den generierten Ergebnissen vollständig zu vertrauen.

Szenario 4: Slack eingebetteter Datenvorgang

Aufgabenbeschreibung: Unternehmen betten Datenbankabfragefunktionen über Slackbot-Komponenten in die Kommunikationskanäle der täglichen Arbeit ein. Das Management fragte im Kanal direkt nach der „Anzahl der Neukunden in dieser Woche“ und der Roboter antwortete mit den Daten; Das Einsatzpersonal fragte nach „Verteilung nach Regionen“, und der Kontext blieb konsistent.

Tatsächliches Einkommen:

• Reibungslose Datenerfassung – der gesamte Prozess des Zählens, Analysierens und Teilens kann abgeschlossen werden, ohne Slack zu verlassen. – Abfrageergebnisse und Konversationsaufzeichnungen werden natürlich in Slack-Kanälen gespeichert und bilden so einen nachverfolgbaren Datendiskussionsverlauf.
• Reduzieren Sie den „Dateninsel“-Effekt innerhalb des Unternehmens – nicht-technische Rollen sehen Datenkonversationen in öffentlichen Kanälen und lernen und imitieren auf subtile Weise das Datenabfrageverhalten.

Wichtige Punkte der Implementierungsüberprüfung: Die Fähigkeit von Slackbot, lange Konversationskontexte aufrechtzuerhalten; und die Compliance-Risiken sensibler Daten, die in Slack-Kanälen angezeigt werden (ob PII-Felder gefiltert werden müssen).

Anwendbare Gruppen von Dataherald

Core Adaptation Crowd

• Datenanalyst: Sie können Dataherald verwenden, um schnell SQL-Grundgerüste zu generieren, Doppelarbeit zu reduzieren und mehr Zeit für Dateneinblicke aufzuwenden. Voraussetzung für die Anpassung ist, dass Analysten über SQL-Audit-Fähigkeiten verfügen und durch KI generierte unvollständige SQL korrigieren können. Ungeeignete Szenarien: Produktionsszenarien, die strenge Qualitätsanforderungen an komplexe Abfragen stellen und keine SQL-Fehler tolerieren können.

• Geschäftsbetriebs-/Marketing-/Vertriebsteam: Erhalten Sie Datenberichte direkt in natürlicher Sprache und beseitigen Sie so die Abhängigkeit vom Datenteam. Voraussetzung für die Anpassung ist, dass das Datenmodell des Unternehmens relativ standardisiert ist (Feldnamen sind klar und mit Anmerkungen versehen) und die Abfrageanforderungen hauptsächlich auf aggregierten Berichten (Summen, Zählungen, Rankings, Trends) und nicht auf komplexen mehrstufigen Analysen basieren. Ungeeignete Szenarien: Situationen, die eine extrem hohe Datengenauigkeit erfordern (z. B. Finanzabstimmung) oder in denen die Abfragesprache Chinesisch ist und die Tabellen-/Feldnamen ebenfalls auf Chinesisch sind.

• IT/Dateningenieur: Verantwortlich für die Bereitstellung, Wartung und Golden SQLs-Beispielverwaltung des Dataherald-Systems. Voraussetzung für die Anpassung ist, dass das Team über Docker-Betriebs- und Wartungsfunktionen verfügt und bereit ist, Zeit in die kontinuierliche Optimierung der Schemakonfiguration, Beispielakkumulation und Modellfeinabstimmung zu investieren. Nicht anwendbare Szenarien: Teams, die kein Vollzeit-Betriebs- und Wartungspersonal haben, oder die Datenbank ist ein altes System (Feldnamen sind bedeutungslos und unkommentiert), oder die Datenaktualisierungshäufigkeit ist extrem hoch (Ebene pro Minute) und erfordert Schemabewusstsein in Echtzeit.

• SaaS-Produktmanager/Technischer Leiter: Evaluieren Sie die Einbettung von Dataherald in eigene Produkte, um Datenanalysefunktionen bereitzustellen. Die Anpassungsvoraussetzung besteht darin, dass das Datenszenario des Produkts hauptsächlich für abfrageorientierte Benutzer auf dem amerikanischen/europäischen englischen Markt gedacht ist. Nicht anwendbare Szenarien: Produkte, die auf den chinesischen Markt ausgerichtet sind (die Genauigkeit sinkt erheblich, wenn Datentabellen- und Feldnamen auf Chinesisch sind) oder Produkte, die eine erweiterte Berechtigungsprüfung und mehrschichtige Datenisolierung erfordern.

Unpassende Grenzen und Voraussetzungen

• Sprachbeschränkung: Beim Schemascannen und der NL-Generierung von Dataherald wird Englisch als Hauptarbeitssprache verwendet. Obwohl das zugrunde liegende LLM chinesische Eingaben verarbeiten kann, sind die Schemafeldbeschreibungen, Fehlermeldungen und Verwaltungsschnittstellen des gesamten Systems für Englisch konzipiert. In Szenarien mit chinesischen Tabellennamen und Feldnamen empfiehlt es sich, chinesischen Optimierungslösungen wie DB-GPT den Vorrang zu geben.
• Datenbankfragmentierung: Wenn die Datenbank eines Unternehmens auf mehr als 50 unabhängige Instanzen verteilt ist, von denen jede eine separate Konfiguration von Verbindungen und Schema-Scans erfordert, steigen die Wartungskosten linear an. Es wird empfohlen, nur auf das Kern-Data-Warehouse zuzugreifen, und Edge-Datenbanken erfordern weiterhin traditionelle Methoden.
• Modellabhängigkeitsrisiko: Dataherald bindet kein einzelnes Modell, aber die Qualität der SQL-Generierung hängt stark von den Fähigkeiten des gewählten LLM ab. Wenn Sie sich für kostengünstige Modelle wie GPT-3.5-Turbo entscheiden, entspricht die Genauigkeit bei komplexen Abfragen möglicherweise nicht den Produktionsanforderungen. Wenn Sie sich für GPT-4 entscheiden, können die Inferenzkosten zu einer Belastung für das Budget werden. Es wird empfohlen, während der PoC-Phase mehrere Modellkombinationen gleichzeitig zu testen.
• Datensicherheitsaudit: Obwohl die Enterprise-Komponente eine Basisauthentifizierung und Multi-Tenant-Unterstützung bietet, gibt der Beamte keine Compliance-Zertifizierungsinformationen wie SOC2/GDPR bekannt. Starke Compliance-Branchen wie die Finanz- und Medizinbranche müssen vor dem Kauf die Compliance-Bedingungen mit dem Vertriebsteam bestätigen.

Zusammenfassung und Ausblick

Dataherald bietet eine hochentwickelte Open-Source-Lösung im NL2SQL-Bereich für Unternehmen. Sein Kernwert liegt in der dreistufigen Pipeline-Architektur, dem schemabewussten Vektorabruf und dem geschlossenen Feinabstimmungsmechanismus von Golden SQL. Diese Designs unterscheiden es von einem einfachen LLM-Prompt-Wrapper.

Aktuelle Vorteile:

• Breite Datenbankabdeckung (9 Arten relationaler Datenbanken + 3 Arten von Vektorspeicher), führend bei der Open-Source-NL2SQL-Lösung.
• Komplette Komponenten (Engine + Enterprise + Admin-Konsole + Slackbot), nah an der Bereitstellungsform auf Unternehmensebene.
• Modellunabhängiges Design, nicht an einen einzelnen LLM-Anbieter gebunden, wodurch ein Wechsel nach Kosten und Szenario möglich ist.
• Je mehr Sie es verwenden, desto genauer wird es. Die durch Golden SQLs + Finetuning gebildete Beziehung verbessert kontinuierlich die Genauigkeit in proprietären Geschäftsdomänen.

Aktuelle Einschränkungen: – Das Projekt befindet sich seit Version 1.0.3 in einer Wartungsphase mit geringer Aktivität. Innerhalb eines halben Jahres gibt es keine neuen Feature-Versionen und die Community-Beiträge bleiben überwiegend bei marginalen Reparaturen. Langfristige Wartungsrisiken müssen bei der Auswahl eines Modells bewertet werden und bei Bedarf sollte ein Gabel-Selbstwartungsplan beibehalten werden.

• Unzureichende Unterstützung natürlicher chinesischer Sprache - Schema-Scanning und Feldbeschreibung NL-Generierung erfolgen hauptsächlich in Englisch, und die Szenario-Anwendbarkeit chinesischer Tabellennamen/Feldnamen ist begrenzt. – Die Generierungsqualität von ultrakomplexem SQL (JOIN mit mehr als 5 Tabellen, rekursiver CTE, dynamischer PIVOT, mehrstufige Unterabfrageverschachtelung) ist nicht stabil genug, erfordert eine sekundäre Überprüfung durch Analysten und kann nicht vollständig automatisiert werden. – Wichtige Geschäftsinformationen wie Preise für Unternehmensversionen, SLA-Verpflichtung und Compliance-Zertifizierung (SOC2/GDPR) wurden nicht offiziell bekannt gegeben. Unternehmen müssen vor dem Kauf eine nach der anderen über die Vertriebskanäle bestätigen.

Branchenausblick: NL2SQL bewegt sich von „benutzbar“ zu „benutzerfreundlich“, und der von Dataherald dargestellte technische Weg (Schemabewusstsein + Feinabstimmung des Abschlusses + Zusammenarbeit mit mehreren Komponenten) ist die richtige Richtung. Da sich die Grundfunktionen von LLM weiter verbessern (z. B. der Fortschritt neuer Modelle wie DeepSeek-V4 und GPT-5 bei der SQL-Generierung), wird der Genauigkeitsengpass von NL2SQL schrittweise gemildert. Bis dahin werden mittelständische Plattformen wie Dataherald, die über ausreichende technische Vorbereitungen verfügen, direkt davon profitieren. Voraussetzung ist jedoch, dass das Projekt seinen Wartungsrhythmus wieder aufnehmen kann, andernfalls wird es in Funktionalität und Ökologie von Alternativen mit höherer Community-Aktivität (wie DB-GPT, Vanna) überholt.

Beschaffungs-/Einführungsrisikobewertung: Es wird empfohlen, Dataherald als „Beschleuniger für Datenabfragen über nicht kritische Pfade“ und nicht als „Kerndateninfrastruktur“ einzuführen. Verwenden Sie zunächst die Open-Source-Version, um einen PoC in einem kleinen Bereich (1–2 Geschäftsteams und 5–10 Kerntabellen) für 2–4 Wochen durchzuführen, wobei der Schwerpunkt auf der Überprüfung ① liegt, ob die Genauigkeit englischer Abfragen 70 %+ erreicht, ② der Leistung des Schema-Scans und des Vektorabrufs in der eigenen Datenbank und ③ der Effektverbesserung nach der Feinabstimmung. Nach der Verabschiedung des PoC werden wir prüfen, ob es auf eine breitere Palette von Geschäftsszenarien ausgeweitet werden kann und ob Unterstützungsdienste für Unternehmensversionen erforderlich sind. Wenn das Projekt über einen längeren Zeitraum nicht in die aktive Wartung zurückkehrt, wird empfohlen, der Bewertung von Alternativen mit einer aktiveren Community als Migrationsziel Vorrang einzuräumen.

Verwandte Tools: github-copilot, Cursor

Versionsinfo

• Stabile Veröffentlichung ：Die erste stabile Version unterstützt mehrrundigen Dialogkontext, komplexe JOINs und die Generierung von Unterabfragen. Einen offiziellen genauen Termin gibt es noch nicht. （~2025-06）
• Beta ：Beta-Testversion, unterstützt grundlegende Text-to-SQL-Abfragen, noch kein offizielles genaues Datum. （~2025-03）