Datenbankabfragen in natürlicher Sprache mit OpenClaw

Geschäftsanwender benötigen Daten. Datenbankadministratoren schreiben Abfragen. Diese Lücke – zwischen der Person, die weiß, welche Frage sie stellen muss, und der Person, die weiß, wie sie die Antwort abrufen kann – kostet Unternehmen enorm viel Zeit und konzentriert analytische Engpässe bei den Personen mit SQL-Kenntnissen.

Diese Lücke schließt die Datenbankabfrage in natürlicher Sprache (auch Text-to-SQL oder NL-to-SQL genannt). Die NL-Abfragefunktion von OpenClaw ermöglicht es Geschäftsanwendern, Fragen in einfachem Englisch zu stellen und genaue Antworten aus ihren Datenbanken zu erhalten, ohne SQL-Kenntnisse, Anmeldeinformationen für den Datenbankzugriff oder das Warten auf einen Entwickler.

Dies ist nicht die einfache Chatbot-über-CSV-Erfahrung, die viele Tools bieten. Hierbei handelt es sich um Text-to-SQL in Produktionsqualität, das komplexe Abfragen mit mehreren Tabellen, Aggregatberechnungen, Datumsbereichsausdrücke und die Übersetzung von Geschäftsterminologie verarbeiten kann.

Wichtige Erkenntnisse

• Geschäftsanwender können Produktionsdatenbanken ohne SQL-Kenntnisse in einfachem Englisch abfragen – OpenClaw übersetzt natürliche Sprache in parametrisiertes SQL – niemals rohe Benutzereingaben in SQL (injektionssicher)
• Das Schemaverständnis über die semantische Ebene ordnet Geschäftsterminologie technischen Datenbankfeldern zu – Komplexe Abfragen einschließlich Joins, Aggregationen, CTEs und Fensterfunktionen werden unterstützt
• Die Ergebnisse werden in einem geschäftsfreundlichen Format mit Kontext und Visualisierungen zurückgegeben – Durch die Zugriffskontrolle wird sichergestellt, dass Benutzer nur Daten abfragen, zu deren Einsicht sie berechtigt sind – Abfrage-Caching reduziert die Datenbanklast und die Antwortzeit für häufig gestellte Fragen – Die Integration mit Odoo, PostgreSQL, MySQL, SQL Server, BigQuery und Snowflake ist nativ

---

Das Problem der Übersetzung von natürlicher Sprache in SQL

Die Übersetzung natürlicher Sprache in SQL ist trügerisch schwierig. Die scheinbare Einfachheit – „Stellen Sie einfach eine Frage, erhalten Sie eine Antwort“ – verbirgt mehrere schwierige Probleme, die darüber entscheiden, ob die Implementierung für die Produktion geeignet ist oder eine frustrierende Demo.

Problem 1: Terminologiezuordnung. Geschäftsanwender sagen „Umsatz“ – aber ist das das Feld invoice_total, das Feld order_amount oder das Feld payment_received? „Kunden“ könnte die Tabelle accounts, die Tabelle contacts oder eine Ansicht bedeuten, die beide verbindet. Ohne eine semantische Ebene, die Geschäftsterminologie einem technischen Schema zuordnet, muss der LLM raten – und er rät häufig falsch.

Problem 2: Schemakomplexität. Unternehmensdatenbanken verfügen über Hunderte oder Tausende von Tabellen. Eine Frage zum Thema „Umsatzleistung nach Region in diesem Quartal“ erfordert möglicherweise die Verknüpfung von 6 bis 8 Tabellen. Das LLM benötigt genügend Schemakontext, um den richtigen Join zu generieren, aber das Senden des gesamten Schemas bei jeder Eingabeaufforderung ist ineffizient und teuer.

Problem 3: Lösung von Mehrdeutigkeiten. „Zeigen Sie mir Top-Kunden“ – Top nach welcher Kennzahl? Welcher Zeitraum? Gibt es eine Schwelle für „oben“? Abfragesysteme in natürlicher Sprache, die mit Mehrdeutigkeiten nicht umgehen können, raten entweder (und liegen oft falsch) oder bitten um Klarstellung (was Benutzer frustrierend finden).

Problem 4: Korrektheitsüberprüfung. Sie können nicht einfach darauf vertrauen, dass die generierte SQL korrekt ist. Es muss validiert werden – syntaktische Validierung (wird es ausgeführt?), semantische Validierung (beantwortet es die beabsichtigte Frage?) und Ergebnisvalidierung (sehen die Ergebnisse plausibel aus?).

Problem 5: Sicherheit. Die Eingabe in natürlicher Sprache kann nicht direkt an die Datenbank übergeben werden. Das generierte SQL muss vor der Ausführung parametrisiert, validiert und zugriffskontrolliert werden. Andernfalls könnte ein Benutzer, der „show me sales where name = '; DROP TABLE sales;'“ fragt, echten Schaden anrichten.

Die NL-Abfragearchitektur von OpenClaw geht auf alle fünf Probleme ein.

---

Architektur: Wie OpenClaw NL-Abfragen funktionieren

Semantische Ebene

Die semantische Schicht ist die Grundlage für NL-Abfragen in Produktionsqualität. Dabei handelt es sich um eine strukturierte Definition Ihrer Geschäftskonzepte, die der Agent verwendet, um die Benutzersprache in Datenbankobjekte zu übersetzen.

Komponenten der semantischen Schicht:

Geschäftskonzeptdefinitionen: „Umsatz“ = SUM(invoice_lines.unit_price * invoice_lines.quantity) WHERE invoice.state = 'posted'. „Aktive Kunden“ = accounts WHERE account_type = 'customer' AND last_transaction_date > NOW() - INTERVAL '12 months'.

Terminologie-Aliase: Ordnen Sie mehrere Begriffe demselben Konzept zu. „Umsatz“, „Umsatz“, „Umsatz“ und „Einkommen“ werden alle in die Umsatzberechnung einbezogen. „Kunde“, „Kunde“, „Konto“ und „Käufer“ werden alle der Kontentabelle zugeordnet.

Beziehungsdefinitionen: Dokumentieren Sie, wie Tabellen zusammenhängen und welche Verknüpfungen für welche Fragen richtig sind. „An einen Kunden verkaufte Produkte“ erfordert einen bestimmten Verbindungspfad durch Bestellungen und Bestellzeilen – dokumentieren Sie dies einmal in der semantischen Ebene.

Metrikdefinitionen: Definieren Sie berechnete Metriken (Bruttomarge %, Kundenakquisekosten, ausstehende Umsatztage) mit ihren genauen Formeln vorab. Benutzer können diese Metriken namentlich abfragen.

Zugriffskontrolldefinitionen: Definieren Sie, welche Benutzerrollen auf welche Tabellen, Spalten und Zeilenteilmengen zugreifen können. Ein regionaler Vertriebsleiter kann nur die Daten seiner Region abfragen.

Pipeline zur Abfragegenerierung

Wenn ein Benutzer eine Frage in natürlicher Sprache einreicht, verarbeitet OpenClaw diese über eine mehrstufige Pipeline:

Schritt 1 – Absichtsklassifizierung: Klassifizieren Sie den Fragetyp (Suche, Aggregation, Trendanalyse, Vergleich, Ranking) und identifizieren Sie die primär beteiligten Entitäten.

Schritt 2 – Entitätsextraktion: Identifizieren Sie in der Frage erwähnte Geschäftsentitäten (Produkte, Kunden, Zeiträume, Regionen) und ordnen Sie sie den Konzepten der semantischen Ebene zu.

Schritt 3 – Mehrdeutigkeitserkennung: Identifizieren Sie mehrdeutige Begriffe und lösen Sie sie entweder mithilfe des Kontexts (vorherige Gesprächsrunden, Benutzerprofil) oder generieren Sie eine klärende Frage.

Schritt 4 – Schemaauswahl: Wählen Sie die relevante Teilmenge des Datenbankschemas aus, die zur Beantwortung der Frage benötigt wird. Dadurch wird verhindert, dass der LLM-Kontext mit irrelevanten Schemata überlastet wird.

Schritt 5 – SQL-Generierung: Generieren Sie SQL mithilfe der aufgelösten Entitäten, semantischen Ebenenzuordnungen und des ausgewählten Schemas. Die Ausgabe ist parametrisiertes SQL, niemals String-Interpolation.

Schritt 6 – Validierung: Überprüfen Sie die generierte SQL syntaktisch. Überprüfen Sie semantisch, ob die Frage beantwortet wird. Überprüfen Sie die Schätzungen der Zeilenanzahl, um Abfragen zu erkennen, die unerwartete Ergebnisse liefern würden.

Schritt 7 – Durchsetzung der Zugriffskontrolle: Stellen Sie sicher, dass der abfragende Benutzer Lesezugriff auf alle referenzierten Tabellen und Spalten hat. Fügen Sie automatisch Sicherheitsfilter auf Zeilenebene basierend auf dem Zugriffsprofil des Benutzers hinzu.

Schritt 8 – Ausführung und Ergebnisformatierung: Führen Sie die validierte Abfrage aus. Formatieren Sie die Ergebnisse für die geschäftliche Lesbarkeit – für Menschen lesbare Spaltennamen, geeignete Zahlenformatierung, Datumsformatierung und Kontext zur Bedeutung der Zahlen.

Schritt 9 – Antwort in natürlicher Sprache: Erstellen Sie eine Zusammenfassung der Ergebnisse in natürlicher Sprache. „Ihr Umsatz im ersten Quartal belief sich auf 4,2 Mio. US-Dollar, ein Plus von 23 % gegenüber dem ersten Quartal des Vorjahres. Das Wachstum wurde hauptsächlich durch das Enterprise-Segment (+41 %) vorangetrieben.“

---

Abfragekomplexität unterstützt

Die NL-Abfragefunktion von OpenClaw verarbeitet das gesamte SQL-Komplexitätsspektrum:

Einfache Suche:

• „Wie hoch ist der aktuelle Preis für Produkt SKU-1234?“
• „Zeigen Sie mir die Kontaktinformationen von Acme Corp.“

Aggregationen:

• „Wie hoch war der Gesamtumsatz nach Produktkategorie im letzten Quartal?“
• „Wie viele Neukunden haben wir dieses Jahr jeden Monat gewonnen?“

Mehrtabellen-Joins:

• „Welche Kunden haben in den letzten 6 Monaten Produkt A, aber nicht Produkt B gekauft?“
• „Zeige mir alle offenen Rechnungen, bei denen das Kreditlimit des Kunden geringer ist als der Rechnungsbetrag“

Zeitreihenanalyse:

• „Zeigen Sie mir den monatlichen Umsatz der letzten 24 Monate mit einem gleitenden 3-Monats-Durchschnitt an“
• „Vergleichen Sie die Vertriebsleistung der Vertriebsmitarbeiter zwischen dem 1. Quartal 2024 und dem 1. Quartal 2025“

Rankings und Top-N-Anfragen:

• „Zeigen Sie mir die Top-20-Kunden nach Lifetime-Wert“
• „Welche 10 Produkte haben die höchsten Rücklaufquoten?“

Kohortenanalyse:

• „Wie viel Prozent der im ersten Quartal 2024 gewonnenen Kunden sind heute noch aktiv?“
• „Wie hoch ist der durchschnittliche Customer Lifetime Value für Kunden, die über verschiedene Kanäle gewonnen wurden?“

Komplexe Geschäftsfragen:

• „Bei welchen Kunden besteht aufgrund der sinkenden Bestellhäufigkeit ein Abwanderungsrisiko?“
• „Welche Produktkombinationen werden häufig zusammen gekauft?“

---

Geschäftsbenutzererfahrung

Das Business-Benutzererlebnis ist bewusst einfach gehalten. Benutzer interagieren über eine Chat-Oberfläche oder ein eingebettetes Abfrage-Widget in ihren vorhandenen Tools.

Konversationsschnittstelle:

Benutzer: „Zeigen Sie mir den Umsatz des Verkäufers in diesem Quartal im Vergleich zu seiner Quote.“

Agent: „Hier ist die Quotenerreichung des Verkäufers für das erste Quartal 2026:

Sarah und Maria sind auf dem richtigen Weg. James liegt drei Wochen vor Ablauf der Frist um 128.500 US-Dollar hinter seinem Kontingent zurück. Möchten Sie James‘ Pipeline sehen, um zu beurteilen, ob er die Lücke schließen kann?“

Folgefragen: Benutzer können im Kontext Folgefragen stellen. „Welche Deals hat James in der Endphase?“ – Der Agent versteht, dass sich „James“ auf James Wilson aus dem vorherigen Gespräch bezieht.

Erläuterung: Benutzer können nach dem „Warum?“ fragen. oder „Wie hast du das berechnet?“ und der Agent erklärt die Berechnung und zeigt die zugrunde liegenden Daten.

Visualisierung: Für Trenddaten generiert der Agent neben der Tabelle ein Diagramm. Benutzer können bestimmte Diagrammtypen anfordern: „Zeige mir dies als Balkendiagramm“ oder „Plot dies über die Zeit“.

---

Sicherheitsarchitektur

Sicherheit ist für jedes System, das auf Produktionsdatenbanken zugreift, nicht verhandelbar. OpenClaws NL-Abfragesicherheitsmodell:

Schreibgeschützte Verbindungen: Die Abfrageverbindung verfügt über schreibgeschützte Datenbankberechtigungen. Strukturell ist es für den Agenten unmöglich, Daten über die NL-Abfrageschnittstelle zu ändern.

Parametrisierte Abfragen: Das gesamte vom Agent generierte SQL ist parametrisiert – vom Benutzer bereitgestellte Werte werden niemals in SQL-Zeichenfolgen verkettet. Dadurch wird das SQL-Injection-Risiko auf Architekturebene eliminiert.

Sicherheit auf Zeilenebene: Zugriffsrichtlinien werden zum Zeitpunkt der Abfragegenerierung durchgesetzt. Ein regionaler Vertriebsleiter erhält automatisch WHERE region = 'North' an alle Abfragen. Ein Kundendienstmitarbeiter kann nur die ihm zugewiesenen Konten sehen.

Zugriffskontrolle auf Spaltenebene: Sensible Spalten (Gehaltsinformationen, Sozialversicherungsnummern, Zahlungskartendaten) werden für Rollen ohne entsprechenden Zugriff vom abfragbaren Schema ausgeschlossen.

Abfragevalidierung: Vor der Ausführung durchläuft jede generierte Abfrage einen Sicherheitsvalidierungsschritt, der prüft auf: nicht autorisierte Tabellenverweise, Versuche, auf eingeschränkte Spalten zuzugreifen, verdächtige Abfragemuster und Abfragekomplexitätsgrenzen (um versehentliche oder absichtliche Abfragen zur Erschöpfung der Ressourcen zu verhindern).

Audit-Protokollierung: Jede Abfrage, wer sie wann gestellt hat und welche Daten zurückgegeben wurden, wird protokolliert. Dies unterstützt die Compliance-Berichterstattung und die Erkennung von Insider-Bedrohungen.

---

Integration mit Geschäftssystemen

Odoo ERP: OpenClaw ist tief in das Datenmodell von Odoo integriert. Die Geschäftsterminologie wird automatisch dem Odoo-Schema zugeordnet – „Kundenaufträge“, „Lieferantenrechnungen“, „Fertigungsaufträge“ und „Bestandsbewegungen“ werden alle korrekt in die entsprechenden Odoo-Tabellen übernommen.

PostgreSQL und MySQL: Direkte Verbindung mit vollständiger Schema-Introspektion. Die semantische Ebene wird während der Implementierung konfiguriert, um die Geschäftsterminologie dem spezifischen Schema zuzuordnen.

Analytische Datenbanken: Snowflake, BigQuery, Redshift und Databricks werden für Organisationen unterstützt, die Analysedaten in einem Data Warehouse zentralisieren. Diese Umgebungen verarbeiten komplexe analytische Abfragen (umfangreiche Aggregationen, historische Trendanalysen), die für Produktionsdatenbanken ungeeignet sind.

SQL Server und Oracle: Unterstützt für Organisationen, die Microsoft- oder Oracle-Datenplattformen ausführen.

Mehrere Datenbanken: Der Agent kann Abfragen über mehrere Datenbanken hinweg zusammenfassen – Fragen beantworten, die eine Kombination von Daten aus dem CRM (Salesforce) und dem ERP (Odoo) erfordern, ohne dass ein Data Warehouse erforderlich ist.

---

Implementierung: Aufbau der semantischen Ebene

Die semantische Ebene ist das wichtigste Implementierungsartefakt für die Qualität von NL-Abfragen. ECOSIRE baut die semantische Ebene durch einen strukturierten Prozess auf:

Woche 1-2: Entdeckung

• Befragen Sie Geschäftsanwender, um häufig gestellte Fragen zu sammeln
• Prüfen Sie das Datenbankschema mit technischem Personal
• Identifizieren Sie Terminologiekonflikte und Unklarheiten
• Priorisieren Sie die 50 häufigsten Geschäftsfragen

Woche 2–4: Aufbau semantischer Schichten

• Definieren Sie Geschäftskonzeptzuordnungen
• Schreiben Sie Metrikdefinitionen mit präzisen Formeln
• Join-Beziehungen dokumentieren
• Konfigurieren Sie Zugriffskontrollrichtlinien

Woche 4–6: Testen und Kalibrierung

• Testen Sie die 50 Prioritätsfragen anhand der semantischen Ebene
• Identifizieren Sie Nichtübereinstimmungen und verfeinern Sie die semantische Ebene
• Erweitern Sie die Tests auf 200 Fragen, die Randfälle abdecken
• Passen Sie die Konfidenzschwellen für Klärungsfragen an

Woche 6–8: Benutzerakzeptanztest

• Bereitstellung für eine Pilotbenutzergruppe
• Sammeln Sie Feedback zur Genauigkeit der Fragenbearbeitung
• Fügen Sie der semantischen Ebene Terminologie aus echten Benutzeranfragen hinzu
• Messen Sie die Genauigkeit der Fragen und Antworten

---

Häufig gestellte Fragen

Wie genau ist die Übersetzung von natürlicher Sprache in SQL in der Praxis?

Bei Fragen innerhalb des konfigurierten Semantikschichtbereichs erreicht die Genauigkeit bei Standard-Geschäftsfragen typischerweise 88–95 %. Bei hochkomplexen mehrstufigen Analysefragen und bei Fragen zu Schemabereichen, die nicht von der semantischen Schicht abgedeckt werden, ist die Genauigkeit geringer. Die Genauigkeit verbessert sich in den ersten 2–3 Monaten, da echte Benutzerfragen zur Verfeinerung der semantischen Ebene verwendet werden.

Kann der Agent SQL generieren, das direkt von einem Entwickler ausgeführt werden könnte?

Ja. Der Agent kann das generierte SQL optional Benutzern zugänglich machen, die es sehen, kopieren oder selbst ändern möchten. Dies ist besonders wertvoll für Datenanalysten, die mit einer generierten Abfrage beginnen und diese weiter anpassen möchten. Die Schnittstelle zeigt die natürliche Sprache, das generierte SQL und die Ergebnisse zusammen an.

Was passiert, wenn der Agent eine Frage nicht versteht oder die Frage nicht eindeutig ist?

Der Agent stellt eine klärende Frage, anstatt zu raten. Beispiel: „Wenn Sie „Umsatz“ sagen, meinen Sie damit den in Rechnung gestellten Umsatz (einschließlich unbezahlter Rechnungen) oder den eingenommenen Umsatz (eingegangene Zahlungen)?“ Klärungsfragen werden auf ein Minimum beschränkt – der Agent löst eindeutige Fälle automatisch und fragt nur, wenn die Unterscheidung tatsächlich Auswirkungen auf die Antwort hat.

Wie gehen wir mit Fragen um, deren Beantwortung in Echtzeit zu ressourcenintensiv wäre?

Der Agent schätzt die Abfragekosten vor der Ausführung. Fragen, die große Tabellen scannen oder kostspielige Vorgänge ausführen würden, werden entweder an die Analysedatenbank (falls verfügbar) umgeleitet, als Hintergrundjobs mit asynchroner Bereitstellung der Ergebnisse geplant oder dem Benutzer mit einer Warnung zur Ausführungszeit und der erforderlichen Bestätigung angezeigt.

Können technisch nicht versierte Geschäftsbenutzer mit dieser Funktion Berichte erstellen?

Ja. Die NL-Abfrageschnittstelle kann Ergebnisse nach Excel exportieren, statische Berichte generieren und gespeicherte Abfragen erstellen, die nach einem Zeitplan aktualisiert werden. Geschäftsanwender können ohne Entwicklerunterstützung persönliche Berichte aus Abfragen in natürlicher Sprache erstellen. Gespeicherte Abfragen können mit anderen Benutzern geteilt werden, wodurch nach und nach eine Bibliothek mit häufigen Abfragen erstellt wird, auf die das Team verweisen kann.

Welche Datenbanken werden nicht unterstützt?

Proprietäre oder geschlossene Datenbanken ohne Standard-SQL-Schnittstellen (einige NoSQL-Datenbanken, benutzerdefinierte Datenspeicher) erfordern möglicherweise zusätzliche Entwicklung für die Integration. Dokumentendatenbanken (MongoDB) und Schlüsselwertspeicher (Redis) erfordern andere Ansätze als relationale Datenbanken. Für diese Fälle entwirft ECOSIRE eine benutzerdefinierte Integration, die die entsprechende Abfragesprache anstelle von SQL übersetzt.

---

Nächste Schritte

Datenbankabfragen in natürlicher Sprache beseitigen einen der hartnäckigsten Engpässe in der Geschäftsanalyse – die Kluft zwischen Personen, die Fragen haben, und Personen, die Anfragen schreiben können. Die NL-Abfragefunktion von OpenClaw, ordnungsgemäß implementiert mit einer starken semantischen Ebene, ermöglicht jedem Geschäftsbenutzer direkten Zugriff auf seine Daten.

[Erkunden Sie die benutzerdefinierten OpenClaw-Skills] (/services/openclaw/custom-skills), um mehr über die NL-Abfragefunktion und andere benutzerdefinierte Skill-Optionen zu erfahren, oder vereinbaren Sie eine Datenbankbewertung, um zu sehen, wie sich OpenClaw Ihrem spezifischen Datenschema und Ihren Geschäftsfragen anpassen würde.